HiddenChest RGSS Player Executable

[kyonides]

A Long Awaited Update?

Normally, you would need to open the hiddenchest.conf Configuration file to enter the name of your game project. Thus it would be capable of finding the corresponding RGSSAD or RGSS2A or RGSS3A compressed file. That happened because MKXP's developer Ancurio was TOO LAZY to do it automatically.

But don't worry  guys! Now HiddenChest version 1.1.59, I mean, 1.1.46 for Linux will find the file on your behalf!

How is it possible? Well, it has a lot to do with a weird bug I had found in Ubuntu's Ruby development package. It forced me to look for a way to do the Dir#glob search in C++ code instead.

One of its great benefits is that it will recognize which RGSS version your game is running on without any external help.

I don't know when I will be able to update the GitHub code.

[kyonides]

Modifications Are Unavoidable!?

Well, I didn't expect to update the engine, but, there's always a but, I was trying to play some game that depended on another engine. Since I couldn't stay put, I had to check out whether or not my own engine could handle it. The sad truth was that it couldn't.

What happened there was that they had included weird methods like Graphics.delta, System.platform and System.user_language. I couldn't find any reason why I shouldn't include them as well, leading me to the moment when I simply looked for ways to implement them as well. One of those method simply made me rename an existing module and the other one forced me to include some new SDL2 header file to grab that information from the current OS.

Then another of those strange moments took place. I realized that there were games like Warcraft that simply told you that pressing ANY button  would let you go to the next scene. I already had a method, namely Input.trigger_any?(button1, button2, etc.) that could do something similar but not identical.

 What if I could fully implement it in HiddenChest?

So I took a moment to analyze the Input class in C code and found out it would be extremely easy to add that desired feature!  Obviously, defining the corresponding Ruby binding function for the Input module was a piece of cake!

This means that now we have several new methods:

• Graphics.delta (N microseconds)
  
• System.platform ("Windows" or "Linux")
  
• System.user_language ("en" or "es" or "de" or "fr" or "ja")
  
• Input.trigger_any? (For gamepads, mice and keyboards)
  
• Input.trigger_buttons?(btn1, etc.) (the old Input.trigger_any? behavior)
  

One day I'll be able to update my GitHub code to include all of the latest additions and other changes made to HiddenChest's source code.

[kyonides]

Source Code Updated!

Well, I didn't really add anything visually appealing in this occasion, but I finally updated the GitHub repository as promised!
 The only thing is that I needed to upload it to a different repository because I no longer have access to my old email account. Yeah, it's a big Ooops  indeed!
Unsurprisingly, my new repository is named kyonides/hiddenchest_linux just in case you wanted to know that.

The few updates made to the source code to make it partially compatible with another fork of mkxp have been included by default.

[kyonides]

Source Code Updated Again!

 

This time I focused on replacing several of the popup windows that you would normally see on the vanilla versions of RGSS with game screen wide error messages that happen to also save the screenshot in the local Screenshots directory. How convenient!

I know that it is not as novel as it might have been like 2 or 3 years ago  but I simply had not fully implemented them at the time. They were more like part of the improved code for its Linux only version. It is not that hard to compile the published code on Windows if you have got some experience with that process.

The Story

This is what happened back in the days. I was experimenting with the code to be able to create a separate library or binary source code for Linux. The reason was a complain a Spanish speaking RM user made back then who strongly defended the use of libraries instead of incorporating the code directly into the executable as it happens by default. On Linux that worked perfectly for it is not as demanding as its Windows counterpart.

The problem was that people like him actually wanted to use its features as a complement of vanilla RM.   No wonder why they ended up using another mkxp fork months or years later for their own projects.