Dev meeting minutes 2016-02-08

Dev meeting minutes 2016-02-08

Minutes of the meetings between Spring developers are archived here.
Post Reply
Spring Developer
Posts: 591
Joined: 02 Jun 2014, 00:46

Dev meeting minutes 2016-02-08

Post by hokomoko »

Present: abma, Kloot, jK, hokomoko

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: 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


<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. ... 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
Last edited by hokomoko on 08 Feb 2016, 00:32, edited 1 time in total.
0 x

Spring Developer
Posts: 3574
Joined: 01 Jun 2009, 00:08

Re: Dev meeting minutes 2016-02-08

Post by abma »

wrt donations:

i've created . paypal will hopefully come soon, also i've added a link to the Download page.
0 x

User avatar
MC: Legacy & Spring 1944 Developer
Posts: 6139
Joined: 29 Apr 2005, 01:14

Re: Dev meeting minutes 2016-02-08

Post by FLOZi »

Great to see meeting minutes again.

Handlers packaged in games is the devils business, improved base content please! :mrgreen:
0 x

User avatar
Posts: 3628
Joined: 25 Oct 2008, 00:23

Re: Dev meeting minutes 2016-02-08

Post by Silentwings »

I'm absolutely in favour of games using their own handlers if they wish. Imo the ability to readily slip in some debug prints to the handler is the single most useful debugging tool for a game dev inheriting an unfamiliar game.

There can also be reasons to modify; I gave BA/BARs widget selectors functionaility to "reset luaui" (delete all widgets saved settings and reload luaui) and "factory reset luaui" (delete all luaui config files and reload from blank config), which the stock handlers cannot do. They also save/load the lua config less than the stock handler, for good reasons that I'm currently too lazy to explain. I could add more.

+1 to the return of meeting minutes.
0 x

Super Mario
Posts: 814
Joined: 21 Oct 2008, 02:54

Re: Dev meeting minutes 2016-02-08

Post by Super Mario »

I'm a bit salty on this matter. Granted that I don't have much spare time as I used to, but I'm willing to offer help if needed, just assign me a task.
0 x

Post Reply

Return to “Meeting Minutes”