Dev meeting minutes 2010-06-27

Dev meeting minutes 2010-06-27

Minutes of the meetings between Spring developers are archived here.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Dev meeting minutes 2010-06-27

Post by hoijui »

Date: Sunday, 27. June 2010 (2010-06-27)
Present: hoijui, jK, Tobi, zerver

_Agenda_____________________________________________________________________
  • Welcome
  • Progress of stuff to be done before release
  • GPL (progress)
  • OS X (progress)
  • MT / LUA
  • Buildbot progress
  • HL header handling (gl*.h, SDL.h)
  • Next meeting
  • Anything else? (WVTTK)

_Main Conclusions___________________________________________________________

  • jk will do pre-release this week with an *rc tag
  • OS X: spring compiles, daftalx got spring-gml to compile by installing mesa
  • GML: instead of including GL.h it should include glext.h on OS X
  • GML: LUA draw call-ins slow down the game a lot
  • buildbot: Tobi switched to ubuntu lucid for the buildbot: newer much more efficient mingw (4.4.2)
  • buildbot: only default is built by default (not debug & syncdebug)
  • HL: copy gl*.h and SDL*.h headers to an include/ dir in the spring repo




_The meeting________________________________________________________________


Progress of stuff to be done before release
hoijui: for me, it is only these bugs, which we declared as memory bugs (plus the path finder one, in case it is a different one)
hoijui: but as we said, we would do the pre-release before they are fixed
Tobi: I fixed buildbot a bit more on monday (newer, much more efficient mingw) and didn't do any other spring things yet due to exams next week and other RL things
hoijui: ok :-)
Tobi: yeah, originally I planned to do that on monday, but that ended up being buildbot improvement day :P
jk: Can I make a RC this week?
zerver: I didnt yet experience that memory corruption crash, so maybe it is AI related?
Tobi: [LCC]jK: that would be fine with me
hoijui: how did you test?
hoijui: and as i said, it happend with different AIs
zerver: Just load testing basically,lots of units lots of action
Tobi: [LCC]jK: do you want to make a rc like in the past releases, that has version 0.82?
Tobi: or just release a certain buildbot build as rc?
jk: I would like to tag it 0.82RC
jk: (for linux users)
Tobi: hmm ok
hoijui: i guess that coudl cause problems in some parts
hoijui: as so far, we used only numbers
hoijui: in the common format
Tobi: yeah I was wondering already why we didn't use 0.81rc etc. in the past
hoijui: mm
hoijui: maybe just try, and fix what does not work ;-)
jk: any idea what could break
hoijui: zerver, how did you test?
Tobi: one thing I know are the regexes in buildbot :-)
Tobi: (and BuildServ)
jk: or is it just general skepticism?
zerver: Well, I spam "give all" like I usually do
Tobi: but that should be easy to fix
hoijui: installer generator, source packages, version comparison algos
zerver: and make lots of action
hoijui: ahh ok
jk: ah stacktrace translator
hoijui: .. ahh yeah true
hoijui: i mean.. maybe it woudl all work.. i dont know ;-)
hoijui: zerver, i will try that too then. you use a NullAI?
hoijui: :D
zerver: just start up with commanders start script
hoijui: why do you try to build that, jk?
hoijui: will never work due ot mingwlib changes
jk: ahh true
hoijui: zerver, ok :-)
jk: still it's a RC, so it doesn't matter that much when the tagging doesn't work as expected
Tobi: I think it's ok to try it, if some stuff is broken on tuesday/wednesday I might be able to take a short look
Tobi: if it's just updating a few regexes then that should be ok
Tobi: I've never really liked using 'major' version numbers for RCs
hoijui: it also needs changeing in GameVersion, right?
jk: yup
hoijui: in addition to the tag
hoijui: ok
hoijui: so.. next topic?
zerver: Yeah, I have nothing against the RC being made
zerver: reconnection is tested and seems to work
Tobi: ok

main points:
  • Tobi has fixed buildbot a bit more on monday (newer, much more efficient mingw)
  • jk will do pre-release this week with an *rc tag
  • hoijui will check for mem-corruption bug with comamdner script and /give all * n





GPL (progress)
jk: I assume, no progress here cause of RL?
Tobi: indeed, all my spring stuff is on hold temporarily until after exams :-)
jk: didn't worked on it either ^^
Tobi: well at least until after monday

main points:
  • there was no progess this week




OS X (progress)
Tobi: I know that, spring compiles, daftalx got spring-gml to compile by installing mesa
zerver: ok
Tobi: no clue why spring those dependencies differed between spring and spring-gml
zerver: strange
Tobi: and also no clue whether it linking to mesa means it always software GL
zerver: that will be fast
Tobi: (the error was that it couldn't find library -lGL )
jk: hmmmm
Tobi: he is still looking at compile errors in spring-hl
Tobi: Linking CXX executable ../../../spring-mt
Tobi: ld: library not found for -lGL
jk: perhaps GML links to gl.h? which is mostly totally outdated on most platforms
Tobi: that was spring-mt error
Tobi: see also: http://springrts.com:7778/builders/full ... logs/stdio
Tobi: there are also all the spring-hl errors
Tobi: probably most due to
Tobi: /buildbot/spring/full-macosx/build/rts/lib/headlessStubs/glewstub.h:8:20: error: GL/glu.h: No such file or directory
Tobi: /buildbot/spring/full-macosx/build/rts/lib/headlessStubs/glewstub.h:9:22: error: GL/glext.h: No such file or directory
jk: instead of linking to GL.h it should link to glext.h
zerver: ok, will check it
Tobi: s/linking/including/ ?
zerver: i guess you mean include?
jk: yeah
Tobi: ok
zerver: because MT contains no linker directives in code afaik ;)
zerver: pragma shit or such...
jk: /buildbot/spring/full-macosx/build/rts/lib/headlessStubs/glewstub.h:9:22: error: GL/glext.h: No such file or directory < this is strange
jk: perhaps it is the other way around
Tobi: I suppose it can be figured out at some point

main points:
  • spring compiles, daftalx got spring-gml to compile by installing mesa
  • GML: instead of including GL.h it should include glext.h on OS X




MT / LUA
zerver: ok well just a quick thought about ways to make MT more noob friendly
zerver: it has issues with LUA draw call-ins slowing down the whole game
zerver: so my thought was whether to by default disable all such call-ins for MT
zerver: and the user has to enable it via confighandler
jk: o_O
zerver: the question is if this gives more or less bug reports
Tobi: doesn't that imply mt will only be useful with BA?
jk: sorry, but when you starting this, then MT becomes a half spring engine and so it shouldn't be included with the installer anymore
Tobi: since ppl wont know about hidden config settings and many other games use some form of Lua draw
zerver: ok
Tobi: how big is this performance impact?
zerver: it depends
zerver: if you turn on xrayshader, teamplatter and such widgets, you might as well run single thread instead
Tobi: but, performance doesn't get worse than single thread?
zerver: much worse
zerver: game is down to a crawl
Tobi: ouch
zerver: draw thread keeps locking mutexes and sim comes to a near complete halt...
zerver: and tbh I have no idea how to remedy this
zerver: other than to make the LUA code MT aware
jk: using a SceneGraph
zerver: ok, well, maybe not such a good idea to disable draw callins then
zerver: was just a thought
Tobi: well, I think putting some note about this in readme or on download page or so is good enough
zerver: yes, problem is no one reads that
zerver: maybe a pop-up messabe on first game start?
zerver: message
Tobi: if performance is slow they might read it :-)
jk: that's why I disliked renamed spring-gml to spring-mt
zerver: yeah
jk: *ing
zerver: why you dislike rename to MT?
zerver: this problem is not GML related
jk: because noobs would think "HEY COOL multithreaded! I must use it!" w/o reading any notes or similar stuff
jk: noobs think multithreaded = 3x faster
zerver: well, after lagging out of 10 games maybe they read notes :P
Tobi: well since they have to manually configure lobby to start spring-mt they would know how to reset it to spring.exe
hoijui: damn.. sorry, had to leave for some minutes
Tobi: np
Tobi: we just reordered some stuff
hoijui: ah k :D
zerver: WRT the MT thing, I think I will add a logOutput print with that performance warning at game start
jk: add a read text to the loadingscreen?
zerver: yeah, or that
jk: *red
zerver: but noob may have uber fast machine that loads instantly
jk: o_O
hoijui: so basically, only people wiht low tech HW should use MT, and only when playing BA?
zerver: nope, I have a good system and cannot live without MT
zerver: it is so much more responsive when game grows big

main points:
  • in GML, LUA draw call-ins slow down the game a lot
  • zerver will add a logOutput print for MT, with a performance warning at game start
  • zerver can not live without MT




Buildbot progress
Tobi: I put it in a ubuntu lucid (10.4) chroot, has newer much more efficient mingw
Tobi: also I made some preparations for allowing user to choose what profile he wants to build
Tobi: and build only default by default, to save some resources
Tobi: that's it
jk: Tobi, does gcc still uses (too) much memory when linking?
jk: or is it fixed with this?
Tobi: fixed with this
jk: nice :)
Tobi: now uses similar amounts as on my Fedora box
Tobi: so it was really mingw-gcc 4.2.1 issue
Tobi: now it's 4.4.2

main points:
  • Tobi switched to ubuntu lucid for the buildbot: newer much more efficient mingw (4.4.2)
  • only default is built by default (not debug & syncdebug)




HL header handling (gl*.h, SDL.h)
hoijui: spring-hl currently depends on these headers beeing supplied by the system (on linux)
hoijui: which is .. not optimal
hoijui: one option is, copying them into headlessStubs dir
jk: that would fix macosx compiling too
hoijui: ahh..
hoijui: :D
hoijui: sold?
jk: still I dislike it somehow to have unchanged shared files in the trunk
Tobi: but, spring itself needs those headers too
jk: sure they are OS-independent (in contrast to most mingwlibs) still ...
Tobi: so if spring compiles then macosx should be able to compile too with the system wide headers
Tobi: *macosx spring-hl
hoijui: then lets look at it independently of that
hoijui: an alternative woudl be, having a linuxlib package
hoijui: with just these headers
hoijui: but the i liek the headlessStubs way more
hoijui: .. or .. are there other ways?
jk: copying them to rts/lib/ is a no-go for me
hoijui: where then?
jk: create a new include dir in the base-folder or something like that
hoijui: mmm
hoijui: ok

main points:
  • copy gl*.h and SDL*.h headers to an include/ dir in the spring repo, for HL




Next meeting
(same again, next week, 16:00 CET)



Anything else? (WVTTK)
zerver: Your stubs are dummy functions that do nothing, right?
hoijui: yes
zerver: Thing is, GML already has such stubs already.
jk: still they need glext.h for the definitions
zerver: So GML could easily be reconfigured to get the same behavior as your stubs
hoijui: mmm
hoijui: you really have all gl* functions subbed?
hoijui: i mena.. osme of them need to return stuff
hoijui: or say.. i would not want to do that ;-)
zerver: I return NULL :)
zerver: or 0
hoijui: in some, we also set the value of a parameter pointer
hoijui: dont know if it crashes wihtout that
jk: shouldn't matter what you return
zerver: ok, it was just a thought that maybe we are doing the same work twice
hoijui: yeah.. i dont know
jk: using the gml-code for it, would reduce the work to maintain it a lot
hoijui: yeah
hoijui: still.. i dont wnat to do that ;-)
zerver: ok, never mind
hoijui: done enough of that shit for some months
hoijui: ill do the include/ dir, with a readme in there or something
hoijui: next
hoijui: end?
Tobi: hey I'm off to catch the train, laters
hoijui: Tobi.. arent you late?
hoijui: ok :-)
Tobi: I'm avail next week this time
hoijui: bye!
Tobi: laters
** Tobi left the channel( Quit ).
jk: caio
hoijui: ok :-)
jk: hardware cursor?
zerver: yes
hoijui: well.. i have to admit, it also gets very unresponsive here in late game (debug build), also with HW cursor
hoijui: hmm..
hoijui: or..
zerver: ST framerate can drop to 5, MT below 20fps is extremely rare
jk: hmm mouse was pretty unresponsive in 80-81 because mouse pos was checked each videoframe instead of using the coords in the OS's mousemove events
hoijui: yeah
jk: but that's fixed in 82
zerver: ah, that sucked
zerver: i noticed that gui buttons trigger pressed even on mouse release
hoijui: for me, i felt it is worse in master then in release
zerver: event
hoijui: might also have to do wiht it beeing debug
zerver: so if you click outside a button and then drag it onto the button and release, the click is registered
hoijui: in late game, i have to press for over a second on a button, for it to trigger
zerver: not so good...
hoijui: thats when hte game is very laggy already of course
jk: under linux it still uses SDL, which checks mouse pos also ... in a bad way
hoijui: with ST
hoijui: single
zerver: there are many things to improve obviously
zerver: this is the type of annoyances im looking at right now
jk: I wanted to lurk into X11 event system, but it doesn't seems as easy as for winapi
hoijui: ahh ok
jk: -s +to be
jk: that's why I hate SDL, it gives rarelly and you need to write hacks for everything
zerver: :)
hoijui: hmm
hoijui: could you get rid of SDL if you woudl not need it for the mouse anymore under linux?
hoijui: most used seems to be SDL_GetTicks, which is easy replaceable
zerver: yep, dont use boost though
zerver: because that one sucked real bad
hoijui: HL uses boost
hoijui: its inacurate under windows?
zerver: the boost microsec timer has 15ms resolution
zerver: totally useless
hoijui: HL uses microseconds + nanoseconds
hoijui: guess it would be ok then?
zerver: have to see the code
zerver: in windows multimedia timers are very good
zerver: if your hw supports them, that is
hoijui: http://sl.pastebin.com/ZETgeTx3
hoijui: well.. rts/lib/headlessStubs/sdlstub_cppbit.cpp
hoijui: :D
zerver: ok, cannot say if boost xtime is good, have not tested it
zerver: i suggest you make a loop and output the time to cmdline to see if resolution is good
hoijui: mm.. i am on linux though :D
hoijui: but may test that one day
zerver: i can test it for you, np
zerver: end of meeting then?
zerver: does anyone write minutes?
hoijui: ok..
hoijui: yes me
hoijui: hmm..
hoijui: http://www.boost.org/doc/libs/1_32_0/do ... xtime.html
hoijui: the "Note"
hoijui: looks like it coudl be the 15ms thing again
jk: "For maximum portability, avoid durations of less than one second."
jk: lol
hoijui: "For maximum portability, avoid durations of less than one second."
hoijui: .. :D
hoijui: yeah
zerver: This is a temporary solution that will be replaced by a more robust time library once available
hoijui: well.. anyway... if this function is the only thing left we use of SDL.. it will be solved i guess
jk: we use SDL for window events
hoijui: ahh ok
jk: so removing SDL is a much bigger project
jk: esp.since Auswaschbar used SDL event structs in aGUI directly ...
hoijui: uhh :/
jk: I told him it is a bad idea, but he didn't listed
hoijui: :D
zerver: and we use SDL for keyboard stuff
zerver: and mouse ofc
jk: sure, but we couldn't implement all the things SDL does ourself
jk: we would need to switch to SFML or similar
hoijui: yeah.. nm.. no need for that
hoijui: now
zerver: k, lets how for a RC real soon then
zerver: bye
zerver: *hope

main points:
  • SDL will not be repalced soon/ever

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7049
Joined: 16 Nov 2004, 13:08

Re: Dev meeting minutes 2010-06-27

Post by zwzsg »

So, after years of being told to use Lua, we're now told Spring will from now on ignore all our Lua?

Yes, only Lua drawings, and only in MT, but that's still game-breaking.
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-06-27

Post by zerver »

As you know, the LUA code is currently single threaded and therefore any attempt to run it in two theads will give rise to major problems.

The above was just a suggestion on my side to make sure newbies understand the current limitations of MT. But we decided it was not a good idea. Instead there will be some kind of you-cannot-miss-it notification.
luckywaldo7
Posts: 1398
Joined: 17 Sep 2008, 04:36

Re: Dev meeting minutes 2010-06-27

Post by luckywaldo7 »

Will it be worthwhile to organize some test games once the release canidate is released?
SeanHeron
Engines Of War Developer
Posts: 614
Joined: 09 Jun 2005, 23:39

Re: Dev meeting minutes 2010-06-27

Post by SeanHeron »

That's generally the idea of Release candidates, yes :) [get some bug-hunting done].

Nice to hear the release candidate is to come soon, looking forward to it! (Thanks as well for these notes - it's great to have a bit of an "inside-perspective" regarding what's going on Engine wise)
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Dev meeting minutes 2010-06-27

Post by Argh »

Tobi: but, performance doesn't get worse than single thread?
zerver: much worse
zerver: game is down to a crawl
Proposal: Spring MT should use the "other processor" for all Lua functions, period.

Then the only Lua-related slowdown should be passing things to the gamestate side, and we don't have to write multiprocessor-aware Lua until the engine can address more than two processors.

Seems like the easiest solution, tbh. Gamecode stuff from Lua that directly effects sim is the smallest amount of Lua in terms of processor demands, generally speaking. Even things like Lua AI are generally designed to be processor-friendly and run as infrequently as possible, or use other load-sharing methods. Most Lua CPU time is actually used for calculations for visuals. So move it to where it needs to go, with the rest of the visual systems, and all that's left is function calls to Spring core, which can be queued up and passed at the end of a cycle.

The only problem there is Unit scripts, especially AimWeapon.

Perhaps it's finally time to have the engine not call AimWeapon every gameframe, but only when the Unit has a valid target and is trying to attack it? Then sim could just send processor 2 a list of the Units that are aiming, the position they're aiming at, and let the Lua side handle all the mechanics from there.
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-06-27

Post by zerver »

Not sure if that would help. Problem is that if the processor is currently executing a heavyweight draw call-in, the sim will still have to wait for it if it needs to execute som lua stuff. This is the exact same problem as the current syncronization "starvation" issue where Draw, also because of higher fps in the MT build, keeps blocking the Sim thread very frequently.

Two separate lua execution environments for sim/draw would help though, but might be awkward for the programmer who wants to share data between the environments.

Another workaround would be to design the call-ins so that they get called multiple times instead of one, and for each call process e.g. a subset of all units. This would shorten the waiting time and allow Sim to proceed.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Dev meeting minutes 2010-06-27

Post by lurker »

With the number of callins that get direct feedback, I don't think moving them to another thread is even remotely workable.

It's simply impossible to take current synced code and run it in parallel. Gadgets have to be able to examine the game state in a completely reproducible way. What you can do is to give gadgets a way to spin off CPU-heavy calculations. What you can't do is make gadgets fully asynchronous, the delays would kill too much.

I wonder how much impact on the widget ecosystem would be had by delayed callins; I'll try to get an idea of this later today.

Tell me a bit about how MT works today. Do Draw calls have access to all callouts? Can the sim state change during a Draw function? Can the sim state change during Update?
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Dev meeting minutes 2010-06-27

Post by jK »

As said the only solution is:
  • a SceneGraph to decouple synced data from render data
  • you copy nearly the full synced data - the unit data like health, LOS-status, .. and not the render related data, that should already be in the SceneGraph - to the thread local storage once per gameframe, so rendering doesn't need lock the synced thread anymore
Both items are quit heavy work :|
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Dev meeting minutes 2010-05-30

Post by lurker »

http://springrts.com/phpbb/viewtopic.php?f=12&t=23174
jK wrote:main points:
  • we will force passwords in script.txt in the future
I don't see this in the chat log/why would this be done? Require a pass to reconnect, sure, but require this to be implemented just to play?
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7049
Joined: 16 Nov 2004, 13:08

Re: Dev meeting minutes 2010-06-27

Post by zwzsg »

And if it changes anything to single player script.txt, I want to know.
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-06-27

Post by zerver »

lurker wrote:Tell me a bit about how MT works today. Do Draw calls have access to all callouts? Can the sim state change during a Draw function? Can the sim state change during Update?
It is basically running fully parallel ATM, except for LUA that is. So yes, Sim state can change during draw and Update. Certain events such as deletion of objects are guaranteed not to happen though.

There is no limitation WRT call-outs. It works the same as single thread.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-06-27

Post by AF »

This article is relevant for those who aren't already aware of it:

http://lua-users.org/wiki/ThreadsTutorial
Chamrin
Posts: 33
Joined: 05 Mar 2010, 12:31

Re: Dev meeting minutes 2010-05-30

Post by Chamrin »

lurker wrote:http://springrts.com/phpbb/viewtopic.php?f=12&t=23174
jK wrote:main points:
  • we will force passwords in script.txt in the future
I don't see this in the chat log/why would this be done? Require a pass to reconnect, sure, but require this to be implemented just to play?
Prevents someone from stealing a players slot if they're slow to connect if they're lagging or something. When it's done right, the player will never notice the difference.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Dev meeting minutes 2010-05-30

Post by lurker »

Chamrin wrote:Prevents someone from stealing a players slot if they're slow to connect if they're lagging or something. When it's done right, the player will never notice the difference.
But why would you force the code to exist on the player? And what do you mean, never notice? Spring won't exactly make you think you're in control of a team when you're not.

jK said the reason things slowed down so much was the MT lua acquiring a lock for every single value it read out of sim, but I can't find where it does this? KDR suggested simply not using read locks where possible, which would be most callouts.
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-05-30

Post by zerver »

lurker wrote:jK said the reason things slowed down so much was the MT lua acquiring a lock for every single value it read out of sim, but I can't find where it does this? KDR suggested simply not using read locks where possible, which would be most callouts.
No that's wrong, it is one lock per call-in. Like I said the problem is mainly because some call-ins take several milliseconds to execute, and this deprives the Sim of precious execution time especially when the frame rate is high.
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-05-30

Post by zerver »

lurker wrote:
Chamrin wrote:Prevents someone from stealing a players slot if they're slow to connect if they're lagging or something. When it's done right, the player will never notice the difference.
But why would you force the code to exist on the player? And what do you mean, never notice? Spring won't exactly make you think you're in control of a team when you're not.
It is mainly because there is practically no difference between a connection and a reconnection. And IMO it has to be forced at some point, otherwise it will never be implemented, and reconnection will remain insecure forever.

What he means by "never notice" is that all password stuff is handled transparently by the lobby system. The user does not need to do anything.
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7049
Joined: 16 Nov 2004, 13:08

Re: Dev meeting minutes 2010-05-30

Post by zwzsg »

I have made code that write startscripts. They are not part of any multiplayer lobby. They are not on Spring's git. You probably have never seen them. Nevertheless, I have one C++ application, and one set of widget & gadget, that generate startscripts.

That is why I request the specification on that startscript evolution.

Of course, I could wait for a new release and see, but I'd rather check now that you aren't forcing something that would only work in multiplayer through SpringLobby. Because I know how easy it is to forget other use cases even exist.
What he means by "never notice" is that all password stuff is handled transparently by the lobby system. The user does not need to do anything.
What if I don't use the lobby system? What if I am not an end user, but a coder writing an app to generate startscripts?

Also, how does it affect replays and single player?
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Dev meeting minutes 2010-06-27

Post by Forboding Angel »

It's a little concerning to me that it seems that about the only considerations given in these meetings seem to be towards *A and BA in particular. It's rather worrisome.

Edit: And I'm not the only content dev who has gotten this vibe.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes 2010-06-27

Post by hoijui »

z: see last two commits:
http://github.com/spring/TASServer/comm ... ptPassword
(they are already in master)

Edit:
Forb, now think about it...
if you were me right now, what (useful) info would you get out of your last post?
"Sorry grand master, for not asking you this morning what are you wishes! a hundred thousand deaths may i die for not reading your mind, and for not taking well care of your suit fruits, ..."
Post Reply

Return to “Meeting Minutes”