Yellow names: It's the console rendering the yellow down arrows. I added color reset codes.
Speed gauge: Well, the bug is there since the HUD was introduced, so it's probably not that important. Tank, want to fix it? I'll give you a low-priority bug entry on SF. I can supply a MaxSpeed function in gCycle that gives you the theoretical maximal speed a cycle can go with on its own (not counting accelerator zones and whatnot).
Edit: Joda, you were pointing out invisible walls. What kind of? Is there a clientside recording?
CVS test server
-
Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
Ok, I added gCycleMovement::MaximalSpeed() that should give you the top theoretical speed of your cycle. This is theoretical, of course, on some servers (like wrtl's race), you cannot reach this speed because obstacles kill you before. So a reality check, like taking the maximal actually observed cycle speed as it is done now, may still be a good idea. And maybe it's a good idea not to call the function every frame, it is surprisingly long.
@z-man: I have no client side recording 
...
I wanted to drive between two walls but died.
This is the situation as far as I remember it:
Legend:
|,-,+ = Walls
> = Cycle
* = Invisible Wall
The only thing that might have happend is that the server did not get my last turn (due to a random packet loss). Sorry, I just wanted to mark the spot, might not be worth to waste time on. (Recording would have been 100MB+ at that time...). Isn't there some way to always keep a recording of the last two rounds in memory and just dump that on demand ? The problem I see is that not all variables are initialized correctly even if the initial server settings are also dumped (including current players in that round).
...I wanted to drive between two walls but died.
This is the situation as far as I remember it:
Code: Select all
| |
| |
|***+------>
| ^
| |
| +--joda.bot--
|,-,+ = Walls
> = Cycle
* = Invisible Wall
The only thing that might have happend is that the server did not get my last turn (due to a random packet loss). Sorry, I just wanted to mark the spot, might not be worth to waste time on. (Recording would have been 100MB+ at that time...). Isn't there some way to always keep a recording of the last two rounds in memory and just dump that on demand ? The problem I see is that not all variables are initialized correctly even if the initial server settings are also dumped (including current players in that round).
The network init bug just struck in the first round I was playing.
- Attachments
-
- network init bug.aarec.bz2
- (78.32 KiB) Downloaded 87 times
meriton: The one with the wrong arena size? I think I fixed it on the seminar, but it requires cooperation between server and client, so it will only work if you update your client to current CVS or RC1 when that's ready.
joda: you cried inisivall twice in one session, I just noticed. Was the incident you described the first (where a couple of other people seemed to be amazed, too) or the second?
joda: you cried inisivall twice in one session, I just noticed. Was the incident you described the first (where a couple of other people seemed to be amazed, too) or the second?
Thanks, Joda! It was real. It wasn't an invisible wall, though, but a teleport. The movement code decided it would be a good idea to take a detour through meritons wall. It's fixed now (played back, changed to the fixed code on the round it happened, and you survived), but the necessary change may have bad side effects, such as other teleports and random deaths. It's active now on Fortress, so keep an eye on it. It's also in CVS, so if you update your client, watch out for local temporary teleport bugs.
On Sumo:Was it something I should pay attention to?
On Sumo:
Code: Select all
[4] [fe] belenus: BUG
[4] [fe] belenus: BUG: i drive through other players wall... or he through mine
[5] dookatee |DpG|: its called lag
[3] joda.bot: it just seems like@z-man: as far as I remember belenus played around with his p2p downloads ... so he might just have had some packet loss / lag there.
I'll try to ask him
and send him here...
@z-man: has anyone ever tried to review that code block ? might be a good idea to get multiple persons to check it ? I'm not sure how complicated those parts are, but perhaps it's a clean spot of code ?
I'll try to ask him
and send him here...@z-man: has anyone ever tried to review that code block ? might be a good idea to get multiple persons to check it ? I'm not sure how complicated those parts are, but perhaps it's a clean spot of code ?
The problems, at least everything I fixed with it in the 0.2.8 branch, all were related to slightly irregular data. On perfect data, the code works fine. However, sometimes the wall handling data structures produce, for examples, triangles with the wrong orientation: topologically, A should be left of BC, but geometrically, it's on the right. Result: the game object movement code takes a slightly wrong turn and faces a situation it should never have been in. This can't be avoided (floating point stuff, all that grinding and whatnot generates quite degenerate triangles), so the movement algorithm has to cope with it and still find a reasonable path to the target position.joda.bot wrote:@z-man: has anyone ever tried to review that code block ? might be a good idea to get multiple persons to check it ? I'm not sure how complicated those parts are, but perhaps it's a clean spot of code ?
If anyone wants to check anyway: the code is eGameObject::Move(). You can ignore the parts that deal with temporary walls, only the code that updates currentFace ever made problems. It uses the grid datastructures defined in eTess2.h extensively. Probably the only one here familiar with them is Philippe, and I'd rather have him finish the parser future proofing first.
Hi, I am encountering a curious new behaviour since I updated the source of my client to RC1. From the moment the "Blue Wins" messages appears until the new round has started, I get very jerky screen updates. FPS drops to about 5-10. Also, I only encounter this on the CVS test server.
Originally I thought me hacking rConsole was responsible, but the problem persists even if I revert my changes.
Originally I thought me hacking rConsole was responsible, but the problem persists even if I revert my changes.
- Attachments
-
- jerky round cleanup.aarec.bz2
- (108.79 KiB) Downloaded 97 times
Only the first round reset is on tape, and there, the two little jerks are caused by network syncs (where client and server pause until all messages are reliably sent) triggered by the server. When that happens, the server has already ended the round, so no danger here, nobody can die.
I'll disable it anyway, syncs triggered by the server won't cause jerks any more unless the client has lots of data still in the queue, which is unlikely.
I'll disable it anyway, syncs triggered by the server won't cause jerks any more unless the client has lots of data still in the queue, which is unlikely.