0.2.8.0 final: Release process and bugs
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.
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...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.
...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
- 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:
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.
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.
- 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:
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."
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."
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.
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.
- 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:
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?
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.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?
Rubber code, IIRC, was not touched.
- 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:
That's all I was wondering in the first place. : /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.
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.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.
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.)
- 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:
Actually, that's only warned about in the Infinity tooltip, not Ztrick.z-man wrote:It's expected behavior and even warned about in the tooltip help
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.
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
This was a bug in stand-alone HexaTRON (before shaped arenas). I forget how we fixed it, but it was fixed last I checked...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.
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.
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.
- 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:
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: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.
ATI Rage 128 Pro
version: 1.1 ATI-1.2.26