Zvengks

Oddly, This was enough for me. I had 3 concerns. They had ignored false positives crashing legit players They had ignored maltiez being a caustic ass They refused to give a real punishment to maltiez So, point 1 they gave, is an explicit admission that yes, There where 3 mods that where false positives causing innocent players to crash. They don't specify the number of players, but they specify the number of mods, and exactly which ones they are, so you can check the number of downloads, and make a best guess estimate. If there where only 100 cheaters (as they claimed), it means the number of false positives crashing innocent players games absolutely dwarfs the number of cheaters crashed. That's 100% an admission. It's done with opaque corpo-speak, but they did say they where hiring someone to help with crisis management, so the wording probably came from them. Point 2, Distances themselves from maltiez in the exact way that they should have in the first place. not supporting his asshole behavior, but also saying "hey, being rude or flippant aren't firable offenses". again, it's in crisis management corpo-speak, but It's the first thing they should have said, day one, instead of everything else. Although I can see a few reasons they wouldn't have done it right away. Point 3. I saw someone on reddit refund the game after over 1000 hours. That's absolutely unheard of. That addresses 2/3rds of my concerns. my 3rd concern, Honestly, after asking why they refused to fire him, and essentially did PR for him, and a few other details. I got a theory on how/why all this happened, and it gives a... I guess satisfying is the right word.... answer to all those questions at once. Satisfying as in it answers the questions without creating more questions, not that the situation is good. but it's one that I can honestly forgive. It's not very flattering to anego if true, so I won't say it on their forums, but it's something I can understand, accept, and forgive. an honest mistake, and it explains why they wouldn't get rid of maltiez, would try to repair his reputation, and are willing to give refunds to +1000 hour players. I'm not refunding the game. I'm not actually mad anymore. at all.

The problem I have with this is, are the cheaters buying the game and using the hacked client, or does the hacked client spoof an account? can hackers change their names arbitrarily because they don't use a real account? can hackers spoof a legitimate player's credentials and play as them? If the answer to these questions aren't all no, then this won't actually work. between innocent players being impersonated, and hackers not having real accounts to block. infinitely spammed names. I don't actually know what the hacked client does, I just know that's one of the most frustrating things on steam. I used to play TF2 regularly and stopped because of the bot problem, and those are the types of ban-evasion tactics they use. Impersonation and constantly changing names. If the hacked client is also a multiplayer compatible piracy client, Server user validation needs patched in a hard-coded way by anego, and there is not a single solitary thing we as the end user and mod community could ever do about it other than accidentally ban impersonated players, and get angry that there seems to be an infinite amount of hackers.

The instructions for removing a block either come from a player's IP, or from a server command. if you block server commands, the only option is block breaking from a user. If you rate-limit a given IP's block breaking based on the tool equipped (and you track inventories, not world blocks), then they can only remove blocks at a legitimate rate. Same result, but less storage space and processing on the server. just give every type of block a weight per tool (weight as in numerical value for calculations, not as in pounds or kg.), as a list (no modifying data into the blocks needed), and use that weight to calculate how fast the player would be able to mine in blocks per unit of time. If they exceed that quantity / time they're cheating. If they stay under that limit, they have no advantage over another player, and therefor aren't cheating, beyond possibly infinite tool durability, which is such a minor thing.

Dye light fastness, so that dye source matters Corundum (aluminum), Mercury, and a few radio-isotopes (cobalt, uranium, thorium) but no ability to enrich Maya Blue, (requires pigment fastness to be practical, and corundum in clay, with indigo and a special type of resin to be mixed and blended as an incents and burned for a day to even be made) make the incents burned to make maya blue do something while burning, like make things more temporally stable (considering what maya blue was used for by... the maya, also isn't burning indigo a mild sedative?) Sythesis of Vermilion AKA the alchemy of the great work, the philosopher stone. (Literally following the alchemical process for the philosopher stone makes vermilion, which is pure cinnabar) metal wire fine metal wire through dies wire mesh wire mesh gambeson (per metal type) tailored wire mesh gambeson (per metal type) Atlatls barrels of blasting powder as really really big bombs. to blow off the tops/sides of mountains. cause landslides.... more glass stuff temporal rift monster versions of every animal in game. give me a nightmare bear. a 2 headed deer. give me more nightmare fuel.

In the poker analogy, Right now in VS, NOBODY is tracking the bets. at all. word of mouth. if the server alone records demos. That's the dealer being the only one recording bets. Everyone is screwed. server side alone isn't sufficient to identify fraudulent activity after the fact, because a given player's position is only provided by that player. If everyone is recording demos, That's everyone recording bets. That's the analogy. as for who cares to tamper with it. there's 3 possibilities. Cheater refuses to record and transmit demo to the server. cheater can't connect to server Cheater records demo truthfully. Is either caught in combat by impossible movement speeds, or landing impossible hits, Or caught later by honest demo recording. Cheater sends fraudulent demos. Is either caught in combat by impossible movement speeds, or landing impossible hits, Or is caught later by having obvious tampering. It's the 3 possible actions the cheater can take. It isn't about one of them being more effective or not. It's the fact that it's a complete system. Also, I should point out. The players sending their demos to the server? those players still have their copies of their own demos. Imagine a worst case scenario, a fraudulent server. Every player recording demos, prevents the server from framing anyone to anego. because all honest players using it, would be recording demos automatically. They're absolutely tiny, why wouldn't you? and different players wouldn't be able to practically coordinate consistent fraud either. the result is, nobody can cheat anybody at the end of the game when everything gets counted out. I've noticed I probably do have a few mistakes in here, so I'll just make a skeleton of my logic for how this whole thing was built up. The list of things a cheater can do to cheat, is smaller than the list of all legitimate actions, so focus on that. Make a list of all things a cheater would cheat. Break each down into every way they could be accomplished list each way to detect those actions Identify the minimum amount of information necessary to detect it. If the identification requires more CPU performance, Off-load it to a different moment in time (server maintenence) Make data recording redundant across all instances, to prevent any part of the system from being fraudulent. That's the process I followed, as best as I was able. Emphasis on as best as I was able. There are likely mistakes here and there. as I said before. I'm not a programmer, or cybersecurity expert or anything. I'm actually a solo musician with basically no fans, that mostly plays videogames and works as a cashier. This is far from my area of expertise. it's not perfect, but given what I started with, I feel like I did a good job demonstrating that something fully open source could work. I have yet to see anyone even attempt a reverse engineering exploit of this. at all. that was the whole point. to make that impossible. it doesn't have to be perfect, it just needs to function while open source and not be vulnerable from reverse engineering. -edit, I just realized one of the things you might think is a mistake. the server demo recording player positions and cheat client spoofing. Realtime detection of literal positions would happen at the games tick rate, but demos would be being recorded with literal timestamps for when changes occur. This means server side demo recording might be just a little bit quirky. That's one component of the latency issue. that's why each player has to submit their own demos, to have more accurate timescales. I am using bold because this is important. There is part of this idea that I have had, That I do not know how to account for, which could impart error into the whole system. One word. Latency. I know latency error correction needs done, and I know that latency correction after the fact is possible. I Don't have the slightest clue how to actually do it. I'll point out that an anti-cheat like this should only be implemented if that problem is fully worked out, with 100% confidence. Requires thorough testing before any public deployment. canary in the coal mine. nice. the problem is, the goal is being open source as well, for the trust of not having anything shady in it, since anti-cheat software in general does some shady things a lot of the time (Kernal level anti cheat for example? and I think it was riot that bricked a bunch of harddrives?). All the canaries in the client side version would also be open source and readable by a cheater, which means a hacked client would know how to respond correctly. it's why I've stuck purely to identifying abnormal behavior, and logging everything. also, it's one of the problems with machine learning for this. you can't open source a machine learning system. it's just a mess of chaotic weights. utterly meaningless to read, and therefor entirely untrustworthy for it's behavior and purpose, as far as open source software is concerned. just throwing that little tidbit in because it popped into my head.

When I mine, I mine a huge area. when I cut down trees, I cut down a LOT of trees. When I build, I build big. I think you are under-estimating how many blocks would be tagged, by several orders of magnitude. That also only covers people destroying eachother's builds, It does not cover speed hacks for mining to gather resources. The demo from the client being tampered with, is the detection method. If a cheater is cheating in combat against another player, if all players and the server record demos, Then, fundamentally, One of them does not match, and that's the cheater. Either they cheat and the demo records the cheat and they get caught, Or they don't cheat, and they fight fair and it doesn't matter. if they tamper with the demo, it still won't match the other player and the server, and is still evidence of cheating. The demo is a ledger. This works like bitcoin, This works like poker with pen and paper for bets. If only the dealer in poker tracks bets on pen and paper, the dealer can control who wins and who loses and by how much, because 99% of the time, people don't have enough memory to remember exact dollar amounts. This is untrustworthy. So everyone at the table has a notepad and everyone writes down everyone's bets. If anyone writes a different amount, they cheated. People can't even agree to screw over a specific player, because they can't coordinate and fudge the numbers in the same way. That's the purpose of the demos. big brother is watching you. Using machine learning to read the demos, might be a good fix actually, Especially given the demos would only be being checked during server down time for maintenance. usually for an hour or so. layer multiple demos on top of eachother, account for lag, Replay, Does anything pop out of place from the other recordings? flag it for human review. machine learning does that process without having to manually write the conditions for detection. That's actually one of the few uses of AI I actually support. That and AI Noise removal, text recognition and transcription, translation. That's... about it though. stuff that we could write all the if/then/elses of how to detect a thing, and just... let it figure it out itself.

When I commented on this thread last night, my comment was on page 9/9 of this thread. When I woke up, My comment was on PAGE 23 OF 30. what got shuffled in behind the older posts so nobody reads it? why are there replies with 'content unavailable'? I feel like I'm being gas-lit at this point.

First, commands are issued as text commands. That's one of the things I covered. that's something the game should be doing by default, validating admin privileges on servers, but it isn't. so until that's added to the vanilla server code in some way, we would need to make our own stopgap for that. the problem is, you can't record who removed every block ever removed, and have minute by minute rollbacks on the server. The volume of data is gargantuan. basically every rollback would be a duplicate of the entire world map. that's gigabytes on gigabytes on gigabytes at an hourly rate. you'd be throwing in new harddrives on the server on a daily basis if it's busy enough, not to mention the processing power. a server with as the example, 200 players, tracking who breaks what block and with what, Would be the equivalent of running 200 instances of the game on one machine. If there is something not included in the demo sent to the server, the server detects something missing, and bans them. If diffie hellman isn't implemented, and the handshake isn't done, The server rejects them from connecting in the first place. So, before I even begin, we already had one guy try to use machine learning to make an anti-cheat (using claude to program it), and on top of that, I have an inherent distrust of anyone reliant on machine learning, for nearly anything. so bias stated up front, This doesn't work for 5 reasons. 1, training a machine learning algorithm on valid gameplay takes at a minimum, hundreds of hours of training time. and that's just on vanilla. assuming that went perfectly, if you included that on a server that uses any mods, it would shit a brick and ban everyone, because mod content doesn't exist in vanilla game rules. it would need re-trained from scratch, for every possible combination and configuration of mods. That's not something feasible, by anyone. google couldn't do that. 2, the sum total of cheat behavior, is absolutely dwarfed by the sum total of legitimate player behavior. total training data is smaller, total goal is smaller. 3, neural networks are huge 4, neural networks require a massive amount of processing power, on top of running the server 5, Heuristic detection based on player behavior is notoriously a bad solution. players developing skill at the game too quickly, or having a very lucky run, leads to players being falsely accused and banned, and has been happening in games since the first call of duty to implement it, at a minimum. this punishes high level play. that's why I'm basically suggesting we make VAC at home.

Hi. I'm new here, and while I wanted to wait until the current drama has been resolved (Not forgotten, but resolved), I don't know if I'm gonna be able to remember and keep any of this coherent and remember to post it by then. So I'm just dumping this here now. I am not a programmer, and cannot implement any of this myself. My experience programming consists of game maker some 15-20 years ago as a kid, and playing Shenzhen I/O and The farmer was Replaced() more recently... and mnemonimov (though not much). Not Sufficient for making a mod here. I do however occasionally watch videos on cyber security, and the details around famous cyber attacks, as something to listen to while doing other things, and understand generally what's in the realm of possible, or probable. What I am doing is making a list of, I suppose suggestions for how to create an open source anti-cheat that is non-destructive, insofar as what the mod would be doing. I don't know 100% how viable this is in terms of compute time, latency, or errors. I'm gonna try to break this down into parts, so I'm gonna use some formatting for a bit. I don't know if this is going to fit in one post either. but here I go. Structure of the mod, client side integration and distribution for automated and manual review, Standards. server side immediate detection review system optional exploit identification for future patching (I recommend against doing this step) Section 1. The mod would necessarily have to be open source at this point, simply to have any trust of userbase. at this point, we all have to operate under an assumption of zero trust, which means everything that this anti-cheat does, must be something that is logically inescapable for a cheater. The first step is that there is a server side, and client side version of the mod. If the client side is not running a valid version of the anti-cheat, the server side would automatically detect this, and disconnect them. while being open source means that a hacker could in theory create a fake client version that fools the server side initially, it won't be sustainable and will be detected later, for reasons described in sections 2 & 3. To verify security, Information exchanged between the server side and client side of the mod will be encrypted using an open source diffie-hellman exchange. This is primarily to force any cheaters attempting to make a fake client side mod to implement the diffie-hellman exchange in their cheat version, and provides a competency hurdle. The primary function of the client side is to record what I am calling a demo file (based on it's existence in other games, namely valve's games), and the primary function of the server side is to be automated detection, suspect event flagging, demo collection, limited demo recording, ledgering, and demo playback for review. So, What is a demo file? Essentially, it records a snapshot of the state of every active entity within range of the player (the client player, other players, mobs, projectiles), with their position, rotation, velocity, health, and time. every time anything on the list changes it's rotation, velocity, or takes an action taken (attack, sit down, open a chest, changes equipment or held item etc) it records the position, rotation, action taken, and velocity, at this moment in time, for all entities in range. if velocity and rotation don't change, speed is constant and the position at any given step in time is deterministic. This means complete playback of the movements and actions of all entities is preserved. it also means that collisions are detected as change in velocity automatically, and force the update to the recording. This functions like an Mpeg of vector coordinates using iframes and pframes. The number of entities recorded will likely be less than 15 on average, and a maximum peak of probably 500 (assuming 200 players in range, all throwing spears or shooting arrows, with 100 animals or mobs in range as well, a veritable stress test.). Block data will technically not be required for this, since it's primary purpose here is the detection of 100% of combat-related cheats. more on that in sections 2 & 3. It also has a secondary purpose. any cheater would have to figure out how to fake this file, or be caught immediately. because having a sort of god mode would require faking both your position and orientation as well as the other player's position, orientation, and time of attack, in order not to be detected as a speed cheat and all other players in range are also recording their own positions, it's it's impossible to build a recording of the other players that matches what the server would also record. (The server would also record a demo this way, but only recording the players, and their projectiles, not other entities. Other entities and projectiles are omitted for performance.) it also has to record text chat. both client side, and server side, with timestamps referent to estimated server time, and the ip address that the message came from. more on that in section 2. Also, it should record the player's ping latency moment by moment. this comes up in section 3 performance wise, you're recording a few bytes per entity, per change in velocity, rotation, or action. assuming 10 bytes per entity, having a change, maybe twice a second on the high end, that's a bit rate of maybe 10kbps. and not a lot of compute. with 200 players, for a theoretical maximum of 2mbps under extreme stress of every player in the same location on a 200 player server. not ideal, but performant. so that's most of the structure, and information exchange, next is standards. When I say standards, I mean industrial standards. Part of detection of cheats is detecting things like mine speed, movement speed, jump height, possible max health, satiety, etc, with as little data as possible. block data has to update server side, so mine speed can be determined server side. if a player breaks too many blocks in too small of a time window, they'll be kicked, but server settings and other mods can both modify mine time and the rest. So, Mods will have to openly list how much their mod is able to modify each value, and by how much, and must list it in a way that the server-side anti-cheat can read and interpret. basically a configuration json or something. I don't want to try to personally write all of this out and define the standard, I'll leave that to smarter people. the point is the broad strokes here. Section 2 : server side immediate detection. This part, is tedious, because it's a game of whack-a-mole, a thousand little holes that all need plugged. it can be done, but it's tedious. We know what cheating is, It's the ability to do things that the game isn't supposed to allow. Spontaneous deletion of parts of the map, impossible damage, impossible dodging, item duplication, Generally fudging the numbers. The easiest to prevent I imagine is spontaneous deletion of parts of the map. There's no vanilla items in game that do this, though there are likely commands that the players do not have access to. A Cheater might have something in their client to either allow their client to use the commands without having privileges, or worse, by claiming the commands came from a different user, aka, an admin that is not the cheat client. in section 1 I briefly mentioned that the clients and servers all have to record chat logs. if a cheater fakes an admin as the source of the command, that admin's recording of the chat log will not contain it. The anti-cheat would detect this immediately. the demo recording chat logs include IP Addresses of the messages. Since players aren't connected peer to peer, and must communicate through the server, all messages from other users have the server IP. This means if a cheater attempts to use admin commands, the server will detect that the user is claiming the source of the command was the server itself, or a random IP, which it wasn't. any spoofed users would also detect this as the wrong IP address, and also be able to flag this automatically. The result is, commands are either rejected, or reverted/rolled back, and the offending player banned. Next possibility, destruction via items in game. In vanilla there are some small bombs. In mods, I don't know, I haven't used mods. a cheater could use item duplication to have an absurd amount of them and rapidly use them. Movement speed caps being exceeded, placement range caps being exceeded, and just like the above, placement source spoofing, would all be detectable and immediately be forced to disconnect as it happens. distance between player and placed object is too far, player is speed hacking, etc. That's also why the standards are needed, To adjust those caps as mods would certainly enable. So, item duplication and then simply being a troll, placing and detonating cheated in bombs at a legitimate speed. That's the next part. Ledgers and Provenance. The server anti-cheat should record every inventory server side. chests, player inventories, ovens, items placed on the ground. It'd be a big table, a spreadsheet, and it would only update, when a player picks something up, drops something, deposits something, anything that changes an inventory. The simple purpose is to detect item duplication. if inventory A has 5 of an item, and inventory B has 0 of an item, and the player moves 1 of the item from A into B, you should not have A = 4 and B = 99. Everyone I argued with on reddit acted like this is an unreasonable ask because they claim you would have to parse through every item in the server every time any item changes. This isn't quantum entanglement. whenever an inventory changes, you only change 2 numbers, and make sure that the addition/subtraction adds up. It's a few bytes and basically 7(?) compute cycles, read, read, add, subtract, compare, write, write. it takes a nanosecond. This does not take a catastrophic amount of compute. at most it takes up about a 10mb excel spreadsheet on the server. you could add every player's health and food satiation for every food type, and current hunger, and update them every second and you're adding maybe half a Mb of write per second, and you don't need to do that much. that's extreme over-tracking at that point. The reason for this is to catch players with items duplicated client side. Next up. Instant detection of combat related shenanigans. I'm only bothering to describe this, because of an argument I had on reddit. They said that the server can't handle doing all the collisions and hitboxes for every player and mob. That isn't necessary, They talked about the shape of weapons mattering, and the shapes of hitboxes. it was insufferable, because that's all unimportant to detecting a cheater. That's only relevant to non-cheating. cheaters fake their attack ranges and hitboxes. All that you need to detect that is the position of players, weapons used. That's it. In melee, the weapon has a maximum distance from the player it can hit a target. If a player is outside that radius, it was impossible for them to hit. the weapon has a maximum range of angles from the center of view that the attack can land on. if the target was outside that range of angles at that moment, the attack was impossible to land. simply by knowing both players position, facing, and selected weapon, Melee cannot be faked. in theory a cheater could attempt use manipulation of player coordinates for both players to ensure that their hits land, and their opponents do not, and if due to latency It may be possible to sneak past an auto detection briefly, Long term, due to demos acting as community ledgers (like playing poker with every player tracking bets, Or I suppose like bitcoin), it would be trivial to detect after the fact, either through an automated review on server maintenance, or be flagged for manual review by a server admin before or during said maintenance. Just play back the demos of all involved players and the server's own recordings of player positions. they should all approximately match, except if there was a cheater faking their position, it would look like a bizarre and unnatural series of sudden movements by both players simultaneously, that do not match other demos, and it would only be recorded on one player's demo. that player is the cheater. cheaters also would be unable to collaborate and cheat as a group, because they would have no real way to coordinate their demo recordings to match, which are sent autonomously, possibly in realtime, which means they couldn't cover for eachother, and would in fact help expose eachother. and for a bit of clarity, I know, the game technically tracks this information already, because that's how things in game occur in the first place, otherwise players couldn't interact with eachother. I am saying that the anti-cheat will be duplicating and recording this information, independent of what the game already does. Next up, Ranged attacks. Arrows are fired from a definite point, at a definite angle, and a definite speed, dictated by the firing player. in order for a cheater to not be hit (as a cheat), they would have to move unrealistically (and possibly trip the speed cap), or alter the position or timing of the arrow. projectile position, angle, and velocity are recorded in demos from every player, including the one who shot it. This means even if the real time systems fail to catch them, automated review will trivially catch this. Section 3 The review system. Demo recordings are not intended as the real-time solution. The real time solutions are to track the validity of server commands (I described this in the demo section, but it would likely have to be a separate data stream), item duplication, griefing, speed hacks, mine hacks, and some combat hacks, based on reasonable assumptions. Demos are to catch any cheats that are being more clever than doing the most obvious method. Terrain is not necessary because literal positions are what is recorded, not collisions, which means the consequences of collisions are recorded as well. This does mean that this does nothing to detect players no-clipping, but presumably, that would be detected by command misuse. it also means wall-hacks are undetectable in this method. terrain tracking however is impossible, because it would fundamentally require a moment by moment recording of the entire world and every block in it. that's an impossible volume of data for next to no benefit, so just throw it out. There are 2 systems for review. Automatic, and manual. both automated and manual review must be performed while the server is disconnected from the players, in a kind of maintenance mode. Typically, The world won't even be loaded in review/maintenance mode, so no worry about time ticking by effecting seasons, crops, or decay. Essentially you could load an empty flat world with no blocks in it at all, and it will work for these purposes. Automatic review is limited. It's just a matter of synchronizing demos, and making sure everything lines up to what is expected. This will primarily be checking ranged attack discrepancies because it's the easiest to prove. if there are 5 players loaded in an area and someone uses a ranged attack and 4 of them have identical positions, angles, velocities and start times, and one of them has anything mismatched, it means that mismatched recording's player is the cheater, who modified the position of the arrow to either guarantee a miss on themself, or guarantee a hit on their target. based on how demos work, that's the only way for that to occur, and it would also always occur. the anti-cheat could automatically ban that user without admin intervention, though it should be flagged for admin review, because a machine cannot held accountable, and should not be left responsible. the second is manual review. There are two types of manual review. Casual overview, which would be done if the server host is suspicious, or just wants to test demo playback. It would load the demos and allow for playback, including adjustment of playback speed. Essentially, Only entities would be loaded, No blocks. Think instant replays and slow motion. Except that the admin has access to the perspectives of every player on the server and can also overlay them when multiple players are in the same location. because latency exists, if a player is recording, and experiences extra lag, and another player was near, that player would simply continue moving in whatever direction, and then snap to the correct place when latency catches up. this would be seen in the demos, which is why it is important that they record player latency. The admin would see how much latency changed, and confirm if it was real, or faked latency to dodge an attack or something. it would be important for an admin to regularly do casual review of normal gameplay, because latency issues would create some variance to demos, which is why not all behaviors can be automatically moderated. automation could flag things for review before or after taking action. Ranged attacks have more confidence so automation could flag after automated moderation, but anything else suspect flagged for manual moderation. The other type of manual review is directed manual review. This could be from automated reporting, or player reporting of a specific player cheating. This, unfortunately means, the admin manually scrubbing through either all of a single player's playtime, Or just specific moments reported, based on server time timestamps. manual review can also be used to potentially check for game bugs and exploits that cheaters could automate, but by default I don't recommend this, because the extra features in part 4 get a little bit sketchy. regardless of automated, or manual review, or even realtime disconnects, the server side anticheat must make a note of all moderation actions, so that specific players can be reported on to the anti-cheat mod authors. This way player account specific tracking and moderation flags can be used across all servers running the anti-cheat. this would be an opt-in red-flag-list that admins would have to manually update, Or could be hard-coded into the server-side of the mod, requiring manual updating. Part 4, exploit detection for future patching. This part is optional because it functionally requires doing something I personally don't approve of. I do not actually recommend doing this. at all. I am very, extremely opposed to doing this part. I am describing it however, because if cheaters/hackers become a very serious problem, at some point, this could become necessary, and I'd like to have a record of a way to do it without it being shady and underhanded, so that nobody could reasonably get away with doing this. I this is how to do this part open source. Most exploits I know of in games, involve abnormal and unexpected user inputs and situations, the intersection of 2 edge-cases, AKA the corner-case, that goes unnoticed. On example of this in a different game that's easy to explain, is Item duplication in cyberpunk 2077. In that game, the way it works is if you have multiples of the same item in a stack, and go to a vendor, start to sell all but one of the item, align the mouse with the location of the item in the inventory, and hold the button used to select to sell that item, and while that is held with the cursor on the item, press the key/button to confirm the sale. (select and confirm sale are 2 different keys) The result completes the sale for all but one of the item in the stack, Opens a new sale for the full stack before updating the item quantity, and then modifies the stack size to 1, allowing you to sell (2x)-1 of the item that you have x of. it also allows you to buy ((2x)-1) of an item the vendor has x of in stock. This includes buying back items you sold. so you sell (2x)-1 and then buy (2x)-1, giving you almost 4x as many of the item as you started with, repeatable infinitely. If any such bugs exist in vintage story, be it in an inventory window interaction, or even a movement or hitbox clipping bug, a cheater will create a utility to automate the process. basically like a TASBot with manual control. press button, receive ham-lego 64 steel ingots. The goal here isn't to identify that a player used an exploit to duplicate items, The inventory ledger does that automatically. the goal of this step, is to see how the cheater accomplishes it. if it's just a client side mod for client side item creation, that's worthless on the server. if it's an exploit that the server doesn't catch that can be done in vanilla with strange user inputs, you want to be able to identify, replicate, and report to anego as a bug report. Unfortunately the only way to actually identify that, would be... lets call it "A Demo of raw user input". In other words, a Keylogger. (DUN DUN DUN) That's why I do not recommend doing this. Typically keyloggers are spyware/malware. Typically, they are immediately flagged by anti-viruses, and rightly so. having a working anti-cheat that depends on being open source, means that you would have to have a fully disclosed, open source, keylogger. you can't put that on github. every anti-virus on earth would flag it immediately, even when you download it in some cases. it means in order to do this you would have to tell users "This anti cheat is open source, and does contain a keylogger, Here is exactly how it is used, here is where it is in the code so you can double check, we used plenty of comments to describe in plain english what each part is doing so you can follow the logic. your anti-virus will 100% scream at you, but cheaters have gotten so bad that this is the only tool we have left at the moment and it is right on the border of being illegal in some jurisdictions. please run it anyway " The truth is though, If any player read that, there's basically a 0% chance they're installing it. here's the fun part though. cheaters won't care. They'll see it's open source, read what it actually does. and hit accept and allow. Why? because if they see how it's used and that it doesn't connect to some random server, or continue running after the game closes, it's "Safe", and because if they don't have that, They can't connect to the server. As a result, Every server running it, becomes a cheater honeypot. sure. maybe there are some legit players that might install it, because it's "safe" but if they're legit, they won't get flagged by anything happening, and review of their behavior will be clean. "Nothing to hide, nothing to fear" taken to the absolute extreme. the way it's a honeypot is that server admins get unrestricted access to what key input trickery the cheats have to do, in order to do what they do. It guarantees that if it's actually due to a bug in the base game that requires specific sequences of inputs in certain conditions... we get all the exploit details we need to get them patched out and make the cheat tools worthless, not because they can't connect to a server anymore, but because the exploits they use won't work anymore once patched. But like I said. I am absolutely against everything in section 4.... section 4A... Section 4B, The good news. If things actually got so bad, that people are legitimately considering exposing themselves to keyloggers (Even if it's only while the game window is active), There is a different, very obvious solution that works to protect servers most of the time, and doesn't require that. Player whitelist servers. Not blacklisting cheaters. Getting whitelisted to join a server in the first place, through user reputation in an established community. This starves out cheaters, giving them no servers to access worth while, killing the value of the cheat utilities, and they stop being developed. a few builds of the game later, and servers can open up again. Nature heals. Still have anti-cheat as described in sections 1-3 though... even on whitelist servers... just in case. So in summary.... realtime detection of command based map griefing, melee combat cheating, minespeed hacks, and client side item duplication, for instant disconnect of offending players. Delayed detection of ranged combat cheating, more clever melee combat cheating, and other forms of griefing. total cost, a few kbps of bandwidth from players, a theoretical 2mbps maximum of increased server bandwidth (closer to 50kbps on average for busy servers), and maybe 50mb(?) of demo storage per 24 hours of continuous server uptime for as long as they keep a backlog for? plus 10-20mb of duplicated map inventory data for duplication detection and spawned item detection. all of it can be coded open source because it works like a public ledger the way bitcoin does, nobody can cheat because it's impossible to coordinate action with the legitimate players. ostensibly it's the same functionality of how VAC works/worked on steam. So I'd call it VSAC Vintage Story Anti Cheat. And I know, i'm not a programmer, and I basically pulled all this out of my ass. but if I can pull this much detail and reasoning out of my ass without even trying and it's in enough detail that someone could attempt to implement it, Why not try? right? that's why I wrote this up. Everyone i've talked to on reddit about this thinks it's impossible to do anything, because there are so many legitimate player behaviors you have to figure out, and I'm just like, no you don't. you don't have to account for legitimate play, the game does that already. you just have account for cheat behavior, and there's only so many things that are even "cheat-able". don't look at a thing and say "was this possible", Just define what's impossible as a threshold and reject everything that passes it. it's all you have to do. I don't even do multi-player. I just have my single player world, where my tailor is building a road to the library in between panning and cooking porridge and making juice. it's 2:24 AM, i've been typing this since midnight, what am I even doing?

incidentally, although I don't have much experience coding (mostly with game maker and fake languages in zachtronics games), I do have a few ideas for how a fully open source, server sided, anti-cheat, could theoretically function, and function because of being open source, rather than in spite of it. I just don't think now's the time to talk about it since it's such a controversial topic at the moment.

I really didn't want this to be my first post on the forums. I don't normally use forums. I just play the game until I burn out and then come back to it. I've been trying to, in the fewest words possible, make one simple point crystal clear. If the reason people are mad was the what of what he did, and nothing else, then reversing course, removing him from the modding community, and a standard corporate apology would have been enough. It hasn't been. Which means a core component of what people are still mad is the WHY of what he did, because something about it smells off, based on his statements. Primarily because of this screencap (and many others, but I think this makes the point the clearest.) When maltiez said "It has nothing to do with protecting servers or stuff", That is literally saying "My motivation was not to improve the community in any way". Just sit with that for a minute. What does it mean? It could mean "Putting malware into a mod, to harm another person, was the goal. everything else is post-hoc justification." That's the least charitable interpretation though. The fact that he called it malware himself, didn't help... That's the old "No such thing as bad actions, Only bad Targets" rational that the overwhelming majority of people find offensive in and of itself. that's the same line of thinking of a school bully who decides "Oh I'll just become a cop, prison guard, or join the army, so I can beat up and shoot people, and it'll be okay because they're bad people " I am not trying to say that that's what maltiez actually wanted. He very well could just be terrible at speaking or working under pressure. I am saying that that's the way he sounds, and a sizable number of people see it that way. I know other people see it that way, because I did not take that screencap, and I did not underline that text. That was already there, floating around, reposted, until even reddit stopped allowing attachments in comments. Something people have felt important to highlight, even if they don't go through the motions of picking it apart to it's logical end like this to figure out why exactly that sentence is so egregious. instead they just underline it and hope others feel the same gut reaction. Me though? Reductio ad absurdum just happens to be my favorite type of argumentation. strip it to it's base logic, and then build the chain of events until you find the absurd flaw to show why the logic wasn't sound. I don't think maltiez actually just wanted to see if he could get away with malware and ruining people's days. Never attribute to malice what can be explained by stupidity. I think maltiez is just an idiot, who asked chatGPT how to stop hackers and it said to cut off the source of the attack from the target of the attack, and also target the source of the funding, and then asked claude to just do that and cobbled it together and bundled it with things he already had claude write. Given how much Maltiez has openly talked about using claude to write his code, This feels closer to the truth than any maliciousness. That doesn't change the perception though, he's either malicious, or catastrophically incompetent and irresponsible, but still has dev connections. and that's why people are actually angry. Not the waste of time he caused. both are reasons to fire him. they need to see that. i don't see any other way this could have happened. it's one or the other. Anyway, Sorry for beating a dead horse.