Prominent's Forum Posts

  • Problem Description

    Text object set to global, changes layer when switching to another layout, when it should stay on the same layer.

    Attach a Capx

    [attachment=0:tbkygg21][/attachment:tbkygg21]

    Description of Capx

    Shows the text layer change in the debug when switching layout after hitting a key.

    Steps to Reproduce Bug

    • run debug
    • look at Text's layer property (should be set to "gui")
    • hit a key to change layout.
    • check text's layer property- it has changed. t

    Observed Result

    The text object changes layer.

    Expected Result

    The text object should remain on the same layer.

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (YES)
    • Internet Explorer: (YES)

    Operating System and Service Pack

    windows vista, sp 2

    Construct 2 Version ID

    r178

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Okay, I suppose that's understandable..

    The workaround that I went with was to use a separate object with the jump through behavior, and place it over the platform below and make it invisible- it adds an extra step to level designing, but it's workable at least. I prefer this solution over changing my character's collision box, since that might effect other situations related to that.

  • posted a capx here:

  • I just tried what you suggested, but that doesn't fix the issue. It still falls through the second platform.

  • Problem Description

    I use the jumpthrough behavior on a tilemap so that each tile can be fallen through. If I have two floors separated by one tile, and the character is taller than one tile, then it'll continue to fall through both platforms because it is waiting until the character isn't overlapping to reset the fallthrough.

    It should be designed to only take into account the bottom of the character collision box (the part touching), rather than the whole collision box. Also it should only take into account the top of the platform collision box (which could be different depending upon the orientation of the object).

    Attach a Capx

    [attachment=0:18l4hbkv][/attachment:18l4hbkv]

    Description of Capx

    Sprite with platform behavior and tilemap with jumpthrough behavior, setup so that bug occurs.

    Steps to Reproduce Bug

    • Press down arrow to fall through platform.

    Observed Result

    Sprite falls through two platforms.

    Expected Result

    Sprite should only fall through first platform.

    Affected Browsers

    • Chrome: (YES)
    • FireFox: (YES)
    • Internet Explorer: (YES)

    Operating System and Service Pack

    windows vista, sp2

    Construct 2 Version ID

    r178

  • That wouldn't fix the issue.

    I use the fallthrough behavior on a tilemap so that each tile can be fallen through. If I have two floors separated by one tile, and the character is taller than one floor, then it'll continue to fall through both because it is waiting until the character isn't overlapping to reset the fallthrough.

    So this is a bug with the fallthrough behavior in my opinion. You'd think it would have been designed to only take into account the bottom of the character, rather than the whole collision box.

    I guess I'll post this in the bugs..

  • When I fallthrough a platform, if the character is overlapping the platform while it hits another fallthrough platform, it continues to fall through that platform as well. How do I stop this so that the character only falls through the first platform?

  • The thing is, if you have 50 objects in a family, and say 25 of them use a behavior, it'd be much simpler/cleaner to

    do this:

    +Foreach Family1:

    -> Behavior action.

    or even:

    +Foreach Family1:

    +Instance has behavior (enables access to behavior's actions/conditions in sub-events)

    -> Behavior action.

    + Behavior condition

    ->behavior action.

    ...

    The reason it'd make it better is because if you need to add or remove objects to and from a family, you don't have to create all the extra events to do the same thing.

    Sure, you can put the ones with the same behavior into a family and give the family the behavior, but that would just complicate things and introduce bugs and make writing the events counter-intuitive.

    Try putting physics behavior on an object, and then put that object in a family where the family has a physics behavior and you'll see it get messed up and not work because the behaviors clash with each other.

  • That's why I said inadvertently. That would be a very frustrating class of bug.

    Perhaps, but there's always going to be possibilities for human error with everything.

    One way to help confusion is to highlight the event with a color where behaviors may not be active. So it would check all objects in a family and if you reference a behavior that isn't attached to all members, it would get highlighted red as a warning that the event may not fire,etc..

    So a kind of, use at your own risk, sort of thing.

  • I can see issues with this. How would you know if you were inadvertently accessing a behaviour that didn't exist?

    Like I said, it would simply ignore it. Nothing would happen if it doesn't exist. You should know how your program works, so running into this issue wouldn't be an issue if you're aware of what things should be doing.

    vee41, that workaround is exactly the type of thing Families should be preventing.

    That is the type of workaround I'm using, but I have to use it so many times that it is becoming a bit ridiculous when this could be prevented and made much cleaner.

  • What I would want, or what I think would suffice:

    Families collect all behaviors from each object in the family, and provides access to these behaviors in the event sheets, but if the behavior is used, and the instance doesn't have that behavior, then that it is ignored.

    Seems like a simple thing to implement?

  • Okay.

    Well, families group objects together.

    Objects in a family can have different behaviors from each other.

    Referencing a group allows you to use less events to pick out objects (saves you from having to create events for each object).

    When you pick out an object this way and need to perform actions based upon their behavior, then you simply can't do it without extraneous steps that make the events crowded and difficult to change later.

    Doing this defeats the whole point of Families.

  • I keep running into the need to access the instance's behavior that has been picked from within a family. I only have access to the family behaviors.

    Don't respond with questions as to why I would need this and effectively change focus of the question. If this is simply not possible, then it should be something to consider implementing.

    Thanks.

  • Just beat the game. I enjoyed it, it is a clever concept and executed very well. I sure you could take it further if you wanted

  • Nice work! I managed to beat all 5 levels. I assume that's all the levels since it wouldn't let me continue past that point. I enjoyed the music, and the graphics were nicely done.