|
Author Topic:   Bug in Demo Servers when Full Game Client attempts to connect:
Random Chaos
Member
posted January 16, 2000 09:04 PM            
I have found a bug in Demo Servers when a Full Game Client tries to connect. It happened to my server and I grabed it in a log file:
-------------------------
Client ID 2 Connected.
>>Player BTvamp is connecting.

Entity Type Synching is Disabled, Not Synching Client.

Could not find Entity with Hash -487100559
Could not find Entity with Hash -487100559
--cut for 4 secs or so - I have that log data too - isn't relevent--
Client ID 2 Disconnected.
>>AI-Fool hosed (TC)Random Chaos with a Nuclear blast!
>>(TC)Random Chaos junked AI-Fool with a laser beam!
>>AI-Fool smashed Blacktooth with a 120mm shell!
>>AI-Fool junked (TC)Random Chaos with a Nuclear blast!
>>AI-Fool mangled AI-Tank-227 with a Nuclear blast!
>>AI-Fool mangled (TC)Random Chaos with a Nuclear blast!
>>AI-Fool destroyed Blacktooth with a Nuclear blast!
>>(TC)Random Chaos smashed themselves with flower power, dude!
>>Blacktooth destroyed AI-Tank-227 with a Nuclear blast!
>>[Blacktooth]: unknown of course
>>The World mangled AI-Tank-227 with Chaotic Evil!
>>The World smashed (TC)Random Chaos with Chaotic Evil!

After BTvamp left the server, there was a new AI tank number 227. This happened on the previous level to with 2 AI tanks. But the AI tank is invisible until a reconnect and the server seemed not to be controling it - rather it just sat where it spawned and did nothing. Additionally, there are NO AI tanks enabled on this server - my HELL! server.

I am a bit surprised that you used the same port number for the master server for Demo and Full game - this will create a LOT of confusion.

------------------
Random Chaos
Member of Clan Temporal Chaos
http://treadmarks.3d-unlimited.com
neym@rpi.edu

IP:

Random Chaos
Member
posted January 16, 2000 09:19 PM            
Oh, and just so you know - AI-FOOL was actually a human player.

In addition, on the client I was playing from, the "AI-TANK-227" showed up as "Unknown" when you killed it - though it was not on the scoreboard. After a reconnect to the server, the name was fixed to "AI-TANK-227"

Furthermore, on the clients, the tank was Invisible, except for the weapon it was carrying and any weapon shots directed at it passed right through it, until you reconnected.

[This message has been edited by Random Chaos (edited January 16, 2000).]

IP:

Sehnsucht
Member
posted January 17, 2000 04:02 AM            
if you set your tank etc as those available in the demo, it'll work fine.

However, that is a nasty bug.

IP:

Cell
Member
posted January 17, 2000 09:01 AM         

[This message has been edited by Cell (edited March 02, 2002).]

IP:

Random Chaos
Member
posted January 17, 2000 10:02 AM            
Well, that was on my hell server - he had the RGrenade that spawns nukes at that stage...all I was doing was building land bridges with the GAU and MGun.

IP:

LDA Seumas
unregistered
posted January 17, 2000 04:33 PM           
Damn, I thought I had made things so that these situations would fail gracefully, but I guess not.

As long as Shareware clients don't connect to Full Version servers, and Full Version clients only select Shareware tanks when connecting to Shareware servers, there shouldn't be a problem. Although it also looks like things will blow up if a full client picks an add-on tank that the server doesn't have when first joining...

This will of course be fixed in a patch before too long. I'll start fleshing out the site's Trouble Shooting page with this sort of stuff, though.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

Cell
Member
posted January 17, 2000 06:02 PM         

[This message has been edited by Cell (edited March 02, 2002).]

IP:

Sehnsucht_at_Work
Member
posted January 17, 2000 06:30 PM            
I think what should happen is, when someone tries to connect with something the server doesn't have, it tells the client too bad, and assigns it a default tank/skin/etc.

If a client connects and doesn't have something someone else has (that the server has also - otherwise they'd be forced to default) then the server should tell it to alias that hash to the default tank (i.e., client says I don't have that, server says alias newtank to defaulttank, or whatever. would also work for nontanks, as long a sthe server can know from the hash what kind of object it is and feed a default one to the client)..

I've also had some problems with what I assume is packet loss, tanks stopping and becomign shoot-through while others keep moving, after some seconds they unstick..

Could you perhaps have a client-feedback that tells the server whether it received a packet ? So the server would know to send update info for stuff in that packet that didn't make it into the next packet.. ?

I've tried rates of 1 to 5K, and it still happens on occasion.. really annoying..
when this happens I sometimes get shot at by a ghost, sorta like a failed client connect ghost, except that it's the stuck tank shooting at me, that appears to be elsewhere (and immobile)..

IP:

LDA Seumas
unregistered
posted January 17, 2000 07:15 PM           
Sehnsucht,

Yes, that's exactly what should have happened, but I wasn't vigilant enough about making sure that's what would happen with non-existent entities and such.

As for jumping/ghost tanks, this is likely packet loss, or it could also just be that the internal distance-based packet dropping algorithm in Tread Marks is still a tad on the nasty side. Tanks jumping around happens most when they're far away, though it can happen when they're close if they suddenly move far away quickly and thus their update frequency drops while your client still thinks it's near by. Positional packets are sent without delivery guarantees, and since they are sent at a fairly continuous rate as it is, it would take too long to get any effect from a client to server message that packets haven't come in for a while for a specific entity.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

Random Chaos
Member
posted January 17, 2000 09:24 PM            
Speaking of packet loss - there needs to be a packet lost statisctice line and/or graph.

IP:

Sehnsucht
Member
posted January 18, 2000 12:18 PM            
Well, perhaps guaranteeing at least one update per second per entity that *has* moved? and use absolute position not relative for those updates?

Prolly this wouldn't be much of an issue if so many people weren't on the server - I'm guessing packet loss must be because the server is maxed out more than my end, cause 2K at least should not drop packets

Server admins should also be sure to set the max rate per client to no more than server bandwidth/maxclients ... that should take care of the problem, except for just freak incidents (like, if sprint's or AOL's backbones are @#*^@^'d up again.. hehe)

IP:

Random Chaos
Member
posted January 18, 2000 03:38 PM            
Yeah - the Sprint backbone that my connection goes through is VERY erratic! Almost as erratic as how often the school's ISP goes down...the name of that company is "AppliedTheory" but we tend to call it other similar names such as mis-AppliedTheory, etc. Apparently the only reason that our school uses them is AT has a member on the school's Board of Directors, AT was originally a school incubator company, and last, the School has stock in AT, possibly a majority share.

UG!

IP: