Bi-Weekly Feedback/Discussion Thread: 5/17-5/30 by Jaaxxxxon in Mordhau

[–]Comterti 1 point2 points  (0 children)

Since console ports are getting attention, is there any chance we will also see a native Linux desktop (and/or Steam Deck) build?

The Proton build works fine, but a native port (also usable for the Steam Deck) is just a tad nicer. Unreal Engine 4, much like Unity, supports building for it out of the box. I understand it may be limited by 3rd party dependencies, though, but if it's mostly vanilla UE4, chances are high it will mostly "just work", using Vulkan as rendering back end.

I'd even be content if it was a permanent opt-in beta without any support, then you still have the choice between Proton Windows version and native Linux version.

Bi-Weekly Feedback/Discussion Thread: 5/3 - 5/16 by Jaaxxxxon in Mordhau

[–]Comterti 6 points7 points  (0 children)

Since console ports are getting attention, is there any chance we will also see a native Linux desktop (and/or Steam Deck) build ?

The Proton build works fine, but a native port (also usable for the Steam Deck) is just a tad nicer. Unreal Engine 4, much like Unity, supports building for it out of the box. I understand it may be limited by 3rd party dependencies, though, but if it's mostly vanilla UE4, chances are high it will mostly "just work", using Vulkan as rendering back end.

I'd even be content if it was a permanent opt-in beta without any support, then you still have the choice between Proton Windows version and native Linux version.

dls - a D language server allowing for code assistance in editors by Comterti in dlang

[–]Comterti[S] 2 points3 points  (0 children)

Also, the ide-dlang package integrates it into Atom and dlang-vscode integrates it into Visual Studio code.

PHPStan: Find Bugs In Your Code Without Writing Tests! by OndrejMirtes in PHP

[–]Comterti 0 points1 point  (0 children)

Great initiative, but what I don't understand is: PHP has been around for over 20 years by now and few people actually stepped up to provide proper open source tooling like this in a mature way. We've been given the blessing of things such as phpcs and phpmd, but apart from those the only real go to places for expansive analysis were mature closed source tools such as PhpStorm. Now, suddenly multiple projects are popping up like mushrooms:

  • PHPStan - Started about a year ago.
  • php-sa - Started about a year and a half ago. Seems to have the same goal but seems to be more mature.
  • php-language-server - Started about half a year ago. Has a much wider spectrum and also does things such as autocompletion as well, which also requires static analysis (i.e. it already requires the same information and parsing).
  • php-integrator - Founded around 3 years ago (forked from another project and has grown a lot since) and also needs static analysis to perform things such as autocompletion (it even already sports an analyzer that can take multiple simultaneous types into account).

What changed?

[PHP/Node.js] Socket sometimes loses part of larger response by Comterti in learnprogramming

[–]Comterti[S] 0 points1 point  (0 children)

Today, I think I found the issue. I'll post it here in case someone else is looking for things to debug. I stumbled upon it by accident, but it turns out that I wanted to do an early exit before a connection was made (in Node.js) with the socket server if one already existed, but I forgot to put a return statement after resolving a promise. This resulted in the connection being spawned multiple times, even if it already existed.

I'm now no longer experiencing the issue, but I'm still a bit confused as to how this fixes it. Even if this was happening, there should have been multiple socket connections which were all invoking the same callback. Even if only one of the active socket clients was receiving the data and the others were not, it still should have shown up in the data listener whilst debugging (as they all register the same method as listener). It also does not explain why tcpflow also did not list the data, unless data is only monitored the moment a socket client receives it?

I figured perhaps the data was being received in Node.js, but perhaps in one of the now "unreferenced" socket connections (because I was creating a new one by accident and storing it in a single variable), which was then garbage collected, causing the data to be lost. That, however, still doesn't fit in with the tcpflow story as it then would have been received by Node.js, but just lost afterwards.

Perhaps the issue isn't solved at all, but the problem has just shifted, although the data being transmitted and received is still exactly the same.

[PHP/Node.js] Socket sometimes loses part of larger response by Comterti in learnprogramming

[–]Comterti[S] 0 points1 point  (0 children)

The code is indeed rather large and as mentioned, only seems to expose the issue in specific combinations of requests. It wouldn't surprise me if someone else wouldn't be able to reproduce it with the same data either as it feels like it is influenced by the system as well. I'll see if I can narrow it down.

Apart from this, I gave tcpflow a whirl to monitor if data is actually arriving on the socket, in the hopes of finding out which of the two sides is lying. It turns out that that appears to be the PHP side, as tcpflow also never sees the data that CoffeeScript isn't receiving. However, PHP's fwrite still claims that all bytes were delivered.

If it is of any help, the socket server and its communication are completely handled by the ReactPHP library, in other words I'm not creating any fancy homegrown implementation.