Known Scripting Engine Issues

[Grimes]

I will use this thread to keep track of reported scripting engine bugs. Please don't report them here, make separate threads for each bug. But if a thread exists for a bug that isn't mentioned here be sure to remind me. :)

 

Please note that somethings with the scripting engine have changed. I have updated the wiki for all relevant changes.

 

Stuff that is different:

 

trigger.action.outText(et all) now have an end boolean variable called "clearview". By default message boxes stack so they don't overwrite each other, if you have a script displaying a new message several times a second you need to utilize this variable.

 

Due to localization changes within the mission editor a large number of items are now named "dictKey_whatever_x". As such any function that grabs any of this text will no longer get the key you are looking for. As a result env.getValueDictByKey() was added. This will convert any string dictionary key into its actual value.

 

MIST v55 is required if you want to use MIST in 1.5. This update is needed because of the two changes listed directly above.

 

Known Bugs

 

 

27372 - Initialization Script File fails to run. Notes: The Do Script box should work, its just not running init script files.

31682 - Client groups not accessible in multiplayer. Sorta fixed in 1.5.5 and 2.0.4 or newer. Will work for single client groups. It is still bugged for multi-client groups.

30528 - Group.isExist() returns true if group is dead

28924 - coaltion.getGroups() returns dead groups

29188 - coalition.addGroup cant specify parking spots for aircraft to spawn at

27912 - Object.destroy() not functional on world objects

24826 - Dynamically spawned AI do not display properly in debrief, logbook. (To test new MP interface and messages)

32313 - Clearview option isn't working on trigger.action.outTextForCoalition. Works for the other outText functions.

xxxxx - Unit.getPlayerName() doesnt work on client controlled CA units. Also it only works for the pilot in an L-39 and not the co-pilot. A new scripting function has been requested to get crew data for multicrew aircraft.

xxxx1 - coalition.addGroup fails to remove an existing group if the new group has the same name. (Only effects Airplanes and Helicopters groups. If units share name the units are still removed, along with ground/ship groups that share names)

Edited January 30, 2018 by Grimes
added xxxx1

[Ciribob]

31682 - Client groups not accessible in multiplayer.

 

Just to chime in on this, this bug is causing a serious headache for me in a bunch of scripts and is going to be a bugger to work around.

 

Any script that tries to add F10 commands to a player will likely run into this bug as usually you add the commands to a player group something like this:

 

local _unit = Unit.getByName("MEDEVAC 1")
local _groupId = _unit:getGroup():getID() -- will fail due to bug 31682 - therefore no f10 command

 missionCommands.addCommandForGroup(_groupId, "F10 Action", nil, someFunction, nil)

 

Which'll not work in 1.5 at the moment.

[xcom]

Any ETA for the fix to - 31682 - Client groups not accessible in multiplayer?

This one kills most of the scripts I ever did.

[Blooze]

I have seen updates break missions in the past and patches that came later to fixed them. For dummies like me that now just have a bunch of broken missions do you think it's possible a forthcoming patch will be available to make them work again or perhaps a user created solution that may be easy for the ME impaired to use?

[Ciribob]

Any ETA for the fix to - 31682 - Client groups not accessible in multiplayer?

This one kills most of the scripts I ever did.

 

Xcom, for the minute i've made a small function like this using MIST's Unit DB as Grimes suggested as a workaround for the CTLD and CSAR scripts

 

function ctld.getGroupId(_unit)

   local _unitDB =  mist.DBs.unitsById[tonumber(_unit:getID())]
   if _unitDB ~= nil and _unitDB.groupId then
       return _unitDB.groupId
   end

   return nil
end

 

If you're not using MIST you can manually generate a table of for mapping unitID to Group ID's the same way Grimes does using the env.mission table but this is obviously not ideal :(

[xcom]

Thanks Ciribob, unfortunately other functions that rely on the client group will still fail.

I think I'll wait until they release a fix, patching up would take too long.

[Ciribob]

Probably a good idea! Luckily for me it was only used in a few places.

[Wizard1393]

30528 - Group.isExist() returns true if group is dead

28924 - coaltion.getGroups() returns dead groups

32145 - Lua Predicate not functional

 

Done some testing. Group.getByName() indeed returns dead(destroyed) groups. But if a group is Deactivated via trigger, it does not return the group.

It does however return the group if set for late activation in the ME.

 

Possible workaround for now seems to check the # of units within a supposedly destroyed group.

 

 

objGroup =Group.getByName('groupName')

if objGroup then

objGroupUnits = Group.getUnits(objGroup)

if #objGroupUnits < 1 then

--group is dead (destroyed)

end

else

--group is dead (deactivated)

end

 

 

 

 

Lua predicate would solve alot too... Anything?

 

Thanks for your info so far Grimes!

Edited October 7, 2015 by chrisofsweden

[Grimes]

Done some testing. Group.getByName() indeed returns dead(destroyed) groups. But if a group is Deactivated via trigger, it does not return the group.

It does however return the group if set for late activation in the ME.

 

Group.getByName() returning the group if its set for late activation is normal behavior because the group is still active and "alive", its always worked like that, even with trigger conditions. Good to know that deactivating the group correctly removes it.

[vicx]

Group.getByName() indeed returns dead(destroyed) groups

 

I don't think that's a bad thing. You should have a way to access all groups; alive or dead.

[Wizard1393]

Group.getByName() returning the group if its set for late activation is normal behavior because the group is still active and "alive", its always worked like that, even with trigger conditions. Good to know that deactivating the group correctly removes it.

 

OK. To me this is confusing. Deactivating a group should put the group in the same kind of state as a group set to late activation would be, wouldn't you agree?

Maybe it's just the working used that makes it confusing then. If it's intended that a group that gets "Deactivated" is not in the same state as a group put in "Late Activation" then I would suggest calling "Group Deactivate" trigger action to be renamed to Group Remove to avoid confusion.

 

 

I don't think that's a bad thing. You should have a way to access all groups; alive or dead.

 

I guess I agree. So is the general idea that you use Group.isExist() for checking if the any of the units in the group is alive then?

Edited October 8, 2015 by chrisofsweden

[Grimes]

I don't think that's a bad thing. You should have a way to access all groups; alive or dead.

 

Yet units are correctly removed from accessibility once they are killed. But that is ignoring the caveat that all units/groups can be accessible with most functions available if you store the actual object ahead of time. I'd prefer for it to work exactly the same for all units/groups, it is annoying to deal with if one type of object has drastically different rules governing it, IE. if Group.getByName('whatever') is always true while if Unit.getByName('whateverElse') won't work if the group is dead.

 

I guess I agree. So is the general idea that you use Group.isExist() for checking if the any of the units in the group is alive then?

 

The problem with that idea is Group.isExist is broken at the moment.

 

In a sense when you don't have a group object Group.getByName is the exact same thing as isExist when you DO have the group object. At least they would be if they both worked as they should.

 

OK. To me this is confusing. Deactivating a group should put the group in the same kind of state as a group set to late activation would be, wouldn't you agree?

Maybe it's just the working used that makes it confusing then. If it's intended that a group that gets "Deactivated" is not in the same state as a group put in "Late Activation" then I would suggest calling "Group Deactivate" trigger action to be renamed to Group Remove to avoid confusion.

 

Well its mostly down to matching how the mission editor works with stuff. To the editor conditions all groups are "alive" until they are killed or deactivated. So while a group set to late activation may not be visible, it still exists and is accessible. Additionally you have the "visible before start" value adding to this, you can see the group, yet they aren't "active" within the mission doing their route or have AI doing its thing.

 

Group Deactivate is the same as Group.destroy() which is the actual scripting function used when you deactivate something.

[Wizard1393]

Group Deactivate is the same as Group.destroy() which is the actual scripting function used when you deactivate something.

 

This is fine. But for the sake of clarity, the trigger action GROUP DEACTIVATE in my opinion should/could be renamed to GROUP TERMINATE or something similar. Using the word DEACTIVATE might have people thinking they can DEACTIVATE the group and then activate it again with GROUP ACTIVATE, seeing as that it's possible to activate a group set for late activation.

 

I'm guessing this is a smaller issue, or even a non issue for most people creating simple missions in the ME. But when getting into advanced mission creating and scripting, you find yourself trying to understand these kind of inner workings, like what the difference is in the states of a group set for late activation and a group that has been deactivated.

 

All improvements, small or big, are still improvements right?

[vicx]

I'd prefer for it to work exactly the same for all units/groups, it is annoying to deal with if one type of object has drastically different rules governing it, IE. if Group.getByName('whatever') is always true while if Unit.getByName('whateverElse') won't work if the group is dead.

 

I have used the MIST convenience tables in the past because it was convenient :)

 

I never looked into how MIST was making it's Dead and Alive tables. I just assumed Unit.getLife was involved in the co-routine that pruned the tables.

[Wizard1393]

BUG (Broken functionality) REPORT MIST

 

Instead of making a new thread, I'll just make a post about it in this existing thread. Grimes, should we use this thread specifically for bug reports/broken functionality regarding MIST and the Scripting Engine, or make new threads in the "Mission Editor Issues" subforum?

 

Function mist.groupToPoint, does not seem to work properly. I'm trying to use it to move a ground group to a zone. It sends the group off in a static direction (not towards the zone) and it disregards the UseRoads variable. I've tried setting UseRoads to true and 1, false and 0. I've set the Formation to 'On Road'. Nothing makes them use road. And they spawn right next to one, some units, even directly on one.

 

mist.groupToPoint('Russian Ground Assault Group', 'Objective Zone', 'On Road', nil, 40, true)

 

I've attached a freshly created test mission that replicates this every time. Just load the mission. After 5 seconds a group spawns in and sets off to the horizon like there's no tomorrow :)

test.miz

[xcom]

Has any of the known bugs been fixed in today's patch?

[Grimes]

BUG (Broken functionality) REPORT MIST

 

Instead of making a new thread, I'll just make a post about it in this existing thread. Grimes, should we use this thread specifically for bug reports/broken functionality regarding MIST and the Scripting Engine, or make new threads in the "Mission Editor Issues" subforum?

 

I personally don't care because I'm going to read it anyways. It could very well end up being a bug with mist or the scripting engine in general so it could be perfectly valid to make a thread on it. I'll check it out.

 

Has any of the known bugs been fixed in today's patch?

 

Nope. :/

[Grimes]

Function mist.groupToPoint, does not seem to work properly. I'm trying to use it to move a ground group to a zone. It sends the group off in a static direction (not towards the zone) and it disregards the UseRoads variable. I've tried setting UseRoads to true and 1, false and 0. I've set the Formation to 'On Road'. Nothing makes them use road. And they spawn right next to one, some units, even directly on one.

 

Very strange indeed. I tested the function outside of your mission and it worked fine, with your mission it didn't initially. However I made a slight change and it fixed it. I simply moved the mist.groupToPoint() function call outside of the script so its not run immediately after the dynAdd function. I'm not sure why the group just drives off like that, maybe they aren't quite ready to get an order the exact moment they spawn.

[Wizard1393]

Ah ok great! Thanks for checking it out Grimes!

 

EDIT: Just sending the groupToPoint function through mist.schedulefunction within 10 seconds solves the problem.

Edited October 11, 2015 by chrisofsweden

[pdmarsh]

I have seen updates break missions in the past and patches that came later to fixed them. For dummies like me that now just have a bunch of broken missions do you think it's possible a forthcoming patch will be available to make them work again or perhaps a user created solution that may be easy for the ME impaired to use?

 

I have essentially the same question as Blooze, but, put another way, when 1.5 or 2.0 are out of beta and released, will some (many?) existing missions remain broken until the scripts they use are themselves updated, or can we expect these scripting issues to be resolved within DCS World 2.0 itself?

 

Thanks,

Paul

[Wizard1393]

I definitely think scripts are going to need updating. Things change in the game / scripting engine and scripts will have to follow. But don't worry. Most individuals who even bother learning LUA and creating scripts in the first place will most definitely update them. Just give them some time. Also don't forget that we're in beta. People who created complex scripts might not bother updating them at least until 1.5 Final is released.

[xcom]

I definitely think scripts are going to need updating. Things change in the game / scripting engine and scripts will have to follow. But don't worry. Most individuals who even bother learning LUA and creating scripts in the first place will most definitely update them. Just give them some time. Also don't forget that we're in beta. People who created complex scripts might not bother updating them at least until 1.5 Final is released.

 

Well, that's not necessarily true.

I don't intend going back to the scripts I published previously and updating them to support new changes in the scripting engine unless they are scripts that I intend to use for future stuff.

[pdmarsh]

I definitely think scripts are going to need updating...

 

Thanks for the response. I guess we'll have to wait and see how things go, but I understand that things do change.

 

Paul

[xcom]

27912 - Object.destroy() not functional on world objects

Is this relevant to all the objects? units/groups etc?

Is there a workaround currently to destroy objects.

[Grimes]

Last I checked it applies to "scenery objects" like bridges, buildings, etc. The function should be working with AI and weapons.