adding a 'lib' folder inside the game dir to $LOAD_PATH

[hanetzer]

Under windows and linux, mkxp's $LOAD_PATH aka $: variable is an empty array []; adding a folder, lib into this array would allow game developers to create custom ruby extensions with native interfaces (eg, written in c/c++ with ruby bindings) and load them from the lib folder with require 'foobar', where foobar is foobar.dll/so/dynlib inside the lib folder.

[Ancurio]

Hm, interesting idea. I played around with support of mkxp-native extensions some time ago (check out the plugin branch).

Is this (ruby side extensions) possible with RMXP? And what problem are you trying to solve? Is there a game that makes use of this?

[hanetzer]

None directly, but I know of a few games that use a custom dll and Win32API with it, so adding the ability to use normal native ruby extensions would aleviate this need and further benefit cross-platform game dev.

[hanetzer]

I've not yet tried using a native extension in rmpx/mkxp, but I have used require for scripts outside of the script database file, and that does work.

[hanetzer]

I would think of this more as an enhancement than a bug in the strictest sense.

[Ancurio]

Hm, okay, but it's hard to warrant adding things with no clear purpose =/ Maybe if there was a specific game you wanted to port that required this?

[hanetzer]

Hmm... More like a game system. See, I'm an admin on save-point.org, and a number of our members have contributed a host of scripts that achieve a certain effect when added to RPG Maker's script database and setup proper. A few very skilled individuals have created very advanced systems using dlls and Win32API; a few have been obsoleted due to MKXP's configuration file (eg, there was a display.dll that allowed you to change the window resolution), but a few remain useful.

One in particular I can really vouch for is MGC's Magic Iso Engine; it allows for the creation of isometric maps through the use of a custom game that serves as a map editor and a dll; but, it requires Win32API to work. Including a proper lib folder and reworking the source code as a proper ruby extension would allow this system to work on all platforms supported by mkxp.

[Ancurio]

So you're saying those enhancing scripts could be rewritten to use ruby's require instead of Win32API and thus work on both RMXP and mkxp?

[hanetzer]

Ayup, that's exactly what I'm saying. EDIT: More like the enhancing dll's themself; they would need a restructuring to work as requireable extensions instead of win32api stuff. A ruby extension loadable by require 'foo' needs a symbol Init_foo that sets up all the classes and such. Not a clue how ruby Win32API works except that it needs to die (and it is, slowly but surely.)

[Ancurio]

Okay. So besides just trivially adding a string like "lib" (or "lib64") to a global variable in ruby, what else would be required for this?

[hanetzer]

I'll compile a small native extension and see if it works within mkxp and see what it does; if it works the rest would be on the shoulders of those who write such code. You're just giving a tool so they can do it better.

[hanetzer]

yep, does the trick. I made a simple rect extension (modeled after the RMXP one), compiled it, and placed the resultant rect.so in Project/lib, then using mkxp.conf I ran the following script:

$: << 'lib/' # appends the lib folder to the load path
require 'rect'
rect = Rect.new(0,0,32,32)
p rect.to_s

and it gave me the popup box with the details of the rect object.

[Ancurio]

What is the default value of $: in RMXP?

[hanetzer]

default is [], that is, empty.

[Ancurio]

Which means a script that wants to run on RMXP too cannot rely on "lib" being inside $:, right? So what is the point of setting it in mkxp if a script can just do that itself?

[hanetzer]

Well, I don't know if you're aware of this but the windows compiled version of mkxp I cooked up can be run from RMXP :P

So, I was just considering the possibility of using mkxp as the engine and RPGXP.exe for the editor.

[Ancurio]

Okay, to avoid any misunderstandings, keep in mind that when I write "RMXP" in 99% of cases I mean Enterbrain's own RGSS player "Player.exe" that implements the RGSS.

Now, am I understanding you correctly that you're trying to "deprecate" RMXP in favor of mkxp? Are you sure the script developers on your forum would be fine with breaking compatibility with RMXP?

[hanetzer]

Actually many of them are very excited regarding it for a number of reasons, including but not limited to having ruby 2.1.2 functions available and being able to release on at least 3 platforms (hell you may even be able to compile this for arm, who knows :shrug: ) Yes, it changes many of the RMXP defaults but so do most of the scripts (to differing degrees). Hell your mouse additions are prompting the main head honcho, DerVVulfman, to rewrite one of his old mouse system scripts to eliminate the Win32API calls in favor of your Input additions.

[Ancurio]

You have to understand that I am very wary about anything that concerns differing behavior between mkxp and RMXP.

There's been many projects before to create "better" or "enhanced" versions of the RMXP player (the last one I looked at was the "Advanced RPG Creator" from Chaos Project) to enable game devs to use features they feel are lacking in vanilla RMXP, or would be cool to have (more layers, multiple tilesets, better audio playback etcetc.) which in the end become their own engines and break compatibility with RMXP.

mkxp is a bit different. My goal with mkxp was to write something that would make it as easy as possible for users to play games on Linux (and likewise Mac) others created on Windows with the RPG Maker editor. This meant approaching fully equivalent behavior to RMXP as close as possible, while adding as little as possible on top. Of course there are limits to this, such as Win32API, which, to fully emulate, I would basically have to ship entire implementations of core Win32 dlls + a dll loader for custom ones, which is an impossible endeavor. I see you noticed the nonstandard RGSS extensions mkxp has; those were not deliberately added from the start to make mkxp superior to RMXP, but rather a compromise I took when I ported "To the Moon" and realized that 90% of Win32API usage in the RPG Maker XP community was for either fullscreen or mouse support. Instead of keeping them in a separate TtM specific branch of mkxp, I included them in the main project in the hopes that they will enable users to run more games with mkxp more easily.

You can read Ethan Lee's goals of FNA if you want, I think there's a lot of similarities with how he sees XNA and how I see RMXP.

That being said, I am not opposed to adding functionality that is 1) trivial and 2) can be neatly tucked away behind off-by-default config options (examples would be showing the real script name in exception messages thanks to work by @cremno), so if you want to have a config entry that basically says "append all this stuff to the $LOAD_PATH variable" we can do that.

At the end of the day, mkxp is open source. Anyone can fork it, anyone can add their own enhancements. All I decide is just what gets added to my branch =)

[hanetzer]

Aint that the truth, lol. Gotta love open source software. I personally don't see any reason to not show the real script name, makes debugging a pita if you have no idea which script broke, but hey, whatever. I'm actually playing Ao Oni on linux with this, lol.

The only thing I could dislike about stuffing $LOAD_PATH stuff into a plain-text file is the fact that once you release a game an end-user could modify this file (quite simply, I might add) and 'shadow' what you want loaded with other libs and cheat in that manner. I personally know how to modify even *.rxdata files via irb on linux, but that takes a bit of know-how and average joe wouldn't be able to 'hack' the game in such a manner.

[Ancurio]

Hmm, aside the fact that a user can just decrypt the rgssad and change all scripts, how would a hardcoded path like "lib" change that? They could just rename your extension.dll and put their own extension.dll in there regardless.

[hanetzer]

True enough, I suppose. Well, one has the source code, so I could theoretically change some of the mkxp.conf default values (so if I want an 800x600 window) and remove the ability to use mkxp.conf at all.

[Ancurio]

Pushed ec16210f8a23b7ca1c034a2536fc07dc3f599967