[BlueFlames]

Something I've noticed, when switching between retail and FSO builds (3.6.5 and 3.6.9, specifically) is that beams have lost all of their kinetic punch in FSO.  Because beams deal damage based on how long they remain on-target, this bug carries with it a lot of potential disruption of mission balance.  I can set up a few retail-compatible test missions, if you like, but here's a brief summary of effects:

• Friendly AAA beam
In FSO, friendly AAA beam hits are pretty punishing, akin to being hit by a hostile AAA beam.  In retail, you get knocked out of the beam's path, but don't often get more than one-percent hull integrity shaved off, regardless of what you are flying.

• Friendly anti-warship beam
As above, in retail, you get violently knocked about, but take very little damage.  FSO often renders these as instant-kills or leaves you with such severe damage that you may be unable to feasibly continue the fight.

• Hostile AAA beam
On Medium and Easy difficulty levels in retail, hostile AAA beams scrape off three to ten percent of your hull integrity, depending on what you're flying and how direct the hit is (as glancing blows will toss you outside of the beam quicker).  Moreover, they disrupt your aim, making it very difficult to lock on for a bombing run, while receiving beam fire.  In FSO, on the same difficulty settings, the damage can be much more severe, particularly if you're traveling parallel to the beam, though your aim will not be disrupted at all.

• Hostile anti-warship beam
Any differences between retail and FSO are pretty hard to notice here, as most beams of this type tend to deal enough damage to instantly toast a fighter.  Once in a blue moon, in retail, I've gotten lucky on a glancing LTerSlash or SGreen, but it's so infrequent as to be unnoticeable, when it stops happening.

Of course, the balance and damage issues are symptoms, as far as I can tell.  The problem is that beams are supposed to knock you around, and at some point, they seemed to stop doing that.

A pair of caveats:  I haven't investigated to see if this behavior persists in 3.6.10, but a cursory check of the documentation suggests the bug hasn't been noticed, nevermind fixed.  Also, I signed up to Mantis to submit this, but after a year-and-a-half of waiting (on bated breath, no less!) for the confirmation e-mail, I think I've satisfied due patience well enough to post the bug report here.

In any case, though I don't say it often, you have made FS2 into a technical marvel for a new era and created a the definitive testament to what a dedicated community of fans can do.  I wish you luck squashing this bug and any others that cross your path.

[General Battuta]

I've noticed this as well. Beams have lost their beamwhack. Where has the beamwhack gone?

[Wanderer]

Are we talking of FSOpen or FSOpen with mediavps?

[QuantumDelta]

BlueFlames 

Beamwhack is one of the several problems observed as a 'difference' between retail and open, the problem does persist into 3.6.11 even, unfortunately.

I'm surprised you didn't pick up on how much more subsystem damage is done by AAA.

Nice to see you around still ;p

[The E]

Are we talking of FSOpen or FSOpen with mediavps?

Both. It's a problem that exists both with and without the mediavps, leading me to the conclusion that it's a code issue.

[Goober5000]

I stole the beamwhack.

I don't know how all the other problems came about though.

[QuantumDelta]

Teef! Teef!

How did you steal beamwhack 

[Tomo]

It looks like the 'other problems' are direct side-effects of the stolen beamwhack.

With beamwhack, small ships are not inside the beam for very long, as they get thrown out of it pretty quickly. In the case of AAA, the aiming AI cannot compensate very quickly.

Without beamwhack, they stay inside the beam for much longer and AAA can be kept 'on target' much more easily.

[Goober5000]

Teef! Teef!

How did you steal beamwhack 

Arr, that be a pirate trade secret!

No actually, it was a side effect of another bug fix that mixed up global and local coordinates.  The reason beam whack was originally so severe was that it was using global coordinates -- thus inadvertently using the torque of juggernaut (or worse) instead of a little fightercraft.  You ought to be able to test this in retail by subjecting yourself to AAA fire near 0,0,0 and comparing it to (for example) 5000,5000,5000.

Since beam whack is also affected by weapon mass, original whack strength can be achieved by messing around with the weapon table.  Perhaps the FSUpgrade project can include TBMs with adjusted mass values.

[Mongoose]

Huh...so fixing something "broke" something else.  I guess that's par for the course when it comes to coding.

[Fury]

Couldn't be arsed to re-type everything, so here's copy paste from irc. Used code tags to prevent height from getting too large.

Code: [Select]

10:14 <Zacam>: "Since beam whack is also affected by weapon mass, original whack strength can be achieved by messing around with the weapon table.  Perhaps the FSUpgrade project can include TBMs with adjusted mass values."
10:14 <Zacam>: Yet: "actually, it was a side effect of another bug fix that mixed up global and local coordinates.  The reason beam whack was originally so severe was that it was using global coordinates -- thus inadvertently using the torque of juggernaut (or worse) instead of a little fightercraft.  You ought to be able to test this in retail by subjecting yourself to AAA fire near 0,0,0 and comparing it to (for example) 5000,5000,5000."
10:15 <Zacam>: So, why should the FSU be doing anything with tables to correct beamwhack?
10:46 <Wanderer>: the original beam whack was a bug
10:46 <Wanderer>: and :v: really, really sucked in fixing vector/orientation rotate/unrotate bugs
10:50 <Zacam>: Okay. I'll look at how it could be corrected then.
10:51 <Zacam>: I see a lot of testing taking place.
10:52 <Wanderer>: well.. it cant
10:54 <Zacam>: So Goober is off base citing that table edits can restore a sembelance of it?
10:55 <Wanderer>: table edits can be used to raise the force of the beams
10:55 <Wanderer>: so it would in general give bigger punch for the beams
10:56 <Wanderer>: in that respect he is right
11:16 <Fury`>: Isn't that a bit two-faced considering the many arguments with KeldorKatarn?
11:16 <Wanderer>: ?
11:17 <Fury`>: He wanted many times to fix bugs that would affect retail behavior, instead of making them flags, like the ones in ai_profiles.tbl
11:18 <Fury`>: All such bug-fixes were denied if it affects retail behavior by default, hence the crapload of flags to fix such bugs. Shouldn't this have been a flag too?
11:18 <Wanderer>: hmm
11:18 <Wanderer>: there has been plenty of outright retail bugs fixed without flags
11:19 <Fury`>: but did those affect gameplay?
11:19 <Wanderer>: somewhat.. but the earlier behaviour was not the intended behaviour
11:20 <Wanderer>: its a very vague thing
11:20 <Fury`>: As much as that may be so, this beam-whack issue seems to be quite a gameplay change considering how much beams are used
11:21 <Wanderer>: imo.. if the earlier behaviour was not technically wrong but new one improves it -> flag it, if the earlier behaviour was wrong -> just fix it
11:21 <Fury`>: ...
11:22 <Fury`>: okay, in a theoretical situation where hull hitpoints were doubled by a code bug in fighter/bomber class and clearly wasn't intended behavior, you would just fix it?
11:22 <Fury`>: effectively halving hitpoints in fighters
11:22 <Wanderer>: not the same thing
11:22 <Fury`>: it is
11:22 <Fury`>: it affects retail gameplay balance
11:23 <Fury`>: as does beam whack, but not to the same degree
11:23 <Fury`>: concept is the same however
11:23 <Wanderer>: if the number of hitpoints would depend on the fighters distance from a set spot in the game area, then it would be
11:24 <Fury`>: Whatever. I'm just saying that fs2_open should not intentionally affect retail gameplay balance, not noticeable level anyway.
11:24 <Fury`>: Fixes that clearly affect gameplay balance should be flagged
11:25 <Wanderer>: after bit of consideration i would say goobs approach (fix the issue and adjust mediavp tables accordingly) is probably the best
11:25 <Wanderer>: at least form more technical pov
11:25 <Fury`>: you're missing that not everyone use mediavps
11:25 <Fury`>: they're completely optional, separate project of scp
11:25 <Wanderer>: true
11:26 <Fury`>: it should't be another project's task to fix issues caused by other
11:26 <Wanderer>: whole thing is something that should never ever been in the code in the first place
11:27 <Fury`>: you could say that about many things, like collision detection
11:27 <Wanderer>: huh?
11:28 <Fury`>: never mind
11:28 <Zacam>: I can make a retail only patch. Sort of like MV_Core for those that want retail, but use the FSO executable but don't want the eyecandy or mods from the MediaVPs.
11:28 <Wanderer>: just to make it clear i do see your point.. i just do not happen to agree with it
11:28 <Fury`>: Anyway. My opinion on the matter is that the issue is SCP's responsibility to work-around and not push the responsibility on FSU.
11:29 <Wanderer>: you can propose that on the scp board


[Mongoose]

At least as far as I understand it, this situation sounds a bit like the bichording/trichording speed boost in the Descent series, which was originally an unintended side-effect of the ship movement physics.  That wound up working out as a player-used combat strategy that was officially recognized and continued by the series' developers, though, not something accidentally flipped off by fixing a ten-year-old bug.  I don't know where the responsibilities would best lie with "fixing" it, but if there were some way in the code to control what's going on via a separate flag, that would seem to be consistent with prior similar situations.

[Tomo]

For what it's worth, I agree with Goober here.
We cannot just 'put back' the old system, even as a flag, because coordinate system errors have far too many side effects.
- Also, how many mods rely on the current behaviour? It's been like this since before 3.6.9, yes?

In any campaign that's got lots of action far from (0,0,0) in one mission and lots near (0,0,0) in another, wouldn't you agree that behaviour in both should be consistent?

However, then the fun and games *really* begins, as the beamwhack is clearly different depending on how far from 0,0,0 you are.
So how big should it actually be?

That's something that can only be determined by playtesting, and ick, 'tis a horrible mess.

[BlueFlames]

The reason beam whack was originally so severe was that it was using global coordinates -- thus inadvertently using the torque of juggernaut (or worse) instead of a little fightercraft.  You ought to be able to test this in retail by subjecting yourself to AAA fire near 0,0,0 and comparing it to (for example) 5000,5000,5000.

That's something I hadn't made conscious note of before (mostly because it's tough to tell how far from the origin you are, mid-mission).  You are right, though, that distance from the origin plays a role.  Still, there seems to be a natural cap, as a test at (10000,10000,10000) yielded about the same intensity as at (1000000,1000000,1000000), and even at the origin, there's some kick, whereas in FSO there is none, regardless of location.

You've gone from some beamwhack at the origin and a lot of beamwhack everywhere else to no beamwhack anywhere.  I can understand wanting the feel to be consistant across the whole coordinate matrix, but in keeping with the objective of retaining retail FS2's balance and feel, that would mean having some beamwhack everywhere or a lot of beamwhack everywhere.  Amputating beamwhack may have been a side-effect of fixing another issue, and I can appreciate that fact, but ignoring the resultant gameplay alteration seems counter to the spirit of the project.

A solution that pops right to mind would be to insert a multiplier that applies to beam weapons' mass.  If you want to be really fancy, let the user alter the value via a command line option, so you can have a default value that mimics retail FS2, and anybody who finds it too strong or too weak can adjust it to their own liking.

[Zacam]

Not another commandline. Please. These things are getting ugly. -wep.tbm flag would be more than sufficient with "no Default" or off value.

Maybe even two values. One that Turns it off or on (0/1) and if 1 but the second value is not specified, a "Retail-like" value is used.

[Goober5000]

Okay, so two things here, one of which I kept note of at the time but subsequently forgot:

1) The change was made in revision 1353 on January 2, 2005 in beam.cpp.

2) Beam weapon mass in weapons.tbl was always 100, but got forced to 1500 (for damage greater than 150) and 500 (otherwise).

So the code currently checks to see if the weapon mass is 100, and if so, it chooses between a 1500 vs. 500 beam whack value.

What we can probably do is change these hard-coded values, since they are applied using a well-defined system.  I recommend that everyone use the b_whack_small, b_whack_big, and b_whack_damage debug functions to experiment with the whack values.  Once we come to a consensus, the code can be changed.

Incidentally, Fury, I don't consider this "two-faced" because it's consistent with my previous arguments.  The beam whack change does not affect balance or mission outcome, therefore it ought to be fixable without being contingent upon an ai_profiles flag.

[Zacam]

It doesn't? When a whack pushes you out after glancing you rather than being able to stay fixed on you, doesn't adjust gameplay in the slightest because the damage piles in on a per second basis?

I'd hate to see what you DO consider a change then.
(end me trying to be funny)

But seriously, I do understand the change taking place the way it did. I can even applaud the fix and what it was to fix. But apparently, people want a visceral indicator that they have just been hit by a beam, so finding some way to exhibit the behaviour will be nice.

FYI, I'm trying out table values now. But that won't work if nobody is using the MediaVP's, unless I also do a non-mediavp Retail release as well. Which I don't have a problem with. But may complicate MP Validation.

Or not, if I just release a main dir over-ride usable by both....dur.

[Goober5000]

So here's how to do it.  Make a mission with you against, say, a hostile Aeolus.  (Make sure to beam-free-all the hostile ship.)  Then here's how to test out the values:

1) Run a debug build

2) During the mission, hit Shift-Enter to get to the debug window

3) Type "b_whack_small 2000" (without the quotes; and 2000 can be any number) to test out the different whack values

4) Get hit by AAA fire (you might want to make yourself invulnerable first)

The b_whack_small command controls the small beam damage, and the b_whack_big command controls large beam damage.  I think 2000 for small beams and 10000 for big beams works pretty well.