So we’re seeing more and more players being caught with modified game files, using it to give them an advantage and exploit. Recently some have been removing props from what we suspect are modified rpf files on their game client. Anyone encountering the same? and or have a way to block this?
Povers
2
Hi,
I discovered the same thing back from holiday.
It seemed to me that during the announce of the client addons that the rpf had to be signed to be loaded except that it is possible to modify a signed rpf to do what you want.
I have not found anything to block this atm
nta
3
Incorrect (both parts of your sentence), however our metrics show that since some other avenue got removed as it was leftover/unused code, people have found out how to use ArchiveFix on base game files and get them to be loaded still (seeing the amount of people crashing from doing it wrong).
This isn’t really possible to fix/‘block’/whatever in a 100%-sure way (since ‘verifying’ files on every launch is a very dumb idea, reading 100 GB+ may take ages), so best design your gameplay to not rely on the appearance of base game stuff, as per usual: don’t trust the client.
So this is good, however, we have some individuals exploiting it pretty heavily now.
Most common-
- Removing props in a combat scenario, so they can see and sometimes shoot an individual through the said object.
- Removing doors that are otherwise locked, being able to pass through them.
These are becoming pretty common which is having a pretty big impact with our community. Are there any flags that we might be able to tick when building to force props to load, or crash anyone that can’t load them due to a modified rpf?
Is there any way the launcher can verify just some folders/directories within the game opposed to the entire game itself?
nta
6
That still doesn’t really make sense as users could just modify any other file loaded with ArchiveFix to add the same dummy replacements.
Your best bet might be to add your own overrides for these objects to stream/ - a bit nasty but it’ll override whatever the user has locally.
So that was our first thought, ie to force it through by streaming the props we were running into a problem with, but somehow they’re even getting through that with the overrides in place. Sadly we’ve encountered a few clips where that isn’t the case.
nta
8
Then either you’re not overriding the files that are being replaced, or there’s something going on that’s not even related to file replacing anymore. I’m leaning towards the first option, unless your server is popular enough that users are thinking of some special methods for your server, in which case it’s impossible to find out what is being done without knowing what is being done: hunches will usually be wrong in these cases.
Hmm, I can look into this some. We are streaming actively with ytyp, yft and ydr. Sometimes manifest files. I’d have to look and see if we have any flags to help with the override process in the ytyp. We are noticing that most of this we’re able to identify and track seem to be users that have completely custom texture packs. So swapping out the sky, clouds, water, and so on.