Since I've been posting a few items on our unofficial BZFlag ezBoard, I thought I should move some of them here. Here's my wishlist for changes to future BZFlag builds. If you need clarification on any of these, or need additional information, please e-mail me. I don't visit this message board much because sourceforge.net simply makes them look ugly. dervishdukot@hotmail.com
1.) User setting (from options page) for adjusting alpha layer blend of the new radar and message objects in 1.7e6 and beyond.
2.) Do away with Pause. We don't need it. Pausing is automatically done when your tank is destroyed. And for those ppl who play at work, there's always mute or F12.
3.) When tanks "pop" into the battlefield, is it possible to randomly generate them AWAY from existing tanks? On packed servers, it's quite annoying to constantly have tanks pop in all around you, and it's annoying when you typically pop in right in the line of someone else's fire.
4.) Blue shots are too difficult to see in ALL 1.7e versions of BZFlag, when they pass through, under, or over boxes on the radar. For example, someone recently made a map with a whole bunch of buildings layed out in a grid design, like a city. There are narrow open areas between the buildings, and when a blue tank fires super bullet, it becomes very difficult to see on radar. Is it possible to change the color of buildings on radar in future versions? This might help, but we need to make sure all colored shots on radar show well.
5.) Please fix a bug where a phantom zoned tank can shoot one shot after a series of jumps. Was this fixed in 1.7e6?
6.) 1.7e6 has some strange problems on win32 (and possibly other platforms) that will allow a lagged player to jump higher than normal. Did the fix for lagged players falling through boxes cause this?
7.) Allow a method to "kill" your server listing on the BZFlag server list. Sometimes, the listings get corrupted and stick around, provided your server is running. When you go and change your server description, it never gets updated until you let it time out and the BZFlag list removes you.
8.) Improve BZFS documentation. It is currently both not accurate and cryptic. Explanations and examples would help greatly. If you need someone to write this for you, feel free to ask me. I know most of the arguments passed in detail, but I might need a better explanation on a few.
9.) Please fix the problems associated with running client and server on the same system.
10.) Allow servers arguments to adjust for reload times of each flag, number of shots for each flag, etc.. The more we allow a server to control, the more dynamic and unique we can make each game.
11.) GUI menu for BZFS, that saves to a file like BZFlag does to bzflag.bzc, or exports to a batch file.
12.) Make BZFS automatically detect and convert on the fly, between radian and degree. Document this conversion required in BZFS man pages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
3.) Ok, great!... can someone make this happen in a future release? May be as an option for a server argument?
4.) Yes, this I know through threads on our BZFlag ezBoard. What would be nice is to make this configurable inside the client instead of just in the settings file. That way, users can play with the settings until it's just right for their preference. Editing the file, starting BZFlag, testing, then exiting and editing again just isn't so hot (yes, I've noticed some strange problems if you try to edit the bzc file while BZFlag is running).
5.) A player once showed me this trick, and I was able to get it to work on my client (back with 1.7e4). It's been a while and I didn't write it down (because I don't like to cheat), so I don't remember the exact sequence of things you had to do. I do remember it did involve jumping straight up and down many consecutive times before it would work.
9.) Lag issues. For some reason, when you run the client and server on the same system, it causes a lot of serious lag. Not necessarily for you, but for others joining your server. This was discussed earlier either on this forum or on ezBoard. I think Mr. Apathy Cream or tankenstein might know about this?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AGREE that it is not good trying to get your radar colours right...
ie having to edit, start bzflag, exit, edit, restart, exit etc etc over and over again... also, its BIZARRE and confusing (IMHO) when your radar colour doesnt match the tank colour on screen. An option to colour each teams tanks on screen the same colour as on the radar settings might be very handy
it seems to me that it is always the most annoying players that choose blue, in the hope that it will help their camping and general sodding around. so i like to make blue near-white on my radar.. and then i get confused when i cant find the white tank im looking for on the screen !! so it would be good if the tank colour could follow the radar colour to avoid confusion (at least for me)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bzflag 1.8 will allow changing that stuff on-the-fly. on a personal note, i haven't really like the radar blue for a long time now; pure blue (which is what it used to be) can be hard to see but the desaturated blue looks too much like a building.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
also re lag issues running the client and the server:
1) this would probably depend on your OS - windows (even 2k or xp) probably wouldnt multitask your server and client well enuff.. maybe you could up your servers priority, but that still may not work as well as you would like. I havent noticed my server getting starved too badly when i run a client and server on linux tho.
2) The above problem would definitely be exacerbated by the way the client seems to love using 100% of your cpu if it can. i have heard bzflag runs well (with a decent graphics card) even on P90s but it still seems to chew up all my cpu on my p3 550 (which admittedly is rather slow by modern whizbang standards). It seems to me there is too much polling and generally idle waiting going on in the bzflag client and i think it would be nice to see some of this reduced. Tho maybe we will have to wait until linux real-time scheduling and microsecond sleeps etc are more accurate for this to be cleaned up 100%
(these are just suspicions of mine i dont really know)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
there appears to be real problems running the client and server on the same system but i've never been motivated enough to track it down. windows is generally bad at multitasking but my understanding is that this problem goes way beyond that.
bzfs uses very little cpu and mostly sleeps on the sockets. bzflag will use as much cpu as it can get (c'mon, it's an action game!) with one limitation. it doesn't busy wait and any polling is done once per frame, which is entirely appropriate.
the limitation on bzflag's cpu consumption is syncing on the vertical retrace. most windows (and linux?) users have this turned off for no good reason. there's no reason to draw 73 frames per second or more if your monitor refresh is 72Hz unless you're trying to determine your card's maximum performance. turn on syncing and, if your card can always draw at least as fast as the retrace, bzflag will go idle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
depends on your graphics driver. on linux for nvidia, set the environment variable __GL_SYNC_TO_VBLANK to a non-zero value (and don't forget to export it if your shell so requires).
on windows: Display Control Panel | Settings | Advanced and then you're on your own. it'll be buried somewhere, probably under OpenGL or 3D settings.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
excellent that explains it and thanks chris ive got an nvidia so ill give that a go.
and like you said it is an action game, and im not sure whether my somewhat clunky p3 550 is fast enuff to run my rather clunky TNT2 flat out anyway, so maybe it wont make much of a difference to me after all, but its nice to know that bzflag doesnt busy wait so that those with faster computers can retain some control if they want to ! kewl.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, i tried it and it made no difference to me which is no surprise as with my p3 550 i only gets 30-40 fps out of my TNT2 and thats in low quality mode. So it runs flat out either way.
BUT i told my bro about this, and he has some new soyo beast motherboard, with 1800 odd MHz processor of some kind and with the syncing OFF he was getting about 110 fps with CPU flat out at 100%
with syncing ON he only got 60 fps which is fine as that was his monitors refresh rate, but his CPU usage only dropped to about 95% !!!!!
so that was a bit disappointing :(
and it seems that this preliminary and rather crude test does seem to indicate there is some CPU being wasted somewhere!!
on the other hand i started up a bzfs server and two bzflag clients (on different XServer displays/virtual terminals) and although there were some problems especially when i was using the menus (oddly) to specify callsign and server to connect to - once i was in the game... it was fine... i was able to switch between clients etc no probs.
and this is on a p3 550 !! so if there are issues running server and client on same box i think they are pretty minimal under linux, even tho it wouldnt surprise me if the situation was worse on windows
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sorry to harp on about this not-so-important topic but the problems i had when running two clients (sluggish response and long freezes when in the menus) reminded me of another litle problem -- when in paused mode, navigating through the menus eg to change callsign or display options or whatever is also VERY sluggish (in linux at least) (even when running only 1 bzflag client like normal)
its no big deal tho, and even when running two clients, when i was actually playing on the map the responsiveness was fine.. i was able to drive around perfectly and find where i had left my other client driving around in a circle and blow it up ... and everything seemed fine. the sluggishness problems only seem to happen with the menus.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dave, you mentioned that there was a good amount of good in BZFlag to make sure a tank doesn't "pop" in front of another tank when spawning in.
I don't see this working.
Many, many, many, many times (can't say that enough), I've spawned right in front of another tank, or another tank has spawned right in front of me. Once, BZFlag spawned three, yes three tanks RIGHT in front of my tank, in a ROW! It was three instant kills for me because I was already shooting a stream of bullets. I'm sure they weren't happy. This happens all the time.
So, if there is code in BZFlag to prevent this, it isn't working. Any way we can add this in our list of things to fix in the future? Thanks. =)
-Dervish
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i have to agree with you. i see similar problems all the time. i know that there is code to prevent bad spawns (i helped write it) but it clearly doesn't work right if at all.
another thing i've noticed is a suspicous clustering when tanks pop in. i think it indicates a bias towards certain areas when picking new positions. that would imply the picking is working. even so i don't like the clustering. perhaps we need a bigger minimum distance from another tank in the spawning algorithm.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In 1.8 I'd like to move the respawning calculation to the server. This will also allow clustering to be avoided by caching the latest additions and using that information in the subsequent spawns.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
also by giving the respawing responsability to the server, it will allow battlefields of a different shape than the 800 units square.
I experimented with a plugin API for world generation and tried a triangle world. BZFlag geometry already allows arbitrary polygonal-shaped walls. What needs to be done (as I probably already wrote before) is an
isInside() method that determines if the coordinates are within the battlefield.
One could code the general equation to determine if a point is within a polygon, but this method could be recoded for worlds that have the same shape over and over.
All I have to do is figure out now how to make it work once CYGWIN manage to create bzflag.exe and bzfs.exe (anybody)
Regards,
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i've already written code for 1.8 for arbitrary regions but i haven't checked it in yet. there's an abstract Shape class which has a method isInside(), classes to transform shapes, and classes to perform CSG on shapes. the final result is that you can define 3D volumes using the union, intersection, and difference of any combination of shapes.
the idea here was to have a powerful and uniform way to define "regions" and use those regions for the following:
* player spawn regions
optionally per-team
different regions for flag-captured-spawn and killed-spawn
* flag spawn regions
optionally per-flag-type
* team base regions
entering the region counts for flag capture
* obstacle regions
these define the inside of buildings
it's all working except a couple of problems with the obstacles.
i've only done boxes and pyramid shapes so far. adding a shape isn't difficult but it isn't trivial either.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I modified the respawn algorithm which had been in bzflag already two times: once for e4 release and once for e6 release. So, you have to take into account, that there are different versions of the algorithm out there which behave very differently. As I hope that in the near future most peopel will be using a client >=E6, I'll ignore the older clients for now.
With the current algorithm, there are two main problems: a) 2 tanks popping up at about the same time, b) clustering of tansk from the same team
a) is a problem because the clients cannot take into account the new popup position of the other tank because of latency. This can be solved by putting the respawn algorithm into the server. This is probably a good idea and should be done for 1.8, however, the server needs lots of information do to that: position/velocity and all tanks and shots. Tryign to find a good position with the current algorithm can take a considerable amoutn of time, so it would put some load into the server and would have to be performed asynchronously to the server's main tasks.
b) The algortihm tries to put your tank in a safe place. A place is considered safe, when no existing shot will hit you soon (not takign ricochet or teleporters into account AFAIK) and when you have a minimum distance to all enemy tanks (depending on the relative orientation of the tanks). So, you might pop up right before or next to a friendly tank. This can be a little confusing for your friend and can also lead to cluster of teammates popping up in the same position.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
aw cmon... are these "problems" or just happy coincidences??
the other day i was on quite a crowded server and managed to genocide the green team twice in quick succession... and then ... surprise... i turn around looking for more fodder ... and the whole green team of 5 tanks pops up in front of me again .... :)
hehehe 3 genocides in a row.. on the same team :) i still chuckle every now and then when i think of the glee and bloody minded determination with which i drove straight at them blasting away so intent on getting that 3rd genocide that i forgot to avoid the few shots they managed to get off in my direction... i did get them tho.. how could i miss with 5 of them right front of me? hehe
seriously tho, it would be good to do something about this problem tho. theres no doubt respawning decisions have gotta be moved to the server, after all, when youve just died, there are no real-time issues involved in your placement back on the map.. it doesnt matter if it takes a bit of negotiation between the server and the client before you respawn.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmm, that prolly 'splains it. If two players die at the same time, something that prolly happens often on a busy server, they both will execute the search code and presumably come up with similar answers for the safest popin place. Since neither one has actually popped in, each believes the spot to be safe (unoccupied). Now they both popin, and trouble insues.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've noticed that the pop in is typically designated to the outer edge of a map on free-for all games. For capture-the-flag games, the pop in area is usually in the center of the board.
This holds true for current tank locations as well, and there may be a correlation. On most free-for-all servers currently running, the players are often scattered all over the map, sometimes in small clumps here and there while they battle. On capture-the-flag servers, tanks are often battling in the middle of the map.
From my observations, is it possible that the algorithm results for pop in is actually the opposite of what it was intended to do?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since I've been posting a few items on our unofficial BZFlag ezBoard, I thought I should move some of them here. Here's my wishlist for changes to future BZFlag builds. If you need clarification on any of these, or need additional information, please e-mail me. I don't visit this message board much because sourceforge.net simply makes them look ugly. dervishdukot@hotmail.com
1.) User setting (from options page) for adjusting alpha layer blend of the new radar and message objects in 1.7e6 and beyond.
2.) Do away with Pause. We don't need it. Pausing is automatically done when your tank is destroyed. And for those ppl who play at work, there's always mute or F12.
3.) When tanks "pop" into the battlefield, is it possible to randomly generate them AWAY from existing tanks? On packed servers, it's quite annoying to constantly have tanks pop in all around you, and it's annoying when you typically pop in right in the line of someone else's fire.
4.) Blue shots are too difficult to see in ALL 1.7e versions of BZFlag, when they pass through, under, or over boxes on the radar. For example, someone recently made a map with a whole bunch of buildings layed out in a grid design, like a city. There are narrow open areas between the buildings, and when a blue tank fires super bullet, it becomes very difficult to see on radar. Is it possible to change the color of buildings on radar in future versions? This might help, but we need to make sure all colored shots on radar show well.
5.) Please fix a bug where a phantom zoned tank can shoot one shot after a series of jumps. Was this fixed in 1.7e6?
6.) 1.7e6 has some strange problems on win32 (and possibly other platforms) that will allow a lagged player to jump higher than normal. Did the fix for lagged players falling through boxes cause this?
7.) Allow a method to "kill" your server listing on the BZFlag server list. Sometimes, the listings get corrupted and stick around, provided your server is running. When you go and change your server description, it never gets updated until you let it time out and the BZFlag list removes you.
8.) Improve BZFS documentation. It is currently both not accurate and cryptic. Explanations and examples would help greatly. If you need someone to write this for you, feel free to ask me. I know most of the arguments passed in detail, but I might need a better explanation on a few.
9.) Please fix the problems associated with running client and server on the same system.
10.) Allow servers arguments to adjust for reload times of each flag, number of shots for each flag, etc.. The more we allow a server to control, the more dynamic and unique we can make each game.
11.) GUI menu for BZFS, that saves to a file like BZFlag does to bzflag.bzc, or exports to a batch file.
12.) Make BZFS automatically detect and convert on the fly, between radian and degree. Document this conversion required in BZFS man pages.
3) Actually there's a good deal of code in there that does just that :)
4) You can change radar colors in the bzflag.bzc file as in
blueRadar 0.75 0.75 0.9
5) If you can isolate when this happens, add it to the bugs list.
9) What problems?
Dave,
3.) Ok, great!... can someone make this happen in a future release? May be as an option for a server argument?
4.) Yes, this I know through threads on our BZFlag ezBoard. What would be nice is to make this configurable inside the client instead of just in the settings file. That way, users can play with the settings until it's just right for their preference. Editing the file, starting BZFlag, testing, then exiting and editing again just isn't so hot (yes, I've noticed some strange problems if you try to edit the bzc file while BZFlag is running).
5.) A player once showed me this trick, and I was able to get it to work on my client (back with 1.7e4). It's been a while and I didn't write it down (because I don't like to cheat), so I don't remember the exact sequence of things you had to do. I do remember it did involve jumping straight up and down many consecutive times before it would work.
9.) Lag issues. For some reason, when you run the client and server on the same system, it causes a lot of serious lag. Not necessarily for you, but for others joining your server. This was discussed earlier either on this forum or on ezBoard. I think Mr. Apathy Cream or tankenstein might know about this?
Thanks
3) No I mean, for awhile code is in the client to 'make sure' you don't pop-in right in front of someone, or vice versa.
9) Don't listen to that Mr. Apathy Cream, he's an idiot ;)
AGREE that it is not good trying to get your radar colours right...
ie having to edit, start bzflag, exit, edit, restart, exit etc etc over and over again... also, its BIZARRE and confusing (IMHO) when your radar colour doesnt match the tank colour on screen. An option to colour each teams tanks on screen the same colour as on the radar settings might be very handy
it seems to me that it is always the most annoying players that choose blue, in the hope that it will help their camping and general sodding around. so i like to make blue near-white on my radar.. and then i get confused when i cant find the white tank im looking for on the screen !! so it would be good if the tank colour could follow the radar colour to avoid confusion (at least for me)
bzflag 1.8 will allow changing that stuff on-the-fly. on a personal note, i haven't really like the radar blue for a long time now; pure blue (which is what it used to be) can be hard to see but the desaturated blue looks too much like a building.
ithink we should keep the pause button tho.
also re lag issues running the client and the server:
1) this would probably depend on your OS - windows (even 2k or xp) probably wouldnt multitask your server and client well enuff.. maybe you could up your servers priority, but that still may not work as well as you would like. I havent noticed my server getting starved too badly when i run a client and server on linux tho.
2) The above problem would definitely be exacerbated by the way the client seems to love using 100% of your cpu if it can. i have heard bzflag runs well (with a decent graphics card) even on P90s but it still seems to chew up all my cpu on my p3 550 (which admittedly is rather slow by modern whizbang standards). It seems to me there is too much polling and generally idle waiting going on in the bzflag client and i think it would be nice to see some of this reduced. Tho maybe we will have to wait until linux real-time scheduling and microsecond sleeps etc are more accurate for this to be cleaned up 100%
(these are just suspicions of mine i dont really know)
there appears to be real problems running the client and server on the same system but i've never been motivated enough to track it down. windows is generally bad at multitasking but my understanding is that this problem goes way beyond that.
bzfs uses very little cpu and mostly sleeps on the sockets. bzflag will use as much cpu as it can get (c'mon, it's an action game!) with one limitation. it doesn't busy wait and any polling is done once per frame, which is entirely appropriate.
the limitation on bzflag's cpu consumption is syncing on the vertical retrace. most windows (and linux?) users have this turned off for no good reason. there's no reason to draw 73 frames per second or more if your monitor refresh is 72Hz unless you're trying to determine your card's maximum performance. turn on syncing and, if your card can always draw at least as fast as the retrace, bzflag will go idle.
How does one turn video syncing on and off under Linux and Windows?
depends on your graphics driver. on linux for nvidia, set the environment variable __GL_SYNC_TO_VBLANK to a non-zero value (and don't forget to export it if your shell so requires).
on windows: Display Control Panel | Settings | Advanced and then you're on your own. it'll be buried somewhere, probably under OpenGL or 3D settings.
excellent that explains it and thanks chris ive got an nvidia so ill give that a go.
and like you said it is an action game, and im not sure whether my somewhat clunky p3 550 is fast enuff to run my rather clunky TNT2 flat out anyway, so maybe it wont make much of a difference to me after all, but its nice to know that bzflag doesnt busy wait so that those with faster computers can retain some control if they want to ! kewl.
well, i tried it and it made no difference to me which is no surprise as with my p3 550 i only gets 30-40 fps out of my TNT2 and thats in low quality mode. So it runs flat out either way.
BUT i told my bro about this, and he has some new soyo beast motherboard, with 1800 odd MHz processor of some kind and with the syncing OFF he was getting about 110 fps with CPU flat out at 100%
with syncing ON he only got 60 fps which is fine as that was his monitors refresh rate, but his CPU usage only dropped to about 95% !!!!!
so that was a bit disappointing :(
and it seems that this preliminary and rather crude test does seem to indicate there is some CPU being wasted somewhere!!
on the other hand i started up a bzfs server and two bzflag clients (on different XServer displays/virtual terminals) and although there were some problems especially when i was using the menus (oddly) to specify callsign and server to connect to - once i was in the game... it was fine... i was able to switch between clients etc no probs.
and this is on a p3 550 !! so if there are issues running server and client on same box i think they are pretty minimal under linux, even tho it wouldnt surprise me if the situation was worse on windows
tho my bro was running an old client 1.7e4 i think.. ive told him to upgrade a few times but he hasnt got around to it yet.
so that might be part of teh problem id 1.7e4 was a bit more wasteful of cpu than the later clients
sorry to harp on about this not-so-important topic but the problems i had when running two clients (sluggish response and long freezes when in the menus) reminded me of another litle problem -- when in paused mode, navigating through the menus eg to change callsign or display options or whatever is also VERY sluggish (in linux at least) (even when running only 1 bzflag client like normal)
its no big deal tho, and even when running two clients, when i was actually playing on the map the responsiveness was fine.. i was able to drive around perfectly and find where i had left my other client driving around in a circle and blow it up ... and everything seemed fine. the sluggishness problems only seem to happen with the menus.
Dave, you mentioned that there was a good amount of good in BZFlag to make sure a tank doesn't "pop" in front of another tank when spawning in.
I don't see this working.
Many, many, many, many times (can't say that enough), I've spawned right in front of another tank, or another tank has spawned right in front of me. Once, BZFlag spawned three, yes three tanks RIGHT in front of my tank, in a ROW! It was three instant kills for me because I was already shooting a stream of bullets. I'm sure they weren't happy. This happens all the time.
So, if there is code in BZFlag to prevent this, it isn't working. Any way we can add this in our list of things to fix in the future? Thanks. =)
-Dervish
i have to agree with you. i see similar problems all the time. i know that there is code to prevent bad spawns (i helped write it) but it clearly doesn't work right if at all.
another thing i've noticed is a suspicous clustering when tanks pop in. i think it indicates a bias towards certain areas when picking new positions. that would imply the picking is working. even so i don't like the clustering. perhaps we need a bigger minimum distance from another tank in the spawning algorithm.
In 1.8 I'd like to move the respawning calculation to the server. This will also allow clustering to be avoided by caching the latest additions and using that information in the subsequent spawns.
Hello,
also by giving the respawing responsability to the server, it will allow battlefields of a different shape than the 800 units square.
I experimented with a plugin API for world generation and tried a triangle world. BZFlag geometry already allows arbitrary polygonal-shaped walls. What needs to be done (as I probably already wrote before) is an
isInside() method that determines if the coordinates are within the battlefield.
One could code the general equation to determine if a point is within a polygon, but this method could be recoded for worlds that have the same shape over and over.
All I have to do is figure out now how to make it work once CYGWIN manage to create bzflag.exe and bzfs.exe (anybody)
Regards,
Daniel
i've already written code for 1.8 for arbitrary regions but i haven't checked it in yet. there's an abstract Shape class which has a method isInside(), classes to transform shapes, and classes to perform CSG on shapes. the final result is that you can define 3D volumes using the union, intersection, and difference of any combination of shapes.
the idea here was to have a powerful and uniform way to define "regions" and use those regions for the following:
* player spawn regions
optionally per-team
different regions for flag-captured-spawn and killed-spawn
* flag spawn regions
optionally per-flag-type
* team base regions
entering the region counts for flag capture
* obstacle regions
these define the inside of buildings
it's all working except a couple of problems with the obstacles.
i've only done boxes and pyramid shapes so far. adding a shape isn't difficult but it isn't trivial either.
I modified the respawn algorithm which had been in bzflag already two times: once for e4 release and once for e6 release. So, you have to take into account, that there are different versions of the algorithm out there which behave very differently. As I hope that in the near future most peopel will be using a client >=E6, I'll ignore the older clients for now.
With the current algorithm, there are two main problems: a) 2 tanks popping up at about the same time, b) clustering of tansk from the same team
a) is a problem because the clients cannot take into account the new popup position of the other tank because of latency. This can be solved by putting the respawn algorithm into the server. This is probably a good idea and should be done for 1.8, however, the server needs lots of information do to that: position/velocity and all tanks and shots. Tryign to find a good position with the current algorithm can take a considerable amoutn of time, so it would put some load into the server and would have to be performed asynchronously to the server's main tasks.
b) The algortihm tries to put your tank in a safe place. A place is considered safe, when no existing shot will hit you soon (not takign ricochet or teleporters into account AFAIK) and when you have a minimum distance to all enemy tanks (depending on the relative orientation of the tanks). So, you might pop up right before or next to a friendly tank. This can be a little confusing for your friend and can also lead to cluster of teammates popping up in the same position.
aw cmon... are these "problems" or just happy coincidences??
the other day i was on quite a crowded server and managed to genocide the green team twice in quick succession... and then ... surprise... i turn around looking for more fodder ... and the whole green team of 5 tanks pops up in front of me again .... :)
hehehe 3 genocides in a row.. on the same team :) i still chuckle every now and then when i think of the glee and bloody minded determination with which i drove straight at them blasting away so intent on getting that 3rd genocide that i forgot to avoid the few shots they managed to get off in my direction... i did get them tho.. how could i miss with 5 of them right front of me? hehe
seriously tho, it would be good to do something about this problem tho. theres no doubt respawning decisions have gotta be moved to the server, after all, when youve just died, there are no real-time issues involved in your placement back on the map.. it doesnt matter if it takes a bit of negotiation between the server and the client before you respawn.
Hmmm, that prolly 'splains it. If two players die at the same time, something that prolly happens often on a busy server, they both will execute the search code and presumably come up with similar answers for the safest popin place. Since neither one has actually popped in, each believes the spot to be safe (unoccupied). Now they both popin, and trouble insues.
I hope this helps a little...
I've noticed that the pop in is typically designated to the outer edge of a map on free-for all games. For capture-the-flag games, the pop in area is usually in the center of the board.
This holds true for current tank locations as well, and there may be a correlation. On most free-for-all servers currently running, the players are often scattered all over the map, sometimes in small clumps here and there while they battle. On capture-the-flag servers, tanks are often battling in the middle of the map.
From my observations, is it possible that the algorithm results for pop in is actually the opposite of what it was intended to do?
last line was supposed to be:
From my observation, is it possible that the algorithm results for pop in are actually opposite of what they were intended to be.
I wish sourceforge.net forums allowed you to edit and delete posts. Oh well.