Maucaub

I wouldn't say you'll never get disconnected, but you are correct that if you keep the changes small, you can get away with it for a while. Given enough time, though, it should eventually find out. By the same token, I'd say that it's not a reasonable nor responsible solution to simply rely on the map checksum to find out, since there's no telling how long it would take to find it based on its current operation. Due to the nature of the level checksum algorithm, there is a finite nonzero probability that changes to the map won't be detected. The fewer changes you make and the more local they are, the greater the probability the checksum won't detect it. If you make widespread changes to the map, you increase the probability of those changes being detected.

I have noticed this too. I've come to the conclusion that you can only start with brick if InitialBrick > 0 (lanc = 255). Since you are using his test zone, why not go all the way and use his code too? The relevant stuff can be found in clientset.c. The specifics of how prizes are granted is handled client-side, not in the server. As for your observations regarding bricks, this is a direct consequence of how the programmers decided to implement prizes. First thing to know is that your ship's initial bounty is treated like a multiprize. Specifically, what ever your InitialBounty setting is, the client grants you a Multiprize with that many prizes when your ship spawns. (The actual Multiprize is controlled via a different setting). Second thing to know is that the VIE client multiprize code doesn't allow certain prizes to be received when picking up a multprize. The prizes not allowed in the VIE multiprize are: engine shutdown, shields, super, another multiprize, warp, and bricks. Hence, no matter what your initial bounty or what your brick PrizeWeight is, you'll never be granted a brick when you spawn. You must either pick it up manually or be awarded it via *prize. The reasons most of those prizes are excluded from the multiprize is pretty obvious, such as not allowing cascading multiprizes. As for the bricks, my suspicion is that bricks were just too valuable/powerful a tool to be allowed to occur in multiprizes, so they excluded those as well.

I may as well chime in on this since it's been a little while since the last reply and it still appears as no one has clearly resolved this issue. Actually, this is not a bug, this is in fact part of the game. There are 2 different thresholds pertaining to the forwarding of weapon packets: one relative to your screen and one relative to radar. Case 1: Player on screen In this case, all weapon packets are forwarded. This is not the whole picture, since there's a small buffer around your screen controlled by the Routing:CloseEnoughBulletAdjust and Routing:CloseEnoughBombAdjust settings in the server.cfg. In actuality, when a player is either on the screen or within the range of these buffers, all weapon packets will be forwarded. Case 2: Player very far away, not on radar By argument of spatial proximity, player A sitting at A1 doesn't need to know much about what player B is doing over at T20, and vice versa. Hence, to minimize the required bandwidth, these weapon packets will not be forwarded. This is akin to the case already described earlier with the mines. Case 3: Player beyond screen buffer but still on radar In this middle ground, player A still may not need to know every little detail about what player B is doing, but at the very least it has to know where player B is in order to display them on radar. On top of that, player A should at least be aware that player B is nearby and possibly hurling weapon projectiles and/or flying in the direction of player A. In order to get some of this info and throttle wasted bandwidth at the same time, it is possible to configure the server to only forward a percentage of the packets from player B to player A. The percentage is controlled by Routing:RadarFavor, and can vary from 100% to as little as 12.5% or below of the weapon packets that are forwarded to the player. I guess this is the appropriate place to also note that the size of the radar, and hence the size of this middle region, is controlled by the Radar:MapZoomFactor. Hence, all told, there is in fact a mid-range distance at which weapon packets can be partially dropped, depending on the exact configuration of the server. Hope this clears things up. -Maucaub