0.3.1 - Let's release it :)

Website · Post by **Z-Man** » Thu Jan 01, 2009 2:19 am

How? Can you provide screenshots? I'm not aware of any differences in rendering methods.

HEXadecimal · Post by **HEXadecimal** » Thu Jan 01, 2009 2:48 am

my bad, however the lines on the floor do look whiter, i guess i got my foot in my mouth.

on a side note i think the clock and mini map shouls also be included in 0.2.8.3 release.

i find the mini map/radar invaluable to game play

HEXadecimal · Post by **HEXadecimal** » Thu Jan 01, 2009 2:50 am

The Extension bmp is not allowed?

by the way Happy New Year to all

Website · Post by **Z-Man** » Thu Jan 01, 2009 1:47 pm

Convert them to png, then. Or upload them to http://xs.to .

HEXadecimal wrote:on a side note i think the clock and mini map shouls also be included in 0.2.8.3 release.

No way. Too much code is attached to those for a remotely clean backport.

Post by **Lucifer** » Thu Jan 01, 2009 2:59 pm

Isn't there already a clock in 0.2.8?

Besides that, this may be the first release since we started in bzr. My question is, should I branch in svn and then create a bzr branch from that, or should I branch from bzr?

(Not yet ready to branch, but I want to be ready for it when we do)

Website · Post by **Z-Man** » Thu Jan 01, 2009 6:01 pm

Since this is a development release, I'd opt for testing a bzr-only approach. We can finish and refine epsy's name-version-from-bzr shell stuff then, and see again how well bzr merging works (we already have some experience with the sty branch, where it works well.) And even after we throw away the 0.3.1 release branch, the individual revisions and release can still be recovered later from the trunk bzr branch (I don't think that detailed information survives the transition to svn, though. bzr tags definitely don't survive. I'll test it with some merges we already have.)

Pre-emting luke-jr: yes, that means we won't be able to reconstruct 0.3.1 from svn later, at least not easily. And yes, this means the world will end, fire and brimstone etc.

HEXadecimal · Post by **HEXadecimal** » Thu Jan 01, 2009 7:33 pm

if it pleases your majesty

HEXadecimal · Post by **HEXadecimal** » Thu Jan 01, 2009 7:35 pm

if the mini map isnt in .2.8.3. then im afraid im just going to have to keep using 0.3

and as i said earlier the gridlines are a lot brighter.

sinewav · Post by **sinewav** » Thu Jan 01, 2009 10:25 pm

HEXadecimal wrote:and as i said earlier the gridlines are a lot brighter.

Hmm.. Isn't that in "settings_visual.cfg"? The 0.2.8 settings are:

FLOOR_RED .2
FLOOR_GREEN .2
FLOOR_BLUE .2

Did the settings or "floor.png" change in 0.3? So HEX, you like the brighter grid or no? Why not just change the texture/settings for 0.2.8 or 0.3 on your local machine? It's a pretty small thing to worry about IMO.

HEXadecimal · Post by **HEXadecimal** » Fri Jan 02, 2009 12:00 am

I do infact like the brighter grid, I thought it might have been new textures however it seems you guys messed with the color scene. Anyway I hope the setings get moved down too 0.2 branch

Website · Post by **Z-Man** » Fri Jan 02, 2009 12:01 am

Yep, that's it

Trunk has brighter values there in the configuration file.

svn blame wrote: 4992 z-man FLOOR_RED .5 # floor color (without moviepack)
4992 z-man FLOOR_GREEN .5 # floor color (without moviepack)
4992 z-man FLOOR_BLUE .7 # floor color (without moviepack)

It only looks like I did that

Apparently, it's the result of a merge from 0.3.0 where joda.bot did the change. I don't disagree with the choice, though, at least not here on my laptop monitor.

Also, on retrieving merged bzr revisions out of svn: It doesn't work, of course. Actually, I'm glad about that. If it did work, bzr-svn would need to store tons of metadata (in addition to the metadata it already stores) hidden in the svn tree.

Edit, SCM dick waggling: "bzr blame" would have attributed the color changes correctly to joda.bot if the merging was done in bzr

apparition · Post by **apparition** » Fri Jan 09, 2009 7:11 pm

So, 0.3.1... LET'S RELEASE IT NOWZ!

Can't wait, fellas.

madmax · Post by **madmax** » Sat Jan 17, 2009 6:26 pm

Console suggestions, that thing when you type "rubber" in the console and it says "did you mean CYCLE_RUBBER" etc, aren't enabled for trunk/MacOS apparently.
wrtlprnft found this in src/tools/tConfiguration.cpp:

Code: Select all

#ifdef MACOSX
    printErrors = false;
#endif

It seemed to work fine (as expected) when I took it off. The revision was this one

Post by **Tank Program** » Sat Jan 17, 2009 7:52 pm

I really do wonder how that one snuck in there. I also seem to remember noticing this in 0.2.8.2.1 on OS X, but I might be making things up.

wrtlprnft · Post by **wrtlprnft** » Sat Jan 17, 2009 8:55 pm

Apparently it was introduced when nemo/dlh merged the ruby branch… probably some temporary hack when ruby broke config error messages.