DCS world bugs for MISSION DESIGN, ED team: please evaluate...

[FlightControl]

Dear ED team,

 

I am a big fan of DCS world. I've been developing over the months/years a couple of classes and a framework to do some very advanced stuff in DCS world, using LUA scripting.

 

Unfortunately, there are some annoying outstanding bugs in DCS world related to some lua functions, which prevent advanced scripts to be functioning correctly. Some of these bugs are already outstanding for a couple of months, if not years, with no fix in sight.

It seems that the ED team has "lost the north" when it comes to bug fixes for mission designers.

 

What i am kindly asking is: Would your team be able to re-evaluate the priorities of some of these bugs please. For your clarity I've listed the bug and the consequence of the bug...

 

Note; these bugs are related to MISSION DESIGN, so i left out the bugs related to User Interface, DCS Modules, etc. I only took into consideration those bugs that prevent good mission design.

 

Please, please, ... please ... evaluate the underlying:

 

 

 

BUG 1: Client groups not accessible in multiplayer.

 

ID at DCS: 31682

 

Description: Group lua functions of remote Client (groups) are not working. They return "group does not exist".

 

Consequence: <URGENT> This bug is really annoying and results in many scripts not working. Some people have been able to develop a workaround this bug using the env environment information to retrieve Group information. If you enquire for example a Group with an active client on the server (player logged into the client remotely) you can't even retrieve the name of that group. The function PlaneGroup:getName() won't work because the function will return that the group does not exist!!!

 

References of posts on the forum:

http://forums.eagle.ru/showthread.php?t=159199&highlight=client+bug

 

 

BUG 2 fixed in 1.5.4: StaticObject.destroy() not functional on cargo objects

 

ID at DCS: 29501

 

Description: This bug is around now for a while. When you call the destroy() function on a cargo object, the cargo object stays alive in the simulator. Normally it should dissapear from the simulator, and it doesn't at the moment! I've created a test mission to demonstrate this behaviour!

 

Consequence: <HIGH> This bug does not allow a proper logic for scripts to orchestrate dynamic spawing and destruction of CARGO objects. Which is a shame. I believe this bug is around since 1.2... Please have a look at this bug...

 

References of posts on the forum:

http://forums.eagle.ru/showthread.php?t=140917&highlight=cargo+destroy

 

 

 

 

BUG 3: coalition.addGroup cant specify parking spots for aircraft to spawn at

 

ID at DCS:29188

 

Description: <MODERATE> This bug is also around for a while now, if not years. Can you please have a look that we can place an air unit in a specified parking spot? When units get dynamically spawned at airfields, these units are spawned at random parking spots.

 

Consequence: It is not so urgent, but annoying. Can you please have a look at this?

 

References of posts on the forum:

http://forums.eagle.ru/showthread.php?t=135811&highlight=dynamic+spawn+parking

 

 

 

 

BUG 4: Crashed air units cannot be destroyed using Group.destroy(AirGroup) or Unit.destroy(AirGroup)

ID at DCS: don't know.

 

Description: <URGENT>When an air unit has crashed ( a S_EVENT_CRASH has occurred ), and the unit is burning, units cannot be destroyed anymore. These units will keep being visible and will keep burning... This in single and multi player.

IMPORTANT Note: The destroy() functions for burning groups and units worked on previous DCS world versions (i believe it worked on DCS world 1.2.6). And then suddenly this stopped working completely.

 

Consequence: I believe this is an important bug to look at. Some of our scripting talents have build a cleanup function to keep or cleanup airbases clean in running multi-player missions. When units crash at airbases, the complete airbase will stop functioning. By monitoring the health status of units at these airbases using lua scripting, and destroying crashed or dead units, the airbase used to be able to keep on running and operating normally. Please have a look at this bug, it is a really annoying thing and i believe most of the mission design will want to have this fixed.

 

References of posts on the forum:

http://forums.eagle.ru/showthread.php?t=153773&highlight=destroy+burning

 

 

 

BUG 5: Lua Predicates not functional in the mission editor

 

ID at DCS: 32145

 

Description: This one i find hard to believe, but it is true. The LUA predicate functionality is completely NOT WORKING in DCS world. Try to add an evaluation function on a group waypoint action... Good luck.

 

Consequence: Missions using LUA predicates are not working properly. Can you please have this looked at?

 

References of posts on the forum:

 

http://forums.eagle.ru/showthread.php?t=148392&highlight=lua+predicate

 

 

 

 

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

ID at DCS: 24826

 

Description: It is even worse. Dynamically spawned AI in multiplayer, does not show at the CLIENT machine (in the F10 map). Although they should be visible. Strangely enough, when you exit that running mission on the CLIENT (server still running) and then rejoin that server, these spawned AI units are now fully visible! So, if AI is dynamically spawned, it seems that AI is not sent through at the client side, although within the DCS world, these units are functional and completely acting normal.

 

Consequence: Missions become confusing. People may not notice that units are spawned on the CLIENT when the mission is running. As such, it is hard for these players to take the role of tactical commander on the F10 map and command ground units for dynamically spawned AI.

 

 

 

BUG 7 - FIXED: It seems that the function Unit.getPoint() is not working.

 

ID at DCS: <unknown>

 

Description: Unit.getPoint is not working, but Unit.getPosition does. A workaround at the moment is to use Unit.getPosition().p to get the Vec3 "point" of a unit ...

 

Consequence: Existing scripts won't work, unless they are modified...

References of posts on the forum:

 

http://forums.eagle.ru/showthread.php?t=154547&highlight=getPoint

 

 

BUG 8: getPlayerName() is not working for ground CLIENT units.

 

 

ID at DCS: <unknown>, but reported by GRIMES.

 

Description: When having a server setup running a test mission, and, having a client machine logging into the server and selecting a ground unit, and jumping into it (RALT-J), the function Unit:getPlayerName() DOES NOT return anything. It returns a blank string ...

 

Consequence: <MODERATE> Got a scoring mechanism made, but because players joining ground units (with ALT-J) cannot have their player names retrieved, their actions cannot be followed ... Unfortunately, and the scoring cannot be calculated...

References of posts on the forum:

 

http://forums.eagle.ru/showthread.php?t=161854&highlight=getPlayers

 

 

BUG 9 - Not a bug. See post 11 in this thread: Controller.isTargetDetected() does not work. returns always false.

 

ID at DCS: <unknown>

 

References of posts on the forum:

http://forums.eagle.ru/showpost.php?...5&postcount=69

 

Explanation of the fix: http://forums.eagle.ru/showpost.php?p=2756153&postcount=11

 

 

BUG 10 tested in 1.5.4 is fixed: ground units don't move when spawned.

 

ID at DCS: <unknown>, but reported by GRIMES.

 

DCS World version when introduced: DCS 1.5.3.53279 Update 7

 

Description: When a new ground unit gets spawned, using coalition.addGroup(), the ground unit does not start moving and follow its planned route.

 

Consequence: <URGENT> has impact on current scripting logics.

 

References of posts on the forum: http://forums.eagle.ru/showthread.php?t=168046

 

 

BUG 11: Cannot destroy an active unit with skill level client, occupied by a player in multiplayer, with the client logged into the server as a client.

 

ID at DCS: <unknown>, net yet reported.

 

DCS World version when introduced: DCS 1.5.3.53279 Update 7

 

Description: There is no way to destroy an active client unit occupied by a player. When you use the Unit API destroy(), the client is not removed from the simulator. There is no possibility to use the Group API destroy(), when you do Unit.getGroup( Client ), because of the CLIENT GROUP BUG (see bug).

 

Consequence: <URGENT> has impact on current scripting logics.

 

References of posts on the forum:

 

 

BUG 12: in last version of DCS 1.5.4, when infantry units touch player helicopter, they can destroy player helicopter. Strange !!! what may be true for heavy vehicles cannot be true for a "little" man !

 

ID at DCS: <unknown>, net yet reported.

 

DCS World version when introduced: DCS 1.5.4

 

Description: in last version of DCS 1.5.4, when infantry units touch player helicopter, they can destroy player helicopter. Strange !!! what may be true for heavy vehicles cannot be true for a "little" man !

 

Consequence: <MODERATE> has impact on current mission scenarios.

 

I hope that these bugs can be considered to be fixed.

Would it be possible to have some kind of timeline when we can expect a fix for these errors from the ED dev team?

 

For compleness i also refer to this thread of Grimes: http://forums.eagle.ru/showthread.php?t=147792

 

Also, can the community add other bug reports to mission design that i've not captured in the above post? Please verbose following the same format please. Note that i've sent this post directly to the ED development team for evaluation... Trying to push a bit the fixes forward, just trying ... (don't shoot the messenger).

 

 

kind regards,

FC

Edited November 6, 2016 by FlightControl

[Quax456]

:thumbup:

 

If ED would get this fixed, it would be much appreciate.

 

This Bugs within the SSE are causing "Workaround" after "Workaround" and make me crazy with raising amount of time... :cry:

 

So please ED take a deep look.

 

Regards

[piXel496]

Yes, the deteriorating functionality of the DCS script-engine since 2015 is rather unfortunate. Please keep us informed if you have news.

 

 

 

 

 

 

 

 

:thumbup:

.

Edited April 21, 2016 by piXel496
+1

[Grimes]

BUG 2: StaticObject.destroy() not functional on cargo objects

BUG 7: It seems that the function Unit.getPoint() is not working.

 

Two was internally fixed on a tester build recently, it hasn't made its way to either 1.5.3 or 2.0.2 yet.

 

Unit.getPoint() seems to be working in 1.5.3. and 2.0.2. I think it got ninja patched or wasn't an issue when I tested it on the tester build when it was initially reported.

[wolle]

Thanks flightcontrol for bringing attention back to these issues. These bugs have broken so many scripted missions. Add to the list that lua predicate and initialization script functions don't work. These bugs have been around for so long, and not a single word from ED if they are planning to fix them.

[FlightControl]

Unit.getPoint() seems to be working in 1.5.3. and 2.0.2. I think it got ninja patched or wasn't an issue when I tested it on the tester build when it was initially reported.

 

Hi Grimes,

 

Thanks for responding. Quax and myself retested the getPoint() function on the latest version of DCS world 1.5.3 (after the update today) and it seems that this function is working now. The problem arose in a multiplayer setup when enquiring the position of a client unit with Unit.getPoint()... See the attached mission how we tested the function ...

 

So, we can flag off BUG 7. I'll update post #1 in this threat.

 

That being said, we have another bug for you in the scripting engine... Concerning object detection (forgot to mention that). I'll add the bug description in a sequent post and i'll also add it at the first post...

2016-04-22 - DCS 1_5_3 - getPoint BUG.miz

Edited April 22, 2016 by FlightControl

[FlightControl]

Dear ED team, would like to add:

 

BUG 9: Controller.isTargetDetected() does not work. returns always false.

 

ID at DCS: <unknown>

 

Description: When you call the function Controller.isTargetDetected() after you got valid results from the function Controller.getDetectedTargets, this function returns false.

Consequence: Two things. First people will have used this function in their scripts and now their missions and their scripts will fail. Second: as a workaround, people will start making "their own" distance, visible etc logic, which is not what a good mission should do! At least, that is what i did in my logic here:

 

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

References of posts on the forum:

 

http://forums.eagle.ru/showpost.php?p=2735185&postcount=69

 

Hopefully this bug can also be traced down...

 

kind regards,

FC

[FlightControl]

Two was internally fixed on a tester build recently, it hasn't made its way to either 1.5.3 or 2.0.2 yet.

 

Hi Grimes & ED team,

 

Thanks for the communication on BUG #2, related to destroying cargo. Please let us know when it is released.

 

Sven

[Grimes]

Controller.isTargetDetected() does not work. returns always false.

 

Unable to replicate. See my attached mission for how I tested it.

controller_getDetectedTargets_isTargetDetected.miz

[FlightControl]

Thanks. Ill check it. Because if I can fix this, it would be great!

[FlightControl]

Unable to replicate. See my attached mission for how I tested it.

 

@Grimes,

 

Thank you for the example how the function isTargetDetected works:

 

if Unit.getByName('b1') and Unit.getByName('b1'):isExist() == true then
   local _u = [color=Red][b]Unit.getByName('b1'):getController()[/b][/color]
   local msg = {}
   for i, detected in pairs(_u:getDetectedTargets()) do
       msg[#msg+1] = '\n ' .. Unit.getName(detected.object)
       for name, _val in pairs(Controller.Detection) do
           local val = Controller.isTargetDetected(_u, detected.object, Controller.Detection[name])
           msg[#msg+1] = '\n       ' .. name .. ' ' .. tostring(val)
       end
   end
   
   trigger.action.outText(table.concat(msg), 10, true)
end

 

I mistakenly used the Controller object of the Group instead of the controller of the Unit. Actually, i was not aware that there is also a separate controller for a Unit...

 

:thumbup:

 

By this I understand now how to correctly use the isTargetDetected method of a Unit Controller :-)

 

I'll delete the bug report from the first post, and i hope that other will learn from this experience also. That's why i documented it.

 

Now, just as a side comment. The documentation of DCS world is a bit confusing here. It is not clearly specified that the controller of the Unit should be used here.

 

http://wiki.hoggit.us/view/Part_2#Controller

 

thanks and kind regards,

FC

[chromium]

Amazing work for this thread, FlightControl, thanks!

[Grimes]

I mistakenly used the Controller object of the Group instead of the controller of the Unit. Actually, i was not aware that there is also a separate controller for a Unit...

 

Thats why I mentioned it in the more organized documentation. Though it probably needs to be more clear which functions work with which controller, but that requires testing to figure out for sure. The unit controller is actually quite powerful because you can control individual aircraft with it. I used it to test the AIs ability to drop multiple JDAMs per attack run by generating a smiley face target and distributing the coordinates to a flight of F-15Es, giving each its own mission task.

 

 

Amazing work for this thread, FlightControl, thanks!

 

Its not like a list didn't exist... Personally I'd prefer for this thread to just be a separate place to raise complaints and desires for these bugs to get fixed, while actual reporting to be done in either the sticky or new threads in the mission editor sections for 1.5/2.0.

[chromium]

Personally I'd prefer for this thread to just be a separate place to raise complaints and desires for these bugs to get fixed, while actual reporting to be done in either the sticky or new threads in the mission editor sections for 1.5/2.0.

 

I didn't know about that! subscribed now.

[FlightControl]

Its not like a list didn't exist... Personally I'd prefer for this thread to just be a separate place to raise complaints and desires for these bugs to get fixed, while actual reporting to be done in either the sticky or new threads in the mission editor sections for 1.5/2.0.

 

Hi Grimes,

 

Thanks for the feedback. I agree with your sticky list to consolidate the bugs there. The reason why I wrote this threat was to re-emphasize and ask kindly ED for some considerations to reprioritize some bug fixes. It can be very true that some of these bugs are hard to solve at this moment, until the true merged DCS world will emerge. However, that being said, some of these bugs are already outstanding for years, and no fix in sight. So, that is the reason I took the effort to explain a bit more in detail the consequences and (re-)ask for fixes ...

 

I mean, we get tons of fixes every new patch on modules etc, but it has been a while that there were fixes reported regarding the scripting engine.

 

BUG #1, BUG #4, BUG #5 and BUG #8 are the ones that i really hope can be fixed soon. It will serve the community and also, it will make the multiplayer lua scripted missions working again, because at the moment most of them won't work due to BUG #1 ...

 

If you could get BUG #8 somehow also reflected in your documentation?

It would be good to know what ED bug report number is assigned.

(Maybe you can modify the your first post in your sticky).

 

Now, for BUG #1 i wrote a "workaround". Find below the code (function) i wrote to get around this bug in MOOSE:

 

--- 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 

FC

[FlightControl]

Thats why I mentioned it in the more organized documentation. Though it probably needs to be more clear which functions work with which controller, but that requires testing to figure out for sure. The unit controller is actually quite powerful because you can control individual aircraft with it. I used it to test the AIs ability to drop multiple JDAMs per attack run by generating a smiley face target and distributing the coordinates to a flight of F-15Es, giving each its own mission task.

 

Aha! So, you can assign also "mission tasks" to individual units??? Interesting to learn that :D! So, you mean that you can assign each unit of a group a different waypoint plan although they belong to the same Group?

 

That would solve how i can get for example infantry run independently from the formation configuration to the helicopter when boarding.

 

Thanks for the feedback.

[Koriel]

Wow, Like the attention this is getting... It's a huge sim when you take all these different aspects into account.. It's just not all about nice gfx.. ;-)

[Grimes]

Aha! So, you can assign also "mission tasks" to individual units??? Interesting to learn that :D! So, you mean that you can assign each unit of a group a different waypoint plan although they belong to the same Group?

 

That would solve how i can get for example infantry run independently from the formation configuration to the helicopter when boarding.

 

Controlling individual units only works for airplanes and helicopters. I assume it is a byproduct of individual AI aircraft units being able to make their own decisions when low on fuel, attacking specific targets, taking damage, reaction to threats, and so on. And yes you can assign each aircraft its own flight plan. Taking my previous example I actually tested and developed it further in an unreleased mission. I generate a route for the whole flight and at a given waypoint I then assign a series of tasks for individual units except for the flight lead. At the end of their tasks they will form back up.

[FlightControl]

Just a side remark about #9. Thinking about it... So, I use the group controller to get the list of detected targets. But if you want to enquire a specific target, you need to use the Unit controller... It's there any reason why it was designed like that?

[Grimes]

Just a side remark about #9. Thinking about it... So, I use the group controller to get the list of detected targets. But if you want to enquire a specific target, you need to use the Unit controller... It's there any reason why it was designed like that?

 

I need to thoroughly test it so I can make the documentation more accurate, unfortunately KSP 1.1 is mighty distracting. However I can make an educated guess. I think it is more of a check meant to know if a specific unit might be capable of engaging the target. getDetectedTargets at a group level returns a list of targets that are collectively detected by the group. So to unit A it might detect the target via visual or radar, but unit B would only know about it due to datalink. Datalink in this case doesn't specifically mean a datalink system but any form of communications. I think it basically includes radio comms like AWACS, EWR, actual datalink systems, and "group level" communications.

[FlightControl]

Grimes, thanks. Reading your response, what is meant with KSP 1.1?

[chromium]

guess: Kerbal Space Program? XD

[FlightControl]

Added bug 10 in the list:

 

BUG 10: ground units don't move when spawned.

[FlightControl]

Bug 10 in the list seems to be fixed in 1.5.4 beta. Can others test also and confirm this? I'll update the list in the first post.

[FlightControl]

Bug 11 has been added in the list:

 

BUG 11: Cannot destroy an active unit with skill level client, occupied by a player in multiplayer, with the client logged into the server as a client.

 

ID at DCS: <unknown>, net yet reported.

 

DCS World version when introduced: DCS 1.5.3.53279 Update 7

 

Description: There is no way to destroy an active client unit occupied by a player. When you use the Unit API destroy(), the client is not removed from the simulator. There is no possibility to use the Group API destroy(), when you do Unit.getGroup( Client ), because of the CLIENT GROUP BUG (see bug).

 

Consequence: <URGENT> has impact on current scripting logics.

 

References of posts on the forum: