On Windows, we cannot resolve addresses using getaddrinfo() before
initializing Winsock. By storing the address as string, the address
parsed later on.
Forcing a static address does not work for IPv6 where everyone has
multiple addresses that change over time. For example, adding a new
connection would fail if the preferred privacy address changes during
a game.
On Linux, all IPv6 sockets are dual-stack per default; on Windows, they
are not. It's still a good idea to set the option on Linux as well as
the default value can be changed.
When connecting via TCP, C4NetIO still creates IPv4 sockets, so no dual
stack option is required there.
It's not actually used anywhere, but it's not broken now!
This also moves the low-level and OS-specific GetLocalAddresses code to
C4NetIO where it's fitting better than in C4Network2Client.
We use ff02::1 as discovery multicast address.
This "all nodes" multicast address is good enough for discovery in the
local network as packets there are likely broadcasted over ethernet
anyways.
When many PXS were at the same location (e.g. because of fast/multiple pumps pumping into a basin), only one PXS per frame could be inserted because insertion of one PXS would postpone insertion of additional PXS in the same frame until they finished their slide movement.
This caused some scenarios like Rapid Refining to become very frustrating, because adding extra pumps didn't actually do anything (unless you tricked the insertion by putting the output into the basin).
Now insert them directly if slide movement led to an insertion position.
This should not break anything because script players are created by scripts and one may expect sane behaviour. This is useful to block entry for normal players into a team.
The extra object is called "Magma" to distinguish it from Lava and has a slightly different color on the symbol. In the pump menu, only "Lava" is shown and magma is turned on/off with it automatically.
It would be nice to have only one object and control a flag somehow. However, this is bound to cause us headaches later on (combining materials, etc.). This solution is probably least error-prone.
This is the goal in defense scenarios and controls the waves. In the future a league interface can also be build. The goal is to adapt the existing defense scenarios to this format (mostly internal changes and infinite waves). Also this should allow for easier creation of defense scenarios.
Using objects was blocked by the GUI menus and the ObjectControl() function anyway, but (!) it was not blocked for the old style menus that can still be used.