Syncing our dev branches

Syncing our dev branches

Postby kripken » 23 May 2010, 06:01

This topic is for offline communication between kripken, quaker66 and T7g (and perhaps others), regarding syncing the main dev branches.

Great work guys :) , I have started to go over your commits and merge them in. I am very impressed. Lots of stuff to talk about though, for starters:

  • {l Code}: {l Select All Code}
    -            {
    -                std::string _class = '@' + logicEntity.get()->getClass(); // '@' makes Sauer create a copy
    -                particle_text(entity->abovehead(), _class.c_str(), 16, 1);
    -            }
    +                particle_text(entity->abovehead(), logicEntity.get()->getClass(), 16, 1);

    This looks suspicious. Should it be particle_textcopy perhaps?
  • The README.markdown completely overwrote the syntensity one. This makes merging hard. I suggest either just adding to the existing one, or using a separate file for the sauer svn revisions that constantly change.
  • I tend to think the Flashlight code should be in a separate file, and not in Character.js. I am open to suggestions for how to organize this stuff though.
  • SkyManager code: (1) skymillis in main.cpp - purpose? (2) rendermodel stuff - purpose? Also, changes in sauer engine files should have // INTENSITY or some other clear marker that they are not originally sauer code, to help with issues down the road. (3) Best to add new lines when possible, not append stuff to existing lines (nicer diffs that way). (4) Use spaces, like the existing source code - tabs messes up the indentation (see how the diffs look in github for example).
  • Lots of commits with new graphics etc. - they lack license info though, without which I can't merge it into the main branch.
  • This commit mixes a sauer sync with new bitmaps...? http://github.com/quaker66/intensityeng ... 893da1145d

Again, great work, I hope we can move quickly with the merging and finish it soon.

- kripken
User avatar
kripken
Syntensity Moderator
 
Posts: 52
Joined: 12 Jan 2010, 13:45

Re: Syncing our dev branches

Postby t7g » 23 May 2010, 06:43

<T7g> kripken, I can corroborate quaker's story about nieb's stuff
<T7g> I was here when he was talking to him and when the license text "For Sauerbraten only" was removed.
<T7g> but yeah, suppose more clear terms would be better
<T7g> sorry, haven't done much lately, have just not had motivation followed by a bunch of stuff I had to do
<T7g> don't have any new gdb backtraces or anything, in fact I need to make some food.
<T7g> kripken, skymillis in there, well- I need skymillis cause I need to sync sun to something like lastmillis but I need to reset it.
<T7g> sauer drifts a lot by it's rotation system
<T7g> to have any sort of sync I had to be able to reset lastmillis (which you can't do) so I created skymillis as a duplicate that I could reset so every cycle at midnight all clients square off on sun position
<T7g> I tried to do it many other ways but it just couldn't be done without resetting that
<T7g> rendermodel stuff is used to do the ambient lighting of map models so they don't always stay dark or lit, they change with the skylight now
<T7g> as if it were really being lit by it
<T7g> as for spaces instead of tabs, quaker spoke to me about that but only after I had done extensive work but if you note some of my latest commits I've made an effort to replace tabs with spaces
<T7g> the new bitmaps I either did or quaker ganked other bitmaps from other projects with proper licenses for us to use them?
<T7g> the license.txt should specify
<T7g> it was just trying to clean up stuff like the particle system
<T7g> some of the ones we had by default were subpar, some were missing
<T7g> and where the license terms were not clear I tried to redo the particle graphics
<T7g> not all were included but not all were good.
<T7g> So, we can go over the new graphics, all the stuff I did is as free as free can get- as for the flashlight code, yeah I agree with you. (It's also not even working proper in multiplayer I don't think)
<T7g> I think I explained the SkyManager stuff, I'll comment better and do spaces instead of tabs and clean up where I can
<T7g> it'd make a lot more sense if you saw the state of things these days, I stopped making example videos out of laziness- you can't experience it through video like you can ingame.
<T7g> playermodels, mapmodels, ambient light all adjust properly and sync with the sun'
t7g
 
Posts: 2
Joined: 11 Apr 2010, 15:11

Re: Syncing our dev branches

Postby quaker66 » 23 May 2010, 10:57

hey kripken. about the textcopy thing, that was solved in one of next revisions.


{l Code}: {l Select All Code}
debian@debian-desktop:~/sauerbraten/intensity-p/src/intensity$ grep 'entity->abovehead(), logicEntity\.get()->getClass()' *
character_render.cpp:        particle_textcopy(entity->abovehead(), logicEntity.get()->getClass().c_str(), 16, 1);


about the README.markdown, i used it to mark new revisions.

about the Flashlight code, it waits for rewrite to better system. i'll try to do that today. for now, merge the current code if you want, or not if you don't.

new graphics with lacking license - you can merge them, since if they lacked license, it was added in next revisions, about that one commit, most of images were replaced and they all have license info now. There is currently no content that lacks license except those nieb's textures/models which i need to talk about with him
quaker66
 
Posts: 1
Joined: 23 May 2010, 10:55

Re: Syncing our dev branches

Postby kripken » 23 May 2010, 22:11

@T7g: What would be best is if you could make a new patch for the SkyManager (all of it together in one patch), so I can read it all at once, and include in that patch the things I mentioned like notes in sauer code, tabs, etc.. Because looking through the many existing commits is hard, and figuring out from the current trunk what is relevant and what isn't is even harder.

I would very much like to have the SkyManager in main syntensity, but it is a lot of code, and so I need to be careful about merging it. In particular where sauer code is modified, it may make future merging with sauer (or diverging from what sauer does) very hard - hence I ask for clear notes like syntensity uses when modifying sauer code.

@quaker66: Cool, thanks for the info.
User avatar
kripken
Syntensity Moderator
 
Posts: 52
Joined: 12 Jan 2010, 13:45

Who is online

Users browsing this forum: No registered users and 1 guest