Present: jK, Kloot, hoijui, Tobi, abma
Agenda
(sorry some stuff is missing at the beginning, kloot/tobi, please pm me with that)
- desync in newer linux-distributions
conclusion: we couldn't reproduce the desync with current spring-master, so nothing to fix! - anything against an slimmed additional installer? (vs online installer)
conclusion: abma needs some feedback from game/lobby devs about that - guard behaviour extension
conclusion: guarding units should be renamed, as it is confusing (units only follow / help them, but they don't guard!) - messures to allow AIs to deal with the new bandwidth limit
conclusion: needs more testing/ideas
<Kloot>oh right, it is pentethingy
<abma>hi!
<abma>sorry, traffic jam :-/
<abma>[RoX]Tobi: did you find out something about the desyncs in newer linux-distris?
<Tobi>not really yet
<Tobi>[ARP]hoijui_g5 and I tried a game on master with syncdebug, but that did not desync
<Tobi>so either the offending code has been removed/refactored/fixed between 0.82.7.1 and master
<Tobi>or something else caused those test games to sync
<hoijui>yeah, and i do sync in release build, and i have only one gc installed, and did not update it since i setup this machine
<Tobi>because also my gcc package was upgraded I also tried again with release but that still desynced
<abma>aah, ok
<abma>[RoX]Tobi: hoijui and you synced?
<Tobi>yes
<hoijui>in master
<abma>ok... then strange
<Tobi>so it may be in master the issue isn't present anymore
<Tobi>could be a miscompile in some code removed since then or so
<Tobi>or an undefined behaviour which we relied upon, which used to work but doesn't anymore in 4.6 and has been fixed in master
<Tobi>in short: needs more testing to draw real conclusions
<abma>ok, then making some more test-games should be fine...
<abma>yep
<abma>:)
<hoijui>maybe we concentrate on other problems, until we have the first test release
<hoijui>then we try to find some guys with different modern distros, and have a test game
<hoijui>and if no problem, we consider it fixed in master
<hoijui>that would be quite little work
<Tobi>I can join some test game too at some point
<hoijui>ok
<hoijui>ah one thing...
<hoijui>wehn refferign to other comits in a commit message
<hoijui>it qoudl be godo to quote the message (and optionally give the SHA1 in addition)
<hoijui>as the SHa changes when mergeing (which happens often when kloot pushes)
<hoijui>plus the message is easier t osearch by eye, and should already give a good idea what the commit was about by nature (without having to go to the comit itsself)
<hoijui>this last comit of zerver now is a perfect exampel why sha1 only is suboptimal
<Tobi>no commit hash doesn't change when merging, only when rebasing
<hoijui>ah ok
<hoijui>:D
<abma>afaik when rebasing only local commits change
<hoijui>yeah.. that would happen quite rarely then
<abma>if you want to change a remote sha1 you've to do a forced push
<abma>but i'm very unsure about that :D
<hoijui>yeha that is basically right
<hoijui>still its better to quote the mesage instead of the SHA1 as primary reference
<hoijui>both do no harm either
<hoijui>git itsself does it this way too, when reverting a comit, for example
<hoijui>(the default generated message)
<hoijui>next!
anything against an slimmed additional installer? (vs online installer)
<hoijui>so how would the fat isntaller include the slim one?
<hoijui>i guess thats only .. configuraton/nsis file wise?
<hoijui>or the fat installer actually contaisn the slim one, and runs ?
<jK>doesn't nsis creates zip files in the exe, which could theoretically just unpacked?
<hoijui>no
<hoijui>you can run code/logic at install time
<abma>7zip can open the installer, you can upack files from there
<abma>but filestructure is a bit different
<jK>if that is too complexe you can still add a quite mode to the slim one and execute it from the fat one w/o showing a GUI
<jK>*quiet
<abma>yep, thats the idea...
<jK>or why don't make just 1 nsis config and build 2 installer from it (via defines like in c)
<abma>maybe includes should be enough
<abma>uh damn, i'm to busy, i didn't see topic start, sorry :D
<abma>yes, that is the idea: create a slim installer, that has command-line switches, which allows unattended install
<abma>the fat-one then will call the slim-installer
<hoijui>thats not the same thing
<hoijui>jk just repeaded thw tow things i mentioned :D
<hoijui>(nothing bad of course)
<hoijui>it are two different ways of doing it
<jK>3
<hoijui>mm ok :D
<hoijui>then eplain you please
<jK>unpack of nsis exe is possible (but didn't found example code of it)
<abma>an other solution would be, to pack all files in an archive, and the installer uses this archive
<jK>http://forums.winamp.com/showthread.php?t=189493
<abma>the archive is a portable archive
<hoijui>the best solution is, to outsource the installer creation to china
<abma>:D
<jK>you want to make a slim ine
<jK>*one
<jK>imo everything is fine atm
<abma>the problem with the current installer is, that it ships with outdated stuff
<abma>springlobby is old, rapid is old, ...
<abma>for nearly everything additional, there is an update avaiable
<jK>didn't your installer allowed webdownload?
<abma>yes, it does webdownload
<abma>but i'm unsure if its the right way, it still feels ugly
<abma>there is no clean way to add sections in the installer at runtime
<abma>the guys from tdm-gcc wrote some c++ code for the webinstaller to add sections at runtime...
<abma>imo this makes stuff to complicate... but would be that what i wanted to do
<abma>and the webinstaller creates the archive in a complete different way
<abma>this could cause packing bugs
<jK>why do would wanted something like that?
<abma>a slim installer? because it would be much more cleaner... one package that can be reused everywhere
<jK>no sections
<jK>slim is totaly redundant to me
<abma>a webinstaller without sections? you mean, download everything?
<abma>the slim installer would be something like the portable archive
<jK>if other installer want to reuse such things then they will use webdownloads on per file level
<jK>we don't need offline installer for spring
<jK>esp. not w/o any games
<jK>-not
<abma>so.. what do we want/need?
<abma>imo we need to keep the same features as currently
<jK>webdownload with the ability for games to add their own content to it
<abma>ok
<jK>any static sections aren't a problem
<jK>*and
<abma>yes...
<jK>just add: ais, maps, games, lobbies, tools, engine
<abma>hm, thats how it is currently
<abma>except all ai's are installed
<jK>(I assume nsis won't show empty sections at runtime)
<abma>yep, that works
<jK>and if it is not too hard it would be nice if games could add their own banner image
<jK>or even fullscreen ones
<abma>that should be possible, but makes usability a bit more worse
<abma>as the file needs to be downloaded, too
<abma>hm, ok, that are some... details
<abma>you don't see the benefits of the slim-installer? it would allow to download the engine only
<abma>similar to a portable archive
<abma>without the overhead of the current fat-installer
<jK>engine w/o games&maps is useless
<abma>no
<abma>the slim installer can be integreated easier
<abma>just run it with some parameters, and it will install the engine
<jK>that's not easier
<abma>this would allow easier integration on different places
<abma>lobbies can install the engine directly
<abma>without installing itself
<abma>+ download overhead
<jK>hmm
<abma>or game-makers can integrate it easier into their installer
<jK>I begin to see your point, still don't see why it has to be an offline installer
<abma>fewer possible errors when installing
<jK>and more work to maintain it
<jK>zero maintain work should be the goal imo
<abma>yes, true
<abma>the slim-offline installer can be easier distributed
<abma>hm... so just test the online-installer + keep the fat as it is?
<jK>do what ever you want, just don't lost the goal
<abma>hmm
<abma>Kloot, [RoX]Tobi, [ARP]hoijui_g5: other opinions?
<abma>if not... next
<hoijui>i agree with what jk siad last
<hoijui>as you do all the work anyway, and you though most about this, and know the possibilities and limitations...
<hoijui>and as jk said, dont invest too much of your time, if the benefit is too small
<hoijui>its your decission
<abma>ok, thx
guard behaviour extension
<hoijui>instead of just following the guarded unit, should attackers be attacked?
<jK>sounds like a very small lua script
<hoijui>yeah, but..
<hoijui>why is it called guard command, if units are actualyl only following?
<hoijui>it is very counter intuitive
<hoijui>having 5 combat units guard a con unit
<hoijui>and then a flea comes by and kills the com during a 3 minutes long attack, and the guarding units on hte other side of the con do nothing
<jK>from the name guarding units should surround the to be guarded one
<jK>but that's not such easy with the current pathing AI
<hoijui>like bodyguards :D
<jK>yup
<hoijui>yeah.. i also see pathing problems there..
<hoijui>but attakcing if guarded unit is attacked shoudl be quite easy, and still much better
<hoijui>otherwise it shoudl be renamed following command
<hoijui>or at least the docu
<jK>yeah, but that's a joke for a lua script
<hoijui>that is irrelevant
<abma>maybe rename to support/follow ?
<hoijui>it is an engine command
<hoijui>it shoudl not be implemenbted half in lua
<hoijui>we could also have both of them
<hoijui>then again.. i dont know what the dfollowing commadn would be good for
<hoijui>may only make a difference for cons
<hoijui>GUYS WAKEUP!
<abma>hm
<abma>i'm a bit confused about the guard command
<abma>there are two ways: either guard a different unit, or a waypoint?
<abma>is it the same command?
<hoijui>mm?
<hoijui>guardign a waypoint?
<hoijui>you mean the ground?
<abma>ehm, ground, yes
<abma>...patrol
<abma>#fu
<abma>ok :D
<hoijui>ah.. yeah.. different thing
<hoijui>:D
<abma>next time i should test it first, damn
<hoijui>so .. i just take it, nobody cares about this
<abma>hmm, i think renaming would be fine
<hoijui>and if someone wnats to do it it can be done
<hoijui>next
<abma>ok...
messures to allow AIs to deal with the new bandwidth limit
<jK>sure, but the biggest problem (not surrounding the to be guarded one) can't be solved atm
<hoijui>yeah, i also would not consider doign that now
<hoijui>these are actualyl two things..
<hoijui>currently, the bandwith limit is per player, if i remember right
<hoijui>so if one host hosts multiple AIs, they have to share the bandwith limit
<hoijui>and independent of that: how could we give AI devs an idea for how they would prevent to reach the limit?
<hoijui>should we just make a simple rule like: "maximum 100 commands per frame per AI-team"?
<abma>[ARP]hoijui_g5: maybe make a callback? like: you reached commands-limit?
<Kloot>make the interface do buffering?
<jK>just add an ignore for AIs?
<hoijui>i think it is godo that AIs are limited by that
<hoijui>afterall, they are one of the main reasons we have the limit
<hoijui>as they are likely to give too many commands
<jK>nah lua scripts were
<hoijui>buffering .. i dont know how this woudl solve the problem
<hoijui>well... ok :D
<hoijui>but thats casue you do not play vs AI
<abma>"buffer" to next frame?
<hoijui>as a matter of fact, AIs are reachign the limit already
<abma>but imo this doesn't solve the problem, yes...
<jK>there is already a buffer
<hoijui>but if an AI issues too many comamnds in frame 1, it wil likely do the same for frame 2
<hoijui>plus the ones buffered in frame 1 ...
<jK>but when the buffer is full it hard drops cmds
<abma>yes, true
<hoijui>its no solution
<abma>so... the ai should get a notification about that?
<jK>duno if it should
<hoijui>yeah.. notification .. maybe have an event.. but that is not a solution..
<hoijui>a solution woudl be.. to have guidelines
<jK>ai should never rely that their cmds get executed
<hoijui>after all, AIs shoudl not reach the limit, but stay way below it
<jK>afaik also none does
<abma>so... limit to commands/frame?
<hoijui>so fi the limit is reached at a usual mixture of 300 comamdns per frame, we should have a guideline to not use mroe then 100 commands per frame
<hoijui>the limit of comamdns per frame is just the easiest way for AI devs to controll it
<abma>yep...
<hoijui>if you tell them to not cause more then X KB load in comamnds per frame
<hoijui>they cant make use of it
<Tobi>not some sliding window average over a few frames?
<Tobi>the limit is also per single frame?
<hoijui>i think it currently is... only jks idea was with sliding frame.. right?
<hoijui>it was not implemented
<hoijui>or how was it jk?
<Tobi>seems a bit silly imho to force AI devs to implement a buffer if they want to run some algo to give a lot of commands in one go
<Kloot>if there are to be "guidelines", may as well make one for cpu consumption
<hoijui>anyway, i think we can set the limit per frame in the guideline
<Kloot>command spam is just one way AIs can bring the engine down
<Tobi>(e.g. buffer could as well be in the engine as all AIs can use it)
<Tobi>same thing for reliability of commands
<jK>the bandwidth limit isn't ideal atm
<jK>it's still on my todo list to reimplement it
<hoijui>i dont think it can be done in the engine
<hoijui>or shoudl be
<hoijui>if the AI handles it, it can issue important commadns first
<jK>(via a window average function)
<Tobi>it's perfectly fine imho for the higher level parts of an AI to assume that orders always gets executed, so if engine drops them randomly, needs another layer in between that just handles regiving orders that got lost
<hoijui>for example.. all attakc comands are important, then move, and then the rest
<hoijui>and the ones over the limit get dropped, not buffered
<jK>btw the max buffer size is always a good guideline for ai/lua devs
<hoijui>and next frame, it generates comamdns again
<jK>atm 512 packets
<jK>per user
<hoijui>if the AI gives a command to a unit, but its internal logic decides it is unimportant, and gets dropped becuase of the internally managed limit
<hoijui>th unit will be idle next frame
<hoijui>and can be given the commadn again, or an other one
<Tobi>yeah true, can handle it using unitidle
<Tobi>as long as that is guaranteed it is fine
<hoijui>hmm..
<hoijui>it surely adds some extra logic that AIs need to take care of, in general
<Tobi>I think it is ugly if AI needs to scan for new units every frame because they can get idle without any notifications
<Tobi>*every X time
<hoijui>mmm
<hoijui>i dont know what woudl be best..
<hoijui>how woudl you do it Kloot?
<hoijui>you also mentioned the problem of some comamnds beeing much worse the nothers
<hoijui>liek pathfinding intensive ones, for example
<Kloot>the givecommand callback has a return code iirc
<Kloot>that could be expanded with a command-dropped value
<Kloot>but that relies on AI devs checking them
<hoijui>yeah.. well no matter how we implement it, AI devs woudl have to add special code for this
<hoijui>ah.. except wiht an engine internal buffer
<jK>dropping is done on the server atm afaik
<jK>(sure a client dropping would be nice too)
<Kloot>hmm, possibly server could signal back that a command was dropped (if they were assigned unique tags when sent)
<hoijui>maybe we can just iaasue a warning at max every 10 seconds, which is shown if the AI gave more then 100 comamdns in one of the frames in the last 10s
<hoijui>issue*
<Kloot>in any case I think AIs should not have to depend on existing callins like unitidle
<hoijui>i did not mean it that way
<jK>sure they should their commands could be removed for a lot of reasons
<jK>(LuaRules::AllowCommands, pathing fails, unit died before, ...)
<hoijui>but when the AI wants to give a command to an idle unit, but later decides to drop the command, it just keeps the unit in its internal idle unit cache
<hoijui>if the AI decides to not give a command, there woudl not be an other idleUnit call from the engien anyway
<hoijui>or you still want to try to handle it all in the engine?
<Kloot>if the unit was already idle yes
<hoijui>yeah.. if it was not...
<hoijui>that measn the AI's logic is able toreuse non-idle units, which it may also do agai nwiht the same unit next frame
<hoijui>so the problem is even easier solved then
<hoijui>maybe we should just give a warning as i described it, and see what ideas AI devs come up with? :D
<hoijui>if thye feel it is too cumbersome what they woudl have to do, adn have ideas for how to solve it in hte engine
<hoijui>we can check them out
<hoijui>?
<Kloot>that would certainly be the least amount of work for us :
<hoijui>yeah :D
<hoijui>but yeah.. it does feel a bit bad to have it implemented in each AI separately..
<hoijui>but i see no good alternative.. as it needs lots of knowledge to know which commands to drop, which only the AI woudl have
<hoijui>or not?
<Kloot>selective dropping is probably a no-go
<hoijui>mmm
<Kloot>because indeed the importance of a command is not easy to judge from anywhere but the AIs perspective
<hoijui>or put this way: the optimum solution woudl be, if the AI never would even plan to do mroe then the 100 comands per frame
<hoijui>ah.. in the engine you meant.. hmm
<jK>AllowCommand can drop any command
<jK>any time
<Kloot>but that is a different issue
<Kloot>if a command is dropped for gameplay reasons, AIs have to take different action than if netbuffer gets flooded
<hoijui>its not about the problem of how to make AIs stay sane if some of the commands they issue are not executed, but how to make them not issue many commands
<hoijui>mmm
<hoijui>i know of E323AI, that it already does have some sort of mechanism to limit comamnds per frame
<hoijui>as it issued so many commands in its early stages, that the engine nearly colapsed due to pathfinding
<Kloot>yeah, what eg. would also help with that is to introduce a group-move command
<hoijui>hm
<hoijui>you mean.. engine-ify custom-formations?
<hoijui>kind of?
<Kloot>so instead of having to send 100 individual moves that require encoding the (shared) goal position 100 times, one command would suffice
<hoijui>i think we alreayd have that
<hoijui>network protocol wise
<hoijui>but it only works, obviously, when all units of a group go to the same spot
<Kloot>true
<hoijui>which i think.. E323AI does not use
<hoijui>does nto do*
<hoijui>as it gets very clumsy with more then a hand full of units
<hoijui>or is unsuited for micro management as done by E323AI
<hoijui>the group move command coudl be useful, if the pathfinder woudl benefit from it..
<hoijui>like...
<hoijui>if instead of giving a custom formation command (by widget) to 100 units, its one command with the curve parameters
<hoijui>but i guess... it woudl be hard or impossible to optimize this in pathfinder.. right?
<Tobi>could be useful already if engine has ctrl+move as real command
<Tobi>instead of client-side hack (I think)
<hoijui>ahh yeah true
<Tobi>hmm though maybe that is available from AI, not sure
<hoijui>quite a similar thing, maybe easier to do
<Tobi>not from LuaAI at least, there I needed to replicate it
<hoijui>from AI?
<hoijui>mm
<Tobi>though there ofc you control your own protocol so it doesn't matter
<Tobi>if you even do an unsynced Lua AI (instead of synced)
<hoijui>aehh... but to end this topic..
<hoijui>should i just do the warning for now? :D
<Kloot>yup ^
<hoijui>i may get cranphin to comment on the ideas we had here, and test his AI if he has time
<hoijui>k :D
<abma>so, stop here?
(lobby server hang/crashed here :D)
it could/will introduce bugs too 
