lionz's Forum Posts

  • The order of layers is done in the layers bar to the right. The z order bar can used to change the hierarchy of objects within the given layer. I don't think the order of layers in the z order matters or has any effect, not sure you mentioned a problem? Are the objects doing something you don't expect?

  • lionz

    From the manual,

    If a trigger is in a sub-event, all of its parent event's conditions must be true at the time the trigger fires, otherwise the event will not run.

    I do remember seeing a post mentioning that triggers should be kept at the top level. However, based on testing and the current manual, I don't think moving the trigger to the top level is necessarily the best solution in this case.

    And yes, filtering/picking first can work better when you're dealing with two different object types rather than instances of the same object type, so that may have been what was happening in your case.

    my point is more that it should just work in its simplest form and it doesn't in this project.

    I have had no problems with sprite + var set on collision with fam then apply actions to the fam in my own projects. So my point is that there must be a fix to have it working with the collision event at the top level not in a sub event but for this project I haven't found that fix even when I chopped down the events to less than 20.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • lionz My solution works because it picks the instance before the collision trigger is evaluated.

    I'm pretty sure On collision is unordered in C2/C3. Because of that, having On collision and EnemyState = ENEMY_STATE_KICKED in the same event doesn't guarantee the picked Enemy is the kicked one. If Construct happens to pick the other instance for that collision pair, the condition fails.

    It should narrow the picked instances of hitbox to only the ones with that variable set or that's how it used to be and it used to be suggested that trigger events should be used at the top level so adding conditions like that under 'on collision' would be the only way to narrow the pool. I understand what you mean but in the past I never had a problem filtering in that way, it acted like an if hitbox collides with enemy and the variable is set then run the event, as in both the things have to be true for it to trigger.

  • By default it should be saving the value if you set them to global variables. When you go between layouts or levels and such the value should be kept. If you want to reset you can use reset global variables action when you hit 'new game' button or however you restart in your game.

  • Here is the chopped down version where the issue still happens. I spent some time on it but can't figure out why unless it is a conflict with family/container. The overlap check does fix it because it runs more often but I would still expect the on collision event to run for each collision.

    dropbox.com/scl/fi/rkv2qtwbs8162mzaio2bj/koopamodified.c3p

  • I trimmed down your project to 15 events and the bug was still happening. For the KoopaHitBox on collision with Enemies I changed it to KoopaHitBox is state 9 and overlapping Enemies and it was fixed. There might be an issue with the on collision event and it being in the same family, which is strange as this method is used to solve collision problems between same object types.

  • is Enemies action a plugin ? you might not be picking any specific Enemy in there unless it works like a function with copy picked. For this one you probably have to share the project.

  • Local storage or save game is how you would do this if you exit the game to restore it on game launch. Since you are talking about within the same game session you can store the data as global variables, they'll keep their value when you go between layouts. Another way is to store all the data in an array object (table) and read from it. When you lose all lives you can run the reset global variables action.

  • Yes that is a standard way of doing this in Construct. It shouldn't affect the performance if it is an empty sprite with no images.

  • I had an issue for a while with setting the cursor from sprite, only to discover that it seems a prerequisite is to first create the sprite in a layout and also that the sprite must remain in the layout and destroying it stops this action from working. It would be good to mention this in the manual as I don't think it is mentioned there.

    Tagged:

  • You do not have permission to view this post

  • I can see the issue why it won't turn, you need an Else. When you set direction to 0 the condition below becomes true and it sets it back to 1. It is a common problem that crops up because the user thinks of it as an if/else but Construct actually runs the first condition then the second one because it became true from the first one, adding the Else direction=0 instead means it becomes a true if/else statement when triggered.

  • What you've described should work in theory so it must be a problem with event structure and picking. When an 'enemy' collides with 'family' then in actions you can apply to each individually with enemy actions and family actions to alter variables or make them swap directions and such. Try to keep as simple as possible at first and see if it works because other events can also interfere.

  • For the dialogue can do with instance variable on the npc, so default is 0 - player presses chat button then if var= 0 show text '1', when you next press the button increase the variable by 1, if var=1 then show text '2' etc under that particular npc.

    To stop the player from moving, when you start to chat you can set a global variable to 1 that was 0 before by default. Then under your player movement events add a condition if that var=0, so when it is 1 you cannot move. After chat has finished, set that global variable back to 0.

  • I kept my response above simple and related to picking only so as to not confuse. But yeah the usual for a platformer I think would be an overlap check, player is overlapping block, and if they can overlap multiple you can use this with 'pick nearest block to player', rather than a for each with system condition comparing distance which won't work well.