Editor hosed me by adding call{}; around init box code

[johnnyboy 3743]

I spent alot of time positiong objects exactly, and placing this in their init in-box:

this enableSimulation false;

This morning I opened the mission and tested my cutscene and it was ruined, because the the editor had somehow change the init boxes to read:

call {this enablesimulation false};

This caused the obects to move and ruin the cutscene I spent 2 days on.   I removed the "call {};" from the init boxes and it works again, but I am scared it will happen again before I publish it.

 

What happened?

 

Also, the same thing happened in Waypoints and Triggers.   Conditions now read:

call {true};
... instead of simply...
true

and OnActivation code also has call{}; added to it...wtf?  Same in all my triggers too!

[AZCoder 921]

Fascinating. I just grepped all of my sqm files for my upcoming campaign on the keyword enableSimulation and found a mix of init="this enableSimulation false"; AND also this one: init="call{this enableSimulation false}";

 

I was gonna ask if you were on dev branch, but I'm not, so that's not it.

[Harzach 2507]

I've seen this in the mission.sqm itself, but are you saying you are seeing changes in the editor as well?

[johnnyboy 3743]

5 minutes ago, Harzach said:

I've seen this in the mission.sqm itself, but are you saying you are seeing changes in the editor as well?

Yes, in the editor.  And it changed how my scene worked.  I'm guessing the call{}; code is slower so my objects are initially physics affected and drop before enablesimulation becomes false.  Without the call{}; wrapper, the objects are immediately disabled and stay in the correct position.

[beno_83au 1362]

Saw the same thing happen with init box code about a year ago, but never saw it since. Very odd that's for sure. 

[Harzach 2507]

I guess this "feature" was added with Apex? I don't see it all of the time, and never in the editor itself. Sounds like a bug.

[AZCoder 921]

I mostly switched to using the simulation checkbox on each unit I want disabled at the start. Probably the safest bet.

[johnnyboy 3743]

25 minutes ago, AZCoder said:

I mostly switched to using the simulation checkbox on each unit I want disabled at the start. Probably the safest bet.

Good call.  I just went through and did that.  This bummed me out as it would fu** up hours of work...but its all cool now.

[whiztler 135]

I noticed this several times as well. Did anything mention/post this in the feedback tracker?

[pierremgi 4739]

Yes, probably since Apex. Same for all fields (see triggers) when you dig in the mission.sqm. That's a mission.sqm engine.

I feel there are two reasons, not saying I'm right:

- some better reliability against error;

- it seems to impact every "shared" (public) codes like init fields or triggers, for some optimization on network traffic.

Not sure but perhaps a BI dev could explain that.

 

[Jigsor 175]

Hmm, are you guys sure this is not caused by editing with mods enabled. I found that the call wrapper was added when editing init field when CBA was enabled. CBA did not used to cause this problem until one of their updates about a year or more ago I believe. Best practice in general is to edit with only required mods because modification to mission.sqm like this could sneak in otherwise.

[Harzach 2507]

33 minutes ago, Jigsor said:

CBA

Ahh. I just created a vanilla test mission with a few objects/triggers/etc. all with simple code in their inits/param fields. The sqm showed nothing out of the ordinary. I then loaded that mission file with CBA enabled and saved it. The sqm now shows call wrappers around trigger params, but not code in object inits.

[johnnyboy 3743]

@Jigsor and @Harzach:  Thanks guys, I think you nailed the cause.  I had CBA mod loaded while working on the mission, and later removed it and had this problem right after that.  @AZCoder's suggestion to uncheck the simulation checkbox for items I want frozen has solved my problem.