Spring RTS Engine

There is no way to draw a custom aiming hud. More specifically, while it IS possible to do it by Lua, it's NOT possible to disable the default one, which seems hardwired.

The request would be that either a gui command would be added to stop rendering the default aiming sights (i.e., the circles and lines that specify where each gun is pointing) in a similar way the mouse cross can be disabled currently, or -

A Lua "DrawHUD" call-in would be added that would be called when the sights are to be rendered. The callin would preferably be passed arguments for each of the unit's guns, and would return a boolean value specifying whether the default aiming sights should be rendered or not.

would be nice if you could see your current unit's model when in FPS mode, and configure the camera position relative to the model. could even make it possible to have an internal cockpit model that becomes visible when inside it.

We don't really need another callin.

thesleepless wrote:would be nice if you could see your current unit's model when in FPS mode, and configure the camera position relative to the model. could even make it possible to have an internal cockpit model that becomes visible when inside it.

afair the camera uses the piece named in AimFromWeapon1 as the point it sits at.

you could probably model a cockpit to sit around the camera point. but i refuse to be held responsible for the results.

We don't really need another callin.

All the pretty stuff (including drawing the cockpit, model, sprite or whatnot else) can already be drawn with lua, so we don't actually need teh callin, yes (it could be nice, though).

The thing is that there's no way to get rid of the unpretty default stuff, and that's why i wrote "a way to disable default sights" before "or we could get a callin".

Anarchid wrote:

We don't really need another callin.

All the pretty stuff (including drawing the cockpit, model, sprite or whatnot else) can already be drawn with lua, so we don't actually need teh callin, yes (it could be nice, though).

Okay, I'll use your terminology. It wouldn't be particularly nice to have another callin.

Well, if another calling would be that punishing on performance, then we'll have to stick with an UI control. I guess skipping a few lines of code on a condition will be easier than adding new ones, too.