Rhindon's Forum Posts

  • You do not have permission to view this post

  • LOL That should have been so obvious to me by now. I'll test it on my end in the morning. Thank you!

  • It's hard to describe the issue so briefly in the subject line...

    Basically, the Pathfinding behavior of the Virus_DoorsAttk object (the attack type for the Virus_DoorsDef object) for some odd reason seeks out the lower-right corner SectorDefense object regardless of the starting point of the Virus_DoorsAttk. The origin point of the SectorDefense object is dead-center and the bounding box is uniform (octagon shape). The Pathfinding cell size is 5 while the SectorDefense object is 60x60. Even with no other objects in the way, the Virus_DoorsAttk object seeks the lower-right corner.

    The event lines in question start at line 153 (group "Blue Attack").

    Here is the .c3p: https://drive.google.com/open?id=1O4DTsJaHk33fSkghFSRU0gbQYxAScIC_

    Can anyone see why this is happening?

  • dop2000 - While waiting for a reply I continued to do some more digging and re-discovered exactly what you just said. So everything is working perfectly now. Thank you, though!

    However, I did not know about the Set Color action within the sprite, itself! Not sure how I ever missed that!

  • I'm trying to set an object to change its color after a random period of time. After such time, it changes to a randomly selected color (yellow, green, blue, or red). I'm using 3 variables on the object and then plugging those variables into an action that determines the values of the Set Color effect. Initially, all values are 0. After that, the only color I'm getting is red even though I've confirmed that the randomly selected color variable and the other color variables are all working just fine. It's the actual Set Color effect that's not registering.

    In the event line where I use the Set Color effect parameters, I have three separate actions for each color parameter of the effect - 0: red, 1: green, and 2: blue - and plug in each of the object's color-related variables to set the effect value. But, as mentioned, the only result I'm getting is RED. Am I doing something wrong when setting the values of the Set Color parameters?

  • Beautiful! Thank you, Ashley!

  • Aaaah! That makes sense. I've checked and rechecked the documentation many times before to see if I wasn't misunderstanding that...

    Is it possible to update the documentation to make this detail clearer? It's always been my understanding that the evaluations all took place in the text box and the operators were essentially use-as-everything-else (if that makes any sense).

    Anyway, I get it now. Thank you both!

  • Oh okay. So, in the text box I would type...

    "text1" | var = "text2"

    .... Correct?

  • I want to use the | logical operator symbol when testing the value of a string instance variable.

    If var = "text1" | "text2"

    However, when I try this, the expected outcome doesn't work.

    I checked the documentation page and it doesn't explicitly state that you cannot use string values but only references numbers.

    Am I correct that | only checks for numerical values and not string? Or is there something else I'm doing wrong?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Those uppity triggers, man. You'd think they'd play by the rules. :P

    I think I'll try to adopt your rule about triggers, myself, just to save on future issues.

  • A simple-enough update. Not a problem, and thank you! :)

    Though, I don't see how my logic is off, per se, given that Else conditions - so I thought - only worked in relationship to the previous event condition of the same level. So long as event line 6 was true, Else gets ignored entirely, regardless of what happens later in the sub-events following line 6. But if that's not the case - or if a trigger alters that - then Else events are, to my thinking, not so clear as they should be.

  • I'm working on setting up a custom pause feature built around tracking current and past dt values. This why I will have an easier time - I believe - at controlling what I want paused and what I want to continue to function. (I am aware that there is a way to manipulate the individual timescales of objects, but I seem to remember a long time ago that this did not serve my purposes...it's a bit beside the point at the moment, I think.)

    The issue I'm having right now is that the Else condition event line seems to be activating even when the boolean test condition above it is true. What should be happening is that event line 6 tests if the condition is true. If it's true, it skips event line 8. If event line 6 is false, it skips to event line 8 and runs the Else-condition actions. It's one OR the other.

    But because of the sub-event at event line 7, the sudden change of the boolean value seems to prematurely trigger the Else condition into thinking that event line 6 was false after all. Because the Else checks for the true or false outcome of the conditions laid out in the previous parent event line I would THINK that the change in the value of the boolean in a sub-event wouldn't matter.

    Am I missing something?

  • If you need to check if any of the picked doors have the same LayerDepthLevel as in Spy, you need to rewrite this condition:

    Doors compare variable LayerDepthLevel=Spy.LayerDepthLevel

    It really was that simple. Thank you for enduring my long post, though. I appreciate your time a great deal.

  • Ya know, that has ran across my mind but I hadn't checked for it. I'll try that later on lunch break... Go figure that that will likely be all that needs to be done.

  • Bear with me, please...I'm going to try to articulate the set-up and the problem in as clear and brief a way as I can...but I sometimes struggle to do both.

    PREMISE:

    My game, "Mr Spy", is set in a 2D platformer environment where Mr Spy (hereafter, "Spy") must move stealthily through an office environment to complete his mission. The game is inspired by the classic arcade game, "Elevator Action". However, I'm taking the use of the multiple doors in the original game to a whole other level by making it to where you can enter the doors and explore additional hallways and office rooms.

    SET UP:

    The game levels will be comprised of three sections:

    1. The main hallway which is almost completely unobstructed from end to end...not unlike your traditional platformer like the Super Mario Bros. series. The Main serves as a kind of "hub" for all other rooms and hallways connected to it via the doors.

    2. Backrooms or parallel hallways. *

    3. Front rooms or parallel hallways. *

    * The back and front rooms (or hallways) all run parallel to the main hallway. Entering a door will take you to the front or back areas depending on which door you enter. The layers I have - besides being set up for background and foreground objects and such - are situated to so that layers in the front or back of the main hallway serve as the back or front rooms (...or hallways...you get the idea).

    From the image above, you can see how I've grouped all my layers together to essentially act as slices of theoretical "group layers". The main "group layer" has two layers for the doors that lead to the back and to the front group layers (which amount to the front and back rooms). Each of these grouped layers I've assigned a "LayerDepthLevel" - 0: back, 1: main, and 2: front. The main, of course, has two doors that lead away from it. Spy also has a LayerDepthLevel variable assigned to him, as well. This is to identify that Spy is in the same layer group as the door he is trying to use. That way, if Spy is overlapping a door in the front group layer but he's all the way in the back, he can't use that door. Each Door is also assigned a "MoveSpyToThisLayer" variable so that, when conditions are right, each door assigns to Spy which layer he's supposed to be moved to. (This assignment of values is set up at the Start Of Layout and is tested by which layer the Doors are on to begin with. I try to set things up so that I have to do as little manual work as possible given that there will be tons of doors throughout the game.)

    I have four types of doors grouped together in a Family (Doors) - they all act essentially the same but are specifically created for each layer they are found on. But this is where the problem begins...

    PROBLEM:

    When moving between layers - from front to main or main to back or vise versa - there will be two doors that overlap each other. These two doors are separate objects that, as described above, serve the same function. I want to make it so that when overlapping these two doors, they both open as if they were one door (because it would look weird if one door animated opening but the other door remained closed when peeking through the first door). However, only the door that is on the same LayerDepthLevel should be referenced when deciding how Spy should move from one layer (and LayerDepthLevel) to the target layer.

    This is my current event sheet...

    I'll try to explain what's going on per event line #...

    70 - Check if Spy is overlapping any of the four door objects (as found on the four layers designated for the doors)

    71 - Determine if the doors being overlapped share the same LayerDepthLevel values. Meaning, while the doors and Spy may be on different actual layers, are they part of the same layer group? If yes, proceed... (The OverlappingDoorActive boolean is for another feature and not relevant here.)

    72 - If the DoorInUse value is false, meaning that Spy (nor any enemies) are not using the door and that the door is done with its open/close animation, when the player presses A make it so Spy cannot move (he's about to "walk through" a door, after all), set the DoorInUse boolean to true so that the door cannot be used by any other characters and that repeatedly pressing A cannot prematurely trigger any other action, and set the Door animation to "Opening". (The ActionAvailable boolean is not relevant here.)

    NOTE: There are two door objects in question when moving to and from a back layer group and main, and to and from a main layer group and front. The best way to understand this is with this sketch I did...

    Each door pair is what links the front to the main and the main to the back layer groups. This is important to understand for the next set of event lines.

    73 - Pick the Door that has the same LayerDepthLevel value as Spy and check for when that Door has the animation frame value of 9 (halfway through the animation). Move Spy to the destination layer that Spy should be on when moving through that Door (and update Spy's new LayerDepthLevel value accordingly). However, there are two Doors still being overlapped at this point which is why it is necessary to use a Pick By Comparison at this point.

    74 - For another feature, thus irrelevant.

    75 - Once the Doors have finished their animations, set them to useable again and update their animation.

    HOPEFULLY, that extensive breakdown sets all things clearly as to what is SUPPOSED to happen. The problem is that when the two doors are overlapping each other, the intended action of the door opening, Spy going to his target layer (and all values updating), and the doors closing to be used again does not actually work. When I have the doors NOT overlapping, Spy can go through a door, end up on the correct layer with the correct variable values, and then use the OTHER door to return back to his originally starting layer and everything works. It is only when the two doors (acting as one as I intend them to) are overlapping does NONE of this work.

    For some reason, I suspect, the issue is that event line 71, but I cannot figure out what's the actual deal and why it's not working.

    Can I get some expert insight, please, to help me figure this out? Thank you!

    (EDIT: I don't know why my last image appeared rotated like that... Mentally rotate 90* counter-clockwise to see it correctly.)