Facepunch / garrysmod-issues

Garry's Mod issue tracker
143 stars 56 forks source link

Incorrect subscribed addon mount order after Dec 14 2023 #5664

Closed TiberiumFusion closed 9 months ago

TiberiumFusion commented 10 months ago

Time to add my entry to the list of unusual breakages caused by the latest ~gmod updates~ undisclosed Valve changes that coincided with the latest gmod updates (see final comment before closing).

Details

For at least the last four years (possibly ten), subscribed addons would always mount on the client in the order they were subscribed to. After the undisclosed Dec 14 2023 - Dec 19 2023 changes, this is no longer true.

Addons now mount in two different conflicting orders, depending on the realm.

This breaks some addons which must mount before other addons in order to work properly - previously achievable by subscribing to addons in a certain order.

Contrived Example

Let's say Addon 100 and Addon 999 each have some file at path `materials/common/texture.vtf" in their GMAs. Only one version of that file can be mounted. Which addon will prevail?

Before the recent gmod changes:

  1. Subscribe to Addon 999 first, then Addon 100 second
  2. Launch gmod, open console
  3. whereis materials/common/texture.vtf -> in Addon 999
  4. Start a game, wait for everything to load
  5. Open console, whereis materials/common/texture.vtf -> in Addon 999
  6. Resub to both addons in opposite order (100 first) and repeat. Now whereis reports Addon 100's file is being used.

After the recent gmod changes:

  1. Subscribe to Addon 999 first, then Addon 100 second
  2. Launch gmod, open console
  3. whereis materials/common/texture.vtf -> in Addon 999 (correct)
  4. Start a game, wait for everything to load
  5. Open console, whereis materials/common/texture.vtf -> in Addon 100 (different)
  6. Resub to both addons in opposite order (100 first) and repeat. whereis still reports Addon 100's file is being used.

Problem

I titled this issue "incorrect" subscribed addon order because 1) the menu realm gets it "right", which is 2) how gmod has worked for years, while 3) the client realm then inconsistently (re)mounts addons in a different order (why?), and 4) I see no reason why addons must load in UGC ID order instead of user subscription order.

There are legitimate cases where an addon must load before another in order to achieve some otherwise impossible goal. The demonstration above is perhaps the prime case - ensuring that if any file path is shared among addons, the user's preference decides which addon's version of the colliding file path will be loaded. Notably, this can be and is used to fix files in old abandoned addons and create/use extension points for/from other addons, particularly wrt assets (not code).

Lastly, I must preempt bringing up the elephant in the room, which is the lack of some kind of "mount priority" mechanism to more cleanly and clearly define addon mount order. This would sidestep the entire issue here, but odds are 1000 to 1 gmod will never receive such a thing. So it is really unfortunate that the only method (afaik) for controllable addon mount order is now broken.

Solution

I propose the change is reverted to the previous behavior, such that addons (re)mount in the client realm in the order they were subscribed to, just like on the menu.

While facepunch normally doesn't give a flying fuck about things like this, I'm hopeful that the new inconsistency they have created in mount order between the menu and client realms may be compelling enough to make them consider this issue.

robotboy655 commented 9 months ago

Possible duplicate of https://github.com/Facepunch/garrysmod-issues/issues/5663

I suspect Steam's new changes to Workshop, specifically their new Steam Workshop mounting order customization stuff is causing issues for you. image

There were no behavior changes from my end to Workshop mounting order. Addons are mounted in the exact order Steam gives them to the game. Maybe the only other issue I can think of affecting this is some addons would not mount at all because they contain files that are not allowed in addons.

TiberiumFusion commented 9 months ago

@robotboy655

I suspect Steam's new changes to Workshop .... is causing issues for you

Interesting.

But, this does not adequately explain the new two different load orders gmod now has.

The last time I played gmod before this changed was December 14 2023. On that day, gmod had one addon load order. In both the menu and client realms, addons loaded in subscription order. This was verified since I was using an addon that required this behavior to work.

Sometime between Dec 14 and Dec 24 this changed.

Now, gmod has two load orders. In the menu realm, addons mount in subscription order. In the client realm, addons mount in UGC ID order.

Why is this?

Addons are mounted in the exact order Steam gives them to the game.

If an upstream Steam change affected mount order in the client realm, why did it not affect the menu realm?

If you truly didn't make any changes to gmod in this timespan, then the only conclusion is that the Steam changes have revealed an inconsistency in gmod, i.e. there are two different code paths that load addons in two different ways. One was affected, one was not. This should be addressed. I believe the game should always load addons in the same order, regardless of realm.

is some addons would not mount at all because they contain files that are not allowed in addons.

This is not applicable to me. I am experiencing this issue with asset files, including .mdl, .vtf, and .vmt. These are not disallowed file types.

robotboy655 commented 9 months ago

Is that something you can actually reproduce? Actually show? Because it makes no sense to me, given that addons are not even remounted when starting a new game from the main menu.

This is not applicable to me. I am experiencing this issue with asset files, including .mdl, .vtf, and .vmt. These are not disallowed file types.

That's not what I mean. An addon (such as a gamemode) that contains those allowed types could've started to simply not load/mount because it also contained files that are not whitelisted. This means that your mount order for a specific file has in fact changed if a file existed in multiple addons for some reason.

TiberiumFusion commented 9 months ago

Is that something you can actually reproduce

Well, I just went through the hassle of setting up a reproducible test case + video for you, only to find out that the issue wont repro anymore. I suppose the only explanation is indeed some unknown count of upstream changes from Valve that were never disclosed to us end users. Thanks Valve.

I can assure you this was definitely broken on December 24th when I filed this issue. I spent a while investigating and confirming it before writing up the OP and the contrived example in said OP, which mirrored my test cases.

Had facepunch seen this issue sooner, then I could have given you a working demo. But holidays and all that obviously. After filing this issue, I did not test it again until you commented here yesterday, so evidently Valve created this problem before the 24th and then later fixed it sometime between the 24th and 4th.

So, to clarify...

This is not applicable to me. I am experiencing this issue with asset files, including .mdl, .vtf, and .vmt. These are not disallowed file types.

That's not what I mean. An addon (such as a gamemode) that contains those allowed types could've started to simply not load/mount because it also contained files that are not whitelisted. This means that your mount order for a specific file has in fact changed if a file existed in multiple addons for some reason.

The first test case I was using only included a single .mdl file. The second only included a single .vtf file. No other files were present in the addon, legal or not.