Interior proxy ordering overrides don't always work

FiveM Discussion Bug reports
1

I was looking more into this recently, but couldn’t find much information on following, so I hope you could explain a bit more, if possible:

deterministic ordering is not even needed anymore in newer client versions

What does that mean? And also I read somewhere in different thread that this automatization didn’t work out in the end? So I suppose we should still stick to making those interior proxies after all? I’m still unsure (probably how many of us here) what the value ‘startFrom’ is actually for.

And not all MLOs have interior proxies. Why not? What’s the difference?

2

Incorrect. There might’ve however been some edge case where the order-independent logic didn’t work but there wasn’t any conclusive report at any point in time so this is really difficult to actually say.

Also, there’s no ‘automatization’ whatever that means, the patch regarding this (fivem/NetInteriorLocationHacks.cpp at 965cbc7ddbdc73851fa922c79d2e4e5465dc9d18 · citizenfx/fivem · GitHub) makes the synced data use a hash of the interior rather than a zero-based global index, yet somehow people interpret this as ‘generating interior proxies automatically’ likely because they do not understand what this file does in the first place.

The ‘interiorproxies.meta’ file is not a file defining ‘interior proxies’ (as these are defined merely by having an interior instance in a map file), it is a file defining the order of interior proxies, because some places in the game save/send this as an index and not as a hash/name, and without an order override these offsets may differ between DLC/addon asset configurations.

As above, the patched logic replaces the serialization code here to send a hash of the interior and not an unpredictable index.

This also answers the following question:

… it’s where the specific file’s list of order overrides starts. This is extremely easy to get wrong and therefore people cargo-culting variants of this as a fix rather than providing conclusive actionable reports for the deterministic logic (and then also removing any leftover override files, as those may in fact cause the same issue anyway if they accidentally overlap) are somewhat acting counterproductively.

1 Like
3

Incorrect. There might’ve however been some edge case where the order-independent logic didn’t work but there wasn’t any conclusive report at any point in time so this is really difficult to actually say.

Well, I’m happy to hear that! Meaning it seems to be working in most of cases after all. If I happen to ran across this, I’ll make sure to point out any useful repro.

I listed it all interiorproxies and their values in this viewable link and this editable one, in case anyone would feel like adding some new information/discovery there.

But 2 instances made me scratch my head. First is that the order of startFrom value doesn’t match up to order of loaded DLCs in 2 cases. Bikers and Import & export DLCs are switched in this order. And to top it off, one interiorproxy files has no content whatsoever, but the next file in line starts with one extra value added. Highlighted as 0 contents with a question mark inside the sheet I posted above.

… it’s where the specific file’s list of order overrides starts. This is extremely easy to get wrong and therefore people cargo-culting variants of this as a fix rather than providing conclusive actionable reports for the deterministic logic (and then also removing any leftover override files, as those may in fact cause the same issue anyway if they accidentally overlap) are somewhat acting counterproductively.

So, roughly speaking, what’s the best course of action here? Having only one interiorproxies.meta file for all addon MLOs (to ensure everyone gets their hash value), with startFrom value… Higher than the last, official DLC, to avoid any possible conflict?

I appreciate your time trying to explain this to me/others in here.

4

Not having any override file at all, and reporting any issues caused by this in a way that it can at least somewhat be replicated (even if by joining an example server).

1 Like
5

So, if that would be of any help, you can join a test server I set up. I’ll leave it on for a few days (I’m happy to assist on this further if you want me to). It’s a basically only custom map, with a few addon interiors through out and all of them have this disappearing issue.

No interiorproxies.meta anywhere inside this server.

Note that, strangely enough, Benny’s replacement on original map didn’t have this issue. When used on a custom map at several location alongside the freeway, this issue became a thing.

Also another custom mechanic shop that didn’t have this issue on original map has this disappearing issue now in a new placement. Quite confusing to me here even further, because in this case, it’s literally only about repositioning an addon interior that wasn’t even replacing anything originally where it was. Seems almost like just placing it elsewhere broken something.

Or what do I know. People have this issue on original map as well, right? I remember we bought one interior back in the day, it was about 3 years ago maybe. I had no ideas about doing anything 3D, so I though “ok, it’s a vanilla garage interior, but on a new placement and with garage door/no teleport requirement”. And it had this disappearing issue as well.

Now I realized I disabled certain ymaps, including MLOs with RemoveIpl in case of this server, but I don’t see how that could have any impact here.

Anyway.

You can press E after getting in to get close to Benny’s replacement outside of original map. There’s also vanilla 24/7 shop right next to it.

Press R for another 2 interior examples (also outside of original map), YellowJack and Auto exotics.

connect 147.135.70.136:30100

build 2699 (the last supported one?)

artifacts 6037

Scripthook and vMenu for better comfort when moving around.

6

Interesting: this server seems to have ended up with the new_interior_hash testing flag not being set (which was, likely as an old leftover, set via the ‘policy’ service). I wonder if this is a side effect of something unusual, and that’s why people have been reporting inconsistent results: they’d been stuck on the ‘old’ behavior for whatever this reason is.

7

This specific thing should be resolved as of fix(game/five): serialize new interior location even w/o policy · citizenfx/fivem@41262e5 · GitHub.

I’ll split the posts related to this out of the release topic however.

1 Like
8

I updated artifacts the 6313, but the issue is still there? I didn’t notice anything different from the last time.

Server is up again, if you want to fly in again. Let me know, if I can help some other way.

Side note, I was using beta of FiveM client (not the “unstable one”) and friend was on regular FiveM client.

9

It’s a client change so if you’re not on an updated client version it is expected to not see any effect.

10

I was under impression clients update themselves automatically…? If not, how can I update it then? Or is it that unstable version I mentioned before?

11

Yes, there’s not been any release on the production or beta channels since that change.

12

You were right, the issue is gone! Out of curiosity, how can one know this feature was brought to stable/beta version? Call me a chicken, but I don’t like to be on unstable client, especially when developing :smiley:

13

‘Stable’ usually gets an announcement post and a changelog entry in-app, ‘beta’ gets bumped at an unpredictable schedule instead usually to test changes with a wider audience.

1 Like