Project BetterJoysticks Plugin

[TCR_500]

I've been working on a control system for Orbiter that I'm modeling after Solar Lander's control system, which I'm calling "Better Joysticks". I've decided to open-source the project after about a couple months of slow progress. Here's a link to the repository of what I have so far. The Visual Studio solution is configured for Orbiter 2016.

GitHub - TChapman500/BetterJoysticks: An Orbiter plugin designed to improve joystick support by enabling the use of multiple devices, and changing control assignments and responses.

An Orbiter plugin designed to improve joystick support by enabling the use of multiple devices, and changing control assignments and responses. - TChapman500/BetterJoysticks

github.com

 

[Fabri91]

Thank you!

 

[TCR_500]

I do need help with this project.

 

[Boxx]

It's interesting actually: beyond the atmospheric flight, how can we use a "BetterJoystick" in space? Maybe you can describe where you were blocked and the backlog that you've got in mind. Having people involved in a new open-source dev is challenging, for sure...

(BTW: where is your open-source license in the repo?! should be at the root)

 

[TCR_500]

The name "Better Joysticks" refers to the plugin extending Orbiter's joystick support capabilities beyond its built-in capabilities. Also, it's incompatible with Orbiter's default joystick handling system.

As for the license, not really sure what type to use or why one would even be necessary.

 

[Urwumpe]

As for the license, not really sure what type to use or why one would even be necessary.

Without license, its copyright protected by default. Thats why a copyleft license is always mandatory for any open-source project. No licence and the source code is (legally) just read-only.


In some jurisdictions like , you also need a small formal written consent by contributors to agree to your licence and give up their individual copyright on their contributions, in case you want to avoid having to remove their contributions if they later disagree and get a lawyer....American law is much less complicated about contracts.

 

[Gondos]

If you can wait for the next version of Orbiter, here's what's in store for advanced built-in joystick configuration :

It's subject to modifications but the node based configuration will stay. I don't see many alternatives if we want to access most core functions from joysticks and adapt to the diversity of controller outputs (an xbox controller's trigger button send -1 when untouched and +1 when fully pressed, it needs to be converted to 0-1 for the thruster API, similarly the output from a thrust lever is -1 when fully backed and +1 when fully pushed and it needs to be converted to 2 values in the 0-1 range for main and retro engines).
Here 2 joysticks are used to configure the thrust, control surfaces and camera orientation. Some other hooks to the core API are shown on the right but you don't have to plug everything.

 

[Urwumpe]

Looks like configuring this might be a bit complicated, also the visual representation could be cleaner, I fear with many more lines on the drawing, it could become hard to read. Maybe a filter to show and hide certain input devices and hooks could be useful.

But in general, the idea is nice, I wouldn't want to stop you there. I just think that some more design iterations could be helpful to improve usability as well. Is it possible to chain multiple transformations ("Splitter", "Scaler") in your model? And also, could the different types of entities maybe get different shapes?

 

[TCR_500]

If you can wait for the next version of Orbiter, here's what's in store for advanced built-in joystick configuration :
View attachment 42485
It's subject to modifications but the node based configuration will stay. I don't see many alternatives if we want to access most core functions from joysticks and adapt to the diversity of controller outputs (an xbox controller's trigger button send -1 when untouched and +1 when fully pressed, it needs to be converted to 0-1 for the thruster API, similarly the output from a thrust lever is -1 when fully backed and +1 when fully pushed and it needs to be converted to 2 values in the 0-1 range for main and retro engines).
Here 2 joysticks are used to configure the thrust, control surfaces and camera orientation. Some other hooks to the core API are shown on the right but you don't have to plug everything.

That reminds me that I need some way of linking two different controls in such a way that they can act as one without outright deleting the assignment of the other if it detects a duplicate.

 

[Boxx]

here's what's in store for advanced built-in joystick configuration :

aren't there any features for space-flight? e.g.: thruster up/down, kill rotation and other nav modes.... would be nice to keep piloting with the joystick when docking, for instance.

 

[Gondos]

Looks like configuring this might be a bit complicated, also the visual representation could be cleaner, I fear with many more lines on the drawing, it could become hard to read. Maybe a filter to show and hide certain input devices and hooks could be useful.

That's the main issue. Look at this monstrosity : https://www.orbiter-forum.com/threads/linux-playground.40476/post-611856

aren't there any features for space-flight? e.g.: thruster up/down, kill rotation and other nav modes.... would be nice to keep piloting with the joystick when docking, for instance.

Yes there are autopilot and HUD nodes. You can even control the mouse cursor.
I'll create a dedicated post when I resume work on this, it is far from ready for release.
My original point was that there is work in progress for advanced joystick configuration in the Orbiter core if the author can wait for the next release, not to hijack this thread.

 

[Urwumpe]

That's the main issue. Look at this monstrosity : https://www.orbiter-forum.com/threads/linux-playground.40476/post-611856

Thats really a piece of art.

 

[TCR_500]

Well, here's what my plugin will be able to do once everything gets implemented. Speaking of which, I still don't know what type of license to put in the repository.

 

[Boxx]

here's what my plugin will be able to do

is that only in atmospheric conditions? in vaccum, I really think that the equivalent of <arrow> and CTRL+<arrow> should be implemented with RCS thrusters.

what type of license to put in the repository

Depends on your sensitivity, just search for details on the web and pick up a copy of the wanted license, but here are some insights:

• you want further dev to stay open-source -> GPL
• you don't care -> MIT
• if you re-use third party code, make sure you can do so.
• if you modify third party code, comply with their license

 

[Urwumpe]

Speaking of which, I still don't know what type of license to put in the repository.

Maybe that helps you:

Choose an open source license

Non-judgmental guidance on choosing a license for your open source project

choosealicense.com

(Yes, it pretty much narrows things down to what Boxx already wrote - but give you some more options)