Hard Light Productions Forums
General FreeSpace => FreeSpace Discussion => Topic started by: ShivanSlayer on March 06, 2021, 12:54:58 pm
-
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
-
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.
-
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
-
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.
-
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.
-
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.
-
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 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.
-
I have seen some mods that seem to automatically change to the newest released mediaVps
-
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.
-
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.
-
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.
-
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).
-
(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.
-
It was in the latest stable release, iirc.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Phrases like "just break stuff" and "imagined consistency" certainly read as some form of judgement, even if they're not intended as such.
In any case, those outcomes seem practically inevitable to me. As PH says, the only way to avoid them is to not ever update anything your mod relies on. The common wisdom I've gleaned even with the big name game engines is that you stick to the version of the engine and any middleware that you started the project with unless you have to update something, because otherwise you risk introducing all sorts of subtle bugs in parts of the game you're not paying attention to at the moment. And of any game I've modded, looked at modding, or consumed mods from, I can only think of one that even comes close to FSO in terms of developer care for trying to avoid compatibility breaks for modders and responsiveness when they do happen.
The only real alternative I can imagine is a basically dead engine development where at most a new version every five or six years keeps it running on modern systems, and I think that'd be a real shame.
I have seen some mods that seem to automatically change to the newest released mediaVps
Mods can be set up on knossos to do this, some surely are. And they shouldn't be, for hopefully now-obvious reasons.
-
I'm baffled as to why nobody mentioned the fact that yes, you can force a mod to use any FSO and MediaVPs version you want it to. The former can be done from the Knossos interface and the latter by modifying a couple values in the mod's mod.json file, I'm sure there's plenty of people around who would happily walk you through this simple proccess. Although I warn you: there is no compatibility or freedom from bugs guaranteed. In case of the FSO version, just because you might hit some novel bugs in newer nightlies.
In case of MVPS, it's because while the FSU team did try to attain maximum compatibility, at some point the packages needed a major refactoring and broke most of the mods that defaulted to the newest MediaVPs. Or at a different point in time, the MediaVPs added a couple magnificent weapon variants and subsequently players wanting to launch Blue Planet with the newest MVPS found themselves crashing on startup because the added variants together with all Blue Planet weapons jumped just that little bit over the weapon class limit.
So generally, I definitely want to encourage exploring mods' compatibility with newest MediaVPs - and preferably if everything is seemingly fine, reporting the fact to the mods' developers or whoever manages them on Knossos at given point in time - but beware that things can get more or less broken and don't be afraid to roll back (preferably reporting the bugs to aforementioned people too; helping locate the bugs is very important for mod makers too). Generally, the rule is that the more a mod resembles retail FS2 (less custom assets, scripts ect.), the more likely it is to cooperate well with newer FSO/MVPS.
Edit: Okay, I was wrong, Asteroth already mentioned it. Whatever.