Dev meeting minutes 2010-10-03

Dev meeting minutes 2010-10-03

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-10-03

Post by hoijui »

Date: Sunday, 03. October 2010 (2010-10-03)
Present: hoijui, jk, Tobi, zerver

_Agenda_____________________________________________________________________
  • Welcome
  • Release plan (unitsync fix)
  • communication enhancement with mod-devs
  • dual/single lua states - mod option?
  • git rules
  • Next meeting
  • Anything else? (WVTTK)

_Topics_____________________________________________________________________


Welcome
hoijui: hello everyone!
hoijui: :D
zerver: hi
Tobi: hello :)
hoijui: to the agenda..
hoijui: do we need all the stuff thats on there?
hoijui: especially the old one
hoijui: unitsync improvement?
hoijui: abma told me he will be here but afk
hoijui: so.. i guess we should leave that out
Tobi: ok


Release plan (unitsync fix)
hoijui: jk, how is your fix?
jk: working on it right now
jk: fixed it mostly already
hoijui: ahh cool :-)
jk: I assume to finish it today
hoijui: mm :-)
hoijui: nice
hoijui: goo so.. if that works out, .. we should do a 0.82.6 i guess
zerver: indeed
zerver: too many people crashing because of this direct control thing
hoijui: with the snake move fix, this one and a real fix for the FPS crash
hoijui: .yeah
hoijui: lets leave that for tomorow evening then
zerver: yeah, should i send u list of commits to include?
hoijui: jk, and zerver telling me what they want in, and ill do the release stuff including a bit of testing and the post
hoijui: yeah please
zerver: ok
hoijui: :-)

main points:
  • jk nearly fixed the unitsync issue (aka Satiriks bug)
  • new release (0.82.6) will come these days

communication enhancement with mod-devs
hoijui: thats the questions in the etherpad
hoijui: looks like jk and me are missing something.. and .. well kloot who is not in there at all :D
jk: I need a week to finish me examples
hoijui: ok :D
hoijui: me too then..
hoijui: i will write a PM to kloot.. i guess he was never informed about it?
Tobi: pretty sure he was, in the meeting a few weeks ago
hoijui: mm ok
hoijui: will remind him again then
hoijui: or should we live with what we have?
hoijui: maybe more/better ideas will come up when it is running
Tobi: yeah
jk: answering those example questions will be the most difficult ^^
hoijui: :D
zerver: yeah, im pretty unsure if there are answers
zerver: "sorry, u can't"

main points:
  • let's see again in a week


improve unitsync
hoijui: this is what abma is workign on, and he is AFK, os we skip this



dual/single lua states - mod option?
hoijui: lets get ready to RUMBLE!!
zerver: yeah, it looks like we are finally getting somewhere now that jK put his suggestion on paper
zerver: we are basically fighting over nothing
zerver: jK's and my suggestion are very similar, he wanted to use more batching, which is perfectly OK
zerver: more work, but less chance of broken widgets
hoijui: mm ok
jk: the thing is as said your way doesn't solve anything
jk: I understand the problem very well, but I also know how current Lua works in Spring
zerver: it solves MT slowdown, that for sure
jk: and your changes show, that you have totally wrong impressions
jk: no it doesn't solve the slowdown
zerver: come on, please stop this...
jk: you aren't listening, fine ...
jk: then move it to a branch please
zerver: explaing why it does not solve the slowdown, even though i confirmed it does
jk: confirmed how?
zerver: by reading the cpu load under identical conditions
jk: you broke 100% of the lua, the lua does nothing in your code, that's why it is faster
zerver: i broke lua, but it is faster because of less locking
jk: less locking?
jk: you didn't removed the mutexes
jk: it is still locking the same amount of time
zerver: i did, with macros redefinitions
zerver: sim thread has its own lock, and draw thread another lock
zerver: so they are not blocking each other
zerver: luadrawmutex, luasimmutex
Tobi: zerver: random question: unsynced-draw LuaUI has no access to GetUnitHealth etc. right?
jk: it has
zerver: ok, i actually have no idea
jk: but the simthread is writting to it at the same time -> boom
jk: your knowledge of the lua handles is very limited
jk: so e.g. the unsynced LuaRules
Tobi: if it has, locks are still needed and too much responsibility will be at the widget writer (i.e. if he accidentally uses any LuaSyncedRead method it can cause random crashes indeed)
Tobi: s/and/or/
zerver: unit deletions cannot happen during draw call-ins, there are locks that prevent it
Tobi: if it hasn't, then the dual state solution as it is now (as I understand) is moving responsibility of buffering/queueing data from C++ to Lua
zerver: well, the lua state split really does not affect concurrenty in any other way than that the thread will no longer fight for the single lua handle
zerver: *concurrency
jk: for callouts as GetUnitHealth I would propose mutex with a lifetime, so all those callout share 1 mutex, but just reset it's lifetime
Tobi: so then there is only a chance for reading a half written value (I've never seen that in practice) or an inconsistent set of values
jk: this way the overhead by mutex creation is limited to a minimum
zerver: Tobi: yeah, MT reads plenty of incomplete values
zerver: this is thy signaling nans have to be disabled
Tobi: ok, so it does happen
jk: and still it wouldn't lock the other threads from running while lua does it's work
zerver: basically, we should discuss the lua split only
Tobi: zerver: sim thread never needs to touch LuaUI
jk: zerver, it has to do with the lua split!
Tobi: just LuaUI needs to access sim data
jk: as your lua split is bugged!
jk: and we discuss solutions
jk: e.g. a 2nd bug: http://github.com/spring/spring/blob/f0 ... d.cpp#L303
Tobi: I think splitting LuaUI is putting responsibility at the wrong level (i.e. at the widget writer)
jk: this function initialize the basic Spring unsynced LuaRules enviroment
Tobi: while the engine could quite easily make sim call LuaUI in async way
jk: note the LightCopyTable in line 304?
jk: you know what it does?
jk: it _copies_ lua objects from the synced enviroment (in the same LuaState as the unsynced one!) to the unsynced enviroment
jk: obviously this doesn't work anymore after your split
jk: and there are multiple of those issues
jk: also you don't need to touch the LuaHandle.cpp at all
jk: you just need to split the LuaState in LuaHandleSynced
Tobi: and even that isn't needed to decouple LuaUI from the sim thread
jk: still it would be a huge parallization increase when doing so
jk: you could even run multiple unsynced LuaStates at the same time (except the render callins)
zerver: my split means two copies of everything essentially
jk: e.g. so you could run UnitCreated in LuaRules(unsynced) & LuaUI at the same
Tobi: yeah, but `just' for gadgets, and I recall usually LuaUI uses the most CPU?
zerver: so I don't understand why the stuff you pointed out would not work
zerver: i have two luaRules (complete), and two luaGaia
jk: yeah, adding a event queue to LuaUI will be enough and fix the performance problem
zerver: they both work!
jk: zerver, you aren't listening
zerver: and im doing the event queue as we speak...
jk: I am really pissed off, I explain things over and over .. and you don't listen and just say "it works period"
Tobi: zerver: the 2 luarules, how do they relate to synced/unsynced code?
zerver: both have synced and unsynced, they are complete
zerver: only sim thread invokes one and draw thread the other
Tobi: ugh
Tobi: design wise that becomes very ugly imo
zerver: so communication is severed ...
Tobi: so from modder point of view there would be 4 luarules :/
Tobi: draw-synced draw-unsynced sim-synced and sim-unsynced
Tobi: with half of the call-ins randomly not working in one or the other
jk: zerver, obviously synced LuaRules can't render ...
zerver: no, because one half of each is "dead" :)
jk: and obviously the current unsynced LuaRules implementations doesn't get any synced events
zerver: im making batching for that
zerver: it goes directly into synced, then batches it into unsynced
Tobi: [LCC]jk: the last thing isn't that obvious, as user questions indicate in my experience
Tobi: [LCC]jk: it's just a technical limitation because of lack of trepan-style state split
jk: I know that it isn't obvious to the user
jk: and I know it is a very bad limitation
Tobi: ok
jk: and I want to really fix it
zerver: jK, but you also suggested state split for LuaSyncedHandle, right?
jk: yeah
jk: but in a toally different way
zerver: so basically, you have nothing against gadgets needing some re-working
jk: gadgets wouldn't need any rewrite!
Tobi: I think the issue is that state *split* is what is desired, and not state duplication :-)
zerver: if you have two states, they *will* need a slight fix
jk: no
Tobi: the trepan-style state split wouldn't need any changes to Lua code afaik
zerver: i made this topic on the agenda to discuss whether the state split should be a mod option
zerver: this way, lazy modders can use their old code too
jk: it shouldn't be in spring at all in the current form
Tobi: it's separated well enough atm to be able to do the change transparantly to the Lua code.. (unsynced Lua never has direct access to synced Lua object)
hoijui: so in short..
Tobi: don't make it an option, that will mean double amount of code paths on which bugs can appear
hoijui: lets get zervers changes into a branch?
hoijui: and jk does what he wants to do in an other branch
zerver: mod option is real easy to implement
jk: my change can be in master even, because it doesn't break anything
zerver: if so, it will not fix the MT performance issue
jk: the performance issue will be fixed with an event queue for LuaUI!
hoijui: i would say.. as zerver still does not believe you can do it better, maybe to it in a branch.. and when done ..
hoijui: zerver can verify it..
zerver: event queue is good
zerver: but there are gadgets too
jk: gadgets use <10% cpu time
jk: and they can be parallized already
hoijui: so.. both of you work in branches, and nobody will make changes in master Lua stuff
hoijui: so no problems
Tobi: I think that is best for now
zerver: kk, but both of us doing the event queue is kind of bad
jk: doing the event queue is a bit more work
jk: (needs more thinking)
jk: work can be shared there imo
zerver: and i dont understand how LuaHandleSynced can be "parellelized already" when it has a single state
zerver: let me do the queue, i already started
jk: yeah, I meant it can be parallelize after the state split
jk: and yeah, do the queue
zerver: ya, and i have split it :)
Tobi: *trepan style state split, I assume
jk: yup
hoijui: zerver, will you revert the 3 or 4 commits in master then, or should i do it?
zerver: i can do it, but it work as i see it so no need really
hoijui: i though we just decided that we do it?
zerver: sure
hoijui: as for jks version, it is not needed
hoijui: ok
Tobi: putting it into a branch needs a little bit of thought too though
hoijui: hm?
Tobi: I think branching & then reverting in master will give huge conflicts on merge?
hoijui: yeah.. maybe better to revert, then branch, and re-revert
Tobi: so maybe revert, branch, cherry-pick to branch might work better?
hoijui: yeah
zerver: can u explain the difference between Trepan split and mine?
jk: your's is done in LuaHandle
jk: trepan wanted to do it in LuaHandleSynced
Tobi: trepan intended to run LuaRules unsynced in one state, and LuaRules synced in another state, instead of both in the same state
zerver: but now tweaked so unsynced luahandles use a single state...
jk: also a lot enviroment creation functions need to be adjusted in LuaHandleSynced
Tobi: without the other half being present in each other
jk: zerver, you created 4 States
jk: trepan wanted just 2 and still use all the old interaction functions
zerver: yeah, but the other half present, does it hurt really, except eating some memory
Tobi: and in a way to simplify the code, i.e. get functions from global table in both states, instead of: get unsynced functions from registry and get synced functions from global table & hack around with making registry used as global table in unsynced
Tobi: I doubt that was in any way clear =)
zerver: :)
Tobi: either way, it would make things more consistent on the C++ side, without any changes needed on the Lua side
jk: I don't think zerver has enough lua knowledge to explain it fully to him
zerver: If trepans solution really has parallel execution in gadgets, how can it be compatible with current code?
jk: you need to know how Lua handles `enviroment` and tables etc.
jk: because gadgets are already splitted in 2 sub-luacodes
jk: in real each gadgets is created twice
jk: as synced gadgets and an unsynced gadget
jk: you see a "if (gadgetHandler:IsSyncedCode()) then" in all gadgets
jk: it is used to detect which part is executed right now
zerver: yeah, i know, but still only one luaState
zerver: so parallel execution --> crash
jk: but you could just give unsynced it's own LuaState
Tobi: not after split
jk: *its
Tobi: after split unsynced half would run in a different state from synced half
zerver: but then it cannot share data via SYNCED anymore
Tobi: why not? `just' needs some buffering
jk: yeah, that needs work
jk: but it is solvable
zerver: i doubt that
jk: you will see
zerver: i thought separate lua handles are completely isolated from the outside world
jk: you still need tunnels between them
zerver: and if the are not, how come concurrent access to shared data does not crash?
zerver: tunnels? ok
jk: e.g. even LuaRules can call LuaUI code via Script.LuaUI.MyCustomGlobalLuaUIFunction()
jk: (unsynced LuaRules)
jk: so those special cases need extra locking
jk: or they are added to the event queue ;)
Tobi: probably depends on whether the LuaUI function can return data to unsynced LuaRules again
jk: no, it can't
Tobi: ok, that's good then
jk: first, I was annoyed it can't, but now I am happy about it :)
zerver: so how would this make it possible to share data via SYNCED?
zerver: where does the locking take place?
jk: no, locking in there
jk: in needs buffering
jk: *it
jk: instead of sharing the lua_objects between synced & unsynced, it needs to copy the data from synced to unsynced
zerver: i think this is fail. what data do we copy, and when?
jk: this should be done each renderframe and on SendToUnsynced
zerver: how can we make sure to copy the data before the reader needs it?
Tobi: SendToUnsynced could be buffered too
jk: "what data do we copy" the same as what it in SYNCED right now
jk: *is
Tobi: copy all data
Tobi: it's a shame though that unsynced SYNCED table refers to synced _G
zerver: so we copy all of it, every time
zerver: FAIL
jk: copy all >valid< data in _G ;)
jk: e.g. functions aren't valid
Tobi: yeah, only primitives and tables, but you still need to loop through everything
zerver: sorry, but i think we should skip this data sharing and use a mod option instead
jk: it already loops through everything
zerver: what does?
Tobi: would have been nicer if there was a separate table in synced Lua (e.g. `EXPORTED') that was made visible in unsynced as SYNCED
zerver: i think it is ok to break _G/SYNCED communication for gadgets if we use a mod option for it
Tobi: [LCC]jk: I thought SYNCED was a magical table that fetched data on demand?
jk: that could be done via an modoptions (or any located anywhere else) if you want
jk: exporting data just in _G.EXPORT
zerver: i don't believe in that, it complicates matters too much
Tobi: it's pretty simple actually
zerver: but how often to copy the data, and does this copying need a lock?
Tobi: probably once reach sim frame is sufficient
zerver: triple buffering :)
Tobi: s/reach/each/
jk: sim frame ?
jk: you mean renderframe
Tobi: no, sim frame
Tobi: as sim things don't change between render frames, unless there has been a sim frame
zerver: once a sim frame --> big chance unsynced tries to read it before it is available
jk: for the synced Lua it doesn't matter if the data for SYNCED was used or not
Tobi: zerver: then it would read data from previous frame, pretty sure in 95% of the gadgets that use it that is no problem
jk: k each renderframe it needs to check if the sim frame increased and then to copy the data
Tobi: it just needs to be guaranteed that SendToUnsynced calls don't arrive in unsynced before the data in SYNCED has arrived -> buffer those too
jk: yup
zerver: they are buffered already
zerver: my commit contains that
Tobi: then each render frame, if there has been a sim frame since the past render frame, copy _G to SYNCED and after that go through SendToUnsynced buffer
zerver: im a bit worried copying may take a long time with tables and stuff
Tobi: it will be pretty fast
zerver: k
Tobi: Lua makes tables all the time
Tobi: and in case -after measurement- it appears too slow anyway then we can then think of a faster `data tunnel', that could optionally be used by a mod if they want to really optimise for max speed
zerver: i think my commit does everything we suggested so far, with the exception of the event queues and the _G/SYNCED communication
zerver: but i assume you want me to revert anyway?
jk: you didn't do so exactly
jk: it might sound from the todo items
jk: but the ways/implementations are different
Tobi: yes, it does much more, that isn't needed (splitting LuaUI etc.)
zerver: not anymore
zerver: i merged luaui again
Tobi: oh ok
zerver: and the split has to be in luahandle, because luahandlesynced uses a lot of stuff from there
zerver: all "synced" calls (UnitCreated etc) is declared in LuaHandle
jk: you need to be more creative
jk: there are solutions for those things
zerver: any attempt to make a nice split in LuaHandleSynced will be horror from a coding perspective
zerver: cannot use macros and stuff the way I have done now
jk: it won't be a 10 lines macro ...
zerver: so, conclusions?
zerver: i'm making the event queue...
jk: fine :)
jk: I will try to split LuaHandleSynced (2-3 weeks project)
hoijui: first, do the revert/move to branch
jk: esp. because my mulitcore CPU is coming this week, before that I can't test the locking
hoijui: yeah :D cool
jk: Phenom II 555BE + GTX460 :D
zerver: jK, you should test my code first
jk: I know it is broken
zerver: how?
jk: I know the code very well
zerver: you did not tell me how its broken in any way that i could understand :)
hoijui: the 4 vs 2 states thing?
jk: nah, the unsynced LuaRules enviroment creation + SYNCED is broken etc.
zerver: not convinced, 2 dead states do not break anything except the _G/SYNCED communication
jk: the `Script` userdata object is broken
zerver: where and why?
jk: Script.LuaUI?
jk: Script.LuaGaia, Script.LuaRules
zerver: and how did I break that?
jk: those are tunnels between the LuaStates
zerver: ok
jk: and now with multiple LuaStates, they may tunnel between the wrong ones
zerver: still a minor issue maybe? really worth it to throw away my solution completely?
Tobi: 2 dead states are bad from maintenance/design POV, will be even harder to understand what the code is doing when half of the runtime stuff it makes are dead bits
zerver: i agree on that
Tobi: clean design that makes as much objects as there conceptually are would be preferred
hoijui: next?
zerver: wait
zerver: Can Script.LuaUI read from the LuaUI state?
jk: not really
jk: but you can check if there are global functions available
zerver: so that would need a lock?
jk: or part of the event queue
jk: e.g. you can do in LuaUI: _.FOO = MyFooFunc and in LuaRules(unsynced): if (Script.LuaUI.FOO) then Script.LuaUI.FOO("bar") end
jk: but it doesn't allow return values, nor can it be used to share any other data than functions
zerver: okay, but it somehow uses the lua state from luaUI
Tobi: could probably be cached? (take lock only when it's never been requested before)
zerver: locks are dangerous, might deadlock
Tobi: yeah, but without it you most probably crash :-)
zerver: this is one of the reasons I still prefer my "broken" solution in a way
zerver: it is simple, but it RUNS
jk: yeah, when calling Script.LuaUI in LuaRules(unsynced) then you need to wait until the LuaUI state is available (or you put the event on the queue - maybe only in none render-callins)
jk: it doesn't run ...
zerver: it is incompatible, but runs
zerver: so my vote is still to sever the _G/SYNCED communication for gadgets and use a mod option
zerver: next...
jk: zerver, you aren't a lua programmer
zerver: i fixed your LUPS...
Tobi: point is that when you will make it compatible you will still see the issues we are mentioning now
jk: I don't think you have any rights to request something like that, because you don't have any idea how important it is
zerver: it didnt seem very important in you LUPS, thats for sure
zerver: it is fairly easy to create the data you need on the respecive sides (synced/unsynced) without any other communication than SendToUnsynced
zerver: synced/unsynced bandwidth requirement is super low, if the code is properly written
zerver: sorry this discussion is getting long, im just worried we are getting nowhere because of to high backwards compatibility requirements
zerver: next...

main points:
  • some disagrement removed, some still present
  • zerver will move his changes to a branch (done)
  • jk will implement his idea (1st stage, using a branch too)
  • colaboration on job queues (jk and zerver)

git rules
hoijui: abma and me started an etherpad here:
hoijui: <stripped>
hoijui: we had some somewhere else already, but that got lost
hoijui: but what i want to discuss here mainly..
hoijui: when to use branches
hoijui: i mean.. this thing now..
hoijui: is kind of unacceptable to me
hoijui: using branches more makes live easier for others, and not harder for you (the branch owner) if people behave
hoijui: i mean.. 3 of us said it should be a branch, and you still put it into master again.. that is just bad.. creates anger for no benefit
hoijui: so.. we should try to do more branching.. if you are unsure, ask others, or just use a branch anyway
zerver: only because i thought i corrected the thing that annoyed you in the first place
hoijui: well... you really overread 70% of what i said then
zerver: single thread works like before, but that's not enough it seems.
hoijui: thing was, that we did not agree on the very principle you use to do it
hoijui: well.. just for the future.. use more branches
Tobi: compiling & running is not the only thing that matters, also design & implementation quality
zerver: im sorry, the explanation is probably that since i wrote 99% of MT, i think i have the right to break it :)
hoijui: i will be reverting stuff more aggressively from now on, when in such situations
Tobi: ok
hoijui: also... when someone has a branch somewhere, do not change lots of stuff in the are of the engine that branch is touching
hoijui: if you need to do that, use a branch
Tobi: :)
hoijui: small fixes and stuff is ok of course
hoijui: i think.. thats all i wanted to say

main points:
  • new etherpad for git rules for hte spring repo
  • use branches!
  • actions that cause problems for others will be reverted more aggressively

Next meeting
hoijui: same is ok for me
jk: me too
Tobi: next week is fine, although I'd prefer a different time in the week in the future, but we can discuss that next week I guess
Tobi: (gtg now in a few mins)
jk: hope Kloot will be back soon
hoijui: yeah :D
hoijui: is he gone somewhere?
jk: (his new branch is promissing)
hoijui: ah :-)
hoijui: mmm


Anything else? (WVTTK)
hoijui: i will do the minutes
Tobi: thanks
hoijui: btw, someone told me there are no debug packages in ubuntu, is that true?
Tobi: I thought they had, but I'm not sure, since I don't use it anymore
hoijui: ahh ok
hoijui: will ask others then.. or check online
Tobi: anyway I'm off to dinner, laters
hoijui: bye! :-)
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7049
Joined: 16 Nov 2004, 13:08

Re: Dev meeting minutes 2010-10-03

Post by zwzsg »

communication enhancement with mod-devs
Shouldn't moddevs be involved into designing the enhancment to mod dev to dev communication? I think a meeting should be held, with a topic of: How to involve the mod devs into the moddevs-devs-comm enhancment plan!

About Lua and multithread:

If you expect every Lua coders to understand and cope with multithreading problematics, you're in for a world of pain. Lua is supposed to be an easy scripting language that let people who are not experienced coders have more freedom in their modding. It has to remain simple to use and to understand, or it'll fail its purpose.

If you make half the gadget fails, and the fix is not obvious, then all modders will be up in arms against you.

Then, it feels sound to write something like _G.EXPORT.MyData instead of just _G.MyData when a gadget want to transmit MyData from synced to unsynced, and, as long you make a clear sticky about it, shouldn't cause thaaat much trouble. I mean, I haven't seen any gadget using _G for anything else than to send data to the unsynced side, so it'd be just a search'n'replace in all files.

On the other hand, if you require gadgets to be manually rewritten using a different logic, we'll be angry.
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-10-03

Post by zerver »

My branch is here and I have implemented the job queue already.
http://github.com/spring/spring/commits/luasplit

Remaining is the _G/SYNCED communication, and possibly fixes for Script.LuaUI.XXX that jK outlined.

I really hope jK does not start from scratch. I adopted his suggestions, now he should adopt mine. I'm requesting the split to be in LuaHandle instead of LuaHandleSynced, because I want to have REAL theading in LuaUI (not by default, but as a mod option). This is just as important to me as it is to have a working _G/SYNCED to you.
zwzsg wrote:On the other hand, if you require gadgets to be manually rewritten using a different logic, we'll be angry.
Since we are talking mod option here, no one is forcing anyone to change anything. New possibilities, not problems.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Dev meeting minutes 2010-10-03

Post by FLOZi »

zwzsg wrote:
communication enhancement with mod-devs
Shouldn't moddevs be involved into designing the enhancment to mod dev to dev communication? I think a meeting should be held, with a topic of: How to involve the mod devs into the moddevs-devs-comm enhancment plan!
+1 to this (and the rest)

If anyone is wondering what kloots promising new branch is, I think it's this:

http://github.com/spring/spring/commits/PathFlowField

:-)
SirMaverick
Posts: 834
Joined: 19 May 2009, 21:10

Re: Dev meeting minutes 2010-10-03

Post by SirMaverick »

zwzsg wrote:If you expect every Lua coders to understand and cope with multithreading problematics, you're in for a world of pain. Lua is supposed to be an easy scripting language that let people who are not experienced coders have more freedom in their modding. It has to remain simple to use and to understand, or it'll fail its purpose.

If you make half the gadget fails, and the fix is not obvious, then all modders will be up in arms against you.
Speak for yourself. I think nobody is interested in rewriting/patching all gadgets/widgets for nothing. But if you get a benefit then you might be motivated to do so. I would be.
As far as I understand, you don't have to deal with different threads in Lua. Just communication (and semantics?) might change a bit.
Since we are talking mod option here, no one is forcing anyone to change anything. New possibilities, not problems.
User can use a MT spring version but mod disables those benefits. How do you sell this to the user?
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-10-03

Post by zerver »

SirMaverick wrote:User can use a MT spring version but mod disables those benefits. How do you sell this to the user?
We will fix it so it is much better than it is now, but it will probably still be inefficient in some ways. The mod option would be for those who want to explore a new programming paradigm.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Dev meeting minutes 2010-10-03

Post by Forboding Angel »

FLOZi wrote:
zwzsg wrote:
communication enhancement with mod-devs
Shouldn't moddevs be involved into designing the enhancment to mod dev to dev communication? I think a meeting should be held, with a topic of: How to involve the mod devs into the moddevs-devs-comm enhancment plan!
+1 to this (and the rest)

If anyone is wondering what kloots promising new branch is, I think it's this:

http://github.com/spring/spring/commits/PathFlowField

:-)
++1

@sirmav and zerver
You guys sorely underestimate the amount of code that would have to be re-written. And yes, if you break gadgets, you will end up starting a war.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Dev meeting minutes 2010-10-03

Post by Argh »

I'd be fine, if the changes to go MT-friendly were:

A. Not giant messes, in terms of changes to core OpenGL operations. I haven't heard anything that makes me think that's an issue; I just want to make sure that's clearly understood.

B. Well-documented, and with active support from the developers to get us past the initial hurdles. Not, "here's an example with a hugely complex Gadget", but "here's a very simple example with comments, and if you're still stuck, I'll help out".

I'm not sure it's wise to encourage us to get involved until you guys are arguing less about first principles and architecture issues; that says to me that anybody who jumps in right away will get their fingers burned pretty badly. And that will definitely bring us out with pitchforks and torches ;)

CA's team may be able to afford the manpower costs of experimentation (i.e., SirMaverick can run a branch without hurting overall development), but I don't think any other project can, and if I were them, I wouldn't do it until the arguments are not about core issues but are just sniping about particulars.

And on the subject of dev-->modder communication...

1. I like the meeting notes, because they at least tell us what's being looked at.

2. I think that we need to have the ability to create polls and vote about important features, so that anybody can have a say without bothering to argue about stuff. Then developers know what people are actually interested in.

That doesn't mean it gets done, but it would be useful as an interest gauge and help developers understand what people actually want, as opposed to whatever sounds vaguely interesting today.

Spring's developers largely appear to ignore what game developers want prioritized; this makes it difficult to have a healthy relationship, because a lot of the time, it feels adversarial rather than communal.



Lastly... there are other issues that I'd like to see tabled at the next meeting:

1. Why are we still showing advertisements for IW on the front page? Their vaporware status as a product is why I've been unwilling to put up promotional materials for my free stuff or participate, and it still makes me angry every time I see it. They haven't even updated in 5 months; isn't it time to finally acknowledge that Spring's front-page PR has been an awful failure and is managed by the wrong people?

2. In light of 1... isn't about time we got somebody competent to handle marketing? I have proven experience in this area, and I'd be happy to do it, if I don't have to deal with a committee second-guessing me for the first month (after that, we can judge by results).

If you don't like that choice, second choices would be Forb, if he's willing to give you the time, or AF, ditto. Having Moderators who don't actually make or market games, don't have strong visual-arts skills and have no track record is just bad policy. I would like to see this reviewed. I'm not talking about rebuilding the front-page, btw- I think it's fine, structurally. Just dealing with the content and presentation.
slogic
AI Developer
Posts: 626
Joined: 17 Mar 2008, 19:03

Re: Dev meeting minutes 2010-10-03

Post by slogic »

Why 0.82.6 won't include #2083 (Unit don't stop moving to unreachable place) & #2085 (ghosted and real view of a unit shown at the same time (for specs)) issues?
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: Dev meeting minutes 2010-10-03

Post by raaar »

Argh wrote: And on the subject of dev-->modder communication...

1. I like the meeting notes, because they at least tell us what's being looked at.

2. I think that we need to have the ability to create polls and vote about important features, so that anybody can have a say without bothering to argue about stuff. Then developers know what people are actually interested in.

That doesn't mean it gets done, but it would be useful as an interest gauge and help developers understand what people actually want, as opposed to whatever sounds vaguely interesting today.

Spring's developers largely appear to ignore what game developers want prioritized; this makes it difficult to have a healthy relationship, because a lot of the time, it feels adversarial rather than communal.
raaar agrees.

But there's also the question.....what do we want prioritized?
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-10-03

Post by AF »

slogic wrote:Why 0.82.6 won't include #2083 (Unit don't stop moving to unreachable place) & #2085 (ghosted and real view of a unit shown at the same time (for specs)) issues?
+1, #2083 is a behaviour bug that needs fixing for ingame behaviour and AI purposes, #2085 is a glaringly obvious rendering optimisation/bug
zerver
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Re: Dev meeting minutes 2010-10-03

Post by zerver »

It does include #2085, sorry if the changelog is not up to scratch.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes 2010-10-03

Post by smoth »

Argh wrote:1. Why are we still showing advertisements for IW on the front page? Their vaporware status as a product is why I've been unwilling to put up promotional materials for my free stuff or participate, and it still makes me angry every time I see it. They haven't even updated in 5 months; isn't it time to finally acknowledge that Spring's front-page PR has been an awful failure and is managed by the wrong people?
And PURE's gadgets fail resulting in broken gameplay. Back off glass house.
User avatar
lurker
Posts: 3842
Joined: 08 Jan 2007, 06:13

Re: Dev meeting minutes 2010-10-03

Post by lurker »

zwzsg wrote:Then, it feels sound to write something like _G.EXPORT.MyData instead of just _G.MyData when a gadget want to transmit MyData from synced to unsynced, and, as long you make a clear sticky about it, shouldn't cause thaaat much trouble.
Nah, you'd write EXPORT.MyData, so it's even clearer than before.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-10-03

Post by AF »

This is RICH coming from you Argh. You have a game developers dream for a website. You have a large traffic inflow, minuscule bounce rate, and people tend to stick around and browse every page on the site and invest in some cases hake an hour just looking at the thing, yet you ignore it and disregard it.

You are turning away thousands of people every month by showing them a site which you have neglected and left to bit rot, so that you can focus on such primetime opportunities as a 700x200 rectangle that may or may not show on a site you have no control over.

What is more, I wanted to go back to it and make updates only to find that my FTP was limited to the one folder and that what changes I tried to make didn't show up on the main site. I've been locked out. I still have google analytics statistics for the site however, and I am seriously telling you as a web developer, you are throwing away an opportunity that companies pay millions of dollars trying to get.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Dev meeting minutes 2010-10-03

Post by Argh »

Smoth: I've been doing my best to figure out the issues, so that when it's finally done, it's working right. You've got to understand, though, that I've never been able to reproduce the problems you've experienced, so I'm still not entirely sure what broke on your machine or why it dumped everything.

That, and I'm here working on it again to finally make it work, only to find that the engine's a lot slower than it was and that we're still missing a lot of things I hoped would be working by now, like MT, that might make performance less of a dreadful gordion knot.

Please try out the build I've posted in the profile build thread, and let me know what happens. If everything there works, that eliminates about 90% of the places where problems may have been occurring- i.e., it's down to Mission code going off the rails or a couple of minor Gadgets in the core- and I'll be happy to make you a private test scenario (i.e., a beta build of the game that should allow you to finally see it). There is one remaining GLSL bug somewhere in LUPS that I still need to nail down, but it's all that's left.

As for IW: if they're making progress, great, but projects without a release should not be allowed to advertise on the front page, imo (which, yes, means no mention of P.U.R.E. at all, since it's been basically dead since 0.79). My impression was that they were dead. Neither gnome nor wz have been here in ages.

AF: I don't have anywhere useful to go with this project until it's working and satisfies the promises I've made.

I dread saying stuff in public about it, when I've been unable to do what I wanted, the engine keeps being a moving target that breaks stuff and works worse, and I'm really not sure what kind of game I can deliver, if I don't see something happen in terms of performance. I hate making promises I can't deliver.

Until I understand what's going on with performance, I can't even say whether it's practical to continue, or under what strategy- zerver's comments suggest MT may be testable soon, but testable isn't stable and well-understood, and I am very afraid of wasting a month or more chasing wild geese.

Like Smoth, I suggest downloading the profile build, so that you can see how far new-tech development went before I ran into various walls six months ago. It won't show you the game modes and things, but I'll be honest and say that they are still crude enough that it's not that important.

If there are easy solutions, by all means let me know, preferably via PM and without yelling at me.

_____________________________________________________

In general, though, the reason why I volunteered is because I know I can do it. It wouldn't just involve the banners- I have a marketing plan and stuff, and I'm pretty sure I can do it well.

And frankly, until I know P.U.R.E. is a useful product and not just a collection of tech, it may be the only worthwhile thing I can do to repay all the people who've done work on my behalf- if I can't make P.U.R.E. fly, maybe I can help Spring.

I hate to be this gloomy about it, but as you'll see when you see the profile build, the performance figures tell me that I may never be able to deliver anything else here, or maybe not for another year, when things finally get settled out.

Is that disappointing? Hell yes it's disappointing. But nobody promised me a goddamn rose garden, and I have to deal with what I've got.
Last edited by Argh on 05 Oct 2010, 22:17, edited 1 time in total.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-10-03

Post by AF »

o_0 you so didnt read my post, my post had NOTHING to do with springs performance, infact it was lamenting your complaining over the hundreds of people who may or may not see a small banner, at the cost of thousands of people viewing a dedicated website for sometimes as much as twenty minutes.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: Dev meeting minutes 2010-10-03

Post by Argh »

I'm just explaining why I'm not talking there. If it was just a matter of talking, I'd be happy to talk. I quit talking because there's nothing to say that wouldn't either be wishful thinking or incredibly gloomy.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: Dev meeting minutes 2010-10-03

Post by AF »

You post plenty of stuff on moddb and here that could be copy pasted literally onto that site with no modification beyond uploading images ( which you don't always have anyway ).

As a medium, it's illogical and hypocritical to ivnest massive amounts of time and effort on the frontpage banner when you have a dedicated website with an audience an order of magnitude larger thats not being given an ounce of attention. You havent even posted 'I dont have much time on this site but here's my moddb and my P.U.R.E thread on the spring forums'
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Dev meeting minutes 2010-10-03

Post by knorke »

uuhuuuu pretty hot in here. i guess i can stay for half a minute:
communication enhancement with mod-devs
seems some new callins were added:
ie PlayerAdded and PlayerRemoved http://springrts.com/mantis/view.php?id=2134

would be nice if such things could also be updated in the wiki otherwise nobody knows about them.
kthxbye.
Post Reply

Return to “Meeting Minutes”