HUD showing teammates alive.

[joda.bot]

just a side note, I'm not sure if the tArray stuff will be converted to <std> C++ library, but you might also use the <std> libraries and benefit from whatever the C++ standard agreed on ...

I'm already using some of the <std> vector for team balancing ... ok, I really finish this.

[Lucifer]

I think we're planning on getting rid of tArray and tString and stuff in favor of stl. If not, then maybe I should consider rewriting to use tArray instead. Except that we'll still need tString and tColored string, just inherit std::string to get what good stuff it has.

[wrtlprnft]

I attached my edited files, nothing is really ready yet...

My biggest problem is getting the data for the HUD.... I have no idea how to do that... you don't like callbacks and I don't want gHud to care about pumping the data into gHudWidget (and manage the kind of data it needs etc...).

Oh, and your current implementation doesn't seem to handle spectator mode very well...

[Z-Man]

I think it looks cool. Good work!

Oh, tank did not get around to do this, but maybe you can: The static function gCycle::MaximalSpeed() can give you the theoretical top speed of a cycle, the one you get when you're permanently between two walls and use the eventual booster to go even higher. It's not perfectly accurate yet, but that can change. Maybe you can use it for the speed meter scale?

[wrtlprnft]

That looks cool, I'm gonna take this function I only have to get some intelligent rounding algorythm... 148.something doesn't look good as maximum.

[Z-Man]

Try ceil(x/10)*10. You'll probably want to replace the 10 by the largest power of ten that is smaller than MaxSpeed*SomeFactor to cater for really fast and slow servers. SomeFactor should be in the range of .1 to .2, I guess.

Oh, and the only server where MaximalSpeed() was way out of the really reachable range was your race server No walls to take acceleration from, and you're dead (or, in unusual cases, you've won) long before you reach the theoretical maximum turbo speed.

[Lucifer]

MIght consider the server suggesting reasonable ranges for special cases.

[wrtlprnft]

The maximum there is 580, which is almost reached if you keep your brakes pressed after you win and stay near the rim (it accellerates a bit)... So it isn't way off.

[Z-Man]

I see, I never make it that far against the AI, they suicide before I'm half finished
Nevertheless, I think Lucifer's idea has some merit. Add a nSettingItem for the top displayed speed, let it default to zero, and ignore it if it's zero.

[Lucifer]

FIrst look at dtd and resource file for cockpits. COmments welcome and desired.

Currently working with the dtd in the resource/proto directory. Is that the appropriate place? How are we going to organize cockpit resources into the resource system?

[Lucifer]

Real progress. I just commited wrtl's latest, with some tweaks.

@wrtl: make sure you do some cvs updating before you start again. After doing the CXXFLAGS thing zman asked for, I found a number of things that had to be corrected.

DTD for cockpits and the standard cockpit are committed, however, the standard cockpit doesn't actually contain the entire hud that we have. Since it isn't loaded, no problem right now. But it is there for all to see. It's in "used it to write the DTD" shape right now.

For all, tXmlParser is ready to be used in the map parser. It will validate and load a map into the DOM type, which is what gParser does. A few changes will need to be maded to gParser to support it, I don't know the extent of the impact of those changes, so I didn't make them. If philippe can dream up a way to reduce even that without breaking the interface of tXmlParser, fine. Otherwise, it's ready. The SAX interface it provides is thoroughly untested! THe model for use that wrtl's laying down, um, I'm not entirely sure is correct, but I don't think it's blatantly wrong either (nad it was one of my suggestions, so I'll take responsibility for it if it turns out to be wrong). ANyway, gHud inherits it, rather than creating another class and instantiating it within gHud.

So, tXmlParser will do the minimum required of a base class for the map parser, but the interface might need some tweaking. I feel like it's a good interface, but y'all check it out. It should simplify making new resources a bit, but for the DOM mode, not significant. If you use it in the untested SAX mode, then it gives you native armagetron/std data structures instead of libxml2 data structures. I suspect we'll use SAX for the cockpit, that seems like the right parser to use there.

That's it. gHud doesn't actually use the map it loads into memory yet, wrtl went to bed before that happened.

[Sniperiid]

Wrtlprnft, would be nice at brake to put reverse colors. When you have only lil brake, color it red, if you have much, put green. You do exactly reverse... But only at brake...

[2020]

a little detail:
you know how on some servers
pressing the brake key makes the bike accelerate....

sounds a little pernicket
perhaps we should apply a different name to it
in the same way rubber refers to something to do with closeness to a wall

not sure what might be an alternative
that applies to accelerate and decelerate
however
when thinking back to the film
the guys start holding a rod
and then the bike builds around this

so
how about:
rod

rod and rubber
sounds kind of...

[Z-Man]

I'd rather rename rubber to something more intelligible