phezzan

It's probably lag. yes, I quit playing because of lag in single player (localhost) that would wreck the 'server' and require a server restart, and the server was on localhost.

version? I think 2.0 really nerfed the basic mining/salvaging commands in favor of the Expert Captain commands. Also if you don't have a captain - the ship won't do anything if you aren't present in the sector. Assuming you do have a captain... (any captain) If hours later the ships haven't complained about 'out of targets' or 'out of cargo space' then maybe move them to a new sector and re-issue the command.

Sometimes when I start the client, there's no sound on the right speaker. Other applications make sound just fine. I restart the client and usually the sound is fine.

I have a vague belief that turret settings are lost, almost all the time. Pre-1.0 I think they were lost when changing ships across sectors. I imagine the code that saves and loads the turret settings isn't the same code that saves and loads the ships.

Yes, I too have the problems you describe. Yes, they were present before v1.0 Yes, they are still present in 2.0.9 While client performance certainly drops when many objects are on screen, the problems you're complaining about aren't related to the number of objects, the speed of processors, or the latency of networks. I'm running a server on localhost, giving it 8 (out of 12) threads on a 5600X with 16GB of RAM. The server isn't using those cores much - and there's no way to strain the network on localhost. As for RAM, the client stays under 3GB and the server stays around 2GB. Resource-wise there are zero problems. The problem is clearly a multi-threaded deadlock. If the game had a 'single-threaded' mode that removed all mutexes and semaphores and TCP messaging, I'm sure it would run fine. I'm a C / python / etc programmer. I've written real-time systems with sub millisecond timing requirements. I've also done plenty of batch processing, API request processing... etc. Game programming is harder than all that. I think I've met two programmers in my entire life who had the chops to code a multithreaded game engine. Both of them make more money than any game company could pay. Multithreaded code is rare because deadlocks are very very hard to figure out. I've known quite a few decent programmers, and many very good ones. Almost none have the chops for games. In fact I'd say that if we confined the set of game-programmers to people capable of writing multiplayer engines, we would never see a real-time 4x space game. We'd be stuck with single threaded space games, because the top tier multithreaded multiplayer engines aren't simulating any part of the world where players aren't present. Lets take a tour. Elite Dangerous - Had roughly $1.8 million in funding. IMO the best space game available - also multiplayer. Last I checked it still has connection problems where you just get booted and can't log back in until the servers get rebooted. Is that a multithreading problem, a networking problem or a database problem? Don't know but it wouldn't surprise me. Star Citizen - $300 million (according to wikipedia). Unreleased even after 7 years. X - ALL SINGLEPLAYER. First 3 games were single threaded. First multithreaded game ("Rebirth") took years of development and released missing tons of expected features from previous games AND was super buggy for years. Egosoft even skipped numbering for it and launched their 5th game as "X4 Foundations" to convince their fans that they've re-implemented lost features that defined the first 3 games. Stellaris - Largely single threaded. Can't handle a heavily populated medium to large universe because they've coded an NP algorithm to update populations and they can't multithread it (and apparently can't optimize it although one would expect memoization would work well enough). World of Warcraft - Single threaded, Used TCP - lost packets would freeze the game. I had a Linksys router with a firmware bug that occasionally, but reliably miscalculated a tiny fraction of TCP checksums. WoW was unplayable because one lost packet and you lost control. Skyrim - primarily single threaded, zero networking, shipped without optimizations, a user noticed this and made a mod that restored like 20% performance by inlining just a few of the most important tiny function calls. I don't recall how many months (but multiple patches) later it they turned on optimization in a patch. The volume of fixes in 3rd party patches dwarf Bethesda's officially released patches. But enough of that - lets find out how much harder it is to write a multi-threaded program that actually uses concurrency without introducing deadlocks: If you have the problem and the chops, then whip out wireshark and a debugger and identify the source of the deadlock. I've seen entire codebases scrapped and rewritten from scratch because these problems are very tough to identify. Good luck, a lot of people will be very happy if you succeed.

Welcome to server controlled calculations. Most multiplayer games have mechanics to allow the client to 'hit' despite the lag in their gamestate. admittedly this is where making multiplayer games get hard. https://docs-multiplayer.unity3d.com/docs/develop/learn/dealing-with-latency/index.html

Yep - Since thrusters are low HP it makes sense to wrap them in armor or larger ship parts anyway. Also - the smaller your thrusters are, the smaller the exhaust plume will be.

I doubt the game cares who killed the station. I have left those sectors without killing the station (50% of 300k HP in Titanium is still too much) Returned (without abandoning quest) to find TWO stations!

Projectiles can also skip thin armor and hit inside your ship too. Need to use line segment collision between old and new projectile position - similar to beam collision - to ensure the 'first' thing gets hit properly.

It got real frustrating chasing the quest Target's lackeys as they zip away while their invulnerable boss pelts me to death because I can't hit them at long range, nor catch them with engines.... My ship wasn't so OP that I could tank the boss for 10 minutes while I chase down each little runner - had to jump sector. Re-entering a quest sector where you had killed some, not others,... always fun when the quest script re-adds things.

Wonders if 'stolen steel' got into the turret requirements somehow...

Was testing reintroducing the --ip parameter to the dedicated server to see if that reduced crazy network troubles described: Everything was fine for a while, updating ships, moving sectors, trading a bit, salvaging, pirate and xsotan attacks with the usual problems (ship destruction often takes 10-20 seconds to 'figure out' where the wrecks are. /say foo worked instantly ... after an hour or two... Then I switched to a sector where my trader lives (a shipyard is present) and attempted to upgrade his Titanium bits to Trinium. The server refused to comply (described in above thread). I closed 'build' and reopened it and some of the components got updated, I attempted to update more. Again the server did not comply. I started using /say to verify the latency. the server console was responsive. The client didn't receive the first say 'foo' for what seemed like 30-45 seconds. The client never received the 'bar' say at all. I exited the client normally. I waited a little on the server console. (no action) I entered "/stop"... (no response) I went ahead and opened Task Manager, and expanded the server affinity from 8 cores to all 12 cores. Eventually the server dumped 8000 errors about the client disappearing, saved and exited. Server CPU usage was always less than a single core. Server RAM usage was under 3GB Client RAM usage was around 2GB Machine is an AMD 5600X 16GB @3600Mhz (Manufacturer rated speed/timings) Machine is not overclocked, runs below 65C at all times. serverlog 2021-11-05 02-33-32.7z clientlog 2021-11-04 21-34-01.7z

Interesting - I had occasional problems back when I was using "--ip 127.0.0.1" but I recently removed it to troubleshoot "Join LAN" The problem got a TON worse around that time. This is an excellent observation!

You can use the Steam UI instead. Just right click on Avorion and 'Uninstall' . Seriously - you deleted your profile, save game, config, mods... And you call that "Fixed"? I'm having the same problem - but after about 45 seconds the changes do (mostly) occur. It's being caused by the server hanging and not accepting and returning results to the client. The huge question is why does this happen? Ideally an interrupt timer would recognize the 'hung' thread and print out the function name, parameters, and queued job information that isn't getting completed and is blocking the rest of the server.

Not in my experience. back in 1.x I ran a server using RAMDISK. Other than sector loading time (and me forgetting to copy back the data before power down) I didn't see a difference. This makes sense because the game keeps sectors in memory and only occasionally saves them to disk, so other than loading time your disk shouldn't matter. OTOH increasing system/turret storage to 1 million will wreck you. The illegal cargo scan code will loop over everything in your inventory looking for licenses. It doesn't even stop once it finds a license, and it doesn't remember that it just did it for a different 'scanning' ship, or even that your escort would have the exact same inventory as you. So the number of loops over your entire inventory equals: #SCANNER_SHIPS x #PLAYER_SHIPS So if there are 3 scanning ships in sector, and you have 3 escorts: 3 x 3 = 9 So every scan time period it will inspect your player's entire inventory 9 times. PS: Wreckages are also very heavy as each separate bit has to be tracked and updated.