Rhindon's Forum Posts

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

  • Arima - LOL I guess so, but I'm still very much a newb. And I'm already going towards my fourth month of struggling with my enemy AI behavior.

  • The title says it all.

    I could really go for a feature in Path Finding that plots the shortest path to an object instance.

    Similar to Pick Nearest Instance, but takes into account that the "nearest" object might be on the other side of a wall that will take many more steps to get to. So it'll calculate the "nearest" instance according to which instance has the shortest path to travel along to reach it. Because the shortest distance isn't always a straight line... :)

  • Arima - Thanks for the clarification. If it's that simple, I think I can manage. May I call on you for help if I hit a snag?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ashley - Right. I do remember that, too, and I've been using For Each sparingly since I came across more information. But I'm still struggling to grasp WHEN For Each is necessary.

  • newt - Thanks for the reminder about Families. :) I do recall that point. I guess I need to review it some more. LOL

  • I'm aware the "For Each" tutorial by Arima (a great help!) and I've reviewed a few tutorials and the manual for "Families".

    I'm not sure if this goes in the "How Do I...?" forum, for it's not quite a request on how to do something. I just need info and clarification.

    I'm wondering if someone can give me a run-down on when I ought to use "For Each" with Families. It's my understanding that Families has a kind of For Each build into it. But that doesn't seem to be the case in certain instances.

    The "behind the scenes" inner-workings of "For Each" and Families is something I don't know a lot about, so it's hard to see when I need to add "For Each" as part of the event conditions and when I can let a Families condition stand on its own.

    Thanks, everyone!

  • Paradox - Aaah, okay. I encountered that, too, and so I set the rotation speed to something up in the hundreds. LOL

  • Okay, run a scenario by me again? What's going on?

    I'm not sure I'm completely following the hang-up in Path Finding...

  • So, in the layout, you want C2 to highlight all objects in a container with a different highlight container?

    Say, object1, object2, and object3 are all in the same container, and you click on object1, objects 2 and 3 would also become highlighted, but with a different color? Is that what you mean?

    If so, I do like this idea.

  • When you get a chance, could you make it an option to toggle the debug window to the SIDE of the browser in addition to its initial nestled point lengthwise at the bottom? :) Thanks. And AMAZING update with r141!!! WOW!