Workflow to store missions in git ?

[bswift]

So .miz files are basically compressed archives.

 

Is there a setting somewhere to have the unarchived structure remain? I'm not sure if storing these in git makes sense - if a buddy and I make mods to these will the diffs make any sense? Lua files seem like it'd be easy to mangle it.

 

Is the best option to just.... save file copies with a different name?

[Rudel_chw]

Is the best option to just.... save file copies with a different name?

 

I keep my saved games\dcs\missions folder on the cloud, where I have automatic versioning (I use MS OneDrive, but Dropbox and Google Drive are similar)

 

[davidp57]

https://veaf.github.io/VEAF-Mission-Creation-Tools/

[Pikey]

So .miz files are basically compressed archives.

 

Is there a setting somewhere to have the unarchived structure remain? I'm not sure if storing these in git makes sense - if a buddy and I make mods to these will the diffs make any sense? Lua files seem like it'd be easy to mangle it.

 

Is the best option to just.... save file copies with a different name?

 

 

Depends on the storage mechanism. For Google Drive, it synched and would retain previous versions without decompressing, but only make available these fo rhte account owner. However I see most serious people use Git and assemble the mission from its components manually. Seems a bit complex, I do not use that mechanism, but plenty do.

[davidp57]

Actually, the problem with cooperative editing is that, each time you save the mission in the DCS editor, the lua files inside the .miz get shuffled (lines change their order, ids change, etc.)

That's why we introduced a normalizer in our workflow.

Then, once the mission is normalized, you can save it as a different name, copy it to a cloud, backup it, or store it on a version control system such as git ; name your poison ;)

[Pikey]

Actually, the problem with cooperative editing is that, each time you save the mission in the DCS editor, the lua files inside the .miz get shuffled (lines change their order, ids change, etc.)

That's why we introduced a normalizer in our workflow.

Then, once the mission is normalized, you can save it as a different name, copy it to a cloud, backup it, or store it on a version control system such as git ; name your poison ;)

Out of interest, which ones get changed? The mission file is an indexed table, not something that generally changes. Something else?

[davidp57]

Actually, the mission file is one of the files that gets modified when saving in DCS editor. The data in the table is not always sorted in the same way, therefore it's difficult to diff correctly from one update to the next.

 

 

Our normalizer sorts the data arbitrarily before saving it in the lua file.

[Targanon]

just out of interest what is a normalizer ? how does it work?

[davidp57]

Hi Targanon,

 

The mission file (.miz) written by DCS mission editor is actually a ZIP archive containing lua files (and more).

The main lua file is aptly named mission and contains a huge lua table describing all the objects in the mission.

 

Unfortunately, LUA tables have no inherent order; therefore each time even a small modification happens in the editor, the mission file is shuffled randomly, making it almost impossible to see what was actually changed in the mission.

 

This process of generating a report showing the difference between two versions of a file is very important in version control. This shuffling makes merging work from different sources impossible.

 

We at VEAF have developped a set of tools, including a script that sorts the lua table in the mission file according to arbitrary rules.

 

This way, when something is changed in the editor, the (sorted) file can be compared with the (sorted) previous version and it is easy to see what has changed.

 

You can read more about this here.

[Worrazen]

Maybe there'll be a brand new mission file format with the new Mission Editor update.

 

Also I'm not fond of extension-less filenames :P Even tho it's just a label, I went "yuck" when I first saw that on linux, never liked it ever since.

[MeerCaT]

There's a lot of value in providing concise but descriptive comments every time you do a source control commit/check-in.

...And of course committing often!

Concerned about committing work-in-progress, breaking changes? That's why you should be working on a separate branch, so as not to affect the main trunk until your 'feature' is complete and tested.

 

It becomes a lot less necessary to analyse file deltas/diffs if the commit history contains meaningful comments.

 

Parallel development by several people on the same file entirely relies upon the ability of the source control software being able to 'merge' the changes.

The 'miz' files are binary files and as such cannot be merged.

No merging means no parallel development on that file.

 

Of course a huge amount of effort (arguably the majority) is likely to be in your custom LUA script(s) rather than the mission file itself.

Being plain text files these are perfect candidates for parallel development.

 

If not already, store your LUA scripts as separate entities within source control, rather than just the 'binary' pre-compiled MIZ file containing the entire project bundled up together.

 

 

UPDATE: oh and if you and your buddy really do need to both be editing the MIZ file, you'll have to come to some arrangement regarding 'checking-out'/locking/reserving the file so that only one of you ever has permission/ability to be touching it at any given time. Only once the edit is complete can it be opened up again.

Edited March 5, 2020 by MeerCaT