Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: z64555 on August 15, 2021, 09:51:53 pm
-
This is a discussion that we've been tossing around on discord off and on, this forum post serves as something a bit easier to keep track of.
Essentially, the SCP doesn't have a path to outright removal of features, only deprecation. To clarify:
- Remove: Completely wipe the existence of a feature from the codebase, making any of its former triggers and methods to use it flagged as an error
- Deprecate: Feature still works, but it won't be upgraded anymore and you may get scolded for using it.
Vanilla features will only ever be deprecated, for the simple fact that we must uphold the Golden Rule of "Thou Shall Not Break Retail," however, any and all features added to the engine by the FSO-SCP is subject to removal. Of course, whats holding us back from doing so is that it'll break any and all mod that uses them (a Bad Thing).
However, if all we ever do is deprecate features and not be allowed to remove ones (especially ones that have their functionality merged, superseded, or outmoded by another feature) we wind up with a ton of crusty code sitting around, getting in the way of maintenance and new work.
We have deprecated sexp's, but to my knowledge we don't have a proper End-of-life cycle for features in general. To start off the discussion, I suggest the following End-of-Life cycle:
- Deprecate a feature for some agreed upon time, such as two release cycles (half a year) or four release cycles (a full year)
- Once the time period is up, remove the feature. Trying to activate the feature through whatever mechanism it uses should return an error message stating when the feature was removed.
- Depending on the type and severity of the feature, this error message may or may not be blocking further execution of the game.
-
Well... as my knowledge goes, most of the older Mods that were designed for 3.6.9 etc. are not working properly with current Builds anyway and need to be updated to be work again.
And i have to say, that i encountered some slightly changed behaviours in the retail campaign missions of FS2 with a more current Open Setup. But some of them could simple be caused by the MediaVP models of course.
I do not like to drag code with me that inflates everything. Mods that require a specific build can still be played if you use the recommend build and MediaVPs from the release thread. It is not like old versions are erased from existence.
-
For context, how many cases would be actually in question? Is this something that would happen on a frequent basis or just every once in a while? The best reference I get for this is the Lua code which has caused scripts to break on a frequent basis.
-
For context, how many cases would be actually in question? Is this something that would happen on a frequent basis or just every once in a while? The best reference I get for this is the Lua code which has caused scripts to break on a frequent basis.
I can't say for certain what the number of dead features are in the codebase currently, but I can say for certain the the end-of-life cycle should be a rare item. Our primary course of action thus far is to add in new features or enhance existing ones, when ever possible.
-
For context, how many cases would be actually in question? Is this something that would happen on a frequent basis or just every once in a while? The best reference I get for this is the Lua code which has caused scripts to break on a frequent basis.
It would not be common but there are a number of features that are simply too specific and shouldn't have been done in-engine (looking at you, autopilot), ones that work but in a buggy way, or features that would be maintained but the way were defined in tables ended up being very clunky and unintuitive, and should be redone in a non-backwards compatible way. These are the main situations I would imagine for this sort of thing.
I would be overjoyed if people were OK with this, but I've generally been of the opinion that most modders would be strongly against this so I'd love to know people's thoughts.
-
As a modder I would be okay with this so long as a very clear, prominent, and explicit changelog with transition instructions was provided. For instance if autopilot was removed with the intention that it be replaced with a script, ideally I'd have that change happen hand in hand with making available the script that replaces it. Maybe not a drop-in replacement but at the very least the skeleton of it. Or if a table value is redefined in a new way (spawn weapon configuration I'm looking at you), instructions for how to produce equivalent effects in the new system.
With the way that people mod there would probably have to be a list of those for current nightlies rather than waiting for a stable to be built.
-
As a modder I would be okay with this so long as a very clear, prominent, and explicit changelog with transition instructions was provided.
...
With the way that people mod there would probably have to be a list of those for current nightlies rather than waiting for a stable to be built.
Sounds pretty good to me. I guess there's no point in maintaining dead-ends; but I think it'd be useful to know what is being removed, ideally before a final decision is made.
For documentation there'd be a single pinned post/wiki article so you could just scroll to the version where xyz was removed.
For instance if autopilot was removed with the intention that it be replaced with a script, ideally I'd have that change happen hand in hand with making available the script that replaces it. Maybe not a drop-in replacement but at the very least the skeleton of it. Or if a table value is redefined in a new way (spawn weapon configuration I'm looking at you), instructions for how to produce equivalent effects in the new system.
While that would be the best solution idk how realistic that is.