0.2.8.0 final: Release process and bugs

Help test release candidates for the next release
Post Reply
User avatar
Phytotron
Formerly Oscilloscope
Posts: 5041
Joined: Thu Jun 09, 2005 10:06 pm
Location: A site or situation, especially considered in regard to its surroundings.
Contact:

Post by Phytotron »

I guess it's a bug, then, because they continue to change around each time I view the master server list, even without me touching +/-.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Hmm, maybe OSX sends the wrong keypresses. Could you produce a recording? Like, start with a clean frommaster.srv enter the server browser, watch it, enter a server, quit right away, enter the server browser again, watch it, quit the game. See if it messed with the biases, if yes, submit the recording, if no, repeat or try something else.
User avatar
belenus
Round Winner
Posts: 269
Joined: Wed Nov 30, 2005 6:22 pm
Location: Cologne
Contact:

Post by belenus »

z-man wrote:Luke: Ok, then, suggestions how to do this welcome. Detection can be done by the machine type (we already do some stuff based on it, like selecting the right way to link with X11), that's no problem. But for the implementation of the init mechanism, I'd need help.
I actually just wanted a check for uname and if the OS is *BSD skip the part of creating the init.d stuff, but as you asked for it...

...this should work with OpenBSD, not sure about other BSDs
You do not have the required permissions to view the files attached to this post.
- bel
User avatar
Phytotron
Formerly Oscilloscope
Posts: 5041
Joined: Thu Jun 09, 2005 10:06 pm
Location: A site or situation, especially considered in regard to its surroundings.
Contact:

Post by Phytotron »

Right, here it is. I sent frommaster.srv to the trash before starting the recording. Then I just did some various things—going to master server, exiting, going back, going into a server, exiting, going to master, etc. First half I never touched +/-, then toward the end I did on a few servers, just for experimental-type thangs. Whatever, you'll see.

One thing I noticed was that Swampland wouldn't change on its own (prior to +/-), but others, like Shrunkland, would.
You do not have the required permissions to view the files attached to this post.
Last edited by Phytotron on Fri Mar 24, 2006 4:18 pm, edited 1 time in total.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Belenus: Thanks, I'll look at it.

Silly: Thanks, too, but it doesn't play back far enough :( Recordings sometimes fail if you press two keys too close together (like leaving a server->entering the internet game menu again immediately), I'm working on it.
User avatar
Phytotron
Formerly Oscilloscope
Posts: 5041
Joined: Thu Jun 09, 2005 10:06 pm
Location: A site or situation, especially considered in regard to its surroundings.
Contact:

Post by Phytotron »

Alright, I made you another recording with less quickly successive key presses. I just replaced the file in my previous post.

And while I'm here, would the following count as a bug report or simply expected behaviour on some video cards: "ZTrick makes the graphics go totally flippin' bonkers when I turn floor rendering to textured or dual textured plane." :)
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

It's expected behavior and even warned about in the tooltip help :)

There's another reason recordings with internet server browsing in them don't always work: the random master is really taken randomly and not with one of the reproducible random number generators. Luckily, the DNS resolver, which is also recorded, puts things right most of the time. This recording plays back on enough attempts :)

But it doesn't show anything unusual; as far as I can tell, only those servers you actively modified have a modified score bias in the end. Note that once you made one score bias negative, the server won't be polled the next time and be at the bottom (happened with Iceman's). If you make the score bias positive again, it'll jump up. That's normal.
User avatar
Phytotron
Formerly Oscilloscope
Posts: 5041
Joined: Thu Jun 09, 2005 10:06 pm
Location: A site or situation, especially considered in regard to its surroundings.
Contact:

Post by Phytotron »

You didn't notice that some scores were changing before I set any score biases? I did the second half where I changed a few scores just in case you wanted a comparison or something; I dunno. But I'm fairly sure some servers changed scores in the first half of the recording, before I ever set any score biases myself. ::shrug:: It's not a big deal to me personally, but if it's a bug....

Also, while I'm here :) were there any changes in rubber code and/or anything related to cycle_delay between beta_4 and 0.2.8.0 final?
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Oscilloscope wrote:You didn't notice that some scores were changing before I set any score biases?[/qoute]No, just the usual reshuffling of servers as those who get polled later, but get a higher score, fight their way upstairs. Of course, the scores don't need to be the same every time, they're calculated from the bias, the ping and the number of players. If it's a bug, I didn't see it here, sorry.
Oscilloscope wrote:Also, while I'm here :) were there any changes in rubber code and/or anything related to cycle_delay between beta_4 and 0.2.8.0 final?
Yes, there was a bugfix to cycle_delay handling. There always was a minimum cycle_delay of, say, .01 seconds enforced. Which was silly, so it was removed. It originally was to combat floating point problems, but I found a better way.
Rubber code, IIRC, was not touched.
User avatar
Phytotron
Formerly Oscilloscope
Posts: 5041
Joined: Thu Jun 09, 2005 10:06 pm
Location: A site or situation, especially considered in regard to its surroundings.
Contact:

Post by Phytotron »

z-man wrote:Of course, the scores don't need to be the same every time, they're calculated from the bias, the ping and the number of players.
That's all I was wondering in the first place. : /
z-man wrote:Yes, there was a bugfix to cycle_delay handling. There always was a minimum cycle_delay of, say, .01 seconds enforced. Which was silly, so it was removed. It originally was to combat floating point problems, but I found a better way.
Rubber code, IIRC, was not touched.
But cycle_delay affects rubber behaviour, as I've recently discovered on Shrunkland. I don't know if that's anything new. When it was raised from .03 to .07, adjusting onto a wall became way too sensitive. I'm not talking about cases when one is already on a wall. I'm talking about instances when one is not even on the thing, but has plenty of visible space between himself and a wall (around about the width of a DB 180—that .07 delay), and just want to get onto it. Pop! Happened in other situtations as well, but the same basic thing that the game presumably read as an adjust.

Yet 180'ing back onto a wall was easy, which is undesirable in Shrunkland.

So, spent 3-4 days tweaking the settings, but when steps were taken to try to remedy one problem, the other got worse, and vice versa. Ended up doing some wholesale changes (many swiped from Tiger's goshdarn clone :) ) that largely seem to have fixed the problems, and things feel pretty nice now. It was just very unexpected what a significant effect simply upping cycle_delay would have. That's why I asked.

(Don't mean to hijack the topic, by the way.)
User avatar
Phytotron
Formerly Oscilloscope
Posts: 5041
Joined: Thu Jun 09, 2005 10:06 pm
Location: A site or situation, especially considered in regard to its surroundings.
Contact:

Post by Phytotron »

z-man wrote:It's expected behavior and even warned about in the tooltip help :)
Actually, that's only warned about in the Infinity tooltip, not Ztrick.

Anyway, I'm back, and beginning to feel like a bit of a nag. I'm experiencing a weird graphical thing when close grinds are made. This has never happened in any previous version. It happens no matter the display or detail settings. Here are a few screenshots. The overlapping effect "moves" as the camera goes by.
You do not have the required permissions to view the files attached to this post.
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

Looks like insufficient depth buffer precision. On my GPU it looks uglier, probably because it has low internal precision. It seems to use 1+7+16-bit floating point about everywhere, which can be bad for geometry. But it's also much faster, with many more capabilities.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

Oscilloscope wrote:I'm experiencing a weird graphical thing when close grinds are made. This has never happened in any previous version. It happens no matter the display or detail settings. Here are a few screenshots. The overlapping effect "moves" as the camera goes by.
This was a bug in stand-alone HexaTRON (before shaped arenas). I forget how we fixed it, but it was fixed last I checked...
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

About adjusts vs. 180s: the problem here is that the move kills you, and has to kill you, before you make your second turn. Consequently, it can't make a difference between 180s and adjusts.

The rendering artifacts are known as z-fighting; Jonathan is right, your z-buffer depth is not enough. In the screen mode setup, you should set the z-depth to 32 bit and probably, as some cards have problems with inconsistencies here, switch the color depth to 32 bit, too. The problems with some cards are the reason 32 bit z-buffers aren't the default.

You're right about the tooltips, I'll adapt the texts to be more menacing.
User avatar
Phytotron
Formerly Oscilloscope
Posts: 5041
Joined: Thu Jun 09, 2005 10:06 pm
Location: A site or situation, especially considered in regard to its surroundings.
Contact:

Post by Phytotron »

z-man wrote:The rendering artifacts are known as z-fighting; Jonathan is right, your z-buffer depth is not enough. In the screen mode setup, you should set the z-depth to 32 bit and probably, as some cards have problems with inconsistencies here, switch the color depth to 32 bit, too. The problems with some cards are the reason 32 bit z-buffers aren't the default.
Erm, but as I said, I haven't had this occur with any previous versions of the game, including any of the 2.8 betas or rc's. Just as now, I've always left those two settings at "default." Nevertheless, on your advice I switched them both to 32 bit, but the artifacts still happened, though more "smeary" looking this time. (In fact, it occurred no matter what combination of those two I used. And yes, I hit "apply changes," and even quit and restarted.) If you're interested:

ATI Rage 128 Pro
version: 1.1 ATI-1.2.26
Post Reply