Separating/Modularizing the View

[hoijui]

i agree with the new one you have there

just to make it clear (even doh i think you know that):
master does not have a special role at all when tlaking about merge/rebase strategies, it is just a name (same goes for origin).

my strategy (in my words, same thing, different wording):
1. always merge different branches. rebase on the same branch if no force is needed to do so.
2. you are only ever allowed to rebase commits in a branch, if nobody else saw them yet (in this branch). as soon as something is pushed (to a public repo), you have to consider it seen/fetched by somebody.

as a side note (not directly related):
i think the master branch in your springheadless repo should actually be called springheadless instead. because....
the repo is a copy/fork of the spring main repo, so you can have github/spring as origin eg, and github/springheadless as originHL.
then fetch from both, and you would see (among others), these branches:
as it is now:

Code: Select all

origin/master
originHL/master

they have the same name, but are actually different branches, as in: we would merge them, not rebase one on the other, cause they are logically different things. so originHL/master should be originHL/springheadless, and originHL/master could still be there, but merely beeing a clone/direct copy of origin/master (though i do not see much sense in this).
i don't think we have to change it though, as long as we keep in mind that the two masters are different branches.

[hoijui]

i "renamed" the master branch to springheadless
so you should probably do:
git checkout -b springheadless origin/springheadless
if you still have local stuff, it is gona get a bit more complicated, but should be doable.

mm.. now it seems a bit rude, sorry. if you preffer master, create it again.

also merged master back in, and becuase of a fix made by Kloot, it is now possible to run at resolution 0x0 (before that fix, minimum was 113x0). I tested, and it works (guess it wont give any speedup though ).

[hughperkins]

i "renamed" the master branch to springheadless
so you should probably do:
git checkout -b springheadless origin/springheadless
if you still have local stuff, it is gona get a bit more complicated, but should be doable.

Sure, that sounds great!

[hughperkins]

i "renamed" the master branch to springheadless

Hi hoijui, I feel it is better now with the branch renamed to springheadless.

One thing I just noticed is that when we go to http://github.com/hughperkins/springheadless , it points us to some random branch since it just looks for master! So, I'm thinking it might be an idea to create a new empty master branch containing just a README that points to the springheadless branch?

[Tobi]

AFAIK you can set the default branch to show on github.

[hughperkins]

AFAIK you can set the default branch to show on github.

Ahh...! Good spot! Thanks!

[hughperkins]

Code: Select all

/**
 * forces certain config values to certain values under certain
 * circumstances, eg for headless spring, we set all graphics parameters
 * to low
 */
void SpringApp::LoadFixedConfigs() {
#ifdef HEADLESS
   configHandler->SetOverride("AdvSky", 0 );
   configHandler->SetOverride("AdvUnitShading", 0 );
   // ... etc ...
#endif // HEADLESS
}

How does that sound?

Stupid. If you want low values, then set it to low values. Thats what config files are for.

Hi Auswaschbar, you know, maybe you have a point I'll back this code out. See http://springrts.com/phpbb/viewtopic.ph ... 91#p393891 for an example of how this change came back to bite me

For now, I'll just back this change out of springheadless, and we can use the global config. I kind of think that it could be useful to add in a command-line argument to specify the location of a specific configfile, eg:

Code: Select all

./spring-hl --config-path=config-headless.txt

No biggie though. I can live without it. Might be nice though, in the case that you consider that it won't bloat the spring code too much?

[hughperkins]

Updated git://github.com/hughperkins/springheadless.git , branch 'springheadless':
- backed out config override changes made in commit 060605420
- added game/config-headless.txt , which contains the settings needed to run springheadless
- added game/LuaAI/Widgets/headless_setup.lua , from aegis, which lets the game run at x120 speed, instead of x3 speed.

For aegis's widget, I'm unsure if it was appropriate for me to create it directly in the game hierarchy like this? Maybe it will interfere with normal spring, in the case that springheadless is merged into spring at some point? Maybe it should just be made available in tools/HeadlessSpring somewhere?

Following this commit, to run spring-hl from a fresh build, the following should probably be sufficient and necessary I think:

Code: Select all

cp game/config-headless.txt $HOME/.springc
spring-hl <scriptfile>

Edit: ah, checking the code in headless_setup.lua, it looks like it only activates when HEADLESS is set to 1, so it should be safe to put directly in the 'game' hierarchy like this?

[hoijui]

hmmm...
yeah the config file thing....
thi solution is, in my eyes, just as ugly. it works kind of ok, though it has still a very high possibility to cause problems. eg, most users that want to use headless spring will not install the template config file, and there is no way you can change this, no matter where you'll write notes to, no matter how big fat and red the letters are you write it with. i know, that i will forget it too.
and other issue is, if you have a machine where you want to run both headless and normal spring. there you had to take even more special messures to make it work right. as it is now, this would mean switching config files whenever you want to run one or the other, and wiht the requested change of the --config-file parameter, you still had to make sure that spring headles is started with that, which means writting wrapper scripts or other ugly stuff -> most users will forget about doing this.
also, it is conceptually bad, if you have a headless build of spring, but widgets only know about the headlessnes if it is configured in a config file.

other possibilities:
1. define a separate default config location for headless spring, eg ~/.springrc-headless. we could then copy the template config file to this one, and users would not forget doing this step. The bad thing of course, is that users will then change config values in ~/.springrc still, and wonder why it does not have any effect.
2. extend the config file system with sections, or with.. kind of prefixes, like so:
sections:

Code: Select all

...
ResolutionX=1024
ResolutionY=768
[HEADLESS]
ResolutionX=0
ResolutionY=0

prefixes:

Code: Select all

...
ResolutionX=1024
ResolutionY=768
HEADLESS:ResolutionX=0
HEADLESS:ResolutionY=0

the prefixes way would be my preffered one i do not see any mayor flaws with it right now, but i guess there are; i am jsut too dull right now. Please bash me again. (Aus? :D)

[hughperkins]

Hmmm, the sections idea makes a lot of sense to me.

- one config file
- that works for both normal spring and spring-hl
- with everything in one place
- that can be configured
- that doesn't imply major changes to spring itself
- and it can be delivered as a single config file at installation, so everything works straight out-of-the-box, both spring and spring-hl!

I have to say I'm quite impressed at how clean this solution appears to me to be and how deceptively simple!

[Tobi]

IMO what would be desired for the config file is a way to have the config handler read from multiple sources, and only write modifications to one source.

This way Spring headless could, for example, read stuff from ~/.springrc, override certain keys with content from e.g. /etc/spring/spring-headless.cfg, and write changes to ~/.springrc.

It would also allow per-game config overrides. (That could be a good way to prevent widgets in one game from messing up Spring configuration for another game, i.e. setting confg variable from widget could write to per-game config file, while e.g. SpringSettings keeps writing to the main config file.)

Would need a bit more thinking tho to come up with a design that is flexible and still easy to understand.

EDIT: hmm this could be done all in one file, using sections.

[hoijui]

:D
the way i understod the multiple config sources idea as you described it... it would not be good if XResolution would be read from springrc-headless, and then written to springrc.
but.. you say it would be better with sections, and all in one file?
how/where would we define the precedence?
lets say XResolution is defined in the default/main section, hedaless one, and in the widgets, gadgets or BA section or whatever (i know the example is not good ). would sections have a priority? [MAIN=10], [HEADLESS=5], [BA=20] ?

as a side note: as "Headless" is now in the Additional version string for headless spring builds, widgets (the newly added one) should check this, instead of a config value named Headless, i think.

[hughperkins]

Just to throw in a random idea in the linux world there are many cases where an installer can just throw files into a directory, eg /etc/sysctl.d , or /etc/sources.list.d/

The advantage being that it makes installation trivial.

On the other hand:
- in fact this could still work using sections, ie the spring-headless config file could still have a "[HEADLESS]" section
-- therefore it could be simply a backwards-compatible enhancement at some indefinite point in the future
- a downside: might confuse users, much as hoijui originally pointed out when discussing passing in a config file name on the commandline
-- but, since the files are all in one place, it should be much more obvious that they're there
-- but but, what is the order of priority when there are conflicts?

[hughperkins]

lets say XResolution is defined in the default/main section, hedaless one, and in the widgets, gadgets or BA section or whatever (i know the example is not good ). would sections have a priority? [MAIN=10], [HEADLESS=5], [BA=20] ?

.... yeah, we could define precedence order, eg build-specific (eg 'headless') overrides generic (eg 'spring'), and widget overrides build-specific and generic, but then we'll have lots of discussions about the appropriate order of precedence, and more importantly: anyone changing the config file will have to memorize these rules...

I'm going to stay out of widget-specific, but maybe for build-specific vs generic, the easiest might be just to have *all* configuration for headless only in the [HEADLESS] section, and *all* configuraion for spring generic only in the [SPRING] section?

[hughperkins]

Oh, or just define inheritance explicitly:

Code: Select all

[HEADLESS]
extends [SPRING]

This is similar to how jinja2 templates work for python webpage design.

I know nothing about widget configs so I'm not in a position to say how well that would work for widget configs.

[hoijui]

hmm.. seems like a good idea to me.

why i preffered prefixes:
it allows different kind of sorting the entries. one would be, to group all from left to right, that would be equal to the sections approach, and the other would be to sort from right to left, which is not possible wiht sections. this could be usefull to more easily see which value will be applied, as eg, all the different settings for ResolutionX would be in the same place, instead of in totally different places like in the sections approach.
but i agree that it is a minor thing; i do not care much.

an other way to handle precedence/inheritance could be hirarchy, eg:

Code: Select all

SettingX=a
WIDGETS:SettingX=b
HEADLESS:SettingX=c
HEADLESS:WIDGETS:SettingX=d

The applying value would then always be the most specific one.
(could be done with both prefixes or sections)

[hughperkins]

an other way to handle precedence/inheritance could be hirarchy

It's not really clear to me what the value of SettingX would be in this case:

Code: Select all

WIDGETS:SettingX=b
HEADLESS:SettingX=c

As far as getting spring-hl committed to spring itself, it looks like having a section called "[HEADLESS]" could be forwards compatible with many of the enhancements we're considering such as hierarchy, explicit inheritance, implied precedence/priority and so on.

Perhaps we could implement a very simple sections implementation for now, to get spring-hl into spring, and then we could think about more detailed options later on, over a few months or so?