Larger collision size for larger sprites/smaller tiles

[Featherbrain]

Looking for a plugin that allows setting larger hitbox sizes (e.g. 2 tiles by 3 tiles instead of default 1x1 tile, etc) especially for the player, but also events and vehicles if possible.

The intent is to allow the use of smaller tile sizes (e.g. 12x12 or 24x24) in lieu of pixel movement. The ability to increase player and event collision beyond one grid tile would make the use of smaller tile sizes much more practical--for instance if using 24x24 (half-size) tiles, the hitbox of a 48x48 sprite shrinks to the 24x24 grid; ideally one could set a default collision size of "2x2 tiles", then the 48x48 sprites would maintain their original 48x48 hitbox. This would also be useful for larger than default sprites. Thanks.

 

[Animebryan]

Yanfly has a plugin that adjusts the hitbox for events (not for the player though). Unfortunately his plugins are no longer free, but it's only $1 for the individual plugin.

Yanfly's Event Hitbox Resize Plugin

 

[Featherbrain]

Yanfly's plugin only works with events that are stationary or set to "through", which seems less than ideal for moving "character" events.

For events I've also found OrangeEventHitboxes. Haven't tried it yet, but it seems like it could cover events.

It's really the functionality to set it for players that is hard to find. I haven't found any solution for adjusting player collision, outside of pixel movement mods, which is exactly what I'm trying to avoid because they all seem to break so many other functionalities and common plugins.

ETA: Experimented with it a bit today and it appears the Orange Event Hitboxes plugin is also only functional for stationary events; setting hitbox sizes larger than 1x1 obstructs the movement of the events. If you set "hitboxX" to -1 it blocks movement to the left, "hitboxY" to -1 blocks movement down, "hitboxWidth" > 1 blocks movement to the right, etc. Setting the events to "through" lets them move but of course disables all collisions, rather self-defeating, lol. So in actuality, there seems to be no available plugins that offer the functionality to set hitbox size for players OR for moving/non-stationary events.

 

[aporokizzu]

I use a combination of Kru_MultitileEvents and EST_Event_Graphic_Shift for the moving enemy events in my project, because they are larger than the standard 48x48 size.

I had to jerry rig their code (by writing custom extensions) to get them to work well together, as well as with the other plugins I am using (Mog Chrono Engine) but it was well worth it.

 

[ImaginaryVillain]

If you're using QMovement you can set the Tile and Grid sizes to 48x48, then set it not allow off grid movement, and you basically have MV's normal move system except you can setup collision boxes. That's what I do. No clue if it will break your other stuff, but I'm building a very action oriented game and haven't really encountered any problems. Might be worth a shot if nobody has a better answer.

 

[Featherbrain]

@aporokizzu Thanks! I'll definitely check these plugins out when I take another pass at collision. The Kru one in particular looks like a big missing link if it indeed allows hitboxes for moving events.


@ImaginaryVillain I checked out the Q suite of plugins when I was first looking into the movement system. Something about it didn't work for my purposes--I think something to do with followers or follower spacing (with large sprites) IIRC. That and the comprehensiveness/proprietariness of the plugin suite was a bit intimidating: must use Qmaps, Qsprite, etc.

Now I'm using TileD with 24x24 tiles for mapping, which, paired with diagonal movement, simulates pixel movement fairly well without a lot of the hassle that actual pixel movement plugins were giving me (not to mention all the mapping benefits of unlimited layers/tilesets in TileD). And TileD allows defining tile-based collision to the half-tile level (12x12 corners of 24x24 tiles), which definitely covers my needs as far as *environmental* collision, and I believe is similar to what Qmovement/Qmap offers?

Thanks for the suggestion, though. If all else fails I'll take a second look at Qmovement. I've seen a few impressive projects using it, including yours!

---

FWIW: Since posting this, for the time being I cobbled together a collision system using Orange Hitboxes, script calls, parallel processes, and self switches:

Spoiler

Essentially I made non-hostile* moving events into parallel processes that detect the player's proximity using a distance calculation script call (see below), then self-switch to a different page where the event stops moving and Orange Hitboxes (which work fine for stationary events) kick in. The effect is that it looks like the NPCs go about their business until the player comes close to them, at which point they turn toward the player and stop moving, waiting for the player to speak to them. If player stays in close range too long without talking to the NPC, or is jumping, pushing against the NPC, or otherwise being "rude" within that close range, the NPC "disengages", attempts to step away from player (until outside of the detection radius) and self-switches back to the normal movement routine/proximity detection page. I messed with this enough for it to look seamless and I'm even kinda pleased with it from an immersion standpoint--makes it seem like the NPCs are paying attention to and reacting to the player.

Script call for calculating distance between player and event:
Math.abs($gamePlayer.x - $gameMap.event(this._eventId).x) + Math.abs($gamePlayer.y - $gameMap.event(this._eventId).y);

*Hostile events work similarly but are even simpler, they just switch to an autorun page that initiates battle if they're within a close enough radius, simulating touch activation. I even figured out the script calls and logic for follower collision detection. Yeah I'm proud of myself, LOL.

But it may all be too processor-heavy in practice, haven't really stress-tested it yet with big maps and multiple events. The Kru plugin might help me take out some of the parallel process logic and improve the processor load. We'll see!

Anyway, while these workarounds more or less work for me (pending stress-tests), it's definitely wonky and complicated, so I consider this request still open. Assuming the Kru plugin covers moving events, the final missing piece would be *player* hitboxes in particular.

 

[ImaginaryVillain]

Yeah Quxios stuff is pretty indepth it's true. Though you only need QMovement. QMap is it's own separate thing for creating maps which I don't even use. QMovement does have a follower add-on though https://quxios.github.io/plugins/QM+Followers but Quxios hates followers and left the scene so who knows how well it works.