99Instances2Go's Forum Posts

  • Using Platform behaviour.

    Set its Default Control property to No.

    Use the Simulate Control action to script only the movements that you want. Need to add Keyboard plugin to the project.

  • With a tilemap based pathfinder ? I dont see it.

  • The new install method is not very nice. I keep a stable version and a beta version. The beta version has a lot more of plugins installed. It is a hassle to maintain.

  • Tiled in 2 different angles for you.

    https://www.dropbox.com/s/v5wyyaoojff0u ... .capx?dl=0

  • The 'curves' depend on the 'turn speed'. But they will stay a bit 'absolute'.

    You can of-course code your own Dijkstra algorithm, or use a flood fill.

    But in the end, that is what the plugins do, but optimised.

    You can try (i never tried that) use a like 100 pixels grid. And scale the layer. Its easyer for a path to make a turn round a 100 pixel corner then round a 8 pixel corner, thats what you do.

    I am always this stupid to dive into this things, but i got this urge to tell YOU about things YOU ask.

  • I did't realise that you grid is this tight.

    Got to loosen the grid some, and then path finding with the official plug in is possible.

    https://www.dropbox.com/s/1gxmepuzkvsv9 ... .capx?dl=0

    To my knowledge, however, it is not possible to force it to find a path each short period of time, in such a tight grid. The curvy paths will force the moving object into as obstacles marked cells. And from there it will not be able to find a new path.

    You going to have more luck with:

    roguelike-plugin-c2-rot-js-interface_t118452

    or

    behavior-easystar-js-pathfinding-for-tilemap_t129056

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Definitions are just between you and me, so we both know what we talk about. Else i make a big mess of it all.

    Yes a cell size of 8 and a -1 border, with a big tilemap, is CPU intense.

    You do realise that this is a new question eh ? The thing is, you wanted obstacle cells that exactly represent your solids tilemap. You dont want unwanted cells marked as obstacles. I think i answered that question for you.

    Personally, i dont see any use in this. Because, see. The origin of an object moves over the found path, the pathfinder is totally dumb about the size of that object. Since it only keeps the origin on path, it will drive objects into the solids. The origin will always keep out the solids, ofcours.

    Now there are many kinda-sorta solutions on the forum to deal with badly calculated paths due badly set cell-size and border-size. Me myself has tried and experimented a lot. And the only thing that helped me out, is to calculate good paths.

    A good path is a path that stays half the size of the objects away from the solids. Or. The collisions cells have cells marked as obstacle around the solids. The opposite of what you wanted.

    Or in you case: cell size = tile size of the tilemap holding the solids. Border size = half the size of the moving sprite , and to be experimented. (no other choice) Check the cells by making the cells visible in a obstacle tilemap. If it does not find a path, you need to change the solids.

    Again, if you look at my 'blah example', did you see that you have to WAIT 1 tick. The obstacle cells are READY the NEXT tick. Even when starting up the game.

    Additional. There is a difference between the graphical representation of a wall and the way/form/whatever it should act as an obstacle. You better have 1 tilemap for graphical representation and 1 tilemap + solid sprites (all invisible) to mark obstacles. Because, see, someone/thing got to do all the work, YOU or the players (victims) PC.

    I am not harsh, i just type that way in bad english.

  • Ah yes there is. Its like a car. When standing still, you can turn that steer wheel as much as you want, the car is not changing direction.

    You can not change the angle of movement for a bullet that has speed zero. Since that angle was zero, the moment you give it speed, it starts from that angle.

    Now, i am not sure about this statement (i should check that): the bullet gets its speed at the end of the tick, so, changing angle immediately after giving it speed is not gonna help.

  • Hello 99 and thank you for your response, so, the solution is doing the tilemap of the obstacles half size of the tileset of the level? so being 16 the prop tileset the collision would be 8, isn't that not optimal?

    Definitions:

    'solids' = well solid, if you have obstacles in the pathfinding set to solids

    'solids tilemap' = iffen you use a tilemap to represent the solids as obstacles

    'obstacle cells' = 2 dimensional array used internal by pathfinding to store a value to represent an obstacle or a free place, based on the solids

    'obstacle tilemap' = a tile map i use to represent the 'obstacle cells' in a visual way

    Answer to the question:

    If you gonna use half tiles in the 'solids tilemap', then the pathfinder cell size should be half the tile size (in the 'solids tilemap') . With a cell border of -1.

    If you want to make the 'obstacle cells' visible, us a 'obstacle tilemap' with tile size = cell size.

    The relation between cell size and tile size is strict.

    The 'obstacle cells' are ready the NEXT tick.

  • I am attempting to make A.I. for the enemies in my game. The enemies have line of sight and platform behaviours. I need to know if there is a way to test if they are moving left or right. I thought that there would be a test for X vector in platform conditions but I didn't see it. Please help because I can't really progress with their A.I. until I figure this out.

    The expression 'Sprite.Platform.VectorX' gives you what you look for.

    To use it in a condition.

    Pick the Enemy (anyhow anyway)

    System > Compare two values ... first = Enemy.Platform.VectorX ...... comparisation = < ...... second = 0

    .............actions run if it goes left

    Else

    System > Compare two values ... first = Enemy.Platform.VectorX ...... comparisation = > ....... second = 0

    .............actions run if it goes right

    Else

    .............actions run if it goes not right and not left

  • Do you understand the strict relation between cell size & grid when showed this way ?

    https://www.dropbox.com/s/486uuo5bd3j9j ... .capx?dl=0

  • Fixed ?

    https://www.dropbox.com/s/h4asvgiry5zt3 ... .capx?dl=0

    Although there is no 'punch' animation in it.

    Besides that.

    My heart cringes when i see how so many people mess up the animations by cropping the transparent edges in each frame.

    As a result each frame has a different size. And the relative position of the pixels of the graphic content towards the origin is dancing in each frame.

    As a result, a helper object, just to move the animated sprite, is mandatory, even in a simple project.

    I tried to fix the animation a little bit.

  • Just some basic adjustments. Notice that it does more, and yet has less events.

    https://www.dropbox.com/s/dqjm7kel3d9qg ... .capx?dl=0

    I did not comment in the capx. Up to you to (learn) figure it out.