Requesting a dynamic collision script.

● ARCHIVED · READ-ONLY
Started by deathsia 17 posts View original ↗
  1. deathsia
    #1 Source
    As the title says, I would like it if someone could create a dynamic collision script.

    I am well aware that a few exist but none of them produce the functionality I need for my game. The following is an example and for the sake of agruement I will be using the colors red and black in my example.

    Red=inpassable

    Black=Passable

    paralax examples.png

    In example 1 you can see the 32x32 pixel is filled in half by both colors, what This means is that half the tile is passable while the other half isn't. While this is similar to RPG maker's default 4-dir passability this is only the start of what I'm asking for.

    In example 2 you can see that each half is still colored in each color but unlike example 1, it's colored in a diagonal fashion. This kind of passability is also possible in RPG maker's 4-dir settings but the program handles it in a choppy fashion.It often causes the player to seemingly jolt up as they run into the tile with this type of setting.

    Now for example 3, you can see that the black color goes in a curve unlike the last two examples, this is as far as I know, IMPOSSIBLE with RPG maker VX ace's passability settings.

    Hopefully these 3 examples have given you a good idea of what I'm asking for.

    In conclusion, what I need is the following:

    • The ability to create a collision map that the script is capable of reading the color code precisely and accurately.
    • Fluent and seamless motion when the player comes in contact with these tiles.(Not a requirement but preferred)
    • The player will be able to move about the map according to the how the collision map is colored pixel by pixel.
    • 64x64 sprite size compatibility.(Not a requirement but preferred if possible)
    • Events being able to read this color code accurately.
    • Compatibility with parallax maps.
    • OPTIONAL: A 3rd color code for behind passability settings.
    Please feel free to ask me any questions or point me to a script if one exists that is capable of this.
  2. Shaz
    #2 Source
    Are each of those images a single tile?


    Are you using a pixel movement script? If so, you'd better provide a link, as this will need to be compatible with it.


    Or are you ASKING for a pixel movement script that performs collision checking at a lower level than the 32x32 of most pixel movement scripts?
  3. deathsia
    #3 Source
    Yes, each image is a single tile. I simply didn't bother to separate the boxes to different images which represented my examples.

    And yes I use a pixel movement script although it's a little hard to figure out atm due to the fact my sprites are 64x64 pixels large. VE Pixel Movement

    Not to mention the fact that a custom script I'm using allows me to use these 64x64 sized sprites but rpg maker itself only recognizes half of it. >.< (the normal 32x32 sprite size) So half of my sprite will often seemingly pass over other NPCs because the engine is only reading half the sprite even though the custom script displays it.

    In case I confused the LIVING HELL out of you, this is what I'm using to display my 64x64 sized sprites:

    Spoiler
    #----------------------------------# Thera's variation of the multiple frame script.## My first RSS script ever. I'm pretty proud of it.# It's meant to be used with a sprite set of 9 frames wide, with the first frame# being a 'standing still' frame, and the rest the actual walkcycle.## It only works on files using a '%' at the beggining of their name.#----------------------------------class Sprite_Character < Sprite_Base #-------------------------------------------------------------------------- # * Set Character Bitmap # # Thera's notes: Character Bitmap analyses the spriteset and sets how big # the frames in the sprite set are. # It also checks before hand whether the file start with a '!', '$' or '%' # After wards it sets the drawing origin of the sprite relative to the # character origin. #-------------------------------------------------------------------------- def set_character_bitmap self.bitmap = Cache.character(@character_name) #start changes# # Yes, this is a nested if_statement, but files starting with '!' would # complain if I did otherwise. sign = @character_name[/^[\!\$\%]./] if sign && sign.include?('$') @cw = bitmap.width / 3 #Orginal Value 3 @ch = bitmap.height / 4 #original value:4 @sixframes = false else if sign && sign.include?('%') @cw = bitmap.width / 9 #Original Value:9 @ch = bitmap.height / 4 #Original Value:4 @sixframes = true else @cw = bitmap.width / 12 #I made a change here Original value:12 @ch = bitmap.height / 8 #I made a change here Original Value:8 @sixframes = false end end #end changes# self.ox = @cw / 2 self.oy = @ch end #-------------------------------------------------------------------------- # * Update Transfer Origin Rectangle # # Thera's notes: Update Transfer Origin Rectangle changes the part of the # spritesheet that is being used as the current sprite of the character. # So it moves this rectangle around on the spritesheet. # I make it check whether 'sixframes' and thus the special sheet is true, # applying different rectangle movements for different spritesheets. #-------------------------------------------------------------------------- def update_src_rect if @tile_id == 0 index = @character.character_index #start changes# if @sixframes pattern = @character.pattern+1 #I had to do this, this way, so that the #animation doesn't do back to the second frame after visiting the third. #The '+1" Allows it to skip over the first frame, the standing still #frame sx = (index % 4 * 9 + pattern) * @cw #orginal second value: 9 Orginal first value: 4 else pattern = @character.pattern < 3 ? @character.pattern : 1 sx = (index % 4 * 3 + pattern) * @cw end sy = (index / 4 * 4 + (@character.direction - 2) / 2) * @ch self.src_rect.set(sx, sy, @cw, @ch) end endendclass Game_CharacterBase #-------------------------------------------------------------------------- # * Update Animation Pattern # # Thera's notes: Update Animation Pattern makes sure that a character cycles # through it's sprite animation. Again, it first checks the filename before # applying operations. # The @pattern variable if very important when editing sprite animation. # Thus I edited basically any instance of it being modified when making this # script. #-------------------------------------------------------------------------- def update_anime_pattern if @character_name[0, 1] == '%' if !@step_anime && @stop_count > 0 @original_pattern = -1 @pattern = @original_pattern else @pattern = (@pattern + 1) % 6 #original value 8 #Changed it to 8 here because we want to have an 8 frame animation. end else if !@step_anime && @stop_count > 0 @original_pattern = 1 @pattern = @original_pattern else @pattern = (@pattern + 1) % 4 end end end # Thera's notes: I actually don't know what straighten position is supossed to # do exactly, but as it was modifying the @pattern variable, I decided to # adapt it to this script's standards. def straighten if @character_name[0, 1] == '%' @pattern = -1 if @walk_anime || @step_anime @anime_count = 0 else @pattern = 1 if @walk_anime || @step_anime @anime_count = 0 end end # Similar as with straighten, I adapted this one because of the appearance of # the @original_pattern variable. def set_graphic(character_name, character_index) @tile_id = 0 @character_name = character_name @character_index = character_index #changed from 1 to -1 if @character_name[0, 1] == '%' @original_pattern = -1 else @original_pattern = 1 end #end change endendclass Game_Event < Game_Character#-------------------------------------------------------------------------- # * Set Up Event Page Settings # # Thera's notes: This sets up the event with all the parameters defined in # the event page in the editor. I chenged the part where the character graphic # was set up, because otherwise it would default to the second frame when # character were standing still. #-------------------------------------------------------------------------- def setup_page_settings @tile_id = @page.graphic.tile_id @character_name = @page.graphic.character_name @character_index = @page.graphic.character_index if @original_direction != @page.graphic.direction @direction = @page.graphic.direction @original_direction = @direction @prelock_direction = 0 end if @character_name[0, 1] == '%' if @original_pattern != @page.graphic.pattern @pattern = @page.graphic.pattern @original_pattern = -1 end else if @original_pattern != @page.graphic.pattern @pattern = @page.graphic.pattern @original_pattern = @pattern end end @move_type = @page.move_type @move_speed = @page.move_speed @move_frequency = @page.move_frequency @move_route = @page.move_route @move_route_index = 0 @move_route_forcing = false @walk_anime = @page.walk_anime @step_anime = @page.step_anime @direction_fix = @page.direction_fix @through = @page.through @priority_type = @page.priority_type @trigger = @page.trigger @list = @page.list @interpreter = @trigger == 4 ? Game_Interpreter.new : nil endend
    I'll be damned if I find the guy who made it so I copied and pasted from my project. Anyways, this is a moot point.

    What i'm ASKING for is what I said above. Not sure how much clearer I can make it.

    It's either that or I'm completely confusing two types of scripts here.

    Anyways, what I'm asking for is a dynamic and advanced version of THIS

    As you can see, her/his script creates a basic pass or no pass setting with the colors red and black. Now take that and look at my example above and you'll see what I'm asking for hopefully.

    And yes, I want it to detect the color code at a range smaller than the 32x32 pixel size.
  4. Andar
    #4 Source
    In cases like this, pixel movement and pixel collision are very closely tied togeter - you can't do the one without knowing the other. That is why Shaz had to ask about that, because you didn't give the info about what pixel movement you use in the first post.


    Basically the only two options for this are either to write a pixel collision script that ties in to Victor's pixel movement (which requires the scripter to analyze and understand that specific pixel movement script, which is a lot of work by itself) or to provide a script that handles both pixel movement and pixel collision on its own, replacing Victor's Pixel Movement in your project.
  5. deathsia
    #5 Source
    Andar said:
    In cases like this, pixel movement and pixel collision are very closely tied togeter - you can't do the one without knowing the other. That is why Shaz had to ask about that, because you didn't give the info about what pixel movement you use in the first post.

    Basically the only two options for this are either to write a pixel collision script that ties in to Victor's pixel movement (which requires the scripter to analyze and understand that specific pixel movement script, which is a lot of work by itself) or to provide a script that handles both pixel movement and pixel collision on its own, replacing Victor's Pixel Movement in your project.
    Which of the two would be simpler to accomplish? I don't wanna say "easier" because making a script like this from scratch would be a challenge in itself.
  6. Andar
    #6 Source
    depends on the scripter - if someone has previous experience with pixel positioning, it might be easier to write from scratch - but if someone is familiar with Victor's scripts, then it would be easier to write it as an add-on.
  7. deathsia
    #7 Source
    Andar said:
    depends on the scripter - if someone has previous experience with pixel positioning, it might be easier to write from scratch - but if someone is familiar with Victor's scripts, then it would be easier to write it as an add-on.
    Well, I'm hoping someone will take up the request either way. the current pathing system is not fit for my 64x64 sprites plus my maps are custom drawn and hardly confine to the strict 32x32 pixel format.
  8. Shaz
    #8 Source
    Glad you mentioned that you're using larger-than-32x32-pixel sprites too, because that's important. By default, I think most people would have assumed your character is still 32 pixels, so if you got a script written it would be based on that.


    So you need a pixel movement and collision script that allows for a player sprite larger than the default size AND collision at the pixel level rather than a 32x32 grid.


    Your sprite is 64 wide, but what "depth" do you want to use? When you move horizontally, do you ONLY want to be able to go if there's a 64-pixel-high gap to move into (ie - your WHOLE sprite height can fit into the gap)? Or should it allow, say, the head (maybe top half?) of the sprite to go over an impassable area as long as the bottom half is passable?


    If you're not sure what I mean, just grab a sprite that's more than 32 pixels high, place a wall along the back of your map, then make your character walk right up to the wall - see how they don't stop when the tip of their head touches the wall?
  9. deathsia
    #9 Source
    Shaz said:
    Glad you mentioned that you're using larger-than-32x32-pixel sprites too, because that's important. By default, I think most people would have assumed your character is still 32 pixels, so if you got a script written it would be based on that.

    So you need a pixel movement and collision script that allows for a player sprite larger than the default size AND collision at the pixel level rather than a 32x32 grid.

    Your sprite is 64 wide, but what "depth" do you want to use? When you move horizontally, do you ONLY want to be able to go if there's a 64-pixel-high gap to move into (ie - your WHOLE sprite height can fit into the gap)? Or should it allow, say, the head (maybe top half?) of the sprite to go over an impassable area as long as the bottom half is passable?

    If you're not sure what I mean, just grab a sprite that's more than 32 pixels high, place a wall along the back of your map, then make your character walk right up to the wall - see how they don't stop when the tip of their head touches the wall?
    That can vary tbh but for all intents and purposes, the sprite would only be able to progress in most circumstances if it was the hight of the sprite for a clearer idea let me upload an image is a sprite set: %25Applejack%20test%20set.png
  10. Andar
    #10 Source
    deathsia said:
    That can vary tbh but for all intents and purposes, the sprite would only be able to progress in most circumstances if it was the hight of the sprite for a clearer idea let me upload an image is a sprite set:
    That doesn't answer Shaz's question, and it's an important one.
    Look at the picture in the following link:


    http://s3-ap-northeast-1.amazonaws.com/rpgmaker.assets/product_sale_images/images/medium/hfpic1.png?1375360518


    At the top left market stand, you see a character sprite standing in front of it, with the stand beginning at half the sprite size. It looks natural this way, because we all know that people are higher than the place they occupy on the ground.


    Unfortunately, the computer does not know that - for the computer, this is the result of a 32x32 collision area combined with a 32x64 size sprite. And you cannot simply change that collision area depending on map structures (OK, theoretically it could be done but this would cause the script to be a lot more work).


    If your collision area is the same as the sprite area, then the sprites would stop moving when the top of their heads hit the very lowest bottom of the market stand.


    If your collision area is smaller than the sprite area, you get the look like the picture linked above.


    You have to make that choice absolutely - not "that can vary", because it will determine how the movement and collision will work.
  11. Shaz
    #11 Source
    yeah, exactly. If you say the height of your sprite is the area that's needed to walk into, your sprite will never be able to walk "up to" a rear wall or counter - it will always look like it's standing a tile below it. Its FEET should not be able to go onto the wall, but its HEAD should be able to.


    Looking at your sprite, I would say the bottom half needs to check collision, but the top half does not, and it's okay for it to appear "over" impassable tiles. It just means you're walking as close to it as you can, until your FEET are about to touch it.
  12. deathsia
    #12 Source
    Shaz said:
    Looking at your sprite, I would say the bottom half needs to check collision, but the top half does not, and it's okay for it to appear "over" impassable tiles. It just means you're walking as close to it as you can, until your FEET are about to touch it.
    You hit the nail right on the head there, Shaz. I have a hard time describing exactly what I need when it comes to technical details.
  13. FenixFyreX
    #13 Source
    - The ability to create a collision map that the script is capable of reading the color code precisely and accurately.
    This requires bitmap processing and is best achieved by compiling and caching the passabilities into a data file which is loaded on the fly.
    - Fluent and seamless motion when the player comes in contact with these tiles.(Not a requirement but preferred)
    Generally any pixel movement script does this; it's hard to actually write glitchiness into the sprite coming to a stop.
    - The player will be able to move about the map according to the how the collision map is colored pixel by pixel.
    See point 1.
    - 64x64 sprite size compatibility.(Not a requirement but preferred if possible)
    This requires processing character sprite data (which could be either manually or automatically derived; once again, bitmap processing, which is slow).
    - Events being able to read this color code accurately.
    I'm sure pixel movement in any script edits the base class for all characters, thus rendering this requirement already complete if someone edit's Victors.
    - Compatibility with parallax maps.
    Actually parallax maps are easier to make work with pixel movement, it is just generally more filesize for the game, requiring parallax images (up to how many layers per map, plus the passability bitmask?)
    OPTIONAL: A 3rd color code for behind passability settings.
    This would already be implemented by the default editor; simply edit the tileset in the database to make the tile at hand above the player, or use an event. Really, the collision bitmask system you are requesting only affects passable and non passable tiles, not above the player tiles.
    Considering all of these points, I'd highly suggest looking at Khas' pixel movement. It does all of this, it's great: Khas' Pixel Movement
  14. deathsia
    #14 Source
    FenixFyreX said:
    Considering all of these points, I'd highly suggest looking at Khas' pixel movement. It does all of this, it's great: Khas' Pixel Movement
    I considered this as one of the first options but the script says that's its incompatible with scripts that heavily edit character data. I have a script in my game that does just that. I also use very large maps which is also another stated incompatibility mentioned in the script.
  15. Tsukihime
    #15 Source
    I'd suggest finding scripts that are compatible with pixel movement, rather than trying to find a pixel movement script that is compatible with your script.
  16. deathsia
    #16 Source
    Tsukihime said:
    I'd suggest finding scripts that are compatible with pixel movement, rather than trying to find a pixel movement script that is compatible with your script.
    Well I tried using yours in combination with VE's Pixel movement script but the issue was that when using my parallax map,(which hardly confines to a 32x32 grid btw) Your script made the passage movement worse than the basic built in passage system. idk whether it was because I simply didn't tweak your scripts settings right, miscolored the collision map, or if it was something in the pixel movement script that I needed to set but it just didn't want to work right.

    When I first saw your script I was like "OH SWEET! Now I can make custom path settings!" Then I realized it was still confined to a grid and I was like "*Facepalm* Damn it, this didn't do what I thought it did..."

    If you know how to tweak the settings in your collision map script to work with VE's pixel movement script, by all means... PLEASE TELL ME WHAT TO DO!

    I'll even take a script snippet if it's needed to patch your script to work with it!

    I'll be happy with being able to make it so my 64x64 sprites at the very least can walk to a drawn cliff part of the map without being forced to halt up to 3 tiles away to prevent it from walking OVER said cliff.
  17. Tsukihime
    #17 Source
    I don't know how to modify victor's script to work with the collision map.


    I tried it when I first wrote it but couldn't figure out how the pixel movement even works to determine when collision detection is being performed.