Consider a FAF lobby with an earlier verison for mods.

[Goldy3]

I ask because 90% of the mods on FAF don't work. Now if your to ask "Why not use blackops, Why not use Diamond" well because there's something going on with those FAF versions that also f*** things up. For instance. I had the following mods activated for Diamond

-Blackops Unleashed ver.8
-Blackops Patch ver. 1.2 ver 12
-Blackops Naval Rebalance v2
-Blackops Adv Commander Units ver.11
-Blackops Alternate reality v3
-Blackops Global Icon Support v5 <------This one really fucks everything up cos' of recent patching.
-Auto Adjust Netlag (beta) ver0.3 v1
-Tracking MMLS v2
-Total Mayhem v1.20
-wall fix
-rks explosions v8
-UI lagfix v1
-graphic enhancement mod v1.1
-Cliff Hanger v1
-More Unit Data UI mod.

But using Diamond UEF couldn't build any Tier 1 factories. The factory was just a sqaure thing. Same problem with blackops. But that's a lot of mods isn't it? 15 to be exact + more if I so choose. Would it surprise you to know that they all worked PERFECTLY with very minor fuss (HP UI glitching out ex: Commanders reading 4k hp on their unit palette that they actually didn't have in reality but that's all) using an earlier version of FAF lobby that didn't ruin 90% of them?

I don't know which version of FAF that broke all the mods but could the community leaders consider releasing an earlier version of FAF that had the nice features (1500 increase in unit cap example) but didn't break all the mods?

[The Mak]

I really hope they implement your idea. I think it was v3640 where all the mods still functioned. I did not update one of my computers and I have all my mods still working. I play mostly against the AI due to traveling for work, but when I do get a chance to play on FAF having those mods is a blast. Now I have to watch every update on a virtual machine and see what has broken before applying it to my computers.

I do not understand why they had to make the mods incompatible. Looking over at the changes on the GitHub site, which btw, is more tedious then when Ze_Pilot was using bitbucket, I see some questionable changes; specifically renaming functions because capitalization and removing functions because they are not used. That, to me, sets some bad precedents. What if in the future someone comes along and says, I do not like how this is spelled. Then we are back in this mess again, for no good reason.

If you do not like how a function appears, just add a new function that does the same thing as the other function and now you have both. Place somewhere, "These are the changes and here are the reasons." You create a document outlining the old functions that were changed so at least there is something to help modders out to modify their code. Right now it reeks of, "Do it this way because I said it is better."

This whole patch process has not been communicated properly. On the GitHub site it is difficult to see sometimes why things had changed. If you try to look at a files history of changes you get all the files that were changed at the time, which makes it tedious for no reason. The bitbucket site was good for that. You can look at a single file and see the history of changes that were done. The documentation there is not so good in general.

[Lionhardt]

I have also observed that using certain mods (e. g. UI lagfix) will render all other UI mods dysfunctional since one of the last patches.

[Ze_PilOt]

I really hope they implement your idea. I think it was v3640 where all the mods still functioned. I did not update one of my computers and I have all my mods still working. I play mostly against the AI due to traveling for work, but when I do get a chance to play on FAF having those mods is a blast. Now I have to watch every update on a virtual machine and see what has broken before applying it to my computers.

I do not understand why they had to make the mods incompatible. Looking over at the changes on the GitHub site, which btw, is more tedious then when Ze_Pilot was using bitbucket, I see some questionable changes; specifically renaming functions because capitalization and removing functions because they are not used. That, to me, sets some bad precedents. What if in the future someone comes along and says, I do not like how this is spelled. Then we are back in this mess again, for no good reason.

If you do not like how a function appears, just add a new function that does the same thing as the other function and now you have both. Place somewhere, "These are the changes and here are the reasons." You create a document outlining the old functions that were changed so at least there is something to help modders out to modify their code. Right now it reeks of, "Do it this way because I said it is better."

This whole patch process has not been communicated properly. On the GitHub site it is difficult to see sometimes why things had changed. If you try to look at a files history of changes you get all the files that were changed at the time, which makes it tedious for no reason. The bitbucket site was good for that. You can look at a single file and see the history of changes that were done. The documentation there is not so good in general.

This is also why the patch process was slower (is it really faster now?). I was making sure that everything was compatible with all FAF options (ie. all mods). Diamond mod was locked to a specific FAF version (did not received any patch), so I don't even understand why it's broken now.

Renaming function to maintain a good nomenclature is good.
But it's only when you are writing the code in the first place. Not after 10 years of people building code over these functions.

Also removing code because it's not used is good, unless it's used somewhere else. And given the amount of mods for FA, you can't be 100% sure it's never used. So don't fucking touch it. It won't make FA run faster if the code is never called.
If the files are huge because of useless code : Split them ! Comment the code you think is useless as "Obselete" so modder stops using them. But never remove them unless you really want to break compatibility (why would you ?).

Also a code must be modified for only one reason : making the program better.
Changing how functions are called doesn't make FA better for the user. For the programmers, it doesn't change anything unless you have some huge OCD. On the other hand, it breaks lot of mods. This is bad coding design/decision.

Since it's now community driven (lol?), you can petition to revert these changes and bring mod compatibility back.

[Blodir]

ITT more salt than in Don Juan Pond

[ckitching]

As far as I know, there is a plan to start having a longer open beta period for new releases to give mod authors additional time to fix their shit.

Thus far, we've not really been fixing people's mods for them: we'd never really get time to make much progress with FAF if we had to do that at the moment, though it would be notionally nice at some point.

I do not understand why they had to make the mods incompatible.

Nobody set out to "make the mods incompatible". Indeed, 3641 had a (perhaps somewhat too short) beta period for mod developers to fix their shit, in which basically nobody got in touch to ask for information about how the changes affect them.

I see some questionable changes; specifically renaming functions because capitalization and removing functions because they are not used. That, to me, sets some bad precedents. What if in the future someone comes along and says, I do not like how this is spelled. Then we are back in this mess again, for no good reason.

By and large, these are not the changes that are causing mods to break (there are a few cases where they are, however, but these represent somebody fucking up).
I've got a local copy of the mod vault I scan for uses of a certain function before refactoring in this way: if it is still used it gets a deprecation warning instead of deletion. If it turns out to not be used, deleting it now is an effective way to make sure it stays that way.

In general, simpler, clearer programs are easier to maintain: an oft-undervalued property of software. While changes like renaming may seem "pointless", they can meaningfully impact legibility of a complicated piece of logic elsewhere that makes use of the renamed function, which can in turn make an error easier to spot (or to avoid introducing when trying to modify behaviour).
Usually, given a choice between "there's a chance an obscure mod might depend on this" and "this makes it easier to prevent regressions", the latter is going to win.

On the other hand, where things do get completely overhauled (such as the new UI library introduced with 3640), they also get in-tree luadocs and the promise of a stable API for modders to use in the future. Introducing the UI updates to the lobby and elsewhere that we did that that point without the new UI library wouldn't have been viable, and for the same reasons modders will find it easier to do their thing with it than the old way: it just slightly breaks parts of the old way.

On the GitHub site it is difficult to see sometimes why things had changed. If you try to look at a files history of changes you get all the files that were changed at the time, which makes it tedious for no reason. The bitbucket site was good for that. You can look at a single file and see the history of changes that were done. The documentation there is not so good in general.

There's a big shiny "history" button at the top right when you're viewing the content of a file that takes you to a page like this showing only the commits that have touched that file (allowing you to view changes, the commit, or browse the file/repository at that point in its history):
https://github.com/FAForever/fa/commits ... m/Unit.lua

GitHub/Bitbucket have feature-parity.

[ckitching]

I should also just add that this problem is going away permanently in the next few months anyway. The new patching system will allow mods to specify a range of versions of other mods they are compatible with, including FAF. At which point it will entirely stop mattering how much mod compatability we break in future versions, as older mods will just continue to use older faf.

[justmakenewgame]

there is a plan to start having a longer open beta period for new releases to give mod authors additional time to fix their shit.

again. the dont fix anything during that period. May be they plan... but they release new version after new FAF patch release.

So: FAF test period -> announcing final version of patch -> mod test period (2 days) -> release.

The new patching system will allow mods to specify a range of versions of other mods they are compatible with

so what if they switch mod to a new version, then it does not work. Can they switch back? Do i need to update mod to get proper specifications? Cuz mods are not autoupdated(why?)

[Col_Walter_Kurtz]

It doesn't sound ideal at all, that mods will force the use of an older FAF version. Unless I'm misunderstanding something it means that as soon as you get used to new balance changes utilizing a certain mod would suddenly force the old situation?

[Sheeo]

It doesn't sound ideal at all, that mods will force the use of an older FAF version. Unless I'm misunderstanding something it means that as soon as you get used to new balance changes utilizing a certain mod would suddenly force the old situation?

Anyone playing with game mods like what we're talking about here, which significantly change the balance, will most likely not care about playing with the most recent balance changes.

Blackops for instance, is based around old FA balance values -- 3599 or 3603. It's entirely 'broken' in terms of balance if you just naively play it with current FAF anyway.