=== Release plan ===
<[ARP]hoijui_g5> aehh release...
<[ARP]hoijui_g5> Kloot, you still want something in .7?
<abma_irc> hey!
<[ARP]hoijui_g5> we just started abma, nothing said so far
<Kloot> yes I do
<[ARP]hoijui_g5> does it have to do wiht the thing that was too slow?
<Kloot> yes, that
<[ARP]hoijui_g5> ok
<Kloot> I've an alternate fix for it in the works
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> did you also have a look at the last KAIK bug i reported?
<Kloot> only briefly, I assumed that assert triggered because a unit got blown off the map
<[ARP]hoijui_g5> mmm ok
<[ARP]hoijui_g5> shoudl we probably convert the asert to a warnign message then?
<Kloot> hmm
<Kloot> I'd rather not until I know if it's a more serious problem
<Kloot> s/if/that it is not
<[ARP]hoijui_g5> Tobi, stack-trace translator can not identify/parse the version number of builds of non-master branch, for example the infolog here: http://springrts.com/mantis/view.php?id=2219
<[ARP]hoijui_g5> [ 0] Spring 0.82+.6.1 ({0.82-branch}0.82.6.1-45-g79c95f5) has crashed.
<[ARP]hoijui_g5> ok Kloot
<[RoX]Tobi> hm
<zerver> .6 is working quite well i think, i don't have much to add
<[ARP]hoijui_g5> ok
<zerver> pathing could be better ofc
<[ARP]hoijui_g5> yeah.. Kloot changed quite soem pathing stuff for .7 already
<zerver> ok, nice
<[ARP]hoijui_g5> is in the release branch
<[ARP]hoijui_g5> next?
<zerver> and this bug where commander stops building if attacked is still there
<zerver> i'll try to pinpoint it
<[ARP]hoijui_g5> nice
<zerver> yeah, next
Conclusions:
There are some remaining issues before 0.82.7 release
=== Color.h, vecX<type>, System/, Util/, Util/Math/ ===
<[ARP]hoijui_g5> related to this discussion
<[ARP]hoijui_g5> https://github.com/spring/spring/commit ... 8#comments
<[ARP]hoijui_g5> basically: cleanup math stuff
<[ARP]hoijui_g5> inclusing floatX, matrixX, vecX(new) and ColorABC
<[ARP]hoijui_g5> suggested was, introducing a new "package" (System, Sim, Rendering, ...)
<[ARP]hoijui_g5> called Util
<[LCC]jK> I don't think that anyone really wants to reimplement those vector types atm
<[LCC]jK> still there is left the thing with moving all data primitives into a separate
<[LCC]jK> +dir
<[ARP]hoijui_g5> i think, we should discuss.plan hwo to do it now, then implement the base stuff, and possibly convert the some of the little used stuff to use it
<[ARP]hoijui_g5> somewhen in the futture.. or never, maybe convert float3 and other often used stuff
<[ARP]hoijui_g5> it woudl be good to do now, cause of hte new Color thing
<[ARP]hoijui_g5> as so far, it is used only in one place
<[ARP]hoijui_g5> Kloot suggested making templeated vecX<type> classes
<[ARP]hoijui_g5> hmm.
<[ARP]hoijui_g5> there seems to be little enhusiasm on this topic :D
<[ARP]hoijui_g5> hehe
<zerver> lol
<[LCC]jK> lol
<[ARP]hoijui_g5> sucker!
<zerver> i was reading the comments...
<Kloot> SL crashed
<[ARP]hoijui_g5> ok
<[LCC]jK> btw there is the problem with unions when adding a template based vector class
<[ARP]hoijui_g5> mm
<zerver> yeah, unions only allow simple types right?
<[ARP]hoijui_g5> i think he means, you can not inherit form a class
<[ARP]hoijui_g5> oh.. is the same :D
<zerver> yeah
<[ARP]hoijui_g5> coudl we somehow get the same functionality liek wiht unions?
<[LCC]jK> btw I always wanted to include http://glm.g-truc.net/
<[LCC]jK> it's a glsl-like mathlib for c++
<zerver> union is a base language construct, hard to replace with something higher level
<[ARP]hoijui_g5> but it is executed on CPU, right?
<[LCC]jK> so you can do things like vec4(vec3(0.0),1.0).bgra
<[LCC]jK> yeah, it runs on the CPU
<zerver> good, otherwise it may desync
<[ARP]hoijui_g5> yeah... how woudl that work wiht sync/sync-checking?
<[ARP]hoijui_g5> would we but that on top of it, where needed?
<[LCC]jK> from the tutorials I sa, OpenCL might be sync safe
<[LCC]jK> *saw
<[LCC]jK> but I didn't tested that yet
<[ARP]hoijui_g5> ok so.. the question is:
<[ARP]hoijui_g5> * union
<[ARP]hoijui_g5> * vecx<type>
<[ARP]hoijui_g5> * GML (if tests show its sync-safe)
<[ARP]hoijui_g5> yeah?
<zerver> GLM
<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> can a class inherit from a union?
<zerver> no
<zerver> or?
<[ARP]hoijui_g5> can a union be templated? :D
<[ARP]hoijui_g5> mm i guess that is hte same again
<[LCC]jK> inheriting and templates aren't the same
<Kloot> it isn't that big of a problem in this case
<Kloot> a union would be needed to represent a color as a uint32 or a vec4<char>
<Kloot> which would have the same size
<[LCC]jK> the best would be if float4 would allow rgba & xyzw indexing
<Kloot> or possibly some more specialized type like colorRGBA
<zerver> or a function that returns the type, GetAsVec4()
<zerver> it may bloat the code
<Kloot> yeah swizzling would be nicest
<zerver> question is if vecx actually improves code readability
<[LCC]jK> problem is that vec2 & vec4 are nearly not implemented atm
<Kloot> it would be easy to typedef some common instances like vec3<float>
<Kloot> as vec3f
<[LCC]jK> and there is/was no global used colorprimitive
<zerver> yeah, the code would otherwise become bigger and have more <> in it
<zerver> which is not very readable
<zerver> if anyone enjoys doing it, i have no objections
<[ARP]hoijui_g5> the reason to do it, is to have a common base, where to put util/helper functions, like .mult(x)?
<Kloot> eh, those helper functions would just be part of vecX :)
<[ARP]hoijui_g5> yeah thats what i mean
<[ARP]hoijui_g5> woudl not have to duplicate in color4 and float4, for example
<Kloot> indeed
<zerver> if u gonna tamper with floatX better merge all branches first :)
<Kloot> plan was to replace int2/float2/float4 first since those are not used much at all
<[ARP]hoijui_g5> yeah.. as said, flaot3 wont be touched of course (now), except we can make the change happen only in float3.h/.cpp
<[ARP]hoijui_g5> mm
<zerver> ok
<[RoX]Tobi> [ARP]hoijui_g5: do you have a 0.82-branch stacktrace nearby to test?
<[RoX]Tobi> [ARP]hoijui_g5: you can try it yourself if you want, it *should* work now
<[ARP]hoijui_g5> yes
<[ARP]hoijui_g5> ok..
<[ARP]hoijui_g5> http://springrts.com/mantis/view.php?id=2219
<[ARP]hoijui_g5> there is one in there.. i will try
<[RoX]Tobi> thanks
<[ARP]hoijui_g5> yyep, works!
<[ARP]hoijui_g5> nice one!
<zerver> quick and dirty fixes are always the best
<[ARP]hoijui_g5>
<zerver> if no one wants to comment, maybe proceed?
<[ARP]hoijui_g5> http://sl.pastebin.com/YFw3BcS9
<[ARP]hoijui_g5> tst.cpp
<[ARP]hoijui_g5> it compiles
<[ARP]hoijui_g5> is that of any use?
<[ARP]hoijui_g5> not nice to have rgba in vec4 of course :D
<[LCC]jK> problem is that it isn't modular anymore
<[ARP]hoijui_g5> mm :/
<[LCC]jK> you need to implement such a template for each single class
<[ARP]hoijui_g5> use GetR() GetG() ... functions in ColorRGBA : vec4<unsinged char> ?
<[ARP]hoijui_g5> hmm.. should we discuss this an other time?
<[ARP]hoijui_g5> looks like it woudl use too much time
<[RoX]Tobi> TBH I wouldn't do all too major rewrites since it's pretty bug free code at the moment afaik
<[ARP]hoijui_g5> and we still have other stuff
<[LCC]jK> I don't see that anyone wants to implement anything of these
<[ARP]hoijui_g5> yeah... rewrite is not hte main concern
<[LCC]jK> but moving the files in a separate dir is still valid
<[ARP]hoijui_g5> but to have the new Color thing be implemented as it should, before it is widely used
<[RoX]Tobi> yeah
<[ARP]hoijui_g5> ok.. in additiona to that, what shoudl we do wiht Color.h?
<[ARP]hoijui_g5> just not use anywhere?
<Kloot> +1
<[ARP]hoijui_g5> or make it a class, based ona a new vec4<type> class?
<[ARP]hoijui_g5> ok...
<[ARP]hoijui_g5> lets postphone it then
<[LCC]jK> there is no alternative for CColor atm :
<[LCC]jK> *:x
<[ARP]hoijui_g5> you mean SColor?
<[LCC]jK> erm SColor
<[ARP]hoijui_g5> still dont know why its S though its a union
<[ARP]hoijui_g5> casue it has a stucts? can be used as one?
<[LCC]jK> unions are structures afaik
<[ARP]hoijui_g5> ah
<[LCC]jK> but the diff between structure and class is just the default public/private thing
Conclusions:
OK to make a template class for Color etc, but not to be used for refactoring, since the current code is fairly bug free
=== rename master -> develop, make master the release branch? ===
<[ARP]hoijui_g5> inspired by http://nvie.com/posts/a-successful-git-branching-model/
<[ARP]hoijui_g5> would mean. we always push to develop branch
<[ARP]hoijui_g5> and master branch is the release branch
<[ARP]hoijui_g5> they also use more branches there.. which i think woudl not make sense for us
<[ARP]hoijui_g5> it is not a big change really
<abma_irc> hm... what does it improve?
<[ARP]hoijui_g5> main outcomes are: a user doing a simple git clone woudl get the release sources instead of current dev
<[ARP]hoijui_g5> the release branch alwyas has the same name
<[ARP]hoijui_g5> (master)
<zerver> more noob friendly?
<[ARP]hoijui_g5> which simplifies some scripts, and makes wiki maintenence simpler
<[RoX]Tobi> version numbers as we have them now would be non-existent though in develop
<[ARP]hoijui_g5> yeah.. i woudl say so
<[RoX]Tobi> since master is never merged to develop as far as I see
<abma_irc> that sounds better then just a rename
<[ARP]hoijui_g5> yes true
<[RoX]Tobi> other than that it sounds ok
<[RoX]Tobi> brb
<[ARP]hoijui_g5> woudl it have consequences to not have versions in develop?
<[ARP]hoijui_g5> looking at a git-describe in develop would not tell you much
<[ARP]hoijui_g5> though we seldomly use these for old commits
<[ARP]hoijui_g5> i came across this site by accident.. maybe there are ways that would fit us evne better... i did not search for them
<zerver> it should be fine i think
<zerver> as long as no one has to sit and determine what to merge into master
<[ARP]hoijui_g5> yeah.. someone has to do that, but that is the smae liek now
<zerver> not really
<[ARP]hoijui_g5> now its cherry picking "master -> 0.82-branch"
<zerver> the release branch we have now shall be deleted i assume
<[ARP]hoijui_g5> then it will be "develop -> master"
<zerver> once we move to 0.83
<[ARP]hoijui_g5> yes.. we woudl not have them anymore
<zerver> 0.83 = master
<[ARP]hoijui_g5> yep
<[ARP]hoijui_g5> all version tags would be on one branch, whihc is not the case now
<zerver> and there is no problem with merging the whole develop into master if you already cherry picked some stuff?
<[ARP]hoijui_g5> an alternative to the "develop & master" approach, is "master & release"
<[ARP]hoijui_g5> there coudl be merge conflicts
<[ARP]hoijui_g5> but thye are easy to solve
<[LCC]jK> using master for releases would be more noob safe
<[ARP]hoijui_g5> yeah
<zerver> i already pointed that out :)
<[ARP]hoijui_g5> :D
<[LCC]jK> we got a lot less-experienced linux users who try to compile spring themselves and always compile the development branch and wonder why things don't work
<[ARP]hoijui_g5> i never want to hear anybody say spring is not noob friendly! we so care for them
<[ARP]hoijui_g5> yeah true
<[ARP]hoijui_g5> though...
<[ARP]hoijui_g5> that would not entirely solve that problem
<Kloot> it is all documented
<Kloot> on the wiki
<[ARP]hoijui_g5> i mean.. the release branch (master) would now contian what we have in 0.82-branch, which does not sync wiht current release
<[LCC]jK> hmmm true
<zerver> that is a prob then
<[ARP]hoijui_g5> if we want the release branch to always sync with current release, we woudl need an extra branch
<zerver> so we have to make a temp branch...
<[ARP]hoijui_g5> like thier hotfix branch
<zerver> 82-branch is resurrected
<[ARP]hoijui_g5> no
<abma_irc> pre-release-branch
<[ARP]hoijui_g5> does not have to be temp
<[ARP]hoijui_g5> yeah... call it release, pre-release, fixes, ...
<[ARP]hoijui_g5> something
<zerver> pre-release, otherwise noobs may check that out instead
<zerver> so decide on this now or later?
<[ARP]hoijui_g5> i guess when Tobi is back
<[ARP]hoijui_g5> somewhen later in hte meeting
<[ARP]hoijui_g5> next?
Conclusions:
We will make master a release branch, so that noobs always check out a version that is valid for playing on the main server
== making shadow matrix linear (loss of quality in <2048 resolutions, but no distortions anymore, also faster) ==
<abma_irc> what means loss of quality?
<Kloot> aliasing
<Kloot> lots of i
<Kloot> t
<[ARP]hoijui_g5> can we see some screenshots?
<[ARP]hoijui_g5> maybe the game devs should have a say in this?
<[RoX]Tobi> uh I was back already, just didn't see anything I thought I needed to comment on :)
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> looks like jk is gone now :D
<[LCC]jK> re
<[LCC]jK> :)
<[LCC]jK> k then the matrix stuff now?
<[ARP]hoijui_g5> ok.. then lets stay with shadow
<[ARP]hoijui_g5> yep
<[LCC]jK> You all may known that the current shadow matrix is non-linear
<[LCC]jK> causing ugly misplaced shadows if the polygons are too large
<abma_irc> aaah, ok
<[LCC]jK> (visible on s44 bunkers etc.)
<[LCC]jK> http://home.arcor.de/jkei/s44_shaders_thumb.jpg
<[ARP]hoijui_g5> ahhhh
<[LCC]jK> so, this would get fixed with a linear shadow matrix and it is even possible w/o breaking backward compability (by changing p17 & p18)
<[LCC]jK> the only negative is that it reduce the quality of lowres shadowmaps
<[ARP]hoijui_g5> the edges of shadows would look pixelated?
<[LCC]jK> yup
<[ARP]hoijui_g5> ok.
<[LCC]jK> extremely blurred
<Kloot> and highres shadowmaps would be slower again
<[LCC]jK> not here
<[ARP]hoijui_g5> what defines the shadow map size? the unit model the map?
<Kloot> especially in shadows 1 mode
<[LCC]jK> for me there was never a difference in FPS for 1024 versus 2048 shadowmaps
<[ARP]hoijui_g5> ah.. its a user setting? spring settings?
<zerver> springsetting
<[ARP]hoijui_g5> ok
<abma_irc> hm... high-quality looks better (no misplaced shadows) and low quality looks more ugly but is faster?
<Kloot> also people would just start complaining about aliasing since it'd be a lot more visible than the nonlinear distortions
<[LCC]jK> also having a linear shadowmatrix would allow to use the normal terrain-renderer with LODing, and so reduce the CPU load
<[ARP]hoijui_g5> well. blurred does nto sound as bad as pixelated to me
<[LCC]jK> and the shaders would even be faster (no sqrt needed anymore)
<[LCC]jK> so in the end it would speedup shadow rendering
<[LCC]jK> it just makes the 1024 shadowmap size .. unusable
<[ARP]hoijui_g5> is it possible to have it as a setting?
<[ARP]hoijui_g5> to choose between the two methods
<[LCC]jK> it is, but then the optimization couldn't be done
<[ARP]hoijui_g5> ah :/
<Kloot> yes it could (#ifdef'ed glsl)
<[ARP]hoijui_g5> i mean.. springsetings
<zerver> Do like PathFinder sharing common interface :)
<[ARP]hoijui_g5> hehe :D
<[LCC]jK> shadow rendering isn't isolated as pathfinder
<[ARP]hoijui_g5> sounds like overkill
<[ARP]hoijui_g5> well.. i cant vote on that
<[ARP]hoijui_g5> maybe do some tests on different hardware?
<[ARP]hoijui_g5> coudl put it into the release branch right after .7
<[ARP]hoijui_g5> or even in a ,7.1 release
<[ARP]hoijui_g5> ti get some test coverage
<[ARP]hoijui_g5> it*
<[ARP]hoijui_g5> or is it too much work to be only possibly accepted?
<[ARP]hoijui_g5> should we just have a vote now?
<[LCC]jK> it's a 4 lines change
<[ARP]hoijui_g5> ah ok
<[LCC]jK> later optimizations are much larger, but switching to a linear matrix is easy
<[ARP]hoijui_g5> so getting some testing before putting it in a require release woudl be good, yeah?
<[ARP]hoijui_g5> ah ok
<zerver> check end user acceptance before optimizing
<abma_irc> then put the 4 lines in the release and get some feedback?
<[ARP]hoijui_g5> anyone agasint that?
<zerver> i dont use shadows
<Kloot> I can see the shitstorm already
<[ARP]hoijui_g5> what is hte default shadow map size?
<Kloot> #define DEFAULT_SHADOWMAPSIZE 2048
<[ARP]hoijui_g5> ok...
<[ARP]hoijui_g5> cant see there beeing much problem then
<[ARP]hoijui_g5> this combined with most people not using minor releases...
<[ARP]hoijui_g5> patch-releases*
<Kloot> with a linear projection that number would have to be doubled imo
<Kloot> to satisfy people's "perceptions"
<[ARP]hoijui_g5> mmm
<[ARP]hoijui_g5> so what?
<[ARP]hoijui_g5> jk?
<[ARP]hoijui_g5> is it ok to put it in a patch release?
<[ARP]hoijui_g5> or what would you preffer?
Conclusions:
Implement linear shadow map, wait for end-user input, if OK, proceed with further optimization
=== streflop::sqrt ===
<zerver> yeah
<[LCC]jK> I will commit and Kloot can see
<[ARP]hoijui_g5> ok
<zerver> i remember back long ago someone did some profiling and streflop::sqrt was 25% of cpu
<zerver> now with SSE and stuff, has that changed?
<[ARP]hoijui_g5> i am on the way to get profling going, wiht BDs help
<zerver> in other words, is sqrt still emulated using integer math? does anyone know?
<Kloot> no, that is the fastmath sqrt
<zerver> eh? emulation is not fast
<Kloot> sqrt_nosse to be precise
<zerver> ok, so the performance problem disappeared when SSE was introduced?
<[LCC]jK> yup
<zerver> good
<zerver> next
<[LCC]jK> IIRC SSE is 20x faster than streflop
<zerver> oh sure
Conclusions:
zerver now knows that streflop::sqrt is fast with SSE
== switch wiki to a default style? ==
<[ARP]hoijui_g5> yeah.. i have listed my arguments in the etherpad
<[ARP]hoijui_g5> *
<[ARP]hoijui_g5> * less glitches
<[ARP]hoijui_g5> * ugly colors
<[ARP]hoijui_g5> * background similar to foreground
<[ARP]hoijui_g5> * less manual color-coding required
<[ARP]hoijui_g5> * people would probably realise that it is a wiki
<[ARP]hoijui_g5> * as it is an engine project site (not game), we are no frontend to the user/player -> no need to have a cool/nice style
<[LCC]jK> what do you mean with default style?
<[ARP]hoijui_g5> black on white
<[LCC]jK> the wiki is still implemented on the spring website
<[ARP]hoijui_g5> like wikipedia
<zerver> ugh... my eyes hurt
<zerver> im a white on black person, to 100%
<[ARP]hoijui_g5> i hate how .. for example code stuff works now
<[LCC]jK> green/yellow on blck here :D
<[ARP]hoijui_g5> i preffer light green on dark green
<[ARP]hoijui_g5> but i cant see why we should care for style
<[LCC]jK> the current code-syntax is because of flexibility ...
<[ARP]hoijui_g5> i jsut though.. the defautl style must have everythign ready
<[ARP]hoijui_g5> hm?
<[ARP]hoijui_g5> we have no syntax coloring
<zerver> prefer is spelled with one f
<[ARP]hoijui_g5> nothign automatic at least
<zerver> fyi
<[ARP]hoijui_g5> :D
<zerver> ich preffer pfeffer und michelle pfeiffer
<[LCC]jK> syntax coloring ...
<[ARP]hoijui_g5> and when you use <code> or <code><pre> it has different colors
<[ARP]hoijui_g5> it looks different on different browsers
<[LCC]jK> code w/o pre is used for inline code declaration
<[LCC]jK> ppl just don't get it ...
<[LCC]jK> e.g. "open <code>rts/System/float3.h</code> and edit line 30 ..."
<[ARP]hoijui_g5> .. .. so?
<[ARP]hoijui_g5> why shoudl it have a differtn color then the other code?
<[ARP]hoijui_g5> with pre, the code has hte smae color as normal text, just a slightly differnt font (hardly noticeable on my browser
<[ARP]hoijui_g5> but well.. looks like nobody else woudl liek to change, so next...
<[ARP]hoijui_g5> .. lets do the wvote for git branch changing now
<[ARP]hoijui_g5> 1. keep as is
<[LCC]jK> your browser is broken
<zerver>
<[ARP]hoijui_g5> 2. master = release branch, develop = what is now master
<[ARP]hoijui_g5> 3. like 2. but wiht an additional pre-release branch (so master woudl always be in sync with current release)
<abma_irc> hmm.. IMHO 2. looks like no real improvement
<zerver> yeah, anything but 2
<zerver> 3 will mean some initial confusion, as always
<[ARP]hoijui_g5> 2 is still an improvement, cause the release branch is always the same, and all version tags are on a single branch, and current release candaidate is alwasy there
<abma_irc> 3. means also to get rid of 0.8X-branches?
<[ARP]hoijui_g5> les maintenence, eg on wiki
<[LCC]jK> http://home.arcor.de/jk3064/wikicodepre.png
<[ARP]hoijui_g5> yes, no temp release branches anymore, neihter wiht 2 nor 3
<[ARP]hoijui_g5> hmm ok jk... thats how it looks in konqueror here too, but not in firefox
<[LCC]jK> firefox is broken then
<[ARP]hoijui_g5> is syntax coloring possible in wiki?
<[ARP]hoijui_g5> mm ok
<[LCC]jK> the css isn't even very special for this
<[LCC]jK> so it is a clear bug
<[LCC]jK> and not a missing ccs3 thingy or something like that
<[ARP]hoijui_g5> mm .. especially that it does not even get the color right
<abma_irc> hmm... the springrts page has many html-syntax errors...
<[ARP]hoijui_g5> ok so.. cna we vote on the git change?
<[ARP]hoijui_g5> +1 on 3
<[ARP]hoijui_g5> or are there more questions?
<abma_irc> [RoX]Tobi: does this break many stuff on the buildbot/translate stuff?
<[RoX]Tobi> good point
<zerver> will there be more merging work?
<[ARP]hoijui_g5> no, not more
<zerver> im ok with 3 then
<[ARP]hoijui_g5> at every mayor release, you will merge develop into master
<zerver> just make sure all commiters know to reduce the confusion
<[RoX]Tobi> I don't really know right now, I guess it will break everything but I think most things should be easy to fix
<[ARP]hoijui_g5> if there are conflicts, you simply replace the whole repoof master with what is in develop, and commit that (can be automated with one or two commands)
<[ARP]hoijui_g5> so what?
<[ARP]hoijui_g5> you want to decide it next time?>
<[ARP]hoijui_g5> jk, kloot?
<[ARP]hoijui_g5> i guess we will have the other change ready before next mayor release too
<[LCC]jK> +1 for a 3 branched system
<[ARP]hoijui_g5> versions beeing only tracked in git tags
<abma_irc> +1
<Kloot> I vote blank on this, don't see clear advantages or disadvantages yet
<[ARP]hoijui_g5> i guess i can do the buildbot related changes too, now that i have access there
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> so.. i note it down as accepted.. but will not wokr on it until the AI interface binary version check is done, and will probably also try the version-as-git-tag-only thing before that
<[ARP]hoijui_g5> or say.. it can not be done before the mayor release anyway
<[ARP]hoijui_g5> next thing..
<[ARP]hoijui_g5> Licho asked for a change in the installer
<[ARP]hoijui_g5> as it is now, the exe installed for ZeroK lobby is only an installer/downloader
<[LCC]jK> btw here a comparision between linear & non-linear http://home.arcor.de/jk3064/shadowmatrix.png http://home.arcor.de/jk3064/shadowmatrix2048.png
<[ARP]hoijui_g5> it has a generic installer icon, and when executed for the first time, will show a message like: "this exe is unverified, woudl you really like to proceed?"
<[ARP]hoijui_g5> if oyu click on yes, it will downlaod latest zeroK lobby, and the icon on the desktop changes to the ZeroK one
<[ARP]hoijui_g5> now...
<[ARP]hoijui_g5> Licho wants the installer to execute the exe right when install is finnished/it was copied ot the install dir
<[ARP]hoijui_g5> so the user will never see the ugly instalelr icon on his desktop
<[LCC]jK> add a "run XYZ" checkbox at the end of the installer?
<[ARP]hoijui_g5> what i kind of disklike is, that we execute .. kind of a 3rd party exe, we downloaded from a URL behind the scenes
<[ARP]hoijui_g5> yeah... sounds better
<[ARP]hoijui_g5> is it defautl on or off? :D
<[ARP]hoijui_g5> on i guess
<[ARP]hoijui_g5> Licho siad, he is not 3rd party
<[ARP]hoijui_g5> and the exe will never change.. we could md5 check it before inclusion
<[ARP]hoijui_g5> so.. checkbox at last screen, default on?
<[ARP]hoijui_g5> any objections?
<[LCC]jK> yup
<[LCC]jK> no objections
<zerver> lol
Conclusions:
Keep current wiki style
== Next meeting ==
<[RoX]Tobi> side note: actually the site is completely broken (as abma said already). until the site validates fine you can't judge browsers based on it
<[RoX]Tobi> same date/time/place is fine for me
<abma_irc> for me it is fine, too
<[LCC]jK> fine
<zerver> same here
<Kloot> same
<zerver> plz test luasplit and tell me what the problems are until next meeting
<[ARP]hoijui_g5> here too
<zerver> you can change the splitting mode via MultiThreadLua in springsettings
Conclusions:
Next meeting same time and day
== Anything else? (WVTTK) ==
<abma_irc> what about an mod, that (nearly) always work with the develop-branch?
<zerver> NullMod
<abma_irc> imho, currently every developer has an .sdd to test stuff
<abma_irc> it should be an full-featured mod, like ba/ca/1944...
<abma_irc> for example, current master + ba doesn't work, because the spawning of units changed
<abma_irc> make an mutator that fixes that problems on github?
<abma_irc> this would also allow to generate an real .zip from this directory for other users, to test current master for example
<abma_irc> ehm, develop-branch :)
<abma_irc> just an idea...
<[ARP]hoijui_g5> yeah.. i am sure nobody here has somethign agasint that
<Kloot> will you be maintaining this mutator on every engine change? :
<[ARP]hoijui_g5> just have to ask the author of the mod you want to use for it
<Kloot> engine/lua*
<[ARP]hoijui_g5> woudl be good if the dev that makes the change in the engine, that requires a change in the mods also makes that in the mutator
<abma_irc> best would be, if the author of the mod would maintain it
<[ARP]hoijui_g5> we would also have a perfect reference then
<abma_irc> ...or so, that would be better
<abma_irc> what mod do you prefer?
<abma_irc> for such stuff
<abma_irc> imho ca is the mod that uses most features
<[RoX]Tobi> it seems to me what would work best is a kind of repo (not necessarily in the VCS kind of way) where we can easily share any fixed mod
<[RoX]Tobi> (as opposed to picking a single mod)
<[RoX]Tobi> also, not maintained, but only updated when the need arises
<[RoX]Tobi> for example: I try to fix bug X in Spring that occurs with game Y, but first I need to patch game Y to run with master. Then I share somehow this patched game Y with other devs so that if they want to fix a bug in game Y too they don't need to patch it themselves.
<abma_irc> is a mutator enough to fix all problems in a mod?
<[RoX]Tobi> pretty much yeah
<[RoX]Tobi> only not if a file may not exist for a game to work
<[RoX]Tobi> as you can't "delete" files using a mutator
<abma_irc> ok...
<[RoX]Tobi> but don't listen too much to my opinion as I probably won't have any significant time to work on Spring in the near future..
<[RoX]Tobi> three words that come up to me when thinking about a solution to this problem are: shared dropbox account
<abma_irc> my personal problem in this case is, that i've an very slow upstream...
<abma_irc> [LCC]jK: can't say if that would be an problem for other users
<abma_irc> for me the screenshots look fine, but i play always with low settings...
<[RoX]Tobi> from what I've heard dropbox is pretty good at transferring only what is really needed, but I have not tried it myself
<[RoX]Tobi> I'm off, laters
<abma_irc> good night! :)
<[ARP]hoijui_g5> with Tobis method.. that woudl mean...
<[ARP]hoijui_g5> if you change somethign that needs changes in mods
<[ARP]hoijui_g5> all mod devs come yelling at you to fix it for thier mod
<[ARP]hoijui_g5> and ... well i woudl not want that
<abma_irc> i don't want to do that, too
<abma_irc> its for testing, not for fixing
<[ARP]hoijui_g5> yeah..
<[ARP]hoijui_g5> i think it woudl be good to stick to a single mod
