Jump to content

phezzan

Members
  • Posts

    61
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by phezzan

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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.
  8. 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!
  9. 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.
  10. 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.
  11. Wonders if 'stolen steel' got into the turret requirements somehow...
  12. 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
  13. 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!
  14. 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.
  15. 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.
  16. You mention thrusters... What about engines? I'm pretty sure that thrusters don't do anything for 'forward'. Also - if this were a bug, nobody would ever have been able to play for even 1 minute, so unless there's some special circumstance you'd like to add, I suggest RTFM
  17. Yeah - It's like the server is getting stuck all the time. I'm running a server and client on a Ryzen 5600X with 16GB of RAM. I'm the only player. Often the server will start to lag out. Today I switched windows to the server console and tossed in a say: ... 2021-10-31 15-55-30| <> The crew of your ship 'Fluffy' was paid. 2021-10-31 15-55-31| <Server> doom 2021-10-31 15-55-32| <> The crew of your ship 'Fluffy' was paid. 2021-10-31 15-55-34| <> The crew of your ship 'Fluffy' was paid. 2021-10-31 15-55-36| <> The crew of your ship 'Fluffy' was paid. 2021-10-31 15-55-38| <> The crew of your ship 'Fluffy' was paid. 2021-10-31 15-55-40| <> The crew of your ship 'Fluffy' was paid. 2021-10-31 15-55-42| <> The crew of your ship 'Fluffy' was paid. ... 36 seconds later it showed up on the client. 2021-10-31 15-56-04| The crew of your ship 'Fluffy' was paid. 2021-10-31 15-56-06| <> The crew of your ship 'Fluffy' was paid. 2021-10-31 15-56-06| The crew of your ship 'Fluffy' was paid. 2021-10-31 15-56-07| <Server> doom 2021-10-31 15-56-07| doom 2021-10-31 15-56-08| <> The crew of your ship 'Fluffy' was paid. 2021-10-31 15-56-08| The crew of your ship 'Fluffy' was paid. 2021-10-31 15-56-10| <> The crew of your ship 'Fluffy' was paid. 2021-10-31 15-56-10| The crew of your ship 'Fluffy' was paid. Of course everything is unplayable. I solved the problem by quitting the client and killing the server window. Just like I had to do yesterday.
  18. Similar problem. I'm starting the dedicated server through a batch file (to set it high priority and give it 6 threads via AFFINITY) Can't "Join LAN" "Join IP" (127.0.0.1) works - but it sits there doing nothing for a full minute, then it 'connects' and loads. Very Often the connection seems to 'break' and ships start rubberbanding, pickups don't.... etc. This is all on a 5600X with 16GB of RAM and no issues in other games like Overwatch / Witcher 3 / etc. Messed with firewall - it's allowed for both EXEs in Public/Private/Domain. Would really love to solve the rubberbanding.
  19. removing steam CRUFT sounds like a good idea. I'll probably go try that and see if my 1 minute connection wait time to 127.0.0.1 gets better.
  20. This game does something terrible with VRAM. The whole game should fit in like 1GB of VRAM and yet I have to run medium Planets and backgrounds on my 4GB rx470. I can run modded Skyrim 64 with 2k textures like butter - the idea that this game is straining my VRAM is silly.
  21. I also have great performance, most of the time. It so happens that this game runs two processes, a server and a client. The server handles all the work of updating the galaxy, while the client renders the pretty. It seems to me the server and the client are often sharing processor cores. That's troublesome. So I set the affinity for the server to run on cores 3-6, and then everytime I start the client I have to forcibly set it to cores 1-2. That works much better, but STARTING A GAME IS REALLY ANNOYING. also - for some reason connecting to a running server on 127.0.0.1 takes forever - like 2 minutes, while single player starts instantly. Haven't figured that one out....
  22. Having to fly within 2km of the mining target certainly does get annoying.
  23. Presently, you have to wait for cloning to finish before you can order training. This is frustrating and fixing it would be great. Benefits: Not having to jump/switch to all your crew factories (stations / ships) every 15 minutes. Less ships damaged/destroyed because you never remembered to finish crewing them up. Makes crew 'training' more like a factory - and isn't that the point of cloning? Suggestion: Don't 'remove' crewman to the academy until training starts. Crew 'in training' should still count toward crew limits (crew quarters, sergents, leutenants, etc) Allow the academy to queue training beyond the available crew on the ship - even beyond the crew capacity. When (the academy queue exceeds the available crew) and (the ship is not full on crew) cloning starts. Allow a toggle to set the 'target' crew counts and automatically queue 'training' for any missing crew. (or fold it into existing 'auto-assign') Crazy ideas: Missions to gather/provide crew to stations / damaged ships / derelicts Shipyards buy crew (as an input like research stations or trade depots) Crew die from hull damage. Sergeants train to become Lieutenants -> ... -> Generals (which provides a non-money cost to large ships)
  24. I could see this stuff useful in a scripted API - As for the rest - you'd really be better off with a hotkey to show the targetted ship's UI and make the changes as if you were in control. Obviously the button would print an error if the target wasn't 'yours'. This has 3 advantages: - Able to 'fix' the ship from the command screen or the map - which is super handy. - Doesn't wipe out any orders that the target ship has - like a giant mining loop (alternatively let me 'save' order loops) - You don't have to switch sectors just to fix/train crew (a periodic task) Presently cloning / training crew is super painful and it doesn't save any significant amount of money. The only way it makes sense to me is to have a single - crew academy base - with an enormous crew capacity and then every time you take a crew you have to order some clones, wait 15 minutes, and place them into the academy. IMNSHO there should only be one step. The academy presently doesn't allow you to train crew unless they are already on the ship/station. cloning makes crew. Suggestion: if you have cloning and tell the academy to train - it should simply allow you to queue up both the clone and the subsequent training right then and there - one click should clone and train .
×
×
  • Create New...