Ozone42

A little tip for kneeboard creators: If you want to create kneeboards from PDF files, a simple tool is mutool.exe, https://mupdf.com/. The tool is inside the distribution ZIP (mupdf-1.16.0-windows.zip) on the downloads page. Run it for example as follows: .\mutool.exe convert -o Ka-50-%d.png -F png -O width=768,height=1024 Ka-50_checklist.pdfThis will create suitable kneeboard PNG files from the PDF. You can also select page ranges to extract from the PDF by supplying them after the PDF file name. I create my checklists in LibreOffice Calc, export the sheets to PDF with pages in 3:4 ratio (18x24 cm), and then convert to PNGs with the above command. (I'm aware of Kneeboard Builder)

What's the source of this information? Most sources seem to say 768 x 1024 pixels (3:4 ratio), which with a quick sample check is also the size of kneeboards distributed with DCS. 825 x 1275 is also a different ratio. Has it changed, or is the information incorrect?

I think I misunderstood, and you got it right. Didn't think of that you can (propably?) install the normal LuaExport handlers that way. I haven't tried yet, but will.

You couldn't have been aware, since I had made it the same or the previous day :). Another way is to use VLC, then you can stream to any device that supports VLC (tablets, Raspberry, or even an Apple Watch). To start streaming from the computer you play DCS and have the DDIs (or whatever you are streaming), run something like: .\vlc.exe screen:// --screen-fps=20 --sout '#transcode{vfilter=croppadd{cropleft=0,cropright=1320,croptop=0,cropbottom=600},vcodec=mjpg}:standard{access=http,mux=mpjpeg,dst=192.168.0.1:8080}'Where 192.168.0.1 is the address of your DCS computer. Use the crop* to get the portion of the screen you want to stream. Then just connect your client to http://192.168.0.1:8080. The video encoding and method in the example here is not ideal for this purpose, and is just an example. Better parameters needs to be determined.

Sorry for the very late reply! Here's the hack, which really is just a quick hack: https://raw.githubusercontent.com/bjanders/dcs-api/master/tools/weapons There's no documentation or anything. I haven't tested it since a year ago when I created the CSV.

There are also some downsides with using the Hooks compared to Export.lua: One has to restart DCS for it to reread the Hooks scripts, compared to restarting the mission for Export.lua. It seems like there is no error output in any logs if you make a mistake in your Hooks code. For Export.lua errors, the errors are log in the dcs.log file. These two things makes development slower. For the time being, I think I have to go on and use the Export.lua because of these issues, and because I have not been able to solve the list_inidication() thing. It looks like that currently there is no ideal solution, or then I don't just know how to use the available API interfaces, and would be grateful for any help and advice.

You can use https://github.com/BlueFinBima/Iris-Screen-Exporter together with https://github.com/bjanders/wxpython-iris-client to get parts of the screen exported to a Raspberry Pi. I just made the simple client and verified that it works on a Pi. Your reply is not constructive and only adds noise to the discussion. You are clearly hinting at something without giving any useful information. I'd appreciate if you can be helpful if you can.

I think I got everything working using the Hooks method, except that I wasn't able to figure out how to call the list_indication() function in that environment. Any ideas? Running net.dostring_in("export", "dofile(...)") on every frame to a onSimulationFrame() is probably not very resource friendly either. I don't need to, and I'm not currently doing it, but if somebody suggests that I call list_indication() that way, then I don't think it's a solution. I tried calling something like: [font=Courier New][font=Arial][font=Verdana][font=Courier New][font=Arial][font=Verdana][font=Courier New]net.dostring_in("export", "list_inidication(1)")[/font][/font][/font][/font][/font][/font][/font] But wasn't able to get it to return anything. How should it done? I also tried: [font=Courier New][font=Arial][font=Verdana][font=Courier New][font=Arial][font=Verdana][font=Courier New]net.dostring_in("export", "print(1+2)")[/font][/font][/font][/font][/font][/font][/font] But didn't get an output. According to the documentation: net.dostring_in(state, string) -> string Executes a lua-string in a given internal lua-state and returns a string result How do I get it to return a string result? Any simple example would help.

I'm looking at this again. So, I only need to do net.dostring_in("export", "...") if I want to make any of my plugin data available to other scripts, is that right? Otherwise I should be fine just using onSimulationStart(), onSimulationStop() and onSimulationFrame()? I saw this discussion on the same topic: https://forums.eagle.ru/showthread.php?t=228270&page=89 Why is onSimulationFrame() not sufficient for TacView, so that LuaExportAfterNextFrame() is needed? I'm asking because it indicates that there is something that I still don't understand, or have misunderstood. Unless TacView is making information available to other Export scripts, then I might understand.

So the SharedTexture() functions do not work? If not, it would be nice if ED removed those functions from the Exports.lua documentation so that developers don't spend time trying to get them to work, like I just did. Does anybody know for sure, does the shared memory work or not?

Thanks! The DCS API folder and the documentation in there was what I was looking for. Was it there a year ago, or did I just miss it? I only had quick look now, but this seems the way to go, just like you suggest. A year ago I wrote a plugin for physical simulator cockpit integration. I haven't documented it yet, so I didn't want to publish it. (And probably buggy, but works for my purposes.) Shortly after, I stopped playing DCS, but now I'm back in the game. :) I'll try to get some documentation done within a week or so, and then I'll give pointers. And yes, I'm well aware of the existing solutions and I tried them and had a look at them, but in the end I wanted to do it my own way. My design goals were: It should be easy to add support for new aircraft without extensive coding. Most of the gauges (game output) and controls (input) are already described in the DCS game files in a structured machine readable format. This information is utilized as much as possible to avoid manual programming of the same information. A simple to use network protocol that can easily be integrated with various client software. This is achieved by sending all data as JSON. (If a more compact data format is needed, then support for CBOR can easily be added, since JSON can be encoded as CBOR.) Avoid sending more data than needed. This is achieved by allowing the client to request which parameters should be exported, at what maximum frequency and with which precision (per gauge). Data is only sent when the information changes at the requested precision. For example, the IAS is within the game a floating point number that in practice changes for each rendered frame in the game. In most cases, it is sufficient for the client software to know the IAS without decimals, for example, at the resolution of 1 km/h or 1 knot. If the IAS stays with that one km/h then an update of the IAS is not sent to the client. Keep the server side implementation fairly simple. (It's currently at about 600 lines of code).

I'm not familiar with this. I'd appreciate if you can share a pointer with more information so I can read about it.

VAICOM PRO (the paid version) has some ATC communication commands that do not exist in the normal DCS menus, such as "Overhead Approach". Do these commands affect the DCS ATC commuication dialog logic in anyway? I didn't notice it had any affect, but I'm not sure I follow the intended procedure.

Currently when making a plugin via the Export.lua interface, the plugin author must save the LuaExport functions of any eventual other plugin, before calling its own LuaExports. When the plugin is done with its own work, it must call the saved LuaExport functions of the other plugin. This is something every plugin author must do if you want multiple plugins to function simultaneously. More or less exactly the same LuaExport copying code is done over and over again by every author. If some plugin author decides not to do this chaining, then other plugins will not be called and thus not function. This also means that every plugin must edit the same Export.lua file which may break it. I suggest that Eagle Dynamics implements better support for multiple plugins, so that each plugin author does not have implement this functionality (and edit Export.lua). I think this could easily be done in a backwards compatible way: DCS first looks for a folder named "Saved Games\DCS\Scripts\Exports". If there is such a folder, then it traverses each subfolder in the Exports folder and looks for a file named Export.lua. If such a file exists, it will call the LuaExport functions in that file. After this is done, it continues as it does today and calls the LuaExport functions in the file "Saved Games\DCS\Scripts\Export.lua". This way plugin author would just make their own folder and have an Export.lua file without bothering about implementing the LuaExport function chaining and editing the top Export.lua. The directory structure would be something like: Saved Games\DCS\Scripts\ Export.lua Exports\ Plugin1\ Export.lua [*]AnotherPlugin\ Export.lua [*]AndOneMorePlugin\ Export.lua Where Plugin1, AnotherPlugin, AndOneMorePlugin are different plugins from potentially different authors. What do you say Eagle Dynamics and plugin authors?

My guess is that they will announce the left vertical panel, the one where the gear handle and flap switch are. Purely speculation.

Brun, what did you base your measurements on, i.e., what's your source for the model? (Sorry if this has been answered already. I skimmed through the 21 pages but didn't see it.)

A quick search on the net of course gives the answer: Source: https://forums.vrsimulations.com/support/index.php/AIM-7_Sparrow#Lofted_Trajectory Yes, you are right. I had no idea what I was talking about and was just speculating.

I'm just speculating, could it be that LOFT optimizes range over speed and maneuverability, i.e. LOFT burns fuel more slowly. That would explain why the no escape range decreased with LOFT for Fred00 and why it would typically be used against non-maneuvering targets like GGTharos says.

(Update: improved file) I was also looking for a guide. The encyclopedia reads the text from the folders in MissionEditor\data\scripts\Enc in the DCS installation folder. I did a quick hack that parses these files and generates a CSV file, attached here. I have named it .txt bacause .csv attachments are not allowed in this forum. You should be able to import this to your favorite spreadsheet editor (like LibreOffice or Excel). The file contains all metadata of all weapons, with one column per metadata. The metadata columns are in alphabetical order except the first that is the name of the weapon. I have merged some metadata that have similar but different names. For example, some weapons have "Max range", some "Range" and some "Range max". All are now in a single column named "Range". The table may contain parsing errors since the format of some weapon files were not consistent with the majority. (For example BetAB-500shp uses Latin1 encoding although the files are specified to use UTF-8 encoding.) With the table you can sort and filter to get a pretty good overview of what you are looking for. weapons-20190130.txt