FSFIan

If your product is information only (plans and code), you won't have many people willing to pay money for your kickstarter, so I am going to assume that you plan to build and ship actual hardware panels, including electronics. Let's assume that you can convince people that whatever team you end up with is able to build the promised product. You are targeting a very small market. Flight simmers are already few and far between, but many of them cannot afford a separate computer just to put into a simpit and/or they don't have the space to dedicate to it, so they are not potential customers. If you are lucky, you might be able to fund a hundred panels at once. While you may save some money buying PCBs in bulk, there are several things that will increase your cost per panel significantly compared to a typical DIY solution. Regulatory compliance So you want to ship an electronic product within the European Union. You now have to deal with RoHS and WEEE compliance. Filing the paperwork for WEEE has to be done in each european country separately, I have seen an estimate of 30 000 EUR just for that alone. Then you have to deal with a random, non-zero chance that some government agency will call you and tell you there's a container of electronic waste somewhere and it's your job to dispose of it now (or more likely, pay someone else to deal with that for you). You'll also have to certify that the electromagnetic radiation of your product are within certain limits; testing that alone can cost 1 000 EUR or more. You need to self-certify CE compliance, which means your product is compliant with "any applicable laws and regulations". To find out what these are, you'll probably need to pay a lawyer. Sourcing Electronic Components If you are shipping products, you have to be certain that every component you put on a board is working, because dealing with returns from customers costs time and money. You also need a guarantee from your supplier that the part is RoHS compliant. Due to those reasons, you cannot buy your Arduino boards for $1.60 from AliExpress or your MAX487 transceiver for $0.20. An RS-485 transceiver costs about 1.30 EUR a piece from a typical distributor like Digikey, Farnell or RS if you order a hundred. No HASL finish with leaded solder either, that slightly increases the costs for PCBs. Customer Support Even if there are no dead on arrival products that generate returns, you will have people who are too lazy and/or too stupid to follow instructions. Since you sold them a product, you'll have to deal with them. This not only costs time, it can also be incredibly frustrating. And then you have those people who have a firewall, antivirus product, or even some unsuspecting third party crapware (Netgear, I am looking at you) that will interfere with DCS-BIOS. Shipping Costs The typical DIYer orders most of their electronics stuff from China with free worldwide shipping, which is subsidized by the Chinese government as far as I know. You will have to ship your finished product to your backers, which will increase the cost compared to the DIY solution. Tools If you are actually building and shipping dozens of units, you will need proper tools for soldering, inspection, and quality control, not to mention whatever you need to produce the cases to mount your switches in. The tools will have to be good enough that you can build many panels in a reasonable amount of time. EDIT: I don't mean that a kickstarter campaign has to be unsuccessful, just that crowdfunding is no viable way to save money IMO. It can still be a way to save time, at least for the customer.

Why use a capacitor and 20 minutes of labor per switch if you can achieve the same result by modifying the firmware of the microcontroller?

What does "display incorrectly" mean? This is one of the times where a photo or video is worth a thousand words (or more than two words are required). Don't tell me what it's not doing ("working correctly"), tell me what it's actually doing instead. Some possible issues are described in the SevenSeg documentation, section 3.6, "Example: Multiple Displays".

Quoting from the SevenSeg documentation, section 4.1: You are not calling disp.write() from an endless loop; your sketch only calls it once every time the value changes. Try this one instead: #define DCSBIOS_IRQ_SERIAL #include <SevenSeg.h> #include <DcsBios.h> SevenSeg disp(2, 3, 4, 5, 6, 7, 8); const int numOfDigits = 2; int digitPins[] = {10,11}; DcsBios::StringBuffer<2> clockSsBuffer(0x1102, NULL); void setup() { DcsBios::setup(); disp.setDigitPins(numOfDigits, digitPins); } void loop() { DcsBios::loop(); disp.write(clockSsBuffer.getData()); } By the way, don't try to use the timer-based multiplexing that the SevenSeg library offers. It is so slow that it ends up blocking other interrupts for so long that incoming data will get lost, so things will stop working. (We recently had that problem on the german forum.)

The environment that is used by net.dostring_in("mission", ...) seems to be the one where the Lua snippets from the mission file (i.e. the things that the Mission Editor autogenerates for trigger actions) are executed. I have not found any way to use net.dostring_in to get data out of the mission scripting environment, other than reading and writing user flags the way Ciribob does it in the thread you linked to. You can get string data into the mission scripting environment with dostring_in("mission", [[a_do_script('some_var="mystring"')]]), but the only way to get string data out of it while avoiding file and network I/O would be to spawn a new group with a specific missionId and then use DCS.getUnitProperty(missionId, DCS.UNIT_GROUPNAME) to retrieve the group name, and I am pretty sure that would have a very significant performance impact.

What exactly is the "scripting" environment? Which files are being executed in its scope? I was only aware of net, mission, config and export. If you can define a function in the scripting environment and make it accessible from the mission environment, you might be able to use something like net.dostring_in("mission", "my_scripting_env_function(\"param 1\", \"param 2\")").

The trigonometric functions in Lua, like in most other programming languages, use radians instead of degrees to express angles. A full circle is 2*pi. function deg2rad(deg) return deg/180*math.pi end function rad2deg(rad) return rad/math.pi*180 end

This is the part of using DCS-BIOS where you need to understand some programming basics. The following link looks like a good place to start: https://www.arduino.cc/en/Tutorial/Foundations#programming Reading the "Variables" and "Functions" sections at the link above should help you understand how variables and functions work, and explain what the "not in scope" error message means. You also need to understand the flow of your program: the setup() method will be called once at the start, so that's where all of your initialization code goes, and where you call DcsBios::setup() so DCS-BIOS can do its own initialization. Then loop() gets executed over and over again. From the loop() function, we call DcsBios::loop() so DCS-BIOS can check if any input has changed or an output needs updating. Whenever the seconds value of the clock changes, DCS-BIOS will call onClockSsChange and pass the new value as a parameter.

I am back at my DCS rig now. Nothing has changed for the A-10C and it still works on my machine. So I assume the only aircraft I'll have to fix is the Huey.

Guys, a recent DCS update might have broken most of the controls in the Huey and the A-10C, and possibly in the Ka-50 as well due to changing device IDs. I cannot verify this right now, as I don't have access to my DCS computer, but I know it happened with the Huey, and Warhog just told me that most of the A-10C stuff doesn't work for him anymore. I'll look into this when I get back to my apartment. If it is what I think it is, fixing it will be relatively easy, if somewhat tedious.

Bei mir auch.

That line will not be called repeatedly, but only once in a while when the clock second value actually changes. You should call it from your loop() function instead. The call to sevseg.begin() should go into the setup() function. Also, I cannot see any place in your onClockSsChange() where you are actually writing the newValue to the display. So even if the rest of the sketch had no issues the display wouldn't show anything, because you never tell it what digits to show. Do you mean there is some error that you cannot find? If there is an actual error message when you try to compile, please post it. When writing a bug report, remember to answer the following three questions: What did you do? Posting the code is a very good start, but it is a good idea to mention whether you could successfully compile it and upload it to your board. Sometimes it is also helpful to know the model of Arduino board that you are using and which versions of DCS-BIOS and the DCS-BIOS Arduino Library you are using. What did you expect to happen? In this case, the answer to this question can be mostly inferred from what you are trying to achieve, but it doesn't hurt to specify this explicitly. What happened instead? I am going to assume here that the sketch compiled and was uploaded to the board, but the display stayed blank (because that's what I would expect that code to do).

So communication works from DCS to the Arduino, but not in the other direction? Sounds like a firewall issue to me. Make sure that DCS.exe is allowed to listen on UDP port 7778. Also, check your dcs.log for any error messages related to DCS-BIOS or Export.lua. EDIT: This may not be anything on your side at all. I just learned that a recent update probably broke most of the A-10C controls in DCS-BIOS because some device IDs changed. I can't verify that right now because I don't have access to my DCS computer, but I know that the same thing happened with the Huey. EDIT2: I just verified that the A-10C still works on my machine, so it looks like you'll have to check your firewall settings.

You want popTask(). The underlying data structure you are manipulating is a stack, so the "opposite" of a push is a pop. The image on that Wikipedia page might help you visualize what is going on (and why pushing NoTask does not have the desired effect).

No.

The Lua Console works fine in both 1.5 and 2.0. The mission editing part of Witchcraft has been broken ever since the mission file format was changed (and I don't plan to fix it -- I'll either remove it at some point or merge the Lua Console into DCS-BIOS 2.0). The mission must be running and unpaused. The mission has to include a current version of MiST and then call "witchcraft.start(_G)" in a DO SCRIPT action. The MissionScripting.lua file has to be edited as shown in the README and the video. If it cannot connect, you should either get an error message in a message box or in dcs.log.

9.5. klingt gut.

Are you talking about a touchscreen that is connected to the PC running DCS or are you talking about an iPad or Android tablet device?

Those errors all look normal. Specifically, there is nothing related to loading Export.lua or DCS-BIOS in there. Make sure to run DCS at least once before trying to install DCS-BIOS. To verify that you have found the correct "Saved Games\DCS" folder, do the following: delete Saved Games\DCS\Logs\dcs.log run DCS verify that dcs.log has been recreated If you have a "Saved Games\DCS Warthog" folder, that may be a relic from the time when DCS: A-10C and DCS: Black Shark 2 were still separate programs (you are running DCS: World 1.5 with the A-10C module, right?). EDIT: Just re-read your post. Wait a minute... you only assume you have 1.5... there is a "DCS Warthog" folder... that's not a relic, holy shit when you said you installed DCS: A10 you actually meant installing DCS: A10, probably from the DVD it came on! ED replaced that with the "DCS: World" platform years ago. You download and install DCS: World, which is free and comes with the Su-25T. Then you can install the A-10C through the module manager (the icon with the square blocks on top of the main menu) and activate it with your existing A-10C key. Waiting for that multi-gigabyte download will take a while, but I promise you when you start a mission after going from DCS: A-10C to DCS: World 1.5 you'll agree it was worth it. Much better visuals and higher framerates. Also, you should try playing multiplayer some time!

I don't quite understand what you mean by "finding" a flag. You may want to look at the following two functions: trigger.misc.getUserFlag(flag) trigger.action.setUserFlag(flag, value) Example usage: -- if flag 35 is more than 6, -- decrease flag 36 by 1 and reset flag 35 to 0 if trigger.misc.getUserFlag(35) > 6 then trigger.action.setUserFlag(36, trigger.misc.getUserFlag(36) - 1) trigger.action.setUserFlag(35, 0) end

Stimmt, bei den Dingern gibt's ja die 7-Segment-Anzeigen gleich mit dabei (zumindest wenn man 4-stellige haben will). So ein Ding hab ich auch bei mir liegen, hat bei Aliexpress 1,40 € gekostet. Der Trade-off, aus China oder Deutschland zu bestellen, sieht ungefähr so aus: Aus China ist's ca. 5 Euro günstiger, dafür wartet man drei bis vier Wochen statt drei bis vier Tage. Und natürlich sollte man aus China keinen Support erwarten (höchstens die Versendung eines Ersatzartikels, wenn der erste defekt ist -- aber dann muss man wieder vier Wochen warten).

Your script does the following three things in order: 1. Add the radio command that will execute a function that sets the flag 2. Check if the flag is set -- if so, display a message. But the flag is not set because the player has not activated the command yet and the flag defaults to 0. 3. Clear the flag. The second solution sets up an action that is triggered by a Lua predicate. That causes DCS to regularly evaluate the Lua predicate (I think once every second). This means that there will be many "attempts" to display the message, and they all fail, until the user actually uses the command -- at that point, the next check of the flag will succeed, and the message will be displayed. You can simply add the action you want to the function you pass to missionCommands.addCommand: ---- adding radio commands local _path1 = missionCommands.addSubMenu("Ground units", nil) missionCommands.addCommand("Moving",_path1,function() trigger.action.outText("it works!!!!", 100) end,nil)

Schwer zu sagen. Es wäre zwar immer nur eine Ziffer gleichzeitig an, aber "So langsam, dass beim Aufruf aus dem Timer Interrupt andere Interrupts so lange blockiert werden, dass die Kommunikation nicht mehr funktioniert" und "so langsam, dass das menschliche Auge ein Flackern sieht" sind zwei sehr unterschiedliche Dinge. Angenommen, die Library will eine 8 darstellen, das sind 31 Aufrufe von digitalWrite() oder maximal 3100 CPU-Takte. Umgerechnet sind das ca. 200 Mikrosekunden. Wenn du die Refresh-Frequenz der Library also hoch genug setzt, dürfte es einige Anzeigen brauchen, bis du ein Flackern siehst. Die maximale Helligkeit wird allerdings abnehmen, da bei doppelt sovielen Anzeigen jede Anzeige nur noch halb so lang leuchtet. Ich würde den MAX7219-Chip empfehlen. Lokal zu kaufen lohnt sich nicht, da zahlst du für kleine Mengen 8 bis 10 Euro pro Stück. Die günstigste Möglichkeit, so ein Ding zu bekommen, scheint im Moment dieses Modul zu sein.

Export.lua belongs in %USERPROFILE%\Saved Games\DCS\Scripts for DCS 1.5 or %USERPROFILE%\Saved Games\DCS.openalpha\Scripts if you are using 2.0.

Ich glaube, dass das ein Feature ist, dass jeder Entwickler selbst einbauen muss. Vermutlich ist das so implementiert, dass beim Einschalten der GPU dann nicht nur im Flugzeug der Strom eingeschaltet wird, sondern auch ein external draw argument gesetzt wird, so dass das externe Flugzeugmodell um eine an der korrekten Stelle relativ zum Flugzeug positionierte GPU erweitert wird. ED könnte jetzt ein external draw argument dafür standardisieren und das beim Einschalten der ground power anmachen, aber das dauert wahrscheinlich auch nur zwei Minuten, um es selbst zu bauen. Der zeitaufwändigere Teil der Arbeit dürfte es sein, das GPU-Fahrzeug passend zu platzieren und die Kabel zwischen Flugzeug und GPU zu modellieren. Disclaimer: alles nur Spekulation basierend auf meinem sehr oberflächlichen Verständnis, wie Flugzeuge in DCS funktionieren