FlightControl Posted June 3, 2016 Posted June 3, 2016 Gents, Are there modifications to be expected in the dcs world scripting engine API when dcs world moves to version 2.5? If yes, or maybe yes, would it be possible to share which changes are going / are likely to be expected? The reason for my question is that building a framework requires design decisions, and it would be good to make these based on a well documented base platform. It would not be good to have suddenly design changes showing as part of a beta release of 2.5 ... Makes sense? Sv. [TABLE][sIGPIC][/sIGPIC]| Join MOOSE community on: DISCORD :thumbup: Website of the MOOSE LUA Framework. MOOSE framework Downloads. Check out Example Missions to try out and learn. MOOSE YouTube Channel for live demonstrations and tutorials. [/TABLE]
FSFIan Posted June 3, 2016 Posted June 3, 2016 As far as I understand it, 2.5 will be 2.0 with the Caucasus map in addition to NTTR, so I wouldn't expect major changes to the scripting engine. I would expect a framework that works in 2.0 to work in 2.5 without modification, since it's the same engine -- the difference between 1.5 and 2.5 will be the data format of the Caucasus map (i.e. the Caucasus map will use the same new terrain engine that is already used by NTTR). DCS-BIOS | How to export CMSP, RWR, etc. through MonitorSetup.lua
FlightControl Posted June 4, 2016 Author Posted June 4, 2016 Ian;2800260']As far as I understand it' date=' 2.5 will be 2.0 with the Caucasus map in addition to NTTR, so I wouldn't expect major changes to the scripting engine. I would expect a framework that works in 2.0 to work in 2.5 without modification, since it's the same engine -- the difference between 1.5 and 2.5 will be the data format of the Caucasus map (i.e. the Caucasus map will use the same new terrain engine that is already used by NTTR).[/quote'] There are a few worries I have ... 1. Multi seated planes in mp. Some APIs may be impacted... Like Unit.getPlayerName() 2. The outstanding bugs ( for months of not years ). These don't get fixed and there must be a reason behind. I am afraid the reason is internal design... There is probably not an easy fix for these bugs, and will require a redesign. Areas like cargo, clients, players are with bugs for months now. 7 updates on 1.5.3 already, but only cosmetic fixes, no core things... 3. New modules are showing up now quickly. In a few months maybe those ships... Well, I would assume that ship logic will be extended, with new apis.. ... FC [TABLE][sIGPIC][/sIGPIC]| Join MOOSE community on: DISCORD :thumbup: Website of the MOOSE LUA Framework. MOOSE framework Downloads. Check out Example Missions to try out and learn. MOOSE YouTube Channel for live demonstrations and tutorials. [/TABLE]
Grimes Posted June 4, 2016 Posted June 4, 2016 1. The feature request I made was for a new function that returned a table on the aircraft seats containing player name, if its AI or human, and if the pilot is alive or dead. My hope is that getPlayerName() doesn't really change at all or if it did it would only return a string of whoever is piloting the vehicle. 2. Whenever bugs get fixed I'd expect for the documented functionality to remain the same. 3. If new features get added to the mission editor it will likely also mean they will get added to the scripting engine. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum
FlightControl Posted June 6, 2016 Author Posted June 6, 2016 1. The feature request I made was for a new function that returned a table on the aircraft seats containing player name, if its AI or human, and if the pilot is alive or dead. My hope is that getPlayerName() doesn't really change at all or if it did it would only return a string of whoever is piloting the vehicle. That is good. Thank you. So the discussion we had earlier resulted in a feature request. I hope too that getPlayerName won't change... 2. Whenever bugs get fixed I'd expect for the documented functionality to remain the same. 3. If new features get added to the mission editor it will likely also mean they will get added to the scripting engine. Is there a way to find these scripting functions? Like examining the dlls included in the dcs bin folder? Since you have a test version, your dlls must have debug info embedded, no? For example, some people would be interested in the api how to set the weight of the helicopter in a mission execution... Or, how to open cargo doors using scripts... Just to nane a few... Sent from mTalk [TABLE][sIGPIC][/sIGPIC]| Join MOOSE community on: DISCORD :thumbup: Website of the MOOSE LUA Framework. MOOSE framework Downloads. Check out Example Missions to try out and learn. MOOSE YouTube Channel for live demonstrations and tutorials. [/TABLE]
Grimes Posted June 6, 2016 Posted June 6, 2016 No, I see what the end user sees. I tend to dump the G table every so often to see what new data might be in there. Usually it doesn't change much, but it is helpful for reference. When stuff does get added its usually documented, and when that patch goes live I update the wiki with at least some useful information for whatever was added. The right man in the wrong place makes all the difference in the world. Current Projects: Grayflag Server, Scripting Wiki Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread) SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum
Recommended Posts