Friday Facts #175 - Programmable Speaker

[Supercheese]

Would be great to have a Lua API for playing sounds (ie. without need to add entity to map).

Indeed, it would be nice - even though the current method isn't that bad.

[AssaultRaven]

Will the alerts be able to show their location on the map? The first thing I thought to do with custom alerts is have bunkers and mines let me know when their logistics systems run low on repair packs or construction robots, but when those bunkers are part of a wall their could be a huge number of them so it would be convenient for them to have the same ability to make a map icon as the attack alerts, so I can just look to see which one is throwing the alert.

[Twinsen]

Will the alerts be able to show their location on the map?

Yes.

[dinodod]

Devs,
in regards to your issue with the map not downloading, I have several thoughts on this.

1) Does this packet get blocked by all firewalls or only certain ones? If some, which ones? Have you contacted the firewall vendors to explain it?
2) Can you allow an exception in the firewall to bypass the block? This is a normal solution for firewalls and might be a simple solution.
3) ips / Firewalls are very complicated, a package that seems innocent enough is also a package that malware / virus authors use to attack a system or the firewall makes an educated analysis of what it could do. It's best to work with a rep from firewall company to determine the cause.

Now if you could do something about the lag with thousands of bugs on the map, that would be great! As I understand it, once a base is found, the bugs stay in memory to calculate movement? Is there any possibility to fix this, like not loading those chunks / regions when outside the radar? Just use a static icon to represent the last known information of the region / chunk?

Also, when fighting bugs in large maps, there is the sudden lag while the system updates everything. Is there any way to stop this until after the fight then slowly update the information somehow? Or is there another solution?

Thanks for the great game. Looking forward to the next update!

[dinodod]

In regards to the sounds, please let there be some admin control to disable people from spamming it. Also, what's to stop someone from loading up a file that annoys everyone or worse?

[tobias.soltermann]

Hello there.

I found a partial explanation of your problem about the UDP checksum and posted it on stackexchange (http://networkengineering.stackexchange ... s-filtered#)

You might be subject of the fact that in IPv6, correct computation of UDP checksum is mandatory. A nil value (0x0000) means that the checksum is left out and therefore an invalid value for any IPv6 UDP packet. See en.wikipedia.org/wiki/User_Datagram_Protocol#IPv6_Pseudo_Hea‌​der. Although your communication is based on IPv4, the ISPs still may route it over some IPv6 networks even if you don't. Got no explanation about 0xFFFF though

Meanwhile, I've dug out the RFC which states that neither a value of 0x0000 nor 0xFFFF are valid. In one's complement, both of them are equal to 0 (+0 vs. -0.)

Please see https://tools.ietf.org/html/rfc1624 on Page 2 and 3:

3. Discussion

Although this equation appears to work, there are boundary conditions
under which it produces a result which differs from the one obtained
by checksum computation from scratch. This is due to the way zero is
handled in one's complement arithmetic.

In one's complement, there are two representations of zero: the all
zero and the all one bit values, often referred to as +0 and -0.
One's complement addition of non-zero inputs can produce -0 as a
result, but never +0. 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 -0 (0xFFFF). It can, however, contain
~(-0), which is +0 (0x0000).

Your packets can get routed over IPv6 networks by the ISP's even if you don't do it on purpose.
As IPv4 allows an invalid or absent checksum (=0x0000) while IPv6 doesn't, you might therefore hit the fact that your packet gets dropped in this case.

I'm a Cisco-certified network engineer and software developer. Feel free to PM me for further questions.

Tobias

[sigillum]

I'm a Cisco-certified network engineer and software developer. Feel free to PM me for further questions.

You may want to read that RFC again. It's talking about a checksum of the header, the one in the IP header. The UDP checksum includes the data (this is another checksum) ... so it definitely can be 0x0000 (which becomes 0xFFFF).

Quite likely, there is some router out there that is calculating the checksum in a different way, by computing a new checksum using 0x0000 for the checksum field, and comparing the result (instead of doing a new checksum over everything and making sure the result is 0x0000). It probably forgets to treat 0x0000 and 0xFFFF as equal.

There is a better thread for that discussion, btw: viewtopic.php?f=49&t=32646

[gunmaker]

Weekly dose of Factorio news: https://www.factorio.com/blog/post/fff-175

someone sure knows there stuff!
https://www.youtube.com/watch?v=-TtA0chzLac

[Jap2.0]

Weekly dose of Factorio news: https://www.factorio.com/blog/post/fff-175

someone sure knows there stuff!
https://www.youtube.com/watch?v=-TtA0chzLac

Nice necro.