Best Practices for Data Editing

[benpark]

I have a few 3D models that I am testing by overwriting backed-up stock files. I am now going to attempt to sort through the interconnected data files, which is a bit complex to keep organized. My first thought is to start a new database, and only enter the vehicle that I am working on and growing it from there. Will the stock files "fill in" the areas that I am not touching?

For example- I have a tank that I am adding.

-I create a new database, and copy all of the files in from an existing database and give that a new name.

-I copy/paste an existing tank in "resources_custom_3d" at the end of the unit list that is existing (with a consecutive number for ID), re-direct the code it to my file names, and adjust any values that don't fit.

-In "units", I copy/paste an existing tank of similar values, and paste as a new, consecutive entry. I cut the Sprite entries at top, and paste in the new 3D links to files in the XML.

-Create a "formations" entry for the unit, as a group with individual entries for any 3D model used in the grouped unit

-Add ammunition, if needed

The other Resource XML's will need be adapted if a different era than the stock game.

Does that cover it? My main question is - Do I need to include the stock code in the XML, or may I just start a new database for just my new unit (so far), and the rest gets filled in from the main database if missing from mine? I would like to grow my database, without the extra stock entries, as that's a large pool of information to tangle with.

[Veitikka]

You mentioned the resources_custom_3d.xml file when talking about a unit list and IDs. Do you mean the units.xml? The former contains model and texture resources and not units.

You can start a database from scratch without any stock data entries in it. One important thing to always have in the units is a pillbox for each Faction Date (MG pillbox ID, "MGPillboxUnitID"). It should be enough to have one faction if you set it to be the default player and opponent faction, and then create a few basic formations for it. The rest can be deleted in the database editor, or in a decent text editor (such as Notepad++).

If it's not clear yet, your custom database is separate from the official database, and when you load it none of the stock data is used.

[benpark]

I do have the new database separated out in my docs. It's a good system. Thanks for making a game so interesting to play, organized (in a quite open file-structure), and open to some tinkering.

I have been looking at the in-game database editor, which I somehow missed in all my map-editor-learning. That seems much better than the Notepad++ method for dealing with adding or adapting new data sets.

I can probably do all of the starting a new database in there, where dependencies may be more clear - It looks helpful. If I can't figure out how to start an all new database there (rather than the manual method), I'll dig around for tutorials. If I can't find any, I'll check back in.