1.63 Script issues

[PiZZADOX 47]

Is this actually breaking anything though? From what I can tell script still run just fine and combine -noLogs and -showScriptErrors you are good to go. Yes it's annoying when testing out missions/scripts.

I've tried a few different well-known A2 script and despite the errors things work just fine (DAC was one of those).

You can replicate a script breaking error by including lea in a multiplayer mission with multiple slots, and only filling some of those slots. Any slot after an empty player slot (which is then an undefined variable since it has no name) will not get executed. The slots before the empty slot will work fine.

As said earlier these are not warnings, they are errors. If BIS intended for the script interpreter to be more strict for the sake of fps and efficiency, I am all for it. However they also have a responsibility to patch their own scripts.

[.kju 3240]

They are warnings in the sense that it didnt work before either. You are just get told about it now.

[PiZZADOX 47]

;2731867']They are warnings in the sense that it didnt work before either. You are just get told about it now.

It would seem as the interpreter now stops a script upon error, as it would in 1.62 with any other major error, and it stops functionality of some scripts that rely on (sometimes) undefined variables, aka LEA or other loadout scripts.

[.kju 3240]

I can't confirm that. I might be wrong, but it was not true for my game mode, nor for BI content/missions.

I would suspect for LEA or other loadout scripts something else is the source, if it no longer works with 1.63 now.

[PiZZADOX 47]

;2732301']I can't confirm that. I might be wrong' date=' but it was not true for my game mode, nor for BI content/missions.

I would suspect for LEA or other loadout scripts something else is the source, if it no longer works with 1.63 now.[/quote']

I can confirm it is within LEA's loadout.sqf that it is reporting the error, I can tell it has to do with trying to apply a loadout to a variable, usually defined by an object (a player unit's name), which without that player slot filled is now undefined. This was not a problem in 1.62 as the script interpreter would gloss over it and continue the rest of the script, but now it stops executing and LEA only works for the player slots that are filled in order, as the script is able to be executed until the unfilled player slots.

But these errors are showing how some BIS content is not well scripted to their own standards, and need to be fixed. Again, I am all for stringent scripting standards, but not if it damages functionality and especially if the developer is neglecting to patch their own reported errors.

[lazyrhino 10]

OA/CO 1.63 + ACE 2 + DAC (everything latest) ......game lagging when units spawn:(

[SavageCDN 231]

Make sure your server is using -noLogs parameter

[AZCoder 921]

Put a manned aircraft on the map. You will get the same error over and over. If you are making a mission with non-stop spammed messages like that, makes it kind of difficult to see your own errors because they quickly get overwritten by the BIS errors. That's why it's a big deal.

[opusfmspol 273]

If you are making a mission with non-stop spammed messages like that, makes it kind of difficult to see your own errors because they quickly get overwritten by the BIS errors. That's why it's a big deal.

Definitely agree with that. Certain errors are part of looping functions and just bury the one-time user script errors. Makes custom mission debugging very difficult. And some of the new detected errors are stopping scripts. The Warfare respawn is one example I can point out. Bypassed by 1.62 but stopped by 1.63.

And yet I do like the new error report system. Stronger debugging for missions. I just wish it had been made some sort of option, so the impact on casual gameplay could have been.... lessened? mitigated? bypassed? arrgh I can't think of the word I'm looking for, my brain just went to mush. I hate when brain thingy no work.

EDIT: Averted.... that was the word.

Edited July 31, 2014 by OpusFmSPol
Past bedtime. Took a moment to think of it.

[.kju 3240]

With the Arma_Licensed_Data_Pack, you could fix the scripting yourself and release the updated pbos.

Yes its considerable effort..

[AZCoder 921]

Definitely agree with that. Certain errors are part of looping functions and just bury the one-time user script errors. Makes custom mission debugging very difficult. And some of the new detected errors are stopping scripts. The Warfare respawn is one example I can point out. Bypassed by 1.62 but stopped by 1.63.

And yet I do like the new error report system. Stronger debugging for missions. I just wish it had been made some sort of option, so the impact on casual gameplay could have been.... lessened? mitigated? bypassed? arrgh I can't think of the word I'm looking for, my brain just went to mush. I hate when brain thingy no work.

EDIT: Averted.... that was the word.

I do agree the stronger debugging is good. Awhile back, someone reported a bug to me about one of my own scripts in Arma 3 that I actually wrote for Arma 2 1.62. I never knew it had a serious bug, and was surprised it had ever worked in Arma 2. I was able to fix it up and make it work in A3 nicely, so I am looking forward to vetting all of my old scripts in A3 as time permits.

[Sexacutioner 0]

I have code like this in my script that worked before:

waitUntil {!isNull attachLogic2};

It throws an undefined variable error when the entire reason for that is to wait until the variable is initualized before using it.

So I am doing it proper and stuff like this is necessary when it comes to multiplayer scripts that you only want the server creating variables and the clients to wait for them.

[opusfmspol 273]

I have code like this in my script that worked before:

waitUntil {!isNull attachLogic2};

It throws an undefined variable error when the entire reason for that is to wait until the variable is initualized before using it.

So I am doing it proper and stuff like this is necessary when it comes to multiplayer scripts that you only want the server creating variables and the clients to wait for them.

I read your post and thought I recalled something about the way variables were handled in 1.63; and sure enough:

From the changelog for 1.63

[97926] Changed: Scripting: When a global variable is assigned a nil value, it is now deleted (was kept with a nil value).

isNull is for checking state of objects, tasks, locations, groups, etc.; isNil is for checking whether variables are defined.

So I'm thinking perhaps isNull checks previously passed with nil variables since they weren't deleted, but isNil checks are necessary now?

But interestingly, I was playtesting with waitUntil using my own statement, waitUntil {!isNull truck1}; to see what you meant, and it threw a generic error in expression rather than undefined variable. I had truck1 predefined as an objNull, and set a trigger to createVehicle truck1 after the wait, but the waitUntil threw generic error and didn't wait (went ahead and executed subsequent hint code). -showScriptErrors and log both indicated the error was associated with the !isNull statement.

EDIT: Ah crap, nevermind that last part. I was doing waitUntil from a trigger, supposed to do that differently:

https://community.bistudio.com/wiki/Talk:waitUntil

I moved it to a script and it performed just fine.

Edited August 3, 2014 by OpusFmSPol

[PiZZADOX 47]

So I am doing it proper and stuff like this is necessary when it comes to multiplayer scripts that you only want the server creating variables and the clients to wait for them.

Exactly. It is breaking multiplayer functionality, particularly with player slots and parameters.

Every addon that used an undefined variable holder (which we can argue was right or wrong in the first place) is now broken and requires updating. With Arma 2's life cycle, I don't see any reason to do this. Why wasn't this change implemented early in the game's history to allow for modders to compensate?

What I'd really like to see is BI come out with a hotfix that no longer has the more strict script interpreter that breaks their own code and nearly every single complex addon, but with the numerous improvements and tweaks they have made.