Mission Editor gives out too large unitIds / groupIds

[deadpool]

I just had a mission where people crashed when they were in the cockpit.

 

I rolled back to a version that was working but didn't contain the players airplanes and created two planes.

 

One F-16 on RAMP in Bandar Abbas, saved, tried to fly it .. worked.

 

The added an F-18 on RAMP in Bandar Abbas, saved, tried to fly it .. crashed, but F-16 works still.

 

Changed the F-18 to an F-16 .. first F-16 worked, second doesn't .. it crashes when stepping into the cockpit.

 

checked the unitIDs ..

 

Name		groupId		unitId

Working1	190525077	 594092539
Broken1		387368192	1207852785

 

changed the broken1's unitId and groupId manually to 6666 and 9999 respectively .. and it worked.

 

 

I will be writing a utility to compress my missions soon, BUT:

 

1.) Why doesn't the mission editor warn or help stay within limits?

2.) Why does the mission editor skip 500 MILLION possible Ids before handing out the next one?

[Grimes]

Going to need the mission file.

[deadpool]

Here you go. I basically deleted everything but two equal units, different only in ids.

JTF-88_Op.Desert.Sword_S007_mandatory_v1.1_DP_4.miz

[Grimes]

Running any editor mods or modify the miz directly via some other means?

 

The unitId and groupId the editor generates start at 1 and go up from there. However it does not go back and look for empty numbers. So create an object it has id 1. Delete that object and create a new object the id would be 2, and so on. When you create a new mission it resets that counter. I have absolutely no idea how the Ids could have gotten that high using just the editor alone. Maybe a lua error that it was able to escape out of and then save the mission? That is grasping at straws and highly unlikely though. Are the ids of everything in the original mission that high?

 

The whole mission would really help try to put a picture together. Or just more information like when was the mission first made. If you have any tracks of earlier builds of it? Does this happen when you start a brand new mission and add stuff roughly the same way?

[Andrei]

Maybe I can chime in as well for the context. We're using a system of static templates to create flights for the mission. This is done so that the squadron leaders can do independent planning for their squads and submit ready flights with the aircraft having correct loadouts, WPs, bort numbers, etc. So the flow goes like that.

 

1. Mission designer creates a mission with all units, scripts, triggers etc

2. He then puts a "template" for the different client flights - basically one client A/C with pre-set frequencies.

3. Mission is then saved-as as the "template" version. In this version, mission designer REMOVES all items that he does not others to see, e.g. enemy fighters, SAMS, etc.

4. This template version is then distributed to the leads for planning.

5. The leads will copy-paste template aircraft and create their flight plan, loadouts, etc.

6. They will then DELETE everything in the mission apart from their flight and save the mission as Static Template

7. They will submit the static templates to the mission designer who will import them to the main mission.

 

Sounds a bit complicated, but this is a working way to work collaboratively on a mission using only DCS built-in tools.

This process involves quite a bit of copy-pasting and importing static templates. I guess somewhere down the line something is messed up with the unit IDs.

[deadpool]

Running any editor mods or modify the miz directly via some other means?

 

The unitId and groupId the editor generates start at 1 and go up from there. However it does not go back and look for empty numbers. So create an object it has id 1. Delete that object and create a new object the id would be 2, and so on. When you create a new mission it resets that counter. I have absolutely no idea how the Ids could have gotten that high using just the editor alone. Maybe a lua error that it was able to escape out of and then save the mission? That is grasping at straws and highly unlikely though. Are the ids of everything in the original mission that high?

 

The whole mission would really help try to put a picture together. Or just more information like when was the mission first made. If you have any tracks of earlier builds of it? Does this happen when you start a brand new mission and add stuff roughly the same way?

 

 

 

The two F-16s I have created there haven't been created by template import.

It was me just clicking an airplane into the mission. Saving, flying to test. Then returning to Mission Editor and repeating. And I was left with that huge of a gap.

[deadpool]

Here is a tool I quickly wrote to compress the IDs .. also fixes some problem I have been seeing with the EPLRS pointing to wrong groups.

 

https://github.com/destotelhorus/DCSMissionTools

 

No idea if that's really creating that stable missions, though. Use at your own risk!

[Grimes]

The two F-16s I have created there haven't been created by template import.

It was me just clicking an airplane into the mission. Saving, flying to test. Then returning to Mission Editor and repeating. And I was left with that huge of a gap.

 

Yes, but if the template has absurd Ids then the next unit and group ids will be adjusted based on those once they get loaded in. So open mission X, it finds the highest unitId and groupId and sets the next value for each to be that value + 1. Likewise the adjustment is made whenever templates get added.

 

 

Ok, figured it out. Its a compounding issue with merging templates it appears. Will make report tomorrow since I need to sleep soon. The gist of it is that when merging templates it treats the next highest Id as an offset to the stored value, if the imported template has higher Ids then it resets the next highest Id to that.

 

Make a template out of the mission you posted and reload it into the same mission. One of the new ids would be 1,801,945,324. Might notice that it is what you get when you add the two existing unitIds together. Which is more or less what the load template code does to create an offset of Ids. The issue compounds itself as more units get added and constant loading new/different templates. Eventually it gets to the very large numbers you see here.

[deadpool]

Yes, but if the template has absurd Ids then the next unit and group ids will be adjusted based on those once they get loaded in. So open mission X, it finds the highest unitId and groupId and sets the next value for each to be that value + 1. Likewise the adjustment is made whenever templates get added.

 

 

Ok, figured it out. Its a compounding issue with merging templates it appears. Will make report tomorrow since I need to sleep soon. The gist of it is that when merging templates it treats the next highest Id as an offset to the stored value, if the imported template has higher Ids then it resets the next highest Id to that.

 

Make a template out of the mission you posted and reload it into the same mission. One of the new ids would be 1,801,945,324. Might notice that it is what you get when you add the two existing unitIds together. Which is more or less what the load template code does to create an offset of Ids. The issue compounds itself as more units get added and constant loading new/different templates. Eventually it gets to the very large numbers you see here.

 

Awesome! Thanks for figuring this out so quickly!