Bounce Stuff?

Argh · Post by **Argh** » 09 Nov 2007, 03:56

Could somebody document how to test these:

- Added GroundBounce, WaterBounce, NumBounce, BounceSlip, BounceRebound, and bounceExplosionGenerator tags

KDR_11k · Post by **KDR_11k** » 09 Nov 2007, 08:51

Did you read the changelog entry that explains what they do? What more do you need?

Argh · Post by **Argh** » 11 Nov 2007, 17:00

Er, I had to hunt it all down in FishEye:

Code: Select all

Added 5 new weapon fbi tags.
        WaterBounce and GroundBounce: Boolean to allow a projectile to bounce off of a surface. defaults to false.
        BounceSlip: Amount of lateral speed kept by the projectile after it bounces. defaults to 1.
        BounceRebound: Amount of vertical speed keeps and reverses. defaults to 1.
        NumBounce: The number of bounces a weapon will make. -1 indicates no limit. defaults to -1.

Added the ability to bounce for Torpedos, Missiles, Lasers, Cannons, and Emgs.

Added flighttime functionality to cannons.

So, lots of stuff to test, and bouncy weapons... heh, now maybe, just maybe, I can do a NoExplode cannonball that acts in a non-retarded fashion...

MightySheep · Post by **MightySheep** » 11 Nov 2007, 17:02

ah so that explaines why when i shot a con vehicle with my gaurdian it bounced around around for a minute, rebounding off everything before it blew up.

Argh · Post by **Argh** » 11 Nov 2007, 18:42

Ok, just tested it, I have a few questions / quibbles:

1. There seems to be very little I can do to control the direction of the bounces, leading to some very retarded behaviors on some angles of a map's geometry. I think that we need a "BounceInertia" tag, that will override the direction returned by a bounce calculation, and swerve it back to the original line of fire. It should be a float, 0.0 (no override) to 1.0 (only changes y axis). IRL, if a heavy cannonball hits an angled surface, it may change angle somewhat, but its inertia will keep it heading more in line with the original vector than the behaviors now seen.

Moreover, there also needs to be some control over what angle will automatically cause the projectile to explode. It looks like it's about 45 degrees- but that should be controllable, imo.

2. It's clear that FlightTime, if non-zero, is now the true lifetime of a Cannon projectile. This needs to be documented- if you set Flighttime too low, then the projectile is removed from the simulation well before it reaches max range.

3. Setting up a projectile with NoExplode did not result in what I was hoping- i.e., finally, a non-hardcoded NoExplode, where it can go through multiple targets while bouncing, but does not have the "every frame I generate an explosion once I have 'landed'" behavior that is so annoying, simply because we can't mess with it at all. Can't this get fixed, by simply allowing NoExplode to work properly, and setting up a Disintegrator default that uses GroundBounce=1 + NoExplode, for backwards-compatibility?

4. On Cannon weapons, if Burnblow=1, then the projectile should die when it reaches max range... right now, Flighttime overrides Burnblow, which does not seem like correct behavior to me.

5. Apparently, somebody decided that Cannon weapons should have a range that accurately reflects the distance that they can travel, based on a 45-degree angle and the WeaponVelocity!

I understand, whoever did that, that you were trying to be cool, and get rid of the problems of "uh, it says it can go X distance, but the Unit always has to move to actually shoot". However, with the Bounce tags working, a weapon's real range can be considerably different than this calculation! Therefore, the range circle needs to reflect "true range", like it does now, but if Flighttime > 0 and BurnBlow=0, then the range circle should be WeaponVelocity * FlightTime - "true range", to arrive at something more accurate!

Moreover, changing this code means that, for my Units to engage at the proper ranges with Cannons, they must have WeaponVelocities high enough to engage, instead of the previous behavior, where the Unit would be forced to move forwards until it was really in range! This is going to result in quite a few backwards-compatibility problems in this version, I can guarantee.

Argh · Post by **Argh** » 11 Nov 2007, 19:05

6. Tested with BeamWeapons... they work great.

So, um, can't we finally have a BeamWeapon variant that will also obey gravity? That would be great... I'd quit using the graphically-challenged Cannon class entirely, if I could have a BeamWeapon that can also obey gravity... with this Bounce stuff, all of the vector-normalization code seems to be working perfectly...

Argh · Post by **Argh** » 11 Nov 2007, 19:56

Ok, so bounceExplosionGenerator just makes the CEG run, or does an actual explosion take place?

KDR_11k · Post by **KDR_11k** » 11 Nov 2007, 20:21

Argh wrote:So, um, can't we finally have a BeamWeapon variant that will also obey gravity? That would be great... I'd quit using the graphically-challenged Cannon class entirely, if I could have a BeamWeapon that can also obey gravity... with this Bounce stuff, all of the vector-normalization code seems to be working perfectly...

Maybe there will be a universal weapon if someone gets around to coding it that will let you use a ballistic projectile with laser graphics.

Argh · Post by **Argh** » 11 Nov 2007, 20:30

<shrugs> I could just write one, supposing that somebody will be so kind as to check it over- it should be really easy to just write a new case, calling that drawing method but otherwise identical to Cannon...

Post by **ILMTitan** » 12 Nov 2007, 01:26

Argh wrote:Ok, so bounceExplosionGenerator just makes the CEG run, or does an actual explosion take place?

They just cause a CEG to run. Without one, it can be a little difficult to understand that a cannon shot is bouncing (without using a special camera angle).

Saktoth · Post by **Saktoth** » 12 Nov 2007, 02:28

Burnblow causes a projectile to explode when it reaches its target, not when it reaches max range.

So the point at which a burnblow weapon explodes depends on where the target is in relation to its range.

Snipawolf · Post by **Snipawolf** » 12 Nov 2007, 03:43

Lurk Moar.

http://spring.clan-sy.com/wiki/Weapon_Variables

Or maybe not, depends. I haven't used burnblow much >__>

Argh · Post by **Argh** » 12 Nov 2007, 04:36

Best solution for range issues, by far, is to set myGravity to a value lower than 0.2, forcing the weapon to achieve the desired range in every situation.

Not perfect, and I'd really like to be able to define slow-moving weapons that could have noExplode and GroundBounce=1, which right now isn't practical without also making them fall veeeeeeery sloooooowly

Saktoth · Post by **Saktoth** » 12 Nov 2007, 07:05

Oh come on, you are telling me to lurk moar and then quoting the wiki?

That thing is just blatantly wrong, full of errors from top to bottom. Put burblown on a buzzsaw/vulcan or a unit with similarly colossal range and terrible accuracy, and fire it at close range. Watch what happens.

Snipawolf · Post by **Snipawolf** » 12 Nov 2007, 13:03

Oh come on, you are telling me to lurk moar and then quoting the wiki?

Yes.

Never noticed that behavior before, but if you say it is true (and you have no reason to lie), then it must be true.

KDR_11k · Post by **KDR_11k** » 12 Nov 2007, 16:20

Burnblow on ballistics is interpreted as flak.

Spring RTS Engine

Bounce Stuff?

Bounce Stuff?