Rhindon's Forum Posts

  • I want to install the MoveTo behavior, but, even after following Ashley's instructions to drag-n-drop it to C2 or to move the file to the C2 directory sub-folder, I cannot get it to work. The file extension I download is a .7z...it doesn't seem like that's what all the other plugins are like. And going to other links that Rex provides seem to be non-existent for the most part or no longer maintained. I'm at a complete loss right now.

  • rexrainbow - I downloaded your MoveTo behavior and, as Ashley said we could do, dragged it into C2, itself. The only behavior I see, though, is a "Drag & Drop", which I didn't add. What am I doing wrong?

    Thanks, man.

  • — - Right. Again, sorry for the confusion. The whole thing has been a mess the more I try different things.

    Right now the Normal status is the only status that uses Bullet behavior while I try to work out yet another variation to my system. Just trying to see what will work and what won't.

    The logic is that, in Normal status, the Enemy will travel via Bullet behavior between the PatrolNode objects. When it collides/overlaps with a PatrolNode, it'll be instructed on which direction to travel in (depending on the frame of the PatrolNode object, as identified by the colored arrows).

    Does that make sense any? Thanks, again, for your time.

  • — - Same initial information, but the problem info is different. In this post, it has to deal with where I might need to use the "For Each" event instruction with the AllEnemies family.

  • Joannesalfa - That's not too far off from what I'm looking for. I didn't see it while I was running FROM the wolves in your game (LOVE the initial set-up and the graphics!), but the Enemies in my game will eventually return to their original posts after a chase. But I'm still having trouble even getting the Enemies to START a patrol at the start of the game.

  • — - *facepalm* Doh! Sorry for the confusion. "Normal" is the correct status name; not "Patrol". Same difference, though.

    Yeah, the reason for the complex Patrol system is because I had one very early system set up where, say if the Enemy overlaps/collides with the NodePatrol object at the south end and I send it west or east, it's at the very bottom edge and may not actually collide with the next Node...literally brushing just by it. I was having trouble with that at the start, thus why I decided to stick with the Pathfinding behavior - to be sure that the Enemy always knows what its goal is and that it gets there.

    Joannesalfa - Thanks for looking, too! I'll check out your stuff and let you know...

  • *a semi-desperate bump*

  • *help request bump*

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • *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.