Rosedale Collision Altering Plugin [MV & MZ]

Thank you for responding - it is much appreciated!

Hey there,

I've been using your Rosedale Collision Altering Plugin, Thanks for the great plugin.

However, I've run into a bit of a snag and I was hoping to get some guidance on how to address it.


Firstly, since specifying collision areas is done through single-stroke drawing, it's currently impossible to separately draw two or more collision areas within a single tile that are not connected to each other. (Refer to the image.) It would be great to have a feature that allows cutting lines or similar functionality to address this issue.



Secondly, when creating a line using only two vertices, there are instances where the positions become misaligned during actual gameplay.


Also, I have a minor query, What 'Ignore Collision' exactly does it do? I have checked this, but the player still couldn't pass through the collision.

Any clarification on this would be greatly appreciated. Thanks in advance for your help!

So I have indeed been looking into this,, but this will require a whole reworking of how collisions are drawn currently, it will probably be added, but I have a few other things I plan to add first, I apologize for this...

Hmmm.. I have not replicated this in any of my testing! Sorry you encountered this, would it be possible to send me a demo project in which this issue is present? If i can find a way to reproduce it I can very much fix this ^^

Great Question! I am not sure if I documented this yet or not so my apologies for that if I have not. So... This is MOSTLY used for tiles, or I believe it works with layered parallaxes as well via a specific plugin( I forgot which one I added support for recently ), So... Firstly you gotta understand, tiles can be layerd... I.E. There is a ground tile at X: 5, Y: 8, but then there is also a a tree tile at this same position right? Now By default, rpg maker will pick the TOP most non star tile, and use the passability of that tile to determine collisions. My Plugin mimicks this same functionality. Therefore, this new feature, prevents a specific tile from overwriting any colliders placed below this tile. In the same example I gave above, maybe the part of the tree being drawn to that location is the tree trunk, and said trunk has a collider attached, but if you were to turn on this feature for the tree trunk in the tool, the tree trunks collider will be ignored! this way the next most highest tile( the tiel directly below it ), will be used fr collision instead.

You may be wondering what is the use of this.... But let's say... you have a wall tile, right? and it's completely impassible. Then let's say you have a moss tile, that is a decoration for the wall, but you dont wanna have to redefine the same collider as the wall, as it just increases file size unecessarily, and is also a bit repetetive, not to mention MAYBE this moss tile doesn't just work as a wall decoration, maybe it makes a good floor decoration, and if you were to give it a collider identical to the wall... then when placed on the floor it would be impasssible right?

Well if wee turn on this feature for our moss tile in the tile editor, THEN when you place it on a wall, it will use the wall tile's collider( and remain impassible for characters ), BUT ALSO, at the same time! when placed on the floor, it will use the floors tile for collision detection( and assuming that this floor is fully passable, or even partially impassible ), it will retain that collision of the floor directly below the moss!

This could all be done by duplicating a tile, anywawys, but this just prevents excess work in stuff like photoshop, and also simplifies things, and saves file size.

I hope my explanation was clear as I am bad at explaining things lol sorry if it's not Q_Q

Is there a script call to return the direction the player is facing if using 8 directions?

it should be the same old script call to get the players direction in general.


This is all I use, it seems to work for me ^^

Hmm, do you have to be using the 8 directional formatted spritesheet with the 8 direction notetag on the actor for it to return an odd value (diagonals)? Because it only returns 2,4 6, and 8 otherwise.

The reason I am asking is because I am using QJ bullet plugin that will shoot a bullet in the direction the player faces/is pressing. I got it shooting in 8 directions in Altimit but had to edit the code to use Altimit's direction8 property. I wanted to test the bullet plugin with your plugin.

Even though your plugin doesn't work with ChronoEngine, I think it's possible to make a shooter-focused ABS by combining your plugin with this one.

Ahh that is indeed correct, it only assigns the direction based on the graphic, because if the direction were to be set to for example 1( which would be down left ), and you only had a 4 directional sprite, the character sprite would attempt to calculate the new frame for direction 1 ( down left ), which would cause an incorrect rendering of your character :x therefore, it is only possible to detect the players diagonal directions when a 8 directional sprite is used. Even when the player moves down left, with a 4 directional sprite though his direction will be either 2, or 4( down or left ).

So if I may uniquire, what exactly are you trying to use the players direction for specifically here? I may be able to assist. ^^

As for... making an Action/Shooting game, This will be very possible very soon. My ABS is currently nearly ready for a beta release( the beta will unfortunately not include support for projectiles yet, but it will be the very next thing added, after everything checks out with the melee combat, and enemy AI ). A lot of ABS's I find are too generic, or lacking, or just feel bad cause the grid based movement. Also it's hard to build an Action Game without proper tools in general... tools that RPG Maker's have long lacked. The collision plugin will be the base for my ABS, so it will have a solid non-grid based movement, and as for the missing tools... I am already pretty far in development for adding support for highly flexible hitbox and hurtboxes. This will allow for highly accurate, AND efficient detection for hitting, and being hurt by, enemy attacks. A preview of setting up hitboxes, and hurtboxes, can be seen in the video below.



So this is ONLY a preview of the tool, and only a small part of that tool, I plan to incorporate an easy to use projectile creator as well, creating projectiles with many varying effect's for example, projectiles, that start slow, and increase speed as it travels, or starts fast, but loses speed as it travels, projectiles that bounce, projectiles that can rotate around the player, projectiles that have an explosion effect, homing projectiles etc.. the list goes on. ^^ On top of this there will also be an enemy AI creator, as well as an enemy alignment setting, where you can choose enemy alignments I.E. maybe you have a goblin type enemy, and an orc type enemy, and they inhabit the same map, and maybe they don't get along, so you can set them as enemies of eachother, and if they encounter one another they will attack eachother. OR instead maybe they are allies, and if you attack a goblin, when an orc is near, he will rush to assist his goblin friend.

This is really only the beginning of what I have in mind for this tool, I plan to make this capable of building very fluid, and professional feeling action style games similar to many popular 2D action/action rpg's found on the snes or nes/sega genesis.

I also plan to add support for building 2D platformers with this same tool as well( you can see a platformer button in the video for choosing the sprite format ^^ ). Sorry, I went off on a tangent here D; but you mentioned an ABS and I thought I would share my next project here, as it was related.~ ^^;

I want to edit this line (3472) in QJ Bullet to change the bullet angle to the direction the player is facing, e.g. if the player presses up and right on the d-pad, fire the bullet at a 45 degree angle.



I would be interested in your new plugin when it comes out, but this plugin is "good enough" for the time being.

okay, so if this is operating off of player input... you can simply use...


This will check if the player is moving in a specific direction AND will ALSO return proper diagonal directions.

But I am assuming that you want the player to be able to fire projectiles while standing still also, which if that is the case, simply using that snippet will not help, as it resets to 0 when the player is not moving at all.

Sooo... I recommend using this bit of code instead.


so what this does... is anytime the player moves, up, down, left, right, or even diagonal... it will store that last moved direction, in the variable of ID( replace ID with the id you would prefer to use ). I recommend using this in a common event, ran in parallel process, that way it's consstantly being updated in real time.

THEN simply using
where I told you to use
SHOULD give you the desired effect your expecting ^^

If you still need further assistance lemme know and I'll do my best to help :D

Also yes, that is understandable, I also meant no disrespect to any other developers who have built an ABS thus far, these types of plugins are a HUGE undertaking, and nothing to be scoffed at, it takes talent to put together something as complex as they have! It is incredibly hard to build such a thing in the first place. So my apologies to any dev's whom I may have offended T_T my bad, sometimes I talk too much.

Thank you, I will try it out after I've submitted my taxes (may have procrastinated a little on that but almost done).
Not at all, your plugins are pretty ambitious and fill a need where other plugins are lacking, or do things that currently require using several plugins together. I'm particularly interested in your 3D plugin combined with an ABS, but that will probably be for a future project.

I've uploaded a demo file! If i make a triangle using 3 dots, it's exactly right, but if use 2 vertices to draw a line, it's out of position.

thanks for sharing this, I'll do my best to get to the bottom of the issue before the next update releases ^^

Thank you for your effort! :LZSproud:

I'm using this plugin and I have a question regarding it. When I repeatedly initiate conversations in front of the counter, it starts triggering unexpected dialogues from unintended sources. Is there a way to fix this?

Hmmm this is interesting I think I made the counter tiles work too good Q_Q lol, joking aside I will check this out ASAP sorry for the inconvenience

Just giving you an update on my project since it has been a while since I have done anything with it:

I was able to make the player stop movement input during battle after checking the alias of the pixel move by input for Chrono Engine. Working good for now.

Still getting the "I can't find X-coordinate 23.2356743" so I built a quick workaround it on the CE side to round out the coordinates at least until I can find a better way to move the player and followers on the screen.

Great work and thanks for the recent update!

----------
Edit: spoke a bit too soon - there is a about 1/4 of a second where if I hold down a direction key right before the UI kicks in for battle, the character will run off yntil it collides with something or hits the edgr of the screen and all control is lost.

I tried working directly with the $gamePlayer update alias and it does stop the player (after 1 frame), but also causing the system to soft-lock and control is lost as well. Will run some more tests and see if there is a remedy or if there is another way to approach this.

Currently, this issue is tied to the $gamePlayer's movement/update/movebyinput. It does work if I don't push any direction buttons during that 1/4 second of loading the battle system.

Update: there was some wierd "x/y" tile by tile movement that was causing this issue so I reworked it in using some of your code. It appears to be functioning well now with the exception of it not being able to find the fractional distances. So far, better, haha. I'll just keep editing this post until I have resolved most things.

So, I just thought, I wouldshare, the next feature being added to the plugin is one that was largely requested ^,^ so I hope this will be helpful to ,any users!





Region Restrictions for the collision plugin! :D Unfortunately, I did NOT add support for outside region restrictions, so I do apologize for that if you were hoping to use a pre-existing one.. it's just far too much work to try to add support for all the variations from MV and MZ especially when some are obfuscated >.<; I ended up writing my own, which is IN the plugin itself, so I apologize if it's not robust enough... if you need more flexibility, please let me know what I am missing...


It's pretty simple to setup though, I hope.

basically, in the plugin manager, you can set region restrictions for players, events( and soon vehicles ), as well as regions specific to ALL characters, not just one specific type!

And if that's not enough, these settings can be overwritten per map too. So if you need to use different regions for a specific map, or only want restrictions in specific map(s), you can use a note tag to overwrite what's in the plugin manager. with something like..

this can be done for all character types just like in the plugin manager.

and... to extend that further, you can ALSO set region restrictions for events independantly.. via a comment on the events page.. Then only the event with this in the comment of the active page, will be restricted by the regions provided, any other event will follow, the map rules, OR if none are set for the map, the rules in the plugin manager, if any are set there.

Now, this update, is still a little ways out from being released, as I am currently investigating several bugs ^^; but once they are all dealt with! I will be sure to release the plugin asap!

Hope this is good news :)

Hello again!

I hope you're doing well. This time, I'm not reporting a bug but I have a feature request. I typically draw collisions on parallax images instead of tiles. However, it’s currently a bit cumbersome as I have to specify collisions for each tile individually. Would it be possible to update the tool so that I can draw collision lines directly on the full parallax image? If this request is too complicated or troublesome, please feel free to ignore it.

Thank you for considering my request!

Hello! I have heard this a couple times before, and( even thought about it before then :c ), but unfortunately as simple as it sounds, it'd take a very large rewrite of the tool itself in order to make this happen. I also would need to rework how parallaxes would work in the plugin side of things, and chances are it would break compatibility with parallax images setup with the current tool as well >.<;

Despite that this is still something I am pondering, however this may be one of the things I do at a later time, as there's other things I intend to address before then as well. >.<; but it is something I am heavily considering. Thanks for the input! It is appreciated :)


Also in regards to yoiur first issue, it seems the offset was only from the y axis, the x axis was unaffected. the reason for this was because well, when the coliders are created in the editor, they are created UNDER the same rules as your projects tile size. I.E. In rpg maker mz you can set the tile sizes to say... 16x16, 24x24, or 32x32 iirc... SO when drawing the colliders in the tool it uses these values... THEN when you SAVE the data... it gets scaled down to FLOAT values I.E. every vertex you place in the collider, gets scaled from a precise pixel point, ranging from anywhere from 0~ your games tile size, DOWN to a number between 0~1. THEN when your game READS this data( on game startup ), it scales these values back up, this is just incase you decide to either scale up, or down your projects tilesets. The collider data will still remain valid to the new tile sizes.

BUT the issue was in the upscaling process! Where I multiplied the y coordinate of line segments start vector, I multiplied y by ITSELF instead of by the tile height u_u since line segments are handled in a seperate format than polygons, it seems that segments were the ONLY one affected by this, and also ONLY the Y axis seemed to be affected as well. the x was correct, and the end vector was all correct as well. but anyways! The issue is resolved! sorry for rambling.. ^^;

Here's a preview!~


TLDR; Line segments being incorrectly placed is fixed lol. :x

That's great to hear! Thank you for your efforts in resolving the issue.