BZ2 1.3.6.4z33 - Open beta & testing

[MrTwosheds]

...and think it's double damage. This is sporadic and impossible to replicate consistently.

Which is going to make it extremely difficult to reproduce and fix. I would recommend that some extensive testing be carried out. You will need to ensure a clean environment...Ie Clean installs of stock BZ2. No hackers, ddossers or laggers in the game. Probably be best to do it "in the Dark" (off raknet) so that Idiots don't know that you are doing it. Turn off the fight, build ships and shoot at each other, see if any other game functions combine to cause it, like building stuff at the same time or particular graphic settings. Does it happen with the AI? Try it with logging on and logging OFF. This sort of bug can be really really hard to pin down, trying to do it and "play" at the same time will be almost impossible.

And to be honest, if certain notorious players were in the games where this has been seen then I would be inclined to disregard it as evidence of a bug at all and just assume it is just yet another hacking attempt.
Reminds me of the old "Claws double sp and blast" incident...invisible shots...sudden extra damage...

[Zero Angel]

Having 'laggers' in the game is necessary to replicate real-world conditions, and in fact I wanted to try and find a way to simulate late packets so we could determine if it's related to the appearance of the bug.

Anyways, I've been discussing and trying to identify the current bugs in the public betas and here is part of a transcript from one of my conversations (it starts at the discussion of a bad behavior of a player in-game)

Code: Select all

[2:51:50 AM] Zero Angel: yeah. But silver was not wrong to demand a ban. That kind of behavior needs to be cracked down upon, in order to have good healthy and fun games
[2:52:07 AM] Zero Angel: and not even a permanent ban, just a temporary ban to make the player sit out a game to discourage bad behavior
[2:52:15 AM] Kebbz: yes, he is now banned
[2:52:41 AM] Zero Angel: I think /ban <playername> and /clearautobans can accomplish temp bans
[2:53:00 AM] Kebbz: i clicked the button in the interface
[2:53:02 AM] Kebbz: in lobby
[2:53:12 AM] Zero Angel: Yeah, I think that accomplishes the same thing
[2:53:34 AM] Kebbz: maybe not
[2:53:39 AM] Kebbz: because last time i banned luci
[2:53:47 AM] Kebbz: i could not even see his game when he hosted
[2:54:03 AM] Kebbz: needed to edit that txt file or what to get out his ip
[2:54:10 AM] Zero Angel: oh, I see
[2:54:23 AM] Zero Angel: so when you ban, it writes it into the txt file?
[2:54:31 AM] Kebbz: yes
[2:54:43 AM] Zero Angel: I wonder if clearautobans would remove the stuff from the txt file
[2:54:48 AM] Kebbz: no
[2:54:51 AM] Kebbz: i tried
[2:55:11 AM] Kebbz: and I remember i have banned him ingame, not in the lobby
[3:01:58 AM] Zero Angel: Have you experienced any bugs related to recieving 'extra damage' ?
[3:02:16 AM] Zero Angel: e.g. on a laser, shad, faf hit, etc
[3:02:33 AM] Kebbz: yes, but mostly giving 1 laser shot kill
[3:02:37 AM] Kebbz: of full HP
[3:03:01 AM] Zero Angel: do you think it has anything to do with a laggy host or clients?
[3:03:32 AM] Kebbz: I think the problem is in game network communication
[3:03:38 AM] Kebbz: it uses UDP right?
[3:03:42 AM] Zero Angel: yes
[3:03:57 AM] Kebbz: which is a stream of data without any errors checking
[3:04:14 AM] Kebbz: so if a packet gets lost
[3:04:26 AM] Kebbz: it wont check anything
[3:04:44 AM] Zero Angel: the packets should be time stamped
[3:05:08 AM] Zero Angel: however, for the past several public betas, the netcode has changed to make the host be 'extra authoritive'
[3:05:20 AM] Zero Angel: e.g. everyone sees on their screen what the host sees
[3:05:34 AM] Zero Angel: the good thing about it is that it prevents laggy clients from warping or causing the game to become out of sync
[3:06:02 AM] Zero Angel: but if this change caused the extra damage bug to appear, then it needs to be studied more
[3:06:28 AM] Kebbz: the worst thing now is the invisible shots

[MrTwosheds]

Having 'laggers' in the game is necessary to replicate real-world conditions

Of course, but to pin the bug down it would be very useful to see if it also happened in non laggy connections.

[Zero Angel]

Having 'laggers' in the game is necessary to replicate real-world conditions

Of course, but to pin the bug down it would be very useful to see if it also happened in non laggy connections.

I can agree with that. Ideally it would be tested first in on a clean start with non-laggy conditions (control group), and then secondly on a clean start under the effects of lag, both high ping and high packet loss (independently from each other). If the bug cannot be duplicated with a clean start, then do a more 'dirty' start and launch and play a previous game.

That would form a more complete picture of when the bug may occur.

[Deathbringer]

I'd like to chime in on this "double damage" "bug".
I was playing around with a game that I created on my AMD machine and ran the game on my ASUS T100 10" as well and was looking at both screens to see how synchronized the game was and I was seeing the issue by simply jumping out as a pilot and then shooting at each other with quick shots.
I'm not sure if both pilots were exhibiting the issue, but I did notice that the first shot didn't show although the guy shooting heard the scream. (any way to make that a different more exaggerated scream?
Anyway. It was a local Lan game and I'm pretty sure it happened every time with a short burst. Sorry to be a bit vague on this as it was like 2 weeks ago and I barely remember yesterday.
I would expect that I could easily re-create this and I'll give it a shot (literally) a bit later.

[MrTwosheds]

Actually its really useful There will probably be different symptoms depending on wether its the server or client doing the shooting.
My own 2nd pc does not work at the moment so I can't try this.

[Nielk1]

If you read the various comments and change-logs you will see that BZ2 has checks for missing packets. This is also helped along by the idea of "host/server is god". A game is like streaming video in a way, once data is old, it is *probably* useless. Though with games, there is a chance even old info is not stale and can correct a simulation process that has not yet gone out of sync, but is destined to given the specific missing info.

Recall specifically the notes GSH has made in changelogs about retransmission. Couldn't do that without some sort of ACK to the packet (well, I guess you could if you saw data from the other machine didn't match predictions, but that gets complex and weird).

[Deathbringer]

Ok, I did a little more testing tonight and first did some testing in the scouts. Shooting at myself there are times when the host was shooting the client and vice versa where there seemed to be no apparent shot showing from either side but both sides took the damage. However there seemed to be a half second to full second delay in me doing a single shot and it taking the 5 points or whatever it is for another scout shot.
So shot from host to client: Client doesn't always see the graphics or hear the sound but I took damage every time. It was sometimes delayed by almost a full second. Movement from one screen to the next when I am watching myself was instantaneous. No perceived delay. So it doesn't look like packet loss or hardware Lag or even an issue with playing the sound on the smaller tablet. The sounds of the scout moving in front of me and my movements seem to come across and in almost instantaneous sync.
I then jumped out and repeated my single shots from the pilots and saw the same behavior. Graphics immediately synced except for the shots. Sometimes it's 3 in a row that don't show and I'm not sure there is a pattern.
Then I put them about 100 yards apart and shot in each others general direction. The server dude fired near the client dude until it started doing single bursts due to low ammo and it looked like every one of those went through on the client. In other words I could see every shot. There did seem to be a shot or two delay when I stopped shooting...
The client shooting in the direction of the host didn't always show the shot. single shots before the ammo depleted did not always show.. The bolts did go by pretty much every time when the ammo went down, but I started getting delays and then two shots to catch up when they went by.

So from my observations, positioning seems fine. Shots seem to actually hit and take damage however when no graphic shows up or sound registers.
So someone coming up on you firing at you will not make a sound until a few bolts in and then you will hear the shots and notice the damage. Also happens if they stop shooting and start shooting again which also gives you a "WTH?" type of feeling as you never saw the shot and never heard the damage.
I'm on CAT6 cable for the host and wifi for the tablet. (that's all it has).. I could get a USB to Ethernet adapter at Fry's and give it a shot, I'm not sure this issue is anything new and am I just wasting my time here? I haven't been back on the forums in years and I'm not sure if this is something that has been fully fleshed out as "the way it is".
Either way... Easy to re-create and if you have two machines I'm thinking this will happen to you just as easily.
GSH..or Ken.. (can't remember your handle and might have screwed up Ken as it's been awhile) If you want me to try anything or supply logs and can do so, but I suspect you may be able to do this yourself.
Thanks and hopefully this helps even slightly.

[Zero Angel]

Thank you for doing that very well written and well documented test. This is an example of a good test report.

Could you run a test in strat mode where you build and shoot laser at the other ship and see if anything strange happens like 1-shot kills or damage which exceeds the 27%-28% damage that laser typically does to other scouts? Best way to do it would probably just be to fly the 'dummy' player to the base and just have him hop into empties or build pods under his ship.

Still trying to figure out if latency or packet loss is a factor, and some LAN tests with a clean connection would make a good 'control group' before laggy/realworld connections are tested out.

[MrTwosheds]

I get the impression from that, that it might have more to do with the server/client authority changes, something with weapons not happening quite as smoothly as it should.

[Commando]

Shots not being rendered is a known issue. If and when it will be looked into is unknown as gsh has other projects he is focused on.

[Deathbringer]

Hey Commando,
So is the lack of sound / screams also a known issue?
If it is, than I would say that this is all tied together then? The damage that is inflicted seems to be pretty consistent and when I was keeping things down to a single burst.
I was looking at multiple things before and wasn't disregarding the "known" issues.
Obviously there may be other things that manifest when other things are going on, but it almost just looks like something in the graphic / sound routine although it seems really odd that I would register damage and not the other.. Unless I was getting a damage recognition from the client which was then deemed correct by the host when the host never got the news that there was a shot coming in towards it in the first place.
It all depends on who does the damage / hit detection and how that is resolved. That process might be different than even getting a detection that a shot is being generated.
Obviously someone who knows better would know better ...
Well, hopefully I didn't muddy the waters with focusing on the known stuff. I'll certainly do a bit more as time permits. Stepson is grounded AGAIN so if I want to get my fix I'll shoot at myself.
I have to say that we had a few people join and someone from Germany while we are both here in AZ and all was extremely well. It really is amazing how much fun this game still is.
Happy Bzing

[Commando]

Effects, from blast and laser, is a known issue. Not sure about the audio issue.

[MrTwosheds]

That's what makes me think its an authority changes bug, Sounds are not being played as well as the shot not being seen. The local machine does not play them because it does not know that there was a shot until its too late to play it. Server asserts its authority and double damage is inflicted.

[Commando]

I believe this bug started before GSH even made the authority change. I remember reporting sniper rifles failing to render before the change was made.