I'm trying to get car energy readings (i.e. the amount of fuel), but I get weird results, namely player.vehicle.energy seems to contain only three possible values depending on the driving direction - when not moving it always contains the value 2666.666, when going forward it's 166.666 and when goin...

nou_spiro on Reddit pointed this out: Hmm actually 0xFFFF seems invalid accordig to RFC1624 Since there is guaranteed to be at least one non-zero field in the IP header, and the checksum field in the protocol header is the complement of the sum, the checksum field can never contain ~(+0), which is ...

If you're generating the checksum based on the entire packet generated just before sending it off, there's no surprise that you'll end up with inconsistencies. If you're generating the checksum from the actual payload data, then packaging and sending it then that should be consistent. If you're sen...

My guess is that either your client code or your server code also incorrectly sets the checksum to 0x0000 instead of 0xFFFF. That would be the OS or, at the very least some library they're using - I can't imagine Wube have re-written UDP implementation. And anyway, as it is only outside the NAT tha...

I have marked my code as using MIT license, so yes, you may alter it and post a derived version. Basically you are only required to give credit and include (I believe linking is enough) the original license.

See: https://tldrlegal.com/license/mit-license

With the possible simple fix of checking outbound checksums and "fixing" the packet to make this particular one impossible. (Is this possible? I haven't worked with UDP much) This would only work if the problem is in the first NAT (the one in the router of one of the players), as the chec...

I have posted my guess on the original thread, but I have no real way of further verifying it without the help of someone affected.

TL;DR - possible bug in one or more routers along the way when UDP checksum is 0x0000.

Not sure it helps, but I have a guess as to the reason - it may have to do with UDP checksum and tunneling through IPv6. Basically, UDP checksum is optional in IPv4, but not in IPv6, and a wrong or missing (all zeros) UDP checksum will result in a packet being dropped. What I suspect/guess might be ...

Is this option only relevant when hosting, or is this client-side?

Also, the config file now has "minimum_latency_in_multiplayer". Can you confirm which is the correct parameter (Or are there two?)

... Added minimum_latency_in_ticks to server settings (for headless server) and into config (for starting game from gui). There is no "minimum_latency_in_ticks", but there is "minimum_latency_in_multiplayer". Should I add "minimum_latency_in_ticks", or is this a typo? ...

Can you try changing to the modsetting kernel driver? See: viewtopic.php?f=49&t=21205

I think I may be facing a similar problem: viewtopic.php?f=49&t=34375

Maybe add an option to limit the minimum latency? Or lower it more gradually, dynamically calculating a "safe" lower bound?

I'm trying to play multiplayer, but I keep getting "Server is not responding" and lag every few seconds, which makes the game completely unplayable ( this post on reddit has a video demo of a similar problem, but no answers). Granted, my connection isn't super-fast, but with 15Mbit down an...

Maybe it should just say "Next summer"

Tinyboss wrote:It doesn't look like two trains can make opposing left turns simultaneously.

They can't - the entire middle is one block.

http://semver.org/

Also, 0.3≠0.30 !!!
0.12.0 is "zero point twelve point zero" (Or replace "zero" with "naught" or "Oh", if you prefer), but definitely not "One point two" or "zero point one point two"

I don't get an overlap on my 1366x768 laptop monitor, with UI scale set to default... So probably you set the UI scaling too high.

And I seem to remember someone once giving 1024x768 as the minimum resolution, but I'm not sure.

LOL, I remember when they used to look like this anywhere, then the end-pieces got added, to help finding dead-end which the player may think are connected but aren't

Here's the post : Headless binaries are only 64bit. We generally want to slowly move from 32bit builds (because they cause some extra problems), and thought that headless releases are a perfect candidate for a first step. If your machine has X libraries, you can use the regular 32bit binares (they ...

I seem to remember the devs saying there won't be a 32 bit headless version....