Pyrax

This is a known bug. I've been informed this happens because they added code prevent player ship loss during a server crash. Hopefully they'll add code later to check/remove duplicate ships. For now, enjoy your extra free ship....

Is there a server administrator for the Official Test Server who might be able to hop on and use the "/addcrew" command on the player stations in sector (9:36)? ^That neutral zone sector is currently like the community hub and many stations had their crews wiped by the bug. Thanks in advance!

Thanks for the info, that's definitely preferable vs losing a fully outfitted ship!

Thank you for the continuous work on the game! Please update the Official Avorion Test Server to 0.15.1 when you have a chance, it's still at 0.15 :'( Edit: Server is now 0.15.1 - Thanks!

I've already submitted a bug report but I'm posting here for supplemental information (screenshots) and to see if anyone else has seen this. Server: Avorion Public Test Server [beta branch] [EU] Date: 25 Nov 2017 Time: some time between v0.15.1 and the v0.15.1 hotfix The bug involved hopping sectors during a server crash, and now I have: - Duplicate ship (identical ship name) - Duplicate crew - Duplicate system upgrades - Duplicate turrets The other ship: The fleet list (look through the menu to see both ships): The map view (showing two ships of same name): The most curious part is that the game seems to allow both ships to exist with the same name. I can also go into build mode and repair the ships. I haven't tried modifying either ship in build mode though (other than turret placements). Either ship will follow orders and both seem to be entirely independent entites. When it's time to pay for crew, only 1 ship's worth of credits is deducted.

I can confirm the jump gate movement bug. Any movement inputs at the time of gate jump are added to your default movement in the new sector and the only other way to clear it is by entering "strategy mode" (one of the F keys). I've gotten in the habit of drifting through gates to prevent this. I can also confirm the docking bug which doesn't allow for strafe or roll inputs until after using main engines.

I don't know if this would technically count as a bug. An Avorion unit is equal to 10m, so a 5000 unit block is 5km (that's 3.1 miles in freedom units) aka that block is gigantic. You're probably reaching the limits of the rendering engine or the game's physics engine or both. Not sure how much that block costs but it's unlikely that most people would be able to afford a ship with blocks that large in non-creative mode. I have made a scale model of an Executor Class starship which is 19km long (crew costs = 10mil/hr) although it is comprised of many blocks end-to-end. That ship does some wonky things with the game engine regarding rendering in build mode, ship previews, and even flying around it. Depending on the render distance setting the entire ship may not appear when flying around one end. If it's crashing the game though the devs may want to put in a hard limit on maximum dimensions for a single block. I've never had crashing/resource issues with the Executor Class so it's probably a single-block issue in your case, but I'm running a pretty powerful machine so nothing is certain. I'll try to reproduce and report back.

Update: It appears I am only unable to log onto the "Official Avorion Test Server EU" for the beta branch. I was able to log onto a new v15 beta branch sever that I found in the public server list which I had never connected to before. I'm not sure if it's something server side with the official test server (I've had issues before with that one) or if it has to do with the fact I had played on the server prior to the latest update and the update broke something with existing players.

I cannot connect to the official Avorion test server either. It seems the server is also blocking me: 2017-11-14 23-53-51| Startup successful. 2017-11-15 00-14-03| Client UDP: Error receiving from 127.0.0.1, error: No connection could be made because the target machine actively refused it, received bytes: 0 2017-11-15 00-14-05| Connecting to 85.25.177.36:27000, query port: 27003 2017-11-15 00-14-05| Waiting for Online polling threads 2017-11-15 00-14-05| UDP closed 2017-11-15 00-14-05| Client UDP: Connection closed 2017-11-15 00-14-05| Online polling threads finished 2017-11-15 00-14-05| Waiting for LAN polling threads 2017-11-15 00-14-05| LAN polling threads finished 2017-11-15 00-14-05| remote address: ip, init: steam 2017-11-15 00-14-05| Connecting to server at 85.25.177.36:27000 2017-11-15 00-14-06| Client UDP: Error receiving from 127.0.0.1, error: An existing connection was forcibly closed by the remote host, received bytes: 0 2017-11-15 00-14-06| Initiating connection with server ID 90111928692288515 2017-11-15 00-15-06| UDP closed 2017-11-15 00-15-06| Client UDP: Connection closed 2017-11-15 00-15-06| remote address: ip, init: ip 2017-11-15 00-15-06| Client: attempting to connect to 85.25.177.36:27000 2017-11-15 00-15-06| Client UDP: Error receiving from 127.0.0.1, error: An existing connection was forcibly closed by the remote host, received bytes: 0 2017-11-15 00-15-06| Client UDP: Error receiving from 127.0.0.1, error: An existing connection was forcibly closed by the remote host, received bytes: 0 2017-11-15 00-15-06| UDP closed 2017-11-15 00-15-06| Client UDP: Connection closed 2017-11-15 00-15-07| Client TCP Error: Connect failed, error: No connection could be made because the target machine actively refused it 2017-11-15 00-15-07| 2017-11-15 00-15-07| Connection to 85.25.177.36:27000 failed: Client TCP Error: Connect failed, error: No connection could be made because the target machine actively refused it 2017-11-15 00-15-07| 2017-11-15 00-15-07| UDP closed 2017-11-15 00-15-07| Client UDP: Connection closed 2017-11-15 00-15-07| wanted to establish a connection to IP, but failed 2017-11-15 00-15-13| Startup successful. 2017-11-15 00-15-16| Client UDP: Error receiving from 127.0.0.1, error: An existing connection was forcibly closed by the remote host, received bytes: 0 2017-11-15 00-15-19| UDP closed 2017-11-15 00-15-19| Client UDP: Connection closed 2017-11-15 00-15-21| Connecting to 85.25.177.36:27000, query port: 27003 2017-11-15 00-15-21| Waiting for Online polling threads 2017-11-15 00-15-21| Online polling threads finished 2017-11-15 00-15-21| Waiting for LAN polling threads 2017-11-15 00-15-21| LAN polling threads finished 2017-11-15 00-15-21| remote address: ip, init: steam 2017-11-15 00-15-21| Connecting to server at 85.25.177.36:27000 2017-11-15 00-15-21| Client UDP: Error receiving from 127.0.0.1, error: An existing connection was forcibly closed by the remote host, received bytes: 0 2017-11-15 00-15-21| Initiating connection with server ID 90111928692288515 2017-11-15 00-16-21| UDP closed 2017-11-15 00-16-21| Client UDP: Connection closed 2017-11-15 00-16-21| remote address: ip, init: ip 2017-11-15 00-16-21| Client: attempting to connect to 85.25.177.36:27000 2017-11-15 00-16-21| Client UDP: Error receiving from 127.0.0.1, error: An existing connection was forcibly closed by the remote host, received bytes: 0 2017-11-15 00-16-21| Client UDP: Error receiving from 127.0.0.1, error: An existing connection was forcibly closed by the remote host, received bytes: 0 2017-11-15 00-16-22| UDP closed 2017-11-15 00-16-22| Client UDP: Connection closed 2017-11-15 00-16-23| Client TCP Error: Connect failed, error: No connection could be made because the target machine actively refused it 2017-11-15 00-16-23| 2017-11-15 00-16-23| Connection to 85.25.177.36:27000 failed: Client TCP Error: Connect failed, error: No connection could be made because the target machine actively refused it 2017-11-15 00-16-23| 2017-11-15 00-16-23| UDP closed 2017-11-15 00-16-23| Client UDP: Connection closed 2017-11-15 00-16-23| wanted to establish a connection to IP, but failed 2017-11-15 00-16-25| Startup successful. 2017-11-15 00-17-10| Exiting client. 2017-11-15 00-17-10| Exited client main loop. 2017-11-15 00-17-10| Waiting for Online polling threads 2017-11-15 00-17-10| Online polling threads finished 2017-11-15 00-17-10| Waiting for LAN polling threads 2017-11-15 00-17-10| LAN polling threads finished 2017-11-15 00-17-10| Stopping local server ...

When you say "nods" I assume you mean the front of the ship dipping "down" before beginning the turn? I believe this is due to the pathing algorithm trying to find the quickest way to get your ship from the direction it's currently pointing to the direction you've asked it to face. I have had this happen on very large ships where the front dips "down" then the ship rolls "left"/"right" and finishes by bringing the front of the ship "up" to face the intended direction. This is due to the pitch thrusters/gyros being more powerful on your ship than the yaw thrusters/gyros. Therefore if the ship simply tried to use your yaw to turn left/right it would be slower. It's quicker to roll the ship and then use the pitch thrusters/gyros. Be aware on very large ships this may cause you to hit other objects if you're not paying attention when the ship executes a "nod" turn.

You can improve faction standing with other players by trading with thier stations. If you don't have any stations you'll need to build some first.

Do you know which ship started the problem? If so, can you do the following test: 1) Transfer crew to from ship with the original problem to a new ship (Ship #2). 2) Confirm that Ship #2 now has the issue 3) Transfer crew from Ship #2 to yet another ship, Ship #3 (do not let Ship #3 interact with Ship #1) 4) Report back if Ship #2 still has the issue and if Ship #3 has the issue Following those specific steps may shed some light on if the problem is infectious, as in stays permanently with intermediate ships by messing up their instances thus enabling them to spread the issue. Or if it only affects the original Ship #1 and the excess crew in Ship #2 is just crew duplication.

Have you tried deploying the fighters after the Xotan have become aggressive? Just wondering if they are deployed and do an initial check and see the Xotan as neutral (purple) and fail to update when Xotan go aggressive (red) or if they just fail to engage no matter when they are deployed.

So first, I did view the screenshot before posting. The number shown is short scale billions 10^9, not long scale billions 10^12. I am not familiar with EU counting as I am an American engineer. Based on what I read on the wiki about long scale usage I assumed the EU used long scale since it says most of Europe: https://en.m.wikipedia.org/wiki/Long_and_short_scales That is why I was questioning the validity of the reported numbers. I specifically have been using scientific notation (10^exponents) to avoid linguistic confusion. There was no screenshot showing the 2.7 billion so I can't confirm if it was actually 2.1 or 2.7 billion. --------------- I appreciate that you posted the screenshot and wanted to make sure I viewed it, but trying to flame me with your comments is unnecessary and not productive for getting this bug resolved.

I thought this initially but didn't post the reply I had drafted because he said EU billions (10^12) not using the American/British short scale (10^9). Also he said 2.7 Billion so even if it was short scale (10^9) it doesn't check out. 2^31 = 2.147x10^9 not 2.7x10^9 so either way the numbers don't match his report. Although 4.3 Bil does match if you assume short scale because 2^32 = 4.295x10^9 --------------------- Therefore, assuming the reported numbers are incorrect, and they were actually 2.1 Bil and 4.3 Bil using the short scale (10^9) then I'd offer the following root-cause analysis: I would venture to guess that the ship data in Avorion is stored in class-based instances which hold all pertinent ship information? I would further speculate that the crew values for that specific ship are stored in standard LONG data types (32-bit integers) since standard INT would only allow for about 32k of each crew type. This class data is probably accessed from the main Avorion code using data call functions in order to do displays and transfers. My guess is that at some point that crew value became corrupted for the ship in question. Depending on the coding language used for Avorion source, this corrupt number may be equal to negative zero: (-)0. Negative zero in binary for a signed integer is (1000 0000 0000 0000 plus 16 more zeros). I would speculate that Avorion has code which checks for a negative numbers since they are not allowed for calculations. This is probably done by looking for numbers less than zero (crew < 0) and then forcing this number to be positive or zero depending on what the devs chose. Although (-)0 is not < (0) in many code bases, although (-)0 may or may not == 0. If this is the case I assume that something in the code is forcing the signed complement (0111 1111 1111 1111 plus 16 more ones) which = 2^31 = 2.1 x10^9 (2.1 Bil in short scale units). This compliment is probably caused by whatever is calling for the corrupted data in the ship instance for doing the calculations. When you go to transfer the corrupted value to the new ship, it transfers the values and now you end up with 2.1 Bil in each ship, so now you have 2^32 crew = 4.3 x10^9. I would guess that ship #2 legitimately now has 2.1 Billion crew and if you did it a second time you now have 4.3 Bil in ship #2. But I'd guess if you transferred the ship #2 crew to another ship (#3) then ship #2 would actually be empty. It's probably just ship #1 with the corrupt instanced data, but from this you could theoretically farm Billions of legitimate crew at a time doing crew transfer. TLDR: Probably an issue with the integer bit math (2^31), and/or a signed integer issue with +/- zero, and/or a 1's or 2's complement issue. If you can crack into the stored data for the ship's instances you could probably see what the saved value was in that table and then figure out the problem from there. If you can view this data from the server files have the owners send you the files dictating the name/location of the ship in question so you can view the crew values the engine is referencing.