Mission Troubleshooting

Removing Dependencies:

At the top of your mission.sqm, you will find the modline. The modline is essentially a section of your mission.sqm that’s there to call what mods need to get loaded for a specific mission. This determines the dependencies that mission has.

Sometimes mods get pulled from the modpack, and even though you didn’t include assets from those mods in your missions, they will still be included in the modline due to major idiocy on the mod developer’s end. A good example of this is old blastcore, which used to include a reference in every mission if you had it enabled while you were building the mission in the editor.

When you run into this, you’ll likely get an error when you try to load your mission up on the server. It will say something about missing required content. That error will generally tell you what mods are being called in the mod line that are not present in your actual mod directory.

The first step to solve this problem (the mission not loading due to calls for mods that are no longer present in the modpack) is to locate where in the mod line those calls are. To do this, you’re gonna need to access your mission.sqm as raw text. To do this, you cannot binarize your mission file. Binarizing a mission file can reduce the ability of users to tamper with the mission, which is a good thing if you’re releasing a mission publically, but it’s not necessary (and really not advised) to do so if you’re releasing the mission privately.

Scenario files are not binarized by default in the CMF, so you shouldn’t have to worry about that unless you went in there and changed that setting yourself. If you have changed that setting yourself and you can no longer open the mission in the editor, you’re SOL.

Once you have your mission.sqm open in notepad++ or whatever text editor you use, scroll down until you see “addons[]=”. This section should have a lot of mods listed, each in their own individual line. It is this section and this section only that you should modify. Assuming you have already identified which mods are the issue, and what their class names are (by reading the error spit out by the server on attempting to load the mission). Use the ctrl + f function or your keen vision to find the culprits. Once you have found the correct class names in the mod line, you can delete them.

Typically with this sort of thing you would comment it out, with aims of being able to revert changes if you mess up. In this case, you cannot comment out code in a mission.sqm, it does not work. This is why it is advisable that you make recurring backups if you want to make direct edits to the mission.sqm.

Slot Ordering and Naming Issues:

Slots are defined by the CMF in most cases. You are given three entire factions, with almost all the special slots needed for any mission you could imagine. Each one of these units is placed down in the editor in a very specific order. There is a reason that slots appear in a specific order in the slotting screen when we start a mission. Units will appear in the order that they are placed in the editor.

As such, any copying, pasting, or deleting and replacing of units will result in jumbled slot order. There are two solutions to this issue, one is preventative, and one is a treatment. The treatment is fairly involved and repetitive, especially as slot counts increase.

The first method is to rename slots based on what they are instead of creating new slots for specific roles. This entails changing the init and the role description of a unit if you wish to create a completely custom slot.

Say you want to create a special unit that is a variation on MAT. Instead of deleting MAT and creating your own unit from scratch, simply edit the role description to accurately reflect what the unit actually is. You can change what type of gear the unit will have by editing the call in the init. The init determines what part of the gear script is read and applied to a specific unit, so going from “MAT” to “r” will change the gear that unit has from MAT gear to standard rifleman gear. This is a great way of manipulating what units have what gear in a completely customizable manner, without screwing up slot order.

If you have already screwed up slot order, you’re first going to determine what order you’d like the slots to be in, then line up your units and copy paste them in that order. As an example, say your command units were deleted and later replaced, causing them to be located somewhere in the middle of all the slots. You want it at the top, so the first unit you copy paste will be your command units, then alpha squad leader and the subsidiary elements, etc.

If your slots are messed up, the best solution is to copy and paste ALL OF THEM in the order that you desire they show up in the slotting screen.

If you've buggered it beyond salvage, there is an option to merge two missions in the editor. Your option here is to merge the CMF into your mission, and the CMF player structure will be added without overwriting anything in the mission but unit structure.

Role descriptions will remain the same in the slotting screen regardless of how many times you copy paste, but the unit’s class name in the editor will change, adding a _1 to the end of the class name. This does not matter and you can ignore this, no one should be paying attention to unit class names anyways.

Reading RPT Logs:

The RPT log is the key tool in determining why your mission might be crashing. It’s a good place to go if you want to figure out what mods are giving you issues in your mod line (covered above), or if a specific asset is giving you problems. Many improperly configured mods will include assets that throw RPT errors on mission start. Often this requires a reload on the server side, which is simply unacceptable when we spend such a significant time slotting and planning for missions as is.

To prevent your mission from throwing RPT errors you must do a couple things: test your mission in a multiplayer environment by using the “play in multiplayer function” available to you in the EDEN editor. Additionally, if RPT errors are present, you must either edit the mission.sqm itself to remove the offending code, or open it up in the editor and delete the problem assets that way. Keep in mind if you use the latter method, you run a lower chance of borking your mission file, but you may still need to remove mod dependencies in the mission.sqm itself.

To view your RPT file, you will have to look in your appdata. RPT files can sometimes get thrown in weird places so it’s common that you’ll be looking at the wrong RPT if you’re not careful. Make sure to check any timestamps at the file head itself, as that is what tells you whether that specific log file is the one you actually want. ARMA generates a lot of these files, and it deletes a lot of them too. Each one is well over ten thousand lines, there’s no way you can read the whole error ridden thing. There will be a lot of errors in your RPT file, but most of these can be ignored. These are all just small config issues that the game notices but glazes over.

If your mission is crashing, the error that you’re interested in will almost always be located at the end of the file, or very close to it. You’re interested in about the first 10 line, and the last 10 lines. Looking at these last lines, you can usually identify what the error is. By and large, the only errors you can actually fix are going to be gear related or asset related. If your error is hinging around something that is broken in the actual mission.sqm, relating to a module or some other mission function, then you likely cannot fix it unless you’re already a mission making wizard.

If your error is gear related, then looking at the RPT will give you good insights in what exactly the problem is so you can get a better idea.