calminthenight's Forum Posts

  • In the editor set the bullet behaviour to enabled then change our events to this.

    You should set the speed at the start of each shot, and return it to zero when it lands back in the cannon. You don't need to enable or disable the bullet behaviour every time you fire or it lands, but you could still do that if you want.

  • You shouldn't need the wait 0 in this scenario.

    Is your event order the same as below, and it does not work without the wait 0 action?

  • The for each loop and check against the array UID would work, the only problem is that it would execute more than one time as the actions would happen "for each" key on every door collision trigger. This was why more keys were getting used. Removing the loop and using pick means that only one key is used per door.

  • I redid your events in a group called simplified. Have a look here: 1drv.ms/u/s!AkmrWgxeuxlKhItm6Td4wPJp_rc_Kw

    There were a few things that were causing the issues. You needed to pick the key based on the UID stored in the array, not just compare it. You also were popping and pushing from the same end of the array meaning you weren't getting the first in first out behaviour you were after, and you had some unnecessary variables and events including your for each loop which was causing some issues.

  • If you need them to have specific values you can set them directly after the action that creates them

  • It doesn't need to be global. Just use the 'load object images action' for the sprite that you need prior to the time that you are going to switch to it.

  • Is there anything that would prevent the crt-lottes.glsl shader from being able to be converted to a C3 effect?

    github.com/libretro/glsl-shaders/blob/master/crt/shaders/crt-lottes.glsl

    It's such an excellent shader. I'd love to see it make it's way to C3.

    Tagged:

  • If you used separate sprites you could just load the next image into memory before it is actually needed and then when you switch to it there shouldn't be any lag.

    Have a trigger that happens when the player is almost about to transfer into the new level, and load the image into memory then. Then replace the image when you usually would.

    Or alternatively you could use a transition to hide anything going on in the background, like a fade to black with the new level name or something to cover up the change.

  • Just to get a better picture, you say only one is shown per level, do your levels all take place within the same layout?

  • I'd focus on the other aspects first and then when they are working correctly, rethink the recoil.

    You want the recoil events to happen after the aim/destroy events so that it does not interfere with the user's aim. I would suggest using Tweens to ensure your values return to what you want them too. Unless you use lerp in a specific way the values will not return to zero. The main thing though is that you don't want those recoil events happening on every tick.

    You could have a boolean instance variable called "recoil" and set it to true after the aim/destroy actions. Then use that state to trigger the tweens for your recoil. When the tween that returns the value to the original number then you can set the recoil boolean to false.

  • I used an overlap check with a buffer sprite to help you visualise what is happening but you can replace the use of the buffer sprite with a simple distance check which will be more efficient.

    Instead of "Spawner is overlapping buffer" use:

    distance(Spawner.X,Spawner.Y,Player.X,Player.Y)<whateverdistanceyouwant

    and

    Instead of "Spawner is not overlapping buffer" use:

    distance(Spawner.X,Spawner.Y,Player.X,Player.Y)>=whateverdistanceyouwant

  • Removing the ammunition check and disabling your recoil events makes it work perfectly. In some cases the ammunition variable is being changed prior to the trigger event that handles the destruction of the object. The recoil is affecting the aim as it is not working the way you intended. If you watch the debugger you will see it constantly changing values.

    It would be better to restructure your events so that all events that happen on the trigger (right shoulder pressed) are sub events of that condition. This way you will have more oversight and control of the order of execution.

    Currently you have two separate (right shoulder pressed) events which can cause the issue you are experiencing because the actions in each separate event are related.

  • Have a look at this example. Very simple. There are other ways you could do it as well.

    1drv.ms/u/s!AkmrWgxeuxlKhItkIM5o4JNYt0u0rQ

  • Ah apologies I didn't see the C2 note. gtanix this is the C3 forum. Try posting in the C2 forum for C2 help.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Lots of ways you could do it, but if it is a "scene" like an animation, I would use timelines. editor.construct.net

    editor.construct.net

    construct.net/en/make-games/manuals/construct-3/project-primitives/timelines/timeline

    Some other ways are discussed in this thread: construct.net/en/forum/construct-3/how-do-i-8/sprite-move-along-path-154504