Altimit Pixel Movement [0.50β]

Thank you so much ! Your instructions were crystal clear to me and it's working perfectly ! Now I don't know if there is "row" and "Column" kinds of activation commands, but that's a big step forward for me !

Again, thank you, you did a great job with this plugin ! :)

It's simple enough to make a rectangle that is incredibly wide (for rows) or incredibly tall (for columns).

And how would you do that, if you don't mind answering a beginner like me ? x)

The screen does a small 'bump' over and over if you walk alongside impassable tiles and while pressing both up and side. I found it was primarily on left walls, up or down, and I had to be holding down both keys.

There's a few ways you can solve this with polygons, or you could increase the size of the player's collider so they can't get as close to the edge.

Tileset colliders was never implemented, unfortunately, so it has to be done manually. The best way would be to define map collisions, but that would take ages and require a lot of experimenting, testing and iterating.

The next best method would be to create some events with custom colliders applied to them and then copy/paste these events to where you want better collision. What you can do is create the various collider shapes in the Plugin configuration and then reference them in the events.

Would it be possible to implement collision maps like in QMovement?

I feel like it would make it a lot easier if its possible!

Yeah collision maps are a life saver, especially when parallaxing maps. Also because I think plugins like these are best suited for projects that don't want to fall into the normal 48x48 tile/event size boundaries.

With TileD you can put in your own collision polygon meshes easily, which is infinitely better than using a graphics editor, however that's TileD. I remember looking into allowing a graphical collision map that gets converted to polygon on the fly, but it is a difficult problem to solve. Altimit Movement uses polygon collisions, other pixel movement systems don't, so that's why they can rather easily use graphical collision maps.

Polygons are better in pretty much every way at run-time - especially with performance, Altimit Movement enjoys surprisingly good performance compared to other Plugins (which surprised me a lot, considering the heavy polygon collision physics going on) likely because polygon collisions only need to test a single side, rather than a collection of grid co-ordinates (and polygons can be quickly discarded from the check list).

There are ways to define your own polygon collision meshes, unfortunately I never had the chance to document them, but generally what you can do is make a list of common shapes in the Plugin parameters and assign them to events. If I remember correctly, you can also define polygons for entire maps.

The original plan was to make an MV editor Tool that lets you define the collisions in the editor itself (or even convert a collision image) however I did have a brief discussion with the MV developers about creating custom Tools and this kind of thing is not supported by the MV editor (custom tools are a bit of a hack and refreshing map data doesn't work, tools are just external programs).

I just double checked the source code, yeah if you want map defined polygon collisions TileD is the way to go, otherwise use event collisions.

The new polygon movement Plugin I've been designing in my head would definitely allow polygon collisions defined in TileD (without needing the TileD Plugin, just the collision data is used) and I would definitely go with graphical collision map too; developers are too used to defining collision in photoshop or similar so it is smarter to cater to that rather than try and convince people to use a better, yet harder to learn, system.