BDR Tile - v1.2

[Fustel]

BDR Tile Version: 1.2 for RMVX
By: Fustel

Introduction
How many times did you ask yourself: "What tile is the player on?".
One of the answer was to scan the $map.data layers and test all the values assignable for a single tile.
Another, the right one, is to use this little scripting tool that identify a tile by its panel ID ("A" to "E") and it column and row in the panel.
And... do I have to say this little one will soon be a requirement for future BDR scripts.

Features

• Identifies tiles by panel, column and row in the panel

Screenshots

Spoiler: Tile Analyze

The 'to_s' method of an array is not very demonstrative, but I assure you that the first line IS an array

Demo

Spoiler: Tile Analyze

http://www.mediafire.com/file/utywztizjm2/BDR Tile - v1.2.zip

Just walk around and use the 'Analyze Map Tile" skill to see what's under your feet (or above your head).
All is in the script line of the commopn event 'Show Map Tile'.

Script
[rgss]#==============================================================================
# ** BDR Tile
#------------------------------------------------------------------------------
#  © Fustel, 2010
#  13/04/10
#  Version 1.2
#------------------------------------------------------------------------------
#  VERSION HISTORY:
#   - 1.0 (06/04/10), Initial release
#   - 1.1 (13/04/10), the method is now 'tile_id' and callable from any Game_Map
#   - 1.2 (19/04/10), introduction of the with_panel metod to the Array class
#-------------------------------------------------------------------------------
#  INSTRUCTIONS:
#   - Place this script in the 'Materials' section
#   - Call tile_id( x, y, layer) from any map (generally $game_map)
#       to get the id of the tile layer (1=ground, 2=decoration) at (x,y)
#   - The result have a dual forms and may be seen as:
#     - a 2 elements array (mainly designed for the ground layer):
#       - the [0] element is the column in the tile panel
#       - the [1] element is the row in the tile panel
#     - a object with the following properties
#       - 'pane' ("A" to "E") determining the panel
#       - 'col' for the column in the panel
#       - 'row' for the row in the panel
#   - the 'with_panel' method of the object returns another objet wich
#       can be seen as a 3 element array:
#       - the [0] element is the column in the tile panel
#       - the [1] element is the row in the tile panel
#       - the [2] element is the panle ID ("A" to "E")
#------------------------------------------------------------------------------
# NOTES
#   - The Array class has been modified so that the [0] and [1] elements can be
#       refered by (respectively) 'col' and 'row' methods.
#==============================================================================
 
class Array
  attr_accessor :panel
  def col
    return clone[ 0]
  end
 
  def row
    return clone[ 1]
  end
 
  def with_panel
    return [ col, row, @panel]
  end
end
 
module RPG
  class Map
    def tile_id( x, y, layer=1)
      result = []
      begin
      if layer == 1
          m = [ @data[ x, y, 0], @data[ x, y, 1]].max
          if ( 2048...8192).include?( m)
            n = m-2048
            n /= 48
            result[ 0] = n % 8
            result[ 1] = n / 8
          elsif ( 1536...1664).include?( m)
            n = m - 1536
            result[ 0] = n % 8
            result[ 1] = n / 8 + 16
          end
          result.panel = "A"
        elsif layer == 2
          m = @data[ x, y, 2]
          case m / 256
            when 0: result.panel = "B"
            when 1: result.panel = "C"
            when 2: result.panel = "D"
            when 3: result.panel = "E"
          end
          m %= 256
          result[ 0] = m % 8
          result[ 1] = m / 8
        end
      rescue
      end
      return result
    end
  end
end
class Game_Map
  def tile_id( x, y, layer=1)
    return @map.tile_id( x, y, layer)
  end
end
[/rgss]

Instructions

• Copy the script in the 'Materials' section, as it fully overwrite the main methods
• Call the tile_id(x,y,layer) method from any map (be it a RPG::Map or a Game_Map instance), where
  • 'x' & 'y' are the coordinates of the tile in the current map needing identification
  • 'layer' is optional and is the layer needing identification (1 for ground (default), 2 for decorative)
• The result have a dual forms and may be seen as:
  • a 2 elements array (mainly designed for the ground layer):
    • the [0] element is the column in the tile panel
    • the [1] element is the row in the tile panel
  • a object with the following properties
    • 'panel' ("A" to "E") determining the panel
    • 'col' for the column in the panel
    • 'row' for the row in the panel
• The 'with_panel' method of the resulting object returns the same object, except its Array view is as follow:
  • the [0] element is the column in the tile panel
  • the [1] element is the row in the tile panel
  • the [2] element is the panel ID ("A" to "E")

Exemples:

• id = $game_map.tile_id( $gamep_player.x, $game_player.y) # => [ 0, 2] on grass
• id = $game_map.tile_id( $gamep_player.x, $game_player.y, 2).with_panel # => [ 0, 30, "D"] on a rail track

FAQ

Compatibility
No issue known, although the Array class was ovrloaded to include the 'col', 'row' and 'panel' attributes/methods

Credits and Thanks
All done by myself

Author's Notes
v1.0 to 1.1:

• The method to call is renamed 'tile_id'
• The method is to be called from a map, not the BDR::Tile modul, which is removed

v1.1 to 1.2

• Adds the 'with_panel' method to the ID object

Terms and Conditions
You may not use this in a commercial game without my explicit permission.
You may not post this script anywhere without my explict permission.
You must give me credit.

 

[BlueScope]

Another interesting concept... actually, kind of cool, but improveable in the following ways IMO:

- naming a module after yourself is still bad coding style, no matter how coolyour name might be
- instead of a display key, this needs a toggle for a display of non-backgroundwindow-numbers in one or the other corner, showing you the data... the way it is right now makes it unnecessarily complicated...
- the display is kind of complicated.. as this apparently is a debug tool, people looking at it will be content with a small hint on what stuff is: c for column, r for row, p for panel, rest is unneeded expect for the actual numbers, of course. This means a single tile could easily be tied down to a single line, making the first suggestion perfectly valid for both easy debug display and, for example, console integration.
- it should display the raw hex tile data, as that's what you need as a scripter.
- only cosmetical really, but wheather or not someone uses your script in a final game or not isn't really important to the final game, only to the programmers. Therefore, making it a condition to credit you for a development tool is somewhat unappealing. Did you every credit Photoshop or something similar in your games? ^^

Keep up the good work though... I see a lot of good stuff coming from you lately.

 

[game_guy]

Nice script. I may borrow the code and try to make an XP version.

Offtopic:
@BlueScope: I know its your oppinion but the naming the module after yourself is actually to avoid Compatability issues and possible method overwriting.

Example: I know this most likely won't happen but its still safer to name it yourself.

module Actors

  Actors = []

  def self.add_actor(name)

    $data_actors.push(RPG::Actor.new)

  end

end

module Actors

  Actors = []

  def self.add_actor(id)

    $game_party.add_actor(id)

  end

end

Its just an example of what could happen. The first Actors would no longer create new actors. Instead the new Actors module would only add actors to your party.

 

[BlueScope]

I completely realize that, and did before. That doesn't change the fact that from a perfect-script-point-of-view, naming the module after something as unselfexplanative as BDR makes no sense at all and therefore is a no-go, if simply for the reason of doing it right.

Example: I know this most likely won't happen but its still safer to name it yourself.

I totally agree with that statement... naming a method, module, class or whatever yourself is perfectly fine, for mentioned compatibility issues and the like. However, naming it after yourself is the critical part IMO.

Well, overall, it's just a cosmetical and usuability thing, meaning it won't matter for 99% of all users, and I know it's something many experienced people like Seph or whoever do as well. However, I feel comfortable spraying my opinion graffity-wise all over the forums, as I think a bit more perfection doesn't hurt anyone... especially not scripters.

(on a side note... your first method up there is pretty bogus, don't you think? ^^")

 

[game_guy]

It was an example D:

xD I get what you're saying. I completely understand too. I just thought I'd throw out my 2 cents as you did.

 

[Fustel]

You're welcome to borrow the code. Just notice the little change to version 1.1, as it quickly became obvious the tiles should be identified from maps other than the $game map.
Exemples of the utilization of this little script are coming soon.

 

[Fustel]

Added the 'with_panel' method to the result to obtain more readable result in a single script line... lazzy me