General FreeSpace > FreeSpace & FreeSpace Open Support

Changes to Weapon Locks & Destroyed Subsystems

<< < (3/3)

Asteroth:
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.

mjn.mixael:
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.

Asteroth:
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.

mjn.mixael:
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. ¯\_(ツ)_/¯

Navigation

[0] Message Index

[*] Previous page

Go to full version