FlightControl

Is nobody reading this??? Come on guys. This is a key requirement.

The Menu API of DCS should be improved a bit, the way menus work. It is great that the SSE provides methods to set menus to: - All players: Path missionCommands.addCommand(string name, Path or nil path, CommandFunction сommandFunction, any argument) - Only players to a coalition: Path missionCommands.addCommandForCoalition(enum coalition.side coalition, string name, Path or nil path, CommandFunction сommandFunction, any argument) - Only players to a group: Path missionCommands.addCommandForGroup(GroupId groupId, string name, Path or nil path, CommandFunction сommandFunction, any argument) The menu system calls the commandFunction, passing the given argument. However, by design, there is a big functionality that is missing in this design. The menu system is not providing to the commandFunction as a parameter the Unit object of the player who selected the menu option. If the Unit object would be passed, that would be a great help. Right now, the only way to know which group has used which menu, is to set a menu option for each group specifically!!!! And this is very bad! That requires a system to remove/add/replace menus constantly when players move from plane to plane in different tasking scenarios. It provides an overkill of menu API calls. We suspect that DCS in a MP environment is not able to handle all these menu relays correctly. On the client side, we see menus disappearing which should be there. So the requirement is that in these menu APIs, if the Unit object (or Group object) would be passed, that would be a great help. It would allow for a much more stable menu system. I suggest to provide as the 2nd parameter to the commandFunction, to pass the Unit object that used the menu option! FC

Just found out that if you load an "old" DCS 1.5.x mission into DCS 1.5.8, it will show you that message box asking you to save the mission. If you DO press save, then you won't get the tempMission.miz file after the run anymore, and the editor will work correctly. But it is still confusing...

- When you load an existing mission, and do "Fly" or "Prepare" in the menus, it asks to save the mission but haven't changed anything! - When you have flown a mission and return, the mission name has changed!!!! Now the mission file name is a tempMission.miz??? This is not a showstopper, but come on... I can't imagine anybody testing this before release??? I hope ED is dedicated to fix these issues... Anybody else having this issue? Sven

Exactly, and now ED will test also and release their fix solving this issue ( following the feedback of ED )... Sent from my SM-N950F using Tapatalk

Guys. Please read carefully the instructions! No testing in MP on the local host!!!! This is indeed like SP. You need a network connection!

@ED, Here is the test mission to test your fix ... Please following the documented test scenario: 2 planes and 2 tanks are located on and near the airport. The test is about checking if S_EVENT_PLAYER_ENTER_UNIT is correctly working in DCS single player and multi player. The test requires you to jump into the 2 planes and into the 2 tanks using CA. Please execute the following scenarios in Single and Multi-Player: 1. Test in Single Player: First we need to get the mission running... To do this, do the following actions: - At mission startup, once you get the slots, press the ESC key... The slot selection window will disappear. - Then press the ESC key again, and in the window, select the menu option "Select Slot". Next, we select the 2 planes... - Select Plane 1 slot. Go to external view. Once you are in the SU-25T, an orange smoke and a message should appear. - Select Plane 2 slot. Go to external view. Once you are in the SU-25T, a red smoke and a message should appear. Next, we select the 2 tanks... Select the MAP view using F10, and: - Select the Tank 1 unit using the arrow. And then press RALT-J which should jump you into Tank 1. Go to external view. Once you are in the Tank, a blue smoke and a message should appear. - Select the Tank 2 unit using the arrow. And then press RALT-J which should jump you into Tank 2. Go to external view. Once you are in the Tank, a green smoke and a message should appear. 2. Test in Multi Player: Run the mission on a server, and connect to the mission with a client... On the client machine, we select the 2 planes... - Select Plane 1 slot. Go to external view. Once you are in the SU-25T, an orange smoke and a message should appear. - Select Plane 2 slot. Go to external view. Once you are in the SU-25T, a red smoke and a message should appear. On the client machine, we select the 2 tanks... Select the MAP view using F10, and: - Select the Tank 1 unit using the arrow. And then press RALT-J which should jump you into Tank 1. Go to external view. Once you are in the Tank, a blue smoke and a message should appear. - Select the Tank 2 unit using the arrow. And then press RALT-J which should jump you into Tank 2. Go to external view. Once you are in the Tank, a green smoke and a message should appear. If all of this is working correctly, then the fix is correctly patched! I've also added the script for those interested how to catch the event ... Kind regards, Sven EVT-105 - UNIT OnEventPlayerEnterUnit Example.miz EVT-105 - UNIT OnEventPlayerEnterUnit Example.lua

Very good news from the homefront @ED. I'll gladly support with a test mission, great!

The release 2.5 can never be an excuse not to solve these kind of issues reported. Those in the DCS community who think that 2.5 will bring a new era in DCS are wrong. This won't be the case. The world turns around and keeps turning. New priorities will always come and will always be there. As long as @ED isn't taking a management decision to focus on these kind of things, it just won't happen. Even when 2.5 is out, which was promised to be delivered since 2015 by the way ... There are always other priorities to be found. And once 2.5 is out, then other priorities will come. I am not saying that 2.5 isn't great, because it is! It IS GREAT. Hat off to the ED team on what you guys are doing there. It is amazing stuff! But please, bare in mind that the experience in your simulation is also coming from mission designers that make great missions. Simulation is about the tactical and strategical experience too, and about dynamism. Those who don't understand this issue, that is fine, but just bare in mind that it is you as a player who are limited by this kind of bugs, because it limits mission designers to make great missions. @ED: All we ask is please to just have a look at this issue reported. How much work can it be? I really wonder... Please do at least an assessment on what the issue is, how much work would it be to do that? And how much work to fix it. 1 day? 5 days? We are here at your disposal to help with testing, if that would help. I will drop you also that mail @Chizh. FC

New issue in DCS 1.5.7 and DCS 1.5.8 beta Another problem found ... An new issue on top of the previous reported regarding the S_EVENT_PLAYER_ENTER_UNIT. In DCS multi player, when a client joins a slot with a plane to a server, the event S_EVENT_PLAYER_ENTER_UNIT is not anymore triggered!!! This used to work a few versions back (even in DCS 1.5.7), but not anymore :no_sad::inv: It is sad. Really sad ... The impact is large on MOOSE. The only option I have now is to build a workaround solution interpreting the S_EVENT_BIRTH events, checking if the unit has a player name, and thus, this would be a player that joined a unit. This would work only for planes and helicopters. For ground units (ground commander, tactical commander etc), where a player joins a vehicle using ALT-J the S_EVENT_BIRTH is not triggered, because the unit is already alive... On top, for ground vehicles the method Unit:getPlayerName returns nil or "" when seated by a player... All works on Single player, but multi player is a mess at this moment when it comes to this functionality. @ED if you are seeing this, can you please focus on this please. Sven

Lots of expectations ... and no wonder after 2 years of waiting. Curious what we'll get. Afraid of the unexpected errors, bugs, lost features and functionality. Especially the lost features or things "not working anymore". Which will result in errors in the system for the coming decade. Wonder what the 2.5 brings in terms of "value" to flight simulation. Wonder about the stability for system hosters. Wonder about what it will bring in term of increased support and flexibility from the ED team. I have many questions. Being honest here. Sent from my SM-N950F using Tapatalk

Will this item be fixed before 2.5 comes out?

I am making progress on the issue... found the cause why the detections weren't propagated properly into the dispatcher. Sent from my SM-N950F using Tapatalk

It will get updated. It is on my radar. I worked about 2 months on this mission.... about 2 years ago. Hardly anyone flew it. Sent from my SM-N950F using Tapatalk

I agree and could reproduce this. I an debugging this to fix this issue.. It has to do with the detection logic not interpreting correctly the spawns. Now that we have a debugger it is easier to fix this. Sent from my SM-N950F using Tapatalk

Guys. This mission is old and dysfunctional. I'll pick it up again later. Sent from my SM-N950F using Tapatalk

Is It? This trespasses my expectations hehe Sent from my SM-N950F using Tapatalk

You mean DESIGNATE? Cab we discuss here further: https://discord.gg/chV6Yf Sent from my SM-N950F using Tapatalk

Ed should allow to cut / paste or duplicate configurations in the ME. There are some long due requirements in that area.

Amazing this post had only 100 views lol. Either nobody had understood the title or people don't like my name. Am afraid it is both lol. No feedback in the mods section???

With moose or the old one? Sent from my SM-N950F using Tapatalk

I will check upon that, DETECTION_UNITS not working. However, "force" the detection? How do you mean?

Dear DCS community! I've written a complete manual now of the debug capability how to set it up properly... The debugger capability has now been released to the master branch of the MOOSE repository. From now on it has become an essential part of the framework. Please consult the online documentation to setup the debugger here... http://flightcontrol-master.github.i...bug_Guide.html I'll make later some MOOSE for Dummies videos to go in depth on debugging and the various stuff that you can do. (The previous videos will be deleted as they are confusing). Enjoy! FC

Hi, There is a new capability for DCS World users... And I don't want you to miss out on this. It is useful for mission design, but this is also essential for lua coding and the design of "mods". The capability is about Debugging lua ... Interactively. This is the source link of the online documentation: http://flightcontrol-master.github.io/MOOSE/Interactive_Debug_Guide.html But you can read ahead here in this post. Enjoy! FC ----------------------------------------- Interactive DEBUG using Lua Development Tools from the Eclipse open source suite. The Lua Development Tools in the Eclipse suite has a possibility to “attach a lua debugger” to your LDT environment. Read this section to setup a debugger in our DCS World environment. The people who have used debuggers before, will recognize a lot in this explanation! How it works: Setup a debug listener within LDT. When running, it will listen over IP on the local host (127.0.0.1) on a port. Attach a debug client to your DCS World configuration. This debug client will attach itself to the debug listener over IP. Modify your mission, so that your source files are loaded dynamically. This is very important because DCS World renames unfortunately the name of the source files when it runs a mission! Set breakpoints where needed. The debugger will stop at the breakpoints set. Run the debug listener on LDT. Run the DCS World mission, which uses the debug client to connect to the debug listener over IP. The logic will stop at the set breakpoints. Using LDT, you can walk through the logic (statements), while inspecting variable contents and evaluate expressions. You can set breakpoints during the process where you want, you can add / delete variables in the views where you want. This capability will give you a new experience in DCS World mission design! Note: The assets that are used in this description, were modified to accomodate the debugging, so the LDT off-the-shelf assets aren’t working. So use the assets as listed here, or your debugger won’t work! 1. Explanation of the LDT debugging environment. The following pictures outline some of the interesting places in LDT to debug your lua code… A quick manual. This picture shows a debug view of the LDT environment. You can activate the debug view through the debug icon that is located in the upper right corner of the LDT. Various windows exist to track the content of: Variables: local and global variables will appear automatically in the Variables window where used. Breakpoints: Breakpoints that are set at lines of various sources, are listed here. Expressions: Various expressions can be entered to evaluate a more complex statement. Interactive Console: Here you can type in commands that will be executed. Here you can SPAWN for example new groups. This window lists the sources active in Eclipse. During a debug sessions, the sources where the process is at the moment of debugging, should be loaded automatically. If not, something is wrong. All the other sources that are currently open in the LDT are also listed. This window shows the status of the “attach debug engine”. If this process is running, it will listen to the IP 127.0.0.1 or localhost if setup on your PC. 2. Setup your debug listener in LDT. To use the debug enviornment in LDT, you’ll need to setup within LDT a “ Lua Attach to Application” debug listener. You can access this screen through the LDT editor menu Run->Debug Configurations…. This is the meaning of each field: Project: The name of the project that you are debugging within your workspace. You need to have a project registered here! IDE key: this string is used connect the debug client to the debug listener. Timeout: the amount of seconds you want DCS World to wait for the debug listener to be connecting. Source mapping: Select the option “Local Resolution”. All the sources are loaded locally from your PC automatically when debugging. Thats it on the LDT side. 3. Setup your debug client and attach it to DCS World mission runtime. This process is essential. Within the MOOSE repository, there are two important files that you need to consider. These files are located in the MOOSE repository here. Download the MOOSE repository or the files on your disk, and read further … You should have at least on your disk: debugger.lua READ.ME MissionScripting.lua 3.1. debugger.lua. This is the debug client. The source is part of the LDT debug suite, but has been modified to work together with the DCS World scripting engine. You need to copy this file to the root directory of your DCS World installation in Program Files. By example, the location of debugger.lua is here on my DCS World installation PC. 3.2. Modify the MissionScripting.lua file. The READ.ME file is a file that contains an explanation of how to modify the MissionScripting.lua. But for clarity reasons, I’ve also attached my version of the MissionScripting.lua. Take the MissionScripting.lua from the folder, and copy / paste (overwrite) the version in your DCS World installation directory under the Scripts folder. If you want, you can first rename the existing MissionScripting.lua file to MissionScripting_old.lua Don’t mistake yourself, a lot of mods/tools modify this file during installation. (like slmod etc). Once you’ve overwritten the MissionScripting.lua file, check if the contents are changed. It should contain the following: --Initialization script for the Mission lua Environment (SSE) dofile('Scripts/ScriptingSystem.lua') -- Add LuaSocket to the LUAPATH, so that it can be found. package.path = package.path..";.\\LuaSocket\\?.lua;" -- Connect to the debugger, first require it. local initconnection = require("debugger") -- Now make the connection.. -- "127.0.0.1" is the localhost. -- 10000 is the port. If you wanna use another port in LDT, change this number too! -- "dcsserver" is the name of the server. If you wanna use another name, change the name here too! -- nil (is for transport protocol, but not using this) -- "win" don't touch. But is important to indicate that we are in a windows environment to the debugger script. initconnection( "127.0.0.1", 10000, "dcsserver", nil, "win", "" ) --Sanitize Mission Scripting environment --This makes unavailable some unsecure functions. --Mission downloaded from server to client may contain potentialy harmful lua code that may use these functions. --You can remove the code below and make availble these functions at your own risk. local function sanitizeModule(name) _G[name] = nil package.loaded[name] = nil end do sanitizeModule('os') --sanitizeModule('io') sanitizeModule('lfs') require = nil loadlib = nil end Please read through the comment lines for a detailed description what it does. The io module has been de-sanitized because the debugger.lua needs to use the io module while debugging. 4. Setup your .miz file. When you run a mission in single player in DCS World, a couple of things are happening. The .miz (mission) file that was selected to run, is unzipped in a temp folder on your drive. Each lua file that is included in a DO SCRIPT FILE, is RENAMED to a file structure like ~mis__nnnnn__.lua. This is very bad. Because this prevents you from settings breakpoints at the source file and ensure that the debugger recognizes the source during run and the location of the breakpoint! So we need to do something special. The trick is dynamic loading. And believe me, it is the only way to be able to debug your sources. So this is a little task that you need to learn how to do, but once you understand it, it will become very easy to do. Instead of executing a DO SCRIPT FILE, you need to add a couple of things in your .miz file. 4.1 Conditionalize the DO SCRIPT FILE execution. Keep the DO SCRIPT FILE line in your mission. Why? Because if you would remove it, and you woudn’t debug your code, your mission file would be deleted. Instead, we are going to put a flag before this part of the execution. A debug flag. For example, in my mission I put a debug flag 999. When 999 is ON, I would NOT execute the mission file… Follow this process how to do that… As my recommendation… Setup a debug flag… If you wanna debug, set flag 999 to ON. Conditionalize the DO SCRIPT FILE execution by evaluating if the 999 is OFF. 4.2 Add a dynamic loader to debug your mission script. Now we are adding a little line. We are now going to ADD a dynamic loader of your mission source. This loads the file dynamically. Instead of a DO SCRIPT FILE, we execute here a DO SCRIPT. The DO SCRIPT contains a little piece of code that loads your source file from a location on your disk. This is how my piece of code looks like. I am using a stub of the MOOSE framework to load the file. MOOSE.Include( full_path_name, file_name ) The full_path_name needs to be between quotes, follows unix folder notation and needs to end with a / The file name is the full file name, including the .lua extension! If you don’t wanna use __Moose.Include, no worries, there is another method. _G.loadfile( full_path_name .. file_name ) The MOOSE.Include loader uses _G.loadfile to load the sources. But it does a bit more checking and logs in dcs.log which files were dynamically loaded, and from which location! 5. Run the debug listener on LDT. Now we are all setup! You’ve got your debug listener setup in LDT, you got your debug client setup and connected to your DCS World environment, and you got your mission file ready for debug! Now we are going to run a debug. To have a successful debug run, you need to start the listener in LDT. 5.1. Setup your debug favorite. First we setup the Debug as your “favorite”, so that it is easy for your to repeat the run easily. Click on the “Bug” icon that you’ll find in the task bar. The “Bug” icon is the place where you will start your debug listener. However, first, click on Organize Favorites. You need to do this one time only. Just click on the Debug Name that you entered (for me DCS 1.5) in the Debug Configuration window and it will be added ot your favorites. I did already that, so it was already added as an example in the previous picture. 5.2. Run the debug listener. Now you can easily activate the debug listener. Just click the “Bug” again, and select the debug listener that you configured. When done, you’ll see that the debug listener is running! It will be listening quietly to IP 127.0.0.1 on port 100000. 6. Set breakpoints. Open your source file from the exact location from where you have specified it to be loaded as part of the dynamic loading. Once it is loaded, you can attach breakpoints within the editor. How? Right click on the source line number or the grey area before the line, and a pop-up window will appear. Select “Toggle Breakpoint”. As a result, the breakpoint will be listed in the “Breakpoints” list at the debug view, and it will show also the line number where the breakpoint is set. When your mission runs, the logic will stop at this line!!! 7. Run your DCS World mission. Now it is time to start your DCS World mission. Just run it as you would like have it. The debug client (debugger.lua) is loaded as part of the MissionScripting.lua file. The debug client connects to the debug listener on ldt using 127.0.0.1 using port 10000. Your mission source will be loaded dynamically. Your mission will start running. Debugger is active and will monitor if a breakpoint has been set at the source currently active during runtime of your mission. Once it matches a valid breakpoint at a valid source and a specified line, it will stop the logic! 8. Next steps. There is a lot to say about debugging and the techniques that you can use how to track the code. For this, videos will be made in the MOOSE For Dummies video series. Please consult the youtube channel for more info on debugging. 9. Sequel. When I started to use DCS World (discovered it by accident), I was sold. After a while I started to discover the SSE capabilities of DCS World and started to code lua. But a very important piece was missing while developing the MOOSE framework. A debugger. I’ve been searching for about 4 years to get this working. There was a huge learning curve. I had to “hack” myself into the LDT environment and modify the LDT assets to make this work. There were moments of “clarity” that made me understand how it all fits together. And now it is there. Wanted to share this for all users of DCS World. It does require a bit of effort to use this in the DCS World environment, but the little effort is a small trade against the huge advantages here! I also encourage you to use the MOOSE Framework, as it brings you a lot of great capabilities you will never have in any editor. Being able to debug your code, will solve a lot of your questions now! I hope you will all have fun with the new debug capability and that it may result in greater missions. kind regards, FC MOOSE is maintained by FlightControl-Master.

I've made some progress today. Finally white spaces are working. Sources are loading in the debugger. I also changed the way how the debugger needs to be loaded. Suggest you update MissionScripting.lua file in the Scripts folder of the DCS program files folder. So here is a quick manual of the changes. The LDT-Debug branch of the MOOSE repo on github has been added with a directory... https://github.com/FlightControl-Master/MOOSE/tree/LDT-Debug/Moose%20Development/Debugger This directory contains 2 files. 1. A revised debugger.lua file, which you need to copy into the dcs program root folder. (On my pc this is C:\Program Files\Eagle Dynamics\DCS World ). 2. A connection.lua file, which contains 3 lines of code that needs to be copied into the MissionScripting.lua file, at the place indicated in the comments of the file. 3. MissionScripting should not sanitize the io library. Comment that line out. I've attached my MissionScripting.lua as an example in this thread. So, when you have done this, and run a mission, if the debugger service is running, you'll run DCS World in debug mode ... (But you'll need to watch the first video and the second one). But you need to load your sources dynamically, from the .miz file, no way around this. As explained in the video... I've attached an example mission how to do this. Ensure your baseline of the moose code on your pc is synched with branch LDT-Debug. Also. Ensure that you setup the debugger configuration in LDT for the service to identify the sources in the workspace following "local" resolvement. (In LDT->Run->Debug Configurations...). Then your sources will be loaded correctly while stepping through your mission logic and it will work. You can setup breakpoints, watch variables, ... and debug my crappy moose code too ... So these changes make the lua debugger available for ALL lua coders. You can debug CTLD, MIST, MOOSE, your missions, you name it. Enjoy! FC MissionScripting.lua SPA-011 - Ground Ops - Simple Spawning.lua SPA-011 - Ground Ops - Simple Spawning.miz