Drawbacks to EffectCutSceneGhost() for large # of NPCs/creatures?
#1
Posté 08 janvier 2013 - 01:41
So I slapped EffectCutSceneGhost() on them all and they seemed to snap out of their pathfinding induced stupor and started walking the three waypoints I'd given them like it was no big deal. Of course they ignored each other's personal space (and presumably would also ignore PWK's), but other than that they seemed to do just fine. I started a fight and they all attacked me but kept their combat perspace distance, which I thought was interesting. I'd be fighting them, run into the center of them and they'd reform their little combat perspace circle around me over the course of a few seconds.
I don't mind the trade off with believability. Are there other drawbacks with this technique that I might be overlooking?
From a CC maker's perspective, the more I learn the less I like how the pathing works- for anything but pure walkmesh, anyway- and so far I feel like I'm winning any way I cut it doing NPC's like this.
Or am I?
I figure there are a couple of other things I can do to soak these guys for all they're worth like setting them not to be targetable in appearance.2da, but I'm wondering if the core idea holds water.
Thoughts/experiences?
#2
Posté 08 janvier 2013 - 02:46
I had not considered doing what you have. I had reserved cutscene ghost for utilitarian purposes. But you have given me the idea of making some adjustments to incorporeal creatures. One of the adjustments would be to add this effect to them when they spawn. Another would be to test the OnBlocked Event with and without this effect.
#3
Posté 08 janvier 2013 - 02:56
Modifié par OldTimeRadio, 08 janvier 2013 - 02:57 .
#4
Posté 08 janvier 2013 - 03:11
Incidentally I have been using the default script profiler* to see how many times these scripts run, and OnBlocked doesn't appear to be a problem at all. I wouldn't put too much credence to those horror storeis if I was you. I think the events to focus on making more efficient are OnPerception, OnHeartbeat, and OnCombatRoundEnd. The DetermineCombatRound function could be improved also for that matter. And then there is spell hooking, and in some cases the PC loop in the module heartbeat. OnBlocked is way down that list as far as I can tell.
* - yes, I know that many speak of the default profiler with derision, but I don't care. I'm using it to get a relative handle on how often a script executes and how much overhead each has relative to others, not an objective understanding. In this case knowing how often a script executes is all that really matters. The OnBlocked event isn't called anywhere near as many times as OnPerception and both scale up in terms of overhead with an increase in the number of creatures in an area. They are exponential in this regard - or what is the term ... factorial?
Modifié par henesua, 08 janvier 2013 - 03:12 .
#5
Posté 08 janvier 2013 - 03:55
If you or anyone else is interested in playing around with this effect, here is my test module:

Instructions:
Load the module, enjoy the clumping of 100 NPC's all trying to get through each other to a few waypoints and then, when you can't take it no more, click the lever. It's quite a thing to see...
BTW, best viewed with shadows turned OFF!
More info:
A combination of two things have been bugging me a bit in regards to NPC pathing lately. This (Omnibus: Babiak AND slowest) pathing hierarchy as described by Robert Babiak of Bioware:
And the second is this video, which isn't necessarily indicative of NPC pathfinding but shows the squirrely crap that can go on behind your back (or I suppose "on your behalf") when the CPU tries pathing through a complex environment. Only a single click is made in the video, and that's on the lever on the raised area. The subsequent movements are all from the CPU attempting to pathfind. I don't know how much of this sort of thing applies to NPCs but I don't like the idea of them in similar states- hence, looking at other approaches such as EffectCutSceneGhost().Robert Babiak wrote...
We do the searching based on the item that will change the least. There is no point in testing if the creature that is blocking you if your destination is blocked by a building.
The other is the relitive cost of determinig if we have intersected a non walkable area. the Tile walkmesh is highly optimized based on the fact that it does not change (we computer the aabb at designtime for this reason). So the test of the tile is the fastest, and we get the most comon blocking thing out of the way first.
now placables may be created dynamicaly so we have a list of bounding boxes that we use to determin if you
are near a placable object we iterate thru this list (slower than the AABB) and determin if we intersect any of the placable objects, secon most common thing you bump into.
Last we test creatures. they are in a list sorted on there X axis. This is optimized for the perseption system not path finding. and to find out if we bump into a creature we need to go thru a chunk of this list. and then determin if the two creatures bump.. slowest operation.
Over all this is done so that we can eliminate a path as invalid in the least amount of time.
Modifié par OldTimeRadio, 08 janvier 2013 - 04:04 .
#6
Posté 08 janvier 2013 - 07:54
- OldTimeRadio aime ceci
#7
Posté 08 janvier 2013 - 04:02
EDIT= Using SetAILevel I effectively disabled the calculations of BioWare's generic pathfinding in place of my own. The creature travels it's distance with a delaycommand resetting it's AILevel back to what it was before based on how fast the creature can move to get to that location.
Modifié par Highv Priest, 08 janvier 2013 - 04:12 .





Retour en haut







