Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Adapt special function "Instant Trim" to choose between sticks->subtrims or trims->subtrims #3300
When doing a maiden, sticks to subtrims is handy. But when doing minute adjustments for certain flight modes, especially on gliders, this is way to coarse.
It would be nice if you could send the trims to the subtrims instead, and clear the trims after the event, as you can from the servos menu.
It could be an option on the SF Instant Trim.
No reason for you, for me there is. Never asked it before, and normally I don't let anybody tell me to do or do not do something, apart from my wife. I might listen to good advice though.
I'm sorry if I annoyed you, or if its to much trouble to respond with some respect. I know you told me to grow a skin. I have one.
OK, maybe it was someone else, sorry.
Then, for the 10th time - take the time to explain it in detail with usage examples, what can't you do with the current state, why it would be better than it is now!
So yes, from your description it seems useless, maybe a complement of info will change it, but... you should really know how it works by now, we shouldn't have to beg for the info we need every time... that is the bit that is annoying. If you want something try to think from our point of view, see why we might resist it, and back your case accordingly. "Yes I know I could do it that way, but it would be better to have a dedicated function for it because XYZ". If there is enough info we can understand you and discuss. With unsufficient info we have to try and interpret ourselves, maybe wrong, and the reply will just be the first feeling we have about it.
And for the record, there is no "sticks to subtrims" function in the first place - only "sticks to trims" (instant trim) and "trims to subtrims", for safety reasons (instant trims is thus constrained to 25% effect - unless you really want to take the risk and enable extended trims beforehand).
Again, for the 10th time, you're considering every request that is already
True, if you have priorities to meet, those are not prio one. That doesn't
My general use case is to prevent ANY changes using the purely technical
Your general use case is you don't care, people should learn it.
As said, that's your choice, but an ignorant one. Ignorant to all people
I will not stop posting ideas if I think they are useful to me. I will not
Still trying to help make opentx a better system,
I never asked you to stop posting ideas, they're welcome, BUT be clear about them.
OK perfect, that's all I wanted to know! Now I know what your goal is with that ticket. Was it that hard? Had you put that in your first post you wouldn't have had that response.
I spent 2 hours a couple of weeks ago in #3263 (comment) to explain you that we needed to know the broader context for your proposals and not just scattered small issues we can't understand why you'd want them and where they would fit on their own, and you seemed to have understood, especially given that you had precisely been asking us about the same thing.
Now you do just the same and didn't improve your way to present your suggestions a single bit, so yeah I'll get annoyed since I obviously completely wasted my time.
You know we aren't going to change the fundamentals of OpenTX, and that everything we do is going further in the same direction we've always been going. You thus know that when you ask for something we'll look at it from the point of view of how things are done in OpenTX, and this issue makes no sense seen from that perspective given that we already have a perfectly good way of doing that, that fits the OpenTX paradigm. If your request is to be seen differently from what we usually see things or is about going in another direction, you have to mention it.
Then this doesn't seem like a good way to achieve what you want - IMO given that the instant trim needs to be configured in an SF that needs interaction with the OpenTX UI - or you do it in a script. If you do it in a script, it would make more sense to ask for the trims->subtrim to be made available to scripts so you can invoke it from your custom UI...
To me the system you want has nothing to do with OpenTX and is not "better" or "worse", it is just different. As such it should be a completely different project with different goals, a different philosophy, different people, a different target audience i.e. while your ideas are good in their context they're pitched at the wrong place. Trying to somehow blend 2 things with completely opposite goals just causes everybody to lose their time. You'll continue to present ideas that are good in your vision of things and with your goals in mind but they'll continue ending up in /dev/null because they go against ours. You'd be better off creating something dedicated to your goals.