Jump to content

quantum69

Members
  • Posts

    10
  • Joined

  • Last visited

  1. Hi all, looks very interesting so I picked up a copy of TouchOSC and your TouchDSC. The communication is ok but the TouchDSC shows the following: info: DcsBios.Communicator.BiosUdpClient[0] Connection to DCS-BIOS opened warn: DcsBios.Communicator.Configuration.AircraftBiosConfiguration[0] Error parsing config file C:\Users\cheese\Saved Games\DCS\Scripts\DCS-BIOS\doc\json\A-10C_CDU.json, skipping... warn: DcsBios.Communicator.Configuration.AircraftBiosConfiguration[0] Error parsing config file C:\Users\cheese\Saved Games\DCS\Scripts\DCS-BIOS\doc\json\AH-64D_EUFD.json, skipping... info: DcsBios.Communicator.BiosListener[0] DCS-BIOS listener started info: OscCommunicator.OscDelegateReceiver[0] OSC listener set up info: TouchDcsWorker.Worker[0] Ready! warn: TouchDcsWorker.BiosOscTranslator[0] Unable to find matching DCS-BIOS command for VHFCOMM_PWR in aircraft (null) so it looks like TouchDCS isn't picking up which aircraft is being used. In this case I am using the UH-1H and the example file you included. DCS-Bios version 0.7.45 TouchDCS 0.3.0 Is this project no longer active? thanks Quantum
  2. Yeah, I took a similar approach and used the 3rd option of the rotary tile (ok, we'll use tile(s) to avoid confusion), the section that allows associating text with returned values. I used some of the standard ASCII values; 211,212, etc (the block characters) to do 4-state indicators. I don't know if the SD would recognize ASCII above 255 but at least good ol' block chars are there. I remember the days of the old ASCII drawings (I'm incredibly old). so text for the 1st state basically covers the underlying graphic, the 2nd state is effectively an empty string (though it has to be something) and allows 1st state graphic to be shown, 3rd state is like the 2nd; no text overlaying the graphic. Set the tile option for value=text accordingly. So a covered over tile is your off. value 0.0=<text that cover graphics>,0.5=<blank text,1.0=<blank text> I'll give that go. Good thinking there.
  3. @Bailey I see you took the route of concat your own strings with the var values in the mix. Nice. Does the export->SD (stream deck) allow embedded color codes in the strings? I noticed one of the pics you had an ECM button, the one with the A S... (auto=A I think for the bird your flying) letters in each corner and each letter was a different color. Did you gimp/mspaint the button and are just changing the number text in the middle? Just curious on that one. @CornAddictyeah, I use gimp and have made several buttons to deal with the current limitations. I had wished the SD SDK might have allowed multiple graphics per button and it was the plugin logic that was missing. Such that tri-state and more could be represented in a single button (I guess some people call them 'tiles' as well. a new lexicon...) Under the hood is just a touch screen so the SDK would have to be lacking in that regard <<-- huge assumption on my part. I'll have to go to the main DCS interface thread and read around. I just got here and DCS has been around a while, without having to build a 'pit', which is not an option for me, perhaps in addition to the SD's I can find a way to use the netbooks as well. thanks for the insights Quantum
  4. Hi all. New here and have been searching for information about all this. I know there are 3 or 4 primary GIT locations that seem to all be supporting the Stream Deck plugin by Charles Tytler. The stream deck plugin works fine and am using the default DCS interface v1.0.4 (july 7 2021). I have seen references to DCS-Bios as well as some other script exporters and am I'm trying to determine if what I'm looking for/to-do can be done with this plugin and the default asherao DCS-ExportScript from that same site. It looks like the plugin is no longer updated so that's question one, the second question is about the other script exporters and whether they would be a better selection. Since the plugin only has a small selection of options, I wonder if anyone who has used this and the exporters for awhile would be kind enough to answer a few questions? 1) there are no tri-state buttons in the plug-in. While a rotary can inc/dec a given ID value it can only display at most 2 visual conditions, and that conditional change can only be based off one ID value. Simplest example; Any 3-state switch in any cockpit. I was wondering if there was another plugin that has more input button options for the stream deck or if there was a way to use the Charles Tytler plugin to perform 3-way button graphic changes. I have seen some example screen shots in this thread that look like a full-string is being concatenated and is populating the text field of a stream deck button. What I haven't seen or know if it is possible with the current plugin, tri-state graphic changes can be done, or is there even a plugin that can. 2) since multi-state conditions like a 3-way switch and rotaries are, from everything I've been able to find so far, represented and controlled by 2 or more stream deck buttons; one button for increment and another button to decrement a value, is there another option to using Stream Deck as an input device to DCS using any of the available exporters? I have 2 stream deck xl's, so 64 buttons. I've had success using multiple buttons to overcome the 2-graphic limit (the switch plugin item and the temporary push-button with light button), but I would like to better emulate the conditions of the cockpit. One of the first that came up; AH-64D, APU. Open cover not activated (no text), Close cover not activated, then both of those have when the button is lit ("ON"). There's no way with the current SD buttons I've found to reflect that. I have a switch that graphically shows (and activates) the flip-up cover and another push-button that uses the unlit and lit states as well as the button push event. That's 4 states. The Fire Det panel is even worse since the underlying button has 4 conditions; Unlit, Fire, RDY, Fire over RDY and the 2 states of the cover. Is there a way to do this with the Stream Deck that anyone is familiar with or could they suggest an alternative physical interface? I've seen Touch Panel mentioned in other threads, and while I have a Win10 netbook (touch screen) that would work nicely, Touch Panel seems to be a phone (iphone/android) to DCS solution. It would be nice to find something I could run on the netbook (win 10) that could communicate with DCS and allow more flexibility in representing cockpit switch/rotaries/etc more accurately. I'm asking for suggestions from those who've been at this and have the knowledge. I've reached an impasse. Also, I do not have a 'pit' setup. I have Thrustmaster Warthogs, TWCS, TPR, 2 stream decks, 2 netbooks and a keyboard and mouse on desk. I don't have any space left for pre-built USB gear that I've seen on the net (and have no idea if the stuff is any good). At this point I'm hoping for a software solution using the Stream Decks and/or netbooks if possible. Thanks to any and all willing to educate me on what might available. Quantum
  5. like trying to fly a ham sandwich with a chainsaw
  6. @Art-JI thought that as well, after ripping off wings down to ailerons and observing that the diamond stopped moving with speed. What's curious, is if this is reflecting down-up draft caused on ailerons due to slipstream effects then shouldn't it be impacted by attitude and airspeed in flight? 100kph and faster and it doesn't move. Climb,dive,airspeed; none seem to cause any further drift. This offset seems a peculiar thing. I use Warthog and assigned throttle slider to ROLL axis as well. Unfortunately there is no setting to make 2 axis additive, but I can 'trim' (using this term referring to offsetting the forced offset) the aircraft back to wings-level. Of course any movement of the joystick and that's the axis that takes control precedence. I was just testing to see if there was an easy way to circumvent this peculiarity. I'm going back through the other WWII aircraft and see if this is happening and I only just noticed it in the Bf109. thanks all addendum: testing all WWII aircraft results Fw190 A-8 brakes on, aircraft stopped, increasing throttle = vertical diamond deflection. this seems to be localized to prop-wash only. Fw190 D-9 brakes on, aircraft stopped, increasing throttle = vertical diamond deflection. this seems to be localized to prop-wash only Bf109 K-4 brakes on, aircraft stopped, increasing throttle = no deflection. horizontal diamond deflection with airspeed ~ 0-100kph Spitfire LF MkIX brakes on, aircraft stopped, increasing throttle = no initial deflection. this is a unique condition. the diamond starts below the horizontal line, this is with elevator trim default position 0, so by default the elevator starts such that the top apex of the diamond touches the horizontal line, which is positive pitch. If you trim NOSE DOWN the diamond doesn't move, however, the NOSE DOWN trim does cause the diamond to deflect upwards from it's initial position as the throttle is increased. So this looks like prop-wash is affecting the elevator. Start a Spitfire hot on the runway, increase throttle = no deflection, add NOSE DOWN trim and increase throttle = vertical deflection. So however ED modeled the airflow is definitely taking place. P-51D no apparent deflection as the above aircraft. Perhaps having trim on all the control surfaces negated this impact. Using external view on the Spitfire with NOSE DOSE trim applied, you can see the trim tab is inclined from the elevator. Increasing thrust you can watch the elevator appropriately lower which reflects what's seen on the controls widget. Take-away. The old WWII aircraft have some truly obscene behavior. With the exception of the P51, the rest seem to have an almost catastrophic desire to madly roll on take-off. The torque modeling in DCSW is unlike anything I've ever seen in a simulator. I've flown Cessna's in real life for my private license and none of those experiences translate to just how twisty these WWII planes can be. But the math doesn't lie if the matrices are correct. Well done ED. All those other simulators must tweak the values so a player never experiences what an accurate mathematical model would do. I have to admit that they are a bear. I prefer the SIM experience to the GAME setting experience. Otherwise it's just like every other sim I've played. It's still a bear and I'll stick to that assessment take care all
  7. Just went into mission editor,picked Bf109, airborne. As soon as it starts and I activate the 'pilot controls' widget, the joystick center indicator (it's a diamond actually) is shifted to the right such that the left peak of the diamond is touching the red vertical axis. I don't have any trim settings in the special. I also have the takeoff assist set on 0. I don't know what's causing it, but is consistent. Quit back to M.E. and set it to 'take off from runway". Pulled up widget and the diamond is entirely centered. thanks addendum: I watched the widget while going down runway (not worried about crashing plane). As airplane speeds up, the diamond slowly slides to the right until it stops as described above. Any ideas? specifics: At 0 kph, joystick diamond centered. At 100kph, joystick diamond has shifted completely as described. Seems to start moving proportional to 0-100kph speed but then remains at 100+ kph after slipping sideways on grass and ripping off left and right wings to ailerons, the diamond remains center regardless of speed. So it is tied to speed-ailerons somehow
  8. Thanks. Let me elaborate to make sure we are talking about the same thing. The 'show controls' widget (the red boxes showing axes), the red cross marking joystick center, shifts to the right after takeoff. I understand the effects of torque and airstream causing the roll, what I don't understand if why the actual joystick center is being shifted. Is this an error, or was this an intentional effect to simulate the induced effects? I took the 109 from the ground to 30,000ft and the joystick center remained off-axis. If they were forcing the center to shift to emulate the forces at play I would have thought the center would drift during various maneuvers; e.g. left-rudder pushing the right wing causing it to lift works as expected but the joystick offset is permanent once off the ground and does not fluctuate. All the other aircraft, older and new, don't do this. Is there something I'm missing here? I can handle steering properly to maintain level flight, but having the joystick center forced off-center doesn't make any sense. I'm new to DCS World, though I bought the A-10A way back when and spent hours playing it. In the past few weeks I've picked up pretty much all the aircraft for DCSW. That's what is puzzling me, the other older aircraft have their quirks, the Spitfire is a bear, but the actual joystick center (the red cross) doesn't get offset once airborne. I'd appreciate knowing if this is just the way they do things in their code, for their reasons, or is there a mod or fix I need to apply to correct this? Adding a full time special tab aileron trim would seem to an odd way to address this, unless that's the fix for some code that deliberately moves stick center. It makes sense in the AH64 for the trim handler that has the physical hardware. If it's broken and that's just the way it is, ok. I've heard DCS World allows LUA scripting so I wonder if someone has found a fix for this externally. Guess I'll keep looking if that's the case. Thanks for the info on the special tab though. I saw that and figured it was just for nulling out the normal torque, like the setting in MSFS, didn't figure it for anything else. DCSW release version, not the beta. Take care
  9. Hi all. I've been reading through this thread trying to find a potential answer for the following problem I'm having. After take-off, the joystick center is shifted off-axis to the right. The stick shows correctly centered on the ground. Has anyone else seen this behavior? If so, is this intended? This adds a very noticeable right roll as you can imagine. No other aircraft exhibits this behavior. Thanks
×
×
  • Create New...