oosyrag's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • What is the size of your tile?

    Edit: Never mind, here is an example with any size tile. It's a little messier to read though.

    dropbox.com/s/452gu6gpqbbi4ka/isoexample.c3p

    Some additional tweaks in this particular example include centering the origin tile 0,0 by ORIGINOFFSET, which is viewportwidth/2, and offsetting the mouse screen coordinate input by tile.height/2 to center the highlight, since the origin point of each tile is currently at the top of the tile instead of the center.

    Basically it's still "Get the nearest isometric tile coordinate from the mouse location, and set the object position to the screen coordinates corresponding to the tile coordinates".

    The main difference from orthographic projection is that any given x or y isometric position requires both an x and y input to get, while in an orthographic system you would only need an x input to map to an x coordinate, and y input for y coordinate.

  • Do you have an isometric grid already set up? Not all isometric grids are created at the same size/angle, so the exact way to do it would depend on what you've got.

    I'd assume any isometric grid set up already has a way to translate screen coordinates to grid locations, which means you should have a way to get/snap to the nearest grid. Then you would just set the position of the object to the nearest grid coordinate every tick instead of the mouse coordinate.

  • Moving up (up to 45 degree) diagonal slopes should work fine by default. Are your tile collision boxes set properly?

    Otherwise try using an invisible helper sprite set to solid and set it to 45 degrees aligned with the slope.

  • Edit: A triggered event cannot be a sub event.