FSFIan

Ich stimme da M-Power zu: Spar dein Geld und nimm einen i5. Ein i7 hat kaum mehr Performance als ein gleich schnell getakteter i5, ist aber unverhältnismäßig teurer. Der i7 kann nicht schneller rechnen, der kleine Performancevorteil kommt von Hyperthreading. Ein Prozessorkern hat verschiedene Unterabschnitte, die für bestimmte Dinge zuständig sind, wie z.B. eine für Berechnungen mit Fließkommazahlen und eine für Ganzzahl-Berechnungen. Wenn jetzt ein Programm z.B. eine Fließkomma- und eine Ganzzahl-Instruktion enthält und das Ergebnis der einen nicht vom Ergebnis der anderen abhängt, dann führt auch ein i5 die beiden gleichzeitig aus ("out-of-order execution"). Nun kommt es aber natürlich vor, dass z.B. eine Ganzzahl-Instruktion ausgeführt wird, es aber im aktuellen Thread keine Fließkomma-Instruktion gibt, die schon ausführungsbereit wäre. Dann hat die Fließkomma-Einheit nichts zu tun. In so einem Fall kann ein Prozessor mit Hyperthreading da eine Instruktion aus einem anderen Thread reinschieben, weil jeder Core mit HT zwei Prozesse gleichzeitig ausführt. Der zweite Vorteil ist, dass der Wechsel zwischen zwei Threads, die auf dem gleichen Core laufen (Kontextwechsel) fast kostenlos ist -- das bringt was, wenn du viele Threads hast, die ständig auf I/O warten müssen und daher ständig wechseln, z.B. in einem Webserver. Der Punkt ist aber, dass HT überhaupt erst was bringt, wenn du mehr Prozesse als CPU-Kerne hast, deine Game-Engine muss also schonmal vier Kerne auslasten können, und auch dann bringt das IMO nicht soviel, dass es den Aufpreis eines i7 rechtfertigt (das Geld kann man dann besser in mehr RAM, einen schneller getakteten i5 oder eine bessere Grafikkarte stecken). Einen Core i7 sollte man nur dann kaufen, wenn man eines der i7-spezifischen Features (wie die vPro-Management-Funktion für Unternehmen) braucht oder wenn es keinen gleich schnell getakteten i5 gibt. Wenn du Intel-CPUs untereinander vergleichen willst, gibt's da übrigens dieses praktische Tool von Intel selbst: http://ark.intel.com

You have to create the Scripts folder yourself.

You are looking for land.getSurfaceType. It takes a single parameter, a vec2 (Lua table with x and y coordinate) and returns 1 for land, 2 for shallow water, 3 for deep water, 4 for roads and 5 for airports (tarmac, runways and taxiways).

Copy your old Export.lua file from %USERPROFILE%\Saved Games\DCS\Scripts to %USERPROFILE%\Saved Games\DCS.openbeta\Scripts. I think Helios still assumes that Export.lua goes into the DCS installation directory, but that was changed a long time ago.

Looks like you can indeed install a second copy of 1.5. By default, it will use the same lfs.writedir(), namely %USERPROFILE%\Saved Games\DCS.openbeta, so when you try to start it alongside the first installation, you still get the "only one instance allowed" error. But all you need is to edit the "dcs_variant.txt" file (I changed the content of mine from "openbeta" to "openbeta_D") so the second installation uses its own directory. I'll adapt this thing to use two instances of v1.5 now. Update: Experimenting with two instances of 1.5 right now. The unit type mismatch still exists, so I assume I am grabbing the wrong field from the mission editor. Maybe there is a unit name and a display name? Update 2: Fixed the unit type mismatch (there's a handy me_db.getNameByDisplayName() function). The new version, along with updated instructions, can be found on GitHub. Update 3: I have recorded a quick video to help you decide if you want to spend the time to set it up yourself (most of which consists of waiting for the second install of DCS: World to complete).

Edit: This is a quick and dirty hack that spawns the groups you are editing in the DCS: World Mission Editor into an empty mission running in a second instance of DCS: World, so you can preview their location in the 3D world. Note: This only works for ground units (see also the "Bugs" section in the README). I don't plan to add any more functionality to this, it was a quick experiment and depends on internal DCS implementation details that could change with every update. As of 2016-02-19, it has been tested with DCS: World 1.5.2.49392 and the 2.0.1.49921 Open Alpha. The most recent version and setup instructions can always be found on GitHub. The original first post follows. I had been excited to read about the satellite view in the mission editor of DCS 1.5. When I tried it, I was disappointed that the units still only appeared as icons and not as 3D models. So I hacked together a mod for the mission editor. This is a quick and dirty hack. It allows you to use DCS v1.2.x (update: a second instance of DCS 1.5) to preview a mission as you are editing it in the DCS v1.5 editor (think DCS Witchcraft, but instead of a browser, you are using the DCS v1.5 mission editor). >> Download and instructions on GitHub v_g-vjP3QgQ Does anyone know a way to have two instances of the Open Beta running at the same time? For example, can I install another copy of the Open Beta in another folder and start both at the same time without getting the "only one instance allowed" error message?

I'll start with some lessons learned from DCS-BIOS: Don't try to keep things simple enough for non-programmers to understand. Most of the design decisions I got wrong with DCS-BIOS were influenced by my overall design goal to keep it as simple as possible. I wanted to teach people how to fish. Turns out that people who are building a simpit are not interested in learning how everything works. Ain't nobody got time for that! (Especially if you are learning woodworking, machining, soldering, CAD, etc. at the same time and also, you know, building a simpit.) The reason I have any users at all is because of a happy accident of programmer laziness. I implemented the example code generation in the reference docs so I would have to do less typing. Suddenly you could get something going without understanding a thing about programming. Don't try to make Export.lua do too much. I wanted to avoid a custom middleware to reduce the amount of programming languages that were involved (see above). I ended up with an export protocol that is good for microcontrollers to consume, but requires a moderately complex parser (as opposed to a simple key=value design that can be parsed with a few lines of C#/Python/insert your favorite high-level language here). The abstraction from DCS implementation details is a good thing to have, but also does not belong in Export.lua. Documentation is important. I would have no users at all if it weren't for the step-by-step user guide (and WarHog's feedback on that to make it understandable to non-programmers). ArturDCS's Flightpanels software (to connect Saitek ProFlight panels) and BrassEm's VRI2DCSBIOS (VRInsight devices) would not exist without the protocol documentation. Export.lua is not only about argument values. While most of the values we need to export are cockpit arguments, some special cases absolutely require custom Lua code (best example: the CDU display in the A-10C). This also means that we need a way to export string values (and it should be able to handle things other than ASCII, because we also have Russian planes). For a common Export.lua, I propose the following architecture: Transport layer I think DCS-BIOS got this one right. Multicast UDP takes care of the common case of sending one data stream to multiple programs running on the local machine without requiring any additional processing in the DCS process. A TCP server provides an even easier way to connect at a slight performance penalty (I never tried to measure it, but I suspect it's not noticeable if you have less than a dozen clients or so), with the disadvantage that DCS has to be running before the consuming application can connect. Through a configuration file, you can optionally define a list of targets that should receive a unicast UDP stream. Protocol The Export.lua file keeps track of several values, each being identified by a key. Keys are strings. A cockpit argument is identified by its decimal representation, i.e. the Master Caution Light in the A-10C would have the key "404" and get the value GetDevice(0):get_argument_value(404). By writing an aircraft-specific extension to the Export.lua file, we can add other values with their own keys (e.g. add a function that knows how to read the A-10C CDU and export it as the "CDU" key, or as one key per line on the display). By default, no data except the current aircraft type is being exported. When a new aircraft is entered, connected applications are notified. A connected application can send a list of keys it is interested in, which will result in those keys being added to the export data (i.e. a standard Observer pattern, with the difference that if there is at least one subscriber, the data goes to every connected subscriber so we can use multicast UDP). I am still unsure how to handle an application that connects later on. One solution would be to constantly export the aircraft type even if it does not change, have the new application send its list of keys it wants exported, and re-send a value whenever a new application subscribes to its key. Another problem here is when to stop exporting a certain key. Naturally there will be a reference count for each key and we can stop exporting a value as soon as no subscribers are left. If an application connects via TCP, we can unsubscribe it automatically. For UDP, it would have to explicitly unsubscribe. On the other hand, maybe this problem doesn't need to be solved (perfectly): in the worst case, we end up exporting some extra data until the next aircraft is entered. For the input side, we should provide an API to call LoSetCommand(), GetDevice(dev):performClickableAction(cmd, arg), and GetDevice(dev):SetCommand(cmd, arg). For anything else (can't think of a use case right now), you'd need to write a Lua extension; the protocol should provide some way (maybe a generic event mechanism) to talk to such a custom extension. Representation of export data I would suggest using JSON, as there are fast parsers available for just about any programming language you can think of and it handles things like strings which have quotes or spaces in them. I am not sure about the precision of floating point values. I'd suggest to export all floats with full precision. Deciding on a case-by-case basis whether to use string.format("%f"), string.format("%.1f"), string.format("%.4f), or something else would reduce the amount of data we send to the network, but as we are dealing with a local network here, I assume it won't be a significant performance gain. It would also require all applications to agree on the right precision. We'll have to experiment with that. License Some variant of the GPL should work well for this. As you can see in the DCS-BIOS License, I am a fan of the Simple Public License, but I'd be happy with GPL (v2 or v3) too. @ohall: I think that covers 1), 2) and 4) on your list. Efficient representation: I'd prefer saving CPU cycles in DCS.exe over saving network bandwidth. We are either sending data to the same machine or over a local network, so bandwidth shouldn't be an issue. Whenever bandwidth is restricted (such as on a serial port), there will be another program in between to translate to a more efficient representation anyway. Regarding 5) -- not requiring configuration files for each aircraft -- this is mostly covered. If all you need is an argument number, simply subscribe to the key tostring(arg_number) and you'll get it. Same for the input side if all you need is to call LoSetCommand, performClickableAction and SetCommand. For the advanced stuff you'd need to write an add-on module in Lua. We could allow doing that dynamically over the network connection, but that would only lead to several applications adding their own way to export the FOO display, so we'd be wasting performance again. Of course, the consuming application still needs to know which argument numbers are interesting and what they mean. IMO this is out of scope for this project, but as I previously mentioned, coming up with a machine-readable format to document this stuff would make a good sister project. @everyone: Please tell me what you think. I wrote a proposal for a concrete implementation instead of a list of requirements because I think this makes it easier to talk about by answering the question "is there anything I would do differently and why?". The answer to that "why" is then a requirement I have missed. We'll also need a name at some point. I'd suggest "DCS-BIOS 2.0", because that is what DCS-BIOS was intended to be all along, but it would probably cause too much confusion because most people seem to equate "DCS-BIOS" with "The DCS-BIOS Arduino Library".

Done: Designing a common Export.lua file Let's take the discussion over there (and sorry for derailing this thread :) )

This thread exists to continue a discussion that started at post #14 in the DCS Integrator thread. The goal is to get the developers of software that relies on an Export.lua file to come up with a single, shared Export.lua implementation. The current situation Currently, we have several pieces of software that use an Export.lua file to connect real hardware to DCS or to implement a glass cockpit: Helios (Gadroc) DCS Integrator (ohall) DCS-BIOS ([FSF]Ian) HawgTouch (ClearDark) DCS Export Scripts by the Simpit Developer Association (HJPuhlmann, McMicha, tomcat97) (German forum) iControl DCS (boarder2) DCS Virtual Cockpit (and I probably forgot a few, PM me and I'll add them to this list. Does anyone know if there is anything in the Russian community?) Each of these comes with its own Export.lua file. In theory, the end user can mix and match multiple programs to get the best of all the worlds. In practice, this would cause a significant performance hit as the same data is exported several times and executing Lua blocks the simulation. It would also probably break down at some point because not all Export.lua files get all of the basics right, such as respecting previous callback functions and avoiding the use of non-unique global variables. Where we want to go 1. Build a single Export.lua file that talks a protocol we can all agree on 2. Adapt our respective software packages to work with that 3. Happy end users! If you are interested in working on this, please post your requirements and design ideas here. I propose that we start gathering ideas in this thread and see how many devs we get on board. After about two weeks, we should try to get together on Skype or TS because some things can be solved much faster that way. Later today, I'll post the requirements from my point of view and some lessons I learned from DCS-BIOS.

The german one looks correct. I assume you are converting from the standard US layout, which is why "<" is missing (the additional key found next to the left shift key in European layouts).

For DCS-BIOS, when flying around in a Huey, the typical update has between 110 and 130 bytes. In an A-10C, it is between 130 and 150, up to 170 bytes if I play with the throttles to make the engine instruments move around a lot. The initial update (containing the complete cockpit state, not just data that has changed) takes 342 bytes for the UH-1H and 758 bytes for the A-10C. Keep in mind that this also contains the position of every switch, dial, etc. which you probably don't need to export to your physical panels. Obviously these numbers will not directly apply to whatever protocol you are using, but they should give you an idea about the relative complexity of the Huey vs. the A-10C. Regarding duplication of effort: There are also some guys on the German forums who are implementing a new gauge pack for HawgTouch and a program to talk to Arcaze USB boards (German forum thread, GitHub). It is probably inevitable that we will end up with multiple approaches with different design goals. To some extent, this is even a good thing for the end user, because each program will try different things, we can see what works and what doesn't, and a little competition can improve the overall quality. There is however one part where we should really try to work together, and that is a common Export.lua file and aircraft definitions. As an end user, I'd want to be able to mix and match the programs that best fit my requirements without worrying about which one handles which aircraft and without having three Export.lua files that all export the same data in slightly different formats, each one incurring a performance penalty because it blocks the DCS process for a short time. If I can convince enough developers, I'd like to cooperate to design "the last Export.lua file you will ever need" (which was the original goal of DCS-BIOS). At this point, it is just an idea that has been nagging me for about a week or so, but here's a few requirements that have crossed my mind: Simple key/value export format, capable of exporting floats (cockpit arguments) and arbitrary strings (can cover everything else, e.g. CDU content, current aircraft name) Support UDP and TCP protocols Provide an input API to trigger LoSetCommand(), performClickableAction(), etc. and the ability to execute a snippet of Lua code in case we miss something Ability to add aircraft-specific add-on Lua files to export things that are not cockpit arguments (e.g. the CDU), which can be reloaded at runtime to speed up development Have the developers of at least three projects cooperate on this from the very beginning so it can hopefully become the de-facto standard Out of scope: TacView-like export of all objects in the game world Once we have something like that, the number of applications that consume this data would matter a lot less, because they can run on another CPU core or even on a different machine altogether. The next step might be to come up with a machine-readable representation (XML, JSON or Lua tables, maybe all three) to describe the data that is exported. Things like "this is a three-position toggle switch", "this argument value represents a pointer angle and this is the scale of that gauge (in case you want to display a numeric value on a character LCD)". That could eliminate a lot of the work of adding a new aircraft module, because you would only do it once and have the result work in all programs.

You are right, if all you edited was the MonitorSetup file, your cockpit screens should not be blacked out. I had assumed that you had edited the files to change the export names (so you can have different names for Ka-50 and A-10C for example) and something went wrong. Editing the indivudual XYZ_init.lua files for each indicator is the only way I know of turning off the in-cockpit displays.

How did you edit your Lua files? If you simply replaced them with ones you downloaded from somewhere, that is likely the reason. If you follow the link in my sig, you can read how I did it, and that works for me in 1.5.

If you have modified your BIOSConfig.lua, make a backup of that. Then just copy the new Scripts/DCS-BIOS folder over the old one.

Wenn du die MissionScripting.lua entsprechend anpasst, kannst du aus einem Missionsskript auf das Dateisystem zugreifen und beliebige Daten speichern und laden. Das ist selbstverständlich standardmäßig abgeschaltet, damit nicht eine Mission, die du aus dem Internet heruntergeladen hast, deine Festplatte löschen kann etc. Dann musst du deine Mission so skripten, dass sie alle relevanten Daten (Position von Bodeneinheiten, welche sind noch am Leben, etc.) speichern kann und diesen Zustand später wiederherstellen kann. Du könntest z.B. eine Liste von toten Einheiten speichern und dann beim Laden da einmal durchiterieren und die alle mit unit:destroy() oder sowas aus der Mission entfernen. Kompliziert wird das dann bei den Details. Wenn du eine Bodeneinheit hast, die Wegpunkte hat, dann müsstest du nämlich beim Abspeichern erstmal rausfinden, was gerade deren nächster Wegpunkt ist (nein, du kannst den AI-Controller nicht einfach danach fragen, das wäre ja zu einfach...) und dann beim Laden die richtige Route setzen. Entweder du benutzt ganz viel Geometrie und Mathematik, oder löst das anders, z.B. in dem dein Skript der AI immer nur einen nächsten Wegpunkt mitgibt und sich merkt, welcher das war. Wenn du das Warehouse-System benutzt, um die Munition der Spieler zu beschränken: das kannst du zwar auslesen, aber nicht per Skript setzen, du müsstest also die Mission selbst mit einem externen Tool editieren wenn du das unbedingt willst. Du willst speichern, wenn eine Brücke zerstört wird? Ja, du bekommst ein Kill-Event, aber destroy() auf Static Objects ist verbuggt. Irgendwo gibt es einen Thread, indem jemand (ich glaub es war chromium oder xcom) damit experimentiert hat, am richtigen Ort eine passend dimensionierte Explosion zu triggern, um das Gebäude nach dem neu laden zu zerstören. Die SAM hat alle Raketen abgefeuert und du speicherst ab? Nach den Laden hat sie wieder volle Munition. Auch hier gilt: du kannst per Skript nachsehen, wieviel Munition das Ding noch hat, das aber nicht setzen. Mit entsprechendem Aufwand kann man natürlich auch das nachbauen (bei jedem Schuss-Event selbst nachzählen, und wenn das Ding dann out of ammo sein sollte aber noch zwei Schuss hat, weil du zwischendurch gespeichert und geladen hast, die Rules of Engagement auf "DO NOT FIRE" setzen, warten, bis das Ding nachgeladen hätte, und dann die Einheit neu spawnen damit die Muni wieder voll ist). Die Antwort auf deine Frage ist also ein "Ja, aber". Ja, es geht, aber wie du das machst hängt von den Anforderungen deiner Mission ab. Deshalb gibt es auch keine fertige Lösung dafür. Du musst auf jeden Fall Lua können oder lernen, um sowas zu bauen. Wenn du das ernsthaft machen willst, schreib hier mal ein paar genauere Anforderungen rein, dann kann ich dir vielleicht sagen, wie viel Aufwand das ungefähr wird und wo du anfangen kannst, nachzulesen :)

Fixed in v0.4.1.

Released v0.4.1. A-10C: add AIRSPEED_MAX_IAS, COMPASS_BANK, COMPASS_PITCH, COMPASS_HDG A-10C: fix CMSP toggle switches (the "held up" position sent a wrong command to DCS) avoid spamming dcs.log with errors when in a FC3 aircraft add first draft of pointer calibration tool Please post comments in the DCS-BIOS Discussion Thread.

Sorry, that is a known bug that was filed months ago. I'll try to fix it today (the "quick and dirty but it works" instead of the "redesign the thing properly" fix). My problem with DCS-BIOS is that everyone is building panels and finding errors faster than I could keep up next to my curriculum and moving to a new place. I hope that changes now that I have finally moved (since last weekend, I have access to all of my electronics stuff again).

Ich stimme zu, dass die einfachste und zuverlässigste Lösung ein größerer Monitor ist. Gebrauchte 19"-TFTs (die haben typischerweise 1280x1024 Pixel) gibt es z.B. bei eBay Kleinanzeigen für 10 bis 20 Euro, wenn du nicht selbst abholen kannst musst du noch mal 8 Euro oder so für den Versand draufschlagen. Wenn ein größerer Monitor keine Option ist (kein Geld oder kein Platz), gibt es im Prinzip zwei Möglichkeiten. 1) Du machst deinen Desktop größer als deine Bildschirmauflösung ("panning desktop"). Dann kannst du über deinen Desktop scrollen, wenn du die Maus an den Bildschirmrand bewegst (wie in einem RTS). Ob sowas funktioniert oder nicht, hängt wohl von der Kombination aus Betriebssystem und Grafikkarte ab. Windows-Versionen bis XP scheinen das oft zu können, Windows 7 wohl eher nicht. Es gibt auch eine kommerzielle Software, die sowas angeblich kann ("GiMeSpace"), aber wenn du 18 Dollar dafür ausgibst, kannst du dir gleich einen anderen Monitor kaufen. 2) Du steuerst den Monitor mit einer höheren Auflösung an. Sofern der Monitor damit klarkommt, wird das Bild dann zusammengestaucht -- sieht auf einem TFT hässlich aus, funktioniert aber. Bei alten CRTs kann sowas den Monitor zerstören, wenn der dafür nicht vorgesehen ist (also vorher in der Anleitung nachschauen!). Bei TFT-Monitoren kenne ich nur, dass die einfach schwarz bleiben oder eine Fehlermeldung anzeigen, wenn sie mit dem Eingangssignal nicht klarkommen. (3: Du programmierst den DCS Mission Editor um, so dass die Schaltflächen woanders auftauchen. Ich vermute, dass die dafür relevanten Teile in Lua geschrieben sind und somit editierbar sind. Das ist aber viel zu viel Aufwand.)

I did a quick test in the 1.5 open beta and it looks like everything works without modification. If you find something that works in 1.2.x but is broken in 1.5, please file a bug report.

Lua errors are logged to %USERPROFILE%\Saved Games\DCS\Logs\dcs.log You can also use env.info("my message") to write your own entries to that log file. Another great way to debug Lua code is the Lua Console in DCS Witchcraft (link in my sig), which lets you execute snippets of Lua code inside a running mission.

In Windows, there is no concept of multiple mice and keyboards. A normal windows application cannot tell input from different devices apart at all (you need to use special low-level APIs for that). There is HIDMacros, which can tell apart input from different keyboards and mice. I have never tried it though, so I don't know whether it can do anything useful with mouse movement data or if it can only deal with mouse buttons. Then you'd still have the problem of getting that data into DCS. If you just want something to work and value your time, it is probably cheaper to buy an additional joystick or gamepad. If you want to get multiple mice working and don't care about how much time it takes you to get running, learn how to program and somehow combine HIDMacros with a vJoy feeder application.

Open the "bin" folder and run DcsBiosCOMHandler.exe. If that does not work, install the .NET Framework (but I assume Windows 10 will already ship with a recent version of that).

Yes, there is :)

I tested again with the Su-25T, which is also a FC3 aircraft. Got the same result you did (GetDevice(1) returns 1). A look at device_init.lua for the Su-25T: mount_vfs_texture_archives("Bazar/Textures/AvionicsCommon") attributes = { "support_for_cws", } --------------------------------------------- dofile(LockOn_Options.common_script_path..[b]"KNEEBOARD/declare_kneeboard_device_left.lua"[/b]) --------------------------------------------- Scripts/Aircrafts/_Common/Cockpit/KNEEBOARD/declare_kneeboard_device_left.lua: is_left = true dofile(LockOn_Options.common_script_path..[b]"KNEEBOARD/declare_kneeboard_device.lua"[/b]) declare_kneeboard_device.lua starts like this: local kneeboard_id = 100 if devices then kneeboard_id = devices.KNEEBOARD or 100 end So for FC3 aircraft (where the devices enumeration is missing), the Kneeboard gets device ID 100. The following works for me in the Su-25T: local dev = GetDevice(100) dev:performClickableAction(3001,1)