Coordinate Assertion failure varies depending on type of network connection?? Huh??
Some of us have seen the familiar messages about coordinate assertion failures before (complaining that posX or posY or posZ of some particular object is outside the coordinates allowed on the map).
But here's something weird that just started happening with it in my mission script after updating from 1.65 to 1.72 today:
When testing out my mission script and seeing how it plays, I often run the server windowed on my own laptop, and I run two windowed clients also on my own laptop. Because it's a laptop with both a wireless network device AND a Rj45 jack connection network device, this means there are three different IP addresses that all lead to the same server computer from the client:
192.168.1.2 : The RJ45 wire connection.
192.168.1.49 : The wireless connection.
127.0.0.1 : Because the client and server are the same machine the loopback would work too.
Here's the odd part: I only get the assert failure on the wireless connection, not the faster cabled and loopback connections. I don't understand this. I can see it impacting performance speed, but I don't understand how slowness of network would alter WHERE the objects are to trigger the coordinate assert failure.
As a side note - a good future feature:
=======================================
Also note that because Artemis server automatically picks which IP address to use when more than one could be chosen and there's no user control to force it to pick a different one, the only way I have to force it to pick the one I want is to disable the others. (i.e. If I want it to pick the cable I have to turn off the wireless). Since servers will often have multiple IP addresses, especially if you're trying to run "headless" with a rackmount server, it would probably be a good idea to give the user more control over which IP address the server will choose when there's more than one to choose from
.
But here's something weird that just started happening with it in my mission script after updating from 1.65 to 1.72 today:
When testing out my mission script and seeing how it plays, I often run the server windowed on my own laptop, and I run two windowed clients also on my own laptop. Because it's a laptop with both a wireless network device AND a Rj45 jack connection network device, this means there are three different IP addresses that all lead to the same server computer from the client:
192.168.1.2 : The RJ45 wire connection.
192.168.1.49 : The wireless connection.
127.0.0.1 : Because the client and server are the same machine the loopback would work too.
Here's the odd part: I only get the assert failure on the wireless connection, not the faster cabled and loopback connections. I don't understand this. I can see it impacting performance speed, but I don't understand how slowness of network would alter WHERE the objects are to trigger the coordinate assert failure.
As a side note - a good future feature:
=======================================
Also note that because Artemis server automatically picks which IP address to use when more than one could be chosen and there's no user control to force it to pick a different one, the only way I have to force it to pick the one I want is to disable the others. (i.e. If I want it to pick the cable I have to turn off the wireless). Since servers will often have multiple IP addresses, especially if you're trying to run "headless" with a rackmount server, it would probably be a good idea to give the user more control over which IP address the server will choose when there's more than one to choose from
.
Login below to reply:
