Can the scripting system be easier?

[Tsukihime]

I saw some feedback for RMVXA suggesting that the scripting system should be "super easy" compared to what it basically is right now.


Now, as a scripter, I am probably biased because I know how to write scripts.


Perhaps if scripting was more like Scratch, would that be easier?


Oh but then again Scratch looks just like...our eventing system! And there are a lot of things that you can do with scripts, that you likely would not want to reproduce with events.


So can the scripting system be made easier?

 

[Ultim]

No harm if RGSS4 was a lot easier.It'll make learning scripting easier and thus making more people able to make their own scripts.So the Script Requests forum will be deserted .But Scratch...Lolwut dude...A 3 Years Old child can make the cat dance.So...

 

[Bastrophian]

I wouldn't mind if RGSS4 were easier, but id still want to learn to script with more complicated scripting languages.....maybe its not for me to decide, but for some people it might be a pretty bad thing. Its not good to hold peoples hands to much, or they wont ever learn anything.  

 

[Zoltor]

No harm if RGSS4 was a lot easier.It'll make learning scripting easier and thus making more people able to make their own scripts.So the Script Requests forum will be deserted .But Scratch...Lolwut dude...A 3 Years Old child can make the cat dance.So...

People seem to be over looking something, RGSS 3 is already insanely simplified as is(punctuation char are kept to a min, which make RGSS 3 a hell of a lot easier to learn, then other programming languages), any more so, and you'll start to lose functionality.

If anything revolving around scripting that needs fixing, It's the utterly usely defualt debugging system. I'm pretty sure when the system finds a error, It's only using the script before the error occurred to figure out what's wrong. This ofcourse means the suggestions the debugging system gives you, is nearly always wrong/makes no sense at all. It should be using both the script before the error, and after the error, to figure out what the error is.

 

[Liak]

For the next RPG Maker, I would like the eventing and the scripting system to become one, basically. I don't know how to do that, but there should be a way to do very expert stuff with the eventing system if you want to. I mean, there is the option to include script lines in some of the event commands, but I would like to see that expanded a lot and make the things to reference there easier to remember. I mean, term-wise.

 

[Tsukihime]

For the next RPG Maker, I would like the eventing and the scripting system to become one, basically. I don't know how to do that, but there should be a way to do very expert stuff with the eventing system if you want to. I mean, there is the option to include script lines in some of the event commands, but I would like to see that expanded a lot and make the things to reference there easier to remember. I mean, term-wise.

I like the way Unity handles scripting.


You can assign scripts to different objects. The same script can be assigned to multiple objects if they should all behave in a similar way.


Script calls are ok, but they are not very flexible by default: you have a limit of 6 lines basically. I wrote this script to address that issue by simply interpreting multiple script calls as a single large script call.


If you think of how Unity does it, you basically write a script once, and then re-use it on multiple objects. Can this be replicated using common events? Somewhat. If your script call was simply to check a few things or make a few moves around, then you could easily move your script calls into a common event and then have each event call the common event.


Unity's scripting approach allows you to bind custom attributes to objects.


This is not much different from the way we do it now using comments to create arbitrary tags that our scripts read and figure out what to do.


So, you can combine scripting and eventing in many ways already.

 

[whitesphere]

There's a tricky line between making a script language too simple and costing developers functionality.   Easier to use generally means the scripting language has fewer options available. 

I think the biggest advantage VX Ace has is scripting.  Now, granted, RPG Maker is extremely easy to use.  To get there, the default engine has limitations on what you can do.  These limitations can be as simple as "There is no straightforward way to represent this series of steps in the GUI"  But, in any event, the scripting allows developers to overcome a lot of those built-in limitations, at the cost of added complexity.

I do like Unity's idea of being able to associate a script with an object or group of objects, visually.  Ideally, the GUI would be basically what it is today, but any object on the map or in the database can have a script tagged to it.  Said script will execute when the player interacts with the object, or when another object calls it.

This would be very useful for, say, Event conditions, where today there are 6 pre-set conditions.  Adding a 7th which said "Script (returns true)" would be nice.  Of course I think the latter would be fairly simple to add, unlike the "rework the entire GUI to add the ability to tag scripts to anything in the database or on the map."

 

[BoluBolu]

It's just my opinion I don't mean to offend anyone, sorry if I offended you,
RGSS3 is already easy, if ones really study it seriously, I believe it's not more than 3 months for someone to understand most of RGSS3 library outside head. Me for example, I just learning RGSS3 since this end of May and now I have create around 40+ scripts. I don't mean to bragging myself, just want to emphasize that RGSS3 is already easy, although there's still a lot more for me to learn, but really, anyone can do scripting if he/she really study it seriously. Basically if you can script in RGSS3 It's not something to be greatly proud of, to be able to script in RGSS3 you just need to learn the basic of Ruby and learn RGSS3 library, you don't really need to go far deep in Ruby, no need to go until exception(although this will come in handy if you know how to handle this) or catch throw, memorized all of the methods, built-in module, and etc(But as I said more knowledge will come handy). Moreover Ruby languange is very easy. For you who think that Ruby is hard, wait until you try C++ languange, I'd love to see your reaction.
Again sorry if I offended someone.

 

 

[Zoltor]

It's just my opinion I don't mean to offend anyone, sorry if I offended you,

RGSS3 is already easy, if ones really study it seriously, I believe it's not more than 3 months for someone to understand most of RGSS3 library outside head. Me for example, I just learning RGSS3 since this end of May and now I have create around 40+ scripts. I don't mean to bragging myself, just want to emphasize that RGSS3 is already easy, although there's still a lot more for me to learn, but really, anyone can do scripting if he/she really study it seriously. Basically if you can script in RGSS3 It's not something to be greatly proud of, to be able to script in RGSS3 you just need to learn the basic of Ruby and learn RGSS3 library, you don't really need to go far deep in Ruby, no need to go until exception(although this will come in handy if you know how to handle this) or catch throw, memorized all of the methods, built-in module, and etc(But as I said more knowledge will come handy). Moreover Ruby languange is very easy. For you who think that Ruby is hard, wait until you try C++ languange, I'd love to see your reaction.

Again sorry if I offended someone.

Lol I know, if people only really knew what C++ was like, and compared it with RGSS3.

I spent most of 4 years trying to learn C++, and didn't get far. I was able to understant what I was reading just fine, and I was able to do map coding(which Isn't hard at all, since It's the most repetitive type of coding ever), but not much more.

However on the upside, dealing with that BS makes it insanely easy to pick RGSS3 up lol(seriously the difference in difficulty is laughable, the difference is so great, yet structure wise, they are very similar).

 

[Euphoria]

Personally, I think it's absolutely fine the way it is. As a scripter myself, the only "hard" part of scripting was understanding how to access and fully utilize hashes (which are wonderful, now that I have learned ). Some commands like .each .select .find .whatever can get a bit confusing for me as to what they do (even with the help file(and .each .select .find are easy, just examples of the commands I'm talking about)) 

The help file could be improved a whole lot, that would help out some people who are trying to get into scripting RGSS3. I mean, there aren't even examples for some of the difficult commands/methods, just a mediocre explanation of what it does.

But as a whole, RGSS3 seems fine to me it's easy enough to learn and hard enough to offer a fun challenge at times. A perfect mix.

As for script calls and how scripts are used in game/from events, I don't have much to say, but I think it could be improved in ways.

 

It's just my opinion I don't mean to offend anyone, sorry if I offended you,
RGSS3 is already easy, if ones really study it seriously, I believe it's not more than 3 months for someone to understand most of RGSS3 library outside head. Me for example, I just learning RGSS3 since this end of May and now I have create around 40+ scripts. I don't mean to bragging myself, just want to emphasize that RGSS3 is already easy, although there's still a lot more for me to learn, but really, anyone can do scripting if he/she really study it seriously. Basically if you can script in RGSS3 It's not something to be greatly proud of, to be able to script in RGSS3 you just need to learn the basic of Ruby and learn RGSS3 library, you don't really need to go far deep in Ruby, no need to go until exception(although this will come in handy if you know how to handle this) or catch throw, memorized all of the methods, built-in module, and etc(But as I said more knowledge will come handy). Moreover Ruby languange is very easy. For you who think that Ruby is hard, wait until you try C++ languange, I'd love to see your reaction.
Again sorry if I offended someone.

 

I learned Ruby first, and have learned a little more than the very basics of C++ and honestly, C++ doesn't seem all that hard either, but maybe I just have'nt gotten far enough into it. I will admit that Ruby/RGSS3 has a much more user-friendly learning curve though. And I agree RGSS3 is pretty damn easy. I started learning about 6 months ago, tried for a month, gave up, and just came back to it about 2 weeks ago, and in those 2 weeks I've learned SO much more about Ruby/RGSS3 that it is ridiculous. I did have some guidance and help debugging a few things, but the last 2 weeks have shown a complete change in my scripting abilities (not saying they are great now, but much much better than before). This was simply due to trying harder and pushing myself to new things and experimenting a bit.

Now I'm rambling... I seem to be doing that a lot today... sorry!

I'll just end with this:

If it can be made easier without limiting what it can do, then great! Go for it! But just because some people can't grasp it (face it, some people NEVER will) doesn't mean they should dumb it down at the cost of functionality.

 

[Zoltor]

Personally, I think it's absolutely fine the way it is. As a scripter myself, the only "hard" part of scripting was understanding how to access and fully utilize hashes (which are wonderful, now that I have learned ). Some commands like .each .select .find .whatever can get a bit confusing for me as to what they do (even with the help file(and .each .select .find are easy, just examples of the commands I'm talking about)) 

The help file could be improved a whole lot, that would help out some people who are trying to get into scripting RGSS3. I mean, there aren't even examples for some of the difficult commands/methods, just a mediocre explanation of what it does.

But as a whole, RGSS3 seems fine to me it's easy enough to learn and hard enough to offer a fun challenge at times. A perfect mix.

As for script calls and how scripts are used in game/from events, I don't have much to say, but I think it could be improved in ways.

 

 

I learned Ruby first, and have learned a little more than the very basics of C++ and honestly, C++ doesn't seem all that hard either, but maybe I just have'nt gotten far enough into it. I will admit that Ruby/RGSS3 has a much more user-friendly learning curve though. And I agree RGSS3 is pretty damn easy. I started learning about 6 months ago, tried for a month, gave up, and just came back to it about 2 weeks ago, and in those 2 weeks I've learned SO much more about Ruby/RGSS3 that it is ridiculous. I did have some guidance and help debugging a few things, but the last 2 weeks have shown a complete change in my scripting abilities (not saying they are great now, but much much better than before). This was simply due to trying harder and pushing myself to new things and experimenting a bit.

Now I'm rambling... I seem to be doing that a lot today... sorry!

I'll just end with this:

If it can be made easier without limiting what it can do, then great! Go for it! But just because some people can't grasp it (face it, some people NEVER will) doesn't mean they should dumb it down at the cost of functionality.

I find the help file, and any language  library manuals in general, to be borderline useless. They're made by computer nerds who locked them selves up in a lab somewhere, never to see the light of day ever again, and frankly, such people haven't got a damn clue as to how to communitcate to actual humans, so how can you expect them to make good help files/manuals.

To make matters worse, every single thing in such manuals/help files are in its own section, so that doesn't help you when it comes to actually learning how to make something via code(all they tell you is the geeked out term, that sort of describes what a key word in the language means, that's it.

The easiest way to learn a coding language, is by actually looking through "finished" scripts/codes.

I hate coding language manuals/help files with a passion.

 

[Andar]

It should be noted that the people asking for a "simpler script system" are not programmers and don't know how to make it simpler, and the people who are programmers consider it already as simple as possible. Most probably this is because "programming" needs a special set of logical skills, and unless you have them (from whereever), you simply can't even understand the problems behind this.


I'll try to explain it with a comparison for the non-programmers:


You basically need to bridge a very wide chasm, with the computer on one side who only understands "High-resistance" and "no-resistance" as logic values, and the human on the other side who says "I want a picture of a person move around".


The programming languages are the method to bridge this chasm - but there is no programming language that can bridge the entire chasm (then we would be able to create true AIs), they all stop at part of that length.


Some programming languages like C++ are nearer to the computer side (let's say 33% - if you think C++ is complex to learn, you shouldn't try Assembler code or Microcode, those are even more toward the computer side), and other languages like Ruby and RGSS are nearer to the human side (let's say 80% or so). The rest of that "distance" has to be crossed by the programmer (or scripter), and that can only be done by learning how to structure your human thoughts into a computer's logic structures.


Now why are there different programming languages at different "distances"? After all, theoretically everyone would like to be able to program with as minimum effort as possible?


The problem is that the larger the distance to be bridged by the programming language, the larger the problems for that language become. Some of those problems result in performance issues - most operating systems today (like Windows) are programmed in C++ or similiar languages, because the nearer to the computer side a language sits, the faster it can be. You got proof of that whenever an RM game lags even on todays computers: all languages that are nearer to the human side are usually slow.


But speed is not the only problem - the computer by itself doesn't even know mathematical operations. It only looks that way because mathematical operations are the easiest to translate into the resistance-logic of the microcode network. The more complex an operation you want the computer to perform, the more problems can arise from the translations. And the people writing those "translators" (the programs that turn the programming language into computer readable structures) can only put in a limited time.


That is the reason why all those limits on higher structures appear - and the simpler you want the language (more to the human side than now), the more restrictions will appear in its use.


Best example are the event conditions for variables: each condition only checks "variable is X or above" - there is no direct way to check a variable for an exact value or if it's lower. If you want to do that by eventing, you need to place your logic with multiple event pages.


Do you think Enterbrain placed that limitation because they wanted to make things difficult for their customers? of course not. But there are limits between "make eventing easier for the user" and "translate the event code into something computer readable" and "finish the program with X work hours, we have to sell it by Year Z".


As of now, scripting in RM (which is really programming, nothing less) requires you to learn the beginnings of how to think like a computer works, and that is not something that comes easy to a lot of people. And even those who can learn it relativly easy, still need months to learn their first programming language.


But making scripts simpler would also mean making them more like the eventing system - and you can check the event limitations rather easily, that's why a lot of you wants to use scripts.


I can think of several ways to make scripting easier for programmers (like better data structures and transfer APIs from the editor to the script engine), but all those improvements would still be an alien language to those people who can't understand programming languages.


And any try to make scripting more "easier" like eventing would create limitations similiar to eventing - and then the same people who are now asking for an "easier" scripting system would probably claim that those changes were bad.


Similiar to people now asking for the mapping system of XP when the mapping system of VX and Ace is "easier" (but also more restricting)...

 

[Euphoria]

I find the help file, and any language  library manuals in general, to be borderline useless. They're made by computer nerds who locked them selves up in a lab somewhere, never to see the light of day ever again, and frankly, such people haven't got a damn clue as to how to communitcate to actual humans, so how can you expect them to make good help files/manuals.

To make matters worse, every single thing in such manuals/help files are in its own section, so that doesn't help you when it comes to actually learning how to make something via code(all they tell you is the geeked out term, that sort of describes what a key word in the language means, that's it.

The easiest way to learn a coding language, is by actually looking through "finished" scripts/codes.

I hate coding language manuals/help files with a passion.

Yeah, I can't say I hate the help file as much as you do

But I agree it can be pretty useless at times. I mean it has the methods and codes I might need, but I usually have to google one that I don't understand because the help file description is ****, and regular people online can explain it WAY better. Not to mention the lack of examples for some of the methods, even some of the more difficult methods are without examples, and examples are really helpful (to me at least) in understanding how to use a method/code.

But yeah, like you said, looking through finished codes can teach you a lot (if you know the basics, and how to read the code already).

If anything I say leave scripting alone, or allow more advanced methods to be used(optionally). But make some damn tutorials or a non-worthless help file to go with the program, since RGSS3 is VX Ace specific and people might want to learn RGSS3 (closest thing I've found is DP3's video tutorials, it was great of him to make those). Shouldn't they have included some better instructions on how to fully utilize it rather than just say "It uses RGSS3 and that's basically Ruby, good luck!"

 

[Zoltor]

Yeah, I can't say I hate the help file as much as you do

But I agree it can be pretty useless at times. I mean it has the methods and codes I might need, but I usually have to google one that I don't understand because the help file description is ****, and regular people online can explain it WAY better. Not to mention the lack of examples for some of the methods, even some of the more difficult methods are without examples, and examples are really helpful (to me at least) in understanding how to use a method/code.

Been there, done that lol.

I know, It's bad enough every single keyword, object or whatnot, is listed separately/scattered all over the place, but why can't they atleast show examples of a completed segment of code, where X is being used, to show how such would be used?

 

[Euphoria]

They only use the foobar bull **** for every example -_- they really should give a real, useful, example from their default codes, explain how it's coded, what it does, and why, and then point to that piece of code in the script editor.

Edit: And I would definitely not complain if they found a better way to organize the help file...

 

[Venka]

As far as the help file.. it's ok for RGSS specific info. I prefer to use this site:

http://www.ruby-doc.org/

for all other ruby info. There's LOADS of info there and some examples or most everything. If they examples they give don't make enough sense to me, then I usually find some related topic on http://stackoverflow.com.

Ruby isn't hard to program in, the hard part was as Andar was saying... trying to come around to the correct way of seeing how it works. Once you understand the basic concepts of programming, the rest falls into place and then it's just a matter  or learning the ways to make the code work for what you want to do.

 

[??????]

I think that THE MOST useful thing they could implement into the next RPG maker would be to simply include all those 'hidden modules && classes', such as the Input module. This would cause alot of scriptwriters to sleep easier at night (imo ofc)

 

[bgillisp]

Agreed. That has been my biggest problem with learning scripting so far. Doesn't help that some have names that are not clear what the variable does (or is).

 

[Napoleon]

I can't speak for non-programmers, but creating a decent game with no programming knowledge at all and low-budget is a myth. The same goes for RPG Maker. It has never been done. A pure event-coded game engine is just not doable. It will either fail because of performance issues or because of missing features. RPG Maker seems to be somewhere in between.

Also in the end a large event-system is harder to learn than just learning to script imo. For those of you who worked with big enterprise development environments probably know that they first had to spent a lot of time just learning where all the buttons and options are located. Scripting from scratch is sometimes just faster and easier.

I find RGSS incredibly bad for experienced programmers/scripters. Debugging is a real pain and no compiler. So many prints and backtraces like "p caller[3]" and such. Also no compiler directives that remove code for the release version and such. I don't like it and I don't call it simple either. Debugging in RGSS can be extremely time consuming and highly frustrating and the error could be a simple upper-case character resulting in a nil value 20+ calls later before the crash. Simple? No!

The second problem is that some of the closed internal code is kinda... weird and sometimes not documented at all. Like some of the accessors like the Bitmap.font accessor. It's really terribly bad and causes undocumented side-effects. Simple? No! Frustrating? Yes! Just a huge trial and error feast. I had that problem recently here: http://forums.rpgmakerweb.com/index.php?/topic/30140-again-dispose-problems/

The script-list is a huge mess once you get over a 100 custom scripts. No tree-architecture, no extra area for a separate header or file version, color coding, nothing. Just nothing... It's really bare and clearly not intended for serious scripters. Simple? Yes (if you don't count all the scripts you have to create to make up for it). Messy? Yes!

Some of the commands are very unclear:

#-------------------------------------------------------------------------- # * Set Move Route #-------------------------------------------------------------------------- def command_205 $game_map.refresh if $game_map.need_refresh character = get_character(@params[0]) if character character.force_move_route(@params[1]) Fiber.yield while character.move_route_forcing if @params[1].wait end endOkay I know what it does. But what parameters does it take and what are it's types? Right... You don't know! Have fun digging into the 'sub-method-calls' all the way down to figure it all out. Simple? Maybe. Time consuming? Yes! Documented? No!

And this feature bugs me the most: When a script crashes, I get some interpreter error and the focus in the script editor is lost and it redirects me to the Game_Interpreter, which is obviously not the cause of the crash. Then I have to scroll down through a lot of scripts to find the script where I left off. Repeat this 25x before I find the bug. 25x of useless scrolling and searching for my own script... sigh... This engine is so not meant for huge or totally customized projects... Frustrating? Very!

Note: I now use notetags like [busy] and then ctrl+shift+f that to get back to my own script relatively fast. Still sucks though.

And no pointer-arithmetic in Ruby... I needed it so many times already...

I can't change the database without hacking/scripting something to edit it first. You need to download something like Tsukihime's database script. But why is it not build-in? So often did I need an extra column or lookup table... Simple? Absolutely not! They tried to make it simple by hiding it from the user, which only works for non-scripters. You might be better off with your own external database in an RPG Maker Project or such.

But I do find the help-file very very useful. Easy to search, has all the parameters listed and such. Just not complete. I have absolutely no problem navigating it. Simple? Yes! Much better than the MSDN for example. But no examples, and again, rather incomplete.

And the efficiency of some of the default internal code for large maps is absolutely horrible. You'd expect some kind of build-in quad-tree algorithm or something to organize events on a map. But nope. Just a simple vertical + horizontal check... Sure it works for 10-200 events on a mediocre PC. But that doesn't work when you have 400-900 events on a map. Sprites in this game are really inefficient. Get ready to rewrite! Simple? No! Time consuming? Yes! (took us nearly 3 months to 'fix' that, and no, splitting it into smaller maps = just ugly). It has nothing to do with the programming language. Some of the internal and open-source code of RPG Maker are simply bad and not efficient for large maps/projects.

I also expected control over when a sprite is redrawn by the GPU and such. But we have no control over those things. The same goes for Windows. The game just redraws as it sees fit using the z-indices or something. This can lead to highly inefficient scenarios. In XNA we had to redraw everything (by default) every frame and it gave us a lot of power because we could simply decide not to draw the other 900 inactive events nor update them with just like 10-if-checks per frame. Here we can't. Simple? Yes, although be it by removing some of the scripters power at the cost of performance... And if you have to work around it, it is no longer simple but instead much harder than it needs to be...

We can't add new buttons to the editor which lead to me creating a lot of external stuff and binary tables to circumvent the region limit (1 per tile) and to achieve performance increases. Simple? No!

No build-in version control system, no support for team-development, etc. Simple? No! Duplicating the same project and copy-pasting everything back into one project again all the time (from the other team members) is very error-prone! It feels like the 90's.

And I could go on forever... Bottom line: "RPG Maker is not meant for large and complicated custom projects (or teams) and seems to be aiming mostly at the non-commercial use of it and prototyping".

If they want to make things easier they can start by making ALL of the code open source. Then we may also get HD resolution without FPS drops.

 

[cremnophobia]

I saw some feedback for RMVXA suggesting that the scripting system should be "super easy" compared to what it basically is right now.

Now, as a scripter, I am probably biased because I know how to write scripts.

Perhaps if scripting was more like Scratch, would that be easier?

Oh but then again Scratch looks just like...our eventing system! And there are a lot of things that you can do with scripts, that you likely would not want to reproduce with events.

So can the scripting system be made easier?

It can. But should it? Ruby is a complex language. There are plenty of alternatives that are simpler, but also aren't as simple as Scratch. But I've already mentioned somewhere else that I'm not a fan of switching the language. And you make a very good point in mentioning the event commands!

I think many of those people are not even able to create more advanced events (but I don't have good proof for that statement). Just look at some RPG Maker 200x games! At least until a few years ago, there weren't as many patches or DynRPG plugins. Making an event-based menu or battle system isn't something you should do with a RGSS-based RPG Maker, but stuff like enjoyable mini-games or cut-scenes. Maybe an interaction menu. You can do that with Ruby, too, but they are possible to make just by using event commands.

There are other people, of course. For example, some of them just don't like Ruby, or are an event pro and just don't get programming (in general). That's fine, too. But I believe eventing is almost as easy as it gets.

I also believe the non-Ruby part of the RPG Maker like the database or events can and perhaps even should be improved. VX and Ace already did that (well, mapping is another discussion). Remember XP? I don't know the details anymore, but some event commands of RM 200x are still missing. I'd like to see being able to add own commands or quick events. Somehow. I also like Liaks comment. Yeah, none of these things will make it easier—see the last sentence of the previous paragraph. If someone here has an idea to do that, please share.

The help file could be improved a whole lot, that would help out some people who are trying to get into scripting RGSS3. I mean, there aren't even examples for some of the difficult commands/methods, just a mediocre explanation of what it does.

Why don't people write one? It's also kinda surprising that there isn't a good English/International RPG Maker wiki.

It's not that hard: start a new thread and preferably setup a repository (e.g. on GitHub or BitBucket). Then create a bunch of files that define RGSS classes/modules and (empty) methods, and use either RDoc or yard to document them. Almost everybody (with some Ruby knowledge) can contribute an example or write/fix/reword sentences! Of course, the official documentation should be improved too, but I doubt that's gonna happen.

By the way, it'd be nice if the contents of the help files (as HTML and CSS are already used by them) could be uploaded to this website. Being able to (reliable) link to a specific help file page would be great and some people dislike being told to RTFM (even if they really should do that). I think linking to the relevant text doesn't come off as condescending as mentioning the help file.

I think that THE MOST useful thing they could implement into the next RPG maker would be to simply include all those 'hidden modules && classes', such as the Input module. This would cause alot of scriptwriters to sleep easier at night (imo ofc)

You're basically proposing to open source the (original) RGSS. (Besides the high unlikeliness of that ever happening) Why do you think that this makes it easier for script writers? Then they have to learn another language (C++) and writing portable scripts will be more difficult if changing fundamental classes is possible.