CHERRY'S PROFILE

Hello, everybody!

I thought you might have a use for this. It's for RM2k v1.07 and RM2k3 v1.08

Normally, if you use "This Event" in a common event, the game will crash ("Erase Event" would do nothing), and if you wanted to move some logic involving "This Event" from a map event into a common event, you couldn't.

This patch will change the behavior so that "This Event" in a common event references the last map event on the call stack. "Erase Event" now works the same - it erases the last map event in the call stack.

Examples, with this patch:
Map Event A calls Common Event C, Common Event C moves "This Event" => Map Event A is moved.
Map Event A calls Common Event C, Common Event C calls "This Event", page 2 => Map Event A, page 2 is called.
Map Event A calls Common Event C, Common Event C uses "Erase Event" => Map Event A is erased.
Map Event A calls Map Event B, Map Event B calls Common Event C, Common Event C moves "This Event" => Map Event B is moved.
Map Event A calls Common Event C, Common Event C calls Common Event D, Common Event D moves "This Event" => Map Event A is moved.

This allows you to finally move all that redundant logic from map events into common events!

Just apply the IPS patch corresponding to your RPG_RT.exe version (using a tool like Lunar IPS) and enjoy. (Or put it in DynPatches if you have DynRPG 0.20.)

Download: http://cherrytree.at/downloads/ctep.zip

Note: If you want to call "This Event" from a common event, the RPG Maker won't let you select pages >1. Just create the "Call Event" line in a map event with enough pages and then copy it over to the common event.

EDIT: Added support for "Erase Event".

@LizardKing: Unfortunately not. Let me explain:

There are simple values which can be changed, that's the case if they are used in an assignment/calculation/comparison, or defining a memory block's size {i]at runtime.

For example, changing the picture limit works because there is a call to memory manager which allocates some memory for the pictures at runtime (where we can change the size), and a few loops iterating over all pictures to draw, update or erase them (where we can just change the value the loops are counting towards).

However, there are also some values which are very very hard to change (i.e. almost impossible with quickpatches or similar means). These are values which impact the size of some objects/memory blocks at compile-time. For example, the battle scene stores some status information about the party. This information is in a fixed-size array in the middle of other data (this means, there is a structure like .....|some other info|some other info|hero 1 data|hero 2 data|hero 3 data|hero 4 data|some other info|some other info|..... just like this in memory). So, in order to add more "slots" for more heros in there, we would need to move all the other data after the hero slots, and update all parts in the code which references their old positions, etc.

You can imagine that the memory is a hand-written list on lined paper. For the pictures, there is a line "look in drawer A-82 for infos about the 20 pictures" and we can just exchange drawer A-82 by a bigger one and strike-through the 20 and replace it by 100. But the battle scene has a list where the information about the party is written directly as part of the list, between other stuff. And there is no space to squeeze additional things in without messing everything up, because accessing those lists works like somebody saying "have a look at my list, line 123, the information is right there".

Actually, it would have been much simpler, better expandable and less buggy to implement it as plugin, by overwriting the normal event drawing mechanism. You know the x, y, transparency, direction, frame, ... so you could just draw a bigger charset. Or even one with more animation. Or whatever.

That's XP.

...then why not just changing the key assignments to the new keys the users configures instead of changing them to F13/whatever and then simulating the keypresses? O_o