Known Scripting Engine Issues

[FlightControl]

Guys, this is a very known issue. The DCS bug is already meaning for MONTHS half of the scripts in the world are not working anymore in multiplayer.

 

It is a shame, and DCS is promising fixes, but no timelines. But I understand, bring out new modules is of course cash, fixing old lua bugs does not bring cash. From a short term spoken that is true. But it is bad advertisement.

 

My moose framework has a workaround, because it had to be developed, no other way around.

 

1. getPlayerName() is retrieved from the Unit, not the group... getPlayerName() works, as long as it is a client with an airplane. When the client is a ground unit, getPlayerName() returns blank.

 

2. getID of the group and other properties can be retrieved from the env environment variable. Although, they are STATIC, meaning, it is not ideal ...

 

See the code here:

 

https://github.com/FlightControl-Master/MOOSE/blob/master/Moose/Client.lua

 

From mine 164...

 

Note that in the functions the _DATABASE object is used to overcome the 153 bug, consulting the Units and Groups from the env environment table when starting the mission.

 

--- Return the DCSGroup of a Client.
-- This function is modified to deal with a couple of bugs in DCS 1.5.3
-- @param #CLIENT self
-- @return DCSGroup#Group
function CLIENT:GetDCSGroup()
 self:F3()

--  local ClientData = Group.getByName( self.ClientName )
--    if ClientData and ClientData:isExist() then
--        self:T( self.ClientName .. " : group found!" )
--        return ClientData
--    else
--        return nil
--    end

   local CoalitionsData = { AlivePlayersRed = coalition.getPlayers( coalition.side.RED ), AlivePlayersBlue = coalition.getPlayers( coalition.side.BLUE ) }
   for CoalitionId, CoalitionData in pairs( CoalitionsData ) do
       self:T3( { "CoalitionData:", CoalitionData } )
       for UnitId, UnitData in pairs( CoalitionData ) do
           self:T3( { "UnitData:", UnitData } )
           if UnitData and UnitData:isExist() then

               local ClientGroup = Group.getByName( self.ClientName )
               if ClientGroup then
                   self:T3( "ClientGroup = " .. self.ClientName )
                   if ClientGroup:isExist() then 
                       if ClientGroup:getID() == UnitData:getGroup():getID() then
                           self:T3( "Normal logic" )
                           self:T3( self.ClientName .. " : group found!" )
                           return ClientGroup
                       end
                   else
                       -- Now we need to resolve the bugs in DCS 1.5 ...
                       -- Consult the database for the units of the Client Group. (ClientGroup:getUnits() returns nil)
                       self:T3( "Bug 1.5 logic" )
                       local ClientUnits = _DATABASE.Groups[self.ClientName].Units
                       self:T3( { ClientUnits[1].name, env.getValueDictByKey(ClientUnits[1].name) } )
                       for ClientUnitID, ClientUnitData in pairs( ClientUnits ) do
                           self:T3( { tonumber(UnitData:getID()), ClientUnitData.unitId } )
                           if tonumber(UnitData:getID()) == ClientUnitData.unitId then
                               local ClientGroupTemplate = _DATABASE.Groups[self.ClientName].Template
                               self.ClientID = ClientGroupTemplate.groupId
                               self.ClientGroupUnit = UnitData
                               self:T3( self.ClientName .. " : group found in bug 1.5 resolvement logic!" )
                               return ClientGroup
                           end
                       end
                   end
--                else
--                    error( "Client " .. self.ClientName .. " not found!" )
               end
           end
       end
   end

   -- For non player clients
   local ClientGroup = Group.getByName( self.ClientName )
   if ClientGroup then
       self:T3( "ClientGroup = " .. self.ClientName )
       if ClientGroup:isExist() then 
           self:T3( "Normal logic" )
           self:T3( self.ClientName .. " : group found!" )
           return ClientGroup
       end
   end
   
   self.ClientGroupID = nil
   self.ClientGroupUnit = nil
   
   return nil
end 


-- TODO: Check DCSTypes#Group.ID
--- Get the group ID of the client.
-- @param #CLIENT self
-- @return DCSTypes#Group.ID
function CLIENT:GetClientGroupID()

 if not self.ClientGroupID then
   local ClientGroup = self:GetDCSGroup()
   if ClientGroup and ClientGroup:isExist() then
     self.ClientGroupID = ClientGroup:getID()
   else
     self.ClientGroupID = self.ClientID
   end
 end

 self:T( self.ClientGroupID )
   return self.ClientGroupID
end


--- Get the name of the group of the client.
-- @param #CLIENT self
-- @return #string
function CLIENT:GetClientGroupName()

 if not self.ClientGroupName then
   local ClientGroup = self:GetDCSGroup()
   if ClientGroup and ClientGroup:isExist() then
     self.ClientGroupName = ClientGroup:getName()
   else
     self.ClientGroupName = self.ClientName
   end
 end

 self:T( self.ClientGroupName )
   return self.ClientGroupName
end

--- Returns the UNIT of the CLIENT.
-- @param #CLIENT self
-- @return Unit#UNIT
function CLIENT:GetClientGroupUnit()
   self:F()

   local ClientGroup = self:GetDCSGroup()
   
   if ClientGroup and ClientGroup:isExist() then
       return UNIT:New( ClientGroup:getUnit(1) )
   else
       return UNIT:New( self.ClientGroupUnit )
   end
end

--- Returns the DCSUnit of the CLIENT.
-- @param #CLIENT self
-- @return DCSTypes#Unit
function CLIENT:GetClientGroupDCSUnit()
   self:F2()

 local ClientGroup = self:GetDCSGroup()
 
 if ClientGroup and ClientGroup:isExist() then
   return ClientGroup:getUnit(1)
 else
   return self.ClientGroupUnit
 end
end

 

 

 

 

Check the code here:

[FlightControl]

I might better modify the script to check which unit in the spawned Group is still alive at the moment I save the mission status. Anyway I'm looking forward to see your solution :)

 

 

This is the function you may want to check out:

 

--- Creation of a Crash Event.
-- @param #BASE self
-- @param DCSTypes#Time EventTime The time stamp of the event.
-- @param DCSObject#Object Initiator The initiating object of the event.
function BASE:CreateEventCrash( EventTime, Initiator )
   self:F( { EventTime, Initiator } )

   local Event = {
       id = world.event.S_EVENT_CRASH,
       time = EventTime,
       initiator = Initiator,
       }

   world.onEvent( Event )
end

You can find it here:

 

https://github.com/FlightControl-Master/MOOSE/blob/master/Moose/Base.lua

 

From line 300.

 

Note that the usage of world.onEvent( Event ) is undocumented, but found the function browsing through the DCS code...

[FlightControl]

Check out this post:

 

http://forums.eagle.ru/showthread.php?t=165254

 

... no comments ...

 

Rik, Chizh and other ED team members have communicated they are aware of all the errors mentioned and will be fixed during future releases of DCS world. But no timing commitments.

[FlightControl]

Is this confirmed?

 

cause I'm trying as hard as possibile to make DAWS Save Mission to work with spawned units but I need to rely on mist DBs to be successfull.

 

If so, I might halt developing that part and focus on other areas of improvement...

 

Check out the DATABASE class of MOOSE...

And tell me what you need...

 

http://flightcontrol-master.github.io/MOOSE/Documentation/Database.html

 

FC

[chromium]

Don't worry I'll find a way to solve it, but thanks for the help and for the work you're doing for the community ;).

 

If I'll get stuck somewhere expect a PM :p

[Grimes]

what is the workaround?

 

The workaround is using databases generated from the mission file to get the data. Client group and unit ids/names can't be changed like AI can. So if you know the name of the group or the unit you can parse something like mist.DBs.[whatever]byName to find out information for that group/unit.

 

 

 

Gents. When I was testing the Respawn function in the moose framework, I got a crash after the last dcs version update. Suddenly a function that used to work did not work anymore... The original logic was that the respawn function would just execute a coalition.addGroup() without checking if there was already a group with the same name alive or not. When there was already a group, dcs would nicely replace the group with the new spawned group. But after the dcs update, the coalition.addGroup() call would crash. I had to specifically write a logic to destroy the existing group first.

 

The game crashes or the script "crashes" causing an error or just stops at that line? There is a big difference in meaning between the two. Also which version and any specific object type you are spawning? I tried it in 1.5.3 and the tester version with aircraft and ground vehicles, it worked just fine.

[SNAFU]

For me I would like to know, how far the bug with getGroup() for MP reaches.

 

F.e. is group:destroy() also causing crash if group is an MP client etc.?

 

I wrote a script to control our squadron training and campaign template, which works in singleplayer but somewhere crashes (first the script, then the client and then the server, usually in this order) in MP and it is hard to isolate the cause in the 13.000 lines if I cannot figure out, what is related to the getGroup() bug what is related to other bugs, since they only happen in mulitplayer.

Edited May 4, 2016 by SNAFU

[FlightControl]

The bug reaches all the way.

 

ALL group functions with an underlying client are not working. In mp. They do work in way single player. On top, lua predicates are not working neither.

[Grimes]

This probably belongs more in the mist thread since its not entirely based on scripting engine issues.

 

Could this be the reason dynamically spawned infantry (CTLD) not appearing in

mist.makeUnitTable({"[blue][vehicle]"})

and

[color=#2C2D30][font=Slack-Lato]mist.DBs.aliveUnits[/font][/color]

I can still force the table to update using a "manual" PLAYER LEAVE UNIT event though.

Also i noticed the birth events for the spawning infantries is there, but it has a time tag of 0 (10 mins into the mission). Can that be causing the DCS database to ignore these events?

 

mist.makeUnitTable doesn't rely on the aliveUnits DB, instead it just uses mist.DBs.units. The aliveUnits table is updated based on the contents of mist.DBs.unitsByNum.

 

I'm trying as hard as possibile to make DAWS Save Mission to work with spawned units but I need to rely on mist DBs to be successfull.

 

The only value in aliveUnits that is updated, aside for whether it is alive or dead, is the "pos" value. The other values are strictly a copy of whatever is in mist.DBs.unitsByNum.

 

That said I have discovered an issue when groups are spawned in that are using existing data like groupName/Id and unitName/Id are not fully updating the DBs with new information. I'm investigating what is going on with it.

[SNAFU]

The bug reaches all the way.

 

ALL group functions with an underlying client are not working. In mp. They do work in way single player. On top, lua predicates are not working neither.

 

I see. Thanks for the clarification. I hoped only some aspects of the getGrou() function was bugged.

[Pikey]

Really hope the thing you saw was the same thing that stopped our script from detecting units in a zone.

This probably belongs more in the mist thread since its not entirely based on scripting engine issues.

 

 

 

mist.makeUnitTable doesn't rely on the aliveUnits DB, instead it just uses mist.DBs.units. The aliveUnits table is updated based on the contents of mist.DBs.unitsByNum.

 

 

 

The only value in aliveUnits that is updated, aside for whether it is alive or dead, is the "pos" value. The other values are strictly a copy of whatever is in mist.DBs.unitsByNum.

 

That said I have discovered an issue when groups are spawned in that are using existing data like groupName/Id and unitName/Id are not fully updating the DBs with new information. I'm investigating what is going on with it.

[Grimes]

Really hope the thing you saw was the same thing that stopped our script from detecting units in a zone.

 

Do you have a small sample of it being broken that I could test it with?

[Pikey]

Yes i will pm you a miz file with steps to repro and observed/expected. We had to use the witchcraft interpreter to really see it.

Do you have a small sample of it being broken that I could test it with?

[SNAFU]

It seems that latest bug, which prevents ground AI (dynamically spawned) to engage, also prevents the ground group to take new tasking.

 

Or is it only me, who experiences that AI does not take new task via Controller.setTask() ?

[Grimes]

I'll check it out. It may depend on the task, I was able to get AI that toggled on/off to accept a new waypoint but obviously they still wouldn't shoot at anything.

[SNAFU]

Thanks. I use Controller.setTask() for groups created via Coalition.addGroup() to give them a new route to move along on roads. Previously they accepted thes new routes, now (current release version) they just won´t move or just turn in circles around their spawn point.

[Grimes]

If its on the Caucuses then that is a new issue for that map. If its on Nevada then its known. Basically the waypoint has to be precisely on a road unlike before when the AI would just find the nearest road to that point. If the On-road waypoint is off of a road the AI will just go in circles.

[Steggles]

Can anyone tell me if - StaticObject.destroy() not functional on cargo objects - Fixed internally - has made it to 1.5 stable yet? I can't get to my DCS computer for a few days to test it.

[SNAFU]

If its on the Caucuses then that is a new issue for that map. If its on Nevada then its known. Basically the waypoint has to be precisely on a road unlike before when the AI would just find the nearest road to that point. If the On-road waypoint is off of a road the AI will just go in circles.

 

That is a good description of what is happeing now on the Caucasus map.

[FlightControl]

Not sure about destroying clients.

 

 

 

There is no isExist function for units, so it is only relevant to groups.

 

 

 

 

 

There is an isExist function for units. I use it extensively.

 

Sent from mTalk

[FlightControl]

It seems that latest bug, which prevents ground AI (dynamically spawned) to engage, also prevents the ground group to take new tasking.

 

Or is it only me, who experiences that AI does not take new task via Controller.setTask() ?

 

Having the same problem :-(

 

http://forums.eagle.ru/showthread.php?p=2802138#post2802138

 

Just posting this for completeness ...

 

sv.

[SNAFU]

Ground groups spawned via script are definitely useless at the moment. Late activation does not seem to work as it should either and air groups seem to be affected the same and do not complete their waypoints, nor do they attack.

[FlightControl]

Ground groups spawned via script are definitely useless at the moment. Late activation does not seem to work as it should either and air groups seem to be affected the same and do not complete their waypoints, nor do they attack.

 

 

 

 

 

Grimes talked about an 'AI BUG'. Maybe setting the AI on after the spawn will work... I'll try this evening if this is a solution.

 

Sent from mTalk

[SNAFU]

Just tested with OB. The same as with the current release version.

 

I let them spawn via Coalition.addGroup() and give them a task via Controller.setTask() and the group starts to form in the formation, but does not move to the waypoint. The units of the group just go in circles seem to form up, but never do.

 

This worked in previous release version. I do not think this is related to Group AI On/Off, because a group with AI off wouldn´t move at all and just be static.

 

This happens with all ground groups spawned via Coaltion.addGroup(). They just don´t take any orders or tasks also not via Combined Arms.

[Ciribob]

Just tested with OB. The same as with the current release version.

 

I let them spawn via Coalition.addGroup() and give them a task via Controller.setTask() and the group starts to form in the formation, but does not move to the waypoint. The units of the group just go in circles seem to form up, but never do.

 

This worked in previous release version. I do not think this is related to Group AI On/Off, because a group with AI off wouldn´t move at all and just be static.

 

This happens with all ground groups spawned via Coaltion.addGroup(). They just don´t take any orders or tasks also not via Combined Arms.

No worries its reported and ED have fixed it on an internal build already.