Hard Light Productions Forums
General FreeSpace => FreeSpace Discussion => Topic started by: Vrets on April 12, 2015, 11:58:57 pm
-
1. Am I the only one that has noticed a slight 1-2 second delay between the AI launching a bomb, and the player's ability to intercept it with cannon fire? I swear that this has been the case for the 10+ years that I've played this game. I remember so distinctly that feeling when a Nahema launches a double "unknown bomb" at close range, and that instinctual, doomed knowledge that my lasers will not have time for the 1-2 second "grace period" to expire so I can save that transport.
2. If not, am I the only one to notice that this delay doesn't exist anymore, or at least is not as consistent? I was FREDing a quick escort mission (I know, I'm sorry) and I am able to intercept the AI's bombs (specifically, Cyclops) the moment they are launched. In fact, the Deimos that I am in charge of escorting is swatting down these bombs at point-blank range with blob turrets like I've never seen. Nobody else is talking about this, but it looks so weird and unfamiliar that I have to mention something.
Perhaps it was only ever my crappy computer that granted bombs a 1-2 second "grace period" when launched. Or maybe I hallucinated the entire thing for all of these years.
-
It's certainly possible. There have been quite a few changes like this over the years, some intentional and some accidental. But a change like this that affects balance should be optional. Would you be able to test different builds to pin down when the behavior appears to have changed?
-
Yes, I could do that.
However, it would first be reassuring to have at least one other person that has noticed the 1-2 second "grace period" of bomb immortality, to validate my sanity before I jump into this.
-
to be honest, the only time I can recall that sort of grace period was when playing WCS:DD (and I found it damn annoying)
-
Yes, I could do that.
However, it would first be reassuring to have at least one other person that has noticed the 1-2 second "grace period" of bomb immortality, to validate my sanity before I jump into this.
If you can reproduce it, then I trust your judgement. :)
-
This delay should still be present as an AI profile flag (http://hard-light.net/wiki/index.php/Ai_profiles.tbl#.24Delay_Before_Allowing_Bombs_to_Be_Shot_Down:) which defaults to 1.5 seconds (matching the hardcoded BOMB_ARM_TIME #define in the Volition sources, it looks like).
-
That seems like it should still be destroyable, just not detonatable.
As in, the bombs won't go kaboom, merely fizzle out or fail to detonate on impact, if they are destroyed before the arm time.
My 2c (I think the arm time was more so you couldn't 'cheat' and point-blank fire into capships? IRL, the reason would be so an accidental misfire/detonation or a hostile shootdown would not damage the bomber as much.)
-
That seems like it should still be destroyable, just not detonatable.
As in, the bombs won't go kaboom, merely fizzle out or fail to detonate on impact, if they are destroyed before the arm time.
My 2c (I think the arm time was more so you couldn't 'cheat' and point-blank fire into capships? IRL, the reason would be so an accidental misfire/detonation or a hostile shootdown would not damage the bomber as much.)
That would be the weapons.tbl arm time (http://www.hard-light.net/wiki/index.php/Weapons.tbl#.24Arm_time:), a separate value; the code for this one is in collideweaponweapon.cpp and clearly indicates that the collision will not happen during that grace period.
-
Hmm. What is the engine's purpose for making the bomb non-collideable at first? :confused:
-
I don't know, point is that it's retail behaviour which we need to preserve.
-
Yeah, I realized that, just wondering what the :v: guys were reasoning.
Perhaps to give bombers a chance to successfully launch when being clobbered from behind by enemy interceptors?
-
Hmm. What is the engine's purpose for making the bomb non-collideable at first? :confused:
You can outrun a number of your bombs on afterburner; it's not even particularly hard. If you tap the burners at launch, you could run over your own bombs. In FS1, this would have killed you very quickly. In FS2, it'd be merely annoying.
-
Hmm. What is the engine's purpose for making the bomb non-collideable at first? :confused:
You can outrun a number of your bombs on afterburner; it's not even particularly hard. If you tap the burners at launch, you could run over your own bombs. In FS1, this would have killed you very quickly. In FS2, it'd be merely annoying.
That seems like it should still be destroyable, just not detonatable.
As in, the bombs won't go kaboom, merely fizzle out or fail to detonate on impact, if they are destroyed before the arm time.
My 2c (I think the arm time was more so you couldn't 'cheat' and point-blank fire into capships? IRL, the reason would be so an accidental misfire/detonation or a hostile shootdown would not damage the bomber as much.)
That would be the weapons.tbl arm time (http://www.hard-light.net/wiki/index.php/Weapons.tbl#.24Arm_time:), a separate value; the code for this one is in collideweaponweapon.cpp and clearly indicates that the collision will not happen during that grace period.
-
missing the point
Arm time is a relatively recent addition and didn't exist in FS1. A Tsunami can, and will, blow up on you right out of the tube. And it does suck.
Also, l2r.
In FS2, it'd be merely annoying.
Just because they're not armed doesn't mean you couldn't run them over and get no bombs when you launched bombs. Simply being not-armed does not mean not-destructible.
-
Also, l2r.
Take thine own advice:
the code for this one is in collideweaponweapon.cpp and clearly indicates that the collision will not happen during that grace period.
This delay has absolutely no effect on ship/weapon collisions (which are handled by collideshipweapon.cpp); nothing stops you from colliding with your own bombs (unless you use collision groups and $Weapons inherit parent collision group: (http://www.hard-light.net/wiki/index.php/Game_settings.tbl#.24Weapons_inherit_parent_collision_group:), but that's definitely not retail).
-
Something is wrong, I can feel it; with every bomb interception mission, I am becoming more certain that the ~1-2 second bomb invulnerability "grace period" no longer exists. I was playing "Dunkerque" tonight and a pair of Nahemas launched bombs which appeared to instantly detonate...perhaps because either it, or the ship behind it, collided immediately ("instantaneously") with the bombs.
I should make a bomb testbench with a Fenris or something spamming bombs at an installation and just run through builds trying to shoot down the bombs. It's the ideal, sad project for a doomed saturday morning
-
Something is wrong, I can feel it; with every bomb interception mission, I am becoming more certain that the ~1-2 second bomb invulnerability "grace period" no longer exists. I was playing "Dunkerque" tonight and a pair of Nahemas launched bombs which appeared to instantly detonate...perhaps because either it, or the ship behind it, collided immediately ("instantaneously") with the bombs.
As already mentioned, the grace period doesn't apply to collisions with ships (and didn't in retail, either).
-
That particular example may have been a red herring, but I still believe that something has changed from the retail experience. Bombs used to absorb incoming fire for ~1-2 seconds after being launched, which made bombers an actual danger when they were allowed to get too close to their targets. This experience is burned into my brain after what feels like a decade of playing this game.
I shall return with proof!
-
That particular example may have been a red herring, but I still believe that something has changed from the retail experience. Bombs used to absorb incoming fire for ~1-2 seconds after being launched, which made bombers an actual danger when they were allowed to get too close to their targets. This experience is burned into my brain after what feels like a decade of playing this game.
I shall return with proof!
1.5 seconds, and that's what it still defaults to.
If you can find proof that "$Delay Before Allowing Bombs to Be Shot Down:" is currently broken, though, I'd be very interested to see it!
-
I have returned with proof of my accusations!
Step 1: download the mission "Bomb Testbench", contained in archive "bombtest.zip", from here. (http://sectorgame.com/fsfiles/?dir=uploads/Projects%20-%20Campaigns%20-%20TCs/Demos&response)
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), with the 2014 mediavps selected as your mod
- Load mission with difficulty "medium"
- Do not touch the controls. Time compression up to 4x is optional.
- 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.
EDIT: time compression is optional
-
I have returned with proof of my accusations!
Step 1: download the mission "Bomb Testbench" from here. (http://sectorgame.com/fsfiles/?dir=uploads/Projects%20-%20Campaigns%20-%20TCs/Demos&response)
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).
-
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
-
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:
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."):
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.
-
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
-
Time to make more swarm torpedo interception missions.
-
Sounds about right to me Ralwood. I can't code at the moment so I'll leave it to you.
-
Should the SCP really be preserving retail bugs?
-
Should the SCP really be preserving retail bugs?
In cases like this? Yes.
-
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.. :P
-
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.
-
Dragon, I believe the problem here is that the delay is incorrectly set, not that there is a delay in the first place.
-
Yeah, my reading of the situation is that :v: 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.
-
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).
-
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.
-
:nervous: What was the Trebuchet bug?
-
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.
-
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).
-
Ah, yeah, I remember that one. I didn't know about the Shivans having Trebs in the Lions though.
-
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.
-
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. ;)
-
Make a treb that is treated 'normally', say, treb#retail and set that as the default loadout, then fix the regular treb handling.
Or make, say, a "treb#corrected" which behaves the expected way and then tell modders to use that instead.
Which is basically what the AI profile flag that changes how the AI uses Trebuchets is doing.
(The other problem with your suggestion is that we can't can't modify retail data.)
-
(The other problem with your suggestion is that we can't can't modify retail data.)
Retail engine will behave using original behavior + use a MediaVPs ships.tbl //if FSO > 3.7.2 then use x entry instead.
Yeah, the other (treb#corrected AI tag) way is better. :P
-
(The other problem with your suggestion is that we can't can't modify retail data.)
Retail engine will behave using original behavior + use a MediaVPs ships.tbl //if FSO > 3.7.2 then use x entry instead.
Yeah, the other (treb#corrected AI tag) way is better. :P
And it would still be something that we would not do in the MediaVPs.
-
I've finally gotten around to this and made a pull request (https://github.com/scp-fs2open/fs2open.github.com/pull/94).
-
My life's work has been achieved. Billions of hours spent playing this game--hours in which every frame of gameplay subtlety was committed to gut memory-- have culminated in the discovery of crappy bombs.
For the first time in my life, I am filled...with joy.