[ShivanSlayer]

A lot of these mods should be updated to run on the most up to date files.  Having all the extra MediaVP files and other assorted things like Mainhalls really eats up hard drive space

[Asteroth]

Unfortunately, updating a mod to work with the more recent MVPs is often not a trivial affair. While its simple to set up knossos to load up the new MVPs this will very commonly result in bugs and issues of various kinds in the campaign, unless the campaign is carefully combed through and updated to ensure the changes are accounted for. The older the mod is, the more this will be true.

[ShivanSlayer]

I fear that when MediaVps 5 comes out that I will have to delete so many mods so I can delete their MediaVp files to make room

[Novachen]

I fear that when MediaVps 5 comes out that I will have to delete so many mods so I can delete their MediaVp files to make room

And that would be a problem, because of...?

Really, you sound like a person who is playing 10+ games simultaneously and that do not delete any game you have finished.
I actually do not see the problem with it to uninstall any mod after you are done with it. Or only to install that ones, you are playing at the moment anyway.

I think that it is a very strange attitude to install everything regardless of being played and then to complain that Game XY is way too big or the Hard Drive (if we are talking about consoles) is too small.

[Mongoose]

And that would be a problem, because of...?

Really, you sound like a person who is playing 10+ games simultaneously and that do not delete any game you have finished.
I actually do not see the problem with it to uninstall any mod after you are done with it. Or only to install that ones, you are playing at the moment anyway.

I think that it is a very strange attitude to install everything regardless of being played and then to complain that Game XY is way too big or the Hard Drive (if we are talking about consoles) is too small.

There are a lot of people out there who are on poor or metered Internet connections, and it may not be practical for them to redownload gigs' worth of files every time they want to replay a mod. That issue is compounded when the mod itself may be relatively small, but it's pegged to a huge older MediaVPs version. There are also those of us who prefer to keep everything we can downloaded so that it's always available, but are then stuck with having a bunch of what are essentially redundant copies of the same upgraded files.

I've said this elsewhere, but I think the real solution is on the human side of things. Start a sort of "Mod Maintainers" group that has update access to the more classic mods on Knossos, so that they can check them against the newest MediaVPs and give them the all-clear. There are relatively-limited mods like Derelict or Warzone that (theoretically speaking) shouldn't have compatibility issues with most MediaVP updates.

[General Battuta]

The real issue is that when you update a campaign to new MVPs you often have to update it to run on a newer FSO version which often breaks everything. So you have to playtest the whole campaign.

[Mongoose]

The real issue is that when you update a campaign to new MVPs you often have to update it to run on a newer FSO version which often breaks everything. So you have to playtest the whole campaign.

As a non-modder this is the part I'd genuinely like to learn more about. Is there something in particular about newer engine versions that tends to cause the most trouble? I know that despite best efforts there are occasionally new bugs introduced, and there may be times when a feature is tweaked and syntax is changed. The fact that the BP team used so many cutting-edge features probably didn't help matters. But I also don't get the impression that the SCP team is in the habit of intentionally ripping out or deprecating old functionality. Is it mostly just a matter of small tweaks that build up over time?

[Cyborg17]

Scripting is the biggest area of change.  Things are deprecated or changed in scripting often enough that it can cause problems and adjustments have to be made after a few years.

EDIT: Also, the heavier your use of scripting, the more likely the chance of something breaking.

[ShivanSlayer]

I have seen some mods that seem to automatically change to the newest released mediaVps

[Mongoose]

Scripting is the biggest area of change.  Things are deprecated or changed in scripting often enough that it can cause problems and adjustments have to be made after a few years.

EDIT: Also, the heavier your use of scripting, the more likely the chance of something breaking.

Ah, I didn't even think about scripting. The era of modding where I could generally wrap my head around what was going on is fairly prehistoric at this point, and that's an aspect I know next to nothing about.

[Asteroth]

Most often I see this with bugwards-compatability. While we try our best to maintain backwards-compatability, even with already existing mods, bugwards-compatability is only guaranteed for retail. If a behavior is a bug, and retail does not rely on it, it will almost certainly be fixed, even if a mod may (usually unintentionally) rely on it. This is a big source of mods failing to behave the same way with later FSO versions.

[Cyborg17]

Ah, I didn't even think about scripting. The era of modding where I could generally wrap my head around what was going on is fairly prehistoric at this point, and that's an aspect I know next to nothing about.

I mean, you can do a lot without scripting, but to do the most complex things, you do need something that can store and return more info -- and write and read files.  Sexps just have those very basic limitations that scripting gets past.

[General Battuta]

The real issue is that when you update a campaign to new MVPs you often have to update it to run on a newer FSO version which often breaks everything. So you have to playtest the whole campaign.

As a non-modder this is the part I'd genuinely like to learn more about. Is there something in particular about newer engine versions that tends to cause the most trouble? I know that despite best efforts there are occasionally new bugs introduced, and there may be times when a feature is tweaked and syntax is changed. The fact that the BP team used so many cutting-edge features probably didn't help matters. But I also don't get the impression that the SCP team is in the habit of intentionally ripping out or deprecating old functionality. Is it mostly just a matter of small tweaks that build up over time?

Scripting aside the SCP team will just break stuff and not notice for many years. Or purposefully change behavior in the name of maintaining some kind of imagined consistency (see Goober's string changes which broke ever single mod using a strings tbl by forcing them to use the hardcoded strings instead of the strings the modder had defined??). Or purposefully change behavior because the retail behavior is insane (see making turn speed independent of framerate which broke a lot of mods).

[Asteroth]

(see Goober's string changes which broke ever single mod using a strings tbl by forcing them to use the hardcoded strings instead of the strings the modder had defined??)

That was like immediately reverted, though, wasn't it? If we're referring to bugs in general, those are happening all the time, its practically unavoidable, but I would generally recommend waiting for a fix rather than going through the trouble of updating only for a brief transitory period.

[General Battuta]

It was in the latest stable release, iirc.

[Phantom Hoover]

Or purposefully change behavior because the retail behavior is insane (see making turn speed independent of framerate which broke a lot of mods).

That's not true at all, it was extensively tested against a wide selection of mods and literally the only issue that it's caused was breaking some of WiH's SEXP-based checkpoints. That still shouldn't have slipped through, but overall we were very careful to check that that change wasn't going to break released mods.

[General Battuta]

No, it broke JAD (in two separate places!) and the checkpoint work I was doing for Adversary. Set-object-facing-object was the culprit in JAD's case, Adversary had a ship doing endless loops instead of docking.

[The E]

Scripting aside the SCP team will just break stuff and not notice for many years. Or purposefully change behavior in the name of maintaining some kind of imagined consistency (see Goober's string changes which broke ever single mod using a strings tbl by forcing them to use the hardcoded strings instead of the strings the modder had defined??). Or purposefully change behavior because the retail behavior is insane (see making turn speed independent of framerate which broke a lot of mods).

This post pisses me off immensely.

There is always the risk that a given change, even after being looked at by multiple developers with years of experience, will still break a given mod because there is some edge case that we didn't know about or consider that somehow ended up being crucial to the balance of a given mission.
We can't, physically can't, play all the major mods out there and verify that a given change doesn't break things.

I'm really sorry that it sometimes takes a while before an issue is noticed and even longer for it to get resolved, I really am. The time and energy I, and any other SCP coder, has to work on FSO issues is limited.

But at the end of the day, here's what that means: We, as the SCP, can't do all the testing by ourselves. We absolutely rely on people testing the nightlies and RC builds for us. If that doesn't happen, if all the testing is left to us and what little of it we can manage, then this is the result.

[Phantom Hoover]

No, it broke JAD (in two separate places!) and the checkpoint work I was doing for Adversary. Set-object-facing-object was the culprit in JAD's case, Adversary had a ship doing endless loops instead of docking.

If these aren't reported they can never be fixed. For what it's worth, I personally played both mods with FIT on before it was activated by default and I found no reproducible show-stopping issues.

The real issue is that when you update a campaign to new MVPs you often have to update it to run on a newer FSO version which often breaks everything. So you have to playtest the whole campaign.

This is also not true. Changing MVP version can introduce hair-tearing gameplay bugs all by itself. For instance, the new Deimos model has a much larger collision radius than the old one because the first-person viewpoint in the POF file was moved. And you know more than anyone how much the new Sathanas model initially ****ed up gameplay. The only way to keep your mod indefinitely free from these kind of subtle issues is to freeze the entire tech stack it's running on -- FSO, MediaVPs and all. Even that isn't foolproof: if your mod was frozen on 19.0.0 but a user switched to playing it on a screen with a high refresh rate, they'd suddenly find all missiles turning like treacle because of the bug FIT fixed.

This is a fundamental problem of software engineering which every system with interdependent components runs into. Indefinite reliability comes at the price of redundancy and staleness, unless you have the enormous resources required to thoroughly test the entire web of dependencies whenever anything updates.

[General Battuta]

Scripting aside the SCP team will just break stuff and not notice for many years. Or purposefully change behavior in the name of maintaining some kind of imagined consistency (see Goober's string changes which broke ever single mod using a strings tbl by forcing them to use the hardcoded strings instead of the strings the modder had defined??). Or purposefully change behavior because the retail behavior is insane (see making turn speed independent of framerate which broke a lot of mods).

This post pisses me off immensely.

There is always the risk that a given change, even after being looked at by multiple developers with years of experience, will still break a given mod because there is some edge case that we didn't know about or consider that somehow ended up being crucial to the balance of a given mission.
We can't, physically can't, play all the major mods out there and verify that a given change doesn't break things.

I'm really sorry that it sometimes takes a while before an issue is noticed and even longer for it to get resolved, I really am. The time and energy I, and any other SCP coder, has to work on FSO issues is limited.

But at the end of the day, here's what that means: We, as the SCP, can't do all the testing by ourselves. We absolutely rely on people testing the nightlies and RC builds for us. If that doesn't happen, if all the testing is left to us and what little of it we can manage, then this is the result.

I understand all this. I am just describing outcomes, not judging the process. Making software is hard.