HUD showing teammates alive.

[wrtlprnft]

I'm gonna care about the colors tomorrow. I've got a new count that increases the number of new settings to 42 (i honestly didn't aim for this number):

1. Background r/g/b/alpha
2. Bar alpha
3. Color of bar at min r/g/b
4. Color of bar at (min+max)/2 r/g/b
5. Color of bar at max r/g/b

And all this times three for the three gauges.

Can you add the Reverse settings to the config, too? It might be disputeable if you want a "rubber used" or a "rubber available", so why not offer both?

Nice screenshot. Can't you just make a screenshot without caring about a nice perspective and that someone explodes? Makes mine look so bad just kidding.

[Lucifer]

Heh.

Ummm, you know, I'm all for freedom of choice. I'd like to exercise my freedom of choice by choosing not to type in 48 new config items, translation strings, and accompanying wiki documentation.

Let's do something else. First, I think that rubber remaining is better than rubber used, and a lot of people in-gme have told me so. So let's make the rubber gauge show that way. Second, I think the brake gauge should shape itself according to the server. If brakes are disable, show no gauge. If brakes are enabled as a brake, show it like it is. If brakes are enabled as an accelerator, show it as brake used rather than brake remaining.

And if people don't like it, well, as you can see, we take patches. I've set the default in cvs head to show bars instead of lines. A lesson I've learned is that people won't use new config options if the default is to show the old way. They might like the new way, but they won't try it and see, typically. So I set the default to the new way because I like it better, and people can change it back if they'd like.

Down the road, I'm thinking of a cockpit as an xml resource file that contains all of these 48 config items and more. Are you interested in working on that, or would you prefer to say "thanks, this is cool, I'm done"?

[wrtlprnft]

I can understand that, fully. The server bookmarks list and the instant chat keys definitely show the limits of the config system.

Yes, I am interested in the XML thing. I'll try to see how the implementation for the map XML stuff works and how to use libxml... Heck, I never did anything that big with c++

If we're using XML I would say we should make it as extensible as possible, like allowing any number of points for the color gradients.

Hmm, changing the HUD with the moviepack... sweet.


EDIT:
What would you like to start with? Start the coding and care about the exact format later (you definitely would have to start since I have no idea where I should begin. Basic things like finding the file and open it as an xmlDoc... I don't even know where I should put code that loads the file at the right time) or start with writing a DTD and an example file of how it could look like?

[Phytotron]

Jonathan, I apologize sincerely for not being, to your liking, technically specific or correct, and for generally being a retard. I also apologize on behalf of all others who might do the same.

[Lucifer]

I'm not sure where to put code that loads it at the right time.

Here's what I'm thinking, until we get their with the gui, which is quite a ways away.

The hud is already a rPerFrameTask, you'll find that down under all the hud code.

So do something like the eSoundMixer. I forget what pattern zman says it is, but it's basically a static method GetMixer() that returns the current mixer. If there isn't one, it creates it. If there is, it just returns it. I can probably throw that together. This would be in a class formally called gHud. We use a global function that is registered as a per frame task that makes this particular call and then called gHud::Render(). Simple, right?

So then in gHud's constructor, check a single config item that gives a path to the cockpit xml file. Check a member variable to see if it's loaded. If not, load it. So on the first run, in the very first frame, the cockpit xml file will be loaded. We might destroy it when the player leaves the game as well, that's no biggee. Definitely destroy in the destructor. I'll throw this stuff together tonight, in a little bit. The hud as it is now should be factored into this gHud class.

So then we need to look at gParser. If there isn't already a base class that we can derive so we don't have to get dirty with libxml, then we go over to irc or something and bitch at Luke-Jr/philippe. Then you decide, do you want to make that base class and follow the model in gParser, or just copy gParser and make it parse a different file, bitching all the way that there isn't class available to inherit that does most of this already.

Simple, right? I would suggest thinking about what the xml should look like, and then we can beat on it when we've actually got enough code to worry about it.

[Tank Program]

Looks cool, but the background color is kind of hard to see.

But, I see you're already working on that.

[Lucifer]

Ok, just committed a pretty serious factoring of gHud. The subby_ and tank_ functions are gone (well, commented). They've been factored into class gHud, which has member functions to do its work. Some code got consolidated, other code got split up.

Here's what's lost:
Speed gauge doesn't rescale
Needle gauges weren't checked at all
Possibly some of the new config items we just made are disabled, I forget

Anyway, I'll give it another look when my brain isn't mush and see that I got everything.

Still left to do:
Factor the clock into its own method
Factor the map into the hud. Currently it's an independent per frame task that happens to be in gHud, should be integrated with gHud.

So if you want to bang on xml resource files describing the hud, as soon as the anonymous servers update, have at it. Like I said, you should be safe to put the xml reading in the constructor of gHud. You should probably make a gCockpitParser class or something, you know, in new header and cpp files. I glanced over gParser and it's definitely not generic, but you might be able to get away with copying it and then modifying it to suit us for a cockpit resource description. When you have that, I'll get rid of *all* of the stupid hud configs in favor of a single one to give a path to a cockpit xml file. (Well, maybe not all of them, but you know what I mean anyway )

Edit: And for once I checked that the dedicated server compiles.

[wrtlprnft]

Still not updated...

Well, I attached something that could be a cockpit file. I think that should give a lot of freedom in creating the cockpit files.

Is there any way to get those files without waiting forever?

Edit: actually i didnt attach anything... Well, I did now.

[wrtlprnft]

For the font centering: I figured it out now, but I needed to add another function to rFont.h. I attached both my changed files.

Here's a Screenshot of what it looks like now. Notice that the current values and the captions are perfectly aligned to the bars now

Once I get my hands on the refactored version of gHud.cpp, I'll put my changes in that, too.

[philippeqc]

Most excellent!

To answer your hidden question: no.

For everybody else, and you if you forgotten it:

Code: Select all

<?xml version="1.0" encoding="ISO-8859-1" stamdalone="no"?>
<!DOCTYPE Resource SYSTEM "cockpit-0.2.8.dtd">

<Resource type="aacockpit" name="example file" version="0.0.1" author="me" category="do we need this?">

category="" is valid.

Did you plan to have a colored background behind the needle too?

Otherwise, I think you are really on a good track there. Keep the good work.

-ph

[gnorty]

Love the idea for teammates alive, but how about showing the tallies in their team colours for instant recognition?

I realise this may not be trivial, so what about red/green for enemie/friends as an alternative?

[wrtlprnft]

It's gonna go into the language files, so everyone can change it if he likes
Team colors are a problem, what color would the "Enemies:" be if you had 4 teams?

Wow, someone actually found this question
Does the category thing get used for anything inside armagetron?

[philippeqc]

Wow, someone actually found this question :)
Does the category thing get used for anything inside armagetron?

It is used to determine where the file should be saved. The location is
author/category/name-version.extention.xml

It ensure that what ever the method for you to get a file, you still can know where it need to be saved.

[wrtlprnft]

I don't know, I think ít would be an idea to have an own class gHudObject that can hold any kind of HUD display, like gauges, maps or just simple text fields... Then gHud would just manage pointers to those classes...

[Lucifer]

Does this mean you were able to update to the newest stuff?

Yes, I agree with the gHudObject thing. Later on, when there's been some GUI factoring done, we'll work gHudObject into the GUI system in a way that'll allow us to put gui objects on the hud as well, like a media player . I didn't do it yet because the hud code was so convoluted, and I was focused on getting it into a class where an xml parser could be plugged easily. So, yeah, those RenderFaster and RenderBlah functions should be pulled out further and stuck into classes of their own with a reasonable inheritance structure.

I was also thinking about making a gStatistics class that will ultimately intercept game events to collect statistics, and then gHud would connect its widgets to gStatistics, theoretically speeding up the hud a little bit, but practically collecting all the statistical information into one place.

Anyway, I"ll look at your xml file right now, this bump is to tell you I'm awake again and if you haven't been able to update, I can post the files here.