[SUGGESTION] Old, good acc?

Not only I think that the new acc. isn't clear and easy to use. Thats why I suggest for developers to restore the previous version.
Its much more simplified and much more easy to use

The new one: (looks rly cool)



The old one (works rly cool)



Please, consider this and response.

For CTS at least, you only need the accelerometer bars (i.e. no absolute value) and a figure for your current speed (i.e. no bar).

The extra stuff in the new display just gets in the way and I found it quite awkward to use.

The old accelerometer was more useful for me than the current one.
It was easier to check speed and if acceleration is positive or negative.

The new one looks better but the old one did its job better.

We need a accelerometer which is as nice as the new one with functions/optic like the old one

For CTS at least, you only need the accelerometer bars (i.e. no absolute value) and a figure for your current speed (i.e. no bar).

I don't fully get your point. Especially for beginners.
I often wondered whether my accel was optimal on the first jump.
Some numerical value would help a lot.

We have a LOT of many more important things to work on at the moment, but quite clearly to you guys something needs done... For me personally, I understand this display just fine and it is just as useful for me.. but I can see the need to make it larger/more obvious for the players/users.

I have created a feature issue on the development tracker, seen here: http://dev.xonotic.org/issues/636

For CTS at least, you only need the accelerometer bars (i.e. no absolute value) and a figure for your current speed (i.e. no bar).

I don't fully get your point. Especially for beginners.
I often wondered whether my accel was optimal on the first jump.
Some numerical value would help a lot.

You can mostly tell if you're doing it right just by the size of the accelerometer bar. Besides, even if your starting jump isn't 100% perfect, that tiny bit of lost acceleration isn't going to affect your final time by a huge amount. Especially if it's a long map (where strafing at high speed, turning and speed maintenance are more important) or a weapon map.

I stretched the field a little and the feature I miss is that you cannot scale the acceleration bar without changing other components.

A cvar like

Code:

hud_panel_physics_acceleration_scale

would be nice

If this cvar is available you can create a bar similar the old one it seems.

You can mostly tell if you're doing it right just by the size of the accelerometer bar. Besides, even if your starting jump isn't 100% perfect, that tiny bit of lost acceleration isn't going to affect your final time by a huge amount. Especially if it's a long map (where strafing at high speed, turning and speed maintenance are more important) or a weapon map.

My tiny experience of CTS showed me that, in a lot of maps, if your first jump is not efficient, you will never reach the first platform (and btw, that is absolutly discouraging for newbies. But it's another discussion). Numerical values could objectivize how good is this first jump. And, more genrally, the question stands for all type of gamemodes.

You can mostly tell if you're doing it right just by the size of the accelerometer bar. Besides, even if your starting jump isn't 100% perfect, that tiny bit of lost acceleration isn't going to affect your final time by a huge amount. Especially if it's a long map (where strafing at high speed, turning and speed maintenance are more important) or a weapon map.

My tiny experience of CTS showed me that, in a lot of maps, if your first jump is not efficient, you will never reach the first platform (and btw, that is absolutly discouraging for newbies. But it's another discussion). Numerical values could objectivize how good is this first jump. And, more genrally, the question stands for all type of gamemodes.

This is because most maps are designed for people who already know how to strafe jump. Only very rarely will platforms be spaced so far apart that a near-perfect starting jump is needed (the map nastyrunn is about as difficult as it gets for strafing, or at least it's the hardest strafing map that I've played ). For the newbies, maybe there could be an easy tutorial map as part of the singleplayer campaign?

I don't see how it applies to other game modes, as default physics are pretty easy anyway - you don't really need the accelerometer for it.

"easy tutorial map as part of the singleplayer campaign" sounds very very very cool. Some easy race maps with XPM physics in the singleplayer mode would be just PERFECT! Great idea, PWTULN! This also should contains small tutorial (some infos) how to strafe (basics). (There is a race mode in campaign, so why it couldn't be XPM>?)
I know it's sth more specific and dificult, but anyway its still a game mode. Don't forget about this!

"You don't really need the accelerometer for other game modes" - Yes, thats right, mabye expect of "race" and "assault" modes. So if it's not that important and representative, why the developers couldn't change it into more similar one (Just the speed and acceleration, without the fastest speed and others)? :]

Is there a chance that physics panel will be changed?

the acceleration bar is always flickering and i wish it it scalable ...

I'd appreciate XPM race tutorials too, as EVERYTIME I connect to the XPM server I fail to finish the map currently played, often I don't get past the first two jumps and sometimes I can't even make the first one which is rather frustrating. And I consider myself at least not to be the slowest racer around.

Spectate good players, and watch the keys they press, that helps, really, believe me.

Not rly, Until we have real Xonotic Pro Mode Tutorial. It is already "Xonotic Movement Tutorial" so why there is no XPM Tutorial?

I know its the same as the CPM in Quake Defrag (or very similar) but developers should consider this in the multiplayer. Quake live has its own movement tutorial which is few simple maps that you have to pass through using different movement techniques.
What about doing the same thing in Xonotic>?

What you say?

Spectate good players, and watch the keys they press, that helps, really, believe me.

Sometimes there is noone like this you can spec. Thats the main problem. How can you learn things without source of the knowledge?

I'd appreciate XPM race tutorials too, as EVERYTIME I connect to the XPM server I fail to finish the map currently played, often I don't get past the first two jumps and sometimes I can't even make the first one which is rather frustrating. And I consider myself at least not to be the slowest racer around.

If you see me online I'll be happy to help you - I seem to be teaching a lot of newbies recently (well, on Nexuiz at least!)

To be honest, one to one lessons are far better than watching videos or even interactive tutorial maps. I once managed to get a guy backwards strafing on his first day, while it took me much longer to figure out what to do (because no one taught me in this way)

If you see me online I'll be happy to help you - I seem to be teaching a lot of newbies recently (well, on Nexuiz at least!)

I will come back to that. I, too, teach newbies on the pubs all the time (much more to do since 0.5 was released...). But this strafe thing I can't get to work right.

As the initial HUD developer (didn't code up that physics panel BTW), yes, even I want the old option back. It was just so simple and easy to read, very useful for strafejumping in XPM. If we can't incorporate near-identical functionality in the current physics panel, then I at least want a switch to toggle between the new stuff and the old accelerometer.

Please bug me about this issue if it's not done soon, then I'll do it myself
That however means a bunch of setting up on my side, haven't developed for Xonotic in a little while (busy)

Personally, I want the information from the current one stay there, but...

- the panel can sure be bigger, sort of like before
- the numbers for speed, topspeed and acceleration can be a LOT smaller

basically resulting in the old display + a few small digits

Here's a random idea that floated through my brain. I kinda dislike how you have to look at any sort of accell bar (old or new) and which makes you not see the map.. How about color tinting the whole display (kinda like the damage flash you get when hit)? E.g. tint the display towards the greener end when accelerating and tilt it towards more reddish tones when decelerating. Or maybe not the whole display, but have the effect gradually increase towards the edges of the screen.

NO! This will "make you not see the map" even more then "normal" acc bar.

I thought about 2 implementation ideas to improve the panel, both can coexist:
1. a cvar to show the acceleration bar with a non linear function like sqrt so that small acceleration values are amplified
2. a cvar to reduce available size for text (NOT for bars) both vertically (to comply with divverent's wishes) and horizontally (it'd make possible to split panel horizontally even when panel aspect ratio (x/y) is big).

I think both ideas can make everyone happy, what do you think?

Well even if we make the improvements to the new one, i would like the option of having the old one back, being able to have that stretch beyond the screen is quite awesome.

Old one was good, but this is fine too, just make it possible to switch between them, and everyone should be happy.

P.S. Sorry for being so stupid, but what does that "G" mean? G-force?

You can try my latest changes checking out my branch origin/terencehill/physics_panel_updates.
I didn't implement idea number 2 as that would have caused to stretch the speed progressbar too. I've added these cvars:

Code:

seta hud_panel_physics_acceleration_progressbar_scale 0 "multiply acceleration progressbar values by this factor (allow progressbar to go out of panel bounds)";
seta hud_panel_physics_acceleration_progressbar_nonlinear 1 "use a non linear function to display acceleration progressbar values (amplify more smaller values)";
seta hud_panel_physics_text_scale 0.7 "scale text height by this factor";

Default settings in my branch:

Code:

hud_panel_physics_acceleration_progressbar_nonlinear 1
hud_panel_physics_acceleration_progressbar_scale 0

Settings for the old mode:

Code:

hud_panel_physics_acceleration_progressbar_nonlinear 0
hud_panel_physics_acceleration_progressbar_scale 2.2

(Just to clarify any scale value < 1 is considered as 1, maybe I'll change this behaviour though)

As you can see, my default settings are to not make the progressbar go out of panel bounds (as it's a hack). Interested people please try both modes for a while (not for just one minute!) and provvide feedback.



@Mepper:
Quoting Wikipedia @ http://en.wikipedia.org/wiki/Gravity:

The strength of the gravitational field is numerically equal to the acceleration of objects under its influence, and its value at the Earth's surface, denoted g, is approximately expressed below as the standard average.

g = 9.81 m/s2 = 32.2 ft/s2

Thank you for this new cvars!

This scaling feature is exactly what i wanted
and i like that you can use the nonlinear function to increase the bar size for smaller acceleration values...

I am using the following settings:

Code:

hud_panel_physics_acceleration_progressbar_nonlinear 1
hud_panel_physics_acceleration_progressbar_scale 4
hud_panel_physics_text_scale 0.85