Present: abma, hoijui, jK, Tobi, Kloot, zerver
Agenda
- make BrainDamage an engine dev?
- Release plan
- UML colab. tool (test Inkscape, Dia, ArgoUML till next week)
- pathfinder-interface
- communication enhancement with mod-devs
- improve unitsync
- Next meeting
- Anything else?
<hoijui> yeah...
<hoijui> i mean.. would be rather a formal thing
<hoijui> i asked him a few times, but he alwyas ignored the question
<hoijui> would just be more practical if he had direct access, as he is patching quite some lately
<hoijui> woudl also reduce frustration on his side.. as he alwyas fears his work beeing lost
<Tobi> sounds like a good idea yeah, if he wants
<hoijui> anyone else want to say something? against?
<Kloot> I am fine with it if he wants
<hoijui> ok
<abma> me too
<hoijui> i'll get him here
<Tobi> ok
<BrainDamage> hi
<hoijui> hey
<BrainDamage> i'm studying atm, so i cannot pay much attention
<BrainDamage> if you need to address me personally, just ping my nick
<hoijui> wanted to ask if you want to get spring dev status (mainly for direct repo access)
<hoijui> BrainDamage
<BrainDamage> it could be useful if that unitsync/liblobby/whatever name gets done, but it's not necessary
<BrainDamage> if you want, go ahead, i hope it will not mean more resposibilities from me
<hoijui> :D
<hoijui> mm ok
<hoijui> lets see.. when you start with a new .. bigger patch maybe?
<hoijui> aehm.. next :D
<BrainDamage> i'm kinda indifferent, really :)
<BrainDamage> what was the term? +0
<BrainDamage> or something like that
<Kloot> alrite
<Kloot> offer remains on the table ofc
<Tobi> yeah, I would say, when you (BrainDamage) want to save the work of lobbying for someone to merge/cherrypick a commit of which you are pretty sure that it's correct, just poke one of us again to get access :)
<BrainDamage> kk, i'll do that for sure
<BrainDamage> i was considering trying to refactor a bit mouse handling btw
<BrainDamage> but after my exams
<BrainDamage> for that, having direct commit access might be handy
<BrainDamage> i was thinking of a centralized handler ala keyboard handler
<BrainDamage> where diff listeners could subscribe
<BrainDamage> it's kinda tricky because for what i saw most of the events are context sensivitive
<BrainDamage> so it would need event passing/dropping
<Tobi> isn't there a bit something like that already?
<BrainDamage> i didn't check spring event handler in dept tbh
<Tobi> or do you mean factoring out the pieces that are in CGame?
<BrainDamage> but mouse is definetly not handled that way
<BrainDamage> i mean something along bind mouseclick1 action
<BrainDamage> cgame is one, but there's several others
<BrainDamage> minimap orders
<Tobi> ah right, you also want it configurable :)
<Tobi> that would be good, I suppose
<BrainDamage> yes, the goal is to make it user configurable
<BrainDamage> and proper event handling would be a prerequisite for it
<hoijui> k.. let BD study now!
<BrainDamage> well, since i'm here
<BrainDamage> i might as well write it completely
<BrainDamage> 5 mins more or less wouldn't change much at this point
<BrainDamage> the events to be hooked that i had in mind where:
<BrainDamage> mousepress, mouserelease, mouseclick and mousedoubleclick
<BrainDamage> at the end, there's a number indicating the button number
<BrainDamage> if possible, scrollwheel should be counted as simple click
<Tobi> so a scrollwheel would be 2 extra buttons?
<BrainDamage> yup
<Tobi> one for one tick in one direction and one for a tick in the other direction?
<BrainDamage> yeah, i think it'd be most flexible way to handle it
<Tobi> might give some weird semantics with click vs pressed/released and doubleclick
<BrainDamage> lagspike
<Tobi> I mean, if you scroll fast, would it generate a bunch of press-release-click-doubleclick sequences of events?
<BrainDamage> sorry, net issues
<BrainDamage> missed any reply since
<BrainDamage> [16:27:28] <[RoX]Tobi> one for one tick in one direction and one for a tick in the other direction?
<BrainDamage> [16:28:46] <BrainDamage> yeah, i think it'd be most flexible way to handle it
<Tobi> [16:28:05] <[RoX]Tobi> might give some weird semantics with click vs pressed/released and doubleclick
<Tobi> [16:28:21] <BrainDamage> lagspike
<Tobi> [16:28:37] <[RoX]Tobi> I mean, if you scroll fast, would it generate a bunch of press-release-click-doubleclick sequences of events?
<Tobi> checked in other big environments, javascript and Java, both have separate wheel event
<BrainDamage> i was thinking of handling simple "click"
<BrainDamage> for wheel
<BrainDamage> but make it count as a normal button
<BrainDamage> and skip press, release and doubleclick
<jK> hi
<BrainDamage> hiho
<Tobi> hmm right
<jK> sorry that im late
<Tobi> welcome anyway :)
<hoijui> hey
<Tobi> maybe for the configuration part it does make the most sense
<BrainDamage> so keep the internal logic handling wheel separately, and present the wheel binds as clicks?
<Tobi> something like that yeah
<BrainDamage> i guess that works
<BrainDamage> btw, i'd like to provide this as extension to uikeys, not a sep file, in the case it was not clear
<Tobi> ok
<BrainDamage> so you could bind say Ctrl+MouseClick1 fight
<Tobi> [LCC]jK: current topic is some possible mouse handling rewrite by BrainDamage that would make it configurable like key bindings
<jK> wheel bindings still need to be processable as wheel movements too
<Tobi> makes sense
<jK> because wheel movements have length scale, normal mouse clicks doesn't
<jK> +a
<Tobi> hence the combination (as many wheels work in ticks)
<jK> k
<BrainDamage> i have a question, when/if i finish that
<BrainDamage> should i change spring's default mouse bindings?
<BrainDamage> i think they are a bit inconsistent with left/right usage
<jK> btw when you are on it, it would be nice if the hardcoded number of mouse buttons could be removed it :)
<BrainDamage> i'd have to check how SDL handles mouse to answer that, but sure
<jK> I would say keep it as it and make some other layouts the user can choose from
<jK> *as-is
<BrainDamage> oh, and before all this, i checked the source, and searched for a lua unsynced call-out that would return the list of binded keys
<BrainDamage> i could only find one that would return list of binded commands for a given keyset, but not list of keysets registered
<BrainDamage> so i'd like to add a call to list them
<BrainDamage> so ingame editors won't have to parse uikeys manually, plus it'd show even keys binded dynamically ingame
<jK> yeah, notices that too
<Tobi> seems good to have that yeah
<abma> yep, sounds good
<jK> the only way atm, is to print all current binded commands to a uikeys.tmp (there is a command for that), and then to parse the file on lua
<jK> *in
<Tobi> right
<BrainDamage> kk, i think i'm done on the topic
<Tobi> ok, then I suggest we continue with next topic and you continue studying
(you can stay here though ofc)Main points
- BrainDamage becomes engine dev
- After exams, BrainDamage may work on mouse handler similar to keyboard handler (e.g. with mouse clicks configurable in uikeys.txt)
<hoijui> i guess, we only do a new release when satirik bug is fixes.. so.. nothing to talk about here i guess
<jK> my RL is (*&(*^ up atm, so I couldn't work on the unitsync bug any further
<Tobi> satirik bug?
<hoijui> or is a new release required right now?
<Tobi> ah the unitsync thing
<hoijui> unitsync thing .. dependencies..
<hoijui> mm
<Tobi> not the map names' extensions?
<jK> same thing
<Tobi> ok
<Tobi> it gets new name every week
<jK> hehe
<Tobi> I've just asked det whether he pushed 0.82.5.1 already to ubuntu PPA btw, since I got some e-mail asking when it would be updated
<Tobi> otherwise I've no release things either
<abma> also the download-page is still old: http://springrts.com/wiki/Download (still 0.82.5 there)
<hoijui> maybe all engien devs get access to endit the download page?
<hoijui> so far, its only you Tobi. right?
<abma> that would make sense
<Tobi> me, BD, koshi, maybe some of the forum admins
<hoijui> ok
<Tobi> I don't know if I can get a list from mediawiki
<Tobi> but I can make engine devs wiki admin too
<hoijui> mmm.. yeah i think that would be good
<Tobi> doing that now
<Tobi> that last thing wrt Release?
<hoijui> yeha.. next
Main points
- Unitsync map extension bug not fixed yet due to RL
- Hence, no reasons yet to make a new bugfix release
- All engine devs get access to the download page
<hoijui> mmm :D
<hoijui> is there anyone who did try all of them?
<Tobi> nope, I didn't get around anything at all unfortunately
<hoijui> inkscape is vector graphics, Dia for diagrams in general, and argo is only UML
<Tobi> although I have tried ArgoUML in the past and could get things done in it, IIRC
<hoijui> mm ok
<hoijui> mm same here
<hoijui> Kloot, i guess, in Dia.. theres no such thing as export to UML format or so?
<hoijui> i bet in inkscape neither
<Kloot> I don't recall if there is
<hoijui> i instaleld all 3 of htem, started them and.. did nothing
<hoijui> ehhh!
<hoijui> [17:05:15] <[RoX]Tobi> ===UML colab. tool (test Inkscape, Dia, ArgoUML till next week)===
<hoijui> hmm so...
<hoijui> shoudl we just decide somethign, or rahter give more time to test?
<hoijui> i am pro giving more time
<Tobi> same
<abma> of these, argouml looks like the best...but i didn't test too...
<hoijui> you can also add other tools to the list
<hoijui> next?
Main points
- No one really tried all the suggested ones => moved to next week
<Tobi> sidenote: Kloot: did you just search-replace for those colors in the minutes or make some kind of script?
<Kloot> lol, I just wrote some python regex script
<Kloot> and randomly picked from all colors consisting of 00 and FF
<hoijui> they were a bit too bright for me!
<hoijui> :D
<zerver> double rainbow, omg
<Tobi> if you can commit it in tools/scripts then I will use it too
pathfinder-interface
<Tobi> anything at all about pathfinder-interface?
<hoijui> on topic: ... it was not quite nice how you merged abmas stuff in
<hoijui> abma.. you mentioned some minor issues, with comments nad such
<hoijui> has that all been fixed?
<Kloot> oh comments are still not "merged" no
<hoijui> ok
<hoijui> soo.. the lets consider this part done ...
<hoijui> what is next in modularizing the pathfinder?
<abma> i had only two suggestions: comments + make functions abstract.. nothing big...
<Kloot> ideally it shuld be able to operate on abstract movedefs
<hoijui> mmm
<Kloot> which I have half-done somewhere
<hoijui> so generally speaking... work so far was: abstracting engine -> pathfinder interface, and now missing is the other way around?
<hoijui> mm
<Kloot> yeah
<BrainDamage> sorry to butt in, and i premise i did not check it yet
<hoijui> ok.. and your plan for the flow field path finder.. would that be an other implementation, or the current one changed?
<BrainDamage> but can the new interface support pushing of arbitrary wights for nodes?
<hoijui> the new interface is same as the old one
<hoijui> its just abstraced
<Kloot> flowmapping would be an extension to the existing one
<hoijui> no new functionality
<hoijui> ok
<BrainDamage> could that be added since you're there?
<Kloot> heh, probably
<BrainDamage> the plugged pathfinder, could or could not use it, but it think it would add several advantages
<BrainDamage> for example, mods after planting mines could declare it as no-go zone for your own units
<BrainDamage> or AIs would finally stop having to use their own pathfinder
<BrainDamage> to handle threatmaps
<BrainDamage> i think the tricky part is that it should be able to have diff weights for each team
<hoijui> better have a weight-field as a param or something
<Kloot> yeah that would be necessary
<hoijui> so it can be per-whatever
<hoijui> 9k.. just saw that was stupid, nvm
)<Tobi> even different weights per allyteam (for e.g. area denial mines) plus weights per team (for e.g. AI threatmaps) are necessary, afaics
<Tobi> and in theory many AI can control the same team together, isn't it?
<hoijui> ok so.. path finder is not kloots terrirory?
<hoijui> exactly
<BrainDamage> yes, but the interface should support such
<hoijui> thats what i was thinking abotu too
<BrainDamage> then the pathfinder could just ignore it
<hoijui> not => now :D
<hoijui> doh!
<BrainDamage> but since we're talking about abstracted stuff, i tought i should mention it
<Kloot> for now AIs using the pf can just supply their own desired weight matrix
<Kloot> as an additive layer
<hoijui> next?
<jK> the new pathfinder should be totally modularized, so there are many layers (ground-height gradients, flowmap, danger zones, ...)
<jK> so each layer can be multithreaded etc.
<zerver> next?
<Kloot> it needs some refactoring anyway, current one doesn't use the slopemap eg
<Kloot> slope costs are handled via speed modifiers
<Kloot> which are precomputed etc
<zerver> yep
<jK> yeah, I also want to add a jump map, so tanks can driver cliffs down, but not up
<jK> *drive
<hoijui> ahh nice :D
<Kloot> so basically directional slope tolerances?
<jK> yup
<zerver> so that jumping units can jump over obstacles :)
<zerver> but maybe they can already, ca had something similar
<BrainDamage> yes, but it has to use it's own pathfinder in lua
<zerver> ok
<BrainDamage> which yet another reason to extend current :)
<zerver> indeed, lau pathfinder is ugly
<zerver> must be slow too
Main points
- comments must still be merged from abma's branch
- some functions should be made abstract
- so generally speaking... work so far was: abstracting engine -> pathfinder interface, and now missing is the other way around
- flowmapping would be an extension to the existing PF
- for now AIs using the PF can just supply their own desired weight matrix as an additive layer
<Tobi> I didn't really do anything yet (wrt making forum), still planned
<Tobi> do we have some rules for it already?
<hoijui> jk made some in last meeting
<zerver> So basically, like the current feature requests forum, but more two way communication?
<Tobi> no, really Q&A forum was the idea
<zerver> ah, so mostly for the current version, not about future changes?
<Tobi> any topic that's not a Q gets instantly (well, whenever it is reported and some moderator is online) removed, I suppose
<BrainDamage> i seriously hope that any (or at least most ) info collected there will be mirrored in the wiki
<Tobi> questions about future changes would be fine I think, but not disguised feature requests questions
<Tobi> anyway, is the idea then that I wait with making the forum until the rules are collected together and written down in postable (bbcode) format? (that's what I thought, just didn't get around on asking whether they were ready yet this week
)<Tobi> or that I make it and write the rules myself based on what has been said in meeting?
<abma> did anyone start an etherpad for the rules?
<Tobi> I didn't
<zerver> ...not sure I can do that
<abma> here it is: <link removed> i currently copy+pasted what we spoke last meeting there...
<zerver> ok, anyone can create new etherpads?
<Tobi> yes
<hoijui> next?
<Tobi> one thing
<Tobi> I think best way to highlight good questions is if we source the forum with a few example questions
<Tobi> we can make those in the etherpad (to make sure we all agree they are supposed to go in the forum)
<zerver> Wrt that etherpad. is there any current documentation for unitDef?
<Tobi> and then have everyone of us post a few of them once the forum opens
<Tobi> and also answer them
<Tobi> I was thinking of everyone think of 2 such questions
<Tobi> then we should have a good example set
<Kloot> unitdef docs are on the wiki, dunno how current
<Tobi> (and let's not all take "what does unitdef tag xxx do?"
)<hoijui> :D ok Tobi...
<Tobi> anyone oppose to that idea?
<zerver> That's good to get it started in the right direction
<Kloot> so only positive examples?
<hoijui> dont know if i can come up wiht a good question.. maybe if i se examples from some of you first
<Tobi> hmm, bad example may be good too, but I don't think those should be actually posted on the forum
<Tobi> everyone think of 2 good examples and 1 bad example then, preferably before next meeting?
<Tobi> bad examples can go in the rules as bad examples
<Tobi> and the good examples can be posted on the forum once it's made
<Kloot> I think the big q&a thread in games&mods could be a good source
<Tobi> ah yeah, feel free to take from that
<abma> maybe move already existing "good" topics into that forum?
<hoijui> SL hang on download finnished
<zerver> ugh, bad question
<Tobi> abma_irc: that would be epic amount of work
<Tobi> at least if it will be work for one person
<abma> not all, just a few as examples
<Tobi> yeah that is fine
<hoijui> you would also still have a lot of useless posts in there
<Tobi> lets just do 2 good example and 1 bad example from everyone for next time
<Tobi> you can pick from that thread if you want
<abma> ok...
<hoijui> my bad one is, posting infolog as text
<hoijui> MINE!
<Tobi> put in the etherpad please :)
<Tobi> btw food is almost finished
<Tobi> this topic also finished?
<hoijui> yeah
<Tobi> ok
Main points
- We make rules in some etherpad document
- We each add 2 good example questions and 1 bad example question before the next meeting
- Once this is done we can make the forum
<Tobi> we already heard that due to RL the map extension bug is still open
<Tobi> is there anything else to discuss on this topic?
<Tobi> ok, I take that as a no :)
Next meeting
<Tobi> same time is fine with me
<hoijui> same is ok for me
<Tobi> off to dinner now, have fun discussing "Anything else"
<abma> here too
Anything else?
<hoijui> off topic: does spring master HEAD run ok for all of you?
<BrainDamage> bon appetit
<BrainDamage> when you build target spring or spring-dedicated it doesn't build unitsync, this is really bad since you have to remember all of them and launch manually, and if you forget even one it will be built during make-install step which is 99% of the times be launched with root priviledges screwing up file permissions
<BrainDamage> to fix it i suggest to rename current target "spring" to "spring-engine" and change "spring" to a meta-target that builds spring, unitsync, game data, ai, etc; the same should be done for the other spring-* buildtargets
<zerver> HEAD works here
<BrainDamage> i didn't test recently
<hoijui> mm :/
<hoijui> might be Unix or NV related then
<hoijui> i'll have a look, BD
<BrainDamage> i'll give a test build later
<BrainDamage> i have linux + nvidia
<zerver> not sure if SDL peforms some operations before calling SDL_main
<zerver> otherwise only difference is an additional thread
<hoijui> mmm
<hoijui> thanks BD
<zerver> you can easily remove that thread start code and see if it runs then
<BrainDamage> another thing:
<hoijui> arg.. i need food too now!
<hoijui> yeah?
<BrainDamage> 6 months ago, if not more
<hoijui> uh huh! :D
<BrainDamage> i got a patch merged in spring
<hoijui> somethign coming up
<hoijui> ah k :D
<BrainDamage> so that selectkeys is handled internally using bind
<BrainDamage> in theory, selectkeys.txt file is useless
<BrainDamage> i only left it in because of that ugly selection editor for windows
<BrainDamage> but it's functionalty is completely replicated in uikeys, and it's even more flexibile in binding
<BrainDamage> should selectkeys be declared deprecated and eventually removed even if there's no alternative atm?
<hoijui> would we probably need an auto converter?
<BrainDamage> not really, since it uses bind interally, engine itself can dump interal keybinds to an uikeys.txt formatte file
<BrainDamage> so calling the command once would suffice
<hoijui> mm ok
<hoijui> so the only problem woudl be, windows users moaning that they have no GUI tool anymore?
<BrainDamage> yes, i don't think it's even included in the main installer anymore
<BrainDamage> it's available in the "downloads" page atm
<jK> I don't expect it before next major release, so there is enough time to write a small chili app
<BrainDamage> i also know that VBS is working on a uikeys editor
<BrainDamage> perhaps the functionality could be added there too
<BrainDamage> also, there's always the possibility to write selectkeys strings manually
<BrainDamage> there's actually good docs about it
<hoijui> so you suggest: deleting cont/selectkeys.txt &tools/SelectionEditor/ ?
<BrainDamage> selectkeys.txt yes, selectioneditor not necessarily yet since someone could reuse the code
<BrainDamage> after an alternative is out, deleting the code from the repo can be done
<BrainDamage> altho i guess since history is kept, deleting won't make much damage
<hoijui> yeah exactly
<BrainDamage> for porting default selectkeys.txt, i can write a small patch
<hoijui> ook
<BrainDamage> anyone against it?
<hoijui> fine with me
<jK> fine
<jK> k have to go
<jK> caio
<Tobi> Kloot, will you commit that meeting-log-colorizer script?
<Kloot> oh sure
<Kloot> give me 10 mins or so
<Tobi> ok, thanks
<Tobi> not sure if I'll have time for minutes in next two-three hours anyway
<Kloot> k :)
EDIT: fixed colors a bit
