Add a new Python script just for compiling pbos in the Packed/Missions folder.

[Qerbas]

For testing purposes it's heavy handed to have to compile all of the other versions. It's adds huge length to the compile time and forces users to have to delete the files in the "Build" folder to delete them, which in it of itself takes several minutes due the sheer number of files and folders compiled.

[CaptainPStar]

You can use the original "compile.py" and change the config used at the beginning of the file. Also compile.py is only meant for final packing. For testing I recommend linking the repository code directly to a dummy mission in your arma3-profiles/missions directory. This way you can preview code changes to the repositry directly in the ingame editor (and exporting to mpmission should work aswell). I am preparing a script file that does the linking automatically. Commit soon™.

[Qerbas]

The dummy mission sounds really interesting and helpful, so I like that. However, since it's a single dummy mission I would only be able to test changes from the "Code" folder correct? I don't think I would be able to mass test changes from the Mods, Missions, and Configs folders, which I use the most, if that is the case.

I tested running compile.py and changed the config and it still outputs files in the "Build" directory and the "Packed/Addons" directory. I think you're misunderstanding my request, so I'll explain it in more detail.

Say for example, I'm editing the UnitClasses.sqf for multiple different versions. Normally what I do is I make the appropriate edits, and then once I'm ready to test I run compile_local.py to compile all mission versions and then copy them over to the Mpmissions folder to test on my dedicated server. It might be 5 or 10 different versions that I need to test. It would be a massive pain to have to manually select each version in the editor and export them individually, and if I make any mistakes and have to recompile I would again have to edit and export each individual mission manually. It's much easier for me to just make the changes in github and recompile all of them with the script, however I only need the contents of the "Packed/Missions" because I obviously just need the mission pbo files, and not the unpacked versions or the addon versions that the other folders have.

The "Build" folder when the script completes as of now for me is 2.41GB and contains 246,878 files and 28,051 folders. Compiling it takes around 14 minutes and deleting it takes about 2 (and this is on an SSD, it's even longer on an HDD) minutes because if I don't delete them and re-run compile_local.py or compile.py it spams me with overwrite requests so I have to delete the contents of the "Build" folder before re-running the script. As a workaround I cancel the script after the missions I need are completed, but it's awkward and requires me to stare at the "Packed/Missions" folder until the versions I want are compiled, which takes longer than it should because the script is simultaneously compiling files in the "Build" folder. I still have to delete what was created in the "Build" folder either way, so it only saves me a bit of time.

It would be much more efficient to have a .py file just for compiling the contents of the "Packed/Missions" folder to make it easier to mass test lots of changes, which is very helpful for my workflow. I tried editing the python file myself, but I'm very, very new at python so I was unable to do it successfully.

Here's some screenshots of the folder sizes:

Build folder:

Packed/Addons folder:

Packed/Missions folder:

[CaptainPStar]

The script allows linking against different mods and terrains automatically. The only thing you need to supply is a working mission.sqm that matches the terrain (there you can use the one used for placing the evac markers).

In my build environment I have atleast one development mission for every mod and one for every terrain. Basically: Escape_Dev_Vanilla.Stratis Escape_Dev_CUP.Stratis Escape_Dev_CUP_Des.Stratis Escape_Dev_RHS.Stratis ... Escape_Dev_Vanilla.Altis Escape_Dev_Vanilla.XYZ

That way I don't need to copy anything around. Changes in code, mission.sqm and unitclasses are directly reflected in the ingame editor and can be previewed, and much more important, debugged directly. Gitlab had a tutorial for this, unfortunatly I forgot to save it, when deleting the instance.

The compiler is really only meant for final packing and not testing (maybe only final MP testing) and I never intended it to be used locally.

[Qerbas]

Since the mission.sqm in Github doesn't have the player units inserted, wouldn't this mean that in for example my extraction edits, I would have to manually edit the player units in the mission.sqm in the Arma 3 profiles folder? I can see how the code and unitclasses changes could work probably through symbolic links, but not the mission.sqm file for the aforementioned reasons.

Also, while that may be good for solo testing, I try to do multiplayer testing in a real world environment, and simply being able to compile all the versions in one go makes it very easy to do focused gameplay tests, while still having the flexibility of being able to choose from any version. For example, in my new Operation Trebuchet edit, I want to test the mod, but my players might want to play Chernarus, and then switch to Thirsk, and it's simply easier to have them all made at once. With your script method I would have to go into the editor one by one and export to mpmissions before every play session, or use my current solution which has it's own issues.

I don't want to make this seem like it's a huge issue. At worst it's really just an annoyance, but since I tweak the missions and test so much all that time spent compiling and deleting files and folders adds up quickly.