oosyrag's Forum Posts

  • Note that CORS needs to be enabled on the web server that the audio is hosted on if your game and audio file are not on the same domain. Otherwise you will not be able to access the audio file.

  • Try adding a Wait 0.1 seconds before your save.

    Music is streamed, it doesn't immediately start playing. Since you do both on start of layout, basically you're saving the game state before the music has started. Since start of layout doesn't trigger on loading, it wouldn't start playing the music after loading either.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • In a loop like for each, every time it repeats, loopindex goes up by 1. So the first time it runs, loopindex is 0. The second time it will be 1, and then 2, ect.

    So if your loop runs 10 times in a for each, because you have 10 instances, loopindex will be 0-9, in order. And because we used an ordered for each, the order can be set by another variable, like speed.

  • First off, my condolences for your 13,000 events and resolve to attempt this feat. If you were familiar with the math, you might have realized that there are 3,628,800 possible combinations of 10 positions. So you're lucky in that you seem to have hit a limitation so early...

    To determine turn order for 10 objects, the simplest way would be to use instance variables. If you had an instance variable for speed, and an instance variable for turn order, you could use the system "For Each (ordered)" to sort them by speed, and then assign each one a number from 0 to 9. 

    + System: For each Sprite order by Sprite.speed descending
-> Sprite: Set turnorder to LoopIndex

    What you would do now that they can be identified by their turn order is up to you. For example, you could keep track of the current turn in a separate global variable, and only allow the sprite with turnorder that matches the current turn to act.

  • Your other post also doesn't have enough relevant information to give you an answer.

    Instead of pictures, if you could recreate the problem in a minimal project and upload that it would be much easier to help you.

  • You're going to want to give more details if you want an answer, because it sure isn't reproducible from just your title.

  • Have you tried the clear storage action in localstorage?

  • construct.net/en/make-games/manuals/construct-3/behavior-reference/solid

    Tags

    An optional list of tags to apply to the Solid, separated by spaces. This is referenced by the Set solid collision filter action, allowing collisions to be enabled and disabled with different sets of solids.

  • Position it at the center of your viewport. Which is at 1800, 1800.

  • Basically your HUD elements need to be in the top left of your layout, not the center. Because there is 0 parallax on your HUD layer, that layer won't scroll to where your player is, which is where you've placed your HUD element.

  • I've never tried nested groups. I imagine a quick test shouldn't be too hard.

  • For your specific question, you could do it exactly as you described.

    When moving, disable solid, and when stopped, enable solids. In addition, whenever moving objects becomes solid, regenerate the pathfinding map and find a new path for everything still moving. This is probably going to cause new problems though...

    There is unfortunately no easy answer to this, it's a pretty classic problem.

    The first step solution is to ignore collisions and overlap between moving units until they reach their destination. This is usually sufficient to prevent pathfinding from becoming a detriment to your game. striketactics.net/tags/pathfinding

    You can read about the history of pathfinding in popular games here, as well as their solutions and how they were done. sandruski.github.io/RTS-Group-Movement

    Modern RTS's generally use flocking/swarming/steering movement algorithms in addition to pathfinding. gamedevelopment.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732

  • I'm using a single layout and a single event sheet for this as I thought things like reconnecting might be easier with a single event sheet. I use groups that I enable or disable to change the state of the game like signalling, hosting, character creation etc. .

    Multiple layouts does not play well with syncing. It can be managed (I think), if you're really really familiar with the concepts of how objects are created and destroyed from layouts and syncing and you have a good understanding of the information that gets passed between clients. Basically I wouldn't recommend using layouts in a multiplayer unless you really know what you're doing, and if your game really needs it (running into vram limitations for any given layout).

    But now I'm wondering if I should instead use different event sheets for the different states. Like one for the connection, then if connected go to the lobby layout (and event sheet) and then if the game is started to a different one.

    Event sheets are for your own (developer) sanity only. It doesn't make a difference to the user or the engine if you use a single event sheet or separate your sheets. Do whatever makes the most sense for yourself organizationally. Separate layouts for connecting and gameplay I feel is a personal preference as well, it doesn't really matter besides the previously mentioned headache of changing layouts with synced objects.

    Also I wonder if it is better to have a group for being the host and one for being the peer (like in the multiplayer tutorial) or instead simply check "is host"...Do This..."else"...Do That... .

    I definitely use groups. Unless you don't like using groups for some reason. Similar idea to event sheets. If you're going to be putting is host/else all over the place, why not just use groups? The people swimming in the pool will never know if you used a hose or a bucket to fill the pool, but why would you use a bucket if you had a hose?

    How do you do it? What do you think is more efficient while developing and performance wise?

    Nothing in here has anything to do with noticeable performance. As always for performance, if you can't find a way measure it yourself, it's probably not worrying about.

    As far as development efficiency is concerned, do whatever is most comfortable for you. But do remember that things like groups and event sheets are there as tools to help you stay organized. They only work if they make sense to you though, no point using them if they only make things more complicated for yourself.

  • It would help if you posted a project file.

    Is the layer visibility set? Are the layers in the correct order? Are you creating hud elements on the right layer?

    One more thing to try is unlinking your event sheet from the layout and seeing if your hud is visible.

  • I believe the example I posted should work with any size/ratio tile. Just change the size of the sprite object for the tile. Let me know if it breaks and I'll take a look again.