Dev meeting minutes 2011-06-27

[jK]

Date: 2011-06-27
Present: BrainDamage, hoijui, jK, Kloot, Tobi, zerver



_Agenda_____________________________________________________________________

• Hoij's new branch model
• Multicasting in Internet/Spring?
• Gamasutra wants an interview with us!
  • Syncing in other games
• Safe multithreading in sim via marking threadsafe functions like you do with const funcs?
• Release

_Main Conclusions___________________________________________________________

• Elaborate answers for the Gamasutra writer
• All should try to get their last things get done, so a release can be made

_The meeting________________________________________________________________
>> jK joined!
>> hoijui joined!
>> BrainDamage joined!
>> zerver joined!
>> Tobi joined!
hoijui: abma said he will not be here
hoijui: so only Kloot is missing
zerver: right
hoijui: as Behe and me both found out independently, somethign seems to be wrong with shadows
hoijui: it uses lots of CPU, even when set to -1

Hoij's new branch model
hoijui: does anyone have some critique about the brnaching model i posted on the forum today?
zerver: do u have a link?
BrainDamage: http://springrts.com/phpbb/viewtopic.ph ... 41#p493041
Tobi: looks good
hoijui: yeah that.. it are 3 posts.. maybe skip the first one (oat least the diagram)
hoijui: k
Tobi: through using tags suffixed only with ~ may be a bit confusing
Tobi: that's the only part that I still don't really like
hoijui: BD, do you see problems with the new versions? (~ instead of +, and chars in patchset, isntead of only numbers)
BrainDamage: no, not really, as long as it remains in the patchset field
jK: it makes lua parsing/handling even more complexe with strings in it
BrainDamage: maybe add special engine calls to give the separate fields independently?
hoijui: for lua you mean?
BrainDamage: yes
hoijui: mm
hoijui: yeah that would make sense
hoijui: i could do that, i guess (sounds like copy&paste work)
hoijui: i though it was you jk, that wnated to have strings in the versions initially
hoijui: eg RC
jK: for lua relevant would be something as: basetag (e.g. 0.83.1), branch ("develop"), number of commits since last tag (53)
hoijui: ok
jK: RC is a bit easier to parse than feature branches
jK:
jK: but with those separate functions it shouldn't be a problem for lua
hoijui: well.. its everythign after the 3rd '.' so... cant see why
hoijui: ok
jK: yeah, but imagine you want to make your game ready for next engine release w/o dropping support for old
hoijui: yeah.. it was, and still will be parsebale by the dots
hoijui: but nm.. even if not, it would work now with the new functions
jK: then you need to know if a commit is included in your dev build of the engine
jK: and if your dev build is a feature branch it doesn't have to contain the commit you rely on
jK: nor the other way around
hoijui: mmm
hoijui: ok
hoijui: you mean you cant comapre them anymore
hoijui: as before
hoijui: doesnt concern the parsing
jK: hmm in theory you would even need to knwo when the last merge with the dev branch was to fully solve this issue, but I think that would be too much
jK: or you save full list of all commits in the engine, so lua can check for single commits
jK: +a
hoijui: hehe
jK: but that would need ways too much cmake magic ^^
hoijui: lua can get the hash of hte exact commit out of the additional info, then make a query at github for the commits list :D
hoijui: can even do a textual search in commit messages
hoijui: so user can write in console:
hoijui: "dear MrZeroK, will you crash if i enabled ground decals?"
jK: spring's lua can't access teh internet
hoijui: "Dear MrZeroK: let me check my internals ..."
hoijui: ahh sahme!
jK: it would cause ways too much security problems
hoijui: mmm
hoijui: maybe lua/games should not even try to run stable on each commit

Multicasting on the internet/in Spring?
jK: btw anyone knows how many ISPs support multicasting and if it would be usefull for spring?
hoijui: for the website?
jK: -l
jK: no, for game hosts
hoijui: the lobby?
hoijui: ah
hoijui: dont know
jK: not that it would make ISPs happy to use such functions just for ~10-20 clients
jK: still it would massivly reduce the traffic for the host
jK: and it would even allow host switching when the host drops
hoijui: i though traffic is no problem in general
hoijui: mm
hoijui: that sounds good
jK: and to switch the host you wouldn't even need to know the IPs of the other clients
jK: because you just send to the shared multicast ip, which all clients share
hoijui: sounds like a more natural and in the end maybe even simpler way of doing relay-hosts
hoijui: .. partly
BrainDamage: that assumes the host still has port forwarding
hoijui: mm
jK: not just that, it assumes: your local router supports multicast forwarding, your ISP supports multicast forwarding, the used toplevel internet routers support multicast forwarding
>> Kloot joined!
hoijui: hey Kloot!
Kloot: 'evening
jK: I still don't understand how multicast works in the internet, but in theory it should massivelly increase internet traffic
hoijui: so far, we discussed the branching model i posted on the forum, and now:
jK: btw anyone knows how many ISPs support multicasting and if it would be usefull for spring?
hoijui: you mean decrease?
BrainDamage: atm traffic is limited by end nodes ability to provide content ( see why many connection got asymmetric bandwith ), with multicast such limitation would be removed
jK: your ISP would have to send the packet to _all_ toplevel routers, which send them to lower level ones, and when you reached a deep enough level (country, region) the routers can begin to filter if the multicast address is even used in their netwrok
BrainDamage: at least for multiple users of the same content
zerver: yeah, traffic decrease only on the sender side
zerver: but those routers will have to work hard
jK: yeah, internet will hate us, but game hosts traffic will reduce by 1/#players
jK: in theory you could even drop the host as a whole, all clients could just send to the multicast address instead of the host
hoijui: mmm ddint think of that
hoijui: sounds like pretty unlikely that any ISP would do that
hoijui: you pay for low bandwith and get high bandwidth and they have to pay for it
zerver: multicast must be like a wet dream for DDoS hackers
jK: still I don't think all ISPs support this, it would increase internet traffic such a lot (you send your packets to the _whole_ internet and routers then filter if you requested incoming traffic on that addr/ip
hoijui: thwy could split the package up
hoijui: as in.. produce one copy per each destination ip in hte multicast address?
jK: yeah, just the DDoS usage makes it very unlikely that it works at all on the internet
jK: no, for multicasting you don't name multiple ips in the package header (that was planned once to, but would need to much CPU power on the router level)
jK: with multicasting you send data to a specific ip which is shared in your whole network
hoijui: mm
jK: so your client requests to accept incoming traffic on ip 224.x.x.x and clients would get the same data (similar to a Token Ring)
jK: it is used for zeroconfig network setups in LANs
jK: so dhcp, dns, ntp, samba, ... informations are send on such a ip, and all clients in the network get those packages
Tobi: I'd forget about it, besides the question if it is sufficiently supported (I don't think it is) it will introduce a piece of code that is *extremely hard* to test and debug and it will introduce a second code path for many network related things so there's a lot more to test too
jK: I assume multicasting is just a dream for gaming >_< (I assume only ISPs themselves can use it for their IPTV)
jK: yeah, it just sounds such nice, possibly too nice
hoijui: so.. anythign else to discuss?
hoijui: i wrote a mail to that guy that wants to have an interview

Gamasutra wants an interview with us!
hoijui: and he sent me some qeustions i will respond to now
hoijui: yeah that
hoijui: anyone interested in hte questions?
Tobi: yeah would be nice to see them
jK: anyone available for the telephone call?
Kloot: I'd prefer answering by email, responses can be more indepth then
zerver: +1
jK: yeah, also he doesn't seem to want an interview with just us, instead he wants to write a more general open source gaming article
Kloot: hmm indeed his questions don't target spring specifically
jK: still the last questions seems to be made for "custom formations" & "excessive lua scripts" ^-^
jK: -s
Kloot: lol
jK: let's make an etherpad to answer those questions or does someone alone want to answer them?
zerver: etherpad is good
zerver: joint effort...
hoijui: i alreayd sent an email :/
hoijui: but i'll wrtie again to say there will be an other one
zerver: np
jK: what were your answers?
hoijui: first question i did not understand
hoijui: last: lobby servers and clients (multiple ones), many different AIs
jK: using a heightmap for collisions instead of polygon/model based approach like being used for first person shooters is such a reason to have a RTS engine
jK: pathfinding is different to first person shooters too
hoijui: hmm ok
hoijui: thats what i though is most likely that he asked for
hoijui: but the question is strangely worded then (i think)0
hoijui: mmm
hoijui: it seemed so at least when i frist read it :D
Kloot: ambiguous if he means engine design or game design
hoijui: yeah
jK: many engine (Unreal, Unity, ...) are universal and he asked why to use a RTS specific one instead of those
jK: *engines
hoijui: also.. there are no really general engines..
hoijui: as jk siad.. you would compare it to FPS engien for example..
hoijui: adn .. it is kind of stupid to argue that fps engien is worse for rts then and rts engine

Syncing in other games
zerver: RTS needs a synced sim, FPS does not
hoijui: :D
Kloot: "needs" not really, it is just much more convenient
jK: oh yeah syncing is a very very important reason too
zerver: but FPS could use a synced sim, but I doubt that any do
hoijui: i though it is a rather little used approach?
jK: w/o syncing we would really need multicasting ;o
zerver: indeed
hoijui: as in.. mostly TA and supreme commadner
Kloot: for fps it would be fail due to lag
BrainDamage: it's also a matter of performance
jK: I wondered if Starcraft2 & OpenTTD use syncing
zerver: lag yea, but the sync frame rate could be higher
BrainDamage: with unlimited bandwith you can use FPS network model just fine
Kloot: openttd has the same network model
jK: same as?
Kloot: us
Kloot: lockstepped sims
Tobi: openra has same too
jK: ah nice :D
Tobi: age of empires 1 had same too
jK: from aoe I knew they did, but except them I didn't knew anyone else
Kloot: only one "fps" I recall had our model (xwing vs tiefighter)
Tobi: it's also interesting to see how they all do sync checking
hoijui: which ones did you check out, code wise, Tobi?
jK: yeah, it would be very interesting to see how they do it
Tobi: we have this ugly templating stuff I made, openra dynamically adds checking instructions to the bytecode based on some attributes
Tobi: don't recall / didn't check openttd
Tobi: I think they use only ints though
Tobi: so that's a whole lot easier already
jK: lol
hoijui: mm :D
Tobi: and openra guys actually do diffs of their disassembled IL code whenever they upgrade mono to find miscompiles
hoijui: sounds like too nice/good for what actually comes out in the end
jK: sounds complicated
Tobi: nah, the solutions work but they work only in manager platforms
hoijui: i mean.. they shoudl come here and do it for spring.. much more worth it :D
Kloot: and they still have many desync bugs ^^
hoijui: ah k :D
hoijui: manager platforms?
Tobi: which one, Kloot?
hoijui: uhh server lag!
Tobi: *managed platforms
Tobi: i.e. CLR, JVM
hoijui: ahh k
Tobi: disassembled IL is much simpler than disassembled x86 machinecode
Kloot: based on the openra changelogs I read at least ;P
Tobi: ah openra
Tobi: yeah I actually desync if I compile it myself because latest stable (I think) mono has a miscompile
jK: still diffing disassembled IL code seems to have many false positives in it
Tobi: depends how much changes between mono versions
jK: e.g. compilers resort commands (which are independent!) for improve cpu waiting times etc.
Tobi: I saw them complain last time cause the label naming changed or something
Tobi: [LCC]jK: IL code is higher level
jK: -for +to
jK: still foo++; bar++; and bar++; foo++; would be different in IL code
Tobi: yes
jK: but for syncing it doesn't matter
jK: so it is a false positive
Tobi: but as long as you take small steps (not too many mono releases at the same time) and you don't have too much code you can do it
Tobi: OpenRA also has nice architecture for units (instead of our ugly unitdef shit), but it depends on good reflection capabilities afaihs
Tobi: *might* be possible in C++ (using CREG or equivalent) but it wouldn't be easy
jK: we already discussed about to use std::map instead of class members but we decided against it (performance & code style wise)
Tobi: that would be equally ugly, architecture wise, imho
Tobi: what they have is more equivalent to small behaviour specific UnitDefs that you can combine at will to form a complete UnitDef
jK: it would allow inheritance etc. that's what I thought you meant with "nice architecture"
Tobi: oh you wanted to make UnitDefs prototype based, sort of?
hoijui: jk didd not want.. i just brought it up as an idea once
Tobi: they call those `behaviour specific UnitDefs' traits
hoijui: basically making it a properties map
Tobi: so you can have a unit for example with CloakableTrait, FlyingTrait, SelfDestructableTrait for a cloakable flying kamikaze unit
hoijui: mm
jK: btw on the lua level such things are possible
jK: but trepan, neither quant wanted them
hoijui: then you can get a list of all friendly units that have SelfDestructableTrait?
Tobi: yes
hoijui: and update is called on all traits?
hoijui: for each unit
Tobi: nah, only on UpdatableTrait I think
zerver: :)
Tobi: so if FlyingTrait needs to do math every frame it could inherit itself from UpdatableTrait
hoijui: ahh ok
hoijui: :D
hoijui: sounds all good
Tobi: I hope I am correct in all I said though, I didn't look long in their code but I think it works like this
hoijui: but jk coudl never accept that.. too much virtual
hoijui: :D
Tobi: afk for a bit
jK: I would prefer a template approach in spring we the template updates all instances instead if updating on per instance level
BrainDamage: is this about making a single unit/feature/tree entity?
jK: -we +where
Tobi: no, actually splitting
hoijui: well.. that woudl liekly be a side efect, yes
jK: -> 1 update vs. 100 updates + no virtual functions -> win
hoijui: or .. would have to be done in advance
hoijui: 1000 times more guly code
hoijui: cause of templates
hoijui: ugly

Safe multithreading in sim via marking threadsafe functions like you do with const funcs?
jK: data driven approach can be multithreaded *much* easier -> win^2
zerver: u mean multithread the sim?
hoijui: you mean one update function per updateable trait?
jK: yup
jK: yup
zerver: synced lua is a huge problem for multithreading of the sim
jK: no it's not
zerver: without lua, i would start doing it tomorrow
hoijui: that sounds good...
hoijui: but i dont see why it needstemplates
hoijui: needs templates*
jK: when you multithread sim you would no matter what reduce your multithreading to >extreme< small code parts e.g. updating the whole MoveAI in thread is devils work and impossible to debug in case of problems
hoijui: i mean.. it can be doen as tobi explained, but hte updating coudl still be done as yo udescribed
jK: instead you need to split it up into small parts, like: DetectCollision, UpdatePos, UpdateMoveParams, ...
zerver: sure, anything that does not invoke synced lua can be threaded
jK: even those lua calls can be moved to the end which needs to be serialized no matter what
zerver: problem is finding the lua free parts :)
zerver: lua is everywhere
jK: e.g. multithreaded collision detection gives you multiple collision possibilities, so you need a single threaded part of code at the end which decided which is the correct one
zerver: y
jK: so lua calls aren't really a problem, the problem is to isolate code, so you can be 100% sure it is threadsafe
jK: I even thought about to >mark< threadsafe functions somehow and to give an error if you call a not-checked/unsafe function from a different thread
jK: e.g. to initialize some TLS in those threads and to check those, but then you would need to mark unsafe functions -> ways too buggy and much work
jK: doing it on compiler/linker level would be nice, but I don't see a way to do it there :/
jK: (similar to the `const` function checking in c++)
jK: const/thread functions could just make calls to const/thread functions
Tobi: sounds like we already have 2 use cases for user defined propagation passes in the compiler
Tobi: I wanted long ago to use such a thing to infer variables/members that must be synced/unsynced due to the way they are used in calculations with other vars/members
jK: are there tools for that?
Tobi: to be able to basically make it impossible to e.g. use an unsynced var anywhere in a computation whose final result gets stored in a synced var
zerver: the way i see it, synced lua must be somhow restricted for MT sim to be feasible at all
Tobi: there are generic tools for analyzing code and running transformations/analyses on it
Tobi: but usually c++'s grammar is a bit of a problem to quickly use them on c++ projects
hoijui: sounds like making a custom frontend with LLVM could do this trick
hoijui: maybe
jK: Perhaps I should write a letter to some c++0x guy, imo it is similar important to `const functions`
hoijui: :D
jK: and c++0x wants to be multithreading friendly and miss it :)
Kloot: meh, it will be another 10 years before that standard is finalized anyway
BrainDamage: i am still pissed for the lack of modules
BrainDamage: sooo much stupid code is written because of it
jK: you don't need to wait till it is finalized to use it, many things in it are already usable (std::mutex, ...)
jK: esp. because they just copied boost ^^
Tobi: are lambdas and inference already in the major compilers?
Tobi: (read: msvc and gcc)
zerver: not sure, but I doubt it
jK: "New wording for C++0x lambdas N2927 Yes"
jK: -> http://gcc.gnu.org/gcc-4.7/cxx0x_status.html
zerver: lambdas are probably easier to implement than inference
Tobi: other way around
Tobi: that type information was available anyway because the compiler had to check it
Tobi: + no need to change anything in any pass after the type check

Release
BrainDamage: since the discussion is kinda dead: is there any stopping bug for a "serious" test release?
BrainDamage: by serious, i mean one announced in news section
BrainDamage: or implement first the branching rules?
Tobi: I think that
hoijui: yes
hoijui: the one we have now is to get game devs to release comaptible versions
hoijui: i think nobody did that so far
zerver: because we did not release hard and often
BrainDamage: tbh, everyone hardly notices test versions when they are on news page
BrainDamage: let alone a simple post in dev forums
hoijui: well licho knows, behe knows, smoth knows, flozi knows
hoijui: -> ZK, GD, BA, S44
hoijui: no releases
BrainDamage: more than no releases, 0 feedback
hoijui: mmm
hoijui: licho made about 2 mantis reports i think.. thats it
hoijui: ah.. flozi did som testing.. but i think that was before the testing release even
zerver: behe did some mantis reports too, also before the testing release
hoijui: one was a bug in S44 lua, the other thing was fixed by kloot one not long ago
hoijui: mm
Kloot: by now it's established that voluntary test releases do not give the level of feedback we need
Kloot: s/give/result in
hoijui: for abusing a real release as testing release, as we alwyas do it, we should really have multi version support through the lobby
hoijui: aegis said he has it done
Kloot: you really think users would take the time and not just stick with 82.7?
hoijui: yes
hoijui: "new version!! i need it!"
BrainDamage: yeah, no
BrainDamage: esp since they'd quickly discover the rest doesn't uses it
BrainDamage: and go back to 82.7
Tobi: just need the pattern we used for the last releases imo: "we'll deploy this at july 8th unless some major issues have been found before then" (for plausable deniability
BrainDamage: see dsd, being the most popular gives enough inertia to keep it self sustaining
BrainDamage: exactly
BrainDamage: even if multiple spring versions would be supported, there should still be a min version so you enforce upgrade at some point
Tobi: could add a `if (build date is more than 6 months ago) abort()'
zerver: i agree :)
hoijui: we just dont accept bug reports for old releases
Tobi: +1
hoijui: anyway... i am kind of shocked to hear what you say
hoijui: if nobody starts to use the new version, it is none of our business
hoijui: no problem for us
Tobi: it's an advantage even since we can't get any bugreports anymore :s
BrainDamage: so you're saying you don't mind your work going wasted?
hoijui: i am sure it will not be wasted
hoijui: the effect of multi version is, that it takes some time after a release for the release to get the main version
BrainDamage: i'm pretty jaded about people doing the right thing seeing so much sheeple mentality around
hoijui: that is not a problem, but desirable
hoijui: map and game devs want ot use new versions
hoijui: cause of new shineiness on map
hoijui: cooler shadows
hoijui: new lua functiosn they need
BrainDamage: but players want to play
BrainDamage: not dev
hoijui: after soem time, the optimal version to play the mod is the new engien version
hoijui: and then players will use it too
hoijui: it is inevitable
hoijui: soem games will be slower in adapting to new versions
hoijui: which is again ok
BrainDamage: the question is the time
BrainDamage: if the average is an acceptable time frame, ok
BrainDamage: but you don't know beforehand, and you cannot control it
hoijui: it cant be a problem for us, cause we move on in our pace
hoijui: exactly
Tobi: we can influence it through the way we deal with e.g. bug reports
hoijui: yeah exactly
Tobi: and feature requests
BrainDamage: then you start a nightmare for everyone
hoijui: if some version is so stable that no bug reports come in, we have no problem if people still use it 2 years later
Kloot: it IS a problem because the new engine version becomes a breeding ground for unfound bugs
hoijui: btw kloot, why did you stop checkign your commits for compile errors?
zerver: the bug reports for the new versions may come in at an extremely slow rate
hoijui: seems liek you dont compiel at all, anymore
Kloot: if it does not get the critical mass of players bheind it in an acceptable timeframe
BrainDamage: don't shift subject please
Kloot: (because recompiling is slower on my old machine than on the buildbot)
BrainDamage: say some exploit/whatever is found in new version, players/modders will roll back, but then what can you do? release another version? then you should patch just the bug
zerver: i wish we still had "scons -j8"
BrainDamage: and nothing else
BrainDamage: or you'll risk introducing more bugs, repeating the cycle
hoijui: aehh yeah..
hoijui: tahts how it always was, BD
BrainDamage: it NEVER was like this
BrainDamage: all sort of shit was added, not simply fixed, even in minor releases
hoijui: yeah, but you are talking abotu a hotfix/ptach
hoijui: patch
BrainDamage: so while amount of bugs was asymptotically decreasing, it was never monotone :p
hoijui: in the end, what you suggest can not be proven or disproven by hard facts
Tobi: I think it will be good to try it
hoijui: its only "i believe" stuff
hoijui: yeah
Tobi: and it should be good incentive to actually keep the feature/bug ratio at a decent level
hoijui: hard facts are only, that it is better for the guy doign the releases
BrainDamage: [ARP]hoijui_g5: sorry? i gave plenty of historical evidence i think
hoijui: adn i am sure all game devs will welcome it too
Kloot: fact: the more code gets added, the more bugs get introduced
hoijui: you cant put historical evidence against an idea that was never tried
BrainDamage: there's several analogue case, like BA versions that simply weren't adopted because there was the chance to
hoijui: .. which is a godo thing!
hoijui: good*
hoijui: you arguemtn that multi version support si bad casue people will use multiple versions
BrainDamage: no
BrainDamage: you misunderstood me
BrainDamage: my argument is against multiple version without an expiration date you cannot set
BrainDamage: ie min version enforcement
BrainDamage: then you can set the min version even of the version of 2 years before
zerver: maybe let games define a minimum acceptable engine version?
BrainDamage: but still a min version
hoijui: it woudl only make sense if engien devs can decide over that
BrainDamage: it'd be a lobby-wide min version
BrainDamage: set by engine devs
hoijui: sure.. i woudl be fine wiht that :D
zerver: so this hot new 8v8BADSD comes out, but it wont run without 0.83... maybe ppl will upgrade then
hoijui: but someone has tp push this stuff in the lobby community
Tobi: yes that is what you want, to decouple game updates from engine updates
hoijui: i tried but... i am clearly not able to do that
hoijui: or say.. the wrong guy
hoijui: everyone else seems to be too lazy to do anything that is not strictly technical
hoijui: in the engien, we have kloot, jk and zerver who do practically only code work, and tobi, abma and me who do more of the organizing stuff
hoijui: in lobby world there seem to be only of the first kind
BrainDamage: the problem is that nearly every change has to go trough server
hoijui: yeah.. that was a problem for me, communicating with aegis....
hoijui: but everyone else has no problme with him, so.... ?
BrainDamage: i cannot coherce anyone into doing work :p i guess i could write the patch myself, but there's several discouraging factors such as completely unfamilliar with the server codebase, and the fact that not just the patch needs to be applied, it'd have to be adopted in the main server as well
hoijui: in practise, it coudl probably really only be aegis, who woudl have to organize it all
BrainDamage: and the latter usually brings up a lot of retrocompatibility discussions
hoijui: well.. aegis claims it is there already since a long time
hoijui: he just had to switch it on.. or he even did already
hoijui: as i siad, the problme is not the codework
hoijui: but the organization
hoijui: someone had to inform eveyrone .. eg all lobby devs
hoijui: get them to agree, accept it
hoijui: make a deadline
BrainDamage: i am not aware of such thing implemented, i am no mind reader
hoijui: ...
hoijui: just what i am saying
BrainDamage: yes, i did not see your text while i was typing mine >_>
hoijui: aegis seems to eb of kind #1 ... which is nothing bad of course.. but .. very unfortunate for lobby land .. him beeing in this position
zerver: we could make it so that if a game does not specify a minimum acceptable engine version, it will refuse to run on anything but the latest engine
zerver: this way, in the next release, we are guaranteed to have action as usual
hoijui: even if we had someone who would do the organizing and be qualified... how woudl he proove it.. he would have no rights.. no weight.. nobody woudl listen
hoijui: .. thas what i dont want, zerver
zerver: but in subsequent releases, there will be zero action
zerver: 0.84 will go unnoticed haha
Kloot: this discussion can be c/p'ed as an answer to a certain one of that gamasutra dude's questions
Tobi: also that kind of requires the engine to be able to determine whether there are new releases of itself
hoijui: you are like where we were 20 mins ago, zerver
zerver: omgwtfbbq
Tobi: lol I think I am totally proving that registering *is* painful
hoijui: painful?
Tobi: </offtopic>
hoijui: well.. the lobby organizing problem is over too, i guess
hoijui: there is a problme, but no solution...
Tobi: all kinds of STL stuff throwing random exceptions at me seemingly because I use them before main...
hoijui: /
hoijui: ehhe :D
hoijui: before main?
hoijui: dirty fellow you! :D
hoijui: ahh.. auto registering..
hoijui: hehe
Tobi: yes
hoijui: ..there was this austrian guy once.. new.. soemthing
hoijui: who wnated to push lobby stuff..
hoijui: but as he was jsut soem outsider.. nobody cared (partly, rightfully so of course)
hoijui: will you guys do an etherpad with questions for a combined email now?
hoijui: .. you already started?
zerver: gotta split
<< zerver left!
hoijui: i have to sleep too
hoijui: cu
<< hoijui left!
jK: etherpad.springrts.com/NON_PUBLIC
Kloot: any deadline for those btw?
Tobi: next meeting?
jK: he made that thread 21., next meeting could be a bit late
jK: I would aim this weekend ~saturday
Tobi: sure
BrainDamage: a workable business model wrt open source dev would mandate a strict collaboration with neurodepressant farmaceutical companies, because of all the grief regularry generated
Kloot: that or really big paychecks
jK: sell Spring to US Army for war tactics training? >_<
Kloot: they dont want officers who only know what to do on DSD
jK: or wait till google buys games?
jK: lol

[smoth]

Re: testing dev branches:
I do test and I did pop in channel looking for you several times. One of them I talked to jk.

My quandry is that I have my own bugs to track down as well as bugs in the current engine(see that freaky pathing image I posted in help an bugs).

As a conent dev I have many things I have to pour over not just engine so please don't think I don't care. In fact I was pretty clear when I started my new job that I would be strapped for time. I cannot snowball test for you guys like I did before because I do not have 16 hours a day anymore. I am lucky if I get 3 hours a day right now. So before I can test the engine I have to adopt all the new lua and make the .n changes as well. I do intend on helping, but I am strapped for time. I also asked if someone could pm me when you guys are in need of critical testing. I have not heard this yet so I continued work on knew features for gundam.

In fact I was going to work on my site and a hotfixx this weekend.... So are you guys at a rc now or are you still working on stuff that you KNOW is broken? Because I was under the impression of the latter

[Google_Frog]

Like smoth I assume the engine is still in the bugfixing stage with known or easy to find bugs.

Have you discovered the type of article the magazine guy wants? Because (somewhat unfortunately) engine development and game development exist sort of separately and he may not be aware of this. It would be silly if he interviewed engine devs and asked questions about 'the game'.

I would like multiple engine version support, it would at least provide a sort of accountability for engine releases that don't visibly improve anything while breaking others. We occasionally considered using 0.82.4 because the versions after that have broken and slow pathing and multiple other things were simply broken. But while ZK-Lobby supports multiple engine versions TASC and SL don't. turnInPlace=0 made half the units annoying to use.

Apparently turnInPlace=0 is fixed for 0.83 and the pathing isn't as slow so I'm hoping for a release soon, as long as nothing else is randomly broken.

[knorke]

hoijui: and he sent me some qeustions i will respond to now
hoijui: yeah that
hoijui: anyone interested in hte questions?

can you put them online? I would like to see them.
I emailed him too btw, saying that I have no idea on how the engine works but was making some game. Hope that did not confuse him.

[Licho]

It would also be easier to test multiple engine versions, if spring-dedicated didnt need mod/map hash in script - or if hashes it needs were god damn engine independent.

And don't tell me again its lobby server issue, its not, spring-dedicated needs it!

[Kloot]

if spring-dedicated didnt need mod/map hash in script

IT. DOES. NOT. NEED. THEM.

Code: Select all

    //  Use script provided hashes if they exist
    if (gameSetup->mapHash != 0) {
        data.SetMapChecksum(gameSetup->mapHash);
    } else {
        data.SetMapChecksum(
          archiveScanner->GetArchiveCompleteChecksum(gameSetup->mapName)
        );
    }
    ...
    if (gameSetup->modHash != 0) {
        data.SetModChecksum(gameSetup->modHash);
    } else {
        const std::string& modArchive =
          archiveScanner->ArchiveFromName(gameSetup->modName);
        const unsigned int modCheckSum =
          archiveScanner->GetArchiveCompleteChecksum(modArchive);
        data.SetModChecksum(modCheckSum);
    }

For fuck's sake, shut up about this already.

[Licho]

Thanks you for notifying me about trying to address this issue, however im not a fucking telepath and I dont know whats in your head!!

Deal with it and stop being angry!

My 7 months old ticket is still open with 0 comments:

http://springrts.com/mantis/view.php?id=2268

Also how will this work in dedicated server which has no map/mod file almost by definition??

[hoijui]

This code was added in f094c483ff8f6a93a80f2ed766086e97df249227
on 2008-10-16. It was in spring 0.77b5.

So first you complain about always getting the same answer, and now about not getting that same answer in that one spot?

should we close that report, or just add a note that it is a lobby issue?

[Licho]

Or to paraphrase you
YOUR. CODE. SHOWS. NOTHING. USEFUL

Dedicated server as no mod/map file or hash knowledge (it wont work if you ask archive scanner for the hashes)

There has to be way to DISABLE CHECK AGAINST DEDICATED HOST not to switch dedicated server server to use scanner..

[zwzsg]

Syncing in other games
zerver: RTS needs a synced sim, FPS does not
hoijui: i though it is a rather little used approach?
hoijui: as in.. mostly TA and supreme commadner

FYI, TA doesn't run a full synced sim like Spring:

• In TA, some events, such as the destruction of units, or the creation of weapon shots, can only be performed by the unit owner.
• In TA, the position (and I guess other states) of every unit is periodically resent to other players.
• In TA, the unit scripts can be playing totally different animation on every machine (and TA won't care).

[smoth]

And TA online was shitty for it lag flashes and all that

[zwzsg]

In 1995, when you had a poor dial-up, and insisted on playing metal heck with 30 build time, maybe.

Otherwise it was, no, it is, a great online game still played today.

[AF]

I think it was more that if you crash out, everyone else was booted out too and the game ended, though I remember there were changes made towards helping disconnects

[zwzsg]

But during the timeout, or if the connexion was bad but not plain disconnected, then would see stuff like:

• Enemy units standing still, not firing at you enemy, and that you could damage down to 0 health but not kill.
• Units finished yet flashing their edges like nanoframe, appearing at 0,0 and moving through every obstacle. Then instajumping to their real position.

Some of my very advanced TA unit scripts worked fine in solo, but failed in multi, until I investigate and took into account difference between units owned by local or remote player:[list]
[*] Callins such as QueryNanoPiece, TransportDrop, TransportPickup, TargetCleared are only called for the unit owned by local computer.
[*] rand() yeld a different result for each player.[/list]

[zerver]

In 1995, when you had a poor dial-up, and insisted on playing metal heck with 30 build time, maybe.

Otherwise it was, no, it is, a great online game still played today.

It was okay on LAN, but on 56k dial up even a medium sized 1v1 games were pretty unresponsive.

And there was this bug with coms showing up at the wrong location during the first 5 mins of game, and if you dgunned that "ghost" com you would win the game. I'm so surprised Cavedog never fixed that problem before it went bankrupt, people must have reported the issue numerous times.