[AdmiralRalwood]

I have returned with proof of my accusations!

Step 1: download the mission "Bomb Testbench" from here.

Freespace2 mods has yet to verify my upload; thank you to Hunter from sectorgame for his simple upload process.

Step 2: follow my test plan exactly:

• Load Fs2: SCP, build fs2_open_3_7_2_RC5 (I'm using NO_SSE)
• Load mission with difficulty "medium"
• Engage x4 time compression. Do not otherwise touch the controls.
• Observe as the alastor sentry guns successfully defend the Elysium transport, seemingly indefinitely.
• Close the game. Open Fs2 retail.
• Repeat steps 2-3.
• Observe as the sentry guns are not able to shoot down the bomb, and the Elysium transport is destroyed (usually on the very first bomb)

Further analysis is required, but the gameplay difference between retail and FSO is not subtle at all. Bombs are much more difficult to intercept in retail; it is highly likely that bombs have a far longer invulnerability period in Retail than in FSO.

Well, no, all you've demonstrated is that there's a gameplay difference between FSO and Retail on your system. Which is a problem that needs correcting, no doubt, but given your steps to reproduce, how do we know this isn't caused by time compression instead of FSO ignoring bomb invulnerability?

In addition, it is not "highly likely that bombs have a far longer invulnerability period in Retail than in FSO", given that default value used by FSO is exactly identical to the value used by the Retail code. I'll be checking out your mission, of course, but I'm looking more specifically for evidence that bombs can be shot down immediately after launch, not just evidence that bombs are easier to shoot down in FSO under time compression (although that may be a problem worth looking into by itself).

[Vrets]

It is not necessary to use time compression, just recommended to quickly see multiple trials; use x1 time compression, then.

For me, the salient observation is simply that it has become much easier to shoot down bombs in FSO, relative to original retail gameplay. I think that when you play the testbench you'll agree that the gameplay difference between retail and FSO is obvious (unless my system is just crazy ).

If we can accept that gameplay has been significantly altered from retail to Fs2 in the department of bomb interception, we can continue to investigate in detail.  While it appears obvious to me that the cyclops launched at the transport in retail shrug off the perfectly on-target morningstar fire from the sentry guns for far longer than in FSO, I acknowledge that we'll need even more proof.

edit: I haven't tried FSO builds other than 3_7_2_RC5; if others can please try my testbench mission to confirm my findings, I will move on to testing a variety of FSO builds

[AdmiralRalwood]

Well I'll be damned. No need for further testing; I know exactly what's happening now.

Here's the retail code for bomb invulnerability:

Code: [Select]

if (wipA->lifetime - wpA->lifeleft < BOMB_ARM_TIME)
return 0;
Here's the FSO code for bomb invulnerability (this logic was introduced by karajorma in r8696, back in 2012, with the giveaway commit message of "Fix a bug that caused bombs to be indestructible by the player for much longer than they should be according to the table settings given."):

Code: [Select]

if (wipA->wi_flags & WIF_LOCKED_HOMING) {
if ( (wipA->max_lifetime - wpA->lifeleft) < The_mission.ai_profile->delay_bomb_arm_timer[Game_skill_level] )
return 0;
}
else if ( (wipA->lifetime - wpA->lifeleft) < The_mission.ai_profile->delay_bomb_arm_timer[Game_skill_level] )
return 0;
See, when an aspect_seeker is fired with a lock, it gets a 20% increase in its lifespan (or, rather, a LOCKED_HOMING_EXTENDED_LIFE_FACTOR). This is reflected on the weapon itself, but not the maximum lifespan of the weapon type (hence why FSO calculates "max_lifetime", so it can compare more easily).

However, retail made no account for the fact that a locked aspect seeker (e.g. every retail bomb) has its "lifeleft" value so increased, so this comparison is comparing with the unmodified lifetime. Given the 25 second lifetime of the Cyclops (the bomb you used in this test), that translates to an extra 5 seconds during which it can't be shot down, meaning a full 6.5 seconds in which the bomb can only be stopped by ramming it.

(Incidentally, the FSO code is also wrong here; it should make sure the weapon actually has a locked target; this only matters for aspect-seeking bombs(/missiles with a defined number of hitpoints, so they can be shot down) that allow dumbfire, which would be a mod-only thing. Still, such a bomb(/missile) would have its grace period reduced, instead of extended, most probably to 0!)

The proper fix here is either a game_settings.tbl flag or an ai_profiles.tbl flag (I'd normally put it in the former without a second thought, but the "$Delay Before Allowing Bombs to Be Shot Down:" setting being in ai_profiles.tbl makes me have second thoughts there, since the two are linked) on the max_lifetime check and encourage mods that don't want an automatic invulnerability extension to set the flag.

[Vrets]

Aaaauuuugh, victory is ours. Awesome that you found the source of the gameplay change.

Since 2012?! Entire campaigns may have unwittingly been balanced around sneakily distorted gameplay, but it sounds like your fix will preserve the balance of those campaigns whilst restoring the retail bomb interception experience, going forward. Bombers shall return to their previous levels of menace!

edit: napalmed unnecessarily verbose post

[Droid803]

Time to make more swarm torpedo interception missions.

[karajorma]

Sounds about right to me Ralwood. I can't code at the moment so I'll leave it to you.

[Phantom Hoover]

Should the SCP really be preserving retail bugs?

[The E]

Should the SCP really be preserving retail bugs?

In cases like this? Yes.

[jr2]

Because it might change mission balance. (The bug was undetected before, therefore, the missions were balanced around the bug.. we hope).

Of course, if the bug was introduced by a late code change / reversion before FS2 was finalized and after they balanced the missions, well, we'll never know..

[Dragon]

I never thought it was a bug. It made sense to not let the player shoot down bombs as they left the bay, so they won't vape the bomber. It always seemed like a deliberate gameplay choice to me.

[X3N0-Life-Form]

Dragon, I believe the problem here is that the delay is incorrectly set, not that there is a delay in the first place.

[Phantom Hoover]

Yeah, my reading of the situation is that made a minor code error that made bombs invulnerable for significantly longer than the specified value in the tables, and the SCP later fixed this. Mission balance isn't a very convincing reason to leave the bug in, given that a) retail balance isn't very fine-tuned, b) every mission made in the last three years was balanced with it fixed and c) this is the only time anyone's noticed it, and it took significant effort to confirm that it was actually happening.

[jr2]

I agree, I think it's simply a knee-jerk to the possibility of encroaching upon teh most holy rule of the SCP (don't break retail). However, since when does that mean, 'don't fix retail'?  It doesn't, honestly, I would think that what would be in order would be to fix the retail bug and then check for balance issues.    You're not really enhancing retail, you're just fixing an obvious error. 

I dunno, it's a fine line, and the SCP dances within a millimeter of both sides (I seem to have a vague memory that they may have fixed retail bugs like this before, but I might be quite mistaken).

[Goober5000]

Mission balance isn't a very convincing reason to leave the bug in, given that a) retail balance isn't very fine-tuned, b) every mission made in the last three years was balanced with it fixed and c) this is the only time anyone's noticed it, and it took significant effort to confirm that it was actually happening.

Ehh, no.

1) Retail balance is the metric against which all other campaigns are balanced.  This starts with retail itself and extends from classic campaigns such as Derelict and Aeos Affair to modern campaigns such as Blue Planet and Between the Ashes.  Balance must stay consistent and predictable between builds so that mods will continue to work as designed.

2) This is unfortunate, but rebalancing recent mods is the lesser evil compared with changing the balance on every prior mod ever published.

3) This is the first time someone has mentioned it.  We have no idea how many people noticed it but said nothing, or kept their grumbling to themselves.  Or they may have adapted to the balance change, thinking "oh, that mission plays differently now".  The quintessential example of this is the "Game of TAG" mission, which had not one but two balance-breaking bugs in FSO for a number of years.

I agree, I think it's simply a knee-jerk to the possibility of encroaching upon teh most holy rule of the SCP (don't break retail). However, since when does that mean, 'don't fix retail'?  It doesn't, honestly, I would think that what would be in order would be to fix the retail bug and then check for balance issues.    You're not really enhancing retail, you're just fixing an obvious error.

It does when "fix retail" means affecting the balance.  Ai_profiles.tbl is full of these sorts of options.  Try playing the Blue Lions missions with the Trebuchet bug fixed.

[Mars]

  What was the Trebuchet bug?

[Goober5000]

AI fighters were prevented from firing Trebuchets in retail (something to do with the bomber+ flag, I think).  But all the Shivan fighters and bombers in the last five missions were loaded chock full of Trebuchets.  When that bug was fixed, it was missile spam everywhere.

Most of the missions were still barely beatable, but the two Lambda transports in Dunkerque got utterly lit up.

[AdmiralRalwood]

AI fighters were prevented from firing Trebuchets in retail (something to do with the bomber+ flag, I think).

"bomber+" in combination with "huge". Retail AI basically takes that as "only fire at bombers" and "never fire at bombers" and the two result in the thing never being fired without good-secondary-time (which, it's worth noting, the retail campaign does use with Trebuchets a few times).

[Mars]

Ah, yeah, I remember that one. I didn't know about the Shivans having Trebs in the Lions though.

[X3N0-Life-Form]

Thing is, Maras and Basilisks have trebs as their default loadouts, so any AI tempering regarding their ability to fire those missiles is going to have some pretty serious balance consequences.

[jr2]

Make a treb that is treated 'normally', say, treb#retail and set that as the default loadout, then fix the regular treb handling.


Basically, have the engine treat treb#retail the old way and everything else the fixed way, and change default loudout to treb#retail.

Just a thought, now I get to see if/how it's flawed.