Present: zerver, jK, Kloot, hoijui, Tobi, abma
Welcome
<abma>hey! :)
<hoijui>hello
<abma>hm, what about librocket?
<abma>anything to discuss there now or just continue discussion in forum?
<hoijui>i say forum only
<abma>ok
<zerver>I have no opinion as long as it does not bloat the engine code
<hoijui>nothing has changed since last week really
Release plan
<abma>as you maybe have seen, i've added a reg key to installer... the springlobby guys hopefully will use it soon
<zerver>nice
<abma>hm, the online-installer should work, i update it from time to time...
<abma>hm
<zerver>So, when do we make a test release?
<hoijui>or who will do it?
<abma>hm, thats the only "problem"
<zerver>:)
<abma>the online-installer can be used as it is, nothing to do there... only "problem" is, that it uses springrts.com for downloads
<abma>so.. thats not good for high traffic
<hoijui>the actual releasing process is not too muhc work, and quite well documented, and also largely automated with scripts
<zerver>I just need to know beforehand because MT branch contains many fixes, need to be merged
<hoijui>the problem is just, rebasing/cherry picking stuff
<hoijui>which was a nightmare already when i (and Kloot) stopped doing it.. 2 months ago or so
<jK>in ~1 week the new widgethandler is finished
<abma>hm, i thought, we are talking about make a release from master-branch?
<zerver>yes, from master
<jK>master this contains a lot of problems
<hoijui>yeah
<jK>so it would be a dev only release (so modders check it for unknownbugs)
<abma>so, cherry-picking is currently not needeed... just if we only allow bugfixes after release
<hoijui>if you do not want a 0.82 release anymore.. there is no reason to discuss details of the next release yet
<hoijui>except if you want a feature freeze
<hoijui>but i would not even do that yet
[ARP]hoijui_g5 [LCC]jK [RoX]Tobi
<abma>hm.. no feature freeze now
<zerver>okay, no need to rush it
<abma>a test-release would be good, as some things will make current mods not working
<abma>for example the commit, that disallows some files in .7z archvies to be solid
<abma>afaik solid is default in 7z archives...
<hoijui>a good thing would be multi version support in the lobby protocol
<hoijui>yeah.. but i think none of all the archives i have fails there.. i think there was only one, which got a new version that fixed it already
<hoijui>or say.. i dont expect much problems there
<abma>ok
<abma>hm, sounds a bit like no test-release, as there is some stuff waiting for merge
<zerver>so, should we set a target date for test release?
<hoijui>i woudl say, we should focus on stuff that we really need before a new release.
<hoijui>the multi version support in lobby protocol.. it woudl come in really handy in the transition.
<hoijui>also the new branching model and new way of incorporating the version in the binary, which we discussed in one meeting
<hoijui>(later is my duty)
<hoijui>and.. i dont know what you others want
<abma>hm, multi-version support in lobby protocol is stuff that isn't stuff of the engine
<jK>yeah they (lobbydevs) really need to discuss these things more
<hoijui>yeah true.. we cant influence it directly
<abma>changing branching could be done after a release, as it shouldn't affect source code
<hoijui>it is pretty much decided
<hoijui>aegis will implement it, then it will be discussed and changed maybe (thats how i remember it)
<zerver>maybe there are features that would be really good to have in 0.83, but it all comes down to if someone is willing to implement it
<abma>hm, i think a must-have is what licho said
<abma>http://springrts.com/mantis/view.php?id=2268
<abma>as afaik springlobby guys work on missions, too
<abma>(support for it, koshis sasi branch)
<hoijui>"Make map/mod hash not depend on springcontent so it does not change with spring versions. "
<hoijui>yeah..that woudl be good, but i think nobody is working on that
<abma>hm, a solution would be, to create versioned spring-content and release that without the engine?
<zerver>but springcontent is too closely linked to engine version
<zerver>shaders etc
<hoijui>hmm...
<hoijui>then again.. maybe it woudl be really little work
<hoijui>as koshi added two unitsync functions to get the checksums of single archives
<hoijui>so we only have to change the code that checks hte checksum internally
<hoijui>maybe we allow both checksums for a while
<hoijui>is there a potential problem with that?
<hoijui>checksums for dependencies will have to be in script.txt too, for checking, when using the single archive checksum?
<jK>I think Licho wished that the checksum checking is done at runtime when the clients are connecting to the server
<jK>so the server/host gets all checksums and majority is the correct one then
<jK>no checksum needed in the script.txt
<zerver>and server needs no maps/mods
<hoijui>that seems to be the first solution in this requrest
<hoijui>aehm...
<hoijui>that is, when the clients are entering the battle
<hoijui>not when the game is starting
<hoijui>right?
<hoijui>so in the engine, we woudl still do the version checking as usualy
<abma> http://springrts.com/phpbb/viewtopic.ph ... 15#p477315 point 2)
<hoijui>i mean.. when the game is starting, the host already knows the checksum of the mayority of players, and can write it into script.txt
<hoijui>hmm.. yeha it sounds like he suggests the engine should do that, while i think the lobbies should.
<hoijui>makes no sense to start the game wiht 16 players, to find out that 4 of them have other content later on
<hoijui>so you have to re
<zerver>y
<abma>yes, sounds like lobby-stuff...
<hoijui>is that a "why?" or a "yes!" ?
<zerver>yes
<hoijui>maybe licho does not want it in the lobby cause it needs a change in the protocol.. which is slower then a change in the engine
<hoijui>ok
<Tobi>it's also an engine thing in that checksum must be written in the script by the host now
<Tobi>which isn't practical in the case of dedicated servers which don't have the content
<Tobi>for that this majority vote would be a solution
<hoijui>do you mean, autohosts which dont have the content?
<Tobi>yeah
<hoijui>ok..
<hoijui>yeah they would get the checksum from the mayority
<hoijui>broadcast it to al clients in the battle whenever it changes/when they enter
<hoijui>so sync is visible in the lobby already
<zerver>dedicated server w/o need for maps and mods would be huge improvement
<hoijui>and when the game starts, the autohost knows the checksum (without having the content) and can write it to script.txt
<abma>that should work...
<abma>next point? (hopefully licho + others agree)
<hoijui>yeah next
main points:
* we will make soon a test release (online installer should already work)
* hoijui will merge assimp
* zerver has some fixes for MT in his branch
* it should be possible to run dedicated server which knows no checksums with extending/modifying lobby protocol - koshi also added functions to calculate checksums of archives without depends
where to discuss developement of lobby-protocol, file distribution (springfiles, rapid, plasma)?
<abma>imo there is currently no central place
<abma>my suggestion is, to make a subforum "Infrastructure"
<abma>i know, we have already tons of subforums :-/
<abma>but this grouping is really missing
<zerver>Maybe call them Engine Development, Non-engine Development
<Tobi>non-engine dev is very wide
<hoijui>that would include too much
<abma>ai/lua is non-engine
<hoijui>map, mod, models
<zerver>ok, but split the development forums nevertheless
<zerver>start by renaming it ti Engine Development, then add the other needed XXX Development
<hoijui>[Game Lobby] - [Misc Development]?
<hoijui>or rather [protocol+server development]?
<abma>please not misc
<abma>protocol + server sounds better
<hoijui>we vote pro/contra that?
<zerver>y
<Tobi>tbh infra seemed a better fit for what is missing as I understood it
<zerver>+1
<abma>imo the devs of lobby clients/server/file distribution need a forum as this programs interact with each other
<Tobi>as I understood it should also be a place for file site discussion etc.
<zerver>Infrastructure Development
<hoijui>[Game Lobby] - [Infrastructure Development]?
<zerver>:)
<hoijui>ok
<hoijui>fine with me
<abma>+1 for Infrastructure Development (ok it is similar to my suggestion...)
<abma>and...the "implementation ideas by developers for new developers" subforum is on the wishlist as well :)
<zerver>To do proper Infrastructure Development, you need a Development Infrastructure
<hoijui>
<Tobi>I suppose we could resurrect that gsoc idea forum of a while ago for this
<hoijui>[Development] - [Infrastructure Development] makes more sense of course.. which is also what you were thinking about, i guess :D
<abma>[RoX]Tobi: yep, the gsoc forum would be good for that, maybe rename it?
<Tobi>yeah
<hoijui>so... abma.. will do handle the details with neddie? or will you do this, Tobi?
<abma>with the details i can help
<Tobi>I had the intention to just change it but I suppose it may be good to shortly discuss it with neddie
<hoijui>next?
<zerver>y
<abma>y
main points:
* tobi will talk with neddie and then create the subforum Infrastructure developement (for devs to discuss lobby protocol, rapid/plasma, springfiles.com discussions) + reactivate the GSoC proposals forum
Anything Else?
<hoijui>zerver.. why did you add this gml.h and myGL.h includes?
<abma>[LCC]jK: about that: http://springrts.com/mantis/view.php?id=2390 can we disable glPointSize?
<zerver>because MSVC behaves real strange
<hoijui>so you add ugly stuff to spring code?
<hoijui>we want to separate sim and rendering.. and you add links again
<hoijui>if the other compielrs do not need that.. i cant imagine this is the propper solution
<zerver>root cause was the GML_ENABLE_SIM was undefined
<zerver>and MSVC seems to silently ignore that at times
<hoijui>mmmm
<jK>sorry, I dislike the idea to disable/remove engine functionalities cause of BUGS in ati's drivers
<Tobi>tried clean rebuild?
<hoijui>so it silently defines it?
<jK>ATi supports pointsizes != 1 !
<jK>only their drivers are totally BUGGED
<abma>[LCC]jK: i dislike that, too, but it looks like lua-devs avoid this call because of this
<jK>if you want to fix it write spam mails @ their dev support
<hoijui>what about just adding a warnign to the documentation for that function? or do we not have a documentation for it?
<hoijui>(guess not.. as it is OpenGL)
<abma>[LCC]jK: hm, i'm bad in opengl, but the docs suggest to use something like glGet (POINT_SIZE_RANGE) and use only values in this range
<abma>and i saw no code in spring that does that
<jK>abma THEY SUPPORT POINTSIZES UNEQUAL 1.0!
<jK>AND EVEN IF THEY WOULDN'T, THEY SHOULDN'T DO WHAT THEY DO KNOW!
<jK>it is a BUG, nothing else
<jK>it is not explainable in opengl specs!
<hoijui>we coudl add a feature to the installer
<hoijui>[x] send hate mail to ATI
<abma>:D
<abma>[LCC]jK: where is a good place to add a fat warning about that bug?
<abma>i hate the ati-bugs, too, but its really anoying if we know that bug and some lua-devs fall into it, because they don't know it
<abma>+ they/we waste time because of it :-/
<jK>I won't start avoiding function calls just because specific ati driver version fail at it
<jK>if we would do so, we couldn't use any!
<hoijui>yeah... i cant see where a warning woudl be good
<hoijui>except in the docu (which is OpenGL, so we can not add it there)
<hoijui>when executing the fucntion.. is not good, because it would be the smae like deprecating the function
<hoijui>zerver... will you revert these changes and search a better solution?
<abma>[LCC]jK: ok :-/
<jK>I always wished there would be a generic OpenGL driver bug database (for ATi _and_ NV), but I would wonder how long it would take until you get a mail by their lawyers
<zerver>i can remove GML_ENABLE_SIM later, after I have merged MT
<zerver>but for now this is needed
<jK>gl.h in unit.h isn't needed at all
<zerver>no, but the GML_ENABLE_SIM must be defined
<abma>zerver: then please make a big //FIXME TODO remove this include
<jK>then separate it into a diff header?
<Tobi>we need a config.h for a long time anyway
<Tobi>could be a good time to add it
<hoijui>and dont start to use "-" commit messages please
[ARP]hoijui_g5 [LCC]jK [RoX]Tobi
<Tobi>so compiled commandline doesn't need 500 -Dblablabla=foo args
<Tobi>*compiler
<hoijui>config.h woudl contain different defines?
<Tobi>it's the standard way how autotools based projects do config afaik
<hoijui>ah... that woudl be an unversioned file, created by the build system?
<abma>[RoX]Tobi: is pandoc missing on the buildbot?
<Tobi>generate a config.h that contains #define FOO #define BLAH etc.
<zerver>the problem I had with MSVC was that different classes saw different versions of the CUnit class, because GML_ENABLE_SIM was defined during some includes, and undefined during others
<jK>don't see a reason for something like that, I assume it would even be more complicated with cmake
<zerver>very dangerous, and led to memory corruption
<hoijui>yeah .. i also do not see the pro in that
<jK>@zerver: make a new gml header w/o gl.h
<zerver>yes
<hoijui>may make sense with autotools, but not so much here
<jK>including gl.h cause of GML_ENABLE_SIM is insane
<hoijui>+1
<zerver>but better than memory corruption
<hoijui>the most ugly hack is not right just becuase it prevents one bad thing
<hoijui>its like killing all humans for the suffering to end
<zerver>anyway, it is weird that MSVC can silently accept an #if XXX statement, if XXX is undefined
<Tobi>abma_irc: quite probably
<Tobi>installed now
<hoijui>zerver, maybe that is because it is #if, instead of #ifdef
<hoijui>?
<zerver>no
<zerver>#if UNDEF_VARIABLE shall generate an error
<zerver>as opposed to #ifdef UNDEF_VARIABLE
<hoijui>yeah would be good i guess
<zerver>btw, if anyone finds MT bugs, don't try to fix them, because there is big chance it is already fixed in the MT branch
<abma>[RoX]Tobi: thx
<abma>[LCC]jK: maybe thats interesting? http://www.kludx.com/capability.php?capability=412
<abma>(list of GL_SMOOTH_POINT_SIZE_RANGE)
<jK>I know those sites
<jK>but as you see your assumption that it would be a problem with GL_SMOOTH_POINT_SIZE_RANGE is incorrect
<jK>even in opengl3 it supports size!=1.0 (the gl3 specs only define ==1.0)
<abma>my range was a wild guess
<abma>0.1 is != 1.0
<jK>you can only make vague assumptions what is failing in their drivers (memcorruption, incorrect bit handling, incorrect uploading to the gpu, ...)
<abma>i hope the opensource drivers are ready soon :-/
<jK>blame them for not checking their drivers before releasing them
<jK>even the stuff they are working on is unchecked
<jK>see here: http://www.geeks3d.com/20110119/tested- ... ly-broken/
<jK>they even noticed the speedup! but didn't spend a second to watch on their screens!
<jK>ATi just such a crap!
<abma>:D
<abma>yeah, blank screen.. 1000 fps :D
<jK>(note that bug was in a driver they wanted to release A WEEK LATER!)
<abma>ouch
main points:
* ati opengl drivers are buggy :-/ (avoid glPointSize if you don't want to trigger an ATI-bug)
* a config.h seems to make no sense with cmake
* don't fix MT bugs it may be already fixed in zervers branch
* please annoy ATI about their bad opengl-drivers
