On page script eval condition:
Actually you're right. it is better to just refresh that specific event instead of the whole map. And when I looked at the code, you can totally do this by calling this line --> $game_map.events[id].refresh and this will only refresh this specific event, not the entire map.
Right on! I think the way events are checked/refreshed in the current versions might be less than ideal, and with an improvement to that, a far more flexible set of Page Conditions feels like it wouldn't be a noticeable hit to performance. (Even with the way it is now, my experience with Hime's excellent script which does this is that the performance hit wasn't too bad.)
On resource stripper topic:
I don't think they would preload all the resources at once. Doing so would require a "loading screen" as many games do. Or at least a performance hit at the beginning of the game. The default behavior always loads the resource on demand rather than load all of them. Except maybe you're using preload plugins which totally make sense if you thought this way.
Thinking about it more, I think you're right about resources loading - I've worked with clients who use preloaders before, so maybe that's what I was thinking of; in any case I was misunderstanding how things are loaded under the hood.
So the Resource Stripper probably wouldn't improve the game's performance, but it would definitely cut down on the enormous file size that makes it harder to share early versions, wastes the player's HDD space, and forced MV's devs to load an "incomplete" base of RTP assets into new games. Still a valuable tool that should be built in as an option, I think!
If they load a resource that does not exist, I simply replace it with the blank bitmap if it's an image resource. Then I record the file path. if it was the audio, I'd just don't play it (or mute the current audio if it was the BGM). There will be a notification window if the resource is missing, but it won't crash. The players are free to continue. If the one that missing is the enemy battler, they just don't see the enemy. So the players have a chance to save their progress and report it to me if something is missing without losing their progress. Whenever I want to build the demo, I also do this. Strips all the resources I suspected that I didn't use it. And play through my own game to see if something is missing.
Really smart idea!! The blank image to replace it is clever - that way I assume you can manipulate that blank image (such as move/rotate it) without further potential for crashes.
On change actor graphic topic:
As someone who has dynamically changed graphics based on various factors, it's way complicated than it sounds. It is not impossible (I managed to make it work), but wouldn't it just complicate the engine? It is not a basic functionality that should exist, it just an aesthetic pleasure to be able to see the graphic changed by many conditions and factors. Additionally, if they promote the graphic changed based on those conditions. They should also provide the basic RTP resource to do so as "an example" on how to use it. This would cost the production of the RTP asset itself alongside with the feature that is not even important, to begin with. Additionally, I have no idea where "all actors" case would be best used except it is probably only good for "transformation".
I think you might be thinking too ambitiously about its uses. I think I did mention being able to change actor sprites for weapons, etc., and this would be a legitimate use of it, but other uses would include changing the actor graphic to a cursor-style event graphic while on certain maps (e.g. for evented upgrade/skill tree screens), or showing visually that a character is, for example, frozen or dead (while on the map).
These are common things that designers either do in RPG Maker (and often have to struggle around), or want to do but can't (because it's too complex or too risky). The RTPs in the last couple versions of RPG Maker already include Down/Status graphics, so no further work would be needed to provide "examples".
For something like the cursor-style event graphic, of course you could just do this by using the existing Change Actor Graphic event command, but the (very) hard part would be changing the Actor Graphic
back to whatever it was before visiting the evented upgrade screen, if the character already goes through Actor Graphic changes elsewhere in the game and can access this screen (and then return to the normal map) from anywhere. For something like the Down/Status graphics, the usefulness of this Feature should be obvious.
As to where the "All Actors" parameter would be used, one of the most frequent uses would be for the "dead" graphic. Several games, including many
Dragon Warrior games, represent dead party members as a standard Coffin graphic on the party caterpillar. (A game like
Disgaea or
Fire Emblem, where you can recruit members of a class, might benefit from using the "All Actors" parameter too if they're not truly instancing the characters but rather creating a couple hundred blank slates in the database.)
I agree this is a functionality that, on the margin, could be either an addition to the editor or an improvement introduced via a plugin, and that's why I listed it in "Would be Nice" rather than "Game Changers". However, the Features Box feels like a really good, intuitive place to put it, and since this would just be one in a long list of options in the existing Features Box rather than requiring a widget of its own (and since this feature should not cause any additional processing load in moment-to-moment gameplay), I personally feel it would be a very good addition to the editor.
On pixel movement topic:
Having a pixel movement as a toggle is almost like having to have a toggle to switch from a turn-based battle system into a tactical game. It is entirely different. It is not impossible, but if they do, they need to be prepared that every movement in the base code already in pixel movement, which is, again, possible.
However, the collision boxes may not as simple as you thought. For the tile-based movement, it is far too simple to implement.
- You want to move to the left
- The system checks if the tile on the left is passable
- Then the system checks if you collide with any event and if yes, check if it triggers the event
- Turned out it is possible to move.
- You move, your character physical coordinate information changed from (1,1) to (0,1)
- Your actual character display coordinate does not. it stayed at (48,48).
- The system gradually move your character toward (0,48)
- While doing so, you're unable to input the movement (it's locked until you arrive at the destination).
- The event touch/player touch event trigger could happen when both of their physical coordinates happen to meet at the moment when either of them checks that specific coordinate even though their display coordinate does not actually represent their actual position (yet)
Now a simple question to the pixel movement if you still want the collision box would be in the tile-based. If I'm in the coordinate (24,48). Am I belong to (0,1) or am I belong to (1,1)? Or am I misinterpreting your words?
Having used a Pixel Movement script and made several bugfixes to it specifically to correct things like collision detection, I feel I'm qualified to talk on this one. I hear your concern for sure - you are right that it
is pretty complex - but it's only complex from the perspective of the person that develops the functionality. From the designer's and player's perspective, I think it's pretty simple.
With "pixel movement" of 1 pixel or 4 pixels at a time (which represents a tiny fraction of a second), the system can check for collision after each complete movement, without worrying about events "crossing over" each other and not having their collision detected.
At the coordinate (24, 48), assuming 48-px tiles, you would be at the tile (1, 1) - because your character graphic box would be spanning from 24 to 71. Pixels 0-23 would be tile 0, Pixels 24-47 and 48-71 would be tile 1, 72-95 and 96-119 would be tile 2, 120-143 and 144-167 would be tile 3, and so on.
A more complex issue would be, for example, if I am between two different Action Button events, facing them both, which one should trigger? In the script I was using, both triggered and it got really messy. I solved this by sorting each Action Button event that
would trigger by its distance from the player (from event base position to event base position), and only triggering the closest event. Complex from the programmer's point of view, but effortless from the designer's and player's.
It's definitely one of the "reachier" features I proposed, I'll admit.
It would be awesome, though!
On Advanced Event Animation Options topic:
This idea is not bad but putting a number manually would break the convention that RPG Maker tried to preserve for a sake of "user-friendliness". The only number you would need to manually put would just in the set variable value or the damage formula. Everything else most of the time is a dropdown list. Set animation id? dropdown. Show balloon icon? dropdown. Pick the character index? you choose it in WYSIWYG editor.
Now speaking of the character index, requesting to pick specific character index in move route --> change graphic is a feasible idea and would be a total improvement. As for now (in VXAce) you only have an option to choose the whole set in the move route command, not the specific index/pattern like you do when you're choosing the graphic on the event page. And then, you have a weird workaround like "Turn Up/Left/Right/Down" just to choose the cell you want to use.
There are a few other places that we use Numeric Entry in the editor that you may not have thought of already. The Features Box is a big one - many Features such as State Rate and Param Rate require free numeric entry. Almost all of the Cel Option features (such as Cel to Display, Zoom, and Opacity) also require free numeric entry, as does the "Change Maximum" (number of database items) on each Database tab.
I'm of the same mind that you are that point-and-click/dropdown menus are the simplest, most intuitive ways to work within the editor, and I'm glad that most functionality uses it. But lots of core functionality requires number boxes, and I think a feature as flexible and useful as Advanced Event Animation would justify a (still relatively simple) numeric entry field.
