So, I'm creating an event that uses a character sprite 12 times bigger than the player character. Basically, this event is programmed to damage the player every time it touches them. But for some reason, it only executes these commands if the one square that is the event itself touches the player, not if the sprite for the event touches them. At first I tried creating multiple invisible copies of the event aligned in accordance with the sprite, which temporarily did solve the issue. However, now I need to program the event to move at random, and I can't keep the invisible events that move with it moving with it if they all move randomly as well. Is there any way to make it so that when an event's sprite touches the player, the programmed commands will be executed? Any help would be appreciated. Also, I don't want to have to resort to using scripts if it can be avoided, so please don't suggest those unless what I want to do is impossible without using a script.
Event Touch Problems B/C of Size?
● ARCHIVED · READ-ONLY
-
-
It's because the collision box for the sprites is only 32x32. You need Shaz's Large Sprite script. for the easiest way to handle this.
-
Hmm. I was afraid of that. Okay, thanks for the help.It's because the collision box for the sprites is only 32x32. You need Shaz's Large Sprite script. for the easiest way to handle this.
-
what you describe is the intended default behaviour - you can give an event a larger sprite, but the collision area will always be only the one grid area that the event has in the editor.
Basically there are only three ways around that:
1) creating invisible events where the sprite covers a larger area
That is what you have done, and as you have seen it requires a lot of handling to move those invisible events if the base event moves.
It can be done if the original event handles the movement and moves the invisible events whenever it does its own step - those can only be randomized moves if the main event decides the move, not with independent random movement.
2) a parallel process checking the relative position of the player
That has its limitations in the form of the large sprite - it needs to be regular, and even then it will require a lot of checks and has a high risk of causing lag
3) a script changing the collision detection for events
For Ace, Shaz wrote a script like that, but I don't know if something like this exists for XP. -
Thanks. I've decided to experiment a little more. I might end up just using a script, but for now I'm going to see how things go. I appreciate all of the replies, everyone.what you describe is the intended default behaviour - you can give an event a larger sprite, but the collision area will always be only the one grid area that the event has in the editor.
Basically there are only three ways around that:
1) creating invisible events where the sprite covers a larger area
That is what you have done, and as you have seen it requires a lot of handling to move those invisible events if the base event moves.
It can be done if the original event handles the movement and moves the invisible events whenever it does its own step - those can only be randomized moves if the main event decides the move, not with independent random movement.
2) a parallel process checking the relative position of the player
That has its limitations in the form of the large sprite - it needs to be regular, and even then it will require a lot of checks and has a high risk of causing lag
3) a script changing the collision detection for events
For Ace, Shaz wrote a script like that, but I don't know if something like this exists for XP. -
Oh snap, sorry I didn't realize this was RPG MAker XP section x_x)
-
Does this event move around, or is it stationary? My script really only works for events that don't move (the most common use I have is transfers between maps where there's a space of 3 tiles and I don't want to use 3 events that all do the same thing, but I have quite a few other uses as well). If your event doesn't move around, I don't think it'd take much to convert to XP.