Quoting: gustavoyaraujo

Quoting: rkfgI think the biggest issue with EAC is how intrusive it is. It clearly includes a kernel-level driver (I found issues describing BSoDs caused by EasyAntiCheat.sys) and Wine, being a userspace set of libraries, simply can't emulate kernel APIs because it would require root access and a kernel module. So Epic/Valve will either develop such a module and provide a way to build/load it from Steam (more likely) or drop the low-level part of anticheat which would make Linux a more preferable platform for cheaters (much less likely). Or maybe they'll find a middleground and do whatever's possible from userspace but with elevated privileges (access to /dev/mem, /dev/kmem and such).

TBH, I don't like any of these possibilities because this anticheat gets full access to your memory, processes and devices and can potentially steal passwords, keys and whatnot.

That's really a thing We should care about. But maybe Valve is planning to do this inside the Steam Linux Runtime. What you think?

SLR is just userspace libraries. What matters is whether it will be in user or kernel space and whether it would require root access. But there's no information, neither official nor rumors so my guess is as good as yours.

View this comment - View article - View full comments

I think the biggest issue with EAC is how intrusive it is. It clearly includes a kernel-level driver (I found issues describing BSoDs caused by EasyAntiCheat.sys) and Wine, being a userspace set of libraries, simply can't emulate kernel APIs because it would require root access and a kernel module. So Epic/Valve will either develop such a module and provide a way to build/load it from Steam (more likely) or drop the low-level part of anticheat which would make Linux a more preferable platform for cheaters (much less likely). Or maybe they'll find a middleground and do whatever's possible from userspace but with elevated privileges (access to /dev/mem, /dev/kmem and such).

TBH, I don't like any of these possibilities because this anticheat gets full access to your memory, processes and devices and can potentially steal passwords, keys and whatnot.

View this comment - View article - View full comments

There's a more complete patch by LukasRuppert here [External Link] that should allow login from the first try but it's not included in that Proton build. I'll try to build it and check.

View this comment - View article - View full comments

Yes, it somehow grew from "an engine" to "The Engine". There are no other FOSS "full-stack" engines of this quality. I remember Ogre3D was popular at the time but it's graphical only. For sound, network, physics etc. you'd need to manually add something else and make it all work. Other small engines fill some roles but there was no complete 2D and 3D FOSS solution that checks all the boxes like the big commercial engines. Now there is and I gladly became a patron albeit not a big one. But hey, every penny helps! Even if I most likely won't become a game developer it's good to indirectly help the others (and the devs of course) who have no money or time to learn the big ones.

View this comment - View article - View full comments

Godot is truly awesome. I decided to learn it a bit last weekend and made a little platformer [External Link] (~18 Mb of web assembly). It demonstrates some basic elements like moving platforms, ladders, boxes, enemies and arcade physics. Only 2 simple levels, WASD controls. Uses free assets from itch.io [External Link] (there are surprisingly many packs there!).

I'm enjoying the engine pretty much, it's obvious that it's made by the people who know what their users want and need. Everything is where it's expected to be, many handy utility functions and elements everywhere and it's not dumbed down and has all the extension points you need including turning off its entire scene system and doing all the heavy lifting by yourself! I don't remember the last time I used a tool without constantly fighting it and Godot is exactly this. Compiling it is also a breeze, it only needs the Mesa development libs (for OpenGL), X11 libs and Pulse/ALSA libs for sound. If you ever compiled any GUI app you most likely already have all this. Everything else is included so you just run scons and get a single working binary. Even building it for Webassembly and Android is pretty easy. Great documentation that even covers some general gamedev topics like linear algebra! And their scripting language is simple, concise and on-point. I mean what scripting languages do you know that directly support true multithreading (not like Python with its GIL)? How many of them don't have garbage collection that unpredictably decides to freeze your game? GDScript is yet again the winner here.

I tried UE4 several times but it's so complex and... enterprise that I decided it's not worth the time. I'd spend weeks trying to make something simple and lose enthusiasm much earlier. Also UE4 isn't well suited for 2D games I think and I didn't even try Unity because it's too proprietary and C#-oriented for me.

View this comment - View article - View full comments

There's also this little fix that probably won't affect many users but it's very important for me:

The X driver will now create a fallback pathname UNIX domain socket in the directory specified by the "SidebandSocketPath" option, or /var/run by default, which will be used by other NVIDIA driver components if they are unable to connect to the default abstract socket.This fixes a bug where graphics applications run within a network namespace (which prevents the use of abstract sockets) were unable to take advantage of some driver features, such as G-Sync.

If you run Steam and/or games inside a network namespace (for example, using Docker), G-Sync wouldn't work before. I use such namespaces to allow Steam (and games) to connect directly while for everything else I use a VPN. It's a pretty unusual setup but I need it to work around censorship and still have regional prices on Steam (that are usually -70% from the base dollar price) so Steam has to see my real IP, and also have low ping in multiplayer games. It's the most robust solution that I found as all I need is to run Steam in that namespace and everything it spawns stays in the same namespace so no need to mess with iptables, routes, ports and such. The programs only see one network interface (a virtual ethernet "pipe" that bridges the namespaces) and one default route (my router), they're not even aware of the VPN's tun0 interface and can't use it.

I reported this bug [External Link] before and it took about a year to fix but eventually it's here and it works. Arthur Huillet found me on IRC (that was a big surprise) and we discussed the issue in details. I used a kernel hack before that basically turns off anonymous UNIX domain sockets isolation (they're not accessible across namespaces) by removing a couple of lines, no sideffects that I'm aware of but I know it's not a good thing. Now it's obsolete and I can use a regular kernel build. This NVIDIA's socket has a long weird and random name, it's not documented anywhere and NVIDIA seem to call it "sideband". I have to admit, if the driver were opensource I could've fixed it myself long ago probably...

View this comment - View article - View full comments

I'm not sure if it's still an issue but I just launched Steam, updated PA:T and it works just fine. Decent performance too (110 FPS, though a small planet and early game). UI is just as good as it was before. My GPU is GTX 1070 and the driver version is 430.40. Looks like they pushed an update an hour ago [External Link], maybe that was the fix?

View this comment - View article - View full comments

Quoting: F.Ultra

Quoting: rkfg

Quoting: F.Ultra

Quoting: Sir_Diealot

Quoting: F.Ultra

Quoting: rkfgI have a feeling that as SteamPlay becomes more and more reliable this situation will become common. I wonder what Valve would do if anything at all.

I hardly think that they pulled the native Linux build due to SteamPlay when you need a custom build of Proton to make it work.

Eh, it *will* work through SteamPlay. Good enough for the Linux folks.

Well if "not working properly" is what they deem good enough for Linux folks then I still don't see how they would not have played this card without SteamPlay.

It won't work on current Proton because it ships a slightly outdated Wine version. When they switch to a newer Wine NS2 will work fine (except for the issues I've described). For now there's a big memory leak in one of the Wine-provided functions, quoting the developer:

The wine maintainers fixed the issues related to us (or better Luajit) using the 64 bit zero bit offset with NTAllocMemory with the release of 4.14
You need a custom proton build which is already based on wine 4.14

Which was exactly my point ;-)

In my recent post they say it's been patched on the game side to support older Wine versions (but I just checked and it indeed doesn't start on 4.11). Anyway, the "custom" thing doesn't mean you need to patch Proton or Wine for this game, just wait for an update. I know it's not much different for an average Joe but for me it's a big difference.

View this comment - View article - View full comments

Quoting: dubigrasuWhile unsupported, will the Linux client be still downloadable (and able to start a local server) or simply removed completely?

Just in case, you can use the not often used Steam function to backup the game files and restore them afterwards. The build 329 is set to be released on Monday (if nothing bad happens) from what I heard on public Discord channels so not much time left.

View this comment - View article - View full comments

Quoting: dreamer_

Quoting: rkfgOkay, so I knew this for a couple of weeks already (was told by a developer who asked me to test the game on Proton) but since it's now official then here's some more info.

If you have direct contact with the developer, can you ask what is their stance on releasing the source code?

I bought NS2 years ago, but the initial Linux version was unplayable on my machine, so I've never gotten into it properly…

I asked the developer and here's what he answered (Liam, add this to the article if you want to):

There are some licensing issues that don't make it possible to release the full codebase of spark to the public. During the early times of development UWE licensed modules of spark to 3rd parties for additional funds. Right now from UWE's perspective it's not worth it spending time and money to resolve that.

Also with engines like unity and unreal available it's not really worth it for a studio like UWE to continue to invest in their own engine.

We will look into ns2-specific issues with wine. We already added a workaround for the NtAllocateVirtualMemory related issues with wine below version 4.15

Something else to note is that essentially the decision to drop Linux came down to dropping support for all renderers beside DX11 long term. So we can add additional render features without having to port them for the other renderers. The OpenGL renderer wasn't in a good place to start with and we just lack a full time developer to just focus on that. And we don't have the budget to invest into a Vulkan renderer. But we would be more than happy to welcome a community developer who's willing to work on the native Linux client just for the sake of it. Of course that developer would need to sign our CDT NDA to get access to the engine's source code.

So if anyone's up to making a Vulkan renderer or supporting the existing one, you're welcome! Mind that the engine is still closed source and under an NDA and you most likely won't get paid for that. That said the alternative ways to get money always exist, like Patreon. The NS2 community is small but dedicated, I myself clocked 3760 hours to date and I don't see a reason to stop.

View this comment - View article - View full comments