== Release plan ==
<abma> nothing really new about that... my online-installer should work but it needs more testing
<abma> + it is currently unusable for stable releases / many downloads as mirrors can't be used yet
<zerver> so when do we release?
<zerver> i suggest before the summer vacations
<abma> this is in august?
<abma> with release, we speak about a beta/test-release from master?
<zerver> no, a real 0.83
<zerver> in most european countries, july I think
<zerver> or august
<zerver> so a release in may-jun
<abma> we could try that.. but before that, i think we should do some test-releases?
<zerver> definitely
<abma> ok
== planed folder-structure for a installed spring? (partly needed for online installer) ==
<zerver> this need more discussion i guess
<abma> hm, i should have named this topic a bit different
<abma> is it possible with the current engine to install multiple versions? if so.. how?
<zerver> just use a different install folder
<abma> yes, sure.. is it enough to install it in something like this: spring\0.82.3 spring\0.82.4 ?
<zerver> y
<zerver> problem is lobby support, settings and such
<abma> does that make sense + will it fit in future versions? (with a loader for example...)
<zerver> for the different engine versions, i suggest to allow any naming of the folder
<hoijui> no, does nto make sense there, i think
<hoijui> aeehh...
<zerver> the lanucher should just iterate the subfolders and grab version from the unitsync.dll
<hoijui> well yeah like that it would make sense, but what people do now, is : C:/Program Files/Spring_verxion/
<zerver> but that can be changed
<zerver> just have to make people understand that if they do that, they have no multi version support
<hoijui> to have multi version support, the user woudl install to C:/Program Files/Spring/ and the required version folder stucture would be created there
<hoijui> yeah
<hoijui> that whould be done by the installer (eg, it would pick up folder where spring is already installed, and suggeast installign there)
<abma> ok
<hoijui> the question here is, whihc structure woudl we use:
<hoijui> spring/version/unitsync
<hoijui> spring/version/engine
<hoijui> or:
<hoijui> spring/unitsync/version
<hoijui> spring/engine/version
<hoijui> theres more then unitsync and engine that would be versioned of course
<zerver> definitely just one "version" folder imo
<abma> hm, this both won't work currently
<hoijui> its not one version fodler
<hoijui> version is a placehodler
<hoijui> sorry.. did not make that clear
<zerver> but like i said, version folder should be allowed to have any name
<hoijui> no
<hoijui> the sprign fodler can have any name
<hoijui> not hte version one
<hoijui> that one is created by the installer
<zerver> why not?
<hoijui> it makes no sense
<abma> user selects to install into c:\games\blabla
<jk> and it wouldn't be any problem code wise. so why limit it to specific namings?
<abma> installer creates blabla\version ...
<hoijui> the first proposal would be backwards compatible, no? why not, abma?
<zerver> particularly if we would change the version numberings at some point, it would suck to have limited naming scheme
<hoijui> dir-name == version
<abma> zerver: +1 for that, that lobbies should search all subfolders
<hoijui> whaat??
<abma> but... the installer has to put it into a subfolder, and the subfolder needs a name?
<abma> or i didn't understand what you mean
<zerver> no, lobbies only invoke unitsync, which in turn scans all subfolders
<hoijui> yeah that
<hoijui> but no
<hoijui> it shoudl not scan all fodlers
<hoijui> well.. nto the contents of fodlers
<hoijui> jsut the fodlers
<hoijui> solders
<hoijui> DAMN!
<zerver> lol, it should scan one level down, and look for the unitsync.dll found there
<jk> why do you guys start the discussion again from zero?
<zerver> did we?
<hoijui> yeah.. what we need to discuss is only which one of the two structures i described shoudl be used
<jk> we already discussed this
<hoijui> not the folder sturcture, no
<zerver> +1 for spring/version
<jk> and there are two jobs to do: 1. add regkey so lobbies know where to search for the unitsync 2. try to make unitsync spring version independent
<zerver> -1 for any registry shit
<hoijui> 3. use a unitsync loader becuase 2 will never be the case
<zerver> portability is the shit
<hoijui> 2 shoudl of course be tried to get real
<jk> w/o regkey lobbies can't be installed in diff folders than the engine
<zerver> they can be installed in the "root" spring folder, below all versions, which is enough
<hoijui> cant we put a file in theMy Docs/Games/Spring/ fodler that has the location to unitsync ?
<jk> also the (2.) isn't that hard to do, the archive checksums just need to ignore dependencies & there need to be a clean way to get all dependencies of archives
<hoijui> no jk..
<hoijui> we discussed that last time
<hoijui> and it is not realistic to assume that
<jk> not realistic in what way?
<hoijui> now you want to discuss the smae thing again
<jk> no, you didn't discussed this at all last time
<jk> you just ignored us
<hoijui> no i did not
<abma> hm, thats not the point here...
<abma> can we hmm.. explain the different solutions in short and don't mix to many stuff together?
<hoijui> true, that does not even matter for the folder structure
<abma> we discussed this 2 weeks ago... so...
<jk> I want to hear real reasons why the unitsync can't be version independent and not just "<hoijui>hey jk.. what is the problem wiht my solution?"
<abma> imo version independant means that the api never will change
<jk> incorrect
<hoijui> becuase the API is not stable for ever, and never will be
<hoijui> that is practise
<abma> / always backwards compatible
<jk> lobbies change so unitsync api can
<hoijui> and again. whether it is needed or not does nto matter for what abma wants to discuss here
<jk> new unitsyncs just need to be backward compatible for 1-3 spring releases
<abma> my question is... do you see problems with an installer that will reuse an folder where different spring-versions are installed?
<hoijui> aehhh... you better think agian what you just said
<zerver> backwards compatibility might not be that hard to achieve
<hoijui> and... again.. it does not matter, so talk about it later, k?
<abma> + where to place maps / games when the installer ships with them?
<abma> use mydocs? or use the program-folder? or create a new folder?
<jk> I try to split this in multiple jobs, e.g. moving lobbies to a separate dir, find folder structure for basecontent, unitsync problem
<abma> ok
<zerver> good idea
<abma> +1 for that... all at once will make problems
<zerver> imo moving maps and mods one level up would be an important step
<hoijui> of course, maps and mods woudl nto be versioned
<zerver> the rest could largely be left intact
<hoijui> ummm!!!
<abma> hm, so how many steps to split this up?
<zerver> 1. fix spring so it searches for maps and mods one level up
<zerver> 2. fix unitsync
<zerver> 3. fix installer
<jk> sounds like an evil hack
<zerver> im expert at those
<abma> [LCC]jK: better solutions?
<abma> (better solutions are always welcome)
<hoijui> hehe :D indeed! :D
<jk> better let it search for maps & games next to the unitsync
<hoijui> that was a nice one
<zerver> but there will be one unitsync per version
<hoijui> hehe
<jk> I mean the global one
<hoijui> love you zerver
<hoijui> right now
<zerver> maps & games next to the global unitsync, but that is same as i suggested?
<abma> [LCC]jK: imo this is step 9/10 what youre talking about? this assumes, that all spring versions are installed in one folder?
<abma> this also assumes, there is a unitsync0.82.3.dll + spring0.82.3.exe?
<abma> or i don't understand
<zerver> there is one global unitsync, and one in each engine version subfolder
<zerver> lobbies should access the global one, preferably by looking in the current folder, and one level up
<abma> [LCC]jK: can you make an example what you suggest and write down, where are 2 unitsync.dll + spring.exe are located/named?
<hoijui> i dont think htey shoudl look one folder higher for untisync
<hoijui> that woudl ony make sense if we coudl change lobbies in odl installers, which we cant
<hoijui> and if we woud create new isntalelrs for odler versions, we coudl place the lobbies in the upper fodler right away
<jk> my timeline would be: 1. move lobbies to a separate dir (they pollute spring's dir & VFS) 2. ignore dependencies in archive checksums, this is already needed by rapid & co. and so should be done separate of the multi-engine support already
<hoijui> so no change needed there
<hoijui> sounds good
<jk> starting from that it's much easier
<hoijui> soo.. 1. on linuix shoudl not be a problem i guess, and on windows.. are there alternatives to a reg key?
<tobi> can make files identified by guid
<hoijui> eg, an .ini file in hte my docs/games/spring/ dir?
<abma> afaik this is common way on win32...
<tobi> then you only need to know the disk its on
<tobi> probably depends on filesystem being ntfs though
<jk> on windows it should check for regkey and/or ini
<hoijui> what is guid?
<hoijui> ok...
<abma> [ARP]hoijui_g5: AllUsers\somepath\.ini would work
<jk> or even the lobby-dir itself (for portable versions)
<zerver> anything that makes the solution not portable is fail
<jk> we know
<hoijui> so reg-key + ini file (either right next to lobby or in a global dir)?
<abma> [LCC]jK: 1. can be done already in installer... only the lobbies itself need an update
<abma> but updating lobbies... this is a step we can't do :)
<jk> yeah, the only thing we need to change is to add a regkey in the installer
<hoijui> if 1. is done from our side, it does not mean that lobbiess have to use it right away
<zerver> regkeys are not portable
<jk> the lobbies have to maintain portable solutions & use that regkey
<abma> zerver: then please a portable solution
<zerver> i already suggested one?
<jk> the lobbies can just check for the unitsync in the current dir as they do now
<hoijui> that
<abma> zerver: how the global unitsync is found?
<jk> but they should first check the regkey and if it exists use it
<abma> where is it placed?
<hoijui> so jk.. you say.. no ini file>?
<zerver> lobbies look first in current dir for a unitsync, if not found they look one level up
<jk> lobbies can decide
<hoijui> or woudl it be reg-key > ini-file > CWD
<abma> zerver: imo we have to split off lobbies from unitsync + spring
<abma> that means: no files of spring in lobbies dir, vice versa
<hoijui> lobbies can decide.. do you mean, we ask lobby devs what they want, or we supply both?
<zerver> lobbies are totally spring related, so no harm in having them as subfolders of spring
<jk> afaik you can already define the unitsync path in SpringLobby, so there is no problem with this (it just needs to use the regkey as default)
<abma> zerver: so... spring\engine0.82.3 spring\springlobby spring\zero-k ?
<jk> zerver: currently the lobbies pollute the spring dir
<zerver> spring\springlobby
<zerver> spring\zerok
<zerver> spring\engine_xxxversion
<jk> I want only spring engine related files in the dir
<jk> no wxwidgets.dlls etc.
<zerver> spring\someotherenginever
<zerver> spring\anyfoldername\unitsync.dll
<hoijui> jks solution has pros, and no contras
<hoijui> you can still put it in hte smae folder
<hoijui> but do nto have to
<hoijui> so ... again: reg-key > ini-file > CWD?
<zerver> yeah,
<hoijui> and we support(create) reg-key + ini file?
<abma> +1
<jk> +1
<hoijui> ok
<zerver> reg-key > ini-file > CWD > CD
<zerver> reg-key > ini-file > CWD > CWD\..
<hoijui> zerver.. that makes no sense
<jk> it makes
<zerver> spring\springlobby
<jk> but it is the lobbies decision
<hoijui> why shoudl we have one lobby per version (and as siad, that only works for future lobbies anyway)
<hoijui> thats where you woudl use spring\springlobby\engine.ini
<zerver> not one lobby per version
<zerver> either overwrite lobby or append version name springlobby_1.2.3
<abma> overwrite will happen
<abma> (maybe only if file is newer)
<zerver> if spring\springlobby folder is always used, sure
<jk> why do you talk about stuff we have no control for?
<jk> we can just create that regeky&ini, and hope lobbies will use it
<hoijui> yeah.. true, lobbies can decide
<abma> yep
<zerver> no control? spring installer installs springlobby so we have control over where it is placed
<hoijui> yeah but not how they locate unitsync
<hoijui> whether they use the ini or CWD/.. for example
<zerver> true, but we can suggest how they should do it
<jk> they may have even better ideas
<hoijui> i dont think that this suggestion would mater much. it's not like these guys woudl not know the differences themselfs
<hoijui> mm true
<jk> so just give them the possiblity to install in diff dirs, and inform them, and see how they solve it
<zerver> and inform them that if they install in diff dirs, it is not portable
<abma> a #ifdef WIN32 shouldn't be the problem in this case?
<abma> we have this in datadirlocator stuff, to
<jk> <tobi> can make files identified by guid > what do you mean with that? afaik guid != checksum, and all archives need to have the same checksum on all clients (to check if they are broken)
<hoijui> it is still portable with ini files, zerver
<zerver> no
<hoijui> mmm ok.. yeah ...
<abma> win32 is 100% posix compatible
<hoijui> it does nto make sense to isntall a protable spring version and install a lobby normally
<hoijui> does it?
<abma> damn: +n't
<zerver> portable = grab the entire shit and move to a new computer, put it in ANY folder, and it works
<abma> ahh :-D
<tobi> [LCC]jK: http://blogs.msdn.com/b/oldnewthing/arc ... 34679.aspx
<abma> zerver: portable != portable (i understood it as platform independant)
<zerver> k sure
<tobi> as I understand it you can basically request windows to create a guid for your file, and then you can always find this file again using this guid (+ the disk letter (or volume guid))
<abma> -1 for guids
<zerver> lol that is the least portable thing ever
<abma> looks like it only works on ntfs
<tobi> yeah, I'd -1 on it too
<jk> GUID is a random generated number
<zerver> microsoft is amazing, just like this SxS configuration shit
<tobi> hmm yeah it wouldn't even be useful in this case, as there is no way to let the lobby know the guid on a particular install
<abma> zerver: for a portable (copy + paste + it works) installation... ehm... lobbies need to find its config file itself + locate then the spring engine
<abma> i'm unsure what the engine can do there...
<zerver> yes, and the lobby will wind spring in CWD or CWD\..
<zerver> find
<jk> also OpenFileById is NTFS only and needs min WinXP+ServicePacks
<abma> ok.. then i will first change the (online) installer, so it places engine stuff in spring\engine_<version> spring\springlobby + add a reg key + add an .ini?
<tobi> I guess the only cool thing about it is that you could make it so that after install, lobby can always keep finding unitsync even if you move it around on the same disk :)
<tobi> but otherwise it seems not relevant now, so -1 on using it (its not KISS anyway)
<jk> oh yeah, that must be the reason why M$ added that
<zerver> "Application has failed to start because side by side configuration is incorrect"
<hoijui> it shoudl be spring\<version>
<abma> ok, sure
<hoijui> or spring\V<version>
<abma> hm
<jk> obviously it must be part of their WinFS project (which was droped as we know
<abma> this is why i suggested spring\engine_someverstring
<hoijui> its not the engine only in there
<abma> hm?
<hoijui> engine is spring.exe
<abma> ok, right
<abma> spring\sync_<somever>?
<zerver> this we discussed already, no need to limit the engine version folder name
<zerver> and unitsync.dll goes in the engine version folder
<abma> zerver: that won't work without unitsync/engine changes
<hoijui> no, that is what you said, it is not what we discussed already
<zerver> jK ageed i think
<zerver> why does it not work with unitsync/engine changes?
<hoijui> cant see how sync_ makes sense
<abma> just a different name :-/
<zerver> thats just an extra folder bloating the spring dir
<hoijui> there should be nothing else then version folders in spring/
<abma> ok, where to install test-releases?
<zerver> and lobbies (optional)
<abma> i want to install 100 different test-releases into one folder
<hoijui> lobbies there is only a hack, or maybe portable.. but for sure an exception
<jk> <abma> ok.. then i will first change the (online) installer, so it places engine stuff in spring\engine_<version> spring\springlobby + add a reg key + add an .ini? > you can't install spring & springlobby in separate dirs right now, first springlobby needs to learn to use regkey/ini/CWD/"CWD/.."
<jk> so the first step is to just add regkey & ini
<jk> and wait until lobbies adjusted
<abma> thats an chicken-egg problem
<abma> (partly)
<jk> no, when you install them right now in diff dirs, they don't work
<abma> what's the name of the reg-key?
<abma> where to store locations of different installed spring-versions?
<jk> HKLM/Software/SpringRTS/dir=C:/Program...?
<hoijui> why different spring versions?
<hoijui> it will alwyas contian the path to latest spring version
<hoijui> as of now
<hoijui> i mena.. latest installed
<abma> hmm... don't know where to start what to explain what i mean
<abma> multiple versions installed means: springlobby needs a way to find all versions installed
<jk> that can be solved later
<abma> means either multiple registry keys or all engine versions in one directory
<jk> first the lobbies should just load the unitsync from that dir
<abma> ok, thats one additional step
<abma> 1. install engine as normally + set registry + .ini
<abma> wait for lobby to read registry + ini key read? or install them seperate for now?
<zerver> lobbies should use this priority imo: CWD CWD\.. reg ini
<abma> zerver: for portabilty: yes, but thats lobby stuff
<zerver> yep
<zerver> i guess ini and reg should point to the global unitsync dir
<hoijui> yeah
<abma> thats why i ask about the multiple versions... there is no global unitsync dir for now
<hoijui> but as of now, there is no such thing, so it is the latest unitsync dir == latest spring dir
<hoijui> abma.. isntall what separate for now?
<abma> lobby
<abma> the other stuff makes no sense, as it won't work
<hoijui> you dont have to change anything lobby related in hte installer now
<hoijui> this onyl may make sense when we move to a multi version structure
<jk> so now (2.): any volunteers for the unitsync archive checksum thingy?
<zerver> i didnt fully understand why that needs a change
<jk> I would do it myself, but still have to finish EFX, weapon-targetting, new widget/gadgethandler, lua instance for loadscreen, ...
<hoijui> as it is now, the mod checksum is: checksum of mod archive + checksum of base content (or other deps)
<hoijui> so for different engien versions -> smae mod+ version -> diffrerent checksum
<hoijui> that is very bad for multi version support
<zerver> yeah, complicated at least
<zerver> so the checksum routine would need to use the correct base content, otherwise fail
<jk> it also breaks rapid. it uses the unitsync checksum to download the archive from the web
<tobi> see it as an extra protection to ensure only correct versions are used with each other
<tobi> unitsync already exposes the raw archive checksum
<tobi> which does not include dependencies
<jk> it does?
<tobi> GetArchiveChecksum
<tobi> * This checksum depends only on the contents from the archive itself, and not
<tobi> * on the contents from dependencies of this archive (if any).
<jk> Licho ...
<jk> and jj ...
<abma> (i'll add the reg + ini + ask then for feedback of lobby devs + you)
<tobi> dunno who wrote the docs but it matches with what I recall I've often said in the past
<zerver> i'll add support for storing maps+mods in parent directory
<jk> if this function works as said no change is required
<tobi> and if not its only a bugfix, not a feature
<tobi> it calls archiveScanner->GetSingleArchiveChecksum(arname);
<abma> zerver: thx
<hoijui> zerver, lobbies may do that, the engine does nto have to do that
<abma> hmm
<zerver> the engine must find the maps tho?
<hoijui> isnt the problem that the lobby protocol advertises the combined checksum, and so lobbies can not know the oen of the mod archive?
<tobi> ah yeah
<jk> but that doesn't matter
<jk> all ppl _must_ have the same basecontent
<hoijui> yeah.. no unitsync change requried for that
<hoijui> it does matter
<tobi> yeah but mod itself can consist of many archives
<jk> yeah, but when you join a battleroom ALL clients must have the same checksums for all used archives
<jk> -> you can't sync with old spring's & basecontents
<hoijui> what about springfiles for example..
<hoijui> if you requrest a file there
<hoijui> it makes no sense to requrest it with the combined checksum
<tobi> yeah problem was that lobby checksum is abused for identifying files iirc, while it was intended only for checking sync
<abma> maybe only the name of the mod should be used for that?
<abma> ehm
<abma> game
<abma> /archive
<hoijui> sync should be checked for all arhcives separately
<jk> there is no need for this
<hoijui> a battle/script.txt shoudl only have the checksum for the mod and the map
<jk> still a more modular lobby protocol (which would allow this) would be nice
<hoijui> mmm
<hoijui> it has to change anyway for multi version support
<jk> yup
<tobi> sync checking is fine as it is, publishing additional hashes for identifying content would be nice extra feature
<jk> same what I said ^^
<tobi> well you just mentioned a more modular protocol :)
<abma> http://springrts.com/mantis/view.php?id=2268
<jk> a more modular protocol is needed to publish these additional hashes
<abma> (thats the problem in short)
<abma> from lobby view
<tobi> ah right dedicated servers
<jk> can't the lobby retrieve it from the connected clients?
<jk> erm lobbybot
<tobi> not with current protocol afaik
<hoijui> simply replacing the combined wiht the single checksum would be enough
<jk> oh yeah, the lobbybot needs to define the hashes when it creates the battleroom
<tobi> yeah
<jk> as said we need a more modular protocol :)
<tobi> this one is also solvable by making spring check smarter, i.e. if no hash is supplied by host only check whether all clients have the same hash
<hoijui> not for this feature though.. so it can be a step in the pan wihtout requrieing lobby tprotocol change
<hoijui> plan*
<jk> yeah, dedi server shouldn't use a hash at all
<jk> still it needs the modhash to open the battleroom
<jk> so the map part can be solved in dediserver, mod part needs a lobby protocol change
<hoijui> i belive you but... i dotn get it... why :D
<hoijui> ?
<jk> when a lobbybot wants to open a battleroom (e.g. ZK0.9) then it needs to know its modhash
<jk> because the modhash is defined when creating the battleroom and can't be changed at runtime (when clients connect)
<hoijui> ahhh k
<hoijui> and lobby bots cant have a list of the mod hashes?
<hoijui> or shoudl not?
<jk> that's what Licho wants to avoid
<jk> to reduce diskusage on the lobbybots
<hoijui> ok
<zerver> next?
<hoijui> one thing....
<hoijui> when having a gobal unitsync, we coudl rename the lib at the smae time
<hoijui> same*
<abma> ehm, yes?
<zerver> what lib?
<tobi> unitsync :)
<zerver> why rename that?
<abma> the name unitsync is wrong
<zerver> ok
<zerver> spring.dll ?
<tobi> confusing if you have hide file extensions on
<zerver> true
<hoijui> engineInfo.dll ?
<hoijui> info.dll
<abma> engineHelper?
<hoijui> i had some ideas in the past.. forgot
<tobi> spring-api.dll or so
<zerver> yeah, or engine.dll
<hoijui> engine-api
<hoijui> hmm..
<zerver> although i dislike the term "engine", which only makes me think of trains
<hoijui> engine alone is not good, cause the engine will eb a dll too in the future, when we have a launcher
<abma> engineHelper
<hoijui> it is already in the spring fodler.. shoudl never be anywhere else really
<abma> hm...
<hoijui> so spring in hte name makes no snee i think
<hoijui> helper, info engine-api, engineApi
<hoijui> *,
<hoijui> tobi, using - instead of camel-casing as word separator is more common in lib names?
<hoijui> ... yeah looks so, if i check out /usr/lib
<hoijui> hmm.. i would like info.dll or helper.dll
<hoijui> or api.dll
<zerver> spring-api.dll is good, having spring in the name can be good to make it unique
<hoijui> ?
<abma> corporate identity...
<abma> write your name everywhere
<hoijui> it is in a unique folder already
<zerver> yeah, but it will scan all engine version dirs, and who knows what resides there
<tobi> more pragmatic it may help when googling for issues with it, if it has a somewhat less generic name than info.dll or so :)
<hoijui> mm ok.. that is a point tobi
<hoijui> it is still kind of bad though....
<hoijui> i mean..
<tobi> now if you look for just unitsync.dll you arrive at spring stuff immediately
<hoijui> its like having libsun-java.so
<hoijui> nobody does that
<abma> afaik its jvm.dll / libjvm.so
<hoijui> mmm
<tobi> for system wide things its pretty common actually afaics
<jk> btw do we have any volunteer for the script.txt change (removing the mod/map hash and check it at runtime when clients connect)
<hoijui> ahh right..
<hoijui> but without the - then
<hoijui> libspringapi.so
<tobi> also I guess that on linux it will go into /usr/lib, so there it really should be less generic than info.dll
<tobi> *libinfo.so
<hoijui> yeah
<tobi> afaics people just do what they want on linux
<tobi> I see _ - and nothing being used as separator :)
<hoijui> hmm..
<hoijui> well for the launcher, i will use - to put version and other stuff (like headless) into the lib name
<hoijui> and the version will use _ inside (if i remember right
<hoijui> )
<hoijui> so having no separator for this .. i would prefer
<tobi> fine with me, I don't mind really much about the actual name as long as it isn't too generic
<tobi> as I think that would be a bad idea
<tobi> anyway I'll be off too, it's late already
<tobi> gn
<abma> gn8! :)
<abma> hm, ok the name has to be somethin like libspring<to be filled in>.so
<hoijui> we can make a poll among loby devs too
<abma> for a naming?
<abma> sure
<hoijui> ah yeah.. has he answered yet? i guess not.. not yet awake i guess..
<hoijui> yep
===assimp merge===
<abma> for the assimp merge.. i only want to say, spliff reapplyed his changes. for myself i didn't test it yet, but it looks much better
<hoijui> yeah, it does.. even though.. i start to dislike how gitk shows merges
<hoijui> the discontinued branches, shown with an arrow into the nothing
<hoijui> that is continued somewhere else.. no idea where
<hoijui> we alreayd have way too many commits to scroll to find that place
<abma> time to start spring2
<hoijui> :D
<hoijui> yeah.. we should learn from reality
<hoijui> keepign too much history creates wars and stuff
<abma> :)
<abma> is there a way to debug lua-scripts inside spring?
<abma> zero-k v0.8 seems to have a problem with an endless loop in a gadget as jk already found
<abma> hm, maybe something like that: http://www.lua.org/manual/5.1/manual.html#5.9
<abma> debug.sethook... but i don't know if that could work
<abma> maybe debug.sethook with count set... so... for example after every 10k of lines... just an idea
<zerver> yeah, try it
<zerver> but would need spring changes i guess
