Release plan <abma>who will make the release? jk again? <abma>if so, whats left? <jK>I am doing so right atm <abma>aaah, nice <abma>afaik current release branch is fine <abma>did a testgame with zydox and it seemed to work fine... <jK>nice to hear
conclusion: hopefully tonight a 87.0 release
"Map creation" in forum <abma>http://springrts.com/phpbb/viewforum.php?f=13 <abma>as it currently is, its more a forum for releases <jK>+1 <abma>my suggestion is: lock the tutorials subforum, because all tutorials seems to be to old and they should go to the wiki... <abma>+ add a "map release subforum" <abma>i can't do that, i've no access... :-/ <abma>[RoX]Tobi: can you do that? <abma>i just want to keep the meeting at high speed
Google Summer of Code (GSoC) <abma>i try to register at least, maybe we are lucky... (i know, having a gsoc will make much work) <abma>but i would be happy if we could get / do it <abma>so... if you have ideas, please add to http://springrts.com/wiki/Project_proposals <abma>i tried to make it a more general page and not so gsoc related <abma>(+ year independant) <jK>really nice what you are doing there <abma>thanks... <zerver>yeah <Tobi>+1 <abma>:-) <abma>i skip the points "merge luasocket / remove lualobby" ... because release + setting live comes first
conclusion: Google, please choose our GSoC projects, we'll attract the best coders!
possible solution for in-source lua documentation <abma>i was a bit anoyed by the current lua-docs... <abma>when i search for a function i need, i currently grep the source code... <jK>nearly impossible cause of the way lua works <abma>a possible solution would be, do the comments in the c++ source <jK>-> one function & multiple syntaxes <abma>and we use a custom syntax which is then used by a doxygen filter that prepares it for doxygen <abma>i didn't fully investigate if it works as we need it <jK>doxygen doesn't support multi syntax <abma>if not, adding some output stuff for the script shouldn't be so hard <abma>multi syntax? <jK>Spring.PlaySound("foobar.wav") Spring.PlaySound("foobar.wav", volume) Spring.PlaySound("foobar.wav", pos_x,pos_y,pos_z, volume) <Tobi>one C++ function mapping to multiple ways to call it in Lua isn't really a problem (although doxygen alone would be insufficient) <jK>that's a bit more than simple overloading <Tobi>harder problem may be those APIs that partially rely on Lua functions, in addition to the C++ stuff <zerver>I agree it would be neat to have in-source docs, it is so easy to forget to update external docs <jK>atm I would concentrate on auto-documentation of Unit/Weapon/CEG-defs <jK>those are much easier to parse <abma>hmm, i thought that a custom doc-string is added, at a place where it fits best <abma>and i see, its much more complicated than i thought :-/ damnit <abma>my idea was, to add the comment, directly to the function, for example for Spring.Echo, exactly here: https://github.com/spring/spring/blob/d ... s.cpp#L722 <zerver>Need some custom parser to extract these docs maybe <abma>yeah, sure <Tobi>extracting comments can be an awk one liner <abma>doxygen seems to be a bit inflexible there... <jK>Spring.Echo is already a special case but still easy to document with doxygen syntax (it uses vararg similar input) <Tobi>only when you want to integrate it with knowledge of the actual code you face a learning curve with near infinite slope <jK>the syntax variations of many other lua function are _not possible_ in c++ <jK>e.g. Spring.PlaySound("foobar.wav", volume) Spring.PlaySound("foobar.wav", pos_x,pos_y,pos_z, volume) <abma>yeah, thats what i expected, but i don't know all cases <jK>volume is a float & pos_x too <Tobi>just don't use doxygen <jK>so it is no c++ overloading <Tobi>or at best, re-use the formatting a little bit, so the comments still look acceptable in doxygen <abma>[RoX]Tobi: yep, that seems to be the only possibility as a doxygen filter isn't enough... <Tobi>but implement custom extracter -> parser of the comment syntax -> generater of HTML <Tobi>I wanted to do exactly this quite a while back, but was too ambitious; I wanted to also make the comments edittable on the web and automatically generate commits from the edits <Tobi>combined with lack of time it didn't work out <abma>[RoX]Tobi: hmm, with github, it is close to that... <jK>documenting a function like Spring.PlaySound in a doxygen similar way would need >2 pages <Tobi>abma_irc: yeah, github obsoletes this idea anyway (IIRC it was before github had web editor) <jK>you would need a totally new syntax to eff. document those functions (e.g. each possible syntax combination is on it's own _single_ line, and the param themselves are document beneath separate) <Tobi>jK: [21:56:52] <[RoX]Tobi> just don't use doxygen <abma>yeah, thats maybe a conclusion, no doxygen <abma>ok, thanks. thats many input.. i try to write it down to the project proposals wiki page
conclusion: in-source lua-api documentation will be a huge project: doxygen can't be used so it will be something like a tiny doxygen
status of touchdev branch <abma>(i always forgot the name of the guy that wrote it, sorry) <Tobi>the only thing that may be nice is if the comment doesn't look totally obfuscated in doxygen, but that could be a matter of wrapping the whole block in <code></code> or whatever the doxygen equivalent is for that <abma>[RoX]Tobi: i would suggest /*- .... */ doxygen should ignore it completely then <abma>ok bill wrote the touchdev stuff <abma>he said, it seems to work fine, i also added some of his lua widgets that use it, but they have to be cleaned up first <Tobi>that would work too <jK>abma, check my todo list for things that should be done before merging it <abma>[LCC]jK: thanks, will look into these <abma>ah, bill also told me, he still works on it, but he has very few time <abma>thats it for that point... <jK>also TUIO should be replaced with XInput2.x <jK>but that's a feature request <abma>ok..
conclusion: the touchdev branch is alive, but there are still some points left to get it merged (mainly code-cleanup)
delete old git branches (those 5 0.82 ones + syncdebug-gcc-4.3)? <jK>anyone needs them? <jK>are there any important commits in those, not commited to dev-branch? <abma>if still not, bad luck i would say... <Tobi>can delete them afaics <jK>k will do so then
conclusion: jk will delete those branches
extend Spring.Echo() to allow a loglevel parameter? <abma>i need a echo function that allows to set the loglevel <abma>i would use it for printing lua error messages to stderr <abma>do you see a way to extend Spring.Echo() that a errorlevel can be set? <abma>currently it accepts all as parameters... <abma>my idea was, to check, if the last parameter is an int, if so, use that as loglevel <abma>this should break very few lua code <zerver>should work <abma>if not, i would add Spring.Log() <abma>with msg, loglevel as parameters, where loglevel is optional <jK>bad idea <jK>that one -> <abma> my idea was, to check, if the last parameter is an int, if so, use that as loglevel <Tobi>yeah <jK>if at all you can use custom lua userdata or strings <zerver>Maybe first param instead? <zerver>But Log may be cleaner... <jK>so Spring.Echo("LOG_ERROR", "foobar") or Spring.Echo(LOG_ERROR, "foobar") <jK>but I would prefer adding Spring.Log <abma>yeah, this will break no existing code... <zerver>Neither will Spring.Echo(LOG_ERROR, "foobar") ? <zerver>you cant echo an int iirc, has to be string <abma>hm, afaik Spring.Echo(1,2,3,"test","test") works... <abma>Echo calls tostring() <zerver>aha <zerver>then definitely Log() <abma>ok, thx <abma>then we are finished :-D <zerver>But I am sure I tried to echo something, and it failed. Maybe it was a bool. <zerver>or nil <jK>Spring.Echo() doesn't output anything <Tobi>it could work if LOG_ERROR is a userdatum, but Spring.Log is cleaner IMO <jK>same as Spring.Echo(nil) <abma>https://github.com/spring/spring/blob/develop/rts/Lua/LuaUtils.cpp#L776 ? <jK>but Spring.Echo(nil, 1) will print "nil, 1" <jK>and yeah, in my example LOG_ERROR is not an int, it's a userdata <zerver>yeah <abma>hmm, Spring.Log seems to be much cleaner for me... even if its the same function with some tiny difference <Tobi>yes, it *is* much cleaner <abma>zerver: should your last commit go into release or not? <Tobi>abma_irc: did you figure out about the mailing lists? <abma>it seemed to work? <zerver>it was an accidental float instead of bool, but IIRC it makes no difference <Tobi>yeah <zerver>true = 1.0f and false = 0.0f <abma>[RoX]Tobi: then its fine... <Tobi>ok <abma>where do i define LOG_ERROR / LOG_INFO /... for usage in lua? <abma>is there already some place for such consts? <abma>or don't define and use 1, 2, ...? <jK>hmm don't think it's already done in our lua api that way <jK>will see if I can write it (it's not that hard, but you need some knowledge about lua's userdata types) <jK>-> here `light userdata` is needed <abma>aah, ok <abma>+ thanks <jK>np <abma>thats what i've already: https://github.com/abma/spring/commit/c ... 3dc4e9daea
Map release gets followed by suggestion and improvment. Maps making discussion gets followed by map release. The two are so intermingled you'd get half of the posts in release forum be about creation and half of the post in creation forum be about release.
Then it's not really clear what you meant so maybe I misunderstood.
Joined: 22 Feb 2006, 01:02 Location: cheap kitchen
imo close Map "Tutorials & Resources" and "Game & Module Development Tutorials & Resources" subforums: It is the same as wiki except that the articles always get broken because only the original poster can update them. This also means they never get really completed and are poorly structured.
the tutorials sometimes get interesting comments with issues and changes being posted there.
You can still make threads like "I have a question about this tutorial [link], blablub" Most comments are like this:
Is there another link to Mapconv? The above doesn't work.
- IMO the forum should be locked - give us 2 weeks to pull the content into the wiki as we need it. -- we have wysiwyg, there is no excuse now! - after the 2 weeks, merge the threads back into mapping, do not sticky them, do not pin them in any way, they are old threads, let them go to the elephant graveyard. - post links to the old threads in my profile in the wiki. I don't mind being a holding place for the location of this old data.
We can do this with all tutorial and resource sections for the next 2 months and should effectively cleanup the forum and beef-up the wiki.
the change i suggested is currently only about the map creation forum. if thats a success, that should be changed for the other content creation forums, too. imo the anouncements of new features in the engine should be directly in the map creation forum, and not in the tutorials... (or just in the release notes)
the current map tutorials are bad for new mappers, because all tutorials are outdated / don't work and nobody (expect the thread creator) can fix it. thats awful! we lock out new possible mappers because of this!
Not trying to argue one way or other, I can always copy the threads into the wiki all the same I just wanted to understand why the same thing cannot be done in the wiki? Discussions can still happen on the forums. The old threads do not and should not have to be deleted.
Maybe, but to see them you have to read a whole thread: http://springrts.com/phpbb/viewtopic.php?f=56&t=23654 Two more parameters for the SMD are mentioned in thread: skyReflectModTex detailNormalTex But not added to original post, so to learn about detailNormalTex you must read until page 2.
what about a combination knorke? like after a helpful thread like that is added, the OP could add a wiki page link to the top once it get some many pages? that way people can see the consolidated version of the post in the wiki?
Users browsing this forum: No registered users and 1 guest
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum