…and with proton, I haven’t heard my son complain in a long time now. (The old [heavy sigh] “I wish I had a windows gaming machine…” has been replaced with “Dad, can you move some more money over to my Steam account…”) He can play his Warhammer games… and he just started running Skyrim. (We have it on PS4 but he loves to run mods and there are not as many on the PS4.)
Offtopic Note: Most games fail to run on linux because they come with their kernel driver spyware, err anticheat. For this and similar reasons they fail on wine and can’t even legitimately be ported to linux either. At least not BattlEye games, because they disallow running with unsigned drivers, which could mean you cannot run on linux when using a driver unknown to THEM. Also they probably don’t have a Linux Anti Cheat handy.
AntiCheat 101: The Client Always Cheats. Perform all cheat-sensitive operations and anti-cheat checks serverside.
Oh, I think “anticheat” in this case is really “anti-piracy”. Where you spend more on the problem than you gain with the solution because of a broken equation. (Broken equation: illegal copies = lost sales)
That won’t help against Aim Botting, Anti Recoil Macros whatsoever though. BattlEye goes really deep: It is a kernel driver which hooks certain syscalls and thus even knows when you use SendInput(). It can and will scan everything which is open and upload it for further analysis, you are not allowed to run without driver signing etc. That kind of “spyware” wouldn’t be possible server side, however Rust e.g. detects Anti Recoil Macros because you always send the same “aim pattern” to the server. But it’s harder than verifying checksums of known cheats.
And yeah, piracy might also factor in, Denuvo Games aren’t portable either, but also most games I am talking about are multiplayer only anyway.
Sure, there are client-side solutions you walk away from - but on the flip side things like aim bots are still easily detected serverside. It’s a tradeoff where one possible solution is fairly straightforward and gives, say, 90% of the desired effect and the other solution is very difficult might get you a little bit farther in some cases. I’d always choose the first unless hard pressed to choose the second.
aim bots are still easily detected serverside
Not really. And aimbots are not the only type of cheat, there are plenty that are more subtle than that.
Yaya, I thought someone would bring up aimbots… I bet those could be detected serverside frequently, if someone tried. With more subtle stuff… bleh, anticheat will never be perfect anyway.
Anticheat also sometimes bans innocent people who just have uncommon software installed, from what I’ve read. Not to mention they’re “borderline” spyware. So these aren’t universally popular. I avoid games that do this stuff.
It’s a small issue holding back some Linux adoption maybe. I hope the industry decides it’s a “niche” use-case and moves forward with better cross OS support anyway. Let the first person shooter geeks switch to consoles if they’re worried about cheaters. (Yeah we’re about to start a flame war here aren’t we?)
isnt this Vulkan topic?
anyway noone like auto-bans, there always need to be human to verify.
in CS:GO they have easy system, players verify players, they get something from it if i good remember.
Continuing the cheat thread… CSGO has terrible anti cheat. Not only did they add a built in outline “x-ray” effect that has made cheats ridiculously easy to make (short source code really easy to find since you don’t have to do any graphics stuff so loads of people compile their own), but their system for players reviewing players is very low tick and so it makes good players look like they aimbot - several pros have been banned and god knows how many normal players.
They also decided to give you a matchmaking trust factor to help split up cheaters from legit players. The more reports you get the lower your trust factor. Everyone I play with started reporting every player they could every game.
Can we please stay on topic. If everyone wants to talk about anti-cheat, it would be appropriate for it to have its own thread.
OK, I found where someone has build a java-vulkan engine on lwjgl. I do not know how good it is, but it could be a good reference.
Yeah we’ve seen it posted before. The demo stuff looks great, and it erased my own concerns about the feasibility of supporting OGL + Vulkan at the same time. Maybe it’s not that hard to do after all.
A bit of a shame the author hasn’t joined this community. I was a little shocked to see that repo out there on its own.
Same, I was surprised to see it with almost no community or other people working on it.
It would be a good place to start when designing an implementation of vulkan. I am working on jme4 in my spare time right now, but the whole vulkan thing is very new to me.
If anyone would like to help me build the abstraction layer and the vulkan implementation, I would really appreciate the help.
For those who would like to help, I moved my repo to github:
I am still in the progress of finishing up the rename to JME4, and would love some help in getting rolling on the JME4 changes.
I have opened up an issue for the roadmap, comments welcome.
Well one thing I’d like to see is a redesign of jme3-examples to clearly separate and define these three concepts. These kind of came out from some conversations I’ve had with @sgold. Should make contribution reviews more productive by stating clear goals ahead of time.
- Examples - Targeted at “end-developers” using JME, to demonstrate how to do something (preferably with minimal distractions), including best practices and strong attention to code/design quality.
- Tests - Ensure XYZ feature works, protect against bug regressions, help maintainers to troubleshoot problems, support test automation wherever possible. Typically should employ as little randomness as possible to ensure tests are consistent and repeatable.
- Demos - Visually impressive examples (preferably following the same guidelines as examples above) which help show off the engine’s capabilities.
Currently they’re all kind of mashed into jme3-examples, and it can create a temptation to satisfy all three sometimes conflicting goals at once.
@louhy I think that is a great idea. Would you open an issue for that, or comment on the roadmap issue? (in the jme4 repo) I think your post here has a great explanation of what needs to be done.
Sure, no problem.
Another thing came to mind reading your post above, I feel like I recall some talks about dropping the “3” from jme3 (which would imply the 4 too). Can’t remember why that came up (maybe just that it’s simpler to type out) but, if you’re doing global renames like that and it’s a desirable change, might want to consider it.
I brought that up a while ago. I really do want to drop the 3/4.
I am having a lot of trouble renaming the packages due to netbeans refractor being dumb. I am going to start over on the rebranding today (and pull the latest changes from the jme3 master branch while i’m at it) I will see if idea does a better job at the refractor, and I will drop the number so we do not have to deal with this problem in the future.
I’m sure the jme 5 guys will thank you.