RogoRogo

this is a CAMERA DISPLAY, not a Lexus pip-mirror - how can anyone even think to type that an MFD-CAMERA FEED is "correct", when the camera image is flipped. The picture is the wrong way round on the Marshal, while the "Madrid" CAMERA FEED displays a correct, untinkered, non-reversed, as-is camera picture on the MFD. MFD location is irrelevant, and also the real life counterparts of these systems do not have a "mirror-flip" as a default state, and for very good reasons (mostly this is not even present as a deep layer option, and why would it). Quick google searches about certain markets' driven "car features" might a a slightly disorienting basis for AV-MFD functionality representation.

and as stated in this very thread, this bizarre option (and that is an OPTION in real life, not a default state or sole status design, and also very much not present on the actual Hoefyster testbed frames) does neither ergonomically apply to backup cameras displayed on MFDs in random locations nor in the context of a PC game. This niche option - while feasible for some, and some only, and only in real life - if a camera image happens to be displayed pip-style in a mirror or placed in "mirror location" does not qualify as being "correct", when it is completely unintuitive, unergonomic and outright confusing to the wider majority of the userbase. Highlighting this as "correct" when it is not only a bug in genesis but also does not apply to the vast majority of backup camera pip-displays in the A3 suite in really not contributive. The thought process behind doing so is even agnostically troublesome. The only, the ONLY suitable application would be an option toggle - somewhere. Which would we a waste of precious ressouces if seen from the potential usage rate. As for this sentence: " And since this thread is about reversing. How about those tracked vehicles. While reversing in any tracked vehicle press the control for vehicle left. Which way should the vehicle turn?", which is about controls. The vehicle should turn left, which is turning the forward hood right, and turning left in the PoV of the reverse vector. Unlike what they do now - that is to rotate left or right by control no matter the forward/reverse state. And the reasoning behind this is again not only simple ergonimics, control translation, de-facto standards but also simple fidelity. All the tracked assets have real life control setups that are visually represented in the ARMA suite that would result in this behaviour and by peripheral input translation (MKB, granular, sticks, wheels, pedals). The genesis of the current tracked control behaviour state is not design intent, it is bug manifestation, and by far not the only bug as there are foundational issues with vehicle controls in general, as examplarily outline fe here: https://feedback.bistudio.com/T157554

This is two years later, but the answer to the topic is rather simple. There is no "Pitch (analog)" and "roll (analog)" and "yaw (analog)"keybind entry in ARMA 3. When you move a joystick (in a helicopter the "cyclic"), you ADD input on that axis. Unlike a boolean keybpress (WASD) you can just define the amount of input added (so there is some weird sort of "granularity" instead of timed increments per buttonpress). But when the joystick recenters the input on the axis remains the same.. until you decrease the input "state" via joystick movement in the opposite direction. That applies to the collective too btw.. it is just less noticeable and less weird in experience. Same goes for the pedals/tailrotor, again less noticeable, because you either "yaw".. or not. Because - again - the joystick is not mapped to an actual axis, it is mapped to a keypress input, just with a granular (aka anlog) input device. So that is the issue on the control/input level - long before there could be any discussion about "flightmodel" (or absence thereof). Of course this means that in ARMA rotaries (planes too btw) actually fly on rails.. and the overall control experience has nothing to do with how a rotary would feel in control input. And anyone playing a flightsim (yes, DCS - but any flightsim, sim-lite or study-level and no, War Thunder "sim" is not a flightsim, neither by intent nor by code) will actually struggle, or at least think twice before risking to ruin his fluent control perception. This is why you have no reaction if you think you "roll the disc".. and will suddenly violently roll left when you add input on the collective. I took me a while (well.. an actual test of about 30 minutes) to understand that. Unfortunately ARMA is very odd in that topic overall... see fe a bugreport like this: https://feedback.bistudio.com/T157554 And while it could be argued that... "butbutbutbut everyone will..." "butbutbutbut no one does..." a product is defined by its intent. So even is the use of granular controls (aka joysticks) for asset control might be a minority segment - you cannot know the relevance of the segment if it is not allowed to exist. And you can even less define how it would shape the perception of the product's potential. But ... with Tencent ownership the chances of anything improving in actual mechanics are slim.. very, very, very slim. I'd dare type non-existant. Not because BHI does not have the competence (they do), or the ability (they do), or the self-expectation (they do) - they just will not be allowed to even think about it.

Service is realiably online - when there is absolutely no connections - aka during EUropean workdays and office hours. As soon as there is any connection load (EUropean evenings before a holiday or weekend, entire weekend) the service is unavailable. If "start with same unit ast last time" is checked in the ARMA launcher (that still features other functions that even create folders on local systems while actually not working or even confusing the full steam-integration functions) the data will show up (locally cached in client?). To have a successfull cohesive service experience for a "unit", every single member has to have joined on the units.arma3.com page at off-peak-times and also have had his client started via launcher when the service was up (aka at off-peak time). Idk if this service is running on some discarded laptop on a cornerdesk in the office and/or on a consumergrade connection - but this is simply the state of things.