No no no no, I was going for generous in forgiving an insult or injury; free from petty resentfulness or vindictiveness: to be magnanimous toward one's enemies. Not that I would consider you an enemy, nor do I feel insulted.
I do not think this word means what you think it means. If it does, you're just being a jerk.
Well you were using Apple as an example of the fruits of control, something like profit/community/brand protection and quality of experience. I was just pointing out that the difference in scale makes that comparison a serious stretch. For example, Apple is protecting billions in profits and millions of users. You guys are protecting zero profits and IDK, 80 users? I also pointed out that Doomseeker is a great experience, and I could get into the community/brand protection thing too, but to be honest I don't feel like it haha.
Strawman much? Obviously you missed the part about control. Apple likes to control its products. ZDaemon likes to control its resources. Any other implications you think I said are a product of your imagination.
I'm totally happy with that. It's way better than "it's Blzut3's fault".
You're just going to have to live with the answer: "We don't want to."
Although I agree it's way easier to write cheats if the source code is open, I don't think it matters once a cheat is written, especially since it's hard to plug a hole to a cheat if it's closed source. Plus, you assume that you can plug the hole; some cheats just aren't exploits. Aimbots can't do anything that a human can't (by definition, they're using the same netcode the human is). You're talking about trying to figure out what an aimbot's behavior is versus a human's; the simplest example is "aimbot shoots 100%, human shoots 85%", but it's easy to either switch off an aimbot or program in some variance.
To get to your suggested solutions:
Aimbots: This strikes me as a completely client-side solution, which.. defeats the purpose in your open-source designs.
1- Difficult to implement. There are issues with prediction, edge cases, etc.
2- Because of the issues in (1), you still have to inform clients before they can see the other user, that the other user is approaching, which means your attempt to avoid transmitting needless data will not save someone who reacts quickly.
Speedhacks: Yes, we do some detection. However, SR50 is still a valid speed in the game. But, that doesn't mean you should be able to physically move at SR50 at all times. We found out that this was possible through a macro and removed the ability to do so.
To more specifically address aimbots, I would definitely not implement a solution in the client. Client commands have angles, world indices and whether or not the client is shooting, during unlagged I can just look at P_LineAttack (or whatever, I'm too lazy to open up the source) and compare that to the positions of the other players. It's not like this would be CPU intensive at all, and keeping statistics like this is actually something players want (accuracy stats). Regarding the pixel stuff, I should have said "unit", that's probably what gave you the impression I would do a clientside thing.
Wallhack stuff yeah, the classic problem when withholding opponent positions is clientside prediction, or like you alluded to, packet loss (opponents just suddenly appear, BOO!, haha). I've generally been comfortable in competitive play mandating a certain level of connection quality; if your ping exceeds 200ms, you're gonna have a bad time, sorry. If your packet loss is so bad that you can predict your own movement all across the outside yard of D5M1, you might see your opponent frozen just inside the cave. Too bad. If you're hosting a friendly match, or you just aren't that serious about wallhacks, feel free to turn the feature off.
But you always know how fast a player could move at any given time. Just figure that out (radius), move them around the circle in however many degrees you want (resolution is up to you, 45 degrees, ANG_1, whatever), and if the player could ever see any opponent, send the message. I realize that effectively means you can write a wallhack that sees around corners, but I think that's an inherent limitation of the technique.
Cheating/netcode discussions are fun, I really enjoy them. Closed source clients have their advantages, they can include checks for running under a debugger, or detecting CreateRemoteThread, or require a CPU that supports DEP, but that stuff is sort of elementary.
So, since we know it's a difficult thing (which it appears only ZDaemon has so far tackled), I can only look forward to seeing how you approach the issue of cheating in your open-source doom ports.
You can also leverage a closed source launcher. It's not a perfect solution, and it doesn't address every attack vector, but a competitive event like IDL could probably issue a new launcher for every season that hashed & launched the Odamex client--this would essentially be the same system ZDaemon uses for anti-name-faking. Again it would only be a matter of time before the launcher got cracked, but it would probably take longer than an IDL season, and then it would be useless.
I don't know if ZDaemon does something like this. I traced IDE's system calls to try and figure out what kind of hashing it was using, and I saw that it was reading the whole EXE I had configured as the ZDaemon client (zddemotool.exe). I don't know if that's a normal part of CreateProcess or what. If it's part of anti-cheat, in that thread we agreed that a problem with that system was that the binary could be switched out between verification and execution. You have to set a breakpoint in the launcher (and it looks like IDE crashes under a debugger, hehe), but it's still very doable. It does require dedication and expertise though, so it's unlikely. Just something to consider, unless I'm mistaken outright.
My guess is that they have the ZDaemon Launcher and IDE do a lot more stuff (like cheat detection). Add that to the new anti-name-fake required verification, and you're requiring users to run anti-cheat through the launcher. This stuff wouldn't really work in Doomseeker because it's open source. Like you said though, their loss :) .
Although I think this conversation may be over, I did want to point out that there is definitely no technical reason Doomseeker can't conform to ZDaemon's protocol. The 1.08 protocol (which can be seen in the ZDaemon plugin code) generates auth tokens as well.