Dev meeting minutes 2011-11-21

Dev meeting minutes 2011-11-21

Minutes of the meetings between Spring developers are archived here.
Post Reply
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Dev meeting minutes 2011-11-21

Post by zerver »

Present: <abma>, <hoijui>, <jk>, <kloot>, <tobi>, <zerver>

=== House warming ===
<hoijui> ufet, you need invitation!
<hoijui> ;-)
<hoijui> nah's ok of course
<hoijui> next time, ask if you want to join, and dont give away channel name
<hoijui> if we wanted everyone to join if wanted, we could do it in #sy
<hoijui> would suck if we needed to make special precautions to keep unwanted out
<det[THE]threat> Sorry, may I stay.
<jk> o_O
<jk> so many?
<hoijui> they invited themselfs
<hoijui> except zyre
<hoijui> i invited him
<jk> Zyre is one who was like 2months on the aggenda, wanted to get informated about ROAM?
<hoijui> exactly
<hoijui> he had some IRL .. heavy occupation stuff, was away from spring, now came back
<Zyre> =D
<hoijui> abma will not come
<hoijui> or only very late
<hoijui> so we are onyl waiting for kloot
<zerver> yep
<hoijui> do we need him?
<hoijui> i think not. right?
<zerver> no, unless he has some new release blocking info
<zerver> I hope not...
<hoijui> mmm :-)
*** <det[THE]threat> left the channel (kicked) ***
*** <Zyre> left the channel (kicked) ***
<zerver> Aww that hurt
<abma> bye!
<kloot> we need a new channel
<kloot> or a new lock
<hoijui> yeah maybe
<hoijui> licho posted the channel name in #sy

Conclusion: This is a private meeting :mrgreen:

=== not proven to sync, or proven not to sync? ===
<jk> the dragon slayer is here :)
<hoijui> ehh hey kloot, we jsut started. nothign said yet
<hoijui> except zerver making minutes again
<hoijui> and:
<kloot> hi
<kloot> ah yeah, that commit
<zerver> I have used fromSynced at least once before, so I was hoping it would be working :P
<kloot> I have seen many wtfs in spring, but a variable called "fromSynced" being false in synced context would be a first
<zerver> in transportCAI IIRC
<jk> fromSynced was added by KDR _ages_ ago
<jk> and he added it to make use of it in lua context
<jk> so it is everything else than stable/tested
<jk> also a function argument for function that is used in synced & unsynced code is imo not a relyable source
<kloot> hmm
<zerver> so, now is the time to test it :P
<zerver> If the release fails, we have a suspec
<zerver> t
<jk> oh and sync errors always tell their source as we already saw the last weeks ...
<zerver> so, leave it for now and try it in 0.85?
<zerver> I mean, we have to try it, unless you specifically know it has problems
<jk> more like for 0.88
<zerver> At the current release fail rate, that will be soon enough
<jk> you don't have to try it, you could also either check the code (spaghetti yummy :)) or refactor the code so synced & unsynced go different paths
<kloot> refactoring commandAI.. does not sound appealing
<zerver> removing the default argument "true" for fromSynced would be a first step
<jk> lol
<zerver> having a default argument is what gives rise to the uncertainity about the value
<zerver> should maybe use a TLS value for fromSynced...
<jk> yeah, I always wanted to add a bool-var around SimFrame() to make it easier to detect synced code
<jk> still it would just give a hint nothing 100% reliable
<zerver> Why not reliable?
<kloot> synced can write unsynced data
<jk> cause synced code can be issued from netcode, too AFAIK
<jk> yeah but synced can't from unsynced
<jk> so if the boolean would be false and it runs synced code -> gives you a hint that something is wrong
<zerver> ok
<zerver> So we do something like that, but not for 0.84

Conclusion: fromSynced may be unreliable, to be rewritten, but not now

=== When to store/send sync checksums? ===
<kloot> I settled on once every 30 frames
<kloot> for the sending part that is
<tobi> may be good to have it more often when doing sync debugging
<jk> and always enable it not just for debugbuilds (with the reduced timing it shouldn't increase traffic, but helps a lot when users provide desync demos)
<kloot> thats fine
<zerver> 4 bytes per player in the demo, 30 frames per sec, that is > 2kbyte per sec with 20 players
<zerver> but once ever 30 frames, yeah
<kloot> a bigger problem is the lack of ASSERT_SYNCEDs
<kloot> lack of sufficient*
<jk> oh gs->Rand needs one
<kloot> so desyncs can go undetected for 100s of frames
<jk> >_<
<zerver> awesome
<kloot> until snowball grows big enough and glhf at that point tracing it
<jk> problem is that each ASSERT_SYNCED eats a hell lot of CPU power
<tobi> we could replace the backtracing with just storing __FILE__ and __LINE__
<tobi> in a macro that actually works
<tobi> it means getting rid of the weird automagic sync checking on assignment to Synced* variables
<tobi> but using ASSERT_SYNCED only is more KISS anyway
<tobi> then I'd get rid of the whole Upcast/SyncedPrimitive business
<jk> SyncedPrimitive still seems to be optimal for unit positions etc.
<tobi> it isn't too hard to search for where this gets assigned and adding an ASSERT_SYNCED after it
<tobi> not fatal either if a few places are forgotten
<tobi> and it makes it much more obvious where exactly sync is checked
<hoijui> sections for sync checks?
<tobi> ?
<hoijui> like unit-related
<hoijui> as with the logging system
<tobi> no need
<hoijui> if we find otu there is a desync, and suspect it is unit related, we enable that section
<hoijui> ok
<hoijui> just thoguh casue jk siad it is cpu intensive
<tobi> yeah but how often do you know beforehand what causes the desync?
<zerver> yeah, almost never, but after the first test run maybe
<tobi> what do others prefer, implicit checking on every assignment to a Synced* variable (using the ugly SyncedPrimitive stuff), or explicit checking using ASSERT_SYNCED?
<jk> I prefer both
<jk> both have their pros & contras
<jk> so both should be used imo
<zerver> ASSERT clutters the code a bit
<tobi> that is true yeah
<zerver> so I agree
<tobi> ok, then the (probably slow) backtrace will have to stay, I fear :)
<jk> why?
<tobi> CSyncDebugger::Sync called from SyncedPrimitive can't know about where from it is called otherwise
<jk> you can still improve ASSERT_SYNCED w/o breaking SyncedPrimitives
<jk> would just need some modularization in the syncdebugger code
<tobi> yeah, both would be possible too at expense of a fair bit of memory
<tobi> but since its just when sync debugging that isn't really an issue
<tobi> not even need for more modularization in syncdebugger (I don't see how anyway)
<tobi> but ASSERT_SYNCED should do something sane instead of the hack it is now
<tobi> i.e., call CSyncDebugger::Sync directly, instead of making a SyncedXXX temporary and assigning to it
<tobi> then it will be easy to have it pass e.g. __FILE__ and __LINE__ too and do something with this in the sync debugger
<kloot> actually it no longer creates a temporary afaics

Conclusion: We keep SyncedPrimitive and ASSERT_SYNCED

=== Send the checksum to all clients, so they can store it? seems to be already enabled for syncdebug builds: ... r.cpp#L591 ===
<kloot> already done
<zerver> what was the decision?
<jk> possibly just send the `correct` checksum?
<jk> this would reduce the traffic even more
<jk> so it wouldn't ever cause a problem when default enabled
<kloot> every client gets everyone's checksum
<zerver> the server broadcasts the correct checksum, the clients should only send theirs if they have detected a desync?
<zerver> Hmm, but the server needs the correct checksum to know what is correct :P
<kloot> clients always have to send theirs
<zerver> yeah, forget what i said
<zerver> so what did jK mean really?
<jk> before it was: clients send their checksums to the server, server process them and detects desyncs between them, sends raw messages if so
<jk> now it is: clients send checksums, sever process them & sends raw message if so + sends all client checksums to all clients
<zerver> okay
<jk> ideal would be it only sends the processed checksum of CGameServer::CheckSync()
<jk> *sends back to the client
<jk> *clients
<jk> this way the traffic would be static independent of the players count
<jk> +&
<zerver> this sending of all checksums, it happens only when desync is detected?
<kloot> no, always
<kloot> because the idea is to be able to detect desynced demos
<zerver> ah
<zerver> yeah, sending checksum of all players seem a bit overkill maybe
<zerver> but you can also see if your invalid checksum matches some of the players'
<zerver> if the desync has some determinism involved...
<jk> in that case the server could send all occured checksums
<jk> (group checksums)
<zerver> yeah, that saves bandwidth too
<jk> offtopic: btw all ppl should update changelog.txt for 84.0 :)
<zerver> nah, no time for that, release is NOW :P
<hoijui> .. you should have told me at meeting start! :P
<jk> hoij can you tag>
<hoijui> there are mostly fixes sinsce 83.0, right?
<jk> *?
<jk> yup
<jk> changelog could aslo be updated after 83.0
<jk> erm 84.0
<jk> changelog since 83.0
<zerver> back to topic... So we decide to only send correct checksum + invalid ones, without specifying the respective players?
<jk> hmm most important things are already in the changelog
<kloot> dunno if it is worth the effort/bandwidth saved
<zerver> if it delays our release, I absolutely agree
<hoijui> i am pretty sure nobody wants to do the sync check stuff changes before hte release, right?
<zerver> lets say it is desirable to make this change then, but not now
<hoijui> maybe we add basic changes since 83.0 to changelog, and i mak release stuff then
<hoijui> we dont have to include hte fixes really
<hoijui> as 83.0 was not live... only testers really woudl care abotu that...
<hoijui> can still add that later, as jk said

Conclusion: Some optimization wrt sending sync checksums is possible, but not to be done now (the release is more important)

=== Will migrate it to the release branch and send the checksums back to all clients ===
<zerver> is it in release already?
<kloot> yes

=== ... or/emplace O_O (when do we switch to c++11?) ===
<zerver> I agree that emplace is a nice feature

=== Release plan ===
<hoijui> so who will put basic changes into changelo.txt?
<hoijui> anyone alreayd working on it?
<jk> it ssems it is completed
<jk> only (desync) fixes were done last week
<jk> so 84.0 is ready to be tagged
<jk> and seems no one thinks otherwise
<zerver> ya
<hoijui> what about the mac changes?
<jk> and as release message I modified the old one just a little
<hoijui> ok. i will let you do the release post again
<jk> unimportant, mac is still experimental
<hoijui> someone shoudl check if spring still basically works on mac
<hoijui> :P
<jk> my fix, likelly didn't fixed the crash
<hoijui> but also did not make anything worse for those who did not suffer from that crash?
<jk> hope not
<jk> still they can use LoadingMT = 0
<hoijui> ok.. so your changes, at worst, break loading screen stuff?
<hoijui> cant break other opengl stuff?
<jk> the worst case is that it renders random stuff on the screen during loading
<hoijui> ok
<hoijui> i though it could laso break in-game rendering
<jk> so nothing ciritcal
<hoijui> then that surely is not so important
<hoijui> k :-)
<hoijui> i'll start then
<jk> nah, ingame crash is possibly a intel shader issue
<hoijui> mm :-)
<jk> need more info to fix it, might fixed until 0.86/0.87
<hoijui> did lua API change?
<hoijui> since 83.0
<zerver> I have random garbage on my loading screen, it has been for a while
<zerver> But another driver/hardware no problems
<hoijui> AI nad unitsync api did not change
<hoijui> (this info goes into the releae tag)
<jk> Lua changed only minimal
<hoijui> :D cool!
<zerver> rofl
<hoijui> btw, make notice about it not beeing live yet again , at top of post
<kloot> I think dragons are usually slayed, not killed
<hoijui> and make it so eveyr noob understand it, as in: "you cna not play online wiht this version yet"
<zerver> no, make it live right away ffs :D :D
<hoijui> zervver, no :P
<hoijui> need to give linux packagers some time
<hoijui> 1 day at least
<zerver> okay whatever
<hoijui> ok... gonna push tag now....
<jk> fine :)
<zerver> increasing pathestimator_version etc, is that done?
<jk> *text fixed*
<jk> erm
<jk> good question
<zerver> we better do it... just to make sure
<hoijui> too late ;-)
<zerver> haha
<hoijui> hmm..
<kloot> it was already increased for 83.0 anyway, and probably no player has caches generated with that
<hoijui> it is building develop now :/
<hoijui> have to wait till that is finnished, so it will start with master
<hoijui> tobi, is it somehow possible to give master branch priority?
<hoijui> if changes on multiple brnaches happen (for buildbot builds)
<jk> back at c++11, when do we switch already hit so many things I would likely use (emplace, enum classes, unorded_maps, `auto` for iterators) :)
<jk> * when do we switch. I already hit ...
<hoijui> when debian stable works with it
<hoijui> ;-)
<jk> yeah GCC 100% is not finished with the implementation, but a lot of things are already usable
<hoijui> also remember the first rule of virtual nature
<hoijui> C++ only gets worse
<hoijui> its like when the black folks though they were now free, at the end of the US civil war
<hoijui> an illusion!
<jk> c++11 isn't a totally different language, but it makes things easier & more efficient
<hoijui> but back on track again..
<hoijui> some people woudl sat the smae about C++ in relation to C
<hoijui> hehe
<hoijui> say*
<jk> the step between c & c++ is ways larger than c++99 & c++11
<hoijui> some parts are supported by all our compilers?
<jk> enum classes * auto should
<jk> *&
<jk> :<
<jk> no emplace yet in gcc
<tobi> [ARP]hoijui: don't think so, or at least don't know
<tobi> you can cancel builds until the right one starts
<tobi> but that is a bit messy
<jk> enum classes & `auto` are in since gcc4.4
<jk> unorded containers are available too in gcc (I assume since 4.4)
<hoijui> ok Tobi, no big deal :-)
<kloot> and MSVS? (not that I care much, but otherwise we get situations like in LuaTextures)
<jk> that wasn't c++11, that was a compilation issue with boost
<jk> if I could have used c++11 there everything should be fine
<jk> (still boost one is by factors faster than current libstdc one)
<hoijui> but do they support the stuf you want to use?
<jk> and unordered_map is supported in MSVC11
<jk> erm MSVC10
<jk> enum classes need MSVC11
<jk> hmmm k
<jk> MSVC development is such slow ...
<kloot> and non-standard
<jk> so the question is what MSVC versions we support
<jk> with MSVC11 we have nearly the same level as GCC4.4
<tobi> we only got vclibs for 2005 and 2008 on github
<jk> they seem to work with msvc10/11, too
<tobi> ok
<hoijui> btw..
<jk> we neither support GCC3.5 anymore ;)
<hoijui> could we probably address zyre now>
<hoijui> ?
<jk> (should be same age as 2005/08)
<jk> yeah, no c++11 flag yet then
<jk> but I might asked again when I hit a c++11 feature and need to workaround/implement it in c++99
<jk> :)
<jk> *might ask
<jk> damn fingers today ...

Conclusion: 84.0 is tagged and ready to go

=== Zyre ==
<hoijui> Zyre is interested in starting to contribute... starting in about 2 weeks or so
<hoijui> tell us a bit .. please :-)
<Zyre> i want to make some things
<Zyre> like to make a system about flocking units
<Zyre> a unit group coordinator to prevent shocking and make a custom formation,
<Zyre> i want to join the dev in the terrain rendering, i was doing some search
<jk> did you read the minutes of our pathfinder meeting?
<jk> ROAM is finished already and just waits for a release
<hoijui> you remember roughtly when that was, jk?
<jk> last christmas?
<hoijui> mm ok
<hoijui> thanks
<Zyre> i found some stuff good to test about, ROAM2 oyu already see about it?
<jk> -+ 2months
<jk> no ROAM implementation is worth to worry about
<jk> the current ROAM is ways faster than the old implemention, so it is worth to be commited
<jk> but a new implementation should be more modern
<Zyre> i thin's the same way
<Zyre> but it will be good to storat making something new to test?
<Zyre> start*
<jk> and any implementation that depends on the CPU is crap ;)
<Zyre> GPU
<Zyre> ok.. well, i think for now i will be doing my stuff's in my AI, if for some luck you guys like it
<jk> so either it should use GL3 & transform_feedback or even better GL4 & tesslator
<jk> new pathfinder would be very nice, too btw
<Zyre> something like ins supreme commander
<Zyre> you already see that?
<jk> I read the papers
<Zyre> i was told that is already someone doing some similar stuff
<hoijui> Kloot is wokrign on the pathfinder mostly
<jk> no kloot just wants to release soon a 2nd pathfinder for spring that is a improved version of the current one
<hoijui> ah ok.... i though te siad he wants to use the supreme commadner thing too
<hoijui> but that is only a plan yet, yeah?
<jk> best would be a totally new implementation, based on `layers`
<Zyre> for now it's my graduation work i only begin to develop it
<hoijui> arg.. now buildbot builds linux develop
<Zyre> well, i will begin hard in it in 2 weeks, maybe i could show something rigth after the new year begin
<hoijui> mm :-)
<kloot> actually I once implemented a pathfinder with the same algorithm used in supcom2
<kloot> (not in spring)
<kloot> but it had.. issues
<Zyre> it could be usefull to me
<Zyre> but i want to make something all of my own
<Zyre> i want to make the player or the computer adjust the formation
<Zyre> like rotate positions
<Zyre> to make some more units survival
<Zyre> it could be of use to many ideas, and tatical combat can be mixed in the RTS
<Zyre> it's no good? o_o
<kloot> no, formations are a nice idea too
<hoijui> if you want to make somethign all by yourself, and you did not yet do anything wiht spring yet
<kloot> but possibly better tested/prototyped as a widget
<hoijui> ... starting small is good, or doing an AI of course
<hoijui> hey abma :-)
<hoijui> you missed EVERYTHING
<abma> hi!
<hoijui> like. lots of girls and cocaine mountians and what not
<abma> i think/hope you did well without me :)
<abma> :D
<Zyre> i think i can do something to test after the year begin, it will be an AI to make more sense anyway, for now
<Zyre> i can release*
<hoijui> we are preparing the 84.0 release now, as oyu may have seen on git
<hoijui> (bama)
<Zyre> well it's all for now...i think if the ROAM is already finished
<abma> nice, i already hoped that it can be done after that desync fix
<jk> the pathfinder meeting:
<Zyre> well, thanks =D
<jk> something important imo is to make it threadable
<jk> so splitting work into layers etc.
<Zyre> nice
<hoijui> also if you have ideas, try to communicate.. maybe others have similar ones, or see problems,, better then starting to write soemthign and when it is finnished, you find otu it was for nothing
<hoijui> cause maybe.. somebody else did the same
<hoijui> ahh finaly it started t build master (mingw)
<Zyre> ok, i will try to make some post in forum and try to make it updated
<hoijui> perfect :-)
<hoijui> nice you came back again, btw :-)
<hoijui> i alreayd though we lost you ;-)
<Zyre> thanks, i liked all the engine itself and the people that talked to me, a lot
<Zyre> i want to make a good work and see all this grow more and more
<Zyre> and if possible to bring more interested people to help in the work
<hoijui> :-)
<hoijui> i like that! :D
<jk> :3
Last edited by zerver on 22 Nov 2011, 02:00, edited 3 times in total.
0 x

User avatar
Posts: 737
Joined: 26 Nov 2005, 11:22

Re: Dev meeting minutes 2011-11-21

Post by det »

Please don't post falsified logs involving me.
0 x

Posts: 1397
Joined: 17 Sep 2008, 04:36

Re: Dev meeting minutes 2011-11-21

Post by luckywaldo7 »

I'm behind on release plans, is 84 the release with roam and the new pathfinder or are those pushed back to 85 now?
0 x

Post Reply

Return to “Meeting Minutes”