=== How to implement arbitrary map-info properties? ===
<hoijui> rts/Map/MapInfo.h
<hoijui> as it is now, it only reads/stores hardcoded properties
<hoijui> (in the engine/unitsync) from mapinfo.lua
<hoijui> each property is stored in a member var (usualyl in sub-structs even)
<jk> just add a customparam table like the others do?
<hoijui> hmm..
<hoijui> well..
<hoijui> yeah, that is an option
<hoijui> the other option is, if we change it all to a map<string, Info>
<jk> not possible
<zerver> that is slow
<hoijui> bascially how i did it for archive info(modinfo.lua) already
<jk> mapinfo.lua stores the values in separate tables
<jk> return { water = {...}, sun = {...}, ... }
<hoijui> yeah.. that is not really a problem
<hoijui> can just store stuff with "water.waterColor" as key
<hoijui> hte slowness coudl be a problem
<zerver> performance critical code accesses mapInfo->xxx
<hoijui> yeah..
<zerver> some data would have to be cached then for that to work
<hoijui> the problem wiht both solutions is though, that they are very ugly
<hoijui> or well.. ugly
<zerver> customparams is not ugly, only inflexible
<hoijui> it is ugly also
<hoijui> becuase i need a map<string, Info> of all properties anyway
<hoijui> as in.. custom plus hardcoded ones
<jk> also what would benefit of custom params?
<zerver> yeah, but it will only be accessed from lua anyway, so no performance problem there
<hoijui> for unitsync (and it might be useful in other places too, for example for AIs)
<hoijui> yeah.. no performance problem, but ugly
<hoijui> hmm...
<jk> mappers still use crappy ways to store those values (mostly tdfs)
<hoijui> hmm.. ok.. maybe not ugly..
<hoijui> i guess i will just leave it as it is, and additionally fill everyting into a map (not just custom stuff)
<hoijui> dont knwo why i did not think on that :D
<jk> yeah, that's a solution
<hoijui> thanks, and sorry :D
<zerver> yeah, does not hurt
<hoijui> next?
<jk> still wonder how you solve the multi level deep tables problem
<hoijui> i just go through tables recursively
<hoijui> and add the table name to the key/property-name
<jk> e.g. {sun = { color = {} } }
<hoijui> sun.color
<jk> color is a table itself
<hoijui> sun.color.bla
<jk> hmmm you should handwrite the [] operator then
<hoijui> why?
<jk> to support glsl-like syntax e.g. sun.color.x == sun.color.r == sun.color[1]
<hoijui> ahh... dont get it
<jk> in glsl you can index vectors like colors, vectors or as arrays
<jk> .x is the same as .r or [1]/[0]
<hoijui> this map is useful for punching the data through narrow interfaces
<hoijui> like unitsync and AI..
<hoijui> ah you mean.. it coudl be useful in lua?
<jk> no, it is needed to indentify a vector
<hoijui> vector is nto a supported type
<jk> vector versus random rable
<jk> color is a vector type
<jk> same for sundir, ...
<tobi> I suppose the type metadata would contains the knowledge it is a vector
<tobi> i.e. GetType("sun.color") -> "vector" or so (I hope I recall correctly that there was going to be a GetType procedure)
<hoijui> yeah, but vector is not a supported type
<jk> then you couldn't even access the default items currently stored in the mapinfo.lua with your new interface
<hoijui> because it has tables with values without keys?
<hoijui> as in {1, 2, 3} instead of {foo = 1, bar = 2}
<jk> you should be able to read the sundir with your new interface
<jk> so you need to add a way to read those vectors
<hoijui> how does such a vector look like?
<hoijui> if there are no string keys, i coudl use sun.dir[1] ...
<hoijui> but i dont get the ==
<hoijui> (in sun.color.x == sun.color.r == sun.color[1])
<jk> the == means that those syntaxes are equal
<jk> both return the same reference
<jk> should have used ===
<hoijui> i imaigned it liek this:
<hoijui> info["sun.dir[0]"] = ...
<hoijui> if there are no names
<jk> ?
<hoijui> [22:13:48] <hoijui> how does such a vector look like?
<hoijui> in lua
<hoijui> a vector is a table, right?
<hoijui> so i read it liek a table...
<hoijui> i dont get the confusion
<jk> {r,g,b} == {1=r,2=g,3=b}
<hoijui> aehh... ok
<hoijui> :D
<hoijui> no idea whats that supposed to mean
<hoijui> wheres the values?
<jk> glsl is the future of math structure syntax (vectors, matrices, colors, ....)
<hoijui> 1,2,3 are the values?
<jk> 1=r -> 1 := key r := value
<hoijui> ok
<hoijui> info["sun.dir.1"] = "r"
<jk> that would confusion with sun.color1 & sun.color2
<hoijui> well.. that is not my problem and nto my fault
<jk> k next then, seems you aren't a glsl-fan
=== Unify Archive-types? ===
<abma> if nobody says horay about this idea... skip it
<hoijui> this kind of continues hte last topic
<abma> yes...
<hoijui> it means, having a single format/file for archives
<abma> was just an idea when i tried to extract infos from archives, this is currently really ugly, as there are to many funktions to extract data
<abma> functions
<hoijui> whether map/game/dependency .. all woudl have soemthign liek archiveinfo.lua
<jk> quite simply: not possible right now
<hoijui> instead of mapinfo and modinfo and such
<abma> ok...
<hoijui> because of different formats?
<jk> VFS unifies all those files in one FS, so map's file would override the reference of the mod one etc.
<abma> ah, ok
<hoijui> ahh right
<abma> then... next
=== which branches can be deleted? (as they are already in master) or better, which can't be deleted? ===
<abma> are there any branches you know about, that can be deleted?
<hoijui> i deleted some before the meeting
<jk> 0.81?
<hoijui> i checked some more, but they are not in master yet
<hoijui> well..
<hoijui> only the aifix one maybe
<abma> ok, this was just a hint
<hoijui> we need the old release branches
<hoijui> because without them, we loose history (useful for bug hunting maybe, and for linking to on github)
<hoijui> this will be better with the new branchign model
<jk> isn't that saved in the tags?
<hoijui> i am not sure anymore.. but i woudl have though tags are lsot if you delete the branch they are on
<hoijui> unlike in SVN
<hoijui> would be easy to check :D
<tobi> tags remain
<tobi> in SVN tags are branches :)
<hoijui> mm ok
<hoijui> yeha then we can delete them
<tobi> (and with the tag all history up to the tag)
<tobi> only links to github might break if they use the branch name or so
<tobi> but I doubt that's really a problem
<hoijui> hmm.. yeah i dont think that is useful anyway
<hoijui> yeah
<hoijui> for topic branches maybe, but not release ones
<abma> sorry, my connection broke
<abma> maybe only a few links in mantis... but in general i think they refer to the commits
<hoijui> the syncdebug gcc 4.3 branch?
<hoijui> and.. i think some others by tobi too..
<hoijui> but the others .. pretty sure they are not obsolete
<abma> so... next? :)
=== did you see the "Edit this file" button on github (when logged in)? ===
<hoijui> i saw it yes
<hoijui> next!
<hoijui>
nah.. what about it? you tried it?<hoijui> jk tried it once, right
<hoijui> ?
<abma> yes, sure :)
<jk> no
<zerver> never
<abma> its nice to edit comments, but imo unuseable to edit large files
<jk> it says I don't have commit access to the repo (github fails with opera)
<hoijui> mm ok
<abma> ehm, to the bug i wrote in mantis
<hoijui> stack corruption?
<abma> hm.. i'm unsure what it is, this was only a guess, it happend so infrequent
<abma> now i can reproduce it better
<zerver> the assimp one?
<abma> yes
<hoijui> it is most certainly not asimp related though
<hoijui> we just did little testing lately
<zerver> k
<abma> to reproduce (mabe there are some other bugs): i check if "Red Build/Order Menu" is enabled
<abma> /cheat + /give all
<abma> and then ctrl + a
<abma> selecting with mouse works
<jk> then you will have obviously more than ~1-4 cmddescs
<jk> so my assumption is still valid that it is a OOM
<abma> it crashes sometimes at different stages... but it looks like it crashes this way always
<hoijui> what is OOM?
<zerver> mmkay, ima try with the superior MSVC debugger
<hoijui> :D
<abma> i hope you can reproduce the crash now
<zerver> the only thing that MS did better than gcc :)
<jk> Out Of Memory
<hoijui> that shoudl be easy to check (OOM)
<zerver> another thing, I see that the current engine searches in both "mods" and "games" folders in the data directory
<zerver> but "mods" is deprecated right?
<abma> yes
<zerver> because ima add searching one level up for the multi engine version support, and will skip "mods" then
<abma> [LCC]jK: maybe is the stack full? http://www.lua.org/manual/5.1/manual.html#3.2
<jk> no
<jk> lua out of stack errors don't cause crashes
<jk> no do they alloc memory
<jk> *nor
<abma> ok
<abma> [LCC]jK: can you now reproduce the crash?
<jk> just table creations can use a hell lot of memory, when you don't give the final in the table construction
<jk> I don't test with BA, nor is my test enviroment in a state to do so
<jk> *final size
