Coop Error

[Friar]

Any one know why

"selected aircraft not created" error comes up on a coop

I am looking at up3 rc3

[FoolTrottel]

Could have several causes... what mission is it?

[FoolTrottel]

Have tried several missions of the Desert44 campaign, no problem here...

[FoolTrottel]

Found out what can cause this.

(But, I'm pretty sure this is not the ónly cause of this error.)

I found this when I loaded a mission in my hosting-tool, it was a mission on which the error had occurred earlier when hosting last week.

In my hosting too, the 'Squadron' designation was set to a value of 5. That is weird, as the maximum is 4!

Loaded the mission in FMB, saved it without changing, and the Squadron designation changed from 5 to 4. So, this corrected the issue.

Further investigation showed this mission had [gb0140] as regiment / wing name.

I've learned from my mate Aviar, what some of these digits mean:

The third one from the right is the flight number. The second one from the right is the squad number. But there's a small trick here: To get the real number, you'll have to add one to the value of the digit. As in the mission file they start at 0, and can also be 1,2 or 3. In the FMB the list runs from 1 to 4.

So, Squad number 4 is bogus, can't be in the mission, as it would show up as 5! Too high!

Resulting into message: "Selected aircraft not created"

And now for the real cause:

- The troubled mission is 'Ardennes_Summer_00b.mis', from the folder 'Ardennes Missions', it is dated 23-3-2008. Its .properties file is older (2003) which made me think this mission has been edited. Now I've seen more of these missions, that have been edited on a date shortly before I downloaded the entire mission set from the Vault in 2008.

Missions where the .properties file was older than the mission file. Now that's strange, as the FMB always saves both .mis and .properties file, so the should have equal date/time stamps.

Then I realized that one of hour hosts uses QMT ('Quick Mission Tuner') quite often.

(Now one of the biggest gripes I have with QMT, is that is edits and saves over the original mission. I hate that, I am all for fooling around and changing missions in order to create some variation, but you do not alter/mess with your source! Never ever. Well, I don't anyways.)

So, I started messing with QMT (on a copy of the mission, for sure!)

And, quickly enough, I found out that under specific circumstances, QMT allows/generates the creation of squad numbers with a value over 4!

Further observations/thoughts

- This error can and will also occur in 4.10.1m Stock. Shocker!! Yes, that is true!

- I suspect that versions pré 4.10.1m (ie. 4.09m) did not suffer as much from this too high value (can't / won't really prove that now, I haven't got a 4.09m ready with me) as it probably corrected it itself, as it never led to an error like this on those earlier versions.

- As of 4.10m, TD got into Zuti-ing it all up. (I know that sounds a bit negative, and I mean it that way. I do like and enjoy the fact that they add new functionalities, but they've been sloppy... they've not spent the amount of attention on error trapping as Maddox did up and untill 4.09m anyways)

Conclusion

A QMT user has been changing missions, chaning/adding flights/squads that in the end resulted into a squad number larger than 4.

Some of these 'affected' missions are in missionpack in the vault.

This - in my opinion- for the biggest part explains why 'all of a sudden', out of a clear blue sky, some (what looked to us like) traditional missions would not start / could not be hosted in UP3. (UP 2 probably also). And we were in deep trouble.

What now?

I am going to try and adjust my tooling for this issue. Whenever it finds a Squad number like it, it will try an alternative number.

If it can't decide on one (it might already be there), it will report the issue, and leave the flight out of the mission.

So, that's one host saved!

As for the all other hosts?

I think I can check my current mission set semi-automatically for this specific issue, and have it try and fix it ... depending on how many missions will have this issue in 'm.

(Lol, maybe it's only limited to this one mission...)

Should this result into a significant number of defective missions, I think I will just try and upload the corrected set to the vault.

(I ám kinda happy and thrilled to have tackled this issue... well I think I have.. and if not... Oh well)

[fruitbat]

Found out what can cause this.

(But, I'm pretty sure this is not the ónly cause of this error.)

I found this when I loaded a mission in my hosting-tool, it was a mission on which the error had occurred earlier when hosting last week.

In my hosting too, the 'Squadron' designation was set to a value of 5. That is weird, as the maximum is 4!

Loaded the mission in FMB, saved it without changing, and the Squadron designation changed from 5 to 4. So, this corrected the issue.

Further investigation showed this mission had [gb0140] as regiment / wing name.

I've learned from my mate Aviar, what some of these digits mean:

The third one from the right is the flight number. The second one from the right is the squad number. But there's a small trick here: To get the real number, you'll have to add one to the value of the digit. As in the mission file they start at 0, and can also be 1,2 or 3. In the FMB the list runs from 1 to 4.

So, Squad number 4 is bogus, can't be in the mission, as it would show up as 5! Too high!

Resulting into message: "Selected aircraft not created"

And now for the real cause:

- The troubled mission is 'Ardennes_Summer_00b.mis', from the folder 'Ardennes Missions', it is dated 23-3-2008. Its .properties file is older (2003) which made me think this mission has been edited. Now I've seen more of these missions, that have been edited on a date shortly before I downloaded the entire mission set from the Vault in 2008.

Missions where the .properties file was older than the mission file. Now that's strange, as the FMB always saves both .mis and .properties file, so the should have equal date/time stamps.

Then I realized that one of hour hosts uses QMT ('Quick Mission Tuner') quite often.

(Now one of the biggest gripes I have with QMT, is that is edits and saves over the original mission. I hate that, I am all for fooling around and changing missions in order to create some variation, but you do not alter/mess with your source! Never ever. Well, I don't anyways.)

So, I started messing with QMT (on a copy of the mission, for sure!)

And, quickly enough, I found out that under specific circumstances, QMT allows/generates the creation of squad numbers with a value over 4!

Further observations/thoughts

- This error can and will also occur in 4.10.1m Stock. Shocker!! Yes, that is true!

- I suspect that versions pré 4.10.1m (ie. 4.09m) did not suffer as much from this too high value (can't / won't really prove that now, I haven't got a 4.09m ready with me) as it probably corrected it itself, as it never led to an error like this on those earlier versions.

- As of 4.10m, TD got into Zuti-ing it all up. (I know that sounds a bit negative, and I mean it that way. I do like and enjoy the fact that they add new functionalities, but they've been sloppy... they've not spent the amount of attention on error trapping as Maddox did up and untill 4.09m anyways)

Conclusion

A QMT user has been changing missions, chaning/adding flights/squads that in the end resulted into a squad number larger than 4.

Some of these 'affected' missions are in missionpack in the vault.

This - in my opinion- for the biggest part explains why 'all of a sudden', out of a clear blue sky, some (what looked to us like) traditional missions would not start / could not be hosted in UP3. (UP 2 probably also). And we were in deep trouble.

What now?

I am going to try and adjust my tooling for this issue. Whenever it finds a Squad number like it, it will try an alternative number.

If it can't decide on one (it might already be there), it will report the issue, and leave the flight out of the mission.

So, that's one host saved!

As for the all other hosts?

I think I can check my current mission set semi-automatically for this specific issue, and have it try and fix it ... depending on how many missions will have this issue in 'm.

(Lol, maybe it's only limited to this one mission...)

Should this result into a significant number of defective missions, I think I will just try and upload the corrected set to the vault.

(I ám kinda happy and thrilled to have tackled this issue... well I think I have.. and if not... Oh well)

good work FT

[Jabo]

Indeed Sherlock!

[FoolTrottel]

Hm, well... theory is nice ... I only found two missions being in error regarding this.

In the end, one cause of 'Selected Aircraft not created' has been identified.

Up and on to the next!

[FoolTrottel]

Here's another cause:

- An Aircraft using an 'incorrect' loadout.

In this case:

Class air.SPITFIRE5BLFCLP
 Fuel 100
 weapons 2fab100

Solution here is to change the '2fab100' into 'default'.

So, Spitfire LF Vb CW, 1943 can not or can no longer take bombs.

Whether this is a bug, I dunno. It happens in UP3 RC4 ánd in 4.10.1m, both show the now famous error message when this aircraft loadout combination is in the mission.

This occurs in the Moskau10.mis, in the Operation Barbarossa Coops folder.

(In my set, the mission file is dated 26-4-2008, where the .properties file is dated 11-08-2002. So, looks like this also could be a victim of a quick and dirty replace of 4x I-16 by 4x some spits...? Have been looking for the original version, I found the mission pack in the Downloads/Vault, but urrently I can't seem to download it succesfully. Have opened a different thread for that... )

Oh well...