Following up the discussion from this thread: https://forums.uberent.com/threads/release-build-73737.65045/#post-1016352 My priority is to not break what Uber releases. After seeing so many broken mods in PAMM I believe that all mods should be disabled on new builds until the authors can regression test AND that it is the responsibility of mod authors to make sure that there are no broken mods in PAMM... ever. When you have to copy sections of Uber code to patch a couple of lines then build version checks are the only way to not break new releases. Uber can help with a workflow that allows mod authors to test on new releases similar to what happens now with PTE builds.
imho it is the users responsibility to test without mods if they should encounter issues after patches.
I agree all users should test without mods and that needs to be clear in PAMM. It doesn't change my opinion about the responsibility of mod authors to regression test, not break Uber releases and to keep PAMM clean of broken mods.
Mods don't actually break that often, and when they do, it's usually specific ones rather than a sweeping change that breaks everything. Requiring mod authors to submit a change every single build to allow it to be used is just going to kill off a lot of casual modders.
I still think there is some responsibility for mod authors to avoid breaking Uber releases especially while the game is under very active development. It would be great if PAMM showed the following: incompatible mods that break the current build experimental mods that might break broken mods awaiting a fix broken mods no longer under active development My distinction is incompatible mods break the release vs broken mods just don't work. Mod authors should be able to flag and clear issues without resubmitting especially for those with auto updating mods. The community should be able to flag incompatible and broken mods via counters that are reset after each update or are cleared by the author for auto updating mods. Casual modders also need some guidelines on how to avoid issues. If you're patching Uber code and modifying handlers that would break an Uber release then you should consider checking build versions and disabling your mod until it can be regression tested. PTE builds normally allow just enough time to regression test and fix any incompatibilities. eg patching the setup function in connect_to_game.js is high risk and it needed a build version check. Without a build version check the Faster Server Browser mod would have killed creating local offline games due to the following code change: Code: // Local servers are not currently started by this screen if (local) { start = false; self.gameHostname('localhost'); self.gamePort(6543); } was changed to: self.isLocalGame(local); There is some responsibility associated with having a popular or promoted mod.
I agree that mods that actively copy paste large chunks of Uber code to fix a single line should be marked as "CAREFUL THIS BREAKS NEXT PATCH". Though only very few mods need to do that. In running PA Stats over the course of more than 1 year I've so far had a single case where I actually somewhat killed the game completely for a few hours if the mod was enabled. That was not after a patch, but after I pushed an update that, ironically, was trying to detect the used build and load different versions of the mod. It turns out loading different versions of the mod isn't trivial at all for the start.js scene and easily makes people unable to do anything in that scene. Apart from that the majority of patches did not break anything at all. Some patches broke reporting, or reported broken data, but even then PA Stats is written in a way that basically reduces the issues to a lot of red stuff in the console with no further effect on the game. I've been there, trying to do version detection. I've burnt my hands with it. I currently have a "no-op" version of PA Stats on my server though. So if the next patch really should break hard with PA Stats I can make that version the active one, effectively deactivating the mod. I've not needed that no-op mod so far. For mods that are normally downloaded from pamm there is very little a mod author can do. Disabling the mod on every patch is highly unreasonable. Too many small patches. Unless you patch Uber code as you described you're better off not disabling it.
We can't track every single build, it's too much work and it ask us, modders, too much reactivity. As a modder, the best thing you can do is to avoid copypasta as much as possible. Better have little mods than a big one messing up with everything. For example, "Faster Server Browser" should only have hooked the engine api to override the call to "ubernet.getCurrentGames", there was already mods to show the starting planets, and to come back to the browser on failed connection (but I think this one is broken).
When I first looked at mods on PAMM my first impressions were not great. Lots of mods I tried were broken... others were incompatible and broke the game. eg some were just broken due to Uber changes, some were based on the floating framework, some failed due to issues with settings (or the settings framework), others broke the game like the reconnect mod with galactic warfare. It was painful having to test mods then open up forums and read through pages to find out the status of each mod, pending fixes and if it was still being actively maintained. Maybe I was unlucky and it's better now. Lots of small possibly broken mods can be like death by a thousand paper cuts. At some point modding and PAMM have to evolve to the next level where players don't have to be testers and developers
The marking of the version a mod was build for could be more dominant for out dated mods. A mod build for a version 6XXXX is most likely gonna break everything for example.
the mod that sets the batchsize to 100 instead of 5 will be 1 year old soon. But if a mod is marked as "written for a version 5 month ago" the user should at least know what they are getting in to. A feature in pamm that allows users to mark "I had successw with this mod in version X" would be helpful I guess.
