3D cockpits

[robn]

So on the way home today I'm planning to start on new-UI-fying the WorldView. It'll be quick to get started but there's going to be a lot of work to get something useful going, mostly in the input system. I don't know how long its going to take, it needs a fair bit of experimenting first. But it really is the first step in all of this.

[FluffyFreak]

Awesome, progress in leaps AND bounds :D

[nozmajner]

Great :)

Yeah, that Rouge Sys level of detail is too much in my opinion too. Even if nobody wants to take a walk after seeing it. :D
Disembodiment isn't seems to be not much problem, I agree to leave it out. Modders can model one if they want.

I'll start drawing elements, buttons and stuff, prefabs then, and I'll start building the library, and documenting the work-flow parallel, so modders and creators will have it on their hands as soon as possible. (Would make for a good dev-diary entry too ;) )

I already have those screens build on array, so I can make them any size and number of buttons, but I think it needs some thought to be more dynamic.

What do you think? Should I remove the little screens from the cockpit until they are working, or keep them there with a texture for display like how it is right now?
I could also fill them with flashy but flight-unrelated data, like reactor output% and such, so it doesn't give the impression of displaying actual data.

[robn]

I'll start drawing elements, buttons and stuff, prefabs then

Do you mean just random non-working bits of the cockpit, or are you talking about the working instruments? If its the instruments, I need to know a lot about them because it will affect the implementation.

(We might need to settle on some common terminology. I'm guilty of mixing things too).

What do you think? Should I remove the little screens from the cockpit until they are working, or keep them there with a texture for display like how it is right now?

Its only worth making a nice non-working version if we're intending to ship it in a build. Which perhaps we should if we're looking for feedback. But otherwise suit yourself :)

[nozmajner]

Do you mean just random non-working bits of the cockpit, or are you talking about the working instruments? If its the instruments, I need to know a lot about them because it will affect the implementation.

Both working and non-working. Like that air-conditioner nozzle, handgrabs, switches, buttons screen models and things like that. First I want to come up with the general look of it, I already have a bunch of sketches I'm happy with. Then turning them into models.
No instrument screens right now, if that's what you mean by instruments. (yeah, let's come up with a terminology :) ) Or you are thinking about different instruments, like dials with rotating needle for example, which would require moving elements modeled? I imagined all instrument as a screen actually, even if some of them are circular. But on a second thought, switches should have at least 2 stages of animation for their states. (Edit addendum:) Or knobs with multiple stages, for flight mode right now for example (the word didn't wanted to come to my mind.) (/edit)
What things you need to know about them? I bet sizes are important for screens.

Some terminology: (proposed)

• Static elements: not manipulatable, and doesn't display any information. Only there for the looks. Like those handgrabs or AC nozzles.
• Dynamic elements: Manipulatable by the player. Switches, buttons.
• Display elements: They are displaying information. Might be dynamic also, like the contact list you mentioned earlier. Screens and touch-screens for example.

These are the first ones to come to my mind.

[robn]

I'm happy with that terminology. I'll clarify "display elements" as being projected UI widgets.

I hadn't even considered dynamic elements like switches and buttons to be honest. I'd assumed that the only non-static parts would be display elements.

Visually switches and knobs are quite easy to do - they're just animations. Input could be quite tricky if they're not just operated by clicks but rather by certain gestures (a drag or similar). We don't have any kind of support for that and I'm not quite sure how to start. I'll have to think about it.

[nozmajner]

I think we don't need full support for manipulating dynamic elements by gestures. I think it's sufficient if they just go (animate, and do that quicky) to the position their state dictates. For knobs with multiple states a left/right click input for increase and decrease of state is sufficient in my opinion.

[nozmajner]

I'd say we should use "projected elements" for the stuff that is projected to the face of the pilot, like reticules and target overlays, and use "display elements" for the stuff that are on actual screens on the dashboard.

[robn]

Ahh, that's the exact opposite of how I've been using it, because I was thinking of projecting flat widgets into the world space (ie putting them onto the cockpit). But that's exactly the opposite of how you implement it too, so I'm wrong all over the place.

So yes, what you said :)

[FluffyFreak]

Just a heads up about https://github.com/pioneerspacesim/pioneer/pull/2635, I got asked to change the copyright notice to attribute it to:

// Copyright © 2013-14 Meteoric Games Ltd
// Licensed under the terms of the GPL v3. See licenses/GPL-3.txt

Just wanted to head off any problems - basically I'm ok with re-attributing it because I'm probably going to rewrite it and use different files etc.

The reason for the rewrite is to make it work without all of the drawbacks like setting frames and requiring it to inherit from the modelbody etc.