Outerra forum
Outerra Engine => Ideas & Suggestions & Questions => Topic started by: cameni on March 08, 2015, 02:09:47 pm
-
Extended controls system will allow aircraft/vehicle scripts to register for and handle generic and custom input actions, that can come either from keys or HID buttons/axes bound in iomap.cfg files, or from clicking/dragging a 3D cockpit element (later), or even from external plugins in case of cockpit makers.
Script registers an action handler like this:
this.register_button("air/starters/engage", handler, options)
Where the handler is a JS function that gets invoked on value change, and options define some extra properties. Later it will also define 3D mapping so that when user clicks on the cockpit element, the same handler is invoked as well. The action name doesn't actually have to exist in the configuration at all, but if it does (user adds it), it will become also possible to invoke the action via keyboard/HID binding. This way it will be possible to customize bindings by the user even for special addons that would otherwise not be able to handle custom mappings.
So, vehicle script specifies the following when asking to receive an input action:
- hierarchic action name (doesn't have to exist in config files, in which case it won't be linked but mouse clicks will still work)
- handler, a JS function(value, channel, dt)
- options: min (initial) and max rate of value change, in other words how fast the value changes from 0 to 1/-1 when user presses a key, which is useful when you want to tie this value to a steering wheel angle, for example
- options: centering rate - how quick the value goes back to zero after being released (can be 0 to remain)
- number of steps for key/button bindings that increment or decrement value in discrete steps, rather than smoothly adjusting it
- 3D cockpit elements or model-space areas bound to action modes, usable in clickable cockpit
- action group, which can be used to enable/disable groups of input actions, for example on switching seat when one may want different controls bound
In config files, controls are arranged in groups, as in the existing iomap config. Each control action has a name, which is used to reference it, in the format cfgname/group/action, e.g "air/engines/throttle". Cfgname is the name of the config file, in this case air.iomap.cfg; you can also have different configs for different vehicle types and the config name is used as the prefix.
For each control action you can have multiple bindings, keys or buttons or joy axis that set the value of the control that is received in event handlers. You can have multiple bindings with different modes, where the mode tells how the button changes the value. For example, you can bind keys with modes that set the target value to 1, 0 or -1, or increment/decrement it in steps. There are also some advanced modes like a toggle (still respecting the ramp parameters) or "combo", which allows you to bind a single key that normally functions as a toggle, but with a shift it sets the target value to 1, with ctrl to -1 (or 0 if an volume range was asked), and ctrl+shift+key resets the value to 0.
Script can also ask to receive symmetric (-1..1) or unsigned range (0..1). Note that button press handlers completely avoid all this and just invoke the handler when the key/button is pressed.
This allowed us to reduce the number of control actions considerably. For example where X-plane has various _on/_off/_toggle/_reset varieties, here it's just a single control action that can have different keys with different modes bound. Some people will be good just with a toggle, some can have on/off mode keys or buttons, or all of them.
Inc/dec key modes allow adjusting the value in steps given by the script.
Additionally, each bound control can specify a channel id. For example, if you have multiple engines, you can bind separate keys for each, all done in the same control action but with binding specifying a channel id. ID 0 (or no id specified) is assumed to be the global action, like turn (on/off/toggle) all engines. Aircraft scripts should always handle the default one, in case people do not have the specific controls bound, and then any extended channels they want to handle.
Some open questions:- should we split the config files into multiple ones, like having one for common aircraft controls and then separate ones with extra controls for turboprops and jets, or should all aircraft stuff be in one file
- what should the default control set be?
- note that most of the controls will be unbound, but we want to have a good base set so that people do not have to invent custom ones, ending up with many different names for the same action
- on the other hand, there's probably no need for some rare ones, or ones that will almost solely be accessed via clickable cockpits - how to transition from current system:
- for aircraft there are default event handlers that can be enabled as groups (for planes or helis), which directly set JSBSim properties without script intervention. It will be good to have this preserved, not having to bind each basic action in every aircraft script, but we also need to have possibility to disable it.
- for vehicles, present temporary extended key system will probably have to be removed, since it's not very compatible
Current WIP aircraft command list is attached below.
-
You`ve done it again guys. I can`t wait to try some clickable cockpits.
-
Maybe we could just see where it takes us ?
I can't say what I want for a plane, as each plane is different, for example a fluid cooled engine requires radiator cowling controls, an air cooled doesn't... but then there's engine cowlings as well..
And I don't want to be descriptive and risk limiting ourselves.... why not leave it open and see what scripts are created and then 'suck' the commons ones in... ?
-
{ name : "no_smoking", comment : "Toggle smoking sign", bindings : [] },If this not makes hardcore flight simmers happy... :))
More seriously, it seems like a solid and flexible system.
Later it will also define 3D mapping so that when user clicks on the cockpit element, the same handler is invoked as well.
It may be useful to add the possibility for the player to move the camera position on y and x axis while pressing the middle mouse button and moving the mouse when inside a vehicle. Some elements may be difficult to reach or hidden in some specific vehicles.
-
Actually Acetone your reasoning is why I prefer not to use 3d cockpit elements...... in real life in a combat situation it's got to be instinctual... like using the gear stick on a car, you don't look at it, your hand reaches for it and changes gear.... a simple key press...
I'm not saying there's not a place for 3d cockpit elements, as there is.... I'm just saying there's a balance.
-
On the other hand, 3D animations are much enjoyed by civil Aviation simmers.
-
that's why I said there was a balance.
-
Startup using clickable cockpits is great, and gives a lot of fun, imho. You actually can learn to do it in real life. Guess it implies a lot of extra programmation, to simulate the procedure accurately.
-
Bravo on the progress. Now for 3d trees!
-
should we split the config files into multiple ones, like having one for common aircraft controls and then separate ones with extra controls for turboprops and jets, or should all aircraft stuff be in one file
Id say, splitting it would be good.
I hope vehicles would work an similar way, whyte possible different config files for all "hardpoints" on them ... maybe ... well, would be there also a way to use multiple configs from one position (assuming, thy wont have owerlapping controlls) ? ... i just thought, if it would be possible to "build" some aspects of vehicles in a specific way. Imagine having a radio-eqipement in vehicles. For, one, it would be easyer to controll the radio by two persons when the vehicles structure allows it in psychical means (that they arent in different capsules, but side-by side, outside the script-needed aspect), and also letting open the way for some sandbox aspect - lets say, you would copy the radio-spec. script into another vehicle (when they have the same equipement), so you dont have to copy-paste the whole thing into the others script, but just saying him, he has it there. ... doesnt have to be in OT like this (it is intended for specific purposes mostly, so not much people would actually physicaly need it this way at all, and programmers on a serious specific project on the OT engine in the future would surely be able to do it themselves for it), but it might be interesting.
-
It's going to be the same system for vehicles and aircraft both.
Vehicles can group the controls and enable/disable them in at once, so you can decide which ones are active depending on the seat or whatever).
It may be useful to add the possibility for the player to move the camera position on y and x axis while pressing the middle mouse button and moving the mouse when inside a vehicle. Some elements may be difficult to reach or hidden in some specific vehicles.
Lets talk first about getting into the mode where you actually have a mouse cursor and can click on cockpit. In discussion with ddenn we talked about using RMB-hold or RMB-toggle to show the cursor, and mouse wheel for zoom. Normally mouse x,y axis is for turning and pitching, respectively, but maybe in that mode it could include leaning?
-
Lets talk first about getting into the mode where you actually have a mouse cursor and can click on cockpit. In discussion with ddenn we talked about using RMB-hold or RMB-toggle to show the cursor, and mouse wheel for zoom. Normally mouse x,y axis is for turning and pitching, respectively, but maybe in that mode it could include leaning?
... leaning ? Wouldnt it be a little weird whyte oculus´s or other tracker use then ? But is true, sometimes, stations can have obstructive objects in the view. I can quite imagine i being on the middle-mouse button, determined by the direction your mouse will be looking from the base view-angle and its intensity. Doe, it need to be seen, how it feels this way.
... i also thinking, holding it a little whyle for the mode to come up might be better. Would not let ya get into it by mistake. (1 - 1.5 sec ?) But im not sure, it anyone had to need to get into it speedy in some situations ... maybe giving an option to people, to have it on click, or a time-holding base in OTs options ?
... clicable stuff in aircraft would also need some way of showing an info about the thing you have the cursor abowe (180+ elements for some cockpits, so its handy to have an hint system like this), would be great if a possible text message would be bound to each clicable element when ya define/action-bind them in script. Usable even if an action would not be assigned to it (when ya want to see a description of some gauges - they would be defined as same objects as buttons, but no action would be assigned at usage, but the text would show up when going abowe it whyte the cursor).
-
It may be useful to add the possibility for the player to move the camera position on y and x axis while pressing the middle mouse button and moving the mouse when inside a vehicle. Some elements may be difficult to reach or hidden in some specific vehicles.
Normally mouse x,y axis is for turning and pitching, respectively, but maybe in that mode it could include leaning?
Ok, didn't realized mouse could be used as a pitch/roll control option too :)
Lets talk first about getting into the mode where you actually have a mouse cursor and can click on cockpit. In discussion with ddenn we talked about using RMB-hold or RMB-toggle to show the cursor, and mouse wheel for zoom.
I would recommend something a bit different, but I'm not sure if it's easy to do.
The idea would be to have hybrid view/control modes. No matter what mode (pitch and roll or clickable cockpit) you are using, LMB-hold will allow you to move the camera freely. Switching from aircraft control to clickable cockpit mode should be set on a toogle key (space being the most obvious one). You can still move the camera in this mode to look around by holding LMB, and interact with elements using RMB.
LMB hold+Mouse wheel could allow zoom in/ zoom out. Wheel only in control mode can be used for throttle up/down. In clickable cockpit mode it will allow to control some systems while keeping the cursor on these (throttle/prop/mixture/trim/...).
It seems a bit more complex but at the end the user only have to know only two things: LMB-hold allow free view (could be toogle or hold in fact) and space make you switch from control mode to cockpit mode. I think this kind of scheme is also fitted for any vehicule type. But I'm not sure if it's clear or even possible to do with the new control system, other users opinion could be a good thing :)
-
LMB-hold + wheel feels pretty awkward to me. I can do RMB-hold + wheel better, but even that is not very pleasant.
RMB-hold is used elsewhere for turning (TPS modes), so I'd like to use that instead of LMB for consistency if possible. What about:
- clickable cockpit mode (toggle with Space) - shows cursor, LMB click/drag to adjust cockpit controls, RMB-hold to control the view (hides the cursor)
wheel for zoom
- view mode - free camera, RMB-hold shows the cursor, doesn't move camera, and with LMB you can click/move the cockpit controls
RMB-hold + other mouse controls is still clumsy, but in view mode it would be just for some quick actions.
-
... clicable stuff in aircraft would also need some way of showing an info about the thing you have the cursor abowe (180+ elements for some cockpits, so its handy to have an hint system like this), would be great if a possible text message would be bound to each clicable element when ya define/action-bind them in script. Usable even if an action would not be assigned to it (when ya want to see a description of some gauges - they would be defined as same objects as buttons, but no action would be assigned at usage, but the text would show up when going abowe it with the cursor).
Exactly! I was thinking on the same thing. That would be very useful indeed. Also an option to turn off the hints wouldn't be bad, maybe there are people that don't like them...
Will be possible to have the clickable elements even outside the cockpit, for example to open doors, remove the remove before flight ribbons and so on?
RMB-hold is used elsewhere for turning (TPS modes), so I'd like to use that instead of LMB for consistency if possible. What about:
- clickable cockpit mode (toggle with Space) - shows cursor, LMB click/drag to adjust cockpit controls, RMB-hold to control the view (hides the cursor)
wheel for zoom
- view mode - free camera, RMB-hold shows the cursor, doesn't move camera, and with LMB you can click/move the cockpit controls
Sounds pretty good for me, but I'm thinking on something more similar to FSX. While Space bar is being pressed, you can freely move the camera, if not, then you can click on the cockpit elements. That simple.
-
LMB-hold + wheel feels pretty awkward to me. I can do RMB-hold + wheel better, but even that is not very pleasant.
Yeah, just realized I inverted LMB and RMB in my post :facepalm:
RMB-hold is used elsewhere for turning (TPS modes), so I'd like to use that instead of LMB for consistency if possible. What about:
- clickable cockpit mode (toggle with Space) - shows cursor, LMB click/drag to adjust cockpit controls, RMB-hold to control the view (hides the cursor)
wheel for zoom
- view mode - free camera, RMB-hold shows the cursor, doesn't move camera, and with LMB you can click/move the cockpit controls
RMB-hold + other mouse controls is still clumsy, but in view mode it would be just for some quick actions.
Seems perfect!
-
Also an option to turn off the hints wouldn't be bad, maybe there are people that don't like them...
Yes, not a bad idea.
-
Will be possible to have the clickable elements even outside the cockpit, for example to open doors, remove the remove before flight ribbons and so on?
Yes that would be good too. Stuff that can be open from outside, optionally highlighted.
RMB-hold is used elsewhere for turning (TPS modes), so I'd like to use that instead of LMB for consistency if possible. What about:
- clickable cockpit mode (toggle with Space) - shows cursor, LMB click/drag to adjust cockpit controls, RMB-hold to control the view (hides the cursor)
wheel for zoom
- view mode - free camera, RMB-hold shows the cursor, doesn't move camera, and with LMB you can click/move the cockpit controls
Sounds pretty good for me, but I'm thinking on something more similar to FSX. While Space bar is being pressed, you can freely move the camera, if not, then you can click on the cockpit elements. That simple.
We'll probably end up with two basic modes - default interactive or default freecam, and whether Space toggles or needs to be held.
-
Yes that would be good too. Stuff that can be open from outside, optionally highlighted.
Yes that would be good too. Stuff that can be open from outside, optionally highlighted.
We'll probably end up with two basic modes - default interactive or default freecam, and whether Space toggles or needs to be held.
That would be just perfect, thank you!
-
Check out the way flightgear handles it..... Don't reinvent the wheel.
-
Yes that would be good too. Stuff that can be open from outside, optionally highlighted.
Id liked that a lot, specially for some external doors n dorlets on trucks, doe, how would be that handled outside the vehicle ? I kinda like that oppening door now, but you had to say the vehicle, witch door/object you want to use. Not sure if ya would let that clickable-mode outside the vehicles, or just let it be extended atleast to characters - (no need to switch to that mode to see a cursor, but at least let the stuff be clicked in the center of the view). ... some protection cowers for aircraft intlets-outlets, gas, hydraulics n electro-agregat cowers. (point is, once some of my airfield vehicles are done, id like to be able to connect the cables and tubes to it, potentionally re-fueling, charging batteryes, adding pressure to the hydro-systems - that would push sims to a next level on ground).
-
It could pick the closest door/hood or whatever thing registered on the model as openable, within a reachable range, and send it to vehicle as AOpen request with the id. The registration of openable items could be providing a mesh name, so that the same mesh can be also highlighted as the one that will/can be opened.
-
It could pick the closest door/hood or whatever thing registered on the model as openable, within a reachable range, and send it to vehicle as AOpen request with the id. The registration of openable items could be providing a mesh name, so that the same mesh can be also highlighted as the one that will/can be opened.
That would be great Cameni !
-
I like how EZDOC camera for FSX does it. Hold middle mouse down to look around, scroll to turn knobs, click to press switches.