MKXP handles array pointer arguments differently than RMXP

LockeZ commented

2017-10-01 13:26:27 +00:00

(Migrated from github.com)

I have a method in one of my game scripts as such:

def self.event_comment_input(*args)
    elements = *args[0]
    trigger = *args[1]
    ...
    etc.
end

It's called from elsewhere in the script with a line like:

event_comment_input(25, 'Destructable')

In RPG Maker XP's default Game.exe, this causes the variable "elements" to be set equal to 25, and the variable "trigger" to be set equal to 'Destructable'. The variables are an integer and a string.

However, in MKXP's Game.exe, this causes the variable "elements" to be set eqal to [25], and the variable "trigger" to be set equal to ['Destructable']. The variables are arrays.

For now, I can handle this by simply having my script check if MKXP is in use, and setting elements = elements[0] and trigger = trigger[0] if so. It's not a big deal for me personally, since I only have one method in one script using this syntax. However, this would be a major problem in some games, and took me about an hour to figure out what was going on.

I'm not sure which behavior is actually correct for a Ruby compiler, but it's probably best for MXKP to exhibit the same behavior as RMXP even if it's wrong.

I have a method in one of my game scripts as such: ``` def self.event_comment_input(*args) elements = *args[0] trigger = *args[1] ... etc. end ``` It's called from elsewhere in the script with a line like: `event_comment_input(25, 'Destructable')` In RPG Maker XP's default Game.exe, this causes the variable "elements" to be set equal to 25, and the variable "trigger" to be set equal to 'Destructable'. The variables are an integer and a string. However, in MKXP's Game.exe, this causes the variable "elements" to be set eqal to [25], and the variable "trigger" to be set equal to ['Destructable']. The variables are arrays. For now, I can handle this by simply having my script check if MKXP is in use, and setting `elements = elements[0]` and `trigger = trigger[0]` if so. It's not a big deal for me personally, since I only have one method in one script using this syntax. However, this would be a major problem in some games, and took me about an hour to figure out what was going on. I'm not sure which behavior is actually correct for a Ruby compiler, but it's probably best for MXKP to exhibit the same behavior as RMXP even if it's wrong.

carstene1ns commented

2017-10-01 17:11:01 +00:00

(Migrated from github.com)

Ruby is not C, there are no pointers and you can only pass by value.
The * (splat) operator does not dereference here, but is used for Array coercion:
https://endofline.wordpress.com/2011/01/21/the-strange-ruby-splat/
The use of the splat operator has changed between 1.8 and later versions, in 1.8 you could use it to flatten an array (which worked in your example), so either RMXP and MKXP behaviour is fine here, regarding the different ruby versions.

Ruby is not C, there are no pointers and you can only pass by value. The `*` (splat) operator does not dereference here, but is used for Array coercion: https://endofline.wordpress.com/2011/01/21/the-strange-ruby-splat/ The use of the splat operator has changed between 1.8 and later versions, in 1.8 you could use it to flatten an array (which worked in your example), so either RMXP and MKXP behaviour is fine here, regarding the different ruby versions.

Ancurio commented

2017-10-01 17:11:06 +00:00

(Migrated from github.com)

Likely a Ruby change that happened in the 1.8 → 1.9 transition. When I finally get around to merging that PR for builds with MRI 1.8 this should be alleviated.

Does simply using args[0] and args[1] not work correctly under RMXP?

Likely a Ruby change that happened in the 1.8 → 1.9 transition. When I finally get around to merging that PR for builds with MRI 1.8 this should be alleviated. Does simply using `args[0]` and `args[1]` not work correctly under RMXP?

LockeZ commented

2017-10-02 02:37:22 +00:00

(Migrated from github.com)

It probably does. Might even be simpler in this case, but part of this script was written for me by someone else, and I'd rather avoid messing with it any more, now that I've gotten it working, in case there is a reason for why it's done that way.

I'm sure there are ten other ways these arguments could be written that would work the same in both pieces of software. The issue isn't the inability to code a working program, just the inability to run ones that already exist.

It probably does. Might even be simpler in this case, but part of this script was written for me by someone else, and I'd rather avoid messing with it any more, now that I've gotten it working, in case there is a reason for why it's done that way. I'm sure there are ten other ways these arguments could be written that would work the same in both pieces of software. The issue isn't the inability to code a working program, just the inability to run ones that already exist.

MKXP handles array pointer arguments differently than RMXP #177