Save-Point

Changing stuff like vsync might not be a wise move most of the time because stuttering, lag or ridiculous speed increases might happen then. I would need to check the other options to see which of them would allow anybody to set their values in game. Window size is possible already and normally people would think it should met their expectations and stop asking for more features.

As far I know the mkxp and HiddenChest license won't stop you from distributing it freely. The only think is that you should include any readme like files included in their original packages, i.e. zip or rar files, and a link to the place where you found it, especially the source code website, available in a near future because the current one is a bit outdated. One of the reasons behind developing mkxp is allowing Linux players to play RM games natively. Since RM developers never planned to offer compatibility with any Linux distro, it can only be considered a plus. Concerning Windows binary executables, we could say that you are just adding some optional components. If you want to make your game as independent as possible to ensure nobody will be going after you, then you would need to rewrite all the scripts available on the script editor. (Even so it is not a must. ) Just take in consideration that if you go commercial, you will need to make some payments to Kadokawa eventually.

mkxp and its forks are nothing but a reimplementation of Ruby based RM engines. It is not reverse engineering, but just the reinvention of the wheel so to say.

Remember mkxp and HiddenChest are just players not editors. The day you get a custom editor (with original features), you would be forced to stop using RM default data or you could eventually get in troubles.

Hi,

(02-14-2019, 07:39 PM)kyonides Wrote: [ -> ]Changing stuff like vsync might not be a wise move most of the time because stuttering, lag or ridiculous speed increases might happen then. I would need to check the other options to see which of them would allow anybody to set their values in game. Window size is possible already and normally people would think it should met their expectations and stop asking for more features.

Actually, nah. What RPG Maker does bad is running the internal systems depending on frames, in case of RPG Maker XP it is 40. So, as you surely know, higher Framerate than 40 makes your game ridiculous faster (animations, movement etc.). Lower Framerate makes it run slow. That is just stupid because with the many configurations out there, running games with differents speed, you can not make sure that they all get the same experience. Another point is the Wait command which ist totally based on frames. All your carefully planned cutscenes and situations where some waiting is involved is going right in the trash because with different framerates on computers your wait commands are totally out of control.
So what i did was change some internal code in the Script Editor at different places so the game and the components like animation, movement etc. are running in the same speed, regardless of the actual framerate. Then you can set the framerate higher (80 for example), makes your game more smooth already with the standard RPG Maker XP 1.8 Ruby System, without fear of speeding up the game. So vsync off or no, no impact on the speed, atleast for me :). But vsync is generating some lag and stuttering in RPG Maker XP, depending on your computer. So reason i ask is to give the player choice. They can decide if they want vsync to eliminate tearing (if it is happening) or not. Would be nice.    

(02-14-2019, 07:39 PM)kyonides Wrote: [ -> ]As far I know the mkxp and HiddenChest license won't stop you from distributing it freely. The only think is that you should include any readme like files included in their original packages, i.e. zip or rar files, and a link to the place where you found it, especially the source code website, available in a near future because the current one is a bit outdated. One of the reasons behind developing mkxp is allowing Linux players to play RM games natively. Since RM developers never planned to offer compatibility with any Linux distro, it can only be considered a plus. Concerning Windows binary executables, we could say that you are just adding some optional components. If you want to make your game as independent as possible to ensure nobody will be going after you, then you would need to rewrite all the scripts available on the script editor. (Even so it is not a must. ) Just take in consideration that if you go commercial, you will need to make some payments to Kadokawa eventually.

Well, that is clear. Maybe we misunderstand each other. I, for example, own RPG Maker XP. So i'm already granted via EULA to distribute my games made with this software free and/or in a commcercial way, even with the RTP Package and edits made by me. Customized scripts do not also stop me in this situation i they are made by me or/and i'm granted to do this by the creator. Games, distributed with mkxp/hiddenchest are still made with RPG Maker Software, but they only run with customized and/or added components, so not hurting RPG Makers official EULA with my understanding. But what about mkxp EULA, or in your case, the hiddenchest EULA? Are you allowing to distribute games in a commercial way using you executables? :)

Thank You!

greetz

As far as I am concerned, both mkxp and HiddenChest should be licensed under the GNU General Public License v2+, especially all mkxp derived works like HiddenChest itself. So google it and you will get your answer.

schM0ggi Wrote:Games, distributed with mkxp/hiddenchest are still made with RPG Maker Software...

That is not quite accurate, my friend. It should say "are still partially made with RPG Maker software" in order to stress out that it is a free implementation of MANY features already available in RPG Maker games (plus a couple of free functions added by Ancurio like the mouse related ones or my custom Ruby classes or modules plus the higher windows resolutions). Obviously, you will need to make the corresponding payments to the RM representative if you sell your games, but I doubt Ancurio will ever ask you to pay him any buck at all. I do not recall the GPL license would ever allow me to sell the HiddenChest player executable as a whole product. Ruby's creator Matz will not ask you to make any payment.

I made a statement about any custom editor because that would certainly change a lot of things here. Since both of us are not working with a custom editor, everything I have said about the player executable should still be valid. You should only worry about most of this stuff the day you get that custom editor.

Even so reading the license mentioned above should tell you whether or not you can sell your game if it includes stuff licensed under the GPL. I think it should still be possible somehow, but I am no expert on licenses so... If it lets you do it, you would have to share all code involved in mkxp or HiddenChest via URLs at least with proper credits included. If you ever mix your own code directly with mkxp's or HiddenChest's, then you will be screwed up for sure.

(02-15-2019, 11:39 AM)kyonides Wrote: [ -> ]As far as I am concerned, both mkxp and HiddenChest should be licensed under the GNU General Public License v2+, especially all mkxp derived works like HiddenChest itself. So google it and you will get your answer.

Just had a quick look, i'm at work at the moment, but as i understand it, my game has to be under GNU GPL when it is distributed (and uses) with some GNU GPL library, executeables etc. I can sell it but have to provide sourcecode (my game, yes) if asked and as soon as someone buys it, he can distribute it for free because it is GNU GPL. This makes it useless to sell something in the first place :D. But maybe i am wrong. Well, you could sell the game without the GNU GPL components and/or provide additional link to download the stuff afterwards with credits etc. That would be a possibilty and the need to share my game under GNU GPL is no more.

(02-15-2019, 11:39 AM)kyonides Wrote: [ -> ]

schM0ggi Wrote:Games, distributed with mkxp/hiddenchest are still made with RPG Maker Software...

That is not quite accurate, my friend. It should say "are still partially made with RPG Maker software" in order to stress out that it is a free implementation of MANY features already available in RPG Maker games (plus a couple of free functions added by Ancurio like the mouse related ones or my custom Ruby classes or modules plus the higher windows resolutions). Obviously, you will need to make the corresponding payments to the RM representative if you sell your games, but I doubt Ancurio will ever ask you to pay him any buck at all. I do not recall the GPL license would ever allow me to sell the HiddenChest player executable as a whole product. Ruby's creator Matz will not ask you to make any payment.

Well, i think it is. See it this way: You create a game with only RPG Maker XP, no custom editor or alike involved (thats what i am talking about). In the creation process the mkxp stuff is not part of it. The game runs standalone with XP's own Library without the need of mkxp. The mkxp components are just used afterwards to make it smoother. That requires, ofcourse, that you do not make your game depending on some Features only provided with the mkxp stuff. But i don's see a problem there.

EDIT:

Found this:

Quote:In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.

That would be my case/question. Sounds for me that distributing and selling the game, usint it but not depending on the mkxp components, with the components is okay and the game itself does not fall under GNU GPL. But i will have a closer look afterwards :D.

greetz

*** Reminder ***
I will not cease to insist on a few points mainly because of any newcomer that might not be aware of mkxp's and HiddenChest's current situation.

As I said earlier, as long as you don't mix code while compiling it, you won't get in troubles. Stuff like a custom database made with GPL stuff would force you to reveal it's source code, no matter if it's C or C++ or Ruby code. I don't think you will so your database code will be safe for now. Wait, Ruby is distributed under the MIT license, so you gotta check it out as well. Make a database with the open version of Qt5 and you will be forced to share it's code, only of you buy the Qt5 license you would be able to keep it for yourself. I don't know what would happen if you use GTK3 instead. Yeah, licencing can be a pain sometimes.

This Bump is all about telling you that I have stopped watching TV shows at night to let you "enjoy the experience" of checking HiddenChest source code and trying to compile the executable yourselves... if you dare!

I know I should have done it some time ago, but I was kind of busy or I needed to keep my mind crafting as many strange things as possible. Now that I have applied to some intensive course of sorts, I found it highly convenient to make sure everybody could find the latest version of your beloved binary executable at any given time. Yeah, it is also some sort of requirement whenever you deal with GPL like licenses.

As I have said some time ago, I have built it on Linux with cmake and g++ and then compiled the 32 and 64 bit Windows versions with cmake and mingw64. Well, you cannot blame me for loving to compile any kind of stuff on my Linux box.

Happy Game Testing, guys!

Err, I guess people like Melana will find it curious that I am posting a new reply here.   Well, I have got my reasons. This dark morning has witnessed something interesting, I have upgraded HiddenChest's Ruby version to 2.6.1! I do believe it is a good one and I hope your game projects end up proving my point later on. From now on you should use the x64-msvcrt-ruby260.dll instead of the old one if you are developing your game on a 64 bit OS.  Actually I also uploaded a Linux binary file I could test on Kubuntu without any issues.

As a tiny, little, minimal surprise I have included an easter egg as well! Nah, it is not such a thing! To be honest with you, guys, it is another little scripting tool. It is called the Scripts module and its purpose is to store script names or symbols in an array to let you take control over what scripts you have included in your game project. Normally you would not feel the need to keep such a feature. Even so whenever you use a Constant to store a value like a boolean testing for a defined Constant or method, RGSS might not find it or will tell you it is not there just because it has not been loaded. It could happen if a script is placed below the other one, even if there is not supposed to be a specifc order to make them work together. In such cases you could use the Scripts module methods to make sure RGSS will always be right about another script's good or evil presence. It is way better than using a $global variable for the same purposes.


Scripts[:script_name] = []
or if it depends on other scripts
Scripts[:script_name] = [:other_script1, :other_script2]
It lets you store the script name or symbol. You can place it anywhere in your script editor except below the Main script.

Scripts[:script_name]
Returns all of its dependencies as an array.

print Scripts.names
You print all of the script names at once.

print Scripts.dependencies
You print all of the script names at once.

Scripts.include?(:script_name)
You double check if the script name has been included. It should be especially useful as part of any if statement (a condition preceded by an if keyword).

OK, I admit it. I forgot to make the new Scripts module scripting tool available for all versions of RGSS and original games. You see, it was setup as if only XP could take advantage of it. Gladly, I noticed it early this morning and fixed it in no time... But I also changed its code!

Now the Scripts module handles not an array but a hash. Why on Earth did I do that? Err, that is because I felt a hash would let you list a script's dependencies as an array. That will allow you to come up with interesting methods to verify you did not skip anything. Hopefully...

OK, it's not like somebody was after HiddenChest at all it just happens that the official Ruby developers' team posted a warning and two security fixes on its official website a couple of days ago.  In my humble opinion I can't say it's something we should really care about, still, I decided I wanted to offer the latest version of Ruby, namely version 2.6.2, to you from now on. Sadly, I could only grab it for my Linux OS so you gotta wait a bit to get the Windows version of it. Even so the bugs were rubygems only related and I haven't offered any custom rubygem so...

Even so you can try the latest compiled binary for 64 bit OS's, it's now divided in two ZIP files. One includes normal player executables, on the other hand the hiddenchestwin64_ruby26_console.zip file includes the executable that opens a command window aka terminal window or shell as well a la VX ACE but it doesn't depend on any specific RM setup.  What's new there? Well, it happens that I have included a binary file that will let you play games at a higher resolution like 1680*1050 px. That's impressive, don't you think?

Welp. Interest peaked. I'm going to try this out.

edit: Wow I don't know how to get this running right.... @_@