Spring RTS Engine

Basically, our control of Settings from within Spring via Lua needs massive improvements.

Many settings cannot be passed integer arguments. For example, you can increase / decrease ViewRadius, but you can't apparently manipulate it directly.

Some things (such as sound volumes) use floats and a non-linear relationship with the settings, whereas they should be taking integers that behave exactly the same way as SpringSettings.

It's hard to build a half-decent settings application if we can't read-write these things in a rational manner. If Spring's UI is going to finally get to the same state as a professional game engine... we need to open this stuff up to Lua.

If all of this worked right, we could eventually quit having to maintain SpringSettings entirely. I have an early settings-control UI, and I know that IceUI has one as well, I'd like to see this stuff get improved to the point where players never have to use SpringSettings at all, but instead picked out a Widget that sufficed for their needs, including auto-control over FPS-crucial variables, such as ViewRadius (which, as I keep reminding you guys, is the single-largest FPS-crusher in Spring atm, due to the problems I've described with the POV and map tessellation, which really should get fixed).

e.g. or Most of them require a restart.

Which ones require a restart, and why can't we change them on the fly?

I mean, hardly anything that can be changed by Settings is a really big deal, other than fullscreen.

Anyhow, I'll look at all of this more later, need to finish packing up 5.2.

Argh wrote:why can't we change them on the fly?

Because there's no infrastructure in place to notify the respective pieces of code which use (and cache) the setting about a change to it.

Either that should be made, or all code should re-read every configuration variable everytime it is used.

That was what I was figuring was the case. If we're going to (eventually) get to the point where everything possible's done through Lua, though, this is one area that needs some love at some point.

Any commercial game you see these days has a settings menu that you can get to by hitting the ESC key. Whereas Spring gives you a console error by default, because it thinks you're trying to quit.

I even finally put a QUIT button on the options application, because I got some gentle complaints from the ModDB crowd about how completely non-normal Spring's handling of such things is.

IceUI

CarRepairer wrote:IceUI

Is it time to name random widgets with spring settings? Rooms.

There's another problem, which is that many settings modified with /set remains between spring exits and and mod changes. There's some setting I would like to set at the beginning of each KP game but preferably without messing up others mods settings.

From what I see of it lurker, imo rooms is incredibly finiky and buggy.

I'm sure it works absolutely fine in ca, but there are 50 million edits that have to be done to make it suitable for blanketing all mods.

Rooms is built as quite literally a CA menu of sorts, not as a settings menu. What we need is a widget that can be plopped into all mods that ONLY covers settings for spring.

If we can read the settings we're setting, that'd be fine. Problem is, we can't read them, so we can't put them back to their old values.

rooms?

Argh wrote:If we can read the settings we're setting, that'd be fine. Problem is, we can't read them, so we can't put them back to their old values.

GetConfigInt, GetConfigString; did you look?

AF wrote:rooms?

gui_rooms aka CA gui

GetConfigInt, GetConfigString; did you look?

Haven't had time, no. Sorry, I've been a bit busy. I'll see about using all of this to revamp my basic settings application for the next version of P.U.R.E., and it's a Widget so anybody can integrate it into their projects very easily. It'd be great to make it save the settings, maybe even have one or more sets of saved settings for different games or w/e, that'd be a big improvement over SpringSettings and it should be pretty easy, if I can actually access everything.

Worked. P.U.R.E. will automatically configure itself for end-users upon startup, the first time people play it, to optimize itself for better performance and beauty.

I'll work on the settings application s'more when I don't have deadlines staring me in the face.