Durham

With the arrival of the SU-33 and the upcoming arrivals of the Harrier, Tomcat and Hornet, controlling ships will become more important for relevant mission development. I wished to prepare for this by using the assets we have already: Kuznetsov + SU-33 to create a carrier group which could be attacked by Viggens and Mirages and anyone else for that matter. First issue I noticed is that the carrier group could not hold formation, either as a group or as individual units with formated waypoints. So: I thought, why don't I write a script that commands the followers in a formation to hold heading and relative bearing from the carrier. First stop, watch youtube/read google and see the way that formations are done in regular game AI with dragons and trolls etc. - not hard, loop, predict position of formation leader, predict position of angle and distance off for each subsidiary unit, convert cartesian, set waypoint, rinse and repeat. At mission start we all need to form up, so I wrote an FSM inFormation boolean, where if false halts leader and lets followers form up. I could not return a valid unit:getPosition() or unit:getPoint() from the lead ship because ships work at a group and not a unit level. Passing a group object to those two functions just generated a compile error. Then I got stumped by groupStopMoving(groupObject), which only works with ground units. Then I went lower StopRoute, but that is readonly. So basically, I have all the math to keep a carrier group in formation, but don't seem to be able to set any variables with ship type assets, in the way that I have been with airplane, helicopter and ground assets. My guess is that nobody has cared about this, but with the launch of all these carrier-borne air-frames, maybe somebody should! We are going to need a carrier FSM, where when recovering aircraft, it turns into the wind, and thereafter returns to its original route. How do we do that if we cannot even get its position? As always, all help and guidance gratefully appreciated, Durham

Thank you for your solution - worked like a dream. I had a greened out, solid HUD, and now everything working fine. I did not have SU-27, which you have identified as the root cause. Many thanks.

Absolutely. Coming from PPL in Cessna 172 with<200hp where engine torque was only a factor on take-off roll, which could be corrected with a little right rudder: to these beasts with nearly 2000hp was a real eye opener. Managing yaw and attitude on throttle change is the critical skill to flying these planes

Durham-No Squadron-UK born US based - F5 only, if available

Durham British Mirage 2000

I am trying to develop a tcp/ip mod that takes data from DCS, puts it into a C#/SQL Server environment and then does lots of wonderful things. At present these wonderful things are limited to a message system that will display text in game, a command line that will execute a lua command (which I call LUA injection) and a map of Nevada from Google that will put the units on it and updates their positions in a timed loop. So nothing earth shattering and nothing that hasn't been done before by the community. In doing this, I communicated via PM with Grimes and he opined that all conversations should be in the forums, so I thought I would publish two useful things I have learnt in LUA during this project. Firstly, LUA has no try{} catch{} finally{} statement, so you send the game commands it doesn't like and it will either hang, crash or just ignore them. The solution I found was the pcall() statement. For example, I am converting a vec2 to Latitude and Longitude to give the unit location to google maps. My application calls:- --protected call to convert lat long function pcallLOtoLL(x, y) if pcall(LOtoLL, x, y, true) then else tcpClient:send("Lat Long error!:\n") end end which then calls --Get Lat Long function LOtoLL(x , y, send) --create vec3 with altitude = 0 tblVec3 = {x = x, y = 0, z = y} --convert to lat/long in decimals local lat, long = coord.LOtoLL(tblVec3) --send to server if send == true then tcpClient:send("Lat = "..lat.." Long = "..long.."\n") elseif send == false then return lat, long end end Just as with try catch, we either get a valid return of lat and long or we get an error message inside the pcall() statement with no hang or crash. The second issue I had was with the table object in LUA which is so flexible and loosely typed as to be a real nightmare for a SQL Server guy like me. If you read Grimes' MIST source code, you will see that mist.DBs is actually one table, which contains lots of tables within it - just like a SQL Server database where you would call [dataBaseName].dbo.[tableName]. Now we cannot use SQL on them with joins etc, but that was a big leap forward in understanding for me. I wrote the following in the command prompt to start comprehending LUA tables and if at least one of you finds it helpful, then that is good:- local tblResult = {} local x=1 local y=1 local z =1 --insert into table for i=1, 10, 1 do tblResult = {["xVal"] = x, ["yVal"] = y, ["zVal"] = z} x = x + 1 y = y + 1 z = z + 10 end --output the index value followed by the zVal for k, v in pairs(tblResult) do print(k) for iK, iV in pairs(v) do if iK == "zVal" then print(iK, iV) end end end This shows the table within a table syntax as well as giving a basic idea of the beginnings of a sql query using two in pairs loops (one for the main table, second for the records (which are tables) and then an if statement to output only one of the fields from the records. Hope that this is useful to someone and thanks again to Grimes for getting me going. Kind regards to all Durham

Tried to do this in a script file. Got the client and server communicating with the remote machine fine - sending mist.DBs.units in JSON to server and then taking messages back which I printed to screen using action.outText(string), which I then converted into lua injection. One issue: Using the witchcraft.lua as a template, I had above the loop: tcpClient:settimeout(0.0001) and in the loop: local line, err = tcpClient:receive() if err then trigger.action.outText("Error receiving message from server!\n", 2) else trigger.action.outText("Message from server:"..line.."\n", 5) end If there was no message from the server, then the game hung for the length of the timeout. If I pinged the client with repetitive [0/enter] then no problem. I looked at multi-threading with:- function receive (connection) connection:timeout(0) -- do not block local s, status = connection:receive(2^10) if status == "timeout" then coroutine.yield(connection) end return s, status end but didn't make any progress. At present, my solution to this issue will be to send a 0 each cycle from the server and run a if client:receive ~=0 then do stuff end which seems really inefficient, but will work smoothly. I got the lua injection to work with f = loadstring(string)(), which has no error handling which can be added later. Do you have a solution to the stuttering on the receive() function, other than regularly sending a message from the server? Many thanks Durham

Been reading the literature on GOAP and believe it will meet the needs for DCS AI better than an FSM, given the significant number of different unit types (agents) in DCS, their large number of actions and ED's habit of changing things with updates, which means that modular code with the DCS hooks all in one place is a necessity. My thought process, given the CPU intensity of the DCS engine, would be to export the DCS world state using JSON to another server, which would then run the GOAP scheduler and planner and then give back actions to the DCS units. Ultimately this second master server could provide the world map updates, similar to those of http://gadget.buddyspike.net/ and maybe even be able to operate as a mission planning tool prior to the simulator start, a command tool during the run and a debriefing tool thereafter. While this might well be an easier project than getting the AI units to behave more naturally, I believe the latter project would be more impactful to the users' experience. Given that the low level AI behavior is handled inside the DCS code, I do not think that the latency of the planner will be too great a problem. I would love to assist you in your endeavors Chromium, but I warn you I am weak at both Lua and C++, so if I was doing it would run the dB in SQL Server and the application in C#, where I spend most of my work programming life. Look forward to linking up with you at your convenience. Durham

Thanks for this - had almost thrown in the towel and gone back to helicopters! Great advice.

Sent you friend invite on Steam - also EST and looking for WSO/Commander to fly with on a regular basis. Gazelle will rock with two players. Best. Durham

I think you are correct - with multiple commands and/or conditional commands I am running a macro and will need a lua script. Unfortunately, I don't own the Mirage, so cannot look at that code. I can tell you that neither of these work: {down = iCommandxxx, down = iCommandyyy, up = iCommandzzz, name = ....} {down = (iCommandxxx, iCommandyyy), up = iCommandzzz, name = ....} However if anyone is interested in the F15 autopilot and the Warthog, here was the solution with no sexy code, just thinking. Up to path to activate attitude, two down to alt to activate autopilot, one back to center for autopilot off. Seems to work fine. Code below: {down = iCommandPlaneAutopilot, name = _('Autopilot - Attitude Hold'), category = _('Autopilot')}, --BIND THIS TO PATH POSITION {down = iCommandPlaneStabHbar, up = iCommandPlaneStabCancel, name = _('Autopilot - Altitude Hold'), category = _('Autopilot')}, --BIND THIS TO ALT POSITION

I got down = iCommandxxx, up = iCommandyyy working pretty easily. I have encountered one problem, which is I cannot find the syntax to run two commands with one press. For example, in order to get altitude hold to work in the F15, attitude hold needs to be on. So the command would be (in codelish) {down = iCommandPlaneAutopilot [+, &, |, || or something] iCommandPlaneStabHbar, up = iCommandPlaneStabCancel, name = _('Autopilot - Altitude Hold'), category = _('Autopilot')}, Anyone any idea of the joining character, which obviously cannot be a comma, so I put in some suggestions. Many thanks.

Re: Default Document How to Modify Control Binding Files I downloaded and read your pdf - excellent work. I am trying to do something fairly simple for the F15, which is to make the Boatswitch on the TM Warthog throttle control the Modes. Push forward for BVR, return to center for NAV, pull back for Close Combat, return to center for NAV. I was about to piss and moan that it didn't work, but as I pasted the code into this message, I saw I had missed the end comma from an edited line, fixed and now all working. The key issue seems to be that you used to do this all from your "C:\Users\[userName]\Saved Games\DCS\Config\Input\[aircraftName]" directory, whereas now if you want to mod a control file you need to edit "C:\Program Files\Eagle Dynamics\DCS World[Version]\Mods\aircraft\[aircraftName]\Input\joystick\default.lua" or maybe even the Input\keyboard equivalent Thanks for your excellent work. Now the next issue is conditional keys: I know it can be done, because the A10C has a control that does one thing on the ground and another in the air, so will have a go at working in an "IF{..}ELSE{..}" or "SWITCH{CASE..}" or whatever the LUA equivalent into a default.lua file. If anyone has had any success, please feel free to share.

Highly recommended - pretty much the only module I have flown since I purchased at release. Much harder to fly than Huey (which was hard enough), because of light weight and maneoverability, but highly rewarding. Obviously, nowhere near as much hitting or staying power as the Orca, but the HOT is very effective if you can get to release parameters. If you like helos and can get a good deal, go for it.

After getting consent from the copyright owner here you go: Direct quote from her - "Wow - this is f**ing amazing".

Mindblowing weekend I thought I should add my comments as my Oculus arrived on Friday and I played solid in the Gazelle through Friday, Saturday and Sunday. Firstly, and very impressive, everything worked out of the box. In the case of the Oculus the packaging was as beautiful as anything I have seen from Apple (which is high praise indeed), software all loaded and updated and away we went to the demos for an amazing experience. I was more anxious about DCS as ED is not as well funded (NASDAQ:FB trades for $332bn, ED likely not so much), but again everything worked out of the box after pressing the detect Oculus checkbox. Well done ED! As to the experience - mindblowing. Without wishing to boast, I have a very hot and much younger girlfriend. I told her to stay away all weekend, notwithstanding repeated requests from her to come over. Enough said! Specifically, when combined with a set of proper helo controls, flying the Gazelle felt just like being in a real R22, for a marginal cost per hour of close to zero versus the real-life $300-$400. Immersion, speed, depth, height - all incredible. My flying improved immensely after only an hour or so in VR. Yes it would be better if the resolution were higher, but I have no desire to use my 4K triple 28" display again for DCS. Nvidia 1080 out very soon - likely two more iterations or 2017/2018 and we will get 4K inside VR - and then we won't need girlfriends at all!! I am highly impressed with the way ED got early onto this technology, as I found it even more of a wow experience than flying in Nevada for the first time. Good on them: like the tech giants (AAPL, GOOG, FB), they really seem to be getting into the virtuous circle of good platform --> subscriber growth --> increased third party development activity --> improved customer experience --> more revenue --> more R&D spend --> better platform and so it goes on. Cannot recommend highly enough DCS, the Oculus Rift and the amazing Frenchmen from Polychop who brought us the Gazelle. I messed around with the SDK and got the pixel count up to 2.0 with the debugger, but saw no discernable difference. Would recommend waiting until it is native in DCS per Wags' post above. Durham out

Issues resolved I have now fixed the issues I reported in the last post: Multiplayer: there is a server option "Export Objects". If the host ticks this, the app works fine, if not, not. The reason this option is present is that clever people can use exported objects to create omniscient God views so preventing such exports eliminates that as a source of unfair competitive advantage. Nonetheless, if its a friendly game no problem. Radios: This was just me being an idiot. Swipe up on the LCD to bring up the UFC and once it is up left and right swipes on the LCD will bring up the three radio displays allowing user to manage frequencies and channel selection on the iPad. Next step is to get a touchscreen for the MFCDs so I can hit the OSB's with my finger rather than the mouse. What will Santa bring??

Current issues I am getting mixed performance from this app. The CDU repeats and the switches/buttons move as I move them in the virtual cockpit. I can get the UFC up on the iPad with an upward swipe on the lcd, but the side swipes do not show the other functions (radios). All of the key-presses work fine, but the only buttons I have got to take on the iPad are CDU and EAC on/off. Cannot change STEERPT or PAGE from the iPad. I went into multiplayer as a client and got nothing from the app: from reading the above I think I will get single player behavior when I am host. I have correctly modified the export.lua file with the ip address of the iPad in cduAppHost = "ipAddress" and added both the dcs.exe and the associated updater file to my windows firewall inbound and outbound rules, as well as opening port 9089 on my router with the PC ipAddress. I am at a loss as to how to get the specified performance out of this app, which is a pity (but not the end of the world as it cost me nothing). Any additional suggestions would be gratefully received.