System ignoring behaviour for >3 NPC instances [solved]

Hi all!

I'll keep this brief. I have a level in which enemy NPC units wander on a set course. They wander between pre-defined and positioned position-sprites.

Everything is running just fine and dandy ... until I add more than 3 enemies. Then the 4th, 5th, 6th etc. simply get ignored by the Enemy wander script. I cannot get my head around this.

Here is the code:

And the map (the red points are the position markers):

And finally, the Enemy properties:

It's driving me a little nuts. 3 or less and everything's peachy, but subsequent enemies are ignored...

From the debug view I can see that these extra enemies' bullet behaviour just stays on 'False' the whole time. If I force it on (with a key-press or whatnot) then they activate, but then they just walk off the screen, ignoring all collisions. Very annoying!

Any help would be much appreciated!! I can try and bust out a custom .capx if necessary but it'll take a while so I'd rather avoid it!

Jimzip

Man thats tough.

It sounds like the enemys never trigger your first event, if they have no collision activated.

Do you add them to the layout before testing or do you spawn them in by debug command?

Also is the "trigger once" in the first event necessary?

It should trigger just ones for each enemy even without this.

Hey dsminor thanks for the reply! Much appreciated. I've been hacking away at this since your post & still haven't found a solution (but I did remove the 'trigger once' you mentioned!).

Collisions are indeed activated. What's more curious is that every few runs, the 4th enemy actually moves! He walks to the first point and stops there! It happens seemingly at random, I didn't change anything.

A couple of interesting points:

1) if I disable the 'for each enemies' at the start of the patrolling behaviour, they all move! (The problem here being that they all copy the first instance's movement). SO I've ruled out something being wrong with instances themselves.

2) if I change 'For each enemy' to "for each enemy, pick by IID ascending" then the last 3 work, and the 1st stops working! It's bizarre.

Again, any suggestions, help or thoughts on this would be much appreciated. I see no reason why the 4th shouldn't work. I've checked to see if there is interdependence or if something is interfering and so far I've come up with nada.

Jimzip

For anyone who wants to take a crack at this, I knuckled down and made a .capx:

https://www.dropbox.com/s/3gaqlp8ky5ycr ... .capx?dl=0

Note that in the TEST_REGION layout, all of the enemies actually do start patrolling, but one after the other, and in a weird, delayed manner - while in the cavern level they do not. (There should only be a 1 second delay at each point). There's nothing special about the cavern, as you can check. Honestly, I'm about to give up!

As I've stripped away almost the entire project (leaving one level so you can see it in context), and the problem remains - I honestly think this is a construct bug - and at this point I'd love to hear that my code is the problem!! Please take a look if you can (and sorry for all the junk in the capx, I just didn't have time today to strip it all totally clean).

Jimzip <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

WIll i get a cake if i solve this?

btw i really like the artstyle.

It's the "Every 0.05 seconds" in event 129. Get rid of it.

Yes thats right i would put it in event 118 though, so the system dont need to loop all enemys ~60 times a second.

Aw! You guys are amazing, thank you.

blackhornet do you know why the time condition would have had that effect on everything? It seems to have made the timing of everything very erratic, I wouldn't have expected that.

In any case, all fixed, I'm so glad it was that simple!

Oh and dsminor, cheers, much appreciated! Here you go:

X)

Jimzip

nice thx

You have to stand back and think: when will that condition be true? It's only true every 0.05 seconds so as you are calling 'For each', only one of your Enemies will hit that condition while it is true, and do the following actions, the others in than particular call of 'For each' won't be true. So it's a complete crap-shoot as to which Enemy will be picked when that condition is actually true. Your 'On collision' really shouldn't be buried where it is either, but if it's working, it's harder to argue against that one.

blackhornet I think see your point. I'm still trying to get my head around how to think about it in the terms you described. In my head this event went: if x, y, and z, every 0.05 seconds do abc - the timer obviously being just an attempt to save CPU.

If I were trying to save processing overhead then, what would be the correct way to limit this? Sorry to extend this thread but I think it's important to know as my thinking about these things is obviously a bit skewed. Thanks for your answers thus far.

Jimzip

The key is cause-and-effect. Your patrolling loop at the moment says: "I have no idea when the Enemy should move, so I will check every X seconds to force him to move". This statement is false, you know exactly when the Enemy needs to move. He needs to move at the beginning of the game, and he needs to move after a small delay when we hits his PositionMarker - there is no guess work here, these are all absolute points in time that you know about.

I've reworked your code to remove the loop completely. I've added one function, since you need to call the function on startup, and on collision. There were also subtle bugs in there that weren't obvious because you were calling the same code every 0.05 seconds, which was accidentally fixing the problem - namely, you were setting the bullet angle after setting the speed - this actually doesn't work, the speed needs to be set first, or the angle isn't picked up.

http://www.blackhornettechnologies.com/ ... gered.capx

Hey — Thanks a lot for the help, I see the issue now - once I checked your solution it made sense. Much appreciated! I'm now picking through the rest of the code to see where else I've misused loops.

Jimzip