Jump to content

FSFIan

Members
  • Posts

    1301
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by FSFIan

  1. There is probably a more clever and more efficient way to do this, but if all you need is a "good enough" solution (i.e. you won't run this hundreds of times per second), the following should work and be easy enough to implement: 1. Calculate an axis-aligned bounding box for your polygon (x_topleft = minimum of all x coords, y_topleft = minimum of all y coords, x_bottomright = maximum of all x coords, y_bottomright = maximum of all y coords) 2. Pick a random point in the AABB, x = math.random(x_topleft, x_bottomright); y = math.random(y_topleft, y_bottomright) 3. Check with mist.pointInPolygon if it is inside your polygon. If not, go back to step 2.
  2. What code were you trying to compile and what version of the Arduino library were you using? It's great to see someone use the Arduino Library like it was originally intended: as an example to understand and adapt to your needs :thumbup: Sometimes I get the impression that many people think if it can't be done by copying and pasting from the reference documentation, "it is not supported by DCS-BIOS". It's probably my own fault because the intro video is all about "look how quickly I can connect this button and LED" instead of "here's what can be done with copy and paste, but if you can find the data you need in the reference docs and you can make your Arduino talk to something, you can make it work with DCS-BIOS".
  3. Note for future readers (because EDGE is right around the corner): the following applies to DCS: World 1.2.x There are several isolated Lua Environments in DCS: World. Disclaimer: I don't claim to fully understand this and I don't know if the following list is complete or not. I got to the understanding I have now mostly by reading the SlMod source code and experimentation. I think Speed knows a lot more about this. The mission environment is where mission scripts run. Because the mission script is untrusted code, the set of available Lua modules is restricted (most notably, access to the "os", "io" and "lfs" modules and the "require" function is removed). That prevents a mission file (which you may have downloaded from the internet for example) from being able to delete all your files or turn your PC into a spambot. You can remove those restrictions by editing the "Scripts\MissionScripting.lua" file (sometimes called the "sanitation module") in your DCS: World installation directory. The server environment is the one that the code in "Saved Games\DCS\Scripts\net\server.lua" is executed in. It provides hook functions to be notified of events in a multiplayer server, such as players joining and leaving. It is also the only environment I know of that has a way of interacting with the other ones (the net.dostring_in function). SlMod uses that function and a modded MissionScripting.lua file to set up UDP communication between the "server" and the "mission" environment to make more information and features available to mission scripts. The export environment is the one where Export.lua executes. It has access to functions that return information about the player's current aircraft. For aircraft with a clickable cockpit, it also has access to all the indicators and switches in the cockpit and can simulate user input. This requires editing the MissionScripting.lua file that is responsible for setting up the environment that mission scripts run in. Everyone who wants to host your mission will have to do the same edits on their server. While simply commenting out the line that removes access to the "require" function will work, it will also make the server vulnerable to malicious mission files. If you do that, you need to make sure to only run missions from trusted sources. A better way is to make a global function available that does the privileged work (such as communication over a network or writing to a specific file) but still remove access to the modules after that function has been defined. The function can keep a local reference to the module(s) it needs.
  4. Let's take a look at two different options to add 16 additional inputs. Price estimations are based on a quick eBay search (looking at ordering quantities of 5 to 10 pieces for the ICs and 100 pieces for the resistors): 2 8-bit 74HC165 shift registers (about 2x $0.20) plus 16 pull-up resistors (about $0.20): total cost about $0.60 16-bit port expander: The MCP23017 (available in I2C and SPI versions) costs about $1.00. Each pin can be configured as an output or input (with optional internal pull-up resistor) just like the GPIO pins on your ATMega. Both ICs are available in DIP packages. If the time it takes you to solder in 16 pull-up resistors is worth more than $0.40 to you, consider using the port expander instead of shift registers. If you want to go with a keyboard matrix approach but don't want to solder small packages, consider delegating the keypad scanning to a second Arduino Pro Mini board. There are many ways to skin this cat. If you were designing a product for a 500,000 unit production run, you'd simply minimize cost and be done with it. For a single-unit hobby design, there are many individual considerations that can influence that decision, for example software development time, how easy you can source the parts, what tools and test equipment you have, and assembly time. You may also want to deliberately choose an option you know will take you longer to implement just to learn how it works :)
  5. Have you tried doing the same thing to the server (i.e. editing the files in the server's DCS installation)?
  6. Not yet. Once people are actually using your code, you have to be aware of how the address allocation works when making changes to keep backwards compatibility. A good example is this commit. The buggy ENVCP_TEMP_PRESS switch was defined as having 30 positions, so DCS-BIOS had allocated 5 bits (2^5 = 32) to it. The fixed one has only 3 positions, so 2 bits (2^2 = 4) are sufficient. To avoid shifting the addresses of everything that is defined after this line around, we allocate an integer with a maxValue of 7, which takes up the remaining 3 bits in the address space. Verifying that it worked is easy though -- the diff of the JSON file should only show changes for the controls that were actually modified.
  7. I know that several people have started on Ka-50 support (got some questions via PM), but I have not heard back from any of them, so I don't know how far any of them got or if they have all given up. I asked them to start a thread on the public boards, which no one did. Maybe they didn't want to show unfinished code. But publishing things as early as possible is the only way to prevent duplication of efforts and later merge conflicts! (I won't put three different versions of Ka-50 support into DCS-BIOS.) Please start a separate thread for DCS-BIOS Ka-50 support and link to your existing code. The definitive way to test this is the When I developed UH-1H support, I had a Chrome open on another monitor. One tab had the interactive control reference for testing, the other tab contained the DCS Witchcraft Lua console which was pointed at the export environment. I would edit UH-1H.lua, reload the UH-1H part with the following snippet of Lua code, then hit F5 in the control reference and test my changes. dofile(lfs.writedir()..[[scripts\DCS-BIOS\lib\Util.lua]]) -- in case I changed / fixed stuff in Util.lua dofile(lfs.writedir()..[[scripts\DCS-BIOS\lib\UH1H.lua]])
  8. Follow the DCS-BIOS User Guide until you have the Master Caution Light example running (to set up DCS-BIOS and verify that it is working). Since you have programmed an Arduino board before (so the Arduino IDE is already set up), that will probably take less than half an hour. Next, start with a fresh TemplateSketch and look up the A-10C's RPM gauges in the Control Reference (switch it to "Advanced" view). You want to copy the "generic" code examples to your onDcsBiosWrite() function so it looks like this: void onDcsBiosWrite(unsigned int address, unsigned int value) { if (address == 0x10a2) { unsigned int lEngFanValue = (value & 0xffff) >> 0; /* your code here */ } if (address == 0x10a4) { unsigned int rEngFanValue = (value & 0xffff) >> 0; /* your code here */ } } Then replace the /* your code here */ comments with code that does something to the value (probably save it to a global variable to use in subsequent calculations). Note that "(value & 0xffff) >> 0" is a no-op, you can also use "value" directly here. The control reference JavaScript is not smart enough to notice this yet. To look at what values DCS-BIOS sends you (it remaps the numbers it gets out of DCS to a range of 0 to 65535 because 16-bit integers are easier to work with on microcontrollers than floating point numbers), you will want to set up the Google Chrome extension.
  9. I am not sure, but I think that means they use a modifier key that is not defined as a modifier. Try clicking the "Modifiers" button and make sure everything is correctly set up in there.
  10. Go to http://dcs-bios.a10c.de and read the User Guide. Then look up the gauge you want in the Control Reference. If you want a more specific answer, we need more context. What have you read/tried before? Where did you get stuck? What specific gauge (in which aircraft) do you want?
  11. It's more reliable (differential signalling) and still inexpensive. I2C is even more inexpensive because it's already built into the microcontroller (so it was my initial choice, too), but it was designed for communication over short distances with chips on the same circuit board. If you start adding more and more Arduinos to an I2C bus, at some point there will be (possibly intermittent) problems. If you don't have the experience and equipment (logic analyzer or scope) to determine what is happening, that can lead to a lot of frustration (and hard-to-answer questions). For RS-485, we will be able to confidently state "as long as you use this schematic and this type of transceiver, if you keep the number of boards per RS-485 bus below X, it will work." It is hard to come up with such a number for an I2C bus. So the short answer to "Why RS-485?" is "because I'll have to support it" (and it was recommended to me by Gadroc and Mike Powell, who (a) know more about this stuff than I do and (b) have actually built a simpit before). However, there is nothing stopping you from using I2C and UDP instead. The DCS-BIOS Arduino library is designed in a way that does not force you to use any particular method to communicate with the PC, and that will not change.
  12. Take a look at Unit.getAmmo(), Unit.getFuel(), and Unit:getDesc().fuelMassMax (see this thread for example code and output). However, getFuel() is bugged in multiplayer right now.
  13. For the special characters: This commit message lists the codes that DCS-BIOS maps them to and my python example includes a mapping of character codes to positions in the A-10C's CDU font texture.
  14. Those are Pro Mini boards. We will implement a protocol to make several boards communicate over a RS-485 bus. The last parts I need to start working on this have arrived at home and I will pick them up this weekend. WarHog has already designed a breakout board for the RS-485 transceiver chip that can go on top of a Pro Mini. A complete cockpit will use two or three of these RS-485 buses, each one will be connected to the PC using an inexpensive USB to RS-485 adapter. The theoretical limit for the number of USB devices (including hubs) connected to a single host controller is 127, but in practice I have heard of people having problems starting at a few dozen devices.
  15. Depends on what device your TFT is connected to and the type of connection (component video, HDMI, I2C, SPI, some parallel data bus, ...). That is conflicting information. Are you using an Android phone or an Arduino UNO R3 board? Also, what type of TFT display do you have, how is it connected and what controller chip does it use? If you are using the DCS-BIOS Arduino library, you would replace the "your code here" comment with code that puts the 24-character string in the "newValue" variable on the first line (line 0) of your TFT display. I don't know if an ATMega controller running at 16 MHz would be fast enough to run a CDU display (I have my doubts, but I have never tried). You may also be interested in agrasyuk's CDU build using a Raspberry Pi running a script written in Python.
  16. You need to edit the indicator's Lua files to make RWR_SCREEN etc. available as view names. See this link on how to do that.
  17. Not currently. We could reserve some of the address space for user-defined variables (e.g. 0xe000 through 0xeffe) and implement a POKE command to write values there. That mechanism could also be used to send calibration offsets (such as offset values for servos) to some panels. Pull requests are welcome, I won't get to work on this for a while (my current priority is to implement communication over RS-485). Are you thinking of implementing frequency settings that do not exist in the DCS Huey?
  18. Allerdings nur im SP, im Multiplayer-Modus funktionieren die Trigger, die auf Cockpitdaten zugreifen leider nicht, so dass du nicht herausfinden kannst, welche Frequenz eingestellt ist.
  19. Compared to the trigger system, Lua scripting is certainly a more elegant and scaleable way of building a mission like you have now. By dynamically spawning units, it should also mitigate the performance problems. Whether it is a better system to do what you are after depends on whether what you are after is possible to implement. Be aware that the power of the DCS scripting engine does not even come close to what you can do in ArmA. In the ArmA series, every aspect in the game is available to the scripting engine. In DCS, mission scripting was added more as an afterthought -- you can do a lot with the scripting engine that is impossible or very tedious to do with triggers alone, but there are several things that are simply impossible to do because not everything is exposed to Lua scripts. Here are a few examples of those limitations: The warehouse system is not accessible from Lua scripts. You cannot for example add supplies to an airport during the mission with a script. No way to re-arm units with a script. No fine-grained control over ground units (e.g. "shoot that specific enemy" or something like that) Things tend to break from time to time and it seems like fixing the scripting engine does not have a very high priority. Occasional bugs and weirdness surrounding the dynamic spawning of units. For example, if a client in a multiplayer mission kills a unit that was spawned that way, it will say "Player XY killed Building" regardless of unit type. For plausible looking units, you will probably still have to place them by hand in most cases (otherwise vehicles may end up on top of buildings or something like that). If you want to explore the DCS: World scripting engine, take a look at DCS Witchcraft (link in my sig). It provides you with an interactive Lua console that allows you to execute snippets of Lua code in a running mission and look at the return value -- great for experimenting without having to constantly reload the mission. PS: If you want pointers on where to start learning Lua (or answers to other Lua-related questions), please briefly describe your previous experience with Lua and/or other programming languages.
  20. You could write a separate program that you run before starting the mission. Such a program (written in whatever language you are most comfortable with) could get weather data from the internet and the current date and time from the system and edit the mission to match this. DCS mission files are ZIP archives. The most important file in that archive is called "mission" and is a serialized Lua table, which you can manipulate fairly easily either by writing your program in Lua or by embedding a Lua interpreter. To find out how to modify that data structure, you can change the setting in the mission editor, save the mission and then look at what changed.
  21. Let me answer this in two parts. (1) Can we get the system date and time from Lua? Lua has os.date() and os.time(), but mission scripts do not have access to the os module (because you don't expect a mission file that you have downloaded from the internet to host on your server to be able to read and modify every file your user has access to). This protection can be disabled by modifying the MissionScripting.lua file in your the DCS: World installation. (2) Can a Lua script set the mission's date and time? As far as I know, no. I don't want to say "this is impossible", because if you are willing to accept arbitrarily complex and convoluted workarounds very few things are truly impossible, but there is no direct way to do it. One such impractical workaround could be to edit the .miz file at mission start and then switch tot the modified mission.
  22. Ich hab 8 GB drin und schon die werden nicht ausgelastet (wenn DCS läuft sind 5 bis 6 GB belegt). Guck einfach mal im Taskmanager nach :)
  23. Eine SSD verkürzt die Ladezeiten deutlich. Ob es beim Fliegen einen Unterschied macht, dazu kann ich nicht viel sagen (der Rest meines Rechners ist da eher der Flaschenhals), aber ohne SSD hätte ich bei der Entwicklung von DCS-BIOS vielleicht entnervt aufgegeben.
  24. Take a look at DCS-BIOS. It covers everything in the A-10C. For the chaff and flare displays, select the "A-10C" module in the control reference and then switch to the "CMSC" category.
  25. To save code size, the build process used by the Arduino IDE disables some C++ features, including exceptions, which are required by the C++ version of the GeographicLib. The geodesic calculation routines are also available as a pure C library, which should compile on the Arduino (see "Implementations of the geodesic routines in other languages"). For conversion from/to MGRS, the MIT-licensed GDAL project includes conversion code: mgrs.c, Compiling the complete GDAL project (if at all possible) would probably result in too much code to fit onto the ATMega's program memory, but those two files look like they don't depend on anything else.
×
×
  • Create New...