Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - KK20

I think the problem has to do with the cached map passibility. This is done so mainly for the minimap and potentially the AI.
    # passable if virtual passability works
    return true if ($game_map.virtual_passability[x / pix, y / pix] & bit != 0x00)

If you want to try and debug it yourself, look at the methods self_passable?, direction_passable?, event_check, and tile_check in BABS Part 2.

I'm not aware of an alternative solution for this other than making a duplicate map with the platforms.
RMXP Script Database / Re: [XP] Easy Party Switcher
April 10, 2024, 09:57:46 am
Your problem is unrelated to this script. You need to find (or create yourself) a script that can support an active party size larger than 4, breaking the default RMXP implementation.
Your A B C keys are going to be Shift, Esc, and Enter respectively. It worked for me.
Using the Timed-Hits demo, I'm putting all 3 parts of BABS above all the timed hits scripts. Your configuration has nothing to do with the Input module not being compatible with timed hits. I'm not getting errors with my fix.

Also, please use more descriptive text than just "it doesn't work". That gives me nothing to work off of.
Modify the Timed Hit script to this:
Code: ruby
#Update the bar
        key = false

#Test for a pressed button
        for button in @timed_hit.key_list
          if Input.trigger?(button)
            key = button
#Test for a hit
        if key
          if @timed_hit_bar.hit?(key)
So now you're using an older version of the script and removed the version check?  :???:

Can't really help you anymore without installing RMX-OS myself, which I'm not going to do.
Couple things need to be done. One is to obviously setup the arrow selection to point to the user. The other is to prevent the player from moving the arrow.

So in my script, I had rewritten the two methods update_phase3_skill_select and update_phase3_item_select. I'm just gonna focus on the former for now.
class Scene_Battle
  def update_phase3_skill_select
    # ...
    # If C button was pressed
    if Input.trigger?(Input::C)
      # ...
      # If effect scope is single ally
      elsif @skill.scope == 3 or @skill.scope == 5
        # Start actor selection
We can add the user scope in this conditional
elsif @skill.scope == 3 or @skill.scope == 5 or @skill.scope == 7
Now the arrow shows up but we're able to move it around from actor to actor. We'll need to rework the Arrow_Actor class. Add this class to the script:
class Arrow_Actor < Arrow_Base
  attr_accessor :disable_selection
  def initialize(viewport)
    @disable_selection = false
  alias update_actor_arrow_selection update
  def update
    return update_actor_arrow_selection unless @disable_selection

    # Set sprite coordinates
    if != nil
      self.x =
      self.y =
I've added a disable_selection property to the class. If set to true, you will no longer be able to move the cursor left/right. So now let's set that property:
      elsif @skill.scope == 3 or @skill.scope == 5 or @skill.scope == 7
        # Start actor selection
        # Prevent actor selection if scope is the user
        @actor_arrow.disable_selection = @skill.scope == 7
Now just make the same edits to update_phase3_item_select (replacing @skill with @item obviously).
      elsif @item.scope == 3 or @item.scope == 5 or @item.scope == 7
        # Start actor selection
        @actor_arrow.disable_selection = @item.scope == 7
Start up your game and confirm that the arrow now appears on user scope and doesn't move.

Stays at 00:00 forever? Did you change the configurations? From what I remember, the script doesn't take the current time; you can make up your own calendar and define how long a day is represented in-game. Think the script always starts you at midnight.

Changing the global variable for ates version makes sense. Honestly surprising it's still 1.0 in ATES despite Blizz claiming he made this RMXOS script compatible with it.
You're referring to this script?,12869.0.html

What about it doesn't work? You need to provide more context for anyone to give you help.
I noticed that weird behavior with Drago's script. I've made a patch that you can stick to the bottom of it:
class Scene_Map
  alias reset_pixel_on_transfer_player transfer_player
  def transfer_player
    $game_player.transfer_start = [$game_temp.player_new_x, $game_temp.player_new_y]

class Game_Player
  attr_accessor :transfer_start
  alias init_starting_transfer_loc initialize
  def initialize
    @transfer_start = TRANSFER_START_NIL
  alias check_if_move_off_transfer_start update
  def update
    if @x != @transfer_start[0] || @y != @transfer_start[1]
      @transfer_start = TRANSFER_START_NIL
  alias buffer_trigger_here check_event_trigger_here
  def check_event_trigger_here(triggers)
    if @x == @transfer_start[0] && @y == @transfer_start[1]
      return false
Addresses two things
1. If the player is offset before triggering a map transfer, the game "slides" it back to that same offset upon loading the new map. The fix will stop that slide.
2. If transferring on top of another event that is triggered by player touch, it will trigger upon the player pressing any directional input. The fix will not trigger the event until the player has moved entirely off the space first.

I've also looked at various caterpillar scripts. Fukuyama's (which I think Blizz rewrote and included in Tons of Add-ons) behaves upon player directional input, i.e. one press of DOWN will update all the followers to move 1 full tile space forward, which doesn't work with pixel movement since one press of DOWN isn't a full tile space anymore. In contrast, Zeriab's and Kyonides' wait for the player to move entirely off of the tile first before it updates the movement of the followers 1 full tile forward. This looks better, but this means the followers still move as if using the default RMXP movement, unlike the player.

Both scripts I tried enabling "pixel_movement = true" but the followers' behaviors were still wonky.
What scripts did you try using in the past? It's going to be easier to just find things that work the way you want them to and repurpose them to your needs.

For example, Drago's pixel movement allows toggling events to use pixel movement, and I'm aware of some caterpillar systems that utilize events. Other caterpillar systems create a new type of map object (e.g. Map_Follow, Game_Follower, Caterpillar_Actor) that can probably be modified to work with Drago's script.
RMXP Script Database / Re: [XP] Weapon Specific Skills
January 24, 2024, 09:29:46 pm
Worked for me on a new project.

You sure the enemy can naturally use the skill (e.g. has enough SP to satisfy the SP cost)? Remove the script from your project and confirm the enemy is still unable to use the skill.

Otherwise, will need your project files to investigate it further. Highly doubt it's a script compatibility issue; I think it's more of a database configuration issue.
RMXP Script Database / Re: [XP] Weapon Specific Skills
January 23, 2024, 02:06:27 pm
Did you try adding the script in a project? Looking at the code, the logic is only being applied to Game Actors, not Game Enemies. Your concern shouldn't be an issue.
RPG Maker Scripts / Re: How to read .rxdata
January 15, 2024, 09:12:17 pm
RPG Maker XP uses Ruby v1.8 as its scripting language. As your link explains, Ruby has a module called Marshal that compresses Ruby objects into long strings of bytes. Official docs can explain it more in detail:

Here's a very bare-bones example of what a marshaled object looks like:
Code: ruby
class Test
  def initialize
    @name = 'foo'
    @type = 'bar'

file ='data_dump.txt', 'wb')
test_object =
Marshal.dump(test_object, file)

And then loading it back in is just a simple call of Marshal.load
test_object = Marshal.load('data_dump.txt'))
You just have to be cognizant of the order you dump and load things:
Marshal.dump(object_a, file)
Marshal.dump(object_b, file)
Marshal.dump(object_c, file)
# load in the same order as you dump...
object_a = Marshal.load(file)
object_b = Marshal.load(file)
object_c = Marshal.load(file)

As long as the class for the object you're dumping can be serialized to a string of bytes, you can call the Marshal functions on it. Otherwise, you're required defining the methods _dump and _load for the class (again, this is already explained in both articles).

I believe there are several parsers of marshaled data in various languages. If you really wanted to get your hands dirty and read byte code, you could write your own parser. On the Python side of things, there's this:
I played with it for a while when I was exploring the idea of making an RMXP editor in Python.

This is a very high level overview of Ruby Marshal, but it's not a very easy thing to explain either. It took me a good few years of using Ruby before I understood the inner-workings of it. I don't think you're ready to handle this yet, especially without having any knowledge of RMXP (or Ruby for that matter).

With that said, since it seems like you're interested in Pokemon Essentials games, I can't help you with that. You're better off asking their forums (assuming people don't immediately frown upon the idea of editing save files over there).
Resource Database / Re: RPG Maker Templates
December 09, 2023, 12:58:52 pm
You can try using Wayback Machine. I tried a link out and it gave me a result
Wow, that's super weird, great work finding out about that one. Alongside a console window, I made a simple parallel process event that would print out the difference in time since the event last ran (making sure to initialize the global variable prior to it):
now =
puts now - $prev
$prev = now
The times between each call increases by 0.025 seconds = 1 frame, if the game is running at 40FPS.

I had to put a lot of debug calls throughout the MMW script until I finally found what was causing it, indicated between the lines I marked below:
class Interpreter

  def setup(*args)
    # index of window for the message
    @msgindex = 0
    $game_temp.message_text, $game_temp.message_proc = [],[]

    if @list.size > 1
      templist = @list.pop
      @list <<,0,[1]) << templist

    # whether multiple messages are displaying
    @multi_message = false
What this is doing is, before running the event, it adds a "Wait 1 frame" event command to the end of the list. A parallel process will call this setup every time it runs, so your event list keeps getting longer and longer, filled with Wait commands.

Obviously this was not intentional for parallel process events, so it was probably designed for the on-trigger type events. I'm not sure why it arbitrarily adds a 1 frame wait at the end to every event...
but we can make sure that it only ever does it once:
    if @list.size > 1 && @list[-2].code != 106
      templist = @list.pop
      @list <<,0,[1]) << templist
I'm not getting that symbol, but I am getting the character with octal value of \016 (which just renders as a missing glyph: ౝ ). That value is what substitutes the \a.

In MMW, if you take a look at def update_text, it evaluates each character one-at-a-time.
      # Get 1 text character in c (loop until unable to get text)
      while ((@c = @text.slice!(/./m)) != nil)
        # Plays Sounds for each Letter, Numbers and Spaces Excluded
        case eval_text(self.contents)
        when 0 then return
        when 1 then next
        # Draw text
        self.contents.draw_text(4 + @x, 32 * @y, 40, 32, @c)
The eval_text method is where the backslash flags are processed. Depending on what the flag is, it can return a value of 0 or 1, which will stop it from being drawn. Because it's still drawing \016 to the window, eval_text must not be returning anything.

Let's look at where it handles the character \016:
  def eval_text(bitmap)
    if @c == '\015' || @c == '\016'
      if @c == '\015'
        # ...ignore this...
      elsif @c == '\016'
        @text.sub!(/\[(.+?)(?:(\d+))?\]/, '')
        name = $1.to_s
      create_name_sprite(name) if name != ''
Notice that there is no return called here. If I simply add return 1 right below the line create_face_sprite(face), it no longer draws \016.

This is clearly a bug with the script.
I had to setup a project to see this for myself. As it turns out, MMW changes the behavior of $game_temp.message_text to be an Array rather than a String, which ends up breaking the Localization script.

What we need to do is make an add-on for MMW by aliasing the replace_basic_code method and call upon Localization.localize's logic:
class Window_Message < Window_Selectable
  alias f0_localize_rbc replace_basic_code
  def replace_basic_code
    @text.gsub!(/\\[Kk]\[(.+)\]/) {$1) }