- Welcome
- Progress of stuff to be done before release
- security issues with in-game join & autohosts
- http://springrts.com/mantis/view.php?id=1975
- simplify version string (in infolog)
- "0.81.2.1 (0.81.2.1-0-g884a107{@}-cmake-mingw32)"
- "0.81+.0.0 (0.81.2.1-1192-g0ecee11 MT-Sim)"
- "0.81.2.1 (HL)"
- "0.81.2.1"
- HL
- DevIL on hl systems
- hl-compile package?
- Wiki: How to build Spring on Linux-Headless
- basefiles: sdz -> sd7?
- rename spring-dedicated -> spring-ds?
- divide financial power (concerning spring server donations)?
- OS X (progress)
- MT / LUA (ignore CPU load for users with a high LUA-DRAW % ?)
- Buildbot progress
- Next meeting
- Anything else? (WVTTK)
<[ARP]hoijui_g5> nothign for me
<[RoX]Tobi> tried to make test build today but didn't work at all on my win laptop and got distracted after that
<Kloot> any progress on 1969/1974?
<[RoX]Tobi> thought about rc in version number but considered that too much work, instead I propose after this release we use odd version numbers for testing releases and even version numbers for real releases
<[LCC]jK> o_O
<[RoX]Tobi> I didn't got around anymore at asking netto to test it again
<[ARP]hoijui_g5> Kloot: smoth has not had time to try the other OpenAL version yet :/
<[ARP]hoijui_g5> but considering it will fix it, what shoudl we do?
<Kloot> hmm, then I suggest we just move on with the RC
<[ARP]hoijui_g5> casue we have also bug reports on hte old (creatives) openal version
<[ARP]hoijui_g5> hmm.. maybe i will try to talk wiht the OpenAL Soft guy then, to get him to try to fix the bug
<[ARP]hoijui_g5> even doh.. he might just say it is a bug in the soudn card or whatever...
<zerver> anyone else had this bug?
<[ARP]hoijui_g5> but yeah.. dont think this should stop us from doign the RC
<[ARP]hoijui_g5> could be, yes
<[RoX]Tobi> I'm continuing on test build post as we speak
<[ARP]hoijui_g5> the errorr has nothign specific in infolog, so it is hard to tell
<[LCC]jK> I was able to reproduce it
<[RoX]Tobi> I prefer at least some testign to be done before rc and I've no clue how much buildbot builds are tested
<[ARP]hoijui_g5> ..there yo ugo
<[LCC]jK> testing right now if it still happens
<[ARP]hoijui_g5> yeah... i did some test games vs AIs lately..
<[LCC]jK> everything fine now
<[ARP]hoijui_g5> and some path finding issues are.. well.. quite bad
<[ARP]hoijui_g5> much more often then in last release, you have to manually maneuvre units to some point
<[ARP]hoijui_g5> cause htey will jsut endlessly try to walk into a wall
<[LCC]jK> seems to be fixed by recompilation with dwarf2
<Kloot> thought that might happen
<zerver> pathfinding was better back in .78/.79
<[ARP]hoijui_g5> or they leave the lab at the wrong end.. with no apparant reason
<[RoX]Tobi> http://springrts.com/phpbb/viewtopic.php?f=12&t=23523
<[ARP]hoijui_g5> hmm.. the thing you removed there once, kloot?
<[LCC]jK> testbuild =? RC
<[RoX]Tobi> I prefer at least some testign to be done before rc and I've no clue how much buildbot builds are tested
<[LCC]jK> k
<Kloot> units getting stuck more often because they don't recheck for new paths as frequently
<[ARP]hoijui_g5> ahh ok
<[RoX]Tobi> besides this saves a lot of time with making tag and stuff (although that needs to happen later anyway)
<[LCC]jK> it makes it more complicated to compile RC on linux
<[RoX]Tobi> *test build
<[ARP]hoijui_g5> yeha.. maybe we shoudl add linux instructions
<[RoX]Tobi> 0.82.0.0 will be RC
<[ARP]hoijui_g5> i like this btw..
<[ARP]hoijui_g5> good if we have an easier way to make test builds then an RC with tags and all
<[ARP]hoijui_g5> even if not as many will take part
<[ARP]hoijui_g5> Kloot... do you have anything planned for that (path finding thing)
<[ARP]hoijui_g5> ?
<Kloot> testbuild or RC will probably have equally low number of people testing them
<zerver> thats always a problem
<[ARP]hoijui_g5> .. hmm also true
<Kloot> so whatever saves us work
<Kloot> is best imo
<[RoX]Tobi> yeah I fear so.. really need someone to pull forward a testing group
<[RoX]Tobi> that worked reasonably well the few times it was pulled off
<[ARP]hoijui_g5> well.. me and zydox are such one
<[ARP]hoijui_g5> and abma also takes part soemtimes
<Kloot> [ARP]hoijui_g5: yes
<[ARP]hoijui_g5> ok
<[RoX]Tobi> ah nice
<[ARP]hoijui_g5> AI devs are good for this .. as they will usually make usefull reports
<[ARP]hoijui_g5> and they have compiling setup locally often.. so no problem tfor them to get a test build
<[RoX]Tobi> for anyone on windows it's should not be a problem because of buildbot
<[ARP]hoijui_g5> ok so... we tell smoth he shoudl try a current build (wiht dwarf2) for 69/74)..
<[ARP]hoijui_g5> mm
<[ARP]hoijui_g5> yeah.. since the 7.13beta BA finally is usable on master without modifications...
<[RoX]Tobi> it's usually just laziness and/or naive expectation that everyone will keep working magically IMO
<[ARP]hoijui_g5> testing wiht windwos users is easier now
<[RoX]Tobi> *everything
<[ARP]hoijui_g5> :D
<[RoX]Tobi> ah that is good to know
<zerver> tried 7.13 yesterday
<[ARP]hoijui_g5> mmm no more workaround needed
<zerver> it seems to work alright
<[ARP]hoijui_g5> mm
<[ARP]hoijui_g5> next?
<[RoX]Tobi> so to summarize plan is, I make 0.82 whenever I have a big enough chunk of free time, and unless critical bugs have been reported in the test build?
<zerver> yep
<[ARP]hoijui_g5> yeah
<[RoX]Tobi> k
Main points:
- I make 0.82 whenever I have a big enough chunk of free time, and unless critical bugs have been reported in the test build?
<[RoX]Tobi> is this on agenda cause it was last week, or is there anything to speak about?
<[ARP]hoijui_g5> casue it was last week
<[ARP]hoijui_g5> the only thing missing there is using a newer lobby server version
<[LCC]jK> is it fixed now?
<[ARP]hoijui_g5> yes
<[ARP]hoijui_g5> tasserver and ueberserver have it fixed
<[ARP]hoijui_g5> byt tasserver master needs stress testing
<[ARP]hoijui_g5> but*
<[ARP]hoijui_g5> it is running on springlobby.info
<Kloot> same as 'uberserver then
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> just that i do not have accoutns data from the official server
<[ARP]hoijui_g5> next
Main points:
- Fixed in tasserver and uberserver, just not tested with those
<[ARP]hoijui_g5> yeah..
<[ARP]hoijui_g5> as the etherpad shows..
<[ARP]hoijui_g5> they are not very nice
<zerver> agree
<[ARP]hoijui_g5> one thing is.. the git tag and the value in GameVersion.h do often not match
<[RoX]Tobi> isn't that simply because of branches?
<[ARP]hoijui_g5> and also.. the {@] thing is ugly for parsing.. plus it is genreally not very nice for parsing
<[RoX]Tobi> I don't use the {@} in new buildbot
<[ARP]hoijui_g5> ahh good
<[ARP]hoijui_g5> you also dont have the cmake-mingw32 part?
<[RoX]Tobi> also there's less info in general, but IMO a lot of it is useful
<[RoX]Tobi> correct, IIRC
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> the difference in the version is.. cause we do not use the + tags
<[ARP]hoijui_g5> eg 0.81+.0.0
<[ARP]hoijui_g5> in git
<[ARP]hoijui_g5> but in the version file we do
<[ARP]hoijui_g5> of course, branchign also matters
<[RoX]Tobi> I use `[config]{branch}commit'
<[RoX]Tobi> where [config] is left out if it equals default
<[ARP]hoijui_g5> ahh..
<[RoX]Tobi> and branch is left out if it equals master
<zerver> good
<[ARP]hoijui_g5> can yo ugive some examples of the fill version (as the ones in ethernet)
<[RoX]Tobi> and I guess I need to check a bit whether it works properly on a tag
<[ARP]hoijui_g5> :D
<[RoX]Tobi> `Additional' is set to `0.81.2.1-1377-ge7e87ab' for example
<[ARP]hoijui_g5> i think we alreayd talked abotu it but.. was there a reason why we need both the git tags and the version in GameVersion.h?
<[RoX]Tobi> so that + whatever spring adds is final version string
<[ARP]hoijui_g5> ahh ok
<[ARP]hoijui_g5> GameVersion.h adds the MT HL and similar stuff
<[RoX]Tobi> on tag I know that Additional at least reduces to e.g. `0.81.2.1'
<zerver> important is to have stacktrace translation up and working before release
<[ARP]hoijui_g5> in addition to Additional
<[RoX]Tobi> it's working
<zerver> good
<[RoX]Tobi> just might need some web interface next to xmlrpc call so it's easier to use for bugs not in Zydox' system
<[ARP]hoijui_g5> hmm.
<zerver> working for MT too? bibims server had problems identifying the MT version in last build
<[ARP]hoijui_g5> i made a java app for that.. but web would be beter, yeah
<[RoX]Tobi> I have not tried that, but IIRC I handle all executables more or less equally
<zerver> ok
<[RoX]Tobi> zerver: if you give a trace of MT build I can try
<zerver> will try my best to crash it
<[RoX]Tobi> so conclusion is that no more change to version number is needed?
<[RoX]Tobi> ok
<[ARP]hoijui_g5> so.. anyone rememberswhy we still need the verison numebr in GameVersion.h?
<[ARP]hoijui_g5> there is still the difference in the two version numbers for anything except a release
<[RoX]Tobi> to use for the version number used for checking whether things sync
<[ARP]hoijui_g5> mmm
<[RoX]Tobi> although that could be calculated from the string git-describe outputs too (i.e. up to 3rd dot is sync-breaking)
<[ARP]hoijui_g5> well.. if we would supply that through the build system..
<[ARP]hoijui_g5> hmm
<[RoX]Tobi> you will still get some mismatch though due to branches
<[ARP]hoijui_g5> yeah.. we couls set ti with cmake
<[RoX]Tobi> git describe only follows the chain of parents of current commit until it finds a tag iirc
<[RoX]Tobi> so it can never find a tag that is on a branch
<[ARP]hoijui_g5> either using git describe, or reading the VERSION file (in case of tarball)
<zerver> to actually patch GameVersion seesm overkill
<zerver> there must be a better way to supply it as a compile flag
<[ARP]hoijui_g5> cmake woudl set a define, which is picked up by GameVersion.h
<[RoX]Tobi> patching GameVersion is way faster
<[RoX]Tobi> if it's -D thing in cmake everything needs to be recompiled when version changes
<[RoX]Tobi> so after every commit
<zerver> ah
<zerver> stupid
<[ARP]hoijui_g5> hmm?
<[ARP]hoijui_g5> no..
<[RoX]Tobi> unless someone patches our cmake system so it passes -D flag only to GameVersion.cpp
<[ARP]hoijui_g5> we would only supply the tag part
<[ARP]hoijui_g5> not the whole git describe
<[RoX]Tobi> putting version string in a file is really not hard though
<[RoX]Tobi> no need to change that to pass it through cmake suddenly, IMO
<[ARP]hoijui_g5> i see no downside so far..
<[RoX]Tobi> of changing it? or of keeping it identical?
<[ARP]hoijui_g5> of changeing it
<[RoX]Tobi> I don't see yet what it solves
<[ARP]hoijui_g5> we do not have to make extra commits to change GameVersion.h before and after releases
<[ARP]hoijui_g5> plus we do nto get different version numebrs in the version string
<[RoX]Tobi> ah I see, you want to more for something like what openttd uses
<[ARP]hoijui_g5> ... hmm :D no idea :D
<[RoX]Tobi> that is, a script integrated into build system that (I think) patches their GameVersion.cpp before compile
<[ARP]hoijui_g5> yeah..
<[ARP]hoijui_g5> but i woudl do wit with a -D
<[ARP]hoijui_g5> as the valeu will only change when we add a new commit
<[ARP]hoijui_g5> aehh i mena. a new tag
<[RoX]Tobi> not exactly sure though, but definitely it picks up version also for local compiles
<[RoX]Tobi> yeah but still it forces needless recompiles
<[ARP]hoijui_g5> ..
<[ARP]hoijui_g5> hmm.
<[ARP]hoijui_g5> yeah at realese.. that is.. one the release tag, and then the + tag..
<[RoX]Tobi> as dev I might have e.g. 0.81-1746, and want to tag that as 0.82, then test whether version appears correctly
<[ARP]hoijui_g5> but we can also compile GameVersion.cpp into a static lib
<[RoX]Tobi> with your approach that would mean complete recompile as opposed to recompiling only GameVersion.cpp and relinking
<[ARP]hoijui_g5> and only pass that -D to that lib compile
<[RoX]Tobi> that would work but seems needlessly complicated
<[ARP]hoijui_g5> well.. it is a 5 minutes change in cmake
<[RoX]Tobi> personally I think there is a reason ./configure based systems put all #defines in a config.h, and #include that
<[ARP]hoijui_g5> and it will save us time and commits at every future release
<[RoX]Tobi> as opposed to putting lots of -D flags on command line
<[ARP]hoijui_g5> yeah.. we can do that too..
<[ARP]hoijui_g5> but that file should not be in git then
<[RoX]Tobi> indeed
<[ARP]hoijui_g5> deal
<[RoX]Tobi> :)
<[ARP]hoijui_g5> so we jsut have ot decide the name for the file, where to place it.. and what exactly it contains
<[ARP]hoijui_g5> contians i guess: "#define ENGINE_VERSION 0.81+.0.0"
<[RoX]Tobi> sure, we can do that later though, IMO (maybe after meeting)
<[ARP]hoijui_g5> yep later
<[RoX]Tobi> ok
Main points:
- Current version strings are sometimes a bit long
- Builds from new buildbot have usually a bit shorter version strings (no need anymore for scons vs cmake, since it only builds using cmake).
<[ARP]hoijui_g5> so i compiled spring with the -DHEADLESS_SYSTEM=TRUE cmake option
<[ARP]hoijui_g5> which does not configure spring and spring-mt
<[ARP]hoijui_g5> i did that on my headles ssystem
<[ARP]hoijui_g5> (mo mesa, opengl, X, SDL, DevIL)
<[ARP]hoijui_g5> mo=no
<[ARP]hoijui_g5> i coudl not use ubuntus DevIL, cause it depends on SDL and OpenGL, cuase it has thumbnail generating capabilities or soemthing)
<[ARP]hoijui_g5> so i had to compile DevIL myself
<[ARP]hoijui_g5> question is.. should we ship such a minimal DevIL?
<[LCC]jK> better use a devil stub?
<Kloot> why not a devil stub?
<[ARP]hoijui_g5> or just setup instructions for how to compile?
<[ARP]hoijui_g5> caseu devil is needed for loading the map, eg
<Kloot> not for the synced part of smf maps
<[LCC]jK> afaik no
<[ARP]hoijui_g5> hmm..
<[ARP]hoijui_g5> i remember i looked at ti two times.. and i always came to the conclusion it was :D but i believe you of course.
<[ARP]hoijui_g5> so i will look at that again
<[ARP]hoijui_g5> next point then
<[ARP]hoijui_g5> ah yeah.. HL wokrs fine on that system
<[RoX]Tobi> devil may be needed for map loading though (e.g sm3)
<[ARP]hoijui_g5> hmm..
<[RoX]Tobi> but I think it's not our problem if devil compile in some distro depends on opengl and sdl and whatever
<[ARP]hoijui_g5> it will depend on that on all distros.. except maybe gentoo
<[ARP]hoijui_g5> or i guess so at least
<[RoX]Tobi> if someone really wants it he could file bugs at the distro requesting devil-headless package or so
<[ARP]hoijui_g5> well... i will try to stub it then, if that does not work, i will incldue Devil compile instructions in the wiki.. it is not too hard)
<[ARP]hoijui_g5> incomparabel to boost
<[ARP]hoijui_g5> hmm
<[RoX]Tobi> lol ok
<[ARP]hoijui_g5> just need libjpeg and libpng + -dev packages, then configure and make
<[ARP]hoijui_g5> next
Main points:
- Ubuntus DevIL is not ideal for completely headless system as it drags in OpenGL and SDL
- Should we ship DevIL ourself or stub it?
- Tobi says it's not our problem and DevIL may be valid dependency even for headless (e.g. for sm3)
- hoijui will try to stub it and otherwise just stick with Devil compile instructions
<[ARP]hoijui_g5> yeah...
<[ARP]hoijui_g5> dont know if it makes much sense..
<[ARP]hoijui_g5> jsut as we use 7zip now anyway :D
<[ARP]hoijui_g5> if we make them 7z, we woudl not need 7zip-full for the build process
<zerver> ok
<[ARP]hoijui_g5> as the base 7zip only supports 7z (not zip + other formats)
<[ARP]hoijui_g5> yeah.. a really minor issue..
<[ARP]hoijui_g5> maybe it woudl create more problems then it solves
<[RoX]Tobi> wasn't this tried before and reverted for some reason?
<zerver> but user maps can still be sdz???
<[ARP]hoijui_g5> hmm.. can not remember that...
<[ARP]hoijui_g5> yeah, we use minizip under rts/lib for sdz archives
<[ARP]hoijui_g5> its just at build time
<zerver> ok
<[ARP]hoijui_g5> the problem i coudl see, is for devs
<[ARP]hoijui_g5> which woudl end up with the base files with sdz and 7z suffixes side by side
<[ARP]hoijui_g5> if we do not take special messures to delete the sdz versions
<[ARP]hoijui_g5> votes?
<[ARP]hoijui_g5> nobody cares enough to say something? :D
<[RoX]Tobi> what is the problem with sdz?
<zerver> blank vote
<[ARP]hoijui_g5> nothing.. except that it requires 7zip-full installed at buildtime
<[ARP]hoijui_g5> instead of 7zip
<[ARP]hoijui_g5> only
<[ARP]hoijui_g5> (or 7zip-common? well.. the base package)
<[ARP]hoijui_g5> as said.. really minor issue
<[RoX]Tobi> then I vote against, could just cause breakage here and there and doesn't really solve anything
<[ARP]hoijui_g5> ok..
<[ARP]hoijui_g5> next then
Main points:
- Should basefiles be sd7 instead of sdz? No, unnecessary change.
<zerver> i vote for
<[ARP]hoijui_g5> yeah.. just for consistency
<[ARP]hoijui_g5> with spring-mt
<[ARP]hoijui_g5> and spring-hl
<[ARP]hoijui_g5> would it cause troubles with auto-hosts?
<[ARP]hoijui_g5> or are they using the shared lib anyway?
<[RoX]Tobi> hmm yeah but will probably break springie and spads
<[RoX]Tobi> good point, no clue
<zerver> that is a 10sec fix so i still vote for
<[RoX]Tobi> actually I guess they use the executable
<[ARP]hoijui_g5> mmm
<[ARP]hoijui_g5> could also imaigne that..
<[RoX]Tobi> 10sec fix yeah, but takes many days probably before all autohosts are updated
<[ARP]hoijui_g5> if we could ship a redirect script maybe..
<zerver> lol
<[RoX]Tobi> it's breaking the interface to other software only for consistency
<[ARP]hoijui_g5> yeah..
<Kloot> ah's need to update their dedicated executables anyway
<[ARP]hoijui_g5> lets dismiss htis too
<[ARP]hoijui_g5> next then
<zerver> yes, if we ever going to change the name, now is the time
<[RoX]Tobi> Kloot yes, but then also their ah software
<[RoX]Tobi> hmm true, with the password changes etc. that's probably true
<[ARP]hoijui_g5> mm
<[RoX]Tobi> blank vote from me as long as I don't have to do it
<zerver> will probably be lots of trouble with passwords and other things anyway, so some more minutes downtime is no big deal
<[ARP]hoijui_g5> we should have at least one AH owner to join the test build jurney
<[ARP]hoijui_g5> we coudl do the change.. and revert later, if it caused troubles?
<zerver> people who are desperate can just rename spring-ds manually
<[ARP]hoijui_g5> an other solution woudl be, to rename spring-mt and spring-hl
<[ARP]hoijui_g5> as nothign depends on them, so far
<[ARP]hoijui_g5> ahh btw..
<[ARP]hoijui_g5> as soon as we get a launcher executable.. all this does not matter anymore anyway :D
<[ARP]hoijui_g5> so maybe.... going for consistnecy there has no big use?
<zerver> short names are best imo
<[LCC]jK> I prefer self-explaining names
<[ARP]hoijui_g5> hehe :D
<[ARP]hoijui_g5> perfect.. in hte same second
<[RoX]Tobi> in code consistency is necessary for reducing brain utilisation when reading it
<Kloot> self-explaining short names
<Kloot> are best :]
<[ARP]hoijui_g5> :D
<[RoX]Tobi> but for a few executable names it doesn't really matter imo
<[LCC]jK> the user sees those files and don't know what they are/do
<[LCC]jK> so it is important here imo
<[ARP]hoijui_g5> mmm
<[ARP]hoijui_g5> also.. you will usualyl not type them in by hand.. anywhere..
<[ARP]hoijui_g5> adn if so, you can usualyl use auto-completion
<[ARP]hoijui_g5> so longer names have no real contra there
<[ARP]hoijui_g5> and as spring-mt and -hl have never been released so far...
<[ARP]hoijui_g5> it coudl nto cuase troubles, changeing their names
<[LCC]jK> :)
<[ARP]hoijui_g5> spring-head-less
<[ARP]hoijui_g5> spring-multi-threaded
<[ARP]hoijui_g5> ?
<[RoX]Tobi> minus the second hyphen
<[ARP]hoijui_g5> ok
<zerver> spring-regular
<[ARP]hoijui_g5> hehe
<[ARP]hoijui_g5> no
<[ARP]hoijui_g5> ok that, Kloot?
<zerver> spring-plain-vanilla
<[ARP]hoijui_g5> spring-headless
<Kloot> I vote for spring----------------, spring-------------, and spring----------
<[ARP]hoijui_g5> spring-multithreaded
<Kloot> let the users guess
<[RoX]Tobi> ok, so conclusion is that descriptive names are better than 2 letter names?
<[RoX]Tobi> lol
<[ARP]hoijui_g5> mmm
<[ARP]hoijui_g5> .. ill change it then
<zerver> ms-dos can only handle 8 chars
<[ARP]hoijui_g5> next?
<zerver> so we need springmt.exe
<Kloot> spring-~
<zerver> we MUST support ms dos
<[ARP]hoijui_g5> if you make spring ms-dos compatible
<[ARP]hoijui_g5> we will change it back
<zerver> lol
Main points:
- Should spring-dedicated be renamed to spring-ds for consistency with spring-hl etc.? No, descriptive names are better in this case.
- spring-hl will be changed to spring-headless
- spring-mt will be changed to spring-multithreaded
<[ARP]hoijui_g5> this shoudl possibly be private.. no?
<[RoX]Tobi> possibly
<[RoX]Tobi> definitely that should be discussion with Licho also, imo
<[ARP]hoijui_g5> ahh yeah true :D
<[ARP]hoijui_g5> so we will do it afterwards.. or an other day?
<zerver> licho takes all the $$$ ?
<[ARP]hoijui_g5> yep
<zerver> kk
<[LCC]jK> it's more like: Licho fills the missing money from his own pocket
<zerver> i know
<[ARP]hoijui_g5> ok so.. lets stop this here :D
<[ARP]hoijui_g5> and maybe continue after meeting, if we can get licho to join
<[RoX]Tobi> k
Main points:
- This can not be discussed here.
<[ARP]hoijui_g5> yeah..
<[ARP]hoijui_g5> http://springrts.com:7778/waterfall
<[ARP]hoijui_g5> can we force OS X rebuilds with the buildbot?
<zerver> build failed ...
<[ARP]hoijui_g5> or could it be like the other slaves: auto building every commit (again)
<[ARP]hoijui_g5> yeah it failed but.. it did not try since ages
<[RoX]Tobi> not yet, I should implement auth at some point
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> i submitted possible fixes..
<[RoX]Tobi> will only start auto builds after it builds succesfully one time
<[RoX]Tobi> ok
<[ARP]hoijui_g5> was over a week ago, and i still dont know if it worked
<[ARP]hoijui_g5> mm ok
<[RoX]Tobi> ok I'll trigger build
<[ARP]hoijui_g5> thanks
<zerver> next?
<[ARP]hoijui_g5> yeah, ok for me
MT / LUA (ignore CPU load for users with a high LUA-DRAW % ?)
<zerver> i plan to send some profiler data from MT clients to the server
<zerver> just to make sure improperly set up MT clients dont slow down the game
<zerver> anyone against this?
<[RoX]Tobi> how do you know its misconfigured compared to just slow?
<zerver> profiler determines % of cpu spent on lua rendering
<[RoX]Tobi> ok, but that's just some, usually high, number
<zerver> yeah, if you have it enabled
<[RoX]Tobi> since without vsync spring keeps rendering as fast as possible and Lua usually eats most cpu there IIRC from profile data
<zerver> correct
<Kloot> the idea sounds wrong imo, server should determine its speed from client simulation rates alone
<Kloot> otherwise you mught as well start ignoring slow rendering st clients
<zerver> different situation
<[ARP]hoijui_g5> you want to auto kick mt clients that have rendering settings set wrong?
<zerver> MT has problems with LUA and im only trying to make sure it will not have negative effects on game play
<[ARP]hoijui_g5> it does soudn a bit wrong...
<[ARP]hoijui_g5> what about runnign a stress test lua widget
<zerver> yes, if they dont follow clear recommendations regarding LUA rendering, they might lag out
<[ARP]hoijui_g5> and if it gets slow, auto disable the slow stuff for that client?
<Kloot> besides even if you subtract the Lua cpu usage percentage, the client is still going to drop
<[ARP]hoijui_g5> i mean.. ther must be simpler/better solutions
<Kloot> or at least get very far behind
<zerver> the lua rendering cpu is zero if properly set up....
<[RoX]Tobi> can't the client determine this by itself? (i.e. does it need to be done in the server)
<[ARP]hoijui_g5> yeah that
<zerver> hmm
<zerver> the client can properly configure the MT, and there willl be no problems....
<[RoX]Tobi> otherwise I think it's ok to hint user in some way that he's using non-ideal configuration
<zerver> this im dong already, the profiler is flashing red
<zerver> *doing
<[RoX]Tobi> ah
<[ARP]hoijui_g5> and if he doesnt.. what about the Lua test widge/gadget idea?
<zerver> not sure how that would help
<[ARP]hoijui_g5> and auto disable bad stuff
<[LCC]jK> the engine doesn't know about `widgets`
<[ARP]hoijui_g5> we.. you coudl auto disconnect the client, eg
<[ARP]hoijui_g5> can a gadget/widget disconnect?
<zerver> widgets are hard yes
<zerver> well, if you dislike the idea, we skip it
<[ARP]hoijui_g5> ...
<[ARP]hoijui_g5> so my idea is bad?
<[ARP]hoijui_g5> is there no other way to solve it locally?
<[ARP]hoijui_g5> no ideas?
<zerver> but it should not make ppl drop unless they have lots of lua rendering enabled
<[RoX]Tobi> what would be the difference with enforce game speed on the server?
<zerver> difference is that only cpu of improperly set up MT clients is reduced/ignored
<zerver> MT is much more tolerant to high cpu than ST
<zerver> to play ST with 80% cpu is almost impossible
<zerver> MT can run smooth with 80% cpu
<zerver> and this makes me think dropping clients will not be a problem at all
<[RoX]Tobi> ok
<zerver> it is only a problem when you hit 100% :)
<zerver> network traffic would be unaffected for regular clients
<zerver> MT would send a special packet with profiler info every 2 secs or so
<[RoX]Tobi> what about somehow scaling cpu usage so it reflects % of what is actually possible in a better way?
<[RoX]Tobi> this sounds like for ST clients the cutoff for slowing down should be at e.g. 50% cpu usage and for MT at 80%, right?
<zerver> maybe
<zerver> but MT needs a steeper slowdown curve then
<zerver> because 100% is still a problem ofc
<zerver> anyway, this is doable if the server knows about client type
<zerver> it already does, though the version string
<zerver> I did not mean this would take all day
<zerver> shall I look at it, and if you don't like it we revert?
<[RoX]Tobi> my point was that client knows about client type too, and could possibly just send something like scaled cpu usage or maximum speed it thinks it can accept
<[RoX]Tobi> but maybe that's too big change
<[RoX]Tobi> that would be generic for all types of builds that would ever be made
<[RoX]Tobi> I'm also fine with what you suggested though, just giving some ideas
<zerver> yeah
<[RoX]Tobi> next point then?
<zerver> yup
Main points:
- There will be some experimental feature that discriminates ST and MT clients and tries to protect games against slowing down due to misconfigured MT clients.
<[RoX]Tobi> no changes since 2 weeks ago iirc
<zerver> k
<[RoX]Tobi> to be done is: auth for triggering builds and making source packages
Main points:
- No changes since last meeting
- To be done: auth, making source packages
<zerver> anyone on vacation next week ?
<[ARP]hoijui_g5> .. do we need auth for triggering builds?
<[ARP]hoijui_g5> old bb did not have it either.. was never a problem
<[RoX]Tobi> didn't plan any vacations yet next week
<[ARP]hoijui_g5> :D
<[LCC]jK> me neither
<[ARP]hoijui_g5> me neither..
<[RoX]Tobi> difference is that this is anoymous web interface and in lobby there always is/was some kind of social control
<[RoX]Tobi> ok, so next week same time same place
<[RoX]Tobi> then meeting is finished
Main points:
- Next meeting same time same place