Official forums for BZFlag.org

Just to let you all know, that intel mac build will only work on 10.5, as it was only built quickly on 10.5.

I have compiled bzflag version 2.99.5... on Ubuntu 8.04 and I am NOT getting "double jumps" when pressing the tab key more than once while in the air. Also the "i" key works for me to spawn.

The one thing I don't like is that the radar now treats a mesh as a 1 dimensional layer. I can't see any difference in height on a mesh map on the radar. This may work for boxes and pyramids, but a mesh needs to have some definition as well. I am using the Enhanced Radar. Normal, Fast, and FastSorted don't do any better with meshes. Have a look at this post for a better explanation. It is essentially the same problem:
http://my.bzflag.org/bb/viewtopic.php?p ... ht=#115208

I would like to see a radar that takes the mesh height differences into account and displays them accordingly.

yea i only have tiger 10.4.11 im too cheap to buy leopard
well i was looking forard to playing this but i guess i cant yet

Blazeing King wrote:yea i only have tiger 10.4.11 im too cheap to buy leopard
well i was looking forard to playing this but i guess i cant yet

You CAN play it, just need to build it yourself from the source.

Just a question.

The BZFlag 3.0 Wiki states:

Additional features are planed to be moved server side, including shot, hit, and death detection

does this mean that hit detection will/is moved to the server? what implications will this have regarding lag?

no they are not moved yet, that is still an ongoing research project that is happening in a branch based on the 3.0 code. I do not expect server side shots and collisions until 4.0

Still, would this mean that a tank explodes when a server sees a hit, meaning i could be exploding when I think i have dodged it?
Or will hit detection use lag unrolling for targeted tanks?

I am just thinking this may change the gameplay a lot.

no, you would have both the server and client do the tests and only have the server arbitrate disputes.

the first part of this is ensuring that the shot paths and tank paths can be matched on the client and server. current research is showing that shots can be done this way. Once we are sure that everything is in sync, the disputes between client and server should be minimal.

We had a paid student over the summer working on the problem and he found out a lot of good info on the subject.

we will not simply make it so that you have to "wait" to die. All these issues are the primary reason that it is NOT in 3.0, because we will not do it unless it is done right.

For all you lazy Mac users ():

Source:
http://home.comcast.net/~devin_d/bzflag ... ce.tar.bz2

MAC 10.5 Binary:
http://home.comcast.net/~devin_d/bzflag ... c-10.5.dmg

MAC 10.4 Binary:
http://home.comcast.net/~devin_d/bzflag ... c-10.4.dmg

All binaries are PPC. The 10.5 binary was configured with --enable-debug. The 10.4 binary was configured with --enable-optimized. I don't know if the 10.4 binary will actually work on 10.4. I configured with: The 10.4 build works on my 10.5 OS, but I'll leave both there, since one is a debug build.

I think there is a problem with the new radar mesh rendering algorithm. The idea that treating a mesh as a single object and using the mesh Z position and height to scale the alpha channel does not work for a mesh that is the terrain of the entire map; there is no definition of the landscape. If a mesh object is something like a tank or boulder or a small building, the current method works well. I think that a mesh terrain needs to be alpha scaled for each individual face height. Perhaps a new BZW option could be used to distinguish between a mesh that is used as the terrain and a mesh that is a smaller monolithic object. This option would be placed in the mesh definition if needed. The current radar rendering code would still have the same rendering speed for monolithic mesh objects. This option would be used to mark the terrain mesh for a face by face alpha scaling. Each face Z position and height needs to be taken into account for the alpha scaling referenced to the tank Z. That way the mesh landscape will have some definition.

Also the use of static display lists defeats the alpha scaling changing with the tanks altitude. It's decided when the player joins before spawning and the tank is at zero altitude. That alpha scaling is fixed at the altitude of zero units.

The MacIntel version wouldn't open.