calminthenight's Forum Posts

  • It's just a matter of having your OBS settings correctly configured and making sure your PC is capable of doing it without frame drops. Have an FPS counter running for your game while it is being recorded so you can see if it is getting throttled by the capture. If not, tweak the OBS settings until you get a smooth capture. Disabling the preview in OBS is a good start to get some fps back also.

    Make sure your capture is the same frame rate as your game or you will always get frame drops.

    TBH though your recording is acceptable already.

  • You might have more luck posting this in the plugin SDK thread: construct.net/en/forum/construct-3/plugin-sdk-10

    IF you do actually get lottes working please let me know! :) I've had it on the backburner to attempt to bring it to C3 but my glsl knowledge is not up to scratch.

    Best of luck to you

  • To add to lionz suggestion. 'Trigger Once' means, trigger once when these conditions become true, not trigger once only ever. If the conditions become false again (in your case object not touching) then it will trigger again the next time.

    Use lionz suggestion of a variable to keep track of if the trigger has been fired already.

    On object touched

    Is object Var_triggered=false

    Trigger Once - Set object Var_triggered to True

  • Do you want the house to change animation only if all the grass directly next to it is mowed?

  • export your project and have a look

  • dop2000 has a project link in this thread that works.

    construct.net/en/forum/construct-2/how-do-i-18/day-week-internet-152861

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • RGBex max value is 100.

  • Use rgba instead.

  • I think you are misunderstanding how the obstacle map regen works. Regenning the obstacle map a single time will work for all of the instances of the object with the pathfinding behaviour.

    Have a look at this quick example that demonstrates that. 1drv.ms/u/s!AkmrWgxeuxlKhJkNjxRTazHyU_pd3A

    If you want to make the regen more efficient you should only regenerate the obstacle map around the areas that have changed, not for each instance of an object with pathfinding. e.g. If you add a new obstacle at coordinates 100,100 then you only need to regen the obstacle map around those coordinates.

  • Looking at your .C3P file the issue is clearly what I mentioned before.

    When you're in the "all" mode, you are asking the creep object to regenerate the entire 1920,1080 area. Total pixels = 2,073,600.

    When you're in the "area" mode, you are asking all creep instances to regenerate a 256x256 area around themselves. Total pixels = 65,536,000.

    You can test this by changing both events to "pick random instance" you will notice no change in the "all" mode, as this is the same calculation, and the "area" mode will be significantly quicker (same as "all" mode), as it is only doing a single 256x256 regen.

    If you change the "area" mode event to use a "for each creep" loop. You will get the same result as the original events in "area" mode.

  • How big is your layout?

    Without testing it myself it looks like you might be regenerating your map of (possibly 1920x1080) once vs regenerating an area of 256x256 1000 times. The latter would be slower.

  • Every X Seconds is not a trigger event. Try using Every 0.5 call function "field change".

    Then put those events inside the function.

    Or use a timer that repeats every 0.5 seconds and use an "On Timer" Event.

  • I know it doesn't answer your specific question, because it does not use the EasyStar plugin. But here is an example of grid based pathfinding and movement using an Array.

    In the example enemy and player position is updated in the array. Multiple passes of the pathfinding function allow the future position of enemies to be stored and their current positions cleared to make room for other enemies.

    1drv.ms/u/s!AkmrWgxeuxlKhJkKoRmgtGecc7MfVw

    The logic should be able to be applied to other pathfinding implementations.

  • Ok. You need a way to store the tile that is going to be occupied by each unit that moves and check that against the other units when finding a path. I'm not familiar with EasyStar so I don't know if this is supposed to be built in or not.

    Normally I would flag the position to be moved to with a variable, or a change in tile state, then exclude that from being a valid path for find path events that follow.

    You would do this using loops. I will make a small example when I have more time to show the logic of it.

  • Both of your code sections are running every tick. Replace the "System mode=all and mode=area" conditions with triggers so that they only run once. A function would work well here.