However, the events are where it gets sticky. It is simple enough for rvpacker to change the IDs of any new map created, and to change the reference to that ID number from any child maps. The event scripting portion, especially, presents a difficult problem for rvpacker to overcome. This means that changing the ID number assigned to a map (and, thereby, making it possible to merge 2 maps with the same ID number) becomes very nontrivial. The ID numbers are used to specify the target of a map transition/warp event in event scripting.The ID numbers are used to specify a parent/child relationship between one or more maps.The ID numbers on the map files correspond to ID number entries in MapInfos.yaml (and the corresponding MapInfos.rvdata objects).However, there are several significant problems with this approach: If you look at the map collision problem described above, the way out of this situation might seem obvious: 'Rename Map011.yaml in one of the branches to Map012.yaml, and problem solved. Why rvpacker can't help with map collisions Do not try changing the map ID numbers manually (see the 'Avoiding Map Collisions' workflow, above, and 'Why rvpacker can't help with map collisions', below). Note that this does not apply to Map files. So in order to support adding new scripts with null IDs, like everything else, the magic numbers on scripts are disregarded and a new ID number is forced on the scripts when the rvpacker pack action occurs. The scripts exist in the database with a magic number that I can't recreate, and nothing in the editor (RPG VX Ace anyway) seems to care if the magic number changes. This is mainly handy for adding new scripts to the project without having to open the RPG maker and paste the script in just make the new script file, add its entry in YAML/Scripts.yaml, and the designer will have your script accessible the next time they repack and open the project.Īlso, the rvpacker tool sets the ID of script files to an autoincrementing integer. This will cause the rvpacker pack action to automatically assign them a new ID number at the end of the sequence (e.g., if you have 17 items, the new one becomes ID 18). You can add new elements to the YAML files manually, and leave their 'id:' field set to 'null'. For a better explanation of why rvpacker can't do this for you, read the next section. While this may seem like unnecessary process, it is a reasonable workaround. They can rename them, reorder them, change all of the map attributes (Size, tileset, whatever), without getting in danger of a map collision. By giving the map owner the authority to create the map blocks, the individual developers can work freely in their map blocks. Using this workflow, it doesn't matter what order Developers A and B request their map blocks, or what order the map owner creates their map blocks. The map owner 4 default, blank maps, and names them all 'Request #12346' or something similar for Developer B.He sends a request to the 'map owner', requesting a block of 6 maps. The map owner creates 4 default, blank maps, and names them all 'Request #12345' for Developer A.He sends a request to the 'map owner', requesting a block of 4 maps. It then becomes this person's responsibility to allocate maps in 'blocks', so that people can work on maps in a distributed way without clobbering one another.

You appoint one person in your project to be principally responsible for the map assets. The best way to avoid this that I can see is to use blocks of pre-allocated maps. The merge fails because of the collision on the Map011 file.

Developer A and Developer B attempt to merge their changes.

It also gets saved by the editor as Map011.

Developer B makes a new map, in a different branch.

One thing that rvpacker really can't help you with right now (and, ironically, probably one of the reasons you want it) is map collisions. Now your project can be forked/merged in a much more safe/sane way, and you don't have to have someone bottlenecking the entire process.

Commit everything to version control (ignore the Data directory since you don't need it anymore use.

Run 'rvpacker -action unpack' on the project.

Load up RPG Maker and do whatever you're going to do save the project.

Run 'rvpacker -action pack' on the project to repack it for the RPG Maker tool.

Checkout the project from version control.Just add a few steps to your existing workflow: This is great for teams that are collaborating on an RPG Maker project.

You can trust this to completely reassemble your Data/ directory, so long as the Scripts/ and YAML/ directories remain intact. This will take all of the yaml files in (PROJECT)/YAML and all the scripts in (PROJECT)/Scripts, and repack all of your (PROJECT)/Data/* files. Rvpacker -action pack -project ~/Documents/RPGVXAce/Project1 -project-type ace

Lisa rpg save editor