BUGMENOT'S PROFILE

author=McBick
[...]is caused from lack of processing power in rpg maker[...]

That, sir, is wrong. (as far as RM2k(3) is concerned)

There is no such thing as a lack of speed there is only a lack of concept.

Lag is mainly caused by 2 things:
A) extensive use of <ShowPicture> event commands
The game has to load the image file from the hard drive. This takes a lot of time.

B) an imperial ton of event updates*
(caused by faulty programming, that's most likely still present in every VXP maker)
EventAmount(Map)** x (ChangeSwitch + ChangeVar + *)/frame = EventUpdates/frame = lag***

*stuff such as <ChangeSwitch>, <ChangeVariable>, <ChangeItem>, <ChangeParty>, <Timer>, <KeyInput>
**each additional EventPage adds roughly 0.5 to the EventAmount
***a value of 100k and above is bad

Solution to A)
People pre-load each and every picture and manipulate them by using the <MovePicture> event command (with DynRPG, pictures with IDs of 1001 and above won't be erased when changing maps).

Solution to B)
AntiLagSwitch
(big algorithms can be flanked by <ChangeSwitch> 1000 = ON at the top and <ChangeSwitch> 1000 = OFF at the bottom to reduce lag)


So here's the question:
Why don't you just use events, that are above hero, on every position of the map, teleport the player below one of those and use <ChangeEventLocation> for NPCs? This would fix the problem of pictures not being bound to map coordinates. And be totally within the range of processing power of anything. Even when updating the fog o' war without pauses.

And also, here's a little something.

Put the MoveEventPointer.ips into the DynPatches folder. The used variable can be changed by pasting the following under the [QuickPatches] section in the DynRPG.ini and changing the number after the #

MEPVar=4AFC06,#3330

So what does this thing do? The patch allows you to assign the Event_ID for a <MoveEvent> command by putting the to-be-moved Event_ID into Var[3330].
1 to 1000 are the events, 10001 = Hero, 10002 = boat, 10003 = ship, 10004 = airship, 10005 = this event

If Var[3330] has a value of zero or below, the event that was assigned by the <MoveEvent> command will be moved instead.


This would make it possible to have your algorithm calculate the x and y coordinates of the concealed tiles and change their CharSets to black tiles (or transparent when visible). It's fairly easy to get the Event_ID from the x and y coordinates:

<> Change Variable: [0021: x] = ...
<> Change Variable: [0022: y] = ...
<> Comment: with coordinates 0,0 in the upper left
<> Change Variable: [0023: Event_ID] = EventsPerRow
<> Comment: let's say there's 20 events in a row, the leftmost event in the 4th row would have the ID = 61
<> Change Variable: [0023: Event_ID] * V[0022]
<> Change Variable: [0023: Event_ID] + V[0021]
<> Change Variable: [0023: Event_ID] + 1
<> Change Variable: [3330: MEPVar] = V[0023]
<> Move Event: Event #0, Frq 8, Pattern: Chg graphic to CharSet_blank #0

Downsides to that would be... you would have to make templates of different sized maps filled with copypasted events that you should never touch. And you would have to copy those templates, create an additional mock-up map (without all those events blocking your view) that you can freely map on. When it's ready, take the selector tool and Ctrl+A the whole map to paste it below the template's copy.

Also your maps can't have more than 10k events on them (size of 100x100). How you would manage to have more than 2000 pictures is beyond me.

Personally, I would love to see someone hit the max.event cap for once.


Or... you could take the lazy route and ask Kazesui to have the LineOfSight-Plugin have a fog o' war mode.

Fixed. And sorry for any inconvenience.

The problem was just the VisuCommands patch. Whoever you are, that uses VisuCommands as well, please replace the old file with the new one: download VisuCommands(fixed)

Also, change the following lines in the DynRPG.ini:
CmdWindowDelta-X=4963DE,#80
CmdWindowFirst-X=4963E7,#0
into:
CmdWindowDelta-X=4963DD,#80
CmdWindowFirst-X=4963E6,#0

And yes, the %xxyy is enough to determine what size the 4x3-frame sprite sheet is going to be. To 'select sprite' the one right next to it requires a similar sized 4x3 template (blue/light-blue) right next to your first one in the CharSet file. Disregard that, it's two across, not one. Disregard that. CEP[+]

The patch just might be applied improperly (that's why you seem confused, as to why it did work in RM2k, but not in 2k3):

make sure you have a DynRPG version of 0.17 or upwards:
download DynRPG

And the appropriate DynLoader for your DynRPG version:
DynLoader for 0.17
DynLoader for 0.20

author=Razzy
15.) bigger character sets. This was done in 2000 so I don't see why 2003 shouldn't be able to.

Sorry, it's not a plugin (seeing as there wasn't one made within the last 12 months, I don't expect any plugins of that sort within the next 6 months)

download CEP(2k3)[+]

Got the same functionality as the 2k one. (And all the same quirks and mishaps)
CharSet's file name must contain the Prefix %xxyy with 1/4 sprite width in xx and 1/4 sprite height in yy.

Credits to Cherry's CharExpandPatch 2k.

Fixed version:
download BreakLoopFix

When using a <BreakCycle> / <BreakLoop> command the script won't jump to the end of the next loop (when using several loops inside of each other) but exit the current loop how it's supposed to.

Well... my gratitude towards Cherry for pointing out my overly complicated second version.