FlightControl

BUG 1 - Client groups with more than one client not accessible in multiplayer. BUG 1: Client groups not accessible in multiplayer for groups containing more than one client. Description: Group lua functions of remote Client (groups) are not working. They return "group does not exist". Consequence: <URGENT> This bug is preventing missions to be designed using scripting where groups have more than one client to fly co-op missions. References of posts on the forum: http://forums.eagle.ru/showthread.ph...ght=client+bug Done this for a dedicated bug report on this on the forums.

Man ... floating cargo? Good find. +1

Hi Snacko, Those who are having a VR seem to have issues with the menu. the size of the menu panel is too small, and text is cropped from the menu panel if the amount of menus is too large. Would you be able to do something on this by making the menu panel larger? Sven

sorry, duplicate

Gents, May I ask something? The smoke size has been increased significantly since DCS 2.5, which is really a good idea that this was done. However, smoke can not only be generated in the ME using smoke actions, but they can also be triggered using the lua scripting API of DCS world. function trigger.action.smoke(Vec3 point, enum trigger.smokeColor color) A call to this method creates a smoke marker. Smoke can and is used for different things by mission designers. Not only to indicate targets, but also for indicating certain achievements, even ownership of zones etc. Would it be an unreasonable question to validate with the ED team of the DCS API could be extended to include two additional capabilities: 1. To make the size of the smoke larger or smaller. We've seen that when you are close to cargo, you can select a cargo from the menu, and the cargo will smoke, but much smaller than the usual one. 2. To stop smoking with an additional command. Is this possible? We think it is, because when you get closer to the cargo that is smoking, that smoking stops... Does anybody know if these methods are already available in DCS world? If yes, what would be the syntax? If no, would it make sense to ask for an extension to the sim? FC

Gents, May I ask something? The smoke size has been increased significantly since DCS 2.5, which is really a good idea that this was done. However, smoke can not only be generated in the ME using smoke actions, but they can also be triggered using the lua scripting API of DCS world. function trigger.action.smoke(Vec3 point, enum trigger.smokeColor color) A call to this method creates a smoke marker. Smoke can and is used for different things by mission designers. Not only to indicate targets, but also for indicating certain achievements, even ownership of zones etc. Would it be an unreasonable question to validate with the ED team of the DCS API could be extended to include two additional capabilities: 1. To make the size of the smoke larger or smaller. We've seen that when you are close to cargo, you can select a cargo from the menu, and the cargo will smoke, but much smaller than the usual one. 2. To stop smoking with an additional command. Is this possible? We think it is, because when you get closer to the cargo that is smoking, that smoking stops... Does anybody know if these methods are already available in DCS world? If yes, what would be the syntax? If no, would it make sense to ask for an extension to the sim? FC

@ED, The USA unit "SAM Stinger comm" has a maximum speed of 4 mps but cannot move! It should have a maximum speed value of 0 mps in the descriptor... It confuses the logic in scripts... Pls correct this! Test mission attached. FC BUG-010 - SAM Stinger comm cannot move.miz

@ED, When a route of a ground vehicle is placed by a human planer, using the map (F10) and "Set Path" button, the Command "Stop Route" is not working!!! The command is given, but the vehicle just drives like nothing happened. local CommandStopRoute = { id = 'StopRoute', params = { value = StopRoute, }, } To resimulate it, i've attached a demo mission. - Start the mission, select game master. - There are 2 units. The AI is routed automatically, the HUMAN you need to route. - You'll see the AI vehicle driving towards the white flag. When it enters the zone, it will stop. - Route the HUMAN vehicle to the white flag using F10 map view and Set Path button. The vehicle should stop entering the zone. But it does not :-( This is a critical problem. How do I hold vehicles that were commanded by players? Anybody can help? Sven BUG-009 - Stop Route not working for human paths.miz

Are there people who can help with testing the cargo transportation and CSAR tasking? - Slingload - Crates - Infantry - Packages - Vehicles pls join on discord https://discord.gg/yBPfxC6 channel #task-cargo-transport FC

Nope. world.searchObjects does not retrieve the ejected pilot within the perimiters of the plane ... Only the plane is shown as found. I search using: { Object.Category.UNIT, Object.Category.STATIC, Object.Category.SCENERY, Object.Category.WEAPON } ---- local PilotUnit = nil self:ScheduleOnce( 1, function() -- Search for the ejected pilot local PlaneCoord = PlaneUnit:GetCoordinate() local SphereSearch = { id = world.VolumeType.SPHERE, params = { point = PlaneCoord:GetVec3(), radius = 100, } } --- @param Dcs.DCSWrapper.Unit#Unit FoundDCSUnit -- @param Wrapper.Group#GROUP ReportGroup -- @param Set#SET_GROUP ReportSetGroup local FindEjectedPilot = function( FoundDCSUnit ) local UnitName = FoundDCSUnit:getName() self:E( { "Units near Plane:", UnitName } ) PilotUnit = UNIT:Register( UnitName ) return true end world.searchObjects( { Object.Category.UNIT, Object.Category.STATIC, Object.Category.SCENERY, Object.Category.WEAPON }, SphereSearch, FindEjectedPilot ) self.CSAR[CSARName] = {} self.CSAR[CSARName].PilotUnit = PlaneUnit self.CSAR[CSARName].Task = nil end ) So I'll just spawn an infantry as a replacement. Maybe a point for ED to pickup in a future release. Make the ejected pilot a manageable group within the sim ... If anyone can help, by my guest ...

In dcs 2.5... When a crate is destroyed using the destroy() method, does it explode? When a barrel cargo is destroyed using the destroy() method, does it explode? The barrel explodes in my testing and creates a dead event... Sent from my SM-N950F using Tapatalk

In DCS 2.5, using StaticObject.destroy() will destroy a cargo object. I mean, it will EXPLODE!!! Is this normal. Anybody has experience with using destroy() on cargo objects? It generates an S_EVENT_DEAD when destroy is called. This is highly unusual. ...

Check here ... https://www.quora.com/Why-is-Lua-so-fast/answer/Hanno-Behrens-2?share=0bc52161&srid=uWIAE This us a great answer. Fc Sent from my SM-N950F using Tapatalk

Is there a update on this problem? Sent from my SM-N950F using Tapatalk

Interesting, because it used to be like that! In the previous versions of DCS, when you would land on an oil rig or another object (like a building block), it used to generate a landing event.

@ED, There is an annoying problem with multi player in DCS, which we have been heavily investigating ourselves. It has to do with hidden units or groups that are respawned. The units show up on the connected DCS World clients on the map view (F10), in a multi player setup, while they should be hidden on the map When you flag a group as hidden in the mission editor, and run the mission in SP, all works fine. When you run in MP and connect through a client, all works fine. The group is hidden. The problem starts when you "respawn" that group passing the exact same group definition structure as defined in the mission editor (with the flag .hidden = true ). In SP respawning of hidden groups work fine. The units of the group work fine after the respawn. But when the same mission is run in MP, and connected with a client, the respawned units WILL show on the MAP (F10) and are not hidden! Find attached the demonstration mission that illustrates this: The mission is very simple. The blue tanks are set to hidden. When the red tanks destroy the blue tanks, the blue tanks group is respawned into zone ZONEVEHICLE1. When you run this mission on a server, and connect with a client, you'll see on the client side the blue units appearing after a minute or two (they first need to be destroyed). The red tanks are set to "immortal" to they will keep on shooting an the respawned blue tanks. This is what you see on the SERVER in MAP view (F10). The units are hidden. And this is the error: You see the blue units appearing on the client side! Maybe this error has already been reported. If not, please investigate and try to fix this. The respawning is done with a mist function, just to make it clear. But MOOSE and mist respawning methods have the same effect. The issue is significant for those mission designers who want to show certain units but hide others. kind regards, FC GRP-620 - Respawn MOOSE and MIST.miz GRP-620 - Respawn MOOSE and MIST.lua

The main GITHUB web page readme section of the MOOSE repositories have been updated (and are still in revision). Have a look as it may contain some new info for you. Mostly is done for the development optimization. Note that now the MOOSE framework is composed out of a number of repositories which are edited or generated. The generated ones contain artefacts. https://github.com/FlightControl-Master/MOOSE You can still download the latest version from the MOOSE release page. kind regards, Sven

You mean, for TASK_CARGO_TRANSPORT? Yes you can! Get onto discord and we can discuss!

Move of MOOSE documentation pages Guys, The documentation pages have moved to: http://flightcontrol-master.github.io/MOOSE_DOCS/ So _DOCS is added to the URL! There is an automatic redirect on the old utl to the new location, but any detailed pages won't be accessible anymore. FC

You're from Belgium?

Which version of DCS and which version of MOOSE?

I vaguely remember that issue. I had it too. Are you sure you are using the 32-bit or the 64-bit versions of JAVA RTM and Eclipse? Because when you mix them, I think you get this issue. FC

Thanks for sharing this. When the time is right I will try this. +1

These flexible functions have already been made and the result is highly inefficient, although the logic behind those functions are highly efficient including refresh logic that works with tagging and time stamps. Why? When you change for a large amount of group(s) the menu items, you need to remove those menus and create new ones... but for all those groups... If you have 20 clients connected to the host, then all these menu updates need to be synched over the network too... Sent from my SM-N950F using Tapatalk

I know, but this does not make sense for a coalition level menu. Sent from my SM-N950F using Tapatalk