MZ - Ignis Pixel Movement v0.7 (MZ)

This plugin works nicely though I find it a bit confusing to adjust settings of.

My biggest problem though is when player followers are on. That is when you see members of your party following the lead character on screen.

They don't follow but instead stay in the same spot as the leader and just kinda... glitch while moving.

On a completely unrelated note...

Why does MZ STILL use GRID-based movement and with absolutely no option for pixel-based???

Grid-based movement is so dated.

EDIT #1 - I just noticed you are already aware of the follower issue. My bad! :yswt:

Just as a thought @Raizen could you have a parameter that we can turn on and off that draws a semitransparent box where collisions are for events so that it's easier to understand where the collisions are?

I'll need to check that, its because shadows also need to be on "pixel movement" mode, but I hope I can fix everything very soon o/
No problem friend! o/,I am working on the issues currently, I hope you all like this next version!


Yeah, that is a great idea, I think I'll implement that also o/

Hey Raizen,

Great work so far! Looking at your demo it appears that pixel movement extends to the event random movement patterns making them look a little bit like they are going through epileptic fits; is this something you are going to be working on or will we need to create custom movement routes for each event to get the standard movement patterns?

In this actual version you can switch to tile mode ando move them, and then switch back.
There are a lot of things I need to work on this still :( . Improving the events movement is one of the priorities.

For sure, but I think for most games, the important thing is the player's pixel movement; 98% of the time the NPC and event movement can be tile based; particularly in the case of random NPC movement where there is already 8 directional movement.

If you do full NPC pixel movement, are you thinking to restructure the event movement scripts for custom scripts?

I don't have MZ but I want to buy it soon. Just thinking what I do / to try out first with MZ.

So I watched your video and it looks great! But I would have two short question / request: Is it possible to activate an Event if it's touching a player? So the player is standing still and an Event moves to him - Event-Hitbox and Player-Hitbox are overlapping = trigger this Event.

Also, would it be possible to make / define more hitboxes for an Event or Player (multiple hitboxes)?
For example for an ABS if the enemy shoots a flame, it would be nice to define maybe 2 or 3 hitboxes to that. So it's not Pixel-Collision but for some things it would be great to have a better & accurate hitbox(es) e.g. for battle systems, some minigames, etc.

PS: Sorry for my bad english.

First of everything, I'm noob as hell at coding, so don't mind if I say stupid things about it :D.

Second, excuse my english (not my language ^^').

The point is that your plugin seems to manage really well with hitboxes and I was wondering if there's any possibility to be compatible with Doodads, I mean, a way to configure the sprites so you can place it with Doodads with their own colision box.

Anyways, nice work atm. Thanks for your time

I'll try it out myself but does anybody know if this plugin plays nicely with other plugins that make use of collisions such as Galv's Map Projectiles?

Good morning, folks!
Surprisingly, this thread seems largely dead, but I'll liven this topic a bit for ya!

I am J/JE/Jragyn, the author of JABS, the Action Battle System that I wrote and released to the public at the start of the year! JABS I like to think is a pretty dandy ABS choice for MZ if that is your cup of tea, however, one of the key features it is missing is indeed a quality pixel movement system. I specifically designed JABS to be flexible, but am only really now getting to the point where I am starting to look to add compatibility for external systems.

Looking at your videos, it seems to run pretty fluidly considering sprite count and concurrent pixel detection management. Looking at your code behind, it looks pretty concise/compact (barely 500 lines of code). I'm impressed! I thought pixel movement would take significantly more code modifications to accomplish this!

What kind of usage rules do you have about integrating this pixel movement system into other systems? I was thinking of writing my own pixel movement system into JABS, but this might be small enough to just weave into it instead. Thoughts?

After attempting to integrate this system into my own, I've determined that it imposes some restrictions that I'm not comfortable with. For those who come after me, those restrictions are that apparently this system only works with the dual analog sticks on a controller, and doesn't appear compatible with the D-Pad at all (unless I've mistaken). A shame, really.

Hey, I know this thread hasn't been updated in a long time, but hopefully the maker is still active.
I'm having an issue where Action Button events one space down from the player can't be interacted with. Events up, left, and right are working, but not down. Any idea what could be causing this?

Here are my parameters (which I'm admittedly having a hard time understanding):
Cursor Distance: 480
Default Player Collisions: [x: 0, y: 0, width: 48, height: 48]
Default Event Collisions: [x: 0, y: 0, width: 48, height: 48]
Region Collisions: unedited from the sample project
Default Mode: true

how to call
default mode: true/false
in middle of game?