*a semi-desperate bump*

*help request bump*

*bump*

I'm really excited to add my (future) game to this new set-up. Looking good, Scirra Bros!

CAPX: https://www.sugarsync.com/pf/D6025908_4317202_6996048

Because my issues are multi-faceted, I've decided to break it up into individual posts, but they're all related.

Here's the rundown on how the Enemy behavior is SUPPOSED to behave:

When the AllEnemies family variable is set to...

1. Normal - The Enemy instances will travel between the PatrolNode object; the directions are determined by the frame number of the object.

2. Chase - When the Player comes into view of the Enemy line of sight, the Enemy will chase the Player until line of sigh is lost.

3. Alert - The Enemy will patrol from within a radius from the last known spot the Player was seen. After so much time has elapsed, the Enemy will return to its original patrol route.

4. Resume - After the Alert phase is over, the Enemy will seek out the PatrolZone it was assigned to at the start of the level, preventing Enemies from congregating in one zone.

PROBLEM 3

I mentioned this a little in Problem 1...

I need my patrol system to be adaptable to whatever level I place the PatrolNodes in. I've been trying several different set-ups so that the Nodes can identify with other Nodes that are possible route destinations.

Presently, I've simplified the possible routes FROM each Node (no more than two; previously there were up to four directions possible). What I'm doing now is trying to set it up so that the possible routes (variables Direction1 and Direction2) are turned on or off (based on boolean WhichDirection. So if a Node has north and south as route options, if the Enemy is moving south, then the south option will be "on", allowing the Enemy to continue south and not be forced back north. But on a return trip, the north option will be turned on and the south turned off (since the last pass), allowing the Enemy to continue north. So each pass toggles the direction the Enemy can take.

CAPX: https://www.sugarsync.com/pf/D6025908_4317202_6996048

Because my issues are multi-faceted, I've decided to break it up into individual posts, but they're all related.

Here's the rundown on how the Enemy behavior is SUPPOSED to behave:

When the AllEnemies family variable is set to...

1. Normal - The Enemy instances will travel between the PatrolNode object; the directions are determined by the frame number of the object.

2. Chase - When the Player comes into view of the Enemy line of sight, the Enemy will chase the Player until line of sigh is lost.

3. Alert - The Enemy will patrol from within a radius from the last known spot the Player was seen. After so much time has elapsed, the Enemy will return to its original patrol route.

4. Resume - After the Alert phase is over, the Enemy will seek out the PatrolZone it was assigned to at the start of the level, preventing Enemies from congregating in one zone.

PROBLEM 2

I'm told by — that some of my Event lines need some For Each conditions (he didn't have time to help me see which ones, though). Arima informed me to treat Families (which my Enemy objects exist in) as objects in their own right with each object in the family as an instance. Makes sense. But I'm still lost as to what I need to change.

CAPX: https://www.sugarsync.com/pf/D6025908_4317202_6996048

Because my issues are multi-faceted, I've decided to break it up into individual posts, but they're all related.

Here's the rundown on how the Enemy behavior is SUPPOSED to behave:

When the AllEnemies family variable is set to...

1. Normal - The Enemy instances will travel between the PatrolNode object; the directions are determined by the frame number of the object.

2. Chase - When the Player comes into view of the Enemy line of sight, the Enemy will chase the Player until line of sigh is lost.

3. Alert - The Enemy will patrol from within a radius from the last known spot the Player was seen. After so much time has elapsed, the Enemy will return to its original patrol route.

4. Resume - After the Alert phase is over, the Enemy will seek out the PatrolZone it was assigned to at the start of the level, preventing Enemies from congregating in one zone.

PROBLEM 1

I can't get the Enemy to begin its patrols normally.

Initially, I had each PatrolNode spawn its own array. In the array was stored the IIDs of other Nodes that lied in the path if you drew a line from one Node to another. This way I could pick the Node to Pathfind to based on the starting Node's available directions.

Then, I created an image point to act as a "horse following a carrot held on a string". While in Patrol mode, the Enemy will plot a path to its own image point every so many seconds. But at the start of the layout, all Enemy instances start moving forward only to veer off and keep going until they hit a wall...

I finally caved and added the Bullet behavior to the AllEnemies family (I wanted to keep things simple and work with just Pathfinding). Even after ensuring that the speed and acceleration of the Enemies are greater than zero and initially enabled, they do not move.

So I'm really lost as to what I'm doing wrong.

CAPX: https://www.sugarsync.com/pf/D6025908_4317202_6984579

Please forgive me for the HUGE problem-laden post here. I don't expect anyone to be able to help me with EVERYTHING, but any input could prove useful. Thanks.

Here's the rundown on the Enemy behavior:

1. Patrol - The Enemy instances will travel between the PatrolNode object; the directions are determined by the frame number of the object.

2. Chase - When the Player comes into view of the Enemy line of sight, the Enemy will chase the Player until line of sigh is lost.

3. Alert - The Enemy will patrol from within a radius from the last known spot the Player was seen. After so much time has elapsed, the Enemy will return to its original patrol route.

4. Resume - After the Alert phase is over, the Enemy will seek out the PatrolZone it was assigned to at the start of the level, preventing Enemies from congregating in one zone.

The problem I'm having is multi-fold.

1. I can't get the Enemy to begin its patrols normally. I've created an image point to act as a "horse following a carrot held on a string". While in Patrol mode, the Enemy will plot a path to its own image point every so many seconds. But at the start of the layout, all Enemy instances start moving forward only to veer off and keep going until they hit a wall...

2. I'm told by — that some of my Event lines need some For Each conditions (he didn't have time to help me see which ones, though). Arima informed me to treat Families (which my Enemy objects exist in) as objects in their own right with each object in the family as an instance. Makes sense. But I'm still lost as to what I need to change.

3. I need my patrol system to be adaptable to whatever level I place the PatrolNodes in. I've been trying several different set-ups so that the Nodes can identify with other Nodes that are possible route destinations. (For example, I had each Node fire off an object that, when it collided with another Node, it would store the target Node's IID into an Array. That Array would later be used to reference WHICH Nodes were acceptable destinations via Pathfinding.) Presently, I've simplified the possible routes FROM each Node (no more than two; previously there were up to four directions possible). What I'm doing now is trying to set it up so that the possible routes (variables Direction1 and Direction2) are turned on or off (based on boolean WhichDirection. So if a Node has north and south as route options, if the Enemy is moving south, then the south option will be "on", allowing the Enemy to continue south and not be forced back north. But on a return trip, the north option will be turned on and the south turned off (since the last pass), allowing the Enemy to continue north. So each pass toggles the direction the Enemy can take.

I think that "sums" it up nicely. Thank you, again, for your input and suggestions. I'll be glad for any help to get this worked out.

Jase00 - Aw, dude, that was so sweet! :) LOL

Excal - That's essentially what I'm doing now. I started this post as a kind of joke, but then got to thinking as I typed it that it might...MIGHT...be a functional idea. Heh, but I'm sure Ashley would agree with you.

naelian - Sounds interesting. Could you elaborate some more? I'm not sure I totally followed.

I completely jest. LOL

I was thinking how I have this patrol system for my enemies to follow. Depending on the frame of the object, its two instance variables will have different values. Then, on top of that, I need to check at what times those values are accessed. If one is accessed, it should be "turned off", so it can't be accessed again. Kind of like a "Trigger Once" condition. Then, on another pass, the previously "off" instance variable would be "turned on", and the other back to "off".

In a sense, I guess my thought is something akin to making certain variables temporarily "non-existent", similar to how groups or behaviors can be enabled or disabled.

So, maybe I'm not totally joking. LOL I do realize the practicality of making such a feature would perhaps be more trouble than its worth.

Thoughts?

How about the option to have selected variables and/or properties of objects/instances appear next to the objects/instance(s) in question. Similar to how we'd create debug text objects to appear along side each object.

So, say we have an object that has a Pathfinding behavior and 3 variables. There are two instances of this object.

We want to evaluate the Pathfinding status and two of the variables for just one particular instance. So, we check off some check boxes next to the info in the debug window and those details appear alongside that particular object instance. A check of a box and info will appear/disappear from that text display.

This way, we don't have to play hide-and-seek through various tables of info which may be separated from several other tables in the debug window.