ph01_cockpit

Halleck · Post by **Halleck** » Sat Jan 21, 2006 1:13 pm

No, it's "jump".

Sigh... these one-letter buttons are still quite confusing.

pheldens · Post by **pheldens** » Sat Jan 21, 2006 1:43 pm

That's why they are also coloured, the letters in fact are only supplemental. It will feel better once you fly a bit with it, you can link button toggles and game events to changes in the HUD.

Turret AI?

I don't know if there even are cockpit button functions for toggles like, "`" Shelton and "o" turret ai? If I had seen them, I'd certainly put them in.

Post by **chuck_starchaser** » Sat Jan 21, 2006 3:16 pm

Yeah, I agree about one-letter things; "Jump" and "Jam" would be better. Also, indicators that've been sorely missing are: for 'Y' key, wheher your speed is currently capped to governor setting or uncapped; time compression; turret mode; and active weapons.
Another old problem is a lack of distinction between messages you send out and messages coming in for you. I think they are color coded but I never seemed to get which way around the color coding worked, and if I ever figured it out, I forgot it afterwards.
And I never figured out whether ALL of the messages are for me or whether some of them are chatter picked up between others.
One more thing: Radar screens: I've always thought that of all things, radar screens should be opaque, since you don't want to see background stars getting mixed with the intentionally displayed dots. I also thought that text should be on opaque background. whereas things like fuel gauges and stuff, currently on opaque backgrounds, wouldnt be hurt by transparency.

Halleck · Post by **Halleck** » Sun Jan 22, 2006 3:44 am

Time compression: NO. TC is a debugging feature, not a gameplay feature.

Speed cap: agreed, but I think it would require changes to the cockpit code.

Guns: this is covered, you can tab through guns/cargo manifest with the m key.

Accu-Accelerated · Post by **Accu-Accelerated** » Sun Jan 22, 2006 6:14 am

chuck_starchaser wrote:One more thing: Radar screens: I've always thought that of all things, radar screens should be opaque, since you don't want to see background stars getting mixed with the intentionally displayed dots.

Another solution would be to make the dots bigger, and make them round dots like on a real radar screen, and perhaps color them gray instead of white. You could even make the circles pulsate very subtly to mimic a real radar effect.

To clear up confusion on what the lights mean, you could press [tab] or some other key to make a help screen that tells you what the lights and numbers mean as well as some basic controls pop up.

Post by **chuck_starchaser** » Sun Jan 22, 2006 7:57 am

Yeah, but why look for sophisticated solutions when the simplest one is obvious. Of all things on the HUD, the very last one one would want alpha blended is the radar.

Accu-Accelerated · Post by **Accu-Accelerated** » Sun Jan 22, 2006 8:29 am

Yes, the simplest solution would be to make the radar opaque. But if it can be implemented, larger, rounded dots would be really nice and it would make it easier to see, even if the radar is already opaque.

Post by **chuck_starchaser** » Sun Jan 22, 2006 9:12 am

That I agree.

pheldens · Post by **pheldens** » Sun Jan 22, 2006 5:37 pm

The original was 100% transparent, this one is 70 or so.
And besides, it's a projected HUD, not a a shaped sheet of metal as in the 3d views.

Post by **chuck_starchaser** » Sun Jan 22, 2006 11:40 pm

Well, I wasn't saying that IS something that it isn't; just saying that it should be something that it isn't. I can see with my own eyes that it is semi-transparent, projected. What I'm saying is that the radar should be a special display device, NOT part of the projected HUD.

Post by **zaydana** » Mon Jan 23, 2006 2:39 am

You know, in this instace I think to change the transperancy of only the HUD would sorta screw up the whole look that pheldens was going for. So... I have to pull out the old open source line for all those who complain: wheres the patch? :-p

Everybody is going to want something different, but i'm pretty happy just to have the new HUD at all, specially something as good as this one. And I think a lot of other people are pretty happy with it as it is, anyhow.

Halleck · Post by **Halleck** » Mon Jan 23, 2006 3:17 am

Ditto.

I'm not too fazed by the transparency. The only thing that bugs me are the one-letter abbreviations, which raise the learning curve of the game interface a little.

pheldens · Post by **pheldens** » Thu Nov 02, 2006 7:14 pm

hey, just checked out svn again after some months, cool you merged it

I'll see if I can finetune it some more, there seem to be some alignment and aspect problems.

pheldens · Post by **pheldens** » Thu Nov 16, 2006 4:24 pm

Tweaked data4.x/cockpits/disabled-cockpit.cpt/panel.spr so pulsing lights and radars are aligned better.

Code: Select all

cockpits/disabled/panel.png cockpits/disabled/panel.png
1.33 0.44666
0 -.7766

Post by **jackS** » Fri Nov 17, 2006 4:02 am

thank's for reminding me - I'll take care of that this evening.

edit: Ok, I've checked in a modified version of that cockpit. Should be centered, etc. now.

pheldens · Post by **pheldens** » Fri Nov 17, 2006 1:25 pm

One more question I asked elsewhere too, what's the function of the LOCK indicator? Is it being locked by someone, or having a lock on an object yourself?

Based on the function I will redesign the present Lock indicator .

pheldens · Post by **pheldens** » Fri Nov 17, 2006 6:07 pm

OK synced. why did you change other values? this is getting frustrating. Also your chnage added dos style (^M) end of lines to the files.

Here are some screenshots:

NOTE:

- Lower right VDU has oversized width. It enters screen at the opposite side.
- Double targets selected? After wormhole jumps ( there are 2 triangle steering indicators )
- The panel is raised from the screen baseline.
- there's a broken ship model with straight white textures and wrong placed engine flares in one of the shots. got an idea what's wrong with that one? it's the only model that has this problem.

Post by **jackS** » Fri Nov 17, 2006 6:50 pm

I moved the crosshair because it wasn't centered, and altered the lock-acquired indicator because it was unreadable. I tried out your posted numbers for just the panel, but the radar displays didn't perfectly align and there was a visible gap between the bottom of the panel and the bottom of the screen, so I nudged it slightly until the radars aligned and there was no gap - perhaps I should have nudged the radar displays instead, but I had assumed them to be correctly located. The cockpit specification had to be changed (order of VDU specification) because only the first two VDUs are set up to respond to keystrokes (both the m and v will work now to switch displays).

The change in scaling for the two VDUs is something I can readily revert/alter. The 50% scaling looked a lot more crisp than the 35% scaling, especially the text. I'll experiment and see if 33.333% is any cleaner than 35%.

I don't experience the wrap-around on the VDUs seen in your screenshots. This is very interesting. What mode (full/windowed), resolution, and aspect ratio are you running at? This could also help explain why we perhaps reached different conclusions as to whether things were actually centered.
I performed my testing last night at 1024x768 windowed (aspect ratio: 1.33)

As for changes to new-lines, this surprises me - I've gone and done whitespace aware diffs on the files I touched, and they all imply that the DOS style ^M^J newlines were present in the versions checked into SVN in March. Unless SVN is playing games with my newlines behind my back, I don't think EMACS went out of its way to rewrite the newlines.

From the engine placement, the untextured ship is clearly a Sartre (the broken engine placement has already been reported as a bug). I haven't ever seen one go about untextured before. Most peculiar. If you ever see such an occurrence again, please target it and find out the faction.

Post by **jackS** » Fri Nov 17, 2006 6:58 pm

pheldens wrote:One more question I asked elsewhere too, what's the function of the LOCK indicator? Is it being locked by someone, or having a lock on an object yourself?

Based on the function I will redesign the present Lock indicator .

Last I checked, the two locks, missile-lock and lock, are for external locks, i.e. enemy missiles locked on, or active hostile targeting (being fired at). The name does leave something to be desired :-/. There are existing graphical indicators for whether a target has been locked by you or that your missiles have acquired lock on a target, neither of which are controlled by the cockpit specification.

pheldens · Post by **pheldens** » Fri Nov 17, 2006 8:09 pm

ok thanks for your answers.

I use a 4:3 CRT screen at 1024*768. (with 4:3 viewable area, with 4:3 screen pixels, 75x75 dpi)
Make sure you're not using some weird 5:4 TFT with odd pixel ratio correction. Like many 17" 1280x1024 tfts. (measure it by hand or check the tft's manual)
Crispness is the same on any scale, as long as you keep the right aspect. (which you also adjusted)
Do you guys clean up ~/.vegastrike/* caches after svn upgrading?

I will check out the white ship in further detail.

Thanks for clearing up the lock behaviour, I dont mind this is its internal name, I'll try to cook up some better indicator (one without the confusing LOCK text in the cockpit. Was thinking of colouring the reticle for this. Since it's tactical info.

pheldens · Post by **pheldens** » Fri Nov 17, 2006 8:23 pm

hmm think I confused my svn tree, by editting files in it myself, doing a fresh checkout now. so ignore those scale issues.

pheldens · Post by **pheldens** » Fri Nov 17, 2006 10:10 pm

neh, after a fresh checkout from scratch. ship problem is with sartre's, vdu problem remains, basline shift seems fixed.

Post by **loki1950** » Fri Nov 17, 2006 11:53 pm

just sucked in the update the distance to target in the right VDU is not there so you can't tell if that pirate you targeted is a threat or not

till he starts shooting.

Enjoy the Choice

Post by **jackS** » Sat Nov 18, 2006 7:33 am

Interesting. Changing between fullscreen and windowed, or moving to any of the other resolutions causes the cockpit changes to be undesirable. I'll see if I can find something that works with all settings - something engineside must have some underlying sub-optimal handling of something, but I'm not set up with time to go hunting for that right now.

Post by **jackS** » Sat Nov 18, 2006 7:50 am

I've tested some settings that appear to be more amenable to multiple modes/resolutions. Please try these out and let me know if they work for you.