Jump to content


  • Posts

  • Joined

  • Last visited

About v81

  • Birthday 01/01/2020

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Regarding this, is the Arduino Mega a *HARD* requirement in code, or does it just happen to be suited due to the number of serial ports it has? I assume 1 port is needed to speak to the host PC and then at least one extra to connect the transceiver to. In some Arduinos the UNO for example, the USB is connected via a USB/Serial adapter to the solo UART on the chip so that naturally rules the UNO out. The Leonardo has 1 port in addition to the dedicated USB/serial, sounds like for a single transceiver this should be valid. The Pro Micro also has the dedicated USB/Serial interface + one additional UART - very compact and cheap to buy. The FlightPanels arduino library now claims support for STM Blue Pill, that has 3 UARTs plus dedicated USB/Serial... ~ USD$5 shipped in single units i think? Am prepared to do my own testing (when appropriate parts arrive) but wonder if someone closer to the code could clarify weather the Mega is essential, or just an ideal candidate.
  2. Bit of a shame.. just not a Chrome fan but it's a small price to pay. My only previous experience is with BIOS is the original, it's great how it's browser agnostic. I'd have the browser open and watch something happen on screen and mirror on the hardware.
  3. I've confused the Flightpanels profiles to be the same thing as DCS BIOS 'modules' that are installed separately over that side of the fence. Have just installed DCS BIOS Flightpanels and found that all the aircraft are already inbuilt. Didn't realize that's how the FP version works. Now if only there were a way do do everything without Chrome I'd be fully happy. Any way the ditch the Flightpanels imposed chrome app nonsense? Kind of annoying to only need chrome for the one thing and not have full control over window size etc..
  4. @toutenglisseAppreciate your input. I was thinking more like ED could implement it in the game code itself. My level of programing is 0.1 out of 10... i can sometimes take a working script or program and tweak or adjust it to do something slightly different... but that's about it.
  5. This has been a issue for years, but I've never seen it reported. Happens predominantly on busier servers, If someone has returned from a sortie, taxied to the ramp and is shutting down / rearming / whatever and another player selects a slot that the first player is physically occupying the aircraft are destroyed. This presents an additional issue of there now being debris in that location rendering it useless until the debris de-spawns or the server resets. Spawning in the debris causes the same issue. Suggestions on how to deal with it range from trivial to significant work. Easy way, have the server check that the location is suitable to spawn in before inserting the joining player. Could do this by sampling weather or not another aircraft is present within xyz co-ordinates of the spawn center. Then delay spawning for new player with a client message saying the current location is occupied. Crude but effective enough to stop telefraging. Most complicated - have a system of aircraft inventory and some logic in the game itself to determine where 'client' aircraft spawn. Something should be done... can happen not at all or a few times in a session. Either way it's unpleasant and DCS should be better than to fall victim to such a simple issue. Can this get a look at please?
  6. Any chance this can get looked at?? It's a mission breaker and a game breaker when you're relying on this unit being destroyed to achieve something. Keep in mind the CH47 and a bunch of other aircraft suffer this issue.
  7. So... I'm lost. Is there a way to with Flight Panels then to connect physical I/O to DCS. Can flightpanels profile make an LED on an arduino blink.
  8. Yes... already reported 8 years ago... And several times since. This is game breaking in that if when playing multiplayer i want to slot for troop transport or logistics i remove hardpoints to reduce weight and get better visibility without the gun sight, then i cannot re-add the hard points Additional Info: Hardpoints appear for a moment only at time hardpoint 5 is loaded and flicks off again immediately when loading points 3,4,2,5 Hardpoints also appear for a moment only when loading hardpoint 1 and disappear when 6 is loaded when loading when loading all points - but this was not consistent. Attached is a demo mission file and also a track from same mission. This has been reproduced over and over and I'd love to see it fixed. Mi8 missing hardpoints.trk Single FARP support vehicles test.miz
  9. Would like the PKT to go. Would love to see the others become options. They don't have any place in a civillian bird. Could they be tied to the removal / installation of the hardpoints & gunsight (which currently has bugs persisting 2+ years... please fix this too!).
  10. Similar issues with other helos in AI hands. This was first reported elsewhere, i don't recall where over a year ago. Still happening and needs fixing. I have attached a TRK of an M1 Abrams emptying it's ENTIRE STORES into an Mi26 helo, and whilst the helo will be damaged it cannot be destroyed. That all HEAT, APFSDS, .50 and 7.62 bar for 1 accidental shot into the dirt when trying to recall the ammo switching bind. I have witnessed in Georgia at war an A-10C dropping a GBU-12 on an Mi-26 at Kras-Pash.... after emptying my tank into it.... only for it to still remain. 2 more GBUs later it was destroyed. This is broken, has been for >2 years. Track attached. I've seen reports of this being an issue with many helos in AI hands, please investigate. Indestructable Mi26.trk
  11. Can't see it, any chance you can link it? Here is where I'm looking... https://github.com/DCSFlightpanels/DCSFlightpanels-Profiles
  12. Can we expect an Apache profile? Is something holding it up?
  13. That's not what Mike has an issue with. As part of a bundle the sale is completely useless to anyone that has one or the other already. I was seriously considering buying the Tomcat, but i already own the Hornet, and that will be the case for hundreds of others. Doesn't seem well thought out. Anything on sale as a bundle should be on sale individually as well or else ED are simply going to miss sales from existing customers.
  14. With all due respect I think the forums are a better place to get feedback prior to such a massive change that is knowingly game breaking for a large portion of the playerbase. Good or bad, OpenBeta is treated as 'release' for the bulk of the MP community, and making such a massive change without consultation is just not sensible. I think the bulk of the frustration and fear are from several things, a few of what I list here others have repeatedly voiced... 1) Lack of communication / consultation. 2) The scale of the change 3) That it sets a precedent leaving us in fear it could happen again. 4) That other more important and overdue things aren't being worked on. For number 4 I submitted .miz files for fixed Su-25T training missions several (4?) years back, I literally did the work for ED, and ED sat on them and did nothing until years later, when they were actually (partially) fixed just recently. This issue put off new comers to the sim for years. Also on #4 a large portion of overdue or corrected functionality is provided by others in the form of files that now break IC, it's ultimately a slap in the face to people who have been doing ED's work for them. Did no one spare a thought for the likes of Warthog Project and others who rely on this functionality along with untold thousands of others?, and the time and effort they put into promoting DCS and sharing what they learned. Was it really necessary for us to lose the obvious functionality of CMDS and viewport configs? If these things are exploitable they should have been fixed behind the scenes, not by removing what is essential functionality for some of us. BIGNEWY, a lot of us just want to know how this happened, and want some assurance it won't happen again. The vast majority of DCS users are advanced in terms of following development and I think a bit of communication is owed. Lack of consultation and communication seems to be the core issue here, and is sadly a recurring theme when any drama happens, despite promises from ED staff that this would be improved on.
  15. Quoting @BIGNEWY from another thread. What cheats and exploits? We've been smacked over the head with no warning with this game breaking nightmare.... and there is no justification? What exploit were you trying to prevent by removing the ability to have instruments exported? What exploit was solved by removing the ability to set personalised CMD profiles? I'm really keen to find the genesis of this decision making. Someone knowingly did this, and surely should have known the obvious repercussions. DCS is build on the modding community, a large portion of the user base is running one mod or another, with many of them actually dependant on the mods for functionality (display exports, elevator trim fix, RWR fix, etc..) and overdue convenience (Dice, custom quick starts). The idea of coming up with a list of affected mods in that other thread so as they may be 'considered' doesn't sit right with me. My concern is, that the gate is being shut here for future mods that don't exist yet, and given how reliant I've become on mods, often providing functionality ED can't/won't/haven't yet I'm pretty bothered by it. I can see 1 thing happening for sure, many servers are going to ditch IC requirement either by necessity, protest or both. ED needs to wheel this back in full immediately. Whatever it was that was trying to be achieved needs to be done in a better and smarter way. White listing a limited selection of current mods and forcing future mods (when the majority simply provide near essential functionality) to go through what WILL BE a difficult, slow and convoluted process and even face a prospect of a ban hammer is ridiculous and should not be the solution. Removing exploitable items from these plain text config files seems to be a vastly superior idea, whilst leaving us the customisation we need to set-up our sims as we see fit. To ED I say... Don't make us justify our mods that you already know are good and sensible. How about you justify why IC got so broadly expanded with zero community consultation knowing full well it would break things. Are we going to have a good business / client relationship here, or are you placing yourselves as overlords and us as mere peasants? I think the above is more than reasonable and healthy debate should be allowed.
  • Create New...