derammo

this issue is being worked on the discord

yeah that's real nice. If we could only find a retail wrapped one like that, for those folks who don't want to tinker and want a nice enclosure

PS: I can always get a deterministic result by just including the whole desktop or at least the left edge in the layout. That's not the question. There are folks who have a left screen they don't want to have DCS draw on, so they can use it for other stuff.

If you set the "Resolution" to something that is smaller than the entire desktop, and your main display is not the left-most display, then DCS tries to be smart about how it places your views. Even though the left offset is not specified anywhere in monitor setup, it will try to fit to your main screen and any screens to the right of that. If it can't, then it will do the pessimistic thing and start at the left edge of your desktop. However, it still seems to try to fit it to include the main display. For example, if you have a tall screen on the left like I do, it will fit the specified extent such that it hits the main screen instead of being off to the top of it. In short, it is trying to be clever. Sometimes it ends up with a good result, sometimes not. Here is my question: Is this algorithm documented anywhere? I am implementing Helios features for viewports and monitors, and I am trying to make Helios correctly generate the monitor setup and viewports. But in these scenarios, DCS won't do what it's told. :) So I really need to know precisely what it will do. This would be a lot of wasted time testing if I have to figure it out from scratch.

Absolutely please do ask if there is an API somewhere or if it speaks any standard protocol. Specifically, we don't want to interoperate with the software, we just want to support the hardware device as a "controller." Maybe it already is a game controller anyway :)

I took a look. It seems like it is tied to their Air Manager software. This software seems like Helios for civilian sims. Since the knob itself would probably not be worth much $$, this makes sense and I doubt they would have an open interface. I found none. However, we should totally borrow/steal the interaction style! I love it. We could do something like "touch any rotary control and then you have a few seconds to grab a rotary input controller and start noodling." For the actual hardware device, we could use something that comes up as a game controller initially, because we have that code. The Phidgets interface is about to be de-rusted and should be possible to use also, maybe? Otherwise, we would have to support something people can buy directly like a FlightPanels box. Right now we support turning knobs with a mouse wheel, but you have to mouse click first, which is nonsense on a touch screen. So supporting this "press on rotary and then turn physical knob" is genius. Cheers.

Yeah at least they called it Ikarus, to make it absolutely clear they are reimplementing Helios instead of contributing to Helios.

You should say "I have not found documentation." Please don't spread misinformation. There are: - the users guide (ok out of date, but it introduces how things work) - a growing wiki for up to date stuff - a support community in the Capt Zeen discord Sorry here are links: - Users guide is installed together with Helios, or you can get one here: https://github.com/BlueFinBima/Helios/blob/master/Helios/_Documents/Helios%20Release%201.4%20Users%20Guide.pdf - The wiki right now is being populated with things that aren't documented elsewhere. So when someone asks a question that should have been in the docs, I tend to write a short wiki page for it for the future. I have not imported the entire user guide into wiki yet. https://github.com/BlueFinBima/Helios/wiki - Capt Zeen discord is where we hang out and answer questions https://discord.gg/KHmkTXe Cheers, derammo

You can create your own custom gauges if you can draw/find/steal the images required. However, the bigger challenge may be to create the exports for it, since Helios does not come with an interface for the Spitfire. You would have to use the Generic interface and feed it the information using export.lua code that you write yourself. It isn't at all simple.

I apologize for shitposting, but I would like to congratulate you on your post title. It is definitely true that WW II in general kind of sucked and could use lots of improvements. I think that is something we can all agree on.

Since I hear this complaint a lot, I don't think there is any way to set them separately. If someone else knows, please let me know as I am currently collecting a set of "reference patches" to include with Helios and the stroke defs are definitely in there. If there is a better way, I want it.

Nice work! Reviewing your Export code, I want to say welcome to the club of people who use 'R' and 'C' as the only upstream commands. I really wonder who wrote the origin code that all that is copied from (I know you got it from s-d-a's stuff) as in whether Gadroc started it from scratch or whether it is older than that. Anyways, your Lua is very nice! Much more Lua-ish than mine. Cheers!

update since people are still finding this thread: For most people's setups, this problem goes away when you disable the "press and hold to right click" option. For the rest of us, my workaround is a feature in Helios since https://github.com/BlueFinBima/Helios/releases/tag/1.4.2019.0611

sounds like you just don't have the monitor setup right. Please join the Capt Zeen discord and discuss in the #viewports-support channel, because this sort of thing tends to require multiple rounds of interaction https://discord.gg/87xampz

Some of the planes have basic "data cartridge" support essentially by allowing the module to grab mark points from the F10 map (this works in the Harrier for example) But this is specific to the module and unfortunately isn't common tech across the aircraft. So there is no API I am aware of where you can load waypoints in any common way.

Will the supercarrier use the same clickable defs infrastructure for its stations that 3D clickable cockpits use? If not, could you please consider providing an API in the export.lua sandbox so we can build third party addons (like Helios) interfaces? If you are just using normal clickables with args, could you maybe do a pass over that and see if there is stuff you might want to include for the benefit of addons that need to hook into export.lua? I am asking now because I doubt there is any chance in hell to get things like that built after it is finished. Here are some things that would be great to get via export.lua: 1) any controls in the various human-usable stations, so we can build cool Helios interfaces for people who like playing at those stations (presumably that would be free if you are using the usual clickable cockpit tech.) 2) whatever tables represent the queues of aircraft being marshaled around by the AI and moving about the carrier, so we could build status displays or enhanced stations [edited: what I really wanted was to figure out how to get ball lights into a VR overlay, but that doesn't work because it would need to be something on the aircraft side, oops :)] Maybe some of these can be accommodated if you haven't finalized everything yet.

The F14 doesn't have good native Helios support, so your best bet is to take Capt Zeen's profile and cut things out of it to make the thing you want to build.

Fakum: You seem to know your stuff. Any chance you could spend a little time telling me more details about your experience? I work on Helios and I have a rig similar to you (a little faster *brag*) so I can reproduce what you are seeing if we can get to the details. Then I would try to do something about it by improving the performance. I will send a PM also with contact info.

Not in the game. There are some third party efforts to scrape info from the F10 view and send the appropriate keystrokes/bindings/clickables to input the numbers for you. But no "data cartridge" style technology built into the game.

What are the exact semantics of render_target_always? Under what conditions is a viewport not rendered, if render_target_always is false?

ok, but that doesn't change the bug I am reporting. screen.aspect is no longer available in the Lua file. Of course it is easy to work around, but it's a bug if devs just randomly remove stuff from an API :)

Dear mods: could you please classify this as a BUG / NOT A BUG / FIXED ?

This doesn't have anything to do with Helios. You might have better luck in a thread about "exporting" viewports. [edit] never mind at this point we might just start a new thread for Helios :)

I second the recommendation for a hub with switches. Being able to turn things off without yanking cables preserves the quality of those connections. Also, it is kinda cool to switch on all your stuff as you are setting up for a DCS session. I use this one https://smile.amazon.com/gp/product/B07G8CMR18/ref=ppx_yo_dt_b_search_asin_image?ie=UTF8&psc=1 since I wanted something flat that I can bolt to my console and also I like the high power charging port on it.

Great find, thank you for sharing! If this crops up a lot in the future, we could put a test in Helios that checks if this is set and lets the user know.