pilotjohn

Sent, thanks!

What I would really like is custom sized touch LCD screens that I could display anything on, and trigger from there. FlightSafety has some classroom trainers that use this concept, but of course more overkill than I want.

Thanks, I can get it to trigger on TURN_RIGHT, which I think is good enough, but would be nice to trigger on KEY_DOWN/UP with short/long press. This seems to just "trigger" when I release.

I do. 🙂 I prefer visual feedback from the VC (instead of buttons blinking/changing). But I prefer some tactile/spatial triggering. My main use for SD buttons is to place them "roughly" in the location where I would reach for them in the VC (not always possible, but close enough). This way, flaps are not where I think flaps should be (e.g. flaps on XCub is left, not on the right), but rather, where you would reach for it in the aircraft (I have plans for having some above my monitor, but not there yet).

Any thoughts why this is not triggering when it's assigned to "CLICK"?

They're triggering virtual FSUIPC buttons, which seems to be very similar to your "WEB API" buttons. The reason I prefer this, is that the config for what to trigger remains in AAO, so if I want to move it to a physical button, I can, without touching Stream Deck profiles (for which I have scripts to swap out buttons per aircraft - to move layout around).

Sounds good, thanks. I'll ponder this as I plan my migration. The reason I thought about it is that this is like an OO design. You have a "base" configuration, which you inherit, but can then override. I can change the base configuration which will update everything that uses it, but things that are overridden would remain so. I could then chain the inheritence if I needed to.

Thanks. If I use this method, changing the template won't apply to existing aircraft, correct? If I link a template, what would be the best way to "override" things when needed by quirky aircraft? This is where I thought the layers would make sense?

Hmm... I save when it says "CLICK", but then the button doesn't trigger (neither down nor up, the green light never lights up). If I save it when it says TURN_RIGHT, it triggers on release. I'm planning on moving from FSUIPC to AAO. I'm using a simple FSUIPC Stream Deck plugin, which is just buttons, and using the buttons is the fastest migration path. I didn't have long-press, but would like to, but I see how I can do that in AAO instead of the SD plugin, so sounds good!

Hmm, ok. So, I'd prefer to have a "full" default template that I can apply when I get a new aircraft (I don't have THAT many buttons/axis). This may or may not fully work. If it does great, done. If it doesn't ... then what? I can always just change it, but if I make changes the default template (to expand more buttons etc.), it will not apply to any existing aircraft. Could I create a template with the just the custom inputs, and then apply that, merging into the existing (default) config? If there are any changes to the default template, or the custom template, I would have to re-apply both. I'm probably thinking about this wrong (like OO design), and it's not quite matching up.

I'm just saving is a template so I have somewhere to load it from. Basically it looks like, both layers move when I first duplicate the axis and switch the layer on 1, but after I apply the template again, or restart AAO, it's fixed.

I'm trying to figure out what's the best way to: 1. Have a base definition/setup that works for most aircraft. 2. That I can modify as needed and will apply to all aircraft. (optional) 3. Then override some functions for special aircraft. Is layering better (e.g. layer 0 default, auto-switch to a layer 1 on aircraft load)? Or should I just duplicate configs/templates, and when I update the "default", just merge it into any that were slightly customized, and exclude the custom axis/buttons during the merge?

To reproduce: 1. Duplicate an axis. Move it to layer 1. Note that the original still shows blank. 2. Switch to layer 1. Note that both axis move. (incorrect behavior) 3. Save template. 4. Reload template. Note that original axis now shows 0 on the left. 5. Switch to layer 1. Note that only layer 1 axis moves. (correct behavior)

Ok, I think this is a minor bug. This only happens when I first duplicate a layer 0 axis. If I save the template, and re-load, it shows a 0 next to the layer 0 axis, and then it works as expected. Before reloading the template, the left area of the axis is "blank", which seems to mean apply all the time no matter which layer is selected.

I did some testing, and if I have two axes, one on layer 0 and one on layer 1, bound to the same device input, both are triggering when layer 1 is selected? Is there a way to make layer 0 not trigger if layer 1 is overriding the behavior? The behavior for buttons seems to be different. If I have a layer 0 button and layer 1 button bound to the same device input, when layer 1 is selected, layer 0 does not trigger.

I'm trying out the simple button handling in Axis and Ohs. However, something weird is happening. When configuring a button, the button click works, and shows up as "CLICK" (button 0). Long press also works the first time, and show up as "CLICK" (button 1). However, after this long press, if I do another short press it shows up as "TURN_RIGHT". If I save the button using this "TURN_RIGHT" assignment, it seems to work. But if I save the button when it shows "CLICK" assignment, it doesn't trigger. What is "CLICK" vs "TURN_RIGHT" and what determines which one is triggered?

How does a non-0 layer override a definition in layer 0? Is it based on which device and input is assigned? For example, if I have a standard mixture axes in layer 0, but then create a layer 1 which splits the axis into several defined ranges that trigger different actions (e.g. like a detent condition lever), will that disable the standard mixture axis in layer 0?

Basically I'm looking to use both key down and up to toggle the ATC window. This way it "acts" like a push to talk button for ATC. In addition, when this button is pressed, other buttons (e.g. my hat switch), can be used to send key press 1-8. It sounds like this would all have to be scripted, correct?

I'm evaluating Axis and Ohs as a replacement for FSUIPC. I have a setup where pressing a joystick button down sends a virtual key press to MSFS (only), and another one on button up. Can this be done with Axis and Ohs? I can see the option to send a virtual key press, but it's not separate for up and down (and appears to be a general key press, not MSFS only).

Good for them... it's about time someone called ORBX's BS on "my way or the highway". I wish other developers would start making airports that seamlessly blend with FTXG or any of their areas. I'm wondering if ORBX libraries are used. I don't care either way, but I know JV would have a conniption if they were. The customer already paid for licensing it. I'm all for independent developers putting out sceneries that require ORBX libraries/sceneries. I see this as more sales for ORBX and more sales for independents. If I were to have to wait for ORBX to create every airport I hope for, I would give up on this hobby. I wonder what will happen to "support" of the 720 products that were developed for or branded ORBX? And I wonder if a similar conflict will rear its head with the Pilots/FSGlobal partnership they're doing for the vector add-on.

Oh I see it... I'm just trying to get the root cause resolved. As cathartic as this thread is for some, it's doing very little to convince ORBX to help. Now I'm simply trying (apparently unsuccessfully) to relay that ORBX has very little if anything to lose by offering a solution. My intent was not for this exchange, but to find a way for two products to work well together (in the end for the good of the community and of course for my own selfish reasons). I hope it's not too late for that, but I fear it may be. So it sounds like someone found a solution: http://forum.avsim.net/topic/419199-no-vector-road-lights-with-utx/page-4#entry2796533 But it also looks like he/she was scared away by the response from ORBX in this thread. This is unfortunate and proves a lot of people's points from above.

Can you at least share your texture findings? No need for the app...

Why do I get a sinking feeling that I have to take my ball and go home. There will be no help forthcoming for getting UTX to be fully compatible, and there will likely be more chest pounding if anyone does post info on replacing the appropriate textures. I do think this thread has taken on a life of its own. But if we go back and evaluate what would have stopped this from blowing up, it's ORBX simply saying: "Our bad, we overlooked something, sorry. We can't muck with someone else's stuff, but if you want to muck about it on your own, here's what you can do on your own in an unofficial fashion..." (maybe as a warning/note in the documentation). That effectively would have a put an end to this entire thread in very short order.

Perhaps I should have been more clear that I'm simply looking to know which ORBX textures a person at their own risk (without support) could copy to replace the custom UTX ones (e.g. backup file B, copy file A to the same name as the original B). I think that's really the solution that would fix all this. This is a minor effort from the developers, but for me (not being intimately familiar with scenery stuff) is an undertaking, which is why I reached out to the community that seems so adapt at fixing many things in this very odd hobby. Does it mean I won't buy FTXG Vector if this information is magically revealed? No, of course not. FTXGV could be the best thing since sliced bread and ORBX can have another $65. But while waiting for all that I would like to enjoy the little time I do spend simming instead of getting frustrated at the disconnect. Anyway, I hope this thread gets back on topic, maybe even with solution to come.

Thanks jV. All other posts/discussions aside, I was simply looking for a private community solution to make this all work and continue for it to be enjoyable instead of me avoiding certain areas (wasn't the reason I bought FTXG so I can fly in areas where I normally wouldn't? - It was, but now I'm back to avoiding them again). No one ever said anything about making programs public to move files around etc. It was simply a request to the well-meaning FSX community to see if there was a solution to this texture mismatch issue as there was to the night lighting. I don't even expect ORBX to make replacement texture. I just want to know how I can get them to match. From reading other threads, we're talking about less than a dozen replacements. But in all fairness, as some of my posts point out, I'm looking to have the full ORBX experience while maintaing all the great things UTX provides (the enhanced LC, polys etc.). Right now, I cannot because of the texture mismatch, and I can clearly tell if I'm flying over an ares that clashes. I think some of my analogies cover this. So what I'm getting is an either or situation. I either not use FTXG at all (in which case I'm back to where I was and out $100) or I disable/cripple some of the features of UTX (but that still doesn't completely eliminate all the mismatch - it eliminates maybe 80%), or I disable UTX completely. None of these are great solutions. A great solution is to simply get those silly textures to match which is likely possible and would be a 15 minute effort to reveal by either organization. Instead, as entertaining as it is, we've got this soap opera.