New plugin idea: Destructable Bullets
New plugin idea: Destructable Bullets
Wouldn't it be cool if you could destroy bullets coming at you by shooting them? Either that, or when two bullets collide have them rico away in opposite directions...
Could add a new bit of strategy, especially on maps where you don't have much room to dodge, like "no jumping" maps.
Could add a new bit of strategy, especially on maps where you don't have much room to dodge, like "no jumping" maps.
- *Boinkage*!
- Private First Class
- Posts: 195
- Joined: Wed May 02, 2007 1:49 am
- Location: Behind you with a stealth flag.
That would be a great idea.
When I was a noob at boxy, I thoguht shooting a bullet blew it up XD.
Anyways, it might be doable if you set the shots as a tank.
On the same topic, what about when tanks hit eachother, they explode?
When I was a noob at boxy, I thoguht shooting a bullet blew it up XD.
Anyways, it might be doable if you set the shots as a tank.
On the same topic, what about when tanks hit eachother, they explode?
The Pen is Mightier Than the Sword.
Okay, you get a Bic, the orc gets a long sword.
He cuts the Bic in half.
Then he cuts you in half.
Oops, I meant quarters.
Okay, you get a Bic, the orc gets a long sword.
He cuts the Bic in half.
Then he cuts you in half.
Oops, I meant quarters.
Currently, that is not even remotely possible with a plug-in.
And, if implemented, this would be an extremely easy thing to cheat. Not to mention the lag issues...
AFAIK there is no code in the game that governs shots' collisions with one another- only with tanks and obstacles.
And, if implemented, this would be an extremely easy thing to cheat. Not to mention the lag issues...
AFAIK there is no code in the game that governs shots' collisions with one another- only with tanks and obstacles.
Optimism is just a milder alternative to denial.
- A Meteorite
- Private First Class
- Posts: 1786
- Joined: Thu Apr 28, 2005 12:56 am
- Location: California, U.S.
- Contact:
2.1's plan is to be able to modify a shot's state: direction, velocity, etc (I heard it being discussed in #bzflag, and it may already be implemented with Jeff's recent overhauls?).L4m3r wrote:Currently, that is not even remotely possible with a plug-in.
So, yeah, it could be done in theory... map a list of all known shots, see when any shots collide, and adjust accordingly.
Owner @ BZFX
Core Admin @ CAN
Email me: bzmet…@gmail.com
Hence the word "currently". 2.2 is still a long way off.A Meteorite wrote:2.1's plan is to be able to modify a shot's state: direction, velocity, etc (I heard it being discussed in #bzflag, and it may already be implemented with Jeff's recent overhauls?).
So, yeah, it could be done in theory... map a list of all known shots, see when any shots collide, and adjust accordingly.
Optimism is just a milder alternative to denial.
- A Meteorite
- Private First Class
- Posts: 1786
- Joined: Thu Apr 28, 2005 12:56 am
- Location: California, U.S.
- Contact:
True, but things like this will be possible... someday...L4m3r wrote:Hence the word "currently". 2.2 is still a long way off.A Meteorite wrote:2.1's plan is to be able to modify a shot's state: direction, velocity, etc (I heard it being discussed in #bzflag, and it may already be implemented with Jeff's recent overhauls?).
So, yeah, it could be done in theory... map a list of all known shots, see when any shots collide, and adjust accordingly.
I surely don't want to be that person who has to develop the algorithm to calculate the rico, though!
Owner @ BZFX
Core Admin @ CAN
Email me: bzmet…@gmail.com
- *Boinkage*!
- Private First Class
- Posts: 195
- Joined: Wed May 02, 2007 1:49 am
- Location: Behind you with a stealth flag.
Why not treat the shots as a tank in itself....could be done possibly.....if tanks were set to stop eachother....then you could make the bullets explode at speed 0.....possibly.
The Pen is Mightier Than the Sword.
Okay, you get a Bic, the orc gets a long sword.
He cuts the Bic in half.
Then he cuts you in half.
Oops, I meant quarters.
Okay, you get a Bic, the orc gets a long sword.
He cuts the Bic in half.
Then he cuts you in half.
Oops, I meant quarters.
How would that help?*Boinkage*! wrote:Why not treat the shots as a tank in itself....could be done possibly.if tanks were set to stop eachother....then you could make the bullets explode at speed 0.possibly.
Tanks have a lot of extra data that shots don't need, and the protocol handling is completely different. it'd be a waste of bandwidth.
the server could theoretically calculate shot collisions and send endshot messages when they happen, but the server state is not even close to being complete enough for that. Letting the client do it is a recipe for a cheating disaster. Even then, the size of shots would make it damn near impossible to deliberately hit them with normal player lag.
Optimism is just a milder alternative to denial.
- BinarySpike
- Corporal
- Posts: 735
- Joined: Mon Mar 28, 2005 11:58 pm
- Contact:
No, bzflag is a dead reckoning networking, *not* input.A Meteorite wrote:2.1's plan is to be able to modify a shot's state: direction, velocity, etc (I heard it being discussed in #bzflag, and it may already be implemented with Jeff's recent overhauls?).L4m3r wrote:Currently, that is not even remotely possible with a plug-in.
So, yeah, it could be done in theory... map a list of all known shots, see when any shots collide, and adjust accordingly.
Quake is input, when you hit forward it asks the server if you can move forward. This is why with extreme lag you can't move on quake maps.
Only if the theory says everybody has *0* lag. Then it would be possible. I can see the pro's and con's of switching from dead reckoning to input. But I like dead reckoning much more than input (even though it is laggier)
Stij, it's a good idea. Just isn't currently possible without bad cheating.
- A Meteorite
- Private First Class
- Posts: 1786
- Joined: Thu Apr 28, 2005 12:56 am
- Location: California, U.S.
- Contact:
Uh, possibly laggy, but not quite... the path for a bullet is already predefined and calculated, as far as I know.BinarySpike wrote:No, bzflag is a dead reckoning networking, *not* input.A Meteorite wrote:2.1's plan is to be able to modify a shot's state: direction, velocity, etc (I heard it being discussed in #bzflag, and it may already be implemented with Jeff's recent overhauls?).L4m3r wrote:Currently, that is not even remotely possible with a plug-in.
So, yeah, it could be done in theory... map a list of all known shots, see when any shots collide, and adjust accordingly.
Quake is input, when you hit forward it asks the server if you can move forward. This is why with extreme lag you can't move on quake maps.
Only if the theory says everybody has *0* lag. Then it would be possible. I can see the pro's and con's of switching from dead reckoning to input. But I like dead reckoning much more than input (even though it is laggier)
Stij, it's a good idea. Just isn't currently possible without bad cheating.
Modding a shot's trajectory during it's course would just mod the trajectory. I would assume the client would continue to draw the bullet on the predefined path until it got a shot update.
Even if that's not so, going through the shots currently in play would not be resource consuming the least bit, and anyone good with math could make an fairly efficient algorithm.
Someone correct me if I'm wrong, though.
Owner @ BZFX
Core Admin @ CAN
Email me: bzmet…@gmail.com
- too much loving
- Private First Class
- Posts: 94
- Joined: Sun May 23, 2004 7:47 pm
- Location: Denmark
- Contact:
You can find algorithms for hard sphere dynamics in Allen and Tildesley, "computer simulation of simple liquids", page 101. The basic idea is to update the trajectories one collision at a time. Each shot knows which object it will hit next and when the collision will take place The corresponding times are added to a sorted list of upcoming events. After each collision (or each tank kill) you have to make a local update of the effected particles (including the ones that would have been hit in chain events).A Meteorite wrote: I surely don't want to be that person who has to develop the algorithm to calculate the rico, though!
If you play on a very bad network, then you may have to save a kind of history so that you can update the sequence of collisions if a laggy client suddenly reports back that it was been hit 100 ms ago. The updated history can lead to another tank suddenly surviving a chain reaction... etc.. (I guess that the clients already have to deal with some of this)
Collisions are fairly seldom, so my guess is that all this does not requires a lot of CPU-time, but it may require a lot of coding-time...
Last edited by too much loving on Tue May 15, 2007 9:29 am, edited 1 time in total.
Yeah, that's basically it. Something like this would have to be authoritative, and the server doesn't have its own game state to do the calculations, really.too much loving wrote:Collisions are fairly seldom, so my guess is that all this does not requires a lot of CPU-time, but it may require a lot of coding-time...
The algorithm would be similar to that of tank/shot collisions... the only difference is that it would have to be done by the server (unlike tank/shot which is done by the client) and it'd have to keep track of ricos and whatnot.
A more complete server-side game state and an authoritative server are long-term goals of the project, but it's still a big, nasty coding job.
Optimism is just a milder alternative to denial.