Present: abma, hoijui, jK, Tobi, Kloot
<hoijui> wohoo!
<hoijui> we are full!
<hoijui> zerver siad he wont come
<hoijui> maybe cleanup agenda first?
<hoijui> or say.. discuss
<Tobi> hello & welcome all
<Kloot> hi
<abma> hi
<hoijui> hey
<Tobi> I'm in RL meeting too so might react a bit slow sometimes
<hoijui> ok
<jK> hehe
<abma> cleanup sounds well...
<hoijui> if no objections/additions to curent agenda
<hoijui> we can also keep it and decide later to skip a point, if meeting gets too long
<hoijui> who will do minutes?
<Kloot> <--
<hoijui> ook, thanks
=== Release plan ===
<abma> the pink points were added by me.. should be ordered by priority i think..
<Tobi> agenda seems ok to me
<hoijui> yeah, yo ucan still do that til we get there
<hoijui> so release plan... curretn release
<hoijui> zerver requested a .6 with his fix.. and i saw kloot has made 2 fixed too
<hoijui> zerver has done more then 1
<jK> I would wait for the unitsync patch
<hoijui> so.. should we do .6 already?
<hoijui> will that not take.. weeks?
<jK> a week perhaps
<hoijui> mm ok
<hoijui> how important are the fixes we already have?
<Kloot> depends on who you ask
<hoijui> if we wait with .6 till unitsync patch, we shoudl at least make 5.1 for MT
<hoijui> hehe :D
<hoijui> if we ask smoth..
<hoijui> nah i mean, for general playerbase
<Kloot> or the gml clientele
<hoijui> mmm
<hoijui> yeah ... that surely should go out earlier then in a week or two
<hoijui> but can be a patch, as said, which is less work/trouble
<hoijui> i can do that
<hoijui> the rest can wait?
<Kloot> the pathing fixes are not critical
<Kloot> imo
<hoijui> ok
<hoijui> the FPSing crash neither
<Kloot> no doubt players would see it differently...
<hoijui> :D
<Tobi> what is the unitsync issue?
<jK> Auswaschbar changed the way mapnames and the mapconfigs are handled (to support the new mapinfo.lua)
<jK> but he changed it is deeply that his change caused a lot of trouble in indirect code
<jK> he tried to fix this himself
<hoijui> http://springrts.com/mantis/view.php?id=2059
<Tobi> ah it is that problem
<jK> but he forgot Lua, Unitsync, AI, ...
<Tobi> hmm
<hoijui> proposal: i do 5.1 with only MT fix, and in one or two weeks, we reevaluate a .6
<jK> doable
<Tobi> you plan to really fix it or (manually) undo the changes / revert the commits?
<jK> real fix
<Tobi> ok
<jK> it is near impossible to undo it
<hoijui> next?
<Tobi> yeah plan seems fine
=== UML colab tool ===
<hoijui> (see etherpad page)
<hoijui> nothing i am really happy with yet
<hoijui> did not try Inkscape, but .. colab support seems quite alpha
<Tobi> doesnt really surprise me TBH
<hoijui> that there is nothign usable? or that inkscapes colab support is alpha?
<Tobi> the first
<hoijui> mm
<Tobi> or is UML-Designer, Creately or Jodoro good already?
<hoijui> so.. we stil with etherpad and stup class code?
<hoijui> Jodoro is very simple, otherwise.. dont know how good it will be in practise, may get inconvienient with more then a few classes
<Tobi> or make UMLs with non-collaborative tools and include picture or so
<Tobi> though etherpad can not do that (pictures)
<hoijui> hmm yeah
<Tobi> but could upload anywhere and include link.. that seems good enough to me
<hoijui> link of the diagram + image?
<hoijui> woudl be godo if we could agree on an aplication still, or at least a format
<hoijui> good*
<hoijui> maybe inkscape? so we could use collab support once it is better supported
<jK> I thought there is a unified fileformat for UMLs
<hoijui> or do you have others yo uare already using?
<hoijui> i think so yeah.. but as i remember form the past, each app supports different subsets of it
<Kloot> what about dia?
<hoijui> does that have a nice windows version too?
<abma> it has a windows-version...
<hoijui> mm ok
<hoijui> lets make a short list, and then we test them during the week
<Kloot> it's the most lightweight easy-to-use diagram editor-like tool I know of
<Tobi> one I would pick now is ArgoUML, that can save to some .uml (xml) format, no clue if that is this unified fileformat though
<Tobi> could be put on list either way :)
<hoijui> .. just wanted to mention that too
<hoijui> ok... lets go to next point. other tools can still be suggested later
=== merge BrainDamage-branches? ===
<hoijui> http://github.com/BrainDamage/spring/tree/gameEnd + http://github.com/BrainDamage/spring/tree/limitdgun
<hoijui> in the first branch, he is outsourcing game end conditions to Lua
<hoijui> abma and me took part in some test matches wiht BD
<hoijui> there were some issues still, but he is mostly done with that
<hoijui> dont know about the second.. abma?
<abma> the second does the same for the dgun-limit
<jK> gameEnd branch: last commit "about an hour ago"
<hoijui> ok
<hoijui> yeah its mainly... when he sais it is done..
<hoijui> maybe you can alreayd have a look at the general structure
<jK> also I requested that he would switch to a GameOver callin instead of a callout to clean up the lua code
<hoijui> and give him feedback
<Tobi> callin?
<Kloot> a GameOver callin is not cleaner at all, the gadget can just get all the info it needs from callouts and signal gameover when it wants
<jK> gadget:IsGameOver() versus Spring.GameOver()
<Tobi> that sounds like the reverse of the point of the branch, because then Spring would have to detect GameOver, isn't it?
<jK> problem is that he does the gameend checking in GameFrame, and calls Spring.GameOver() deep in the 4-5th if-clause level
<abma> shall we invite BrainDamage to the meeting? he seems to be online...
<jK> if it is a callin it is much easier to read and maintain
<Tobi> just apply extract function then to the lua? :)
<Tobi> yeah but besides the point
<Tobi> because then spring would have to detect game over again
<Tobi> while the point of the branch is to move detecting game over to Lua
<jK> ?
<Tobi> and have Lua tell the engine that the game is over (using Spring.GameOver)
<jK> there would no change to that if it is a callin
<Tobi> what would trigger when it is called?
<jK> except that the engine calls once per gameframe a IsGameOver callin
<Tobi> oh now I see
<Tobi> what if IsGameOver returns true once and false again after that?
<Tobi> would it cancel the game over?
<jK> it shouldn't call the callin afterwards anymore
<Tobi> right
<Tobi> I don't really mind then I think, though I think lua can be made equally readable without changing engine
<Tobi> i.e. function IsGameOver() ... end and function gadget:GameFrame() if IsGameOver() then Spring.GameOver() end end
<Tobi> the way it is now highlights better that it's not reversible imo
<jK> http://github.com/BrainDamage/spring/bl ... nd.lua#L69
<hoijui> ..?
<jK> see in what level GameOver() gets called? it is very hard to see.
<Tobi> that's a matter of refactoring the Lua
<Kloot> time to push for Lua continue statement support
<jK> you can blame the lua coder, or you can directly design the interface, so the lua coder writes easy to read code himself
<hoijui> is there break?
<jK> yup
<Tobi> code would be as deep with a call-in TBH
<Tobi> that doesn't magically get rid of all the loops and ifs
<hoijui> if the sample gadgt does it right, 99% of games will follow, no?
<hoijui> gadjet, as Scifi calls it :D (i like it)
<jK> no you would get a anchor point in the code, e.g. function gadget:IsGameOver() return CheckGameOver() end
<jK> having such a point helps a lot
<Tobi> refactoring the code so there is less deep control structures helps orders of magnitude more imo
<hoijui> how it is now, coudl GameOver() be called in draw code?
<jK> it is SyncedCtrl
<hoijui> i mean.. it sems like a detail to me..
<hoijui> and as BD put quite some work into it...
<hoijui> we coudl say, .. you suggest this to him, and if he does not like it, we keep it as it is?
<hoijui> tell him to move the GameOver() call to the end of the fucntion
<hoijui> function
<hoijui> so in the sample gadget, it will be called from one point only
<jK> also I know it is not a huge change, it's just the dot on the i
<jK> still it seems he's not finished with it yet
<hoijui> yeah.. we do not have to push it in rihgt now.. he will say whne it is finnished in his eyes, then we'll have more test runs.. but better to have a look at such stuff before it is final
<hoijui> so .. he will read this anyway, and we can talk abotu it wiht him later
<hoijui> next point?
<Tobi> anyway I agree that it would be good if the sample gadget was a bit clearer written (less deep indentation) before merging it
<hoijui> ok
=== commands refactoring ===
<hoijui> abma!
<Kloot> on the previous point I'd say his limitdgun branch can be merged as-is
<abma> we spoke wit jk last "meeting" that wasn't a meeting about it... we came to the point, that currently just move the commands to an additinal file would help before doing bigger changes to that
<abma> but what to do after that...
<hoijui> (ok kloot, i'll do that)
<abma> if i understood jk, it would be bad, if the commands get into several files
<Tobi> the commands, as in, what is now in commands.h ?
<hoijui> jk's suggestion was, using one function per command (using function pointers), like this:
<jK> commands as in what is now in Game.h
<abma> the commands in Game.cpp
<hoijui> commandHanlder.add(new Command("skip", "skipps frames", &skipCommandFunction);
<Tobi> ah ok
<abma> the ~1500 lines (?) function CGame::KeyPressed
<hoijui> while abma and me suggested, using one class per command
<abma> sorry, CGame::ActionPressed
<hoijui> which we argued, is better for (future) extendability
<jK> it would blow up the new file upto 40kB again
<jK> so there wouldn't be any win in readability
<hoijui> better structure > less size in chars
<hoijui> readability is nor relative to number of chars/lines
<Tobi> class has advantage that everything of a command can be together
<hoijui> not*
<hoijui> yeah exactly
<Tobi> with function + commandHandler.add call the info will be spread over two places
<jK> they want a subclass that takes ~20lines per command
<hoijui> as i already explained last time, our solution, wiht the same functionality as yours, woudl take +2 lines per commadn, over yours
<abma> the change would make it possible, to add the commands where they are needed.. for example, the heatmap command could be registered from the heatmapper
<hoijui> but it allows for more functionality
<hoijui> (2 linies beeing the "class BlaCommand" & "};"
<jK> public keyword?
<hoijui> yeah, the first line would be larger
<jK> function headers?
<Tobi> use struct instead of class gets rid of the public keyword
<hoijui> common
<hoijui> thats just silly
<jK> common you
<jK> it's not just 2 lines
<hoijui> even if it is 10 lines
<abma> yep, that's not the point i think...
<hoijui> it still does not matter, if the structure is better
<jK> lol
<jK> it was YOUR argument
<hoijui> it was your argument that number of lines/chars matter
<jK> don't blame me if it is not valid
<hoijui> my bad was only, to give in to this way of messurement
<abma> it is hard to say, if it will be the same ammount of lines after the change
<hoijui> so.. lets do a vote?
<jK> the thing is that the new commands.cpp would become really really large with it
<abma> there is many duplicate code to check the arguments
<jK> also I said you should first extract it from the Game.cpp, something you didn't yet
<hoijui> yeah.. we know your argument
<jK> when you do so you could get an impression of it
<hoijui> yeah true. that will be done first.. its not like we cant imagine how that will look like though
<abma> i started with it, but it isn't finished yet
<hoijui> so.. votes for "function" or "class" pls!
<jK> and it is not that I don't see the pros of a subclass system
<hoijui> class
<jK> still I think trivial commands should be doable in a less number of lines
<jK> and more complex ones could use such subclasses
<hoijui> yeah.. its stil the same argument.. lets get this done and to the next point
<hoijui> yeah.. i guess that is doable with having classes as a base
<hoijui> having a ByFunctionCommand class
<hoijui> hmm.. nah does not make sense
<hoijui> so .. hello?
<hoijui> guys, vote!
<hoijui> feels like trying to get your game started
<Kloot> I vote for moar popcorn
<jK> ...
<abma> hmm
<hoijui> not even jk and abma did vote?! i mena..
<hoijui> .. it
<jK> you don't argue ..
=== pathfinder-interface ===
<hoijui> i gave my arguments, you gave your argument.. then tis time to discuss
<Tobi> use class + you can have a FunctionPointerCommand command if you want
<hoijui> but instead, you repeated your single arguemnt in 10 different sentences
<jK> next point on the agenda please
<abma> my voiting would be clear..thats why i didnt vote. when others have no opinion
<abma> ok, next point
<hoijui> but having that class woudl again split the command/ having parts of it defiend in different places
<hoijui> === pathfinder-interface ===
<hoijui> so far, jk is pro functions, and 3 are pro class
<hoijui> soo.. kloot siad he would merge that into master..
<jK> that point was added by zerver?
<hoijui> after release
<hoijui> no abma
<abma> no, by me
<jK> I amcolorblind sorry :<
<abma> kloot, did you something there?
<hoijui> etherpad fail.. if you use different colors at different times
<Kloot> I picked it up again yesterday
<Kloot> only thing I want a cleaner solution for is the drawer class
<Kloot> ie. no rendering code / structures anywhere under path/
<jK> drawer class of the cached paths?
<jK> (those lines that show up in cheat & debug-mode)
<Kloot> yes
<Kloot> atm it relies directly on cpath* to plot the visualisations
<hoijui> i reemmber jk saiygni he will take care fo this.. is it not that?
<hoijui> with some future refactor
<jK> that's a different thing
<hoijui> ok
<hoijui> hmm you want ot make the drawing independent of the implementaiton?
<hoijui> or how could it not depend directly on that?
<Kloot> Rendering/Path/IPathDrawer + derived class
<hoijui> ahh.. so basically.. just move the class?
<hoijui> (interface)
<Kloot> yep, and maybe pathfinder implementations could decide whether to enable debug overlays
=== meeting with mod-devs ===
<hoijui> not that i care a lot for it
<hoijui> abma!
<jK> meeting with mod-devs is quite hard to realize (different timezones etc.)
<jK> also I assume it will be less orgainized than our meetings
<abma> yep...
<abma> would an meeting with the mod-devs help to avoid non-tested releases for example?
<abma> the communication between mod-devs and devs is quiet low i think.. most takes part in forum
<hoijui> for more testing, it would be better to make it technically easier to test
<hoijui> not to have meetings with devs
<hoijui> i mean.. allow multiple spring versions on the official server without setting anythign special in the lobby
<hoijui> allwo having multiple engine versions configured wiht the lobby client, ...
<jK> you don't test your mods in the lobby
<hoijui> maybe even distribute RCs through rapid or somethign similar
<jK> modders start spring directly
<hoijui> hmm..
<hoijui> i just reemmber from talking to modders, that they think it is too muhc work to test wiht release candidates
<abma> there are some points: http://springrts.com/phpbb/viewtopic.php?f=12&t=23913
<hoijui> they also often seem to think it is not possible to have multiple spring versions installed side by side and similar stuff
<jK> problem is win7 etc.
<jK> so spring installs everything into the user folder
<jK> and so it overrides the old files
<jK> modders should use portable instead
<jK> (placing the springsettings.cfg next the exe)
<jK> +to
<hoijui> mm
<jK> but I am not a win7/win vista user, so I can't help here
<abma> such stuff maybe could be discussed in a meeting with the mod-devs?... i'm unsure what the agenda would be
<hoijui> we coudl have a channel only for mod devs and engine devs
<abma> give the modders a possibility to talk about their problems while modding...
<hoijui> where they ask questions
<abma> that could help
<abma> or we ask questions
<hoijui> that would free us fro mthe need of finding a time
<jK> problem is that modders just don't ask
<hoijui> yeah... but if we have this channel, we have one more thing we can blame them .. with?
<hoijui> for
<jK> they can already ask in #sy
<hoijui> "coudl have asked in the channel!?"
<jK> also there is #moddev
<abma> hm.. maybo to many channels?
<abma> -o+e
<hoijui> it would stil make sense. as in moddev, there is lots of inter-mod-dev talk, wich we had to scan through, to find the questions for us
<jK> no, I answer a lot engine related questions in there
<hoijui> ok
<Tobi> what I see as ideal would be a stackoverflow like place for modders to ask questions
<hoijui> hehe :D
<Tobi> that way at least q&a remain over time, and don't need to be asked again and again
<jK> problem is that they don't make usage of it
<hoijui> .. that is not our problem
<jK> there is now such a Lua thread and no ones askes in there
<Tobi> but that's probably not easily possible to get (not enough users to get our own stackexchange site I think)
<hoijui> they request meeting, whihc seems not possible due to timezones, so we give them the next best thing.. qhich .. right now seems ot be what tobi suggested
<hoijui> we can delegate this to moddevs
<hoijui> next point?
<Tobi> all in all I wouldn't really know a good solution atm
<jK> they should make a forum thread for now
<Tobi> yeah
<Kloot> separate subforum for moddevs to ask engine-related questions?
<Tobi> as in really question & answer forum?
<Kloot> yeah, with answers of the level of detail that we can provide
<Kloot> questions like "where is the engine going" are too general
<hoijui> stuff like "what does unitDef.abcTag = 1" mean?
<Kloot> but "I have problem XYZ with my mod M and think it is caused by commit 0x123, ideas?" is answerable
<jK> yeah, they should explain there problem and we give them hints how to solve it
<jK> *their
<jK> but they shouldn't blame us for not working things in there
<hoijui> and only mod devs and us get access?
<hoijui> .. yeah godo point
<hoijui> good*
<Kloot> only moddevs would need it, so yes imo
<jK> and they should always explain what they want to do, because there are many ways to reach the goal and their way might not be the best
<Tobi> that raises the question of who will maintain this list and how a modder gets access
<hoijui> we shall have ammenments
<jK> we have such a list already because of the mod subforums
<hoijui> all engien devs are modderators?
<Tobi> aren't there modders without a subforum?
<jK> so all modders are already in specific groups
<Tobi> seems silly to make having a subforum a prereq for asking questions
<hoijui> yeah.. the question is also...
<jK> we could limit the access later, too
<Tobi> alternatives are new topics need to be approved
<Kloot> anyone with (a) significant project(s) is already in the moddev usergroup afaik
<hoijui> will i get access as a mod dev, after a "nouncing my mod idea" thread?
<hoijui> ok
<Tobi> or moderating it properly according to this q&a definition
<jK> imo we should first try it with open access
<Tobi> +1
<abma> +1
<jK> if there will be too many trolls it can still be limited (atm I fear the opposite: too less questions)
<hoijui> 0
<Tobi> yeah
<hoijui> Tobi makes the subforum, jk the rules?
<hoijui> and sticky it
<Tobi> ok
<jK> k
<abma> next point?
<hoijui> yep
=== improve unitsync ===
<hoijui> abma!
<jK> it needs to be renamed :D
<hoijui> YEAH!!!
<abma> yep...
<abma> give me a few secs
<Kloot> s/unitsync/liblobbyaux/g
<hoijui> engine-interface
<hoijui> it shoudl be descriptive for that it does (not what apps are its most prominent users)
<hoijui> engineInfo?
<hoijui> springInfo
<Kloot> what it does is provide filesystem helper functions for lobbies
<hoijui> or autohosts, or ..
<Kloot> all lobby clients
<hoijui> and it is more then just filesystem..
<abma> it could provide lobby-function as well...
<abma> or download...
<Kloot> then naming it after its functionality would get pretty longwinded
<hoijui> it is just not related to the lobby
<hoijui> woudl be a bad name in my eyes
<abma> i picked this up, because currently all lobbies have their own download and lobby-connect code
<abma> it is used by springsettings as well
<hoijui> but indeed.. naming after its functionality would need a long, or a very abstract name
<abma> it is somethink like an interface to spring
<Tobi> springvfs seems fine to me
<Tobi> even if it offers a little bit more services here and there
<Tobi> hmm
<hoijui> springdata?
<hoijui> springlogic
<hoijui> springinfo
<Tobi> not sure it is a good idea to put lobby connect code in it, as it couples lobby (protocol) development more to spring development
<abma> my idea was, to make plugins...
<Tobi> I would do that as a separate library
<abma> and through a lobby-plugin make the connect code....
<hoijui> yeah, separate lib sounds good
<abma> and this could be done by an git-submodle... like the ai's
<Tobi> what would be the advantage of plugins compared to multiple libs for completely separate functionality?
<abma> an clear interface?
<hoijui> the interface would not have to be different
<hoijui> anyway, you can only use simple C functions
<hoijui> for cross language functionality
<abma> yep..
<hoijui> which lib supplies the function shoudl not matter
<hoijui> there coudl be one additional lib for conect code, and one for downloading
<jK> I would like it if the unitsync is able to write the script.txt
<hoijui> and the donwloading one coudl have submodules
<hoijui> or say.. plugins
<Tobi> I don't really see how plugins make things better than just having separate DLLs.. it sounds like it would just be implementing dlload/dlsym/LoadLibrary/GetProc in unitsync
<hoijui> hmm.. yeah... i just though of plugins .. code wise.. coudl be static libs
<Tobi> [LCC]jK: and unitsync be the only software allowed to write script.txt? (as in do you want to remove script.txt as external api?)
<jK> yup
<jK> so script.txt are unified between lobbies and could be replaced with script.lua
<Tobi> why even write a file in that case?
<Tobi> unitsync could start spring and pipe/sharedmem the data into it :)
<jK> the server still needs to send a script file to the clients
<hoijui> yeah.. also.. the flexibility of script.lua would hten be limited by the unitsync C interface foor writing it
<hoijui> better make a script.txt to script.lua conversion script, which lazy lobby devs coudl use
<Tobi> I don't really like this idea, I think script.txt is a decent interface now and don't like forcing anyone wanting to start spring in a non-standard (i.e. battle) configuration to use a low level C API
<hoijui> ditto
<Tobi> if the motivation is to get rid of tdf parser, maybe script.txt could be parsed with parse_tdf.lua ?
<Tobi> if not, what is the motivation/advantage to have script.lua instead of script.txt ?
<abma> maybe lua is used everywhere in the engine?
<abma> i think it was, because of removing the tdf parser... but as you said, it could be replaced by a lua script
<hoijui> any more stuff for this point in the egenda, abma?
<jK> parsing the script.txt with parse_tdf.lua is quite complexe
<jK> it is the reason why modinfo.tdf was removed
<abma> ok
<Tobi> almost, with modinfo.tdf the problem is that parse_tdf.lua is in a file with a modinfo.tdf
<Tobi> so it's a circular dependency
<Tobi> that isn't the case with script.txt
<Tobi> though indeed it's still quite complex :)
<abma> is it currently possible to get the gamestate trough unitsync after an game? (win/lost/...)
<Tobi> though I think less complex than the C++ tdf parser either way :)
<Kloot> unitsync does not know anything about gamestate
<Kloot> or any "live" data
<abma> ok
<hoijui> next point?
<abma> so, seperate the functionality in different libs?
<abma> (yep, after that)
<hoijui> +1
<Tobi> yes imo
<abma> ok
<hoijui> ah btw.. forr the download lib, i guess you will have ot depend on libtorrent, right?
<Tobi> also two of my wishes for unitsync: 1) allow it to be quiet on stdout/stderr and 2) allow getting data directory from unitsync without scanning everything
<hoijui> ahh.. kinf od.. different init states?
<hoijui> kind of*
<abma> or maybe lazy initialization
<abma> i'll put it on my todo
<abma> can't say much about that currently
=== Next meeting ===
<hoijui> same is ok for me
<Kloot> and me
<jK> me too
<abma> i can't say, if i can take part... but should be, is ok
<Tobi> fine for me
=== Anything else? (WVTTK) ===
<Tobi> thanks for all the efforts to make the last releases :)
<Tobi> nothing else from me atm
