101.0 Release
<hokomoko> first I think the fact that development versions have 4 digits means we need to proritise release at the moment
<hokomoko> so I'd want to post an RC today
<hokomoko> which also means feature freeze
<Kloot> +1
<abma> i agree, last release was to long ago
<hokomoko> I'd just ask to refrain from nlcs since we accidentally put bugs in 100.0 this way
<Kloot> definitely no more features or refactors (unlike for the 100 release) if at all possible
<hokomoko> bug fixes only
<hokomoko> I'm happy we're on the same wavelength
<hokomoko> do we currently know of something broken in 101.0?
<abma> you mean current development version?
<hokomoko> yes
<hokomoko> sorry
<Kloot> I don't
<hokomoko> ok
<Kloot> and have nothing left in queue either
<hokomoko> abma_irc something else regarding release?
<abma> roadmap is fine, too: https://springrts.com/mantis/roadmap_page.php so, rc
<hokomoko> k
<hokomoko> next subject
<hokomoko> "how to get some structure to indirectly related to the engine stuff? (website, lobbyserver, server, donations, ...)" abma_irc would you expand?
<abma> ugh, this was added between now and the last meeting minuts :D
<hokomoko> heh
<hokomoko> ok
Conclusion: feature freeze => RC => release
Donations
<abma> "donations"
<hokomoko> as I understand we currently don't ask for any since we don't have any potential use
<abma> current server-resources are atm donated by dasan, but thats 60 EUR a month if i remember right
<abma> aw
<abma> a year
<abma> oops XD
<hokomoko> what is the question then
<hokomoko> ?
<abma> it would be nice to give back the 60 EUR
<hokomoko> agreed
<abma> Kloot offered a long time ago to handle donations, is this still true?
<Kloot> it's easy to handle them when there aren't any
<jK> lol
<hokomoko> hehe
<abma> yep, but there are no advertisment placed yet
<jK> there are none cause we don't ask for any
<jK> zk got them cause they have a website + interface
<abma> yeah, the server directly burns the money
<Kloot> I guess we could make engine draw billboards along map edge with donation advertisements
<abma> ok, i try to create a wiki page and... then... where to place a link to it?
<jK> abma_irc: ok, i try to create a wiki page and... then... where to place a link to it? > add a new link next to download in the header?
<abma> ok
<jK> + make the wiki uneditable by none devs, so ppl cannot change account data
<Kloot> they work as far I tested, yes
Conclusion: Add donation page to wiki, use to cover hosting costs
101.0 Release - continued
<jK> my missing things for 101: 1. need to update changelog (los changes, weapon changes, ...) 2. find a proper solution for float3 == 3. I dislike it that UnitDestroyed is called twice now, I would prefer a new callin
<jK> ah and 4. http://github.com/spring/spring/commit/ ... 2715fa07a8
<hokomoko> 1. is mostly your stuff afaik. I tried to update the log as I go
<hokomoko> [LCC]jK?
<jK> obv 1. is my stuff (and I always delay it to the last hours before a release ^^)
<jK> @4. that `fix` seems strange and breaks smooth radar icon movements, I would like to find the real cause of the offset
UnitDestroyed callin
<Kloot> 3. the idea is that Lua devs stop using the preEvent UnitDestroyed, so there won't need to be two calls next release
<hokomoko> [LCC]jK drawmidpos is now dynamically set
<jK> hokomoko: what's the issue with 2? > slow, cause 1. defined in .cpp (-> not inlined) 2. large as hell
<hokomoko> well, I don't see how it can be made faster and also, using float3 == should be avoided anyway
<jK> Kloot: 3. the idea is that Lua devs stop using the preEvent UnitDestroyed, so there won't need to be two calls next release > better is to split it imo into: UnitDestroyed & a new UnitDeleted
<Kloot> nah, UnitDeleted is ugly internal engine detail
<jK> no
<Kloot> lua should not need to know or care about such differences
<hokomoko> UnitRenderDestroyed actually
<hokomoko> we already have that event
<jK> it matters to differ when a unit dies (as in it starts to call its death animation) and the time it data is freed
<jK> *its
<jK> i.e. a dying unit cannot recv cmds, or shoot others, or generate resources, ...
<jK> writting the changelog for los takes me multiple hours
<hokomoko> summarize ^^
<jK> a lot of breaking stuff in it
<jK> cannot
<hokomoko> k
<hokomoko> Kloot I think I mostly agree with jK regarding the event
<hokomoko> as far as most sim goes, the unit _is_ dead after the preevent
<hokomoko> only stuff left are graphics and some odd bits
<Kloot> actually it can still receive orders
<jK> but it won't process them
<hokomoko> that may be an issue
<Kloot> it will, unless explicitly blocked
<hokomoko> is it selectable
<jK> dying units get paralyzed etc.
<Kloot> e.g. a unit running its death anim can still be moved around
<hokomoko> because I don't remember moving dead units around
<Kloot> dying units get paralyzed etc. --> not anymore
<hokomoko> why?
<abma> stupid question: whats the difference between dying and dead units?
<hokomoko> units during their death animation = dying
<Kloot> but existing Killed callin + UnitDestroyed(post) should cover everything already
<abma> ok
<hokomoko> units after the animation when the object is destroyed = dead
<jK> there is a Killed event?
<Kloot> script callin
<hokomoko> he means Destroyed
<hokomoko> ah
<hokomoko> the script?
<Kloot> the thing that starts a death anim
<jK> script != lua
<Kloot> your "Killed event" is UnitDestroyed(pre)
<hokomoko> personally I don't think "Lua devs stop using the preEvent" would ever happen
<jK> yes, I know, but it's not available to rest of lua, neither is it worth to start renaming lua events
<hokomoko> is there any other reason to be using the same callin for both?
<Kloot> 1) it is the easiest way of achieving a pre- and post-death phase
<Kloot> 2) it represents the least amount of work for game devs to restore BWC
<Kloot> 3) processing the callin twice should break a minimal number of *gets
<Kloot> (c/p from commit)
<jK> 1 is not true
<jK> 2 neither
<hokomoko> breaking least amount is adding a new callin
<jK> yep
<hokomoko> nothing changes, and nothing new is called
<Kloot> least amount of work for *me*
<Kloot> and 2: changing one line in gadgethandler *is* the least
<Kloot> or adding, in case a game uses a custom GH
<jK> you wrote "for game devs"
<hokomoko> adding an event takes less time than our discussion
<hokomoko> we could even use the existing renderunitdestroyed event
<jK> damn do you have to remind me to finish the new handler.lua
<Kloot> re-using UnitDestroyed takes even less...
<Kloot> I don't see what the big philosophical objection is tbh
<hokomoko> any vivid objection to splitting the callins?
<hokomoko> if it's not very important to you I'll change it myself
<Kloot> splitting into UnitDestroyed + RenderUnitDestroyed you mean?
<hokomoko> or something to that effect
<jK> it's not philosophical, 1. it might break lua code (not all code is safe to get called twice) 2. it won't be easy for lua to differ pre & post calls and clutter the lua code 3. performance
<hokomoko> [LCC]jK yes, we got it, I want to get on with the conversation
<Kloot> you have a point with 1 and 2, not 3 (two callins needed either way)
<Kloot> anyway, I am fine with RenderUnitDestroyed too
<hokomoko> thank you :)
<hokomoko> let's move on
<jK> :)
<Kloot> next time I would just like to hear objections *earlier*
<Kloot> not 5mins before an RC
<jK> you made that commit at dec 25!
<hokomoko> Kloot I agree, I should've said it earlier
<jK> I just noticed it when you closed the mantis ticket
<Kloot> and you said nothing then...
<hokomoko> although communication is a bit hard on github
<hokomoko> that's why I wanted to hold this meeting
<hokomoko> anyway
<Kloot> kk
<hokomoko> let's move on
<hokomoko> I'll solve 4 with jK later I think
<hokomoko> not extremely important
Conclusion: UnitDestroyed callin will revert to its previous state, UnitRenderDestroyed will be expose to lua in place of the postEvent
printf replacement
<jK> oh I also wonder if printf performance is relevant on windows
<jK> buildbots seem to give a different result for windows ones (but those aren't running window, and use wine instead)
<hokomoko> last time I tried to run your test I had asserts flying all over the place
<jK> still I wonder if the results are really that bad on windows
<hokomoko> talk to me later and I'll test it
<hokomoko> anything else?
<hokomoko> Kloot?
<jK> when there really is a demand, it could be switched to a handcoded int64 printing (atm uses printf one)
<Kloot> do we really want scientific notation support for lua printf
<Kloot> ?
<jK> and I saw results on google with 10x and better performance with handcrafted code
<hokomoko> Kloot it's necessary for synced printing
<hokomoko> next item
<jK> scientific notation isn't even that complicated, digit precision is
<jK> ie. 0.00000002
<jK> you cannot shift a float digit by digit (as you can do with an int) cause of float errors
<Kloot> yes, floating point sucks to print
<jK> so you have to do all math in and rush to transform your float into a int that you can print then
<jK> best for that is to cast the float to a double multiply it so all digits are in the pre dot part and then cast it to a int64
Conclusion: new printf perf needs to be tested on windows
Post 101.0 plans
<hokomoko> what are our plans for after 101.0?
<hokomoko> do you have any?
<jK> hokomoko: what are our plans for after 101.0? > I want to reduce memory usage, by freeing sysram copies of model's vertex data
<hokomoko> cool [LCC]jK
<Kloot> then probably custom projectile shaders
<hokomoko> sounds good
<jK> I already prepared everything for the freeing (engine doesn't use te vertex data anymore), I just need to find a clean API for post & pre stage
<hokomoko> I've figured saving/loading can't really be delegated to lua so I may want to investigate lua_state serializing
<jK> also demand for the new handler.lua seems to be high
<hokomoko> [LCC]jK I'm not sure about that
<jK> and there is someone asking for a lua sound object
<hokomoko> most games have custom handlers
<hokomoko> lua sound could be cool
<hokomoko> we clearly miss stuff like fade-in/out etc
<hokomoko> cool, seems like we're not going to step on each other's toes
<jK> hokomoko: most games have custom handlers > custom in way of haxxings, my handler.lua means: a new widget/addon object (faster & cleaner to write) and automatic callin handling (when the engine exposes a new callin, the handler will handle it without any changes)
<hokomoko> I know
<hokomoko> so
<jK> it's a pain in the ass that each callin needs to be added by hand
<Kloot> hokomoko: exact state serializing can't be delegated, but "close enough" load/save is a simple gadget
<hokomoko> Kloot I want to sync
<Kloot> meh, overrated
<hokomoko> hehe
<jK> oh I wanted to test how far creg savesystem is now :)
<hokomoko> [LCC]jK try it with BA
<hokomoko> works impressively
<hokomoko> lua can't handle it though
<jK> yea, I haven't added the lua support yet
<hokomoko> anyway, to keep coordinated I think we may want to use an etherpad
<hokomoko> [LCC]jK with serializing, you won't have to
<jK> cause last time i tested it unit rotations, piece positions etc. weren't saved
<jK> and units were unable to move >_<
<hokomoko> they should be ok now I think
<jK> yeah, never thought that the UnitTest I wrote would ever be finished ^^
<jK> when I did the UT it had like 200 unsolved classes
<hokomoko> I was angry that people always broke it without fixing, so I figured the only way to solve this is to put the allowed violations on 0
<jK> it's a strange feeling to see it now at 0 >_<
<Kloot> I make no promises about not breaking creg again :>
Conclusion: we all have plans, creg is amazing
Dev Coordination
<hokomoko> if I send you an etherpad link in PM, will it get updated?
<hokomoko> or do you prefer some other way of coordination?
<jK> I lost the urls of the old etherpads
<hokomoko> they can be found, I promise :)
<hokomoko> Kloot do you want to work with etherpads?
<Kloot> did before, can do again
<Kloot> + in general it would be nice to know what people are planning / code they need to touch
<hokomoko> I kinda tried to keep this: viewtopic.php?p=571741#p571741 up to date
<hokomoko> can be done in etherpad too
<hokomoko> [LCC]jK any objections to etherpadding?
<jK> no
<hokomoko> cool
<jK> digging in pm history then
<hokomoko> that was my agenda, anything else you guys want to discuss?
<hokomoko> [LCC]jK I'll send you the link in forum PM
<hokomoko> anyway
<hokomoko> I think this was a good conversation which should be held once in a while
<hokomoko> thanks you for appearing on a day's notice!
<hokomoko> and we all need to be more communicative so the UnitDestroyed situation doesn't repeat itself
<Kloot> there used to be regular minutes, then the zerver situation happened and they... stopped being very productive
<hokomoko> I think it would be best if we just invoke another one in PMs when we have content to talk about
<Kloot> if development is very active maybe every two weeks, otherwise once a month or on as-needed basis
<hokomoko> sounds reasonable
Conclusion: future meetings will be held as needed, etherpad to be used
