Author Topic: Changes to Weapon Locks & Destroyed Subsystems  (Read 1161 times)

0 Members and 1 Guest are viewing this topic.

Offline Trivial Psychic

  • 212
  • Snoop Junkie
Changes to Weapon Locks & Destroyed Subsystems
I've noticed recently that there has been a change to the ability to obtain a target lock on a destroyed subsystem.  Basically, you can't.  Although that doesn't sound all that concerning, it makes it difficult to destroy some ships that require the use of Huge weapons, should all of its subsystems and turrets be destroyed.  Most torpedoes require a weapons lock to fire, and if it can't get a lock, then you can't fire it.  You also can't get a lock on subsystems that aren't assigned hitpoints, like fighterbays (unless it is assigned subsystem strength in the tables).  I don't know when this change occurred... yet.
The Trivial Psychic Strikes Again!

 

Offline mjn.mixael

  • Cutscene Master
  • 212
  • Chopped liver
    • Steam
    • Twitter
Re: Changes to Weapon Locks & Destroyed Subsystems
https://github.com/scp-fs2open/fs2open.github.com/pull/3614

What flag was added to opt out of the behavior is not on the wiki as far as I can tell.

Having read through the two related threads on Github now... I can't say how thoroughly I disagree with the decisions made. This is a broad sweeping change and should have never even been considered as an opt-out candidate rather than opt-in. This will affect retail. Blaming mission designers is bad form.
« Last Edit: November 11, 2021, 12:48:17 pm by mjn.mixael »
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.

 

Offline Mongoose

  • Rikki-Tikki-Tavi
  • Global Moderator
  • 212
  • This brain for rent.
    • Minecraft
    • Steam
    • Something
Re: Changes to Weapon Locks & Destroyed Subsystems
Yeah, I can definitely remember missions where I wound up bombing a fully-disarmed ship and targeting a dead subsystem. Granted it's something of a niche case where there was not much going on and I was bored enough to take out everything, but it definitely happened.

 

Offline EatThePath

  • 28
  • Laser Lich
    • Twitter
Re: Changes to Weapon Locks & Destroyed Subsystems
As the main reason that change went in, I feel I should chime in. At first this thread really confused me, because I was very focused on turrets and was confident that locking on to dead turrets was never possible without multilock. The issue of a ship with no subsystems left at all was raised a few times in discussions and potential ways to handle it discussed, but I'm not sure I ever fully realized/remembered that dead non-turret subsystems have always been target-able. My testing and attention consequently didn't involve that case at all.

Having now tested it, I see that indeed you can't lock them, despite the fact that you can still target them. Not being able to lock your targeted subsystem is definitely something I would consider a bug, and I'll be filing it at as such shortly if nobody else has beat me to it.

I only advocated the change as opt in because of how niche it's intended effects are. It should only affect the secondary seekers of multilock weapons, whose adoption has been quite limited as best I could determine. MJN, I must admit that having been so involved in this one, despite not making the final decision or the actual code, it stings a little that you would conclude that a retail-behavior change was knowingly and cavalierly made.

Also, https://wiki.hard-light.net/index.php/Weapons.tbl#.22multilock_target_dead_subsys.22
Name your damn turrets and sounds! Numbers alone aren't helpful!
"if disco is dead then I am the laser lich"
"...[Warmachine] keeps changing as fast as EatThePath can force the engine to do his dark bidding..."

 

Offline Nohiki

  • 28
  • Graf von Kaffeetrinken
    • Minecraft
    • Skype
    • Steam
Re: Changes to Weapon Locks & Destroyed Subsystems
It always sort of confused me why missiles and beams do not use the same targeting mechanism? Beams can lock onto a model vertex IIRC if subsystem targeting is disabled/unavailable.
:::ALSO PROUD VASUDAN RIGHTS SUPPORTER:::

 
Re: Changes to Weapon Locks & Destroyed Subsystems
Yeah, guys, the bug here is that this is affecting primary targets, and not just multilock. All those decisions were made for multilock 'incidental' locks only. The fix should be pretty simple.

 

Offline EatThePath

  • 28
  • Laser Lich
    • Twitter
Re: Changes to Weapon Locks & Destroyed Subsystems
That fix is in nightlies now. Please make some noise if there are any more troubles
Name your damn turrets and sounds! Numbers alone aren't helpful!
"if disco is dead then I am the laser lich"
"...[Warmachine] keeps changing as fast as EatThePath can force the engine to do his dark bidding..."

 

Offline mjn.mixael

  • Cutscene Master
  • 212
  • Chopped liver
    • Steam
    • Twitter
Re: Changes to Weapon Locks & Destroyed Subsystems
In the process of changing default behavior for a feature that's been in final release builds a retail affecting bug was created. I'm sorry it stings, but at the same time this new trend of people (both in SCP and not in SCP.. in this case not) of blaming modders and FREDers for not noticing changes in the engine also stings. It feels like I'm expected to read every commit to the FSO codebase.  :(
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.

 

Offline EatThePath

  • 28
  • Laser Lich
    • Twitter
Re: Changes to Weapon Locks & Destroyed Subsystems
Quote
blaming modders and FREDers for not noticing changes in the engine also stings
And who did that here? There were some offhand comments in the issue discussion about 'bad design' yes, and I'd agree that those were misguided as reasons to change or not change something, but I don't think those comments were very influential in the decision making. And I don't see anyone there or in this thread 'blaming' anyone for having a problem with the bugged breaking change.  If I'm having a blind spot for something, please point it out.
Name your damn turrets and sounds! Numbers alone aren't helpful!
"if disco is dead then I am the laser lich"
"...[Warmachine] keeps changing as fast as EatThePath can force the engine to do his dark bidding..."

 

Offline mjn.mixael

  • Cutscene Master
  • 212
  • Chopped liver
    • Steam
    • Twitter
Re: Changes to Weapon Locks & Destroyed Subsystems
Offhand comments are all it takes.

The blame is in aggregate. The new "pin your build" mantra is what set us up for changes to default feature behavior (across final releases!) being considered mundane. Had this thread not been posted, I would not have known to fix my mod. That it caused a retail facing bug is the only way I might have seen this.

In an effort to make mods stable, SCP has ignored modders doing active development unless they are A) persistent or B) part of SCP.  I did 5 years of dev on BtA1 and never had near this much trouble with FSO being a moving target as I do now.

But none of this really belongs in this thread. If you really want to discuss it further, start a new one in the appropriate place.
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.

 
Re: Changes to Weapon Locks & Destroyed Subsystems
I mean, I think this is a perfectly fine place to discuss this, It's not like things are final, we can still reverse this decision if you think this was a bad idea. Several people put forth the idea that this was a more reasonable default, and given it was a recent feature, would also have relatively minimal fallout. The fact that you were unable to contribute to this discussion does not mean we were trying to "ignore" you, it's obviously going to be very difficult to weigh the opinions of those are aren't able to participate in the discussion.

Looking back through Discord's logs, around the time this decision was being made we tallied up those mods who were using multilock and since BtA was, we contacted DefCynodont and passed the changes by him. I was hoping this would either bring to the surface any qualms from you/the team or at least notify you guys of the changes, but it appears that wasn't enough.

  

Offline mjn.mixael

  • Cutscene Master
  • 212
  • Chopped liver
    • Steam
    • Twitter
Re: Changes to Weapon Locks & Destroyed Subsystems
Reversing feature behavior by default should never have been on the table in the first place, though. You did it that way because the one who wanted the alternate behavior made a ticket. In the course of changing it SCP opted to change the default and have to hopefully notify all previous users of the feature to opt-out... why do that instead of making the new behavior opt-in and the one person who wanted it was right there already aware of the change? Why make a this big broad generalized change when a targeted change would have worked just as well?

Now if this was a feature that was added during nightly and changed during the same nightly run, that's one thing. That's expected and part of the game. This was not that. I can understand something changing across final releases if it's buggy or whatever and there's no alternative. This wasn't that either. To me, as someone not in SCP, this feels like part of the trend away from mod backwards compatibility being even a base consideration.  :(

EDIT: And yes, I'm aware that you brought up backwards compatibility in the github thread, Asteroth. That thought was obviously discarded. That's my issue.
« Last Edit: November 23, 2021, 09:13:24 am by mjn.mixael »
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.

 
Re: Changes to Weapon Locks & Destroyed Subsystems
When new features are added, a lot of considerations have to be made about whether the way that some feature is being presented is in fact the best way to do so. I can't speak for others, but at least it is a huge consideration for me. It is in fact, what I would call the biggest barrier to actually implementing something I know exactly how to do. There are several features, I know exactly how to do, but the potential awkwardness and/or unavoidable ambiguity or unintuitive design of actually using the feature effectively prevents me from adding the feature at all. Even of features that do make it in, this aspect undoubtedly is the largest aspect that slows down it's development and causes me the greatest consternation, sometimes even to the annoyance of the person who requested it.

Why? Because once a feature's design/API is chosen, we are locked into it forever.

There are (in general) no take-backsies. Get it right the first time, or every single modder for the rest of history of FSO is going to have to deal with your poor decisions. When I mod, I constantly chafe at poor design decisions made with features. It's not always the original developer's fault, but these things really add up. Inconsistent naming schemes, bad naming in general, unintuitive behavior, similar mechanics being duplicated in different areas with slightly different designs for maximum confusion, features being in the wrong place, a feature claiming to be comprehensive for some set of situations but only covers some of them, a feature doing much more than it claims to do, the list goes on. And while experienced modders can eventually learn all of this as second-nature, it's this kind of stuff than turns away newer modders and makes FSO less appealing as a platform in general.

All of this is to say that when presented with an opportunity to change a feature for the better, where it is actually possible to tally up and notify all of the feature's users about the change then yes! I will try to make that change happen. Backwards incompatible changes are not an inherent evil, it's simply an extremely rare situation given the requirements for it to be reasonable. There is no "trend away from mod backwards compatibility being a base consideration", but you're probably right that it should not have been after the stable, which is something I definitely think we should be more ironclad about.

 

Offline mjn.mixael

  • Cutscene Master
  • 212
  • Chopped liver
    • Steam
    • Twitter
Re: Changes to Weapon Locks & Destroyed Subsystems
Saying there is no trend and then saying SCP should be more ironclad regarding evidence of that trend just makes me shrug.

I've said my piece. I stand by my original comment; I strongly disagree with the decisions made here in this case. Take it or leave it. Chasing FSO recently is exhausting and not everyone has the coding know-how to run hours long custom tests on AI changes or whatever else comes up to figure out what SCP is doing all the time. But hey, I'm getting really, really good at searching the commit log to figure out why something broke.

But that's just my anecdotal experience as one of a handful of active FREDers that remain around here. ¯\_(ツ)_/¯
« Last Edit: November 23, 2021, 12:33:04 pm by mjn.mixael »
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.