BadMario's Forum Posts

  • Sounds like you could just make another copy of your loop and rename it then import into construct as a new file, so it will not look like an identical track ( It is, but construct doesn't know that if you rename it, does it? ).

    I just noticed you mention that at the end of your post. Anyway, doesn't seem like a big deal really unless files are huge and file size is of concern.

  • You are looking at it the wrong way. Use car behavior

    Then create a sprite ( just a simple colored rectangle ) with an instance variable called position ( or whatever ), copy it maybe 10 times and place around the track

    set instance variable of each sprite 0-10.

    Give your car instance var called position too. set it to 0

    Then use events to set angle of your car toward sprite with instance variable position that matches same named instance variable of the car which will be 0, and simulate car behavior accleration

    once it reaches that one add 1 to car's instance variable, so now the car will turn towards the sprite with position variable 1, and so on.

    That is the general idea, then tweak to make it nicer

  • It does make sense. Calculator and modulo here are different things. In other words 1000%50 in Construct is 0 because you can divide 1000 by 50 exactly ( 20 times ), nothing is left over.

    Calculsting a percentage is a completely different thing. Unfortunately the symbol is the same so I can see how it can be confusing.

    (1000*50)/100 is something you can use to get the right percentage ( 50 there would be percentage you want to calculate, 1000 is you max value, percentage of which you want to figure out.

  • don't use image points, just use offset from what would be mouse position

    With mouse player position is Mouse.X and Mouse.Y with Touch, set it to Touch.X + or - offset, same for Y position

  • What are you using to launch your projectiles?

    I have games with physics, always use independent frame rate setting and launching things with set velocity ( x and y ) produces consistent results. Tested on PCs, phones, different refresh rate monitor and with Construct 3s unlimited frame rate setting. Seems to work fine in all these tests.

    The only "trick" I use is to set linear damping to 0 then once a projectile hits something set it to 1 or whatever to slow it down gradually

    Give it a try

  • You do not have permission to view this post

  • You can have only 15 - 20 instances of the same object and a game that will slow to a crawl if these instances overlap each other.

    And it may happen when exporting using runtime 3 and/or webworkers, then works fine if exported without webworkers and/or using reuntime 2.

    Don't ask me why , but it is true. My workaround was to change the collision detection method and it worked fine.

  • You could also just open all your Construct 2 project in Construct 3 right now and save as Construct 3 files, just in case future versions break something. That way you have your original v2 files and v3 files just in case.

  • You can just specify if no key is down play idle and the rest is obvious I guess.

    You can have else if type of thing.

    Do your first action ( If key LEFT is down for example )

    Then add else below that, then add another condition in the same event ( If RIGHT is down )

    then finally add another else below that without any other conditions where you add play idle animation

  • You could probably run a for each square loop

    set global variable squarecount, then for each square if overlapping circle add 1 to that variable, so you should get exactly how many are overlapping.

    Don't forget to reset thev ariable to 0 before the loop, otherwise it will just keep adding up

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Don't physics ( if set to frame rate independent ) already use dt, as do all behaviors, so if you add your own dt that just messes with physics.

    And you really have no options other than using v-sync. The other ones are there just for testing ( to make sure game will run roughly the same on different monitors/systems.

    You have to export the final game using v-sync

  • When I say wipe out everything, I meant everything in the game folder, not my browser cache.

    Overwrites will happen only if there is exactly the same number of files and with same names

    I do this because Construct creates sprite sheets and gives them names without my input. It is possible that a different export will have more,fewer and/or differently named sprite sheets, so if your javascript files do not all update you get code pointing to a sprite sheet that is still there from the old version and a screen that makes no sense ( random sprites all over the place )

    So just to be safe, delete everything, then opload the new export

  • I've been wiping everything before uploading a new version. I guess because of the way sprite sheets are generated they may be different in different exports while retaining the same file name. In that case things will look messed up ( Code pointing to images on a sprite sheet that now in the new version does not contain those same images, or in the same order.

    So, I really don't see a solution, if you really want to be sure everything works, other than having them download everything again with each new export. This should make sure all sprite sheets are correct and they will not lose any data saved in local storage since they are not clearing their cache.

    Of course they still may have to refresh the page once in a while.

  • Global variable, call it score and set it to your score/number.

    Then have an event, when score= or greater than 3000 go to next level.

    Since score is global it will retain its value/stay the same

    • Post link icon

    I guess moving platforms are unfortunatelly a no go with jumpthrough platforms.

    My default speed is 60*dt, then speed up to 240^dt and it worked perfectly fine on my PC while developing and testing in Construct 2.

    Seems that Construct 3 has a problem with it. So, since it will be exported w Construct 3 I had to rework the mechanics and use solids.