----
The Mac OS X 10.2.8 build is on SF.
----
I did some work on getting a universal binary compiled. It will take longer than I thought, only because I have to build all the frameworks myself.
0.2.8.0_rc2: Release process and bugs
Er, so I'm going through gHud because I'm refactoring it, and it seems FPS is calculated twice. Once in display_fps_subby() (this result is displayed) and then also in tank_display_hud(). Maybe we can get a 0.001 FPS boost.
----
The Mac OS X 10.2.8 build is on SF.
----
I did some work on getting a universal binary compiled. It will take longer than I thought, only because I have to build all the frameworks myself.
----
The Mac OS X 10.2.8 build is on SF.
----
I did some work on getting a universal binary compiled. It will take longer than I thought, only because I have to build all the frameworks myself.
Silly: Thanks, I'll have a look at them and see what I can find out.
Parallel lines put more stress on two parts: first, if you go close to them, they use up more fillrate than the equivalent length of wall spread out in a zigzag. Second, all the zigzagging people to anyway put the grid datastructures in a state where straight lines will get heavily fragmented and cut down to pretty small bits, creating more work for collision checks and rendering. It usually isn't that bad that it gets noticeable, I always have to maliciously construct situations with debug output enabled so I see the grid data. But I'm not playing on all servers, so I don't see all real world situations.
Nemo: I never found out how the two functions interacted, so I left them alone They do some lazy updating, too. Will you give a warning before you commit the refactoring? It certainly does not belong into 0.2.8.0, so if you want to commit it so it gets into 0.2.8.1, I'll need to branch b0_2_8_0 first.
Parallel lines put more stress on two parts: first, if you go close to them, they use up more fillrate than the equivalent length of wall spread out in a zigzag. Second, all the zigzagging people to anyway put the grid datastructures in a state where straight lines will get heavily fragmented and cut down to pretty small bits, creating more work for collision checks and rendering. It usually isn't that bad that it gets noticeable, I always have to maliciously construct situations with debug output enabled so I see the grid data. But I'm not playing on all servers, so I don't see all real world situations.
Nemo: I never found out how the two functions interacted, so I left them alone
They do some lazy updating, too. Will you give a warning before you commit the refactoring? It certainly does not belong into 0.2.8.0, so if you want to commit it so it gets into 0.2.8.1, I'll need to branch b0_2_8_0 first.BUG.
Some days ago, on Fortress, I saw a zombie of Speedracer. That is, the server said he was killed, but on my client, he was just stomping on, pausing before every wall until he finally made it to the enemy zone. His trail kept lingering on inside our zone, I was on defense and messed it up, of course. Now I know the reason. Non-Programmers should skip the following block.
About half an hour before, I had switched to spectator mode for a minute. That destroyed my player, sending a destroy message to the server and removing it from all lists. The server also sent back a destroy message. When it arrived at my client, it found the object it wanted to destroy not there, and waited in a queue for the object to appear. Of course that did not happen, because the object was already dead. It kept waiting. Later, Speedracer's cycle appeared, being unlucky enough to have the same ID as my player had before. The deletion message jumped at it and removed it from all lists. But since there were other references to it, the cycle stayed in the game, but could no longer receive syncs.
So, the effect of this bug is: whenever I go to spectator mode and come back, some random object spawned half an hour later will not get sync messages or never be spawned correctly. The connection may be terminated because of that, but not often. It's a new client bug introduced with the bugfix for the sporadic client disconnects.
I suppose this is critical enough to be fixed for 0.2.8.0.
Some days ago, on Fortress, I saw a zombie of Speedracer. That is, the server said he was killed, but on my client, he was just stomping on, pausing before every wall until he finally made it to the enemy zone. His trail kept lingering on inside our zone, I was on defense and messed it up, of course. Now I know the reason. Non-Programmers should skip the following block.
About half an hour before, I had switched to spectator mode for a minute. That destroyed my player, sending a destroy message to the server and removing it from all lists. The server also sent back a destroy message. When it arrived at my client, it found the object it wanted to destroy not there, and waited in a queue for the object to appear. Of course that did not happen, because the object was already dead. It kept waiting. Later, Speedracer's cycle appeared, being unlucky enough to have the same ID as my player had before. The deletion message jumped at it and removed it from all lists. But since there were other references to it, the cycle stayed in the game, but could no longer receive syncs.
So, the effect of this bug is: whenever I go to spectator mode and come back, some random object spawned half an hour later will not get sync messages or never be spawned correctly. The connection may be terminated because of that, but not often. It's a new client bug introduced with the bugfix for the sporadic client disconnects.
I suppose this is critical enough to be fixed for 0.2.8.0.
Thanks lucifer, than the new camera mode of beta4.2 is better than the old...
...any chance to make an option like smart / smart_old in the configuration to select which one someone likes more?
Or any other method so one can select between old and new smart camera? code patch? configure option, anything? =)
...any chance to make an option like smart / smart_old in the configuration to select which one someone likes more?
Or any other method so one can select between old and new smart camera? code patch? configure option, anything? =)
- bel
-
Lucifer
- Project Developer
- Posts: 8641
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Um, there's no more output to the log when the round is over. There's still the "Overall Winner:" output, but nothing for the round. No big deal, probably falls outside the bug freeze, and maybe I can hack it in there at the appropriate point for my server.
(In other news, Swamplords on Crack now rotates the maps properly, instead of being one round off)
(In other news, Swamplords on Crack now rotates the maps properly, instead of being one round off)
Be the devil's own, Lucifer's my name.
- Iron Maiden
Bugfixes that clearly only affect one spot and changing it can't have any side effects are all right, too. What was the message text that should be printed so I can search for it?
I noticed when playing back a server recording that the output would depend on the playback/record state. Or maybe the debug state. Something, I think it was the round end message, was printed in fortress operation (non-debug, recording) and not in playback (debug). I'll dig.
I noticed when playing back a server recording that the output would depend on the playback/record state. Or maybe the debug state. Something, I think it was the round end message, was printed in fortress operation (non-debug, recording) and not in playback (debug). I'll dig.
-
Lucifer
- Project Developer
- Posts: 8641
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
I thought it used to print "Round Winner:" and the name. I don't remember exactly, it possibly never printed a round winner. I have a pretty strong memory of the console having once contained all the center messages. So if the center message is "Winner: Lucifer", that would be in the console, and therefore the log. Those seem to have disappeared entirely. Um, I don't know what version my server's running right now, it might be rc1.
I have a pretty strong memory of the console having once contained all the center messages. So if the center message is "Winner: Lucifer", that would be in the console, and therefore the log. Those seem to have disappeared entirely. Um, I don't know what version my server's running right now, it might be rc1.Be the devil's own, Lucifer's my name.
- Iron Maiden
Two bugs :
1) One concerns flicking rendering of the grid... guess this might be a numerical / camera bug.
Timestamps: 5-10 sec
2) Server list does not always show all server's ... I get this sometimes... I just got lucky as a certain server was missing on the first browse.
Timestamp: 5-10 sec
EDIT: wrtl's race server and some other color coded servers did not appear
3) 2n recording/bug might contain a AI team removal bug:
This is the bug I wanted to record. Sometimes the AI team does not disappear... AFAIK i hosted some Local/LAN games and then used an online server while the AI team still was present (sometimes I got two AI teams
).
That's also on the 2nd recording at the end ... I bet if I had joined a server without an AI team my AI team might have survived ... yeah go AI team go.
Timestamp: 150 sec - 300sec
1) One concerns flicking rendering of the grid... guess this might be a numerical / camera bug.
Timestamps: 5-10 sec
2) Server list does not always show all server's ... I get this sometimes... I just got lucky as a certain server was missing on the first browse.
Timestamp: 5-10 sec
EDIT: wrtl's race server and some other color coded servers did not appear
3) 2n recording/bug might contain a AI team removal bug:
This is the bug I wanted to record. Sometimes the AI team does not disappear... AFAIK i hosted some Local/LAN games and then used an online server while the AI team still was present (sometimes I got two AI teams
).That's also on the 2nd recording at the end ... I bet if I had joined a server without an AI team my AI team might have survived ... yeah go AI team go.
Timestamp: 150 sec - 300sec
You do not have the required permissions to view the files attached to this post.
Last edited by joda.bot on Fri Jan 27, 2006 1:36 pm, edited 1 time in total.
Using the
rim_wall_256x256_armagetronad.png
texture shows that the texture coords for the rim walls seem to be inverted ?
See image:
I'm not sure but floor_b.png might be rendered too bright-ly(?)
see screenshot... the floor_b.png uses the same color as floor_a.png (90% white) instead of pure white. floor_* are all at 1.
EDIT: the horizontal line has the correct color
rim_wall_256x256_armagetronad.png
texture shows that the texture coords for the rim walls seem to be inverted ?
See image:
I'm not sure but floor_b.png might be rendered too bright-ly(?)
see screenshot... the floor_b.png uses the same color as floor_a.png (90% white) instead of pure white. floor_* are all at 1.
EDIT: the horizontal line has the correct color
You do not have the required permissions to view the files attached to this post.
Silly, about the performance: It's a classic mixed feelings bug I'm embarrased that it happened, but proud I found it All player walls were rendered twice. Some late sync message adds them to the list of walls a second time. The bug is old, the same thing happened in 0.2.6 when holes were blown into walls, but it just got promoted because some timings changed.
I'll look at joda's recordings and Lucifer's cry. Joda: which server is missing?
The rendering "bug" is old, too; I think the two textures are just blended additively. We can't change that, good moviepacks take the effect into accound and make floor_b slighly less bright.
The texture coordinate thing is a lack of specification. We simply don't have an orientation of grid walls defined. I suggest we fix it in the maps, the code starts with t=0 and increases it from there.
I'm embarrased that it happened, but proud I found it All player walls were rendered twice. Some late sync message adds them to the list of walls a second time. The bug is old, the same thing happened in 0.2.6 when holes were blown into walls, but it just got promoted because some timings changed.I'll look at joda's recordings and Lucifer's cry. Joda: which server is missing?
The rendering "bug" is old, too; I think the two textures are just blended additively. We can't change that, good moviepacks take the effect into accound and make floor_b slighly less bright.
The texture coordinate thing is a lack of specification. We simply don't have an orientation of grid walls defined. I suggest we fix it in the maps, the code starts with t=0 and increases it from there.