FSFIan

Die Ingenieure, die den MSFFB Pro und MSFFB 2 designt haben, waren entweder Perfektionisten oder irgendwer hatte Angst in den USA wegen "Mein Joystick hat meine Kaffetasse umgehauen und mir heissen Kaffe auf den Schoss gekippt!" verklagt zu werden. Jedenfalls hat der MSFFB eine Lichtschranke. Solange die nicht unterbrochen wird (du also den Stick nicht greifst), bleiben die FFB-Effekte (und damit auch die Standard-Federung) aus. Wenn du den Stick loslässt, ist die Feder weg, der Stick kippt weg, und dann auch der Heli. Ein kleines Stück Klebeband über dem kleinen Loch am Griff (ungefähr da, wo dein kleiner Finger zu liegen kommt), schafft Abhilfe. Ich kann mit meinem unmodifizierten TM Warthog den Huey relativ gut fliegen, aber nicht lange, weil irgendwann der Arm vom ständigen gegen die starke Feder arbeiten lahm wird. Hab mir deshalb einen MSFFB2 besorgt, bin damit aber noch nicht so recht warm geworden. Der kleine Arcade-Griff ist ungewohnt, wenn man vom Warthog kommt. Der Stick selbst ist zwar sehr präzise, aber durch den etwas kürzeren Stick (verglichen mit dem Warthog) reagiert er auch empfindlicher. Zumindest bei meinem Modell hab ich das Gefühl, dass die FFB-Federung nicht sehr gleichmäßig ist, ich den Stick mit FFB also nicht so genau steuern kann (aber ganz ohne FFB ist auch blöd, weil dann jegliches Feedback über die Position fehlt). Außerdem ist die große Basis des Sticks im Weg, wenn ich den auf meine bestehende Center Mount-Konstruktion setze. Entweder ich hab ein Exemplar erwischt, was schon etwas verschlissen ist, oder ich muss mich einfach nur dran gewöhnen (hab erst ein paar Stunden mit dem MSFFB2, 50 bis 100 mit dem Warthog). Vielleicht hilft es auch, den MSFFB zu verlängern.

You probably went to GitHub, saw the link to me_3dview.lua and used right-click and "Save link as..." to save it. That won't work, because that link does not go to the raw file, it goes to a pretty website that shows the syntax-highlighted code. (If you open the me_3dview.lua you downloaded, it's probably full of HTML markup.) You can either click the link normally, then use the "raw" link/button on that site to get the file, install Git and clone the repository, or just use the "Download ZIP" button on GitHub to get the contents of the complete repository as a ZIP file.

I can't test right now, but the following should work: Group.getByName("Group Name"):activate()

@Exo7: I have read through your code and can't see anything wrong with it. The only theory I have right now is that your receive buffer is getting filled up under some specific circumstances. Using #define DCSBIOS_IRQ_SERIAL would fix that. I have pushed a commit to the master branch on GitHub now that should make IRQ_SERIAL work on the Arduino Mega, although I haven't had the time yet to test it on actual hardware or make sure it doesn't break anything on the Uno, so it's not in a release yet.

Here is a Lua solution that avoids having to use multiple triggers. You can execute it in a DO SCRIPT block at mission start, or at any other time. I included outText actions for illustration purposes. -- adjust these values to set the minimum and maximum delay time in seconds local minDelaySec = 2*60 local maxDelaySec = 30*60 local function doAction() -- this function will be executed a random amount of time after the current time -- for example, you can make it output some text: trigger.action.outText("action!", 0) -- or have it set a flag (the following sets flag 1 to the value 5): trigger.action.setUserFlag(1, 5) return nil -- do not reschedule end -- determine random delay and schedule execution of doAction() in the future local delaySec = math.random(minDelaySec, maxDelaySec) trigger.action.outText("scheduled delay "..tostring(delaySec).." seconds", 0) -- display the delay that has been decided on (you will probably want to delete this line before releasing the mission) timer.scheduleFunction(doAction, {}, timer.getTime() + delaySec) This is a good example for something that can be done with reasonable effort with the trigger system, but has a cleaner solution in Lua. The Lua solution also saves the effort of decreasing a variable once every second, so theoretically it has less of a performance impact, but the difference won't be measurable unless we are talking about an insane number of these randomly scheduled events. The biggest advantage of doing it in Lua is that all of the information (minimum and maximum delay time and the action that gets executed) is in one place, although you may want to remove all of the comments before pasting it into the small text field in the mission editor to keep things readable in there.

Sofern du auf der Black Sea Map unterwegs bist, könnte dich dieses Experiment interessieren (am besten auf einem zweiten Monitor oder Tablet/Laptop/Smartphone/intelligentem Kühlschrank benutzen): http://dcsmap.a10c.de Achtung, das zerlegt sich gelegentlich selbst, sollte dann aber innerhalb von ca. 2 Minuten wieder neu gestartet werden. Wer Interesse an ziviler ATC hat, dem möchte ich die folgende YouTube-Playlist empfehlen: Das sind Workshops von pilotedge.com, die sowohl den Sichtflug (VFR) als auch den Instrumentenflug (IFR) erklären, inklusive Karten lesen, Navigation und Funk. Sind recht lang (jeweils mehrere Stunden), gehen aber auch sehr ins Detail. Der Fokus liegt auf dem Funk; pilotedge bietet professionelle ATC für FSX und X-Plane an und richtet sich an Flugschulen und Piloten, aber auch an Simulatorflieger. Auf militärische Besonderheiten wird da eher nicht eingegangen, aber Navigation und Karten lesen funktioniert ja ähnlich (im Kampfjet hat man halt TACAN statt VOR/DME und benutzt teilweise andere Funkfrequenzen).

Ich stimme meinen Vorpostern grundsätzlich zu, möchte das Ganze hier aber mal aus einer anderen Perspektive beleuchten. Ich kenne mich relativ gut mit den Möglichkeiten von Lua in DCS aus, aber die einzigen Trigger-Aktionen, die ich benutze, sind "DO SCRIPT" und "DO SCRIPT FILE" -- ich hab mich also im Gegensatz zu vielen anderen zuerst mit Lua beschäftigt und dann mit Triggern. Falls ich hier was falsches über das Triggersystem behaupte, bitte ich die Leute, die sich damit auskennen, mich zu korrigieren. Mit Lua-Skripten kann man bis auf sehr wenige Ausnahmen alles machen, was man mit dem Trigger-System machen kann. Dabei gibt es durchaus viele Dinge, die zwar auch mit Triggern gehen, mit Lua aber deutlich einfacher sind. Zum einen kann man in Lua komplexe Bedingungen mit mehreren UND- und ODER-Verknüpfungen einfach hinschreiben, mit dem Triggersystem muss man sich das mit mehreren Bedingungen und Flags zusammenbauen. Bei den Flags im Missionseditor kann man schnell die Übersicht verlieren, weil man den keine Namen geben kann. Ja, man kann sich ein System für die Nummernvergabe überlegen, aber benannte Variablen sind da doch um einiges einfacher. Und natürlich kann man in Lua nicht nur Zahlen speichern, sondern auch komplexere Datenstrukturen bauen. Mit der Lua Console aus meinem "DCS Witchcraft"-Projekt ist es auch möglich, Dinge auszuprobieren, ohne die Mission neu zu starten; das geht mit Triggern nicht. Die Lernkurve von Lua ist deutlich steiler als die des Triggersystems, aber wenn du sowieso Lua lernen willst, ist es durchaus möglich, sich die Zeit zum Lernen des Triggersystems erstmal zu sparen. Wichtig ist, dass du bevor du im Hoggit-Wiki in die Doku zur Simulator Scripting Engine und den Mission Scripting Tools eintauchst, erstmal Lua selbst lernst. Die Aufgabe dieser Referenzdokumentation ist, dir zu zeigen, welche Lua-Funktionen es gibt, um Informationen über die Spielwelt zu erhalten und Dinge zu beeinflussen (z.B. einer Gruppe von Einheiten einen neuen Befehl zu geben). Du wirst dort aber weder Programmieren im Allgemeinen noch Lua im speziellen lernen. Und ohne Grundlagenwissen in Lua (tables, Kontrollstrukturen wie if, for und while, Funktionsaufrufe) wirst du es schwer haben, die Beschreibungen der dir zur Verfügung stehenden Funktionen zu verstehen.

For some reason (i.e. "what was I thinking when I wrote that?") the SwitchMultiPos class defaults to position 0 when it should default to the last position that was seen: https://github.com/dcs-bios/dcs-bios-arduino-library/blob/v0.2.1/Switches.h#L87 Changing that line to "return lastState_" will fix that. I'll add that fix to the Arduino library soon. Implementing debounce timers is a trade-off between features, performance and memory usage. Method 1: make sure there is a certain minimum delay between separate reads of the switch status. Implementation 1a: call the delay() function in your loop() function. This has the disadvantage that you waste the time you spend waiting when you could have spent it on other computations, but it's a viable option when all we are talking about is a couple of switches. Implementation 1b: Store the last poll time for each control and return early from its pollInput() method if millis()-lastPollTime<threshold. This will allow other things to be processed while waiting, but requires additional memory per control. Method 2: implement a small state machine for each control that ensures a new switch state is only recognized if it has been unchanged for a certain amount of time. Similar advantages and disadvantages as 1b, but requires another byte of memory per control to store the current state (or stealing some of the high bits from an existing instance variable). I will have to think about what the default solution should be here.

The DCS-BIOS data format is described in the DCS-BIOS developer guide. It also describes how to connect with multicast UDP or TCP, which don't require editing BIOSConfig.lua. As you are writing your program in C++, you may be interested in the ProtocolParser::processChar() method in the Arduino library, which implements the state machine to parse that data stream.

Like ESAc_matador said, a DCS mission will include any scripts it depends on in the mission file itself. I guess the mission author has mentioned those dependencies to make you aware that if some future version of DCS is incompatible with the version of MiST or CTLD that come with the mission, the mission may fail to work because of that.

...because you don't have to. You will have to start a mission, enter an aircraft and unpause it before you can see anything on your physical panel or in the interactive reference documentation, but you can start the connect-serial-port script and DCS in any order you like. Yes, you can capture this data with your own program. See the developer guide for details. Note that DCS-BIOS does not have Mi-8 support at this time. And yes, it's off-topic here, a new thread would have been more appropriate (see below, or the "What to post where" section in the DCS-BIOS Overview thread). @Everyone: Please stop posting in this thread. Open a new thread for any question. Yes, I know that you have to come up with a meaningful subject line for that, and that takes an extra ten seconds of effort. But it will make it a lot easier to find that thread in the future, so the answer to your question can help someone else. Posting everything into one thread also gets really confusing when there are two (or even more) conversations going on at the same time! If you think the thing you want to post is not "noteworthy" enough for its own thread, and no one will have a need to find it again in the future, you can use the DCS-BIOS Discussion Thread.

You never call BIOS.lua from your Export.lua file. You will have to follow the full setup instructions in the User Guide.

Wenn du es an einen Arduino anschließen kannst, dann kannst du es mit DCS-BIOS verwenden, also ja. Die Frage ist dann immer, wieviel Code du selbst schreiben musst. Einen Hall-Sensor kannst du aber aus Software-Sicht wahrscheinlich wie ein Potentiometer behandeln, letztendlich erzeugen ja beide eine Spannung an einem Analogpin. Der Poti-Support ist allerdings noch ein bisschen kaputt, da muss noch Code rein um das Rauschen zu unterdrücken. Ich komm nur leider seit Monaten nicht dazu, weil mir die Zeit zum implementieren und testen fehlt.

That's normal on Windows 10, it's a warning and not an error, and that message does not prevent it from working. Could be a number of things: Firewall or Antivirus issue DCS-BIOS not set up correctly Some other add-on which uses Export.lua does not play nice with DCS-BIOS Check your dcs.log for any error messages. And try updating DCS-BIOS and the DCS-BIOS Arduino Library to the most recent versions (although I doubt that will solve this particular issue, it's a good idea in general).

Gar nicht. Der Chip unter dem 12 MHz-Quarz ist ein CH340 USB-auf-Seriell-Wandler, und nicht der auf den Originalboards verbaute ATMega16U2. Der CH340 kann wirklich nur von USB auf TTL-UART übersetzen, den ATMega16U2 kann man per DFU-Modus neu flashen, so dass er sich gegenüber dem PC nicht als virtueller COM-Port, sondern z.B. als Joystick meldet. Auf Uno- und Mega-Klonen wird der ATMega16U2 gerne durch den CH340 ersetzt, weil das einen Preisunterschied von mehr als einem Dollar ausmacht und für die meisten Benutzer keinen Unterschied macht. Das steht dann auch oft in der Artikelbeschreibung. Wenn du einen Mega mit ATMega16U2 brauchst, kannst du entweder ein Originalboard kaufen oder einfach drauf achten, dass in der Artikelbeschreibung explizit erwähnt wird, dass ein ATMega16U2 an Bord ist, wie z.B. hier (aus China) oder hier (DE). Wenn ein Bild dabei ist, kann man auch nachsehen, ob der Chip rechteckig (CH340) oder quadratisch (ATMega16U2) aussieht. DFU steht für "Device Firmware Update". Auf den Original Mega-Boards (und exakten Klonen) kannst du den ATMega16U2, der den seriell-auf-USB-Adapter spielt, in diesem Modus versetzen, wenn du zwei bestimmte Pins kurzschließt, und kannst den dann umprogrammieren. Damit kann man aus z.B. aus einem Mega einen USB-Joystick machen.

When you use DCSBIOS_IRQ_SERIAL, the DCS-BIOS Arduino Library supplies its own code to handle the serial port interrupts. That means that you can't use the built-in Serial object anywhere in your program, because that will bring in the default Arduino code for that, you end up with two definitions of the interrupt service routine for the receive interrupt, and get an error message like that. Double-check the code of the graphics library you are using and make sure there is not a single call to Serial.print() and friends in there. Even if it will never be reached in the program flow, such a line will still cause the default Arduino serial code to be compiled in and conflict with what DCS-BIOS tries to do. If you find a line like that in the library, simply commenting it out should make things work.

You have to #include the Servo library before you include DCS-BIOS. The following should work (it compiles, I have not verified it on actual hardware): #define DCSBIOS_IRQ_SERIAL #include <Servo.h> #include "DcsBios.h" DcsBios::ServoOutput flapPos(0x10a0, 5, 544, 2400); /* paste code snippets from the reference documentation here */ void setup() { DcsBios::setup(); } void loop() { DcsBios::loop(); } Background: The ServoOutput class depends on the default Servo library, which ties up some of the hardware timers on the microcontroller when it is included in a sketch. If DCS-BIOS would include the Servo library for you, it would force you to give up those resources even if you are not using a ServoOutput anywhere. The "fix" for this problem is to have the user explicitly include the Servo library and have the DCS-BIOS library only define the ServoOutput class if the default Servo library has already been included. To make that work, the Servo library has to be included before the DCS-BIOS library. A less confusing solution (and what I plan to do in the long term) would be to move the ServoOutput class to a separate Arduino library. The same would apply to other possible additions, such as support for I2C I/O port expander chips.

In that case, use mist.scheduleFunction in an initialization script to schedule a custom function that checks your condition, and set it to repeat once a second (or slower, if you don't need your trigger to react that fast).

Iterate through the mist.DBs.zonesByName table and build a new table with the zone names. Warning, the following code is untested: local zoneNames ={} for k,v in pairs(mist.DBs.zonesByName) do zoneNames[#zoneNames+1] = v.name -- since the zone names are the table keys, zoneNames[#zoneNames+1] = k would also work here end

Released v0.2.1 of the Arduino library. This update only has a minor change: the MasterCaution example sketch has been fixed.

If you try to understand the Scripting Engine Documentation or the MiST documentation without having a solid background in the basics of the Lua programming language itself, you will be confused a lot. It would be like trying to do a type rating for an A380 without having a pilots license: the type rating teaches you the A380-specific things (such as how to tune the COM1 radio to a specific frequency and where the push-to-talk button is), but it won't teach you about the ATC system or how to talk on the radio. Once you know Lua, you can look at the Scripting Engine Documentation as your toolbox. MiST adds even more tools to your toolbox -- some are high-level functions that handle the details of commonly needed operations for you (such as respawning or teleporting a group of ground units), others are small utility functions that you could write yourself, but don't have to (such as doing vector math). You do not need to know how to use each tool in your toolbox right away, but you should have a general idea of what's in there. Scan through the entire documentation at least once, even if you don't understand everything right away, to get an idea of what tools are available to you. The Lua Console in DCS Witchcraft will let you iterate much faster. Even professional programmers routinely write code that does not work on the first try, so it is quite normal that lots of trial and error is involved. That gets more important when you are writing Lua scripts in DCS: World, because the Lua interpreter cannot catch as many errors up front as a compiler for a strongly typed language such as Java can. Being able to fix an error and retry your code snippets within five seconds instead of having to wait for the mission to reload will save you a lot of time and frustration. Here's something that might get you started. This code snippet returns the number of blue ground units in a trigger zone. It is a slightly adapted version of the example for the searchObjects() function. If you change the return statement to something like "return numBlueUnits < 5", you could use it as a Lua Predicate that returns true as soon as there are less than five blue ground units in the trigger zone. local sphere = trigger.misc.getZone('name of trigger zone') local volS = { id = world.VolumeType.SPHERE, params = { point = sphere.point, radius = sphere.radius } } local numBlueUnits = 0 local ifFound = function(foundItem, val) if foundItem:getCoalition() == coalition.side.BLUE then numBlueUnits = numBlueUnits + 1 end end world.searchObjects(Object.Category.UNIT, volS, ifFound) return numBlueUnits

I did not, because there was no need to. The Lua Console works fine with current versions of DCS. Make sure you use a current version of MiST. The unit moving part is probably broken, use this hack instead.

Did you read the Tutorial: Introduction to Lua Scripting that is stickied in this very forum? It seems to be a common theme that people want to start with Lua scripting, take one look at the hoggit wiki, and then get this deer in the headlights look because they see a lot of information at once and don't know where to start. Maybe I should do a screencast about this at some point... Here's a list of steps I would recommend to get started: Download and set up DCS Witchcraft. It gives you a live "Lua Console" that allows you to write and execute snippets of Lua code while the mission is running. When something does not do what you expect it to, you can instantly try again. Here's a screenshot of what it looks like: https://jboecker.github.io/dcs-witchcraft/dcs-witchcraft-alpha1-luaconsole.png Make a simple mission that loads a current version of MiST, calls witchcraft.start(_G) as described in the DCS Witchcraft readme, and has a few ground unit groups with names that are easy to remember. Learn Lua! The documentation for the scripting engine and MiST is a reference for the functions that DCS and MiST provide; its job is not to teach you the core programming language. You don't have to know all of Lua before jumping into the fray, but you should at least know how to use local and global variables, do basic math, and how to work with tables (the data structure that Lua uses for everything). You can learn about flow control (if statements and loops) later. Take a look at the Group and Unit classes. Whenever you need some information about units on the map, you will need to use their member functions. It often starts with a call to Group.getByName(). Read this post, where I describe the general process I go through when I want to do anything with the scripting engine Use the Lua Console to experiment with the ground units in your test mission. Grab a group object with Group.getByName, get a specific unit by calling getUnit() on that, and see if you can use the Scripting Engine Documentation to make sense of the return value of getPosition(). See what happens if you call unit:destroy(). Try respawning the group with MiST. Play around with the trigger.action.explosion function...

I have never tried this, but as far as I know, every time the game spawns a ground unit (including aircraft that start on the ground), it only looks at the X and Z coordinates. It figures out the Y coordinate (altitude) by casting a ray towards the ground and seeing where it hits something. (Related: the discussion in the MiST thread starting at post #958.) What might work here is the following: - spawn several static objects or ground units on the parking spot to build a stack of things - spawn your aircraft - remove the "ladder" objects you spawned before It might end up just making everything explode on spawn, though. If you are only targeting single player, you might be able to trigger a failure somehow, but I don't know if there is a failure that would kill the engines but allow them to be restarted again.

You did not place a "moving zone" on the APC, because there is no such thing. You placed a trigger zone that happened to be centered at the APC's starting location. How can there be no concept of a moving zone when there are trigger conditions like "unit inside moving zone"? Note that the unit that the zone moves with is an attribute of the trigger condition and not of the zone itself. In other words, placing that zone in the editor is just a convenient way to graphically specify a "radius" parameter. Whether a zone is treated as a moving zone or not depends on the trigger action or script command that you use it with. We can, however, use mist.teleportToPoint instead. The following teleports the infantry to a random point four meters away from the APC, assuming the APC group is called "apc" and the infantry group is called "infantry": local apc = Group.getByName("apc"):getUnit(1) mist.teleportToPoint({groupName="infantry", point=apc:getPosition().p, action="teleport", radius=4, innerRadius=4}) If you want to, you can get fancy and calculate a spawn position in relation to the APC position. The following example spawns the infantry group five meters behind the center of the APC, so they don't get overrun: local apc = Group.getByName("apc"):getUnit(1) local apcPos = apc:getPosition().p local apcDirection = apc:getPosition().x local spawnPos = mist.vec.add(apcPos, mist.vec.scalar_mult(apcDirection, -5)) mist.teleportToPoint({groupName="infantry", point=spawnPos, action="teleport"}) BTW, when testing these, I wondered why they wouldn't work, then read the ****ing manual and noticed that MiST refuses to spawn units on airports and taxiways to avoid blocking AI aircraft :doh: