Rezzing progress bars

[zerver]

I assume there are multiple widgets that do this already, but shouldn't it also be built into the engine? Sometimes it is essential to know whether a corpse can be rezzed in reasonable time. I can add it, just want to hear what u think...

[hoijui]

fine for me
but i am sure that it has to be configurable, through mod-config or settings or all together, as otherwise ppl will not be happy :D
for me it would be ok, no matter how configurable.

[Beherith]

Ok, I know this sounds stupid, but could someone link me to a version of healthbars that:

Doesnt display 100% health
Displays reclaim and rezz

[manolo_]

hi,

i use the healthbar of xta (took from the archive)

[zerver]

Yeah, my plan was to include reclaim info in the bar as well. Initially there will be no bars, but if you start reclaiming or rezzing, the bar appears. And it will be optional of course.

[manolo_]

i think the xta-version supports that, ask the dev of ur fav mod to include it as gadget or use it as widget, dunno why this should be implemented into engine

[jK]

Why do you want everything in the engine?
There is the widget, it works fine, it's pretty fast after multiple optimizations and then it's even included with nearly all mods.

[BrainDamage]

can't the widget be bundled with spring?

[zerver]

Why do you want everything in the engine?
There is the widget, it works fine, it's pretty fast after multiple optimizations and then it's even included with nearly all mods.

If it is something that most users want to have, it should be in the engine imo. Lua may be fast, but not as fast as the engine.

[Argh]

What about all of us who are building games where we don't need that feature, and don't want to spend the CPU cycles on a feature we don't need and don't want, built for a game we don't play?

This is what Widgets are for, basically. Things concerning UI should all be Widgets, imo. The engine does not need to do lots of built-in drawing tasks any more, and (imo, at least) should slowly get out of the drawing business entirely (there are other ways to provide that speed, such as library support, for things where C++ performance is utterly crucial).

If speed's an issue, then the place to look is the Lua --> OpenGL interface, because a well-designed Widget is not touching the CPU a great deal anyhow.

But jK's Healthbars Widget (or, for that matter, mine) is pretty much zero load. So, you're asking everybody working on every game to support extra display steps and more loop cycles on something that not all of us want, simply because a of a speed issue that doesn't exist in the first place.

I do apologize, if it seems like I'm being a troll, but you've gotta understand the issue here. I don't want the engine to waste cycles on stuff that isn't universally useful. I think that the engine's better that way than it's ever been, and that that is a trend that should continue to be pushed.

[zerver]

It's good to hear different opinions, Your reasoning makes me think we should remove the health bars from the engine.

[Argh]

I would support that, and removing the Console, resource bars, ground display rings (heck, even stuff like metalmap display, although frankly I see no need) etc., frankly.

Practically all of that can be drawn with Lua, no exotic / crash-prone code or fancy OpenGL is required.

[CarRepairer]

I can make all the healthbars in the world in lua but I can't patch the engine. I'd rather see spring devs work on stuff I can't do instead of the very same stuff I'm already working on. Seems to be a complete waste.