New plugin idea: Destructable Bullets

Make suggestions for improving one of the best games on the net!
Post Reply
Stij
Private First Class
Private First Class
Posts: 56
Joined: Thu May 10, 2007 1:55 am

New plugin idea: Destructable Bullets

Post by Stij »

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.
User avatar
*Boinkage*!
Private First Class
Private First Class
Posts: 195
Joined: Wed May 02, 2007 1:49 am
Location: Behind you with a stealth flag.

Post by *Boinkage*! »

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?
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.
User avatar
L4m3r
Hater of Everything
Hater of Everything
Posts: 724
Joined: Tue Feb 08, 2005 5:15 am
Location: Los Angeles

Post by L4m3r »

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.
Optimism is just a milder alternative to denial.
User avatar
A Meteorite
Private First Class
Private First Class
Posts: 1786
Joined: Thu Apr 28, 2005 12:56 am
Location: California, U.S.
Contact:

Post by A Meteorite »

L4m3r wrote:Currently, that is not even remotely possible with a plug-in.
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.
Image
Owner @ BZFX
Core Admin @ CAN

Email me: bzmet…@gmail.com
User avatar
L4m3r
Hater of Everything
Hater of Everything
Posts: 724
Joined: Tue Feb 08, 2005 5:15 am
Location: Los Angeles

Post by L4m3r »

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.
Hence the word "currently". 2.2 is still a long way off.
Optimism is just a milder alternative to denial.
User avatar
A Meteorite
Private First Class
Private First Class
Posts: 1786
Joined: Thu Apr 28, 2005 12:56 am
Location: California, U.S.
Contact:

Post by A Meteorite »

L4m3r wrote:
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.
Hence the word "currently". 2.2 is still a long way off.
True, but things like this will be possible... someday... :)

I surely don't want to be that person who has to develop the algorithm to calculate the rico, though!
Image
Owner @ BZFX
Core Admin @ CAN

Email me: bzmet…@gmail.com
User avatar
*Boinkage*!
Private First Class
Private First Class
Posts: 195
Joined: Wed May 02, 2007 1:49 am
Location: Behind you with a stealth flag.

Post by *Boinkage*! »

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.
User avatar
L4m3r
Hater of Everything
Hater of Everything
Posts: 724
Joined: Tue Feb 08, 2005 5:15 am
Location: Los Angeles

Post by L4m3r »

*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.
How would that help?

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.
User avatar
BinarySpike
Corporal
Corporal
Posts: 735
Joined: Mon Mar 28, 2005 11:58 pm
Contact:

Post by BinarySpike »

A Meteorite wrote:
L4m3r wrote:Currently, that is not even remotely possible with a plug-in.
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.
No, bzflag is a dead reckoning networking, *not* input.

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.
Stij
Private First Class
Private First Class
Posts: 56
Joined: Thu May 10, 2007 1:55 am

Post by Stij »

Hmm, I'm not surprised, really. I know next to nothing about modding, anyway. :P
User avatar
A Meteorite
Private First Class
Private First Class
Posts: 1786
Joined: Thu Apr 28, 2005 12:56 am
Location: California, U.S.
Contact:

Post by A Meteorite »

BinarySpike wrote:
A Meteorite wrote:
L4m3r wrote:Currently, that is not even remotely possible with a plug-in.
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.
No, bzflag is a dead reckoning networking, *not* input.

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.
Uh, possibly laggy, but not quite... the path for a bullet is already predefined and calculated, as far as I know.

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.
Image
Owner @ BZFX
Core Admin @ CAN

Email me: bzmet…@gmail.com
User avatar
too much loving
Private First Class
Private First Class
Posts: 94
Joined: Sun May 23, 2004 7:47 pm
Location: Denmark
Contact:

Post by too much loving »

A Meteorite wrote: I surely don't want to be that person who has to develop the algorithm to calculate the rico, though!
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).

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.
User avatar
L4m3r
Hater of Everything
Hater of Everything
Posts: 724
Joined: Tue Feb 08, 2005 5:15 am
Location: Los Angeles

Post by L4m3r »

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...
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.

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.
Post Reply