Drawbacks to EffectCutSceneGhost() for large # of NPCs/creatures?

[Legacy_OldTimeRadio]

               I had a bunch of NPC's (100, spread over 4 tiles) for something else I was testing and I thought "Wouldn't it be cool if you could just have a big mass of NPC's walking around a city, doing stuff, instead of looking so empty as most of them do?"

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?
               
               

               
            

[Legacy_henesua]

               Tangent:

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.
               
               

               
            

[Legacy_OldTimeRadio]

               You'll want to test it out of course but, I believe with this setup OnBlocked may only fire for doors.  If you do test this out, please post the results because getting rid of that OnBlocked event for creatures should be one of the big resource savers.  I found a number of horror stories about how frequently OnBlocked can fire, even in unexpected situations like combat.  However, with the combat perspace distance keeping I observed, this may still be going on in some fashion.
               
               

               

                     Modifié par OldTimeRadio, 08 janvier 2013 - 02:57 .
                     
                  

            

[Legacy_henesua]

               Exploring the OnBlocked event is of general interest to me. So eventually I will get around to it.

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 .
                     
                  

            

[Legacy_OldTimeRadio]

               Good to know and another reminder that what was once true (as evidenced by a thread in the Omnibus) may not be true, today.

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:

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.

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().
               
               

               

                     Modifié par OldTimeRadio, 08 janvier 2013 - 04:04 .
                     
                  

            

[Legacy_Pearls]

               afaik there are no substantial drawbacks, it is also one of the best fixes for the push exploit, thats what we originally used it for
               
               

               
            

[Legacy_Highv Priest]

               I used an invisible wall behind doors that gets destroyed when the door is opened and respawns if the door gets locked again. Works great, they try to push and can phase into the door, but don't get to the other side. It also TRAPS them there and they have to relog to escape so it teaches them a lesson too. The only real issue with using effectcutsceneghost is that players can move through them.(basically the monsters can't surround him) So if you don't particularly care that a player can CHARGE through a wall of enemies like they didn't exist in the first place(albeit they can hit him all the way through) then it works. Also I am working on a much more efficient pathfinding system, but I'm stuck between working on 3 -huge- projects lol and college at the same time. I have my upgrades to Castle of The Damned, the ultimate drops system, and pathfinding to work on and my priority for them is in that order.

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 .