I check time to time and i'm amazed you have continued and improved all the stuff.
I'm only worried about performance, the rpgmaker XP engine is not a tought one.
I'd like to do more but just dont have as much free time as I used to. Trust me, more is planned.
Now, for performance, believe me, more advances can be made, more scripts added, and framerates can actually increase! As an example, one of the packaged scripts is called "Collision Optimizer". Normally, every Event gets updated once per frame. Now lets say you have five Events on the map. When each of those Events tries to move, it scans every Event to check for a collision, thus 5 Events scanning for 5 Events results in 25 total checks. Five events isnt a big deal and shouldnt cause anyone issues as far as performance, but when dealing with high number of Events, because ALL Events are checked, that is one place that performance hits take place. So now lets say instead of just 5 Events, you have 250 Events. Each frame, each Event moves, thus checks ALL Events. As a result, for 250 Events moving, 250 Events are checked for each moving Event, thus, 250 x 250 = 62,500 and that is one place the Framerate really starts to suffer.
The "Collision Optimizer" works like this: when an Event is updated, it checks its position against a Hash, and updates it when it is different. But for checking for Collisions, the Hash allows the moving Event to check Events ONLY at a specific map location. For example, $game_map.events[129] tries to move to X=51, Y=39, the Hash is used to grab Events at that spot. If there are no Events there, then ZERO Events are checked for collisions. If one is there, then one Event is checked. If two Events are at 51, 39, then ONLY those Events are checked. This reduced the number of checks for 250 Events on a Map from 62,500 to less than 250 because not Every event is moving or colliding or next to another Event. This speeded things up a LOT. Now lets bump up the number even higher. Lets say 5000 events. Cant be done without scripts. Without the Collision Optimizer, 5000 x 5000 = 25,000,000. 25 MILLION checks per frame. That destroys framerates and turns games into slideshows. With the CO, only the Events that are moving to a new set of logical coordinates are checked for collisions, thus, number of events scanned drops from 25,000,000 to well less than 5000.
As a result, further performance increases ARE possible, as well as adding more functionality and even more scripts.
There are two more major roadblocks that take a toll on performance. Graphics are the #1 framerate killer. In XP, we dont have access to the core graphics renderer, but can make some adjustments to the module Graphics. If collisions were written inefficiently, you can also imagine that the Graphics module was also written rather inefficiently also.
Last on the list is Ruby itself. Version 1.8.7, which is what XP uses is slow in comparison to newer flavors of Ruby. Fortunately, we can use this to our advantage. A couple of guys over on chaos-project have been working hard for some time on our own version of XP Ace, where we can use the speed and efficiency of both newer versions of RPG Maker and Ruby. We edit with the XP Editor, and the game runs using the VX Ace dll files. And there are some serious performance gains to be had there also, as well as drawbacks. I ran into trouble using our homebrew XP Ace with a couple of scripts. Cloud Altitude didnt like me very much on XPA, and Im pretty sure all the Transitions (lateset release) also dont work due to differences in the Graphics module. So there are ups and downs to our homebrew XP Ace solution.
The last major update I put into the Collection came from rewriting just TWO core methods that handle collision checking. And it enabled Vehicles, Non Player Characters to move around on Event Tiles (like the player can), the Collision Optimizer, Looping Maps for XP, Diagonal Stairs, Ice, Restrict Bush Passage, and Restrict Tile Passage (core for Vehicles). That was the "Modular Passable" script. Its kind of like the SDK for just 'Game_Map passable?' and 'Game_Character passable?' methods. What I wanted to do there was to do it better than the SDK by only releasing ONE version of it, so it had to be absolutely perfect upon release. That was what really killed the SDK for XP was so many versions, and what I did my best to avoid at all costs. Trust me, that was a LOT of work. It doesnt look like much but it took me months to fine tune and perfect Modular Passable. I believe the payoff was well worth the effort since I can continue to write even more scripts, efficiently, that are 100% compatible with the rest of the Modular Passable scripts. I did take it a bit further as I put in some extra code so we could also efficiently and easily add Comment configurations to Events with like two Aliases. That allows us all to write compatible scripts that dont have that dont impact performance that much. So if say M.A. wrote a script that prevents characters from moving on either Map Tiles or Events with a certain terrain tag, he'd put in a Comment that read something like "\no_move_terrain_tag[5,6]". When the Events are doing their thing, his Comment Config gets scanned with the rest of the Comment Config calls so his code shouldnt have to do its own set of scans. Then the new properties get added to Events in a more efficient manner. What else is good is the Comment Configs do NOT have to be the very top line on an Event's Page which preserves Compatability between scripts. What happens there is if someone writes a script that needs the top line of an Event Page to read one thing, and another script also needs to use the top line of an Event Page, then we, as users, would not be able to add features of both scripts to that Event. Its usually one or the other, and again, Modular Passable takes care of that. Comment Configs can take as many lines as they need to, in case a Config needs one or more Comments to configure. Such as Sound Emitters and Super Event Sensor.
In the end, we can still use the XP engine without adverse effects on performance if we write our scripts properly.
Im glad you guys appreciate all the work I put into this thing. Remember tho, Im always looking to expand it even further, with even more Scripts, Art, Tilesets, Characters, and Music, and I will continue to update this beast when time is available to me.
Discord
Light Style