Jump to content

The indended usage of API version...?


Recommended Posts

So, I'm struggling to see the point of the mod API version, at least in it's current incarnation.

For example, currently, I am forced to update all of my mods to just bump up the API version even if there are zero other code changes necessary. This seems backwards. What even is the point of having to specify a single specific API version that a mod is compatible with? That doesn't even reflect how API changes work (assuming that most have some semblance of backwards-compatibility).

It seems like it'd be much more useful to both modders and users to implement a better API version compatibility specification system:

1. Remove the restriction on setting api_version in modinfo.lua to a number greater than the current API_VERSION. This would enable mods to specify that they are more than likely able to work with any future API_VERSION (as is the case for most mods; when is forwards-compatibility even an issue?). Alternatively (or additionally), allow a nil api_version to act as a "compatible with all future API versions" setting. Could also rename this to max_api_version.

2. Add a min_api_version setting to modinfo.lua. This is the only thing that truly matters, right? Like, for example, if I add config settings to my mod using the config settings system added in API_VERSION 6, then I'd need to specify that it's only compatible with API_VERSION >= 6.

Hopefully I'm not alone in this frustration. Assuming mods to be automatically incompatible with an incremented API version is totally unnecessary and requires more work on modders' end for zero added information on the users' end (actually negative added information, as it misinforms users by explicitly stating that there are incompatibilities when it's more likely that none exist).

Link to comment
Share on other sites

I fully agree, and I know @DeathDisciple does as well.

My main issue is with mods being labeled as "Out of date!" when the api version is bumped, and being freaking disabled automatically.

The automatic disabling of a mod after a crash is also far from helpful. If anything, it just makes it very likely for an user to botch a save due to losing all mod savedata when loading it again. If you're going to automatically disable a mod when it crashes, you might as well automatically uninstall the game when a non mod related crash happens. And the automatic disabling of all mods when a crash happens at game startup has the same issues.

Both cases of automatic mod disabling have a rationale behind them: preventing the game from crashing before the user is able to disable the mod, rendering the game unplayable (unless the user erases the modindex file manually from the save folder). But in my opinion this should be addressed by putting up an error screen the next the game loads, saying such mod caused a crash the last time and asking if the user would like to disable it (but advising against it); that way, if the user does in fact run into the rare situation of an endless crashfest, then it can click a button to disable the offending mod(s).

Link to comment
Share on other sites

Fully agree with everything that's been said here.

 

One more thing tho, not only you shouldn't autodisable mods on every possible opportunity, you should warn users before they load a save that was made with mods that are no longer active. Push a warning asking people to reenable the mods they made the save with, before they totally break their saves - like Oblivion/Skyrim/Torchlight, most other heavily modded games do, really. What are the chances that someone intended to keep the mod active but it got autodisabled, or whatever, loaded a save, then saw the mod was off, hit save&quit, reenable the mod just to find out his save is permanently broken by saving without mod active?

Link to comment
Share on other sites

I think between version 2 and 3 they actually added stuff you needed in modinfo.lua. Then in 3->4 I THINK they altered something about prefabs and how images were loaded. So in those cases it was entirely justified to up the API version (mods with earlier version likely wouldn't work). But now I'm looking at 5->6 and I can't imagine a scenario where a version 5 mod would be breaking in version 6. Yes, they did add the DLC/normal game flags, but that wasn't enough to break anything - they built it to allow not having those tags anyway.

 

If it's 100% backwards compatible, it doesn't need a new API version.

Link to comment
Share on other sites

If it's 100% backwards compatible, it doesn't need a new API version.

Well, if it worked like I suggested it should, the new API version would still be useful (with regards to a min_api_version setting).
Link to comment
Share on other sites

  • Developer

I can explain the reasons behind the API_VERSION implementation. The main goal of the API_VERSION is to let users know after an update which has significant chanages to the mod api, whether or not the mods they are using have been tested by the mod developer with the new api changes.  This was done because previous to this change, whenever there was significant changes to the mod api, we would get a flood of crash reports and support requests due to mods not working with the new update instead of those people going on the forums to talk to the mod developers. We needed a way for players to understand that their mods needed to be updated to work with the new API_VERSION. It's basically meant to inform the user whether the mod is expected to "work as intended" or if you're using it "at your own risk". 

 

While I agree that the current API_VERSION is a pain for mod developers, it has actually worked surprisingly well at getting users to go and talk to the mod creators whenever the API_VERSION gets updated. 

Link to comment
Share on other sites

While I agree that the current API_VERSION is a pain for mod developers, it has actually worked surprisingly well at getting users to go and talk to the mod creators whenever the API_VERSION gets updated.

Has it, though? My experience is that users either complain that the mod is out of date (possibly because the game claims that is the case) or outright assume the mod is broken, saying "doesn't work, game says 'out of date'" (when in fact it is working). This is especially frustrating when we're forced to keep a lower api version due to standalone being behind Steam, which happens during early access periods.

I'm not against warning the users the mod might not be compatible with the current state of the game, but claiming the mod is "out of date" is just misleading. "Might be out of date" would be a more proper description. And even then, this would only make sense when an api bump represented a severe break in backwards compatibility as some of the older bumps did; the latest api bumps had no real impact in backwards compatibility (only forward compatibility), so updating a mod just to change modinfo.lua is unnecessary plastic surgery.

I can explain the reasons behind the API_VERSION implementation.

I understand the reasons. It's the automatic disabling of mods that's the main issue.

Link to comment
Share on other sites

  • Developer

Has it, though? My experience is that users either complain that the mod is out of date (possibly because the game claims that is the case) or outright assume the mod is broken, saying "doesn't work, game says 'out of date'" (when in fact it is working). This is especially frustrating when we're forced to keep a lower api version due to standalone being behind Steam, which happens during early access periods.

I'm not against warning the users the mod might not be compatible with the current state of the game, but claiming the mod is "out of date" is just misleading. "Might be out of date" would be a more proper description. And even then, this would only make sense when an api bump represented a severe break in backwards compatibility as some of the older bumps did; the latest api bumps had no real impact in backwards compatibility (only forward compatibility), so updating a mod just to change modinfo.lua is unnecessary plastic surgery.

I understand the reasons. It's the automatic disabling of mods that's the main issue.

 

I totally agree, there are a lot of people who complain about their mods being out of date but it's still way less than the amount of people who used to complain about their game being broken. Basically the current implementation is less than ideal but it's still better than when there was no implementation. 

Link to comment
Share on other sites

When was the last time the API change actually broke most mods, last year? If you claim the purpose of it is to warn people of broken mods, then why are you bumping API version, when it does NOT have a chance of breaking mods? And aren't all mods 'use at your own risk' anyway?

 

You are scared that mods might crash their game, so you preemptively crash it just in case, all because you 'might' get an error report somewhere outside the mod forums.

 


While I agree that the current API_VERSION is a pain for mod developers, it has actually worked surprisingly well at getting users to go and talk to the mod creators whenever the API_VERSION gets updated. 

 

You're ruining the experience not of modders, but of people that are actually paying your bills. You know, the actual customers, there are way more of them than there are us. They are the people that will spread the word, make others buy it or run away screaming. How does it help your case that they're screaming at us, instead of you, if they end up giving up on the game because of broken games/saves you caused by trying to protect them?

 

Which we have already explained why and how is happening due to the current implementation.

 

I hope you've read just the title out of this whole thread... or I'm losing what's left of my faith in humanity.

Link to comment
Share on other sites

I'm starting to feel tehMugwump's pain...

I've written all of my mods with the specific intention of not needing to maintain them. If I have to change a single arbitrary number in one file of each mod every so often, then package them all and upload each of them to this forum, and then open the mod tools and update each mod on the workshop... ugh. I'm not going to keep doing that forever, and it's nonsensical to expect anyone to. You're effectively going to be obsoleting non-obsolete mods, and you've already done so with many mods that still work but are no longer being maintained.

Cheerio, what problems do you foresee with the implementation suggested in the OP? Surely it's on Klei to make sure that API version increments have backwards compatibility (which you do seem to do; let me remind you of this comment in health.lua that was added in the last patch):

    -- We don't always do this just for backwards compatibility sake. While unlikely, it's possible some modder was previously relying on    -- the fact that StartRegen didn't stop the existing task. If they want to continue using that behavior, they now just need to add    -- a "false" flag as the last parameter of their StartRegen call. Generally, we want to restart the task, though.
EDIT: If absolutely necessary, you could mark specific API versions as not backwards compatible, and enforce min_api_versions accordingly. API version 5 to 6 is not such a case.
Link to comment
Share on other sites

I've written all of my mods with the specific intention of not needing to maintain them. If I have to change a single arbitrary number in one file of each mod every so often, then package them all and upload each of them to this forum, and then open the mod tools and update each mod on the workshop... ugh. I'm not going to keep doing that forever, and it's nonsensical to expect anyone to. You're effectively going to be obsoleting non-obsolete mods, and you've already done so with many mods that still work but are no longer being maintained.

I feel the same way.

Cheerio, what problems do you foresee with the implementation suggested in the OP?

The problem is probably that it's likely too late for this kind of change. The mod API (and how the game implements and interacts with it) might still receive incremental changes, but I doubt it'll be reformed.

Link to comment
Share on other sites

Auto disabling mods with wrong api number is annoying, also people lose  modded items and structures upon loading save file if they don't notice the mods were disabled, and if they don't use alt + f4 all stuff is gone forever.

Link to comment
Share on other sites

  • Developer
Hey everyone. As always, we appreciate the feedback. Here are my thoughts on the issues brought up here. Sorry for the wall of text.

 

First off, I'm guessing that this thread exists because we increased the API_VERSION from 5 to 6 with the latest patch. In that patch, we added a bunch of functionality to give modders more tools in their toolbox but nothing fundamentally changed about the mod API that was present prior to the patch. It was almost entirely additive changes. That's all well and good. However, we made another change that is actually incredibly important, even if it doesn't change anything about the guts of the mod or how the mod code is written. Specifically, that change is the new dont_starve_compatible and reign_of_giants_compatible flags that modinfo.lua should now have. It's true that if we had not increased the API_VERSION, mods would almost definitely continue to function exactly as they had before the patch. But, as you've all advocated, it's ultimately about the mod user's quality of experience. These new flags are an essential part of that. Mods may continue to work without them, but the new flags are an important and powerful way for you, the modders, to make your users' experiences as seamless as possible, regardless of what mode they're playing.

 

I posted about that change on the forums and added a link to the post in the stickied modding guides thread. The thing is, not every modder or mod user is on the forums. In light of that, I made a decision to increase the API_VERSION as a way to signal to mod users and modders that something important had been added and deserved attention. It's rudimentary, but it's the best we've got. There's definitely an argument to be made that the variable API_VERSION is poorly named (or at least it has become poorly named), but changing it at this point would do more damage than good. Don't Starve, along with its mod system, has always been a "living" product: if the mod maker isn't supporting their mod anymore, then the API_VERSION isn't even a factor in the conversation, in my opinion. There is no such thing as a future-proof in this context. That applies to both mods and internal files of the game.

 

The last time that we increased the API_VERSION was when Reign of Giants first launched. As I'm sure you'll recall, there were plenty of issues with mods that cropped up around then. We increased the API_VERSION as a reaction to the flood of crash reports we were receiving. API_VERSION 5 is sort of a weird case because we didn't change anything about the mod API itself, but we fundamentally changed the nature of Don't Starve (i.e. there were now two different modes that had various things that were coded in different ways between the modes and would require special handling). This was, just as with API_VERSION 6, our way to signal to modders that something important had changed and might need attention. In an ideal world, the compatibility flags and associated functionality would have been a part of API_VERSION 5 and we wouldn't have felt a need to increase it for 6 (since the patch would have then just included the additive stuff I talked about above). But, with limited resources (i.e. actual humans to work on this stuff), we didn't have time to do that, so here we are.

 

So, that's the long and short of how and why we got to where we are. I'd like to address some of your other concerns as well. I fully sympathize with the frustration caused by having to update API_VERSION numbers on your mods, but let's keep in mind for the sake of this discussion that there are two main purposes of API_VERSION. First, it lets modders know if there has been some significant or important change that affects mods. Second, it lets mod users know if the modder has checked that their mod still functions as desired after those changes. It's also important not to conflate "out of date" with "incompatible". It's possible our messaging on that isn't the clearest it could be, but I don't think we ever say that an out of date mod won't work, just that it might not because the modder hasn't said that it does yet (by updating the mod and API_VERSION). If you folks have ideas on how to improve that messaging, I'm all ears (and no, I don't think "might be out of date" communicates any different information than "out of date"). I'll think on how we can rephrase it myself, too.

 

I don't think that allowing for a way to set a mod to be compatible with future API versions is actually viable. As I said above, there isn't really any such thing as future proof (alternatively, forwards compatibility). Neither developers nor modders can predict what will change. As a user, I'd be pretty confused if I had a mod that claimed to be up to date but strictly wasn't (and was crashing or exhibiting other bad behavior because of that). All told, that situation with an unmaintained mod is worse for more people than having a mod listed as out of date but still able to be turned on. As for the min_api_version, I don't really see the use case there. As far as I'm aware, there's no way to get older versions of the game (and thus the mod API) through normal channels. Because of that, adding a min_api_version doesn't seem functionally different from allowing forwards compatibility as discussed above. If I'm not understanding fully, please do correct me.

 

@squeek pulled out a comment I wrote in health.lua when talking about backwards compatibility. We aren't in the business of explicitly making the game or its mod support backwards compatible (see previous point about not having a way to get old versions through any normal channels). Given our team size, down that road lies madness. That said, we do try to avoid breakings things where possible. The comment in question was one instance where I saw an opportunity to provide backwards compatibility in a situation where the fundamental behavior of a functional call was changing. It took me less than 100 characters (not including the comment itself) to do so, so I did it. Please take that bit of code and the associated comment in health.lua as the exception, not the rule.

 

As for the automatic disabling of mods when API_VERSION is increased or a mod crashes: sure, it can be annoying. We could argue about whether the automatic disabling makes sense for the user until the cows come home, but doing so seems pointless. Ultimately, we made the decision to disable mods when they become out of date or crash because it leads to the most stable application, overall. And with the API_VERSION increase case: it doesn't diminish the fact that it can be a bother, but it does happen pretty infrequently--on average, once every few months. Further, I don't currently anticipate it changing again, with the possible exception of Don't Starve Together's launch (though we haven't really examined how mods are going to work in a multiplayer context, so that might end up being another discussion entirely).

 

Now, let's examine the actual problem that arises from this. It's not that mods get disabled, but that doing so can lead to broken saves. The way to fix this is not to change the behavior of disabling the mods but to display a modal warning when loading into a game with mods disabled that were previously enabled in that save game. Doing so should be relatively easy and I fully agree that it's important. I'm looking into adding that.

 

There's actually another more insidious issue wrapped up in this that is harder to solve: the mod enabled/disabled screens that show when the game starts up is just noise. People almost definitely are not reading it closely, especially since a mods-related screen appears every time the game is launched for a user who uses mods actively. It's a wall of text that gets clicked through on auto-pilot without any consideration for the information being shown. Adding "Keep Mods Enabled" and "Disable Mods" buttons to the mods-have-been-disabled screen doesn't do any good if the user isn't engaging with the screen. Because of that, I'm going to see if there are easy ways to clean to screen up or make it more obvious when it's a "hey, just so you know, mods are installed" screen vs. a "mods had an issue and we need you to make a decision" screen. If the user is clicking through the latter screen on auto-pilot, they can still easily end up stuck in a loop of a game that won't run properly without knowing why or how to break out. Yes, hypothetically they would realize it and eventually click the disable mods button, but if they've launched the game several times, clicked through the screen, and crashed, we've already failed. We'll see what I can come up with--I'd definitely like to let users choose to not disable the mods, but unless that choice is presented clearly, it's a bad user experience to have the choice.

 

 


TL;DR

 

[Responses]

- The recent API_VERSION increases weren't done in the best way. We had specific reasons for doing it the way we did. Ultimately, it's how it happened and there's not much use on dwelling on it.

- API_VERSION serves to let users know that the modder hasn't said their mod is guaranteed to work, but it still may. It also serves to let modders know when significant or important changes have happened.

- I don't anticipate increasing API_VERSION again, with the possible exception of when Don't Starve Together launches.

- We don't explicitly make the game or the mod API backwards compatible, since there is no way to get older versions through normal channels. Sometimes we do, but that's the exception not the rule.

- I don't think you can legitimately say that any mod or game code is forwards compatible.

 

[The Good Stuff]

- I'm planning on adding a modal warning when loading into a save game that previously had mods being used that are currently disabled. As far as I see it, this is the actual problem, not the fact that the mods are getting disabled (because it leads to broken saves).

- If we do allow users to keep crashed mods enabled on startup, the screen will need some reworking to communicate better what's going on. I'm looking into that as well.


 

I know that the mods situation surrounding Reign of Giants' roll out has been a little rocky, but we're addressing things as we can. I hope that clears things up.

Link to comment
Share on other sites

(and no, I don't think "might be out of date" communicates any different information than "out of date"). I'll think on how we can rephrase it myself, too.

I don't think saying mods might be out of date is the ideal phrase for it, but the change in tone if far from trivial. It should still make users check with the modder in case issues arise, suggesting this as a possible cause, while not outright claiming the mod is obsolete, suggesting is should cause issues even if the user has no other reason to believe that (and this is certainly a common scenario).

I hope you can find a proper phrasing, but "Out of date!" doesn't cut it.

As for the min_api_version, I don't really see the use case there. As far as I'm aware, there's no way to get older versions of the game (and thus the mod API) through normal channels. Because of that, adding a min_api_version doesn't seem functionally different from allowing forwards compatibility as discussed above. If I'm not understanding fully, please do correct me.

The main reason for that, as I see it, is that while mod api bumps are infrequent, the discrepancy between standalone's and Steam's mod api tends to last for a long time. And throughout all that time, we're forced to keep the "Out of date!" message in Steam, by keeping the mod api at the lower iteration, simply because otherwise it'd be standalone which would refuse to load it, due to it being "in the future". I don't particularly think specifying a minimum api version is all that relevant, but being able to specify more than one is, due to this scenario.

Now, let's examine the actual problem that arises from this. It's not that mods get disabled, but that doing so can lead to broken saves. The way to fix this is not to change the behavior of disabling the mods but to display a modal warning when loading into a game with mods disabled that were previously enabled in that save game. Doing so should be relatively easy and I fully agree that it's important. I'm looking into adding that.

There's actually another more insidious issue wrapped up in this that is harder to solve: the mod enabled/disabled screens that show when the game starts up is just noise. People almost definitely are not reading it closely, especially since a mods-related screen appears every time the game is launched for a user who uses mods actively. It's a wall of text that gets clicked through on auto-pilot without any consideration for the information being shown.

The major issue is certainly the automatic disabling, which I do believe should be handled via a modal warning when the player attemps to load a save no longer using one of the mods present in it the last time it was loaded. In fact, I implemented this in Up and Away a couple months ago:

y5N9WGt.jpg

This screen is presented when the player attemps to load a save without U&A enabled, while it had been enabled the last time that save was played (don't ask me how I managed to run code without the mod being enabled, the technique is far from clean, only justifiable by the severe save breakage triggered by the alternative; a game supported alternative would be much preferable). This screen is presented before savedata is actually loaded. If the player clicks on "Enable UA", Up and Away is automatically enabled and the save loading resumes (if U&A was uninstalled, this button does not appear). If the player clicks on "Main Menu", the save loading is halted and execution returns to the main menu. "Ignore" proceeds to load the save without U&A enabled. I think something like this, but supported directly by the game, would be the ideal.

But even though the automatic disabling is the major issue, I believe the game should prompt the user for mod disabling (preferably on a per mod basis, presented as a list of spinners defaulting to "Keep enabled") when the mod api updates. Many users don't pay attention to the Mods warning screen, that much is clear (No Warning wouldn't have 11k subscribers otherwise; and No Warning's modinfo.lua still lists api_version 4, by the way, since I wouldn't update a mod without having new features to justify it). But this could be solved by either having the mod disabling prompt have a different background colour or simply removing the mod warning screen (replacing it with a main screen widget which automatically vanishes after a couple seconds, or some other non-intrusive, non-modal notification). Maybe both.

Link to comment
Share on other sites

SethR, your logic for increasing API_VERSION to 6 does not hold in this case. The dont_starve_compatible and reign_of_giants_compatible flags in modinfo.lua were not made required, so forcing modders to update a completely separate and not-at-all-related variable does nothing to draw attention to those added flags. In fact, it definitely worked in the opposite direction for me; I completely forgot about adding in the new flags when updating two of my mods because the only thing that truly mattered was that I updated the api_version variable.

You're right that API_VERSION is misnamed or misused at this point. The way I see it, it should only be incremented when non-backwards-compatible changes are made to the game code and/or mod API that will for sure break a huge number of mods (like, for example, the patch a while ago that completely refactored the screen/widget stuff). I'm in favor of not increasing API version unless absolutely necessary.

Another thing that used to help were the public previews so that we could make the necessary changes in advance and have a mod update ready for when the patch hit, but we don't seem to get those anymore. This makes an updated API_VERSION even worse; we don't even have a chance to properly keep up.

Link to comment
Share on other sites

First of all, thanks for finding the time to follow up on this, it is appreciated. Whomever dies on the wall of text likely deserved his fate.

 

 

 

It's also important not to conflate "out of date" with "incompatible". It's possible our messaging on that isn't the clearest it could be, but I don't think we ever say that an out of date mod won't work, just that it might not because the modder hasn't said that it does yet (by updating the mod and API_VERSION). If you folks have ideas on how to improve that messaging, I'm all ears (and no, I don't think "might be out of date" communicates any different information than "out of date"). I'll think on how we can rephrase it myself, too.

 

 

I don't know, myself, but that is a very big issue. Most of the time I will not hear 'hey go check there's a new api version', I will hear 'wah this !@#$ isn't working', especially after force disabling. People see some red signs somewhere saying something and assume it's crashed and modder disappeared and it's no longer maintained etc... we can't react the very second you push the patch, and we likely don't even know we will have to before it happens.

 

 

 

Now, let's examine the actual problem that arises from this. It's not that mods get disabled, but that doing so can lead to broken saves. The way to fix this is not to change the behavior of disabling the mods but to display a modal warning when loading into a game with mods disabled that were previously enabled in that save game. Doing so should be relatively easy and I fully agree that it's important. I'm looking into adding that.

 

 

If you're dead set on it... well I'll get what I can. I'll say 'people still won't read and they're gonna click continue and break their saves'. Then you'll say 'otherwise they wouldn't read the mod that crashed the game, click through and get into infinite crash cycle'. The only right way is to fix the human brain, I guess we'll have to agree to disagree on what should be the default behavior.

 

Having a properly presented warning on load time is still MILES ahead of what we have right now, so as long as that happens, and is presented in a proper way, actually making it clear to people what's going on, that'll have to do.

But yeah, core of the issue is communication. I've had enough 'fake alert' bugs and crashes caused by mods that are not being updated for 8 months etc. That is a problem. But we also have a tight time window between your mod api update and the time we start losing users due to a number change which is... more than unnerving. Hopefully you will find a way to make it clear what's going on.

 

And please, pretty please, for the love of all that's unholy, do not repeat the story of ROG steam-exclusive API_VERSION higher than standalone when DST starts...

Link to comment
Share on other sites

  • Developer

SethR, your logic for increasing API_VERSION to 6 does not hold in this case. The dont_starve_compatible and reign_of_giants_compatible flags in modinfo.lua were not made required, so forcing modders to update a completely separate and not-at-all-related variable does nothing to draw attention to those added flags. In fact, it definitely worked in the opposite direction for me; I completely forgot about adding in the new flags when updating two of my mods because the only thing that truly mattered was that I updated the api_version variable.

 

If we'd made them required, then mods would have been completely unusable until updated and we would be having a different discussion. I chose to make them optional so that mods that aren't still being maintained can still be used, in the event that they still work as desired. In any case, a warning gets printed to the log if the flags aren't set (we do this specifically because we strongly want any currently maintained and all future mods to leverage these flags). Like I said, the tools we have are rudimentary. Even if something had been completely rewritten and could actually break mods, changing the API_VERSION doesn't tell the modder anything about that: all I can do from my end is up the API_VERSION and write a post about what's been changed and hope for the best.

 

Just wanted to respond briefly to that. I'm listening to the rest of what you folks are responding with, but just as a heads up, I probably won't respond in-depth again unless something demands it.

Link to comment
Share on other sites

If we'd made them required, then mods would have been completely unusable until updated and we would be having a different discussion.

I wasn't saying that I think the compatibility flags should have been made required; the implementation of the flags is perfectly acceptable. I was simply saying that your reasoning for the increasing the API version to 6 should not be used in the future as it does not have the effect you intended (drawing attention to backwards-compatible changes or any other changes that don't inherently require modders' attention on their own).
Link to comment
Share on other sites

- I'm planning on adding a modal warning when loading into a save game that previously had mods being used that are currently disabled. As far as I see it, this is the actual problem, not the fact that the mods are getting disabled (because it leads to broken saves).

 

 

Thats good news, but why can't game run test on mods with wrong api number, simple prefab loading test, and if not crashes on test keep it enabled.

 

Link to comment
Share on other sites

Thats good news, but why can't game run test on mods with wrong api number, simple prefab loading test, and if not crashes on test keep it enabled.

This would hardly detect all but the most trivial issues. I don't think mods should be automatically disabled, but I'd rather have mods be disabled than misinform the user a mod is working fine (by running a very simplistic test) when it isn't...

Link to comment
Share on other sites

This would hardly detect all but the most trivial issues. I don't think mods should be automatically disabled, but I'd rather have mods be disabled than misinform the user a mod is working fine (by running a very simplistic test) when it isn't...

 

Most mods are simple prefab post inits, or new item prefabs that use some of the game components, they will work till the end of time, or to the time they change whole component, so far that never happened.

 

I get flamed by mod users cuase game says mod is out of date, they don't care to check if it works, its simply out of date for them, and it works fine, but game is force disabling it anyway.

I wouldn't mind it that much, but users are horrible and demanding, no "please update" just "UPDATE".

 

Link to comment
Share on other sites

Heck, I still get people asking if my mods are updated, even when I type out the patch name and the date the mod was last updated. It's the new no-effort generation, I guess.

 

I was considering another option, which would be more like a website where modders could go and quickly click a checkbox for if mod version X is updated for game version Y. The game would start by checking this website for info, and then if no info found would fall back to what the devs discussed so far in the thread.

 

Of my 4 mods, 3 required no changes except altering API info last patch. I agree that it's pretty annoying to have to change the number, rar, upload to steam, upload to here, type in "changelog" for such stuff.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...