Sep 23 2012, 05:16 PM
Hey all. I wonder, could I removed the old scripts from XP and update them RGSS2 from RPG maker VX or even RGSS3 from VX ACE? Would the program still work?
Also if I did choose to leave all the original scripting in XP would it still be compatible with RGGS2/3?
Sep 24 2012, 02:41 AM
Hmm, I am not an experienced Scripter but I don't think that it would work that way. The database and etc is attached to the RGSS that is used in that software. There are alot of different items in the databases of each engine. I doubt you can work the same database, you'd most likely have to change the databases as well, which would involve complete re-coding...
Why would you want to use VX/A coding in XP?
Sep 25 2012, 10:14 AM
There's been an ongoing discussion over at RMW, but the reality of it is there's really no easy way around it, and none that appears to be worth any amount of time. As Jonnie indicated, the way the program runs and the setup of the events and database rely on the current scripts. You can't simply swap out the scripts and think it will work.
In each maker, new features have been added, and new features have been removed, and they all generally rely on the default scripts that were written in their current language at the time for proper implementation. So anything XP offers that VX does not could potentially cause a feature to become non-existent in XP when switched from RGSS to RGSS2/3. Likewise, any new features that were created in later programs would still not be possible by default once ported over. For example, Ace has the sprite/face generator and shadow pen, as well as the unlimited tileset that offers up to 5 complete tabs for each set. These functions are built into the tools of the program and database. Switching the scripts from RGSS to RGSS3 would not make these features available, because it wouldn't alter the database in any way. And since event commands are laid out differently for each maker, you'd have to account for that as well.
You'd probably have to be an expert scripter and know which scripts will work and which will not, and rewrite a lot of the code so it could be used with the current database. And you may even have to have access to the source code (which violates EB's EULA) in order to make some of the database changes in order to implement features that were introduced in later programs.