Rhindon's Forum Posts

  • CAPX - https://www.sugarsync.com/pf/D6025908_4317202_6987262

    I've swapped out all my events and actions for my Enemy objects and replaced them with the AllEnemies family (all Enemy objects are in the family folder).

    But for some reason, I cannot figure out why the enemies will not so much as move along the path via Path Finding. I've double-checked the ChaseStatus variable and that's good. Debug shows nothing out of the ordinary that I can see.

    Is there something about the Families option that is preventing me from getting my enemies from moving along the paths via Path Finding?

    (I can go into greater detail if you need me to...)

  • eldods - :) Man, Ashley hasn't even confirmed that it WILL be in C2. We still need him to confirm that he LIKES the idea. Thank you for the enthusiastic support, nonetheless! :D

  • Similar to Path Finding, I would like to recommend a Path Making behavior.

    Where as Path Finding plots its path to a selected point according to the obstacles between Point A and Point B, Path Making would define a strict, straight, specific path the objects would follow...a patrol route, in essence.

    This could be used for enemies in a top-down game to patrol prescribed zones or bosses in side-scrollers to follow a pattern to be discovered (revealing a weak point in the process).

    At present, I'm trying to work out my own patrol system/Path Making behavior from the existing C2 engine, and I'm frequently hitting road blocks. What I've worked out so far is to create these "nodes", contain them with variables and/or arrays that define which directions are open for the character to pursue, and then tell it to find the path from that node to the next node. This has worked, with much pain and labor, but it's not perfect.

    What I propose then, is that the Path Maker behavior will allow you to set similar nodes which will give you the option to define how the character will behave when it arrives at that node:

    • will it randomly choose from all available path?
    • will it be able to choose the path it arrived on?
    • will it cycle through the paths in a sequential order?

    You can further choose the angle the paths are set at as they branch out from each node (and of course, there will be the option to choose how obstacles are set).

    The main difficulty I've had in setting up my own system like this is how to place each node in a way that, regardless of how I arrange the nodes, it will have the information it needs on which node to travel to next. But in this case, the character needs only to know to follow the patrol path established by whichever node it originates from. If that path leads to another node, then that path, though perhaps originating from another node, is considered a viable pathway (perhaps an option to make paths one-way regardless of its origins?).

    In summary:

    1. Nodes are origin points for paths.

    2. Paths can be set at any angle.

    3. Per-node options to dictate...

    -- How the character will choose a new path.

    -- Which paths are available to select from.

    -- If paths are one-way or two-way.

    -- The length of the path or if it is to end at another node it overlaps.

    4. The character will strictly follow the path, similar to Path Finding.

    5. Paths that overlap other nodes will be considered viable paths to select from unless the parameters of the originating node dictate otherwise.

    (See my crude illustration here: https://www.sugarsync.com/pf/D6025908_4317202_6987563.)

    This is probably an idea that would require some refinement if it's applied to updates to C2, but I hope it's a viable one.

    Your thoughts?

  • Right now, setting an instance boolean variable is limited to toggling the true/false value of the variable. But I'd like to see a feature where I can set the boolean of one instance variable to the value of another boolean instance variable.

    For instance...

    Object 1 hits object 2. Both have a boolean instance value "is hit". Upon object 1 registering there is a collision, its "is hit" boolean changes to "true". Object 2 (for whatever reason) checks the value of Object 1's "is hit" (now "true") and says "set Object 2 'is hit' to the value of Object 1 'is hit'".

    This way it works just like other variables where Variable1 can set its value to whatever Variable2's value is (be it string or number).

    Can we do this?

  • Thank you, once again, — I'll look it over and see what I can work out. I'm probably gonna scrap my Patrol system (during Normal status) and try to simplify it... May I petition you for further help in the future?

  • blackhornet - I think I understand. So it won't hurt anything if I were to delete such Browser events/actions? (I'm gonna read up on the manual before I change anything, though.)

    I noticed a couple of things, though, when I repositioned the patrol zones.

    CAPX: sugarsync.com/pf/D6025908_4317202_6971329

    1. The enemy does not automatically begin his patrol at the start of the game.

    2. When the enemy approaches the upper-left Node, it seems to stutter.

    3. I didn't change anything in my PatrolRoutes event sheet, but when the enemy approaches the upper-right Node, it never takes the occasional downward trip to the bottom-right Node. (I'm considering altering this set-up anyway - removing the random nature in which way the enemy will go when it reaches a junction.)

    What can you see in light of these issues?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Rest well, Scirra Bros! Thank you for the heads up!

  • blackhornet - Okay, so here's where I stand with your changes...

    Event: Your changes

    Action: Set MyMind to "blown"

    I never once thought to look into using the Browser object. CLEARLY I have some research to do!

    In the meantime, can you give me a summary of what's actually going on with the use of the Browser object, please? Like, amongst other things, what's all the "Log in console" about?

    Thank you so much! You've just helped me complete the final piece to what's been a three-month headache!!! lol

  • Thanks, — :D I'll check it out...

  • CAPX: sugarsync.com/pf/D6025908_4317202_6992586

    === PLEASE SKIP DOWN BELOW TO THE UPDATE ===

    Starting at line 3 on the "ES Enemy" event sheet, I'm attempting to set up conditions that tell the Enemy instance to find the nearest PatrolNode within the NodeZone (so that it doesn't try to find a Node outside the proper patrol zone even if that other Node is closer) and then follow the patrol routes I've defined.

    The enemy will go through a series of statuses:

    1. Normal - within each NodeZone, follow the patrol routes setup by the PatrolNodes within that zone.

    2. Chase - the enemy will chase the player...

    3. Alert - the enemy will randomly search for the player within a range from the last point it saw the player.

    4. Resume - Return the the enemy's assign NodeZone and resume the patrol as defined by the Nodes in that zone.

    But at present all I can get to work is the chase, alert, and resume statuses. The enemy will not even select a Node to seek out. Can anyone see what I'm missing?

    ===========================================================

    UPDATE: Related issue but not quite the same as before.

    In the "ES Enemy" event sheet, line 12, I'm trying to pick those patrol nodes that are within a particular zone.

    The enemy and the nodes are assigned the zone's IID - it's "home base". This way, after a chase, it can return to its original patrol area and not just any patrol path.

    So, after a chase...

    • Pick all patrol nodes which have an HomeZone instance variable value equal to the HomeZone instance variable value of the enemy.

    -- From those patrol nodes that are picked, further pick the nearest one to the enemy.

    -- Find path.

    Everything works up to event line 12. But for some reason the enemy will not return to the node it's closest to within its own zone.

    Also check out the "ES Setup" event sheet, lines 4 and 5. That's where I assigned the IID of each patrol zone to the HomeZone variables.

  • Excal - That's a great idea! Make sure you submit it to Ashley in the suggestions forum.

    R0J0hound - On that note, I would THINK it ought to still act accordingly for each instance (without the For Each loop). If it works mostly as it should without the Trigger Once, then all Trigger Once should do is work once PER instance if true. It doesn't make sense to stop it altogether for all instances just because ONE instance meets the conditions.

  • — - Haven't used the Turret behavior yet, but yup, that would make perfect sense.

  • Bl4ckSh33p - Atually, before Ashley added the LOS behavior, that's exactly what I was doing. :) lol

  • Thank you, wizaerd and — :) I now feel legit. LOL

  • How would it work to add a debug feature that makes the field of vision cone for the LineOfSight behavior visible during preview mode or even during actual gameplay? This could really help me in fine-tuning how far and wide the cone is.

    Sound good? :)