Unified Setting Tool (based on Settings++)

[koshi]

I'm trying to adapt Kloot's Settings++ for Linux to use the engine's abstract ConfigHandler. It uses wxwidgets, so with appropiate runtime could also be used on win and mac. I've already posted in the Settings++ thread, but I'm hoping to get feedback/help faster by posting here again. Not that I'm impatient, but come monday I won't have time for it for several weeks.
So here's my post again.

The adaption is somewhat complete. The code compiles ok, but I'm having problems while linking it to the relevant engine code. I've put the source in spring/trunk under tools/Settings++ and wanted to add it to the scons script. I thought that was the easiest way.
Well that was before I learned how complex that script really is (never used scons before). Anyway, after some reading in various documentations I got the source compiled via scons. That's when my trouble with said linking begins.

Here is an archive containing the source plus a diff of the SConstruct file.

The scons part for wxwidgets libs is adapted from here.

If someone could take a look at it and help that would be great. Of course I'm not set on using scons, just thought it would be easiest.

Also please tell me if I'm completely wasting my time here...

[Tim Blokdijk]

Well, for the things you ask/talk about you should get Tobi's attention.

[koshi]

I figured out how to compile it with scons using my limited python knowledge. Very hackish it is. Someone familiar with scons will be able to do it properly.
Using the engine's abstraction for config handling works great. Settings are stored instantly and load fine, too.
Only thing to do now is figure out why all the labels have disappeared in the gui...

[koshi]

I've made some progress:
- works very well on linux, no more quirks
- SConstruct for linux compilation is relatively clean now
- got it to compile on windows using wxDev-C++

Todo:
- setting registry values does not work yet on win (reading is ok)
- some gui issues on win (too many ticks under the sliders)
- message boxes for errors

[Tobi]

Great work!

I think this should replace the current settings executable, since that is totally unmaintained and misses a lot of new settings.

What is impact of the dependency on wx btw? Does that need another installer to be bundled with ours, or is it just a DLL or is the Settings++ binary statically linked with the executable?

Btw, the sliders don't have any text next to them here, I suppose that's a bug?

[koshi]

Linking is static, no additional dependencies. This makes the win executable ~3.7mb in size atm.

Btw, the sliders don't have any text next to them here, I suppose that's a bug?

That is with the binary I posted earlier right?
Take a look at current source plus binary (linux only) or win executable.

At the moment I'm having slightly different source version for win and linux due to compilation issues. That should only be a matter of time to solve. I just wanted to test it on win in limited time yesterday and made some quick and dirty changes to get it to compile.

Once I've made some further progress I would like some help to get it to compile on win using scons. I've had some trouble trying to build wxwidgets libraries with mingw which is necessary for intergrating it into springs build system later on, right?

I'll see what I can do on my own first, but have no timeframe for it.

[Tobi]

No I built it from the sources in the link in the post you quoted in your first post.

But either way, the new linux source + binary works fine

I'll see what I can wrt the compilation on windows: I'll probably look into making a new mingwlibs package including wx (and ogg, for Kloot's stuff ) libraries.

[clericvash]

If it works great in Linux can we have it in the builds? So we don't have to download separately?

Thanks!

[koshi]

A little heads up: from next thursday on I'll have time to work on this again. When it runs stable on both plattforms I will look into the ideas Yokozar has posted in the orignal thread.

@clericvash: once the app is working on both platforms and is properly tested it should be easy enough to integrate it into spring's build system.

[koshi]

Finally gotten it to save settings properly on windows. It was a very simple matter of string vs int values which took me a long time to figure out. (Hopefully I didn't break linux functionality, but too tired to test now)
I'm still having issues with colours, though.

Would someone care to take a look at it and tell me if there are settings that should be added?
Win binary
(I'll edit this post later today with link to linux binary)

TODO:
- fix these damn color issues
- add a "reset settings to default" option
- proper error handling
- add license notes, as discussed with kloot
- look into yokozar's feature idea

Any more suggestions?

[Gnomre]

Using WinXP SP2

Important things:

• The program has a fixed height. My desktop is 1024x768, and it extends past the bottom of the screen. The last option I can see is "maximum texture stages" so I can't comment on anything below that (it's as high as my monitor goes)
• Screen resolution isn't picked up right. I run at 800x600 in a window right now (as a modder, it's easier to test that way) and it reports it as this: by X
• The drop down boxes for screen resolution used by the current settings.exe app are far superior than manual entry
• The various slider bars don't seem to scale quite properly. Setting shadows to 2048 for example puts the marker at around the 30% mark. This at least applies to similar bars (I think things like the volume sliders may be correct)
• Please, please, please, please don't make disabling luarules and luagaia an option, too many games under development right now depend on luarules to play and function correctly. Disabling luaUI is acceptable though
• IMO, the program should only update the settings when you click an "OK" or "Apply" button, not instantly every time you mess with a value. There also needs to be a cancel button.

The following are my own personal feelings, and by no means are they an obligation for this application right now.
On a semi related note, I feel that this method of displaying the options (this applies to the current settings.exe too) is very intimidating to people. If possible, you should simplify it to have things like:

Code: Select all

Shadows: Off | Low | Medium | High

Code: Select all

Water Quality: Very Low | Low | Medium | High

Instead of

Code: Select all

Shadows: 1024 | 2048 | 4096
[four radio buttons for water]

and a seperate "enable shadows" tickbox on the other side of the application. Obviously for something like anti aliasing you have to use the numbers, but for things like max particles, generalize the settings to some preset 'notches', that is:

Code: Select all

Particles: Lowest | Low | Medium | High | Very High

with the values correlating to

Code: Select all

Particles: 1000 | 5750 | 10500 | 15250 | 20000

By all means, have an "advanced mode" button which would allow us to use the raw numbers if we prefer it that way, but by default it should be simple and as user-friendly as possible so new users aren't frightened off.

Also, I think it'd help if you could tab the program instead of having an entire screen of options blasted at you at once. The mouse settings in your app are in a particularly illogical place.

Finally, if you want to go the extra mile, create a hardware testing thing which could disable things like dynamic water + 8800s or shadows + very low end cards so there is less difficulty in troubleshooting for everyone. The test would only need to run the first time it's installed, and then have a button for "Re-run hardware test" in case a user upgrades or some engine bug (dynamic water for example) happens to get fixed or have its requirements somehow lowered.

[Neddie]

Using WinXP SP2

Important things:

• The program has a fixed height. My desktop is 1024x768, and it extends past the bottom of the screen. The last option I can see is "maximum texture stages" so I can't comment on anything below that (it's as high as my monitor goes)
• Screen resolution isn't picked up right. I run at 800x600 in a window right now (as a modder, it's easier to test that way) and it reports it as this: by X
• The drop down boxes for screen resolution used by the current settings.exe app are far superior than manual entry
• The various slider bars don't seem to scale quite properly. Setting shadows to 2048 for example puts the marker at around the 30% mark. This at least applies to similar bars (I think things like the volume sliders may be correct)
• Please, please, please, please don't make disabling luarules and luagaia an option, too many games under development right now depend on luarules to play and function correctly. Disabling luaUI is acceptable though
• IMO, the program should only update the settings when you click an "OK" or "Apply" button, not instantly every time you mess with a value. There also needs to be a cancel button.

The following are my own personal feelings, and by no means are they an obligation for this application right now.
On a semi related note, I feel that this method of displaying the options (this applies to the current settings.exe too) is very intimidating to people. If possible, you should simplify it to have things like:

Code: Select all

Shadows: Off | Low | Medium | High

Code: Select all

Water Quality: Very Low | Low | Medium | High

Instead of

Code: Select all

Shadows: 1024 | 2048 | 4096
[four radio buttons for water]

and a seperate "enable shadows" tickbox on the other side of the application. Obviously for something like anti aliasing you have to use the numbers, but for things like max particles, generalize the settings to some preset 'notches', that is:

Code: Select all

Particles: Lowest | Low | Medium | High | Very High

with the values correlating to

Code: Select all

Particles: 1000 | 5750 | 10500 | 15250 | 20000

By all means, have an "advanced mode" button which would allow us to use the raw numbers if we prefer it that way, but by default it should be simple and as user-friendly as possible so new users aren't frightened off.

Also, I think it'd help if you could tab the program instead of having an entire screen of options blasted at you at once. The mouse settings in your app are in a particularly illogical place.

Finally, if you want to go the extra mile, create a hardware testing thing which could disable things like dynamic water + 8800s or shadows + very low end cards so there is less difficulty in troubleshooting for everyone. The test would only need to run the first time it's installed, and then have a button for "Re-run hardware test" in case a user upgrades or some engine bug (dynamic water for example) happens to get fixed or have its requirements somehow lowered.

These are all pretty good suggestions, lads, I agree with Gnome on all points.

[rattle]

Agreed, but add Very high => 8192 to shadows.

[koshi]

First of all: thanks for the input.

I agree with the tabbed interface. In fact I've already started rebuilding the UI from scratch with tabbing in mind. The positive side effect being that this seems to solve the color issues.

As for the "simple" settings thing: I would like to bundle rendering options in one tab while keeping the "real" options live in other tab. That way one could set low-high profile with say two or three clicks and leave it at that or modify it further on the other tabs. I don't think just using "notches" for all of the options would really simplify things.

Also the tabbed UI will allow for a much more compact window size.

The screen resolution issue: the scrambled output was another string vs int case I missed. The drop down box might be a good idea for the "simple" tab. I'll keep the manual input box in the other tab for dual screen layouts, exotic widescreen resolutions and such.

The thing with the misscaled slider is a compromise kloot originally introduced as a means of keeping the rendering options all sliders while allowing only sane values. I'll try to improve the behavoiur or change it into radio buttons / dropdown box.

LuaRules/LuaGaia: I don't really think hiding options is that good an idea. Maybe I should slap a sticker on it making clear that theses are probably necessary to play some mods? Yet I don't really know why one would disable those, so if there is no plausible scenario for it I'll drop them.

As for the hardware testing thingy: yokozar already suggested something similar and I will look into it after everthing else is done. Anybody got an idea how this might be done while keeping cross-plattform functionality?

Also I'm still looking for options to add.

[Gnomre]

Sure, an overall settings tab which influences multiple settings at once sounds fine. I'd still simplify the current settings to low/med/high/etc unless an advanced mode option was checked somewhere. Even with a few large unified setting sliders, users may still want/need to tweak certain things, and I see no reason to go out of our way to confuse people who want, say, low unit LOD and close-in icon display, but the highest quality shadows (why someone would do this I don't know, just work with me here). But at the same time, we shouldn't alienate those who aren't afraid of more full, precise control.

I'll use a couple games I'm a part of as an example why luarules and luagaia (and luacob, in case you get any ideas ) shouldn't be disabled:

• SWS:
• • Due to engine limitations, metal extractors can't do things like build as a factory. We require a luarule for them to extract metal
  • We use a custom lua-->cob script call when factories begin building a unit, since Spring doesn't call the necessary function itself if there is a unit queue. Without this, our factories don't animate.
  • Since Guessmyname spilled the beans in another topic: we have flags (our metal extractors) which are captured automatically by your men. The flag doesn't need rebuilt, the lua simply spawns a new one under you control if you capture it. Both the capturing process and the team conversion process are handled by lua; without lua, the game is quite literally completely fucked.
• Tower Defense:
• • Towers cannot be built without luarules (in order to make them buildable in all of the proper locations on the map instantly without waiting for a commander to walk around)
  • Tower upgrades are handled by luarules
  • Creeps are not spawned without luarules
  • Creeps cannot carry out their route without luarules
  • There is no custom GUI without luarules (and some luaui)
  • Maps require luagaia to define the waves of creeps (frequency, which creeps to use, etc) and the waypoints they need to follow, since the maps are generally going to be maze-like. Without luagaia, the game fails

That's just a partial look at two games (SWS has a *lot* more lua in play). Look in the lua forum and check out stuff Zpock is doing, for example: he's practically rewriting a large part of the engine core in lua (his weapons are all lua handled). And of course, there's CA, which is probably the gold standard for lua coding right now.

It's just a bad idea for it to ever be an option. Lua has passed the point of novelty in the engine, it's no longer a way to perform nifty little tricks. It's now the core of several games, without which each will completely and utterly fail at being anything remotely playable. If LuaUI hadn't been designed so openly in the first place, I'd rally for its option being taken out of settings as well, but that ability to disable it is now a safeguard against buggy and/or conflicting scripts more than anything.

[tombom]

* Since Guessmyname spilled the beans in another topic: we have flags (our metal extractors) which are captured automatically by your men. The flag doesn't need rebuilt, the lua simply spawns a new one under you control if you capture it. Both the capturing process and the team conversion process are handled by lua; without lua, the game is quite literally completely fucked.

pls let s44 use this

I didn't even realise it's possible to disable LuaRules/Gaia through settings. It's a really bad idea IMO.

[koshi]

Alright, I see it would be *really* not a good idea to be able to disable those easily. Consider them gone. If anyone should find a good reason he could still disable them manually.

Gnome, if I get you right you would like the sliders to be "notched" anyways, but if the user enables expert mode they should revert to numeric?
Don't know how easy to implement that would be. I'm still thinking about how to implement the "save on demand". The underlying engine code I'm using for settings handling was specifically designed to instantly save them, so I would have to store them in some structure at first and only later "give" them to the config handler. But not to worry I'm still on top of most of the stuff

[Gnomre]

I was thinking something simple, like this:

(I didn't bother correlating that value with the text for the pic)

[edit] "Medium" would be translated by the program to mean "10500". I just did the math to get the mid-range value between 1000 and 20000. If a user wanted, say, 8000, he'd need to go into expert mode to set it to that.

[koshi]

That's what I thought you were thinking...

I agree that the "normal" mode is less intimidating/ confusing. Plus I really like the use of spin buttons in the way you pictured.
But as I now see it I would have to swap out tabs or even reinitialise the whole window to switch from normal to expert mode. Meaning it requires a good amount of thought and work to minimise code dublication and whatnot.
So this will be at the bottom of my priorities list, just above the hardware detection thingy.
Don't get me wrong, I like the idea, but I would like to finish basic functionality first and add upon that later.

So if anyone has more ideas / feature requests keep them coming.

[Gnomre]

I certainly understand. It's definitely better to have a good, working, cross-platform version of the application, even if it's not friendlier than the current one yet. I'm just saying in the long term, it should be made more accessible, after its funcitonality is set up.