Rhindon's Forum Posts

  • OH MY GOODNESS. I figured it out. I was setting the TargetY variable to Self.StarX and not Self.StartY.

    PROBLEM SOLVED.

  • VinniePin - That's a good question. I haven't touched the Collision Mesh; only the Collision Polygon in the image editor.

  • EDIT: I solved my own problem. It was an incorrect reference to an instance variable. (See my last comment below.)

    I'm working on a stealth-styled mini-game and, as expected, the Line Of Sight (LOS) behavior is employed.

    Instead of giving the behavior to the enemy guards (black circles with green+red eyes), I've given them to the red lines you see as in the screenshot below...

    Instead of projecting a single image to show the cone of the LOS field, I'm using individual lines that show how my character, Mr Spy (grey circle, green eyes) falls into that field of vision (the black and grey walls also work the same way).

    The polygon hitbox for Mr Spy is an 8-point "circle" for the sprite...however, even with that shape, the red lines clearly show a massive off-set of hit detection when using the LOS behavior raycasting and detection. Here's the setup at the Start Of Layout as well as the raycasting event lines:

    While this seems to work...it's obviously not working as I hoped. Some lines are going right through Mr Spy while others are acting like they're detecting raycast hit detection when they're (visually) not.

    Any idea why it's behaving this way? What am I missing?

  • — & DiegoM - As always, I'm grateful for your assistance. This time, however, I must apologize, too, because I rather sent you all on a wild goose chase when the answer was - apparently - not related to the Tween or my variables. I checked the image of the Quad_HUD object again and I realized I had a second animation that - despite playing quite clearly in the preview of the game - I had missed entirely when I resized the first animation.

    Since the second animation was still twice the size of the new resize, when the animations were changed, they appeared to be starting out larger or smaller than their target Tween value. So when it was to Tween to a larger size, it was switching animations and appearing initially larger and thus Tweening smaller. At any rate, I've tested all the main areas and things are working.

    The only "bug" was in my brain.

  • DiegoM - I'm inclined to agree completely. I have continued to scour my variable but it doesn't explain why it will start a Tween at a smaller value and then Tween to its larger end value or vise versa.

    For example, as you saw, if I'm moving to the top-left Quadrant (#1) the MAX height for that Quad should be 45. But it will start the Tween at a value much larger than 45 and Tween its height smaller. In other instances it will start smaller and Tween larger.

    In addition, I've taken all instance of the objects and clicked the "Make 1:1" button just to make sure there was no residual issue when I resized the image art, itself (I've noticed in the past that can sometimes cause problems).

    I'll keep looking things over and checking my variables and finish writing the bug issue if I can't find a resolution...

  • In the project window, look for the HUD_Elements Family to find the variables being referenced here.

    The event lines are on the "E Gameplay" event sheet and are at event lines 218-230.

    The only changes made were

    - to the instance variable values that I made in the parameters window and not through the event sheet.

    - to the position of the objects on their respective layers.

    - to the original size of the objects before manually resizing them in the layout to set them for their initial size once the game is run.

    No changes were made to the event sheet. And it's only happening to TWO of the Family objects (the top two yellow "Quadrant_HUD" Objects). Everything else is working fine after getting their instance variable values updated.

  • DiegoM - This is the issue I'm having...

    As I mentioned in my comment above, the strange thing is that this is an issue only for on particular object instance and not the others that all are included in a Family and following the same exact action instructions.

  • ...yeah, that's not getting me anywhere. I am afraid I have only kept a single of the project and I'm unable to open it in older versions of C3.

  • dop2000 - I will try, but I'm 99.999999999999% certain that it's not in my code. Since, as I mentioned, I changed absolutely nothing EXCEPT the object image sizes, the positions in the layout, and the instance variable values. That shouldn't break how the Tween behaves.

    The curious thing is, as I go about finishing the updates to the aforementioned details, all the other objects are working - it's literally only the Quad_HUD objects (the yellow squares in my mini-map) that are behaving like this.

    Off to test your suggestion...

  • With the recent update (beta 203.2), the bugs in the Tween behavior were supposed to have been fixed. Either there is still an unresolved issue that got overlooked or I'm dealing with a separate matter...

    I'm using Tween behavior to adjust elements of the HUD map system. Each element (Quadrant, Hallway, Boss room, and Sector) share the same exact instance variables per a Family.

    Depending on where in the environment the Player is, the elements of the HUD map Tween to their new size and position according to the values of their copies of the instance variables.

    So the map will look something like this when in action:

    When the Player moves from one area to the next, whichever area is occupied has its map counterpart expanded to its relative size of the actual area. The origin point of each HUD map element is in the top left. So, in the image above, the top-right Quadrant would Tween from its current position to a number of pixels to its left. At the same time, its size would expand at the same Tween rate that it moves. (Some objects, like the top-left Quadrant, would have the same X/Y values all the time or only part of the time depending on which area is accessed. And the same for the sizes, as well...some values will change while others will not.)

    This system was working perfectly prior to the recent update. Even after the apparent Tween behavior bug fix, the problem persists. However, the ONLY thing I changed recently has been the VALUES of the instance variables. Because I reduced size of EVERYTHING - layout, objects, etc - I had to update where the HUD elements appear on the HUD layer. I also had to update the X/Y and size values that the elements Tween to. That's it.

    The problem is that, when I Tween to certain areas, the size of the element will START at a value GREATER than it was at before the Tween. For example, if I'm moving from Quadrant 2 (top-right) to Quadrant 1 (top-left), the width will Tween to its correct size but its height will start out at more than double its original size prior to the Tween (and its height isn't even supposed to change!).

    The max size any element will reach is 45x45 pixels. The minimum is 15x15. But I'm seeing cases where the height and/or width starts out at as much as 90. In other cases I'm seeing where it will Tween from a smaller size to its target size when it shouldn't have changed sizes at all. As per my illustration above, moving left to right will keep the top two Quadrants the same height. But the Quardant 1 element will Tween from 15 pixels to 45. But I have quadruple checked the values for the instance variables to confirm that it shouldn't be Tweening to or from anything different.

    Here is the .c3p file: https://drive.google.com/file/d/11fTotgPQCiQDkq5UtETuYOpfyLBgkuI9/view?usp=sharing

    CONTROLS:

    - WASD to move

    - MOUSE to move the targeting reticule (make sure it's around the middle of the screen

    In the project window, look for the HUD_Elements Family to find the variables being referenced here.

    The event lines are on the "E Gameplay" event sheet and are at event lines 218-230.

  • That agrees with what I seem to have discovered, too... Except when I had removed the behavior from the individual objects alone. Maybe I missed one. Ah well. It's working now.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • UPDATE: I don't know what the issue was, but after going back to what I initially had with the objects in the Family, deleting all actions referring to the behaviors for the individual objects, and then also deleting the behaviors assigned to each object, AND THEN adding the same behaviors to the FAMILY...it all seems to work. I don't understand the conflict as I've been able to add the same behavior to an object AND to the Family the object is a part of and it just said "Behavior2" when I did that.

  • Ashley, are you and your team aware of this?

    I'm just not sure why this is an issue when I've been able to add behaviors to Families even when the individual objects, themselves, already had the same behavior.

  • Before I go and post this as a potential bug, I wanted to ask if anyone else has noticed the inability to add the Tween behavior to a Family of sprites.

    Initially, the individual sprites, themselves, had the Tween behavior. I know that you can add the same behavior to the Family and it'll be something like "Behavior2" because of the existing Behavior to the objects that make up the Family.

    But after adding these objects to their Family, I found that the Tween behavior wasn't in the list of options for the Family, itself. All other applicable behaviors were, however.

    I tried removing the Tween behavior from the individual objects of the Family, deleting this Family and then creating an entirely new Family with the same sprites I'm working with. Even with the Tween behavior not existing in the sprites with this new Family, I still could not add the Tween behavior to the Family, itself.

    Am I missing something or are others experiencing the same thing?

  • Yeah, I did that but I couldn't find how to retrieve that info when I hit F12.