I've been looking at the CPU usage as top shows it, not at individual cores. There's no telling which core does what --- unless I'd look at a thread display maybe, but with so many threads being scheduled between 56 cores, I don't feel like doing that. Top shows between about 260 and 370, so it's using between 2.6 and 3.7 cores. When I use htop, it shows 8 busy instances one of which is currently around 290%, with the other 7 between 20 and 40. There are more (I think another 8) which are below 5%. Maybe proton is limited to 8 (though I read somewhere that wine is usually compiled with a limit of 48). I'm finding what top shows more useful. In practise, it doesn't matter how much a particular core does unless you want to design or debug something. Since I can't debug or design the game or proton (or is proton open source?) and since I haven't felt like changing out the CPUs (I got the ones I wanted), there's nothing to be done about it. It doesn't get much better, if any, than 2xE5-2697 v3, unless I spend like 3000 or so on a new machine. Besides that I don't want to do that, I'd want an AMD graphics card because they're better with their drivers, but that would very strongly suggest an AMD CPU, and as long as AMD doesn't support ECC RAM, I don't want that. And good luck finding a suitable mainboard with a reasonable number of PCI slots for either AMD or Intel ... preferably with (something like) iDRAC ... I'm like always between 26 and 30 fps. With fog, lots of lights and reflective surfaces, it doesn't seem surprising that the FPS rate gets lower. However, light definitely needs to be worked on. Lights you place shine through walls, and that's very annoying. Thread load? You mean you don't get more threads when there's more to do? And you have (at least) 10 threads to begin with? When you have 10, there must be a reason why I only have 8 (unless I count the instances that don't do much). What do you consider a 'thread'? The instances in htop seem to be processes, not threads. [/quote] It makes sense that the CPUs get to do more when there's more activity. It would be cool if everything would automatically scale to the available and needed CPUs, but that's not it works ... BTW, how did you prevent your CV from being destroyed when attacking a base? When a damaged drone shoots a HV made from unreinforced steel blocks to bits and when a single missile takes out blocks with 200 hit points each in a 3m radius, attacking a base seems like a suicide endevour. The minigun turrets on my SV didn't even react; why didn't they try to shoot the missile down? Too much delay?
> Using the factory like that is kinda cheating, isn't it? > Why bother to go into survival mode at all when you do it this way? The great thing about a sandbox is, you get to pick and choose which rules you want to use. At the moment I imagine the factory is just a bunch of nanobots, each holding a piece of a block or device, and when you give the order, they all start assembling the vehicle. I still prefer the survival rules. I enjoy have POIs I can visit and buy stuff from, enemies I can find, destroy, and salvage and I enjoy doing the quests sometimes. None of that stuff is available in creative in the same manner. Besdies, 99% of the stuff I find goes into storage at either a freighter CV or a base I've built somewhere. It's not like I dump everything in the factory -- usually just enough to start the next bp production. > And I rather build something myself rather than using someones blueprint because that way, I'll learn better how to do it, and it will be built the way I want it to be. I can agree with that. I've only ever used my own BPs to be honest. I've seen lots of nice-looking ones of the workshop, but I choose to build and use my own regardless. > Why have volume limits when you put everything into the magic factory anyway? For everything else. 99% of the stuff I gather does not go into the factory. Trade goods, bulk cargo shipments (RE items), most of the salvage, etc. None of that goes into the factory. I've built a series of Freighter CVs specifically to carry large amounts of cargo. My biggest one (at the moment) has 640kL x 16 of storage space, which is a LOT. Without volume limits, I would have much less reason to build large, cool ships > I found that giving another build order just replaces the previous one, and the resources you put in are all available for the new order. And the ones that were not used remain in the factory for the next order. Yes, that is how it works. Well spotted! I brought it up because I've seen others lament the fact that they didn't realize that resources deposited into the factory cannot be removed. > Then why have volume limits? Why have a survival game mode? Why require resources and build time? Just spawn everything instantly. Why do anything? Why play the game in the first place? Because it's fun! The factory is not the end-all of the game. It's a very small part of it. You don't have to use it if you don't like it. One alternative I've heard is that some folks pretend it's physicalized, and only deposit materials when at a specific place, like your main base or something, and then only spawn it at that specific facility. You can even build a big old shipyard to pretend that the ship seems like it is being built more diagetically. That way, you still have the volume limits in effect in a self-imposed way, and a less "cheaty" form of factory. > And they suck because they constanly burden the CPU and, very importantly, you have everything in the same container. Who would want that? Do they take up that much CPU in Vanilla? Maybe I'm spoiled by RE in that regard. I know that container extenders take a tiny bit of CPU, but it's never been a problem for me. Usually what constricts my CPU is generators, shields, and turrets. I usually divide up my loot between several large containers. I generally try to build maximum size containers, even if I don't use it all. Max capacity per Container Controller for CV should be 640,000L per container, at least in RE. Might be a bit different in vanilla. Usual containers include (but are not limited to) - Blocks and Devices - Contruction Materials (Constructor Inbox, basically) - Extra Fuel, O2, Pentaxid - Ammo - FPS Weapons and Equipment, Armor, Armor Boosters - Farm Fridge (Raw Food/Medicie Materials) - Food Fridge (Edible Food and Medicines) If I have a Furnace, then also: - Furnace In (Raw ores) - Furnace Out (Ingots) If I have deconstructors, then: - Decon In (Components I don't plan on using) - Decon Out (Resources I can use for other stuff) Of course you should choose how you divide your own loot. This is just what I do and I know it wouldn't work for everyone. > That's exactly what I don't want. And don't want to build hundreds of containers. You should build like 6 container controllers, and attach container extenders to them to increase their volume capacity. No idea where you keep getting this 'hundreds of containers' idea from. Consider Container Controllers to be the access point for the container, and any adjacent Container Extenders as additional storage space for that specific Container Controller. Container Controller = 500L capacity box (example figures, actual numbers vary based on vehicle type. CVs and BAs have much bigger container controllers and extenders than HVs, for example) Container Controller + 1 Extender = 1000L capacity Container Controller + 2 Extenders = 1500L capacity box Container Controller + 10 Extenders = 10,500L capacity box Those aren't the exact numbers but they give you the idea. To store more stuff, you need more space to store it. Container Extenders make your containers bigger, thus more space to store stuff. Container Extenders are not separate containers; they make the containers they are adjacent to bigger. Make sense? For a practical example, here's my current 'light' freighter, with 4x 640kL containers: https://steamcommunity.com/sharedfiles/filedetails/?id=3040652156 There are a total of 334 container extenders, yes, but only like 6 or 7 proper containers total. The extenders just give the Container Controllers more volume to work with. 4x 640kL Container Controllers 1x 24kL CV Ammo Box (which I also stash extra fuel and stuff in) 1x Fridge (which is sorta its own category of container) It may differ in vanilla, but in RE the container extenders consume a whopping 5 CPU each. I think the Container Controllers maybe add an extra 100 CPU each at most. So that's 2,560,000 L of storage volume for about 2,000 CPU usage. I'd say that's pretty good CPU value, personally! > And what if someone comes along and destroys them (portable constructors)? Unless you're playing on a PvP server, that won't happen. I'm not even sure if hostile NPCs would attack portable constructors specifically. So that's not something I would be worried about, personally. > So the information in the game must also correct and not misleading. Well you're not wrong there! Stuff changes constantly, but the documentation is often not updated to match. I agree it can be very misleading. > How do you build a SV or a CV that can defend itself when a single missle takes out 4 rows of steel blocks in a 3m radius around the point of impact? That's where shields come in. The shield absorbs the blast so you don't take any damage to the hull. The other option, of course, is to keep an eye on anything that might shoot at you, and take evasive maneuvers if/when they do. And if you get hit? Remember what hit you and try to take a wider path around it next time. Consider it a learning experience I think we all learn a few painful lessons from this game the longer we play. I know I was shot down on moons a few times before I learned how to avoid them. So no shame there! POIs on airless moons are especially deadly, as they have a longer range on their turrets due to 0 atmospheric density. Thicker atmosphere means shorter range on weapons and turrets, so no atmosphere means they have maximum range. For most turrets, this is between 800m and 1.2km. Keep at least 1.5km between your ship and any POIs and you'll be fine for the most part. I prefer to keep 2km away from hostile POIs, personally (unless you're attacking the POI of course, but from what I gather you're not quite ready for that yet). > I've watched some videos and was told that it's better to place multiple RCS units, like as many as you can, on any vehicle, because that makes it steer bettter. Is that true? Can be, but they're not strictly necessary. To turn your ship, you need torque. There are two ways to generate torque: either place your thrusters at an angle to the center of mass that produces torque (further from center of mass generally means more torque, think of a lever and fulcrum), or use RCS which adds a flat amount of torque to every turning direction. Personally, I prefer to use good thruster placement and 0 RCS, but you can choose what you do yourself of course. If you pack a ship full of RCS, you'll turn quicker, but also be way heavier. But you can also turn quicker just by positioning your thrusters better. > If they do stack up, how many do you need? One per thruster or 10 or 100 They do! And you don't even need to worry where they're placed: they produce the same amount of torque regardless of placement. You can use as many as you want. No general rule here: just do what feels natural for your playstyle. I prefer my ships to feel 'weighty' so I use 0 per thruster personally. Been a long time since I designed any ships with RCS in them. > I thought you place one (RCS) as required. This ain't Kerbal. You don't need them (except maybe on an HV that only has hover engines), though they do help turn your ship quicker if you choose to use them. See above.
I'm literally just looking at the activity over all Threads on my CPU, so, that's 16 threads total for my 8 Core CPU with Multi-Threading. I'm not looking at individual game threads, so much as how they load the hardware. I.e. one CPU thread might be running several game threads, but I just look at the overall load on the CPU, by CPU (MT) thread. Basically, no individual CPU thread works very hard at all and, despite the light load, the scheduler still spreads the workload around fairly evenly, rather than it just being one or two threads more heavily loaded. The only time I see performance dips are: 1) Graphically complex scenes (lots of POI's etc.) that make my GPU (3070) run at 100% - not that common. 2) The Fog / interior lights / shiny surfaces issue - which sees neither CPU or GPU apparently taxed. Engine limitation perhaps.
>> Using the factory like that is kinda cheating, isn't it? >> Why bother to go into survival mode at all when you do it this way? > The great thing about a sandbox is, you get to pick and choose which > rules you want to use. At the moment I imagine the factory is just a > bunch of nanobots, each holding a piece of a block or device, and > when you give the order, they all start assembling the vehicle. Oh, don't get me wrong, I don't mind that you want to use the volume limit. Only I don't see why anyone would do that. > I still prefer the survival rules. I enjoy have POIs I can visit and > buy stuff from, enemies I can find, destroy, and salvage and I enjoy > doing the quests sometimes. None of that stuff is available in > creative in the same manner. same here > Besdies, 99% of the stuff I find goes into storage at either a > freighter CV or a base I've built somewhere. It's not like I dump > everything in the factory -- usually just enough to start the next > bp production. I guess at some point you don't need so many resources as at the beginning. Once you have the ships and HVs you want, you'll probably build a base here or there and upgrade and repair, and use some resource to defeat enemies. >> And I rather build something myself rather than using someones >> blueprint because that way, I'll learn better how to do it, and it >> will be built the way I want it to be. > I can agree with that. I've only ever used my own BPs to be > honest. I've seen lots of nice-looking ones of the workshop, but I > choose to build and use my own regardless. I used only 2 so far. It's easier to use one than making your own first when you need some support vehicle that doesn't matter much for a particular purpose. There are really nice ones, and there's always something to learn from them. >> Why have volume limits when you put everything into the magic factory anyway? > For everything else. 99% of the stuff I gather does not go into the > factory. > Trade goods, bulk cargo shipments (RE items), most of the salvage, > etc. None of that goes into the factory. And why would you use limits that only get in the way when doing that? > I've built a series of Freighter CVs specifically to carry large > amounts of cargo. My biggest one (at the moment) has 640kL x 16 of > storage space, which is a LOT. Without volume limits, I would have > much less reason to build large, cool ships You can still do that, and it'll be much easier. And the limit doesn't go away: Containers have only so many slots, and you need more eventually. >> I found that giving another build order just replaces the previous one, and the resources you put in are all available for the new order. And the ones that were not used remain in the factory for the next order. > Yes, that is how it works. Well spotted! > I brought it up because I've seen others lament the fact that they > didn't realize that resources deposited into the factory cannot be > removed. You can't remove them, can you? >> Then why have volume limits? Why have a survival game mode? Why >> require resources and build time? Just spawn everything instantly. > Why do anything? Why play the game in the first place? > Because it's fun! Volume limits are the opposite of fun. There's certainly something to be said for requiring volume for storing something and the effect of stuff having mass. Yet the way it's implemented braekes the game and doesn't make sense. There's no difference for the result between directly picking up, for example, the 500 concrete blocks and everything else you take to another planet or moon to build an outpost there, and picking them up indirectly through painstakingly connecting to an array of containers all the time. You build the outpost one way or another by picking up concrete blocks and everything you need and placing it as you like just the same. --- Or, when the CPU limit is enabled, you can't build an outpost at all because you can't build a ship that can have so many containers and thrusters because you don't have the resources to build CPU extenders and thrusters, and you'll never get those because to get those, you need to build the ship you don't have the resources for. The relevant difference is that one way, you can efficiently make progress, and going the other way, you have to go to ridiculous lengths and torture yourself to get anything at all done because the volume limit --- and not even a weight limit! --- gets into the way with everything you're trying to do. If we had to build construction equipment like forklifts, excavators, transport vehicles and so on, and use them to haul the cargo from where's produced into our CVs and from there to the construction site, it might make a relevant difference. We don't do that and instead, single handedly carve out whole mountains within a couple minutes with a hand drill, if we want to, and just place blocks with our very hands. What's the size of a concrete block? 2x2m? 4 qubic meters of reinforced concrete weigh 10 tons[1]. We place each block with our bare hands, and it doesn't matter if we're connected to a storage container or not, it's exactly the same either way. We don't even use reinforced concrete since we don't use rebar in it which means that our bases won't hold together. The volume limit doesn't make any sense and pointlessly holds us back. How could that be fun for anyone? [1]: https://www.omnicalculator.com/construction/concrete-weight > The factory is not the end-all of the game. It's a very small part > of it. You don't have to use it if you don't like it. It makes sense to me that someone who wants to build something first makes some kind of plan, or a blueprint, of what they want to build. Once the blueprint is completed, building can commence. Once you have the necessary resources and a constructor that can make the parts you need, what would speak against using the factory? It would be nicer if we had like a blueprint console at our bases we put the blueprint into and have the equipment in our base make the parts and if there were drones that take the parts to the construction site to put it all together, and it doesn't matter too much that we don't have that. > One alternative I've heard is that some folks pretend it's > physicalized, and only deposit materials when at a specific place, > like your main base or something, and then only spawn it at that > specific facility. You can even build a big old shipyard to pretend > that the ship seems like it is being built more diagetically. If we could get a parts list from the blueprint, we could produce the needed parts ... I rather make ingots than putting ore into the factory anyway because that way, it's easier to see how many ingots are needed than figuring out how much ore it takes. > That way, you still have the volume limits in effect in a > self-imposed way, and a less "cheaty" form of factory. You'd still be 'cheating' considering the volume limits. >> And they suck because they constanly burden the CPU and, very >> importantly, you have everything in the same container. Who would >> want that? > Do they take up that much CPU in Vanilla? Maybe I'm spoiled by RE in > that regard. They take 960 CPU per controller and 960 CPU per extension for a CV; and 8000 volume each. So for the maximum of 320k, it takes 38400 CPU. That's a lot of CPU. A container takes no CPU, also with 8000 volume. However, the volume is irrelevant when the volume limit is disabled. I use containers for categories and haven't run out of slots per category yet. I can't do that with controllers because they take way too much CPU and don't allow to make categories. So why use them? These controllers are merely another symptom of the ill-concieved volume limit. > I know that container extenders take a tiny bit of CPU, but it's > never been a problem for me. Usually what constricts my CPU is > generators, shields, and turrets. 960 isn't tiny. A HV CPU has only 5000 CPU, and the volume of HV extenders and containers is only a ridiculous 125. They still take 15 CPU each. That means you can't transport anything when the volume limit is enabled. That already annoyed me in the tutorial. > I usually divide up my loot between several large containers. I > generally try to build maximum size containers, even if I don't use > it all. Max capacity per Container Controller for CV should be > 640,000L per container, at least in RE. Might be a bit different in > vanilla. Looks like I'm not the only one who thinks that the volume limit is a bad idea. Otherwise they wouldn't have increased the limit to the double of what a whole container array can hold in vanilla per container in RE. It probably still only only holds you back entirely unless the volume of your backpack is increased by a factor of at least 1000 ... > [...] >> That's exactly what I don't want. And don't want to build >> hundreds of containers. > You should build like 6 container controllers, and attach container > extenders to them to increase their volume capacity. No idea where > you keep getting this 'hundreds of containers' idea from. > [...] > Those aren't the exact numbers but they give you the idea. To store > more stuff, you need more space to store it. Container Extenders > make your containers bigger, thus more space to store > stuff. Container Extenders are not separate containers; they make > the containers they are adjacent to bigger. Make sense? No, I use different containers for different categories. Controllers don't allow for that unless you build just as many of them as containers, which is pointless. At least a controller must allow you to make categories so you can put stuff you store in it into the appropriate category. > For a practical example, here's my current 'light' freighter, with > 4x 640kL containers: > https://steamcommunity.com/sharedfiles/filedetails/?id=3040652156 > There are a total of 334 container extenders [...] > So that's 2,560,000 L of storage volume for about 2,000 CPU > usage. I'd say that's pretty good CPU value, personally! That's a lot of CPU. So you built well over 300 containers just to deal with the volume limit, and you're asking me where I'm getting "this 'hundreds of containers' idea" from :~Z It's your idea, not mine Like I said, I don't want to build hundreds of containers. Besides, how realistic is that? A concrete block has a volume of 80 (whatever that is) and weighs 10t. That makes for 320000t of mass, and concrete blocks, of all items, probably don't have the highest ratio of mass per volume. Like if you were to load copper ingots, that would be a mass of almost 23 million tons. Do you have the thrusters for that? How much fuel does that take? What about the structural integrity required to get a mass of 23 million tons moving at the rates of acceleration we're used to? Having that said, I can only think that the volume limit is so pointless and ridiculous that it's not even worthwhile discussing it >> And what if someone comes along and destroys them (portable >> constructors)? > Unless you're playing on a PvP server, that won't happen. > I'm not even sure if hostile NPCs would attack portable constructors > specifically. So that's not something I would be worried about, > personally. Hm, in that case, I guess the NPCs need to be worked on as well. When they're attacking you, why wouldn't they either take over what they can and destroy and salvage what they can't or don't want. > [...] >> How do you build a SV or a CV that can defend itself when a single >> missle takes out 4 rows of steel blocks in a 3m radius around the >> point of impact? > That's where shields come in. The shield absorbs the blast so you > don't take any damage to the hull. Unfortunately, I can't build shields. Day before yesterday, my first CV was suddenly destroyed when I was curiously approaching a neutral artifact site when I ventured into another system to find the resources to build things like shields. It took only 3 seconds. Out of nothing, there was an alarm that I'm being attacked and half a second later, I could hear some impacts, so I backed up, and then there were more impacts. I was thrown out of the pilot chair and floated and was killed right away. I respawned at the artifact site and managed to salvage what was left of my CV. Perhaps if I hadn't taken take to design it such it might be somewhat resilient, it would have taken only 1 second or less, and I might not have been able to salvage it but have died at the artifact site. If I hadn't had a HV with a constructor in the hangar, the game would have been over. So what do shields do? An enemy is likely to also have shields. > The other option, of course, is to keep an eye on anything that > might shoot at you, and take evasive maneuvers if/when they do. And > if you get hit? Remember what hit you and try to take a wider path > around it next time. There wasn't anything to see, and trying to evade the attack didn't have any effect. Whatever attacked me seemed to have left, otherwise I'd proably have been attacked again when I switched on the new generator. > Consider it a learning experience I think we all learn a few > painful lessons from this game the longer we play. I know I was shot > down on moons a few times before I learned how to avoid them. So no > shame there! If I hadn't been able to salvage, I'd had probably started a new game, but on my server this time. Some things take time, like auto mining and charging capacitors from solar panels and fuel consumption, and it's odd that it all gets interrupted when the game isn't running. My CV wasn't reasonably repairable, so I designed a new one and could make it better after learning the disadvantages of my first design. Currently I'm grounded until the auto miners have mined enough promethium ... However, I can't keep loosing CVs like that. They must be more resilient and not destroyed within 3 seconds or less. > POIs on airless moons are especially deadly, as they have a longer > range on their turrets due to 0 atmospheric density. Thicker > atmosphere means shorter range on weapons and turrets, so no > atmosphere means they have maximum range. For most turrets, this is > between 800m and 1.2km. Keep at least 1.5km between your ship and > any POIs and you'll be fine for the most part. I prefer to keep 2km > away from hostile POIs, personally (unless you're attacking the POI > of course, but from what I gather you're not quite ready for that > yet). Well, yes, but I don't know if they're hostile or not before I know what they are. That means you have to get close enough. >> I've watched some videos and was told that it's better to place >> multiple RCS units, like as many as you can, on any vehicle, because >> that makes it steer bettter. Is that true? > Can be, but they're not strictly necessary. > To turn your ship, you need torque. There are two ways to generate > torque: either place your thrusters at an angle to the center of > mass that produces torque (further from center of mass generally > means more torque, think of a lever and fulcrum), or use RCS which > adds a flat amount of torque to every turning direction. > Personally, I prefer to use good thruster placement and 0 RCS, but > you can choose what you do yourself of course. If you pack a ship > full of RCS, you'll turn quicker, but also be way heavier. But you > can also turn quicker just by positioning your thrusters better. I've tried it and RCSs do stack up but don't add much rotation. Yet for HVs they are kinda required because up/down thrusters don't work on them, so the only way you can point their bow/stern up or down is using an RCS. Is that maybe an issue with your HVs, that you don't use an RCS and thus keep driving into the ground? >> If they do stack up, how many do you need? One per thruster or 10 or 100 > They do! And you don't even need to worry where they're placed: they > produce the same amount of torque regardless of placement. Yeah that's another thing that doesn't make sense. Their effect would have to depend on where they are placed, letting aside that there can be no torque directed one way without the same amount of torque directed the opposite way --- maybe not all at once, but still. > You can use as many as you want. No general rule here: just do what > feels natural for your playstyle. I prefer my ships to feel > 'weighty' so I use 0 per thruster personally. Been a long time since > I designed any ships with RCS in them. They take too much CPU in CVs to be worthwhile. You can see it in the statistics display. For SVs I didn't feel I'd need one, and the HVs require one if you want to be able to raise/lower the bow.
Hm, it much depends on hardware. With my CV landed on planets, my FPS rate got so low that I had to resort to a lower resolution, so I'm glad that I have an old display connected that does only 1920x1200. Lighting and shadows does/do affect FPS rate here, but with the lower resolution, I could bring up the settings and it looks better while still getting 60 FPS. I've also found --- and that is very surprising --- that either switching from Fedoras 'balanched' performance mode to 'performance' or disabling Fedoras way and directly changing the CPU governour from schedutil --- as Fedora uses by default -- to performance gives me 10 FPS more! There doesn't seem to be a noticable difference between schedutil and performance, so I stay with the default way for now. I've never seen any effect of such a change on any machine before. I guess I might get a bit more performance when I change some BIOS settings, but I haven't looked into that yet. So maybe it's possible to say that a faster CPU, as in 'faster per core', makes a big difference for Empyrion. How much load there is per core doesn't seem to matter as much. Of course, Xeons aren't ideal for this ...
Well the best part of this game is, you don't HAVE to use them! But I think I already explained why some people use them. It's alright if you don't find such restrictions to be fun, but I hope you understand why others do find it fun. There is something nice about having just a few touches of realism here and there, even if the game is not 100% true-to-life simulator. Hope you fix the rest of your issues! It's a big game and there's certainly a lot to learn. Good luck!
Well, I understand that you use the volume limit so you need to build lots of containers. You can do that, and everything else, much easier when the limit is disabled
I think this has already been done under the very general umbrella of "optimisation" in various past surveys. I have been working / playing a lot with Unity lately, trying to learn as much as I can about its quirks and best practices and so on. One random discovery among others, which was far from obvious at first, but makes a lot of sense if we think about this from a "coding" perspective : the order of complexity of colliders, from low to high, is as follow : sphere - capsule - box - mesh The vast majority of colliders in the game are assuredly "box colliders" (3rd most complex). I understand now that for the engine, determining a collider's precise boundaries in the 3d world is much easier if the only calculations required are a point of reference (ex. object center / origin) and a simple radius from there, vs calculating 6 planes relative to an origin (raycasting takes time...). I may be oversimplifying a bit here. But for the problem at hand regarding HV behavior, I'm slowly starting to believe that using a spherical collider for most of the vehicle's volume (or a capsule, or several spheres instead of many cubes or rectangular prisms) could help HVs navigate complex collisions with terrain in a smoother way... ------------------------------------------------------------------ The issue of turrets taking 15 secs to start shooting (that's 900 physics frames !!) ... they are either brain dead while the game checks through all the fuzziness of a zillion variables, or some data gets dropped somewhere to allow smooth render (frames can be dropped / skipped)... No clue. Regarding the critters hitting the player from a distance /through a cockpit's wall, I believe it may be also due to a delay between the time the attack is determined as a success and the time the animation is played, or a simple collider issue (collider larger than model rendered). Obviously, these attacks could at least damage the ship instead of the player...
How would you program these turrets? It may simply take too long to compute a firing solution, especially in a dynamic situation. Even a minigun turret has a range of 260m or so, and that is a lot of ground to cover.
In fact, before any attempt at fixing this turret behavior, I would simply try to isolate the issue(s) with proper bug investigation and testing. Here @Scoob reported the issue happening in different contexts after various durations during play. Best way is to focus on the issue by loading a game and testing this right away in a minimalist setup, to avoid interference from other parts of the game that may produce this apparent delay. There are simply too many variables in the situation as described in the OP. By isolating the event in a minimalist setup and gradually adding / editing elements then reloading the game, the developers would have better clues as to what might be the problem.
The key here is time I think. I mean, someone with the right tools (Devs) to observe and log what's going on under the hood when Turret responsiveness degrades. It's not a simple case of loading a save, zooming around for five minutes and saying "well, it looks fine to me", cos it really isn't. I don't think I play any other Unity engine games, certainly nothing with Turrets, so I don't know if this is a core weakness of the engine (unexpected) or whether this is just a difficult thing to implement in a performant manner. Regardless, turret delays have been a thing for as long as I've been playing, which is seven years at this point. Turrets have always been a bit weird. I remember from the early days that your basic base turrets had limitations. They'd often lack responsiveness, but there were two reasons for this; the first we're discussing here, and the second was more about what a turret can see. This is a weird one, because what a turret can see depends on where the player is standing. Years ago now, I provided a perfect save demonstrating this issue, but it did not seem to go anywhere. Basically, imagine this; The Turrets are at one end of my Base, I'm at the other, looking towards the turrets. Enemies (drones of course) are incoming from the other side of the turrets, and the turrets are unresponsive, only beginning to shoot once the Drones are at close range, and already shooting. Several turrets lost before they even start shooting. Once they do, they make quick work of each Drone, but with a target-switching delay. I repeat the test, now I'm standing down near the turrets, the Drones approach and the Turrets start shooting much more promptly, while the Drones are further away from the Base. The final test was to be "out in the field" ahead of the turrets so the Drones would fly over me on their way to the base. This time the Turrets open fire before the Drones even got close to me! I'd more than doubled the Turret's working range by me moving closer to the targets. Basically, this was the first time the turrets actually opened fire at near their rated max range. This is a simplification of things - but not by much - but it showed how player location impacts turret target acquisition. It's seems like there's a bubble around the player where certain events are "live" so to speak. This makes sense, and High/low attention processing for environments is hardly a new thing. However, with Empyrion, it looks like there is NO low-attention for player assets. Drones seem to operate (as "live") at a fair distance from the player, and can often be seen shooting things in the distance. Anyone remember when it wasn't uncommon to return to your base, only to see it being wrecked by Drones, while the base sat there unresponsive? Get close enough and the base suddenly "wakes up" and turrets finally start shooting. The "fix" implemented for this? Drones no longer attack your base when you're not there, not give base's some "low attention" processing to fight back. These two issues combine, I'm sure of it, to make things even worse. Whether it be the player on a sprawling Base, with turrets "too far away" to respond properly to enemies, or stuff is in the "live" zone, but Turrets are still unresponsive. It's not good. I'd hoped one day we'd see the AI Factions able to field their own SV's and HV's intelligently. Path finding on a planet might be a new challenge of course, but it's the existing problems that I suspect are the blocker for this. Here's the thing, for me, the early-game survival vs. the environment is great fun. Sure, there's some jank with critters able to "hit" the player where player isn't close, but generally a solid experience. I really enjoy this stage of the game. Then we move to the next "level" where the player is facing tech foes (drones) just fending them off from their base. Here, Turrets let things down due to the issues mentioned. Turrets generally totally out-match Drones, IF they actually shoot promptly. Taking losses because your ample (in theory) defences had trouble shooting is a let-down. Shields were the crutch here, allowing the base to take a few hits, allowing the turrets time to respond. Once we move on to direct POI assaults, taking things to the enemy, things break down further. Sentries not clearing those ground troops from the LZ promptly, turrets now ignoring enemy external sentries to work around the "closest only" targetting logic, that doesn't consider blocks in LoS calculations. Get past that, likely with a degree of frustration and we infiltrate the POI, what do we face there? Being shot through walls, objects blocking our shots, despite perfect (to a human eye) LoS. Weird delayed spawns, where enemies pop in on top of you (not by design of the POI author!), being hit by melee attackers when not in range. Enemies clipping through the player (Nightmare rush) leaving the player vulnerable but unable to deal damage... I could go on. ALL of these issues easily forgiven in an early-access title, but Empyrion isn't early-access any more, and I'm not seeing any progress towards fixing these things. Empyion is great fun, but I always get to the "I've had enough of this poop" point and either use God Mode to work around things, and keep playing, or just give up entirely. Empyrion with solid Turret logic would be a revelation. Addressing those other issues would be something else. Look, I get it, small team and not their engine so perhaps there are limitations and challenges they face we don't understand. However, these are all core features of the game that simply do not work properly. You know, at this stage, if the Devs said "Look, we've gone as far as we can with Empyrion, we just can't get things to work as well as we'd like with the limitations of the engine". I'd be fine, as long as they announce Empyrion 2, in a new engine with enhanced tech on that day. I'd certainly happily buy an Early-Access Empyrion 2, if they showed solid improvements in core features, but perhaps a little content-poor vs. the mature game we have now. That's the thing, the devs have added some great additional content and features over the years, but it's these core issues that stop me fully enjoying a long play-through each time. Anyway, I've rambled enough
The current behaviour isn't what I'm asking about. I'm asking about how you would program turrets. So far, I haven't seen any real issues with turrets. I'm still wondering if Scoob and maybe a few other players have this while many or most don't. Just yesterday, my CV with 25 turrets took out an attacking ship all by itself while I was in my SV mining an asteroid. I tried to get back on board as soon as I could and about right by the time I made it, the fight was over. The shield of the CV didn't show a scratch. I could watch the turrets firing from afar, and it was a cool sight
The issue is the lack of responsiveness of turrets, it's a very well-documented issue. You could watch any number of Youtube vids by Spanj and others where they curse slow turret response. I imagine many are resigned to it now, but I do hope things get improved one day, as I really wrecks certain aspects of the game. I mean, I have a vessel designed to clear an LZ of hostile troops and critters, it should be great at it, but the turrets don't fire...until as long as Fifteen Seconds under fire by hostile parties. I'm actually shocked by people who haven't noticed Turrets being slow to respond. I mean, when I'm under fire and my turrets are unresponsive, I really notice that...time and time again. So, yeah, turrets do work, but they work badly due to this lack of responsiveness. Sometimes this might be in our favour, such as when attacking a POI in a swift SV - I can get in and get some good hits on the POI's turrets before it responds. Once it's woken up though, considering the player is ONE target, they work just fine. Once a turret actually shoots, they work fine. Eleon just need to get to the bottom of this weird delay. There's no doubt it exists, far to much video evidence of it to deny it.
Indeed. If there are things in Empyrion that are holding things back, old spaghetti code, things that simply need a total rework from the ground up, then perhaps it's time to seriously consider Empyrion 2 - if those discussions aren't already taking place internally. Considering the content the game is getting, but core issues are not being addressed, it does suggest the game is in a very different phase. I.e. the mechanics are what they are, working well or not, but content is still being added within those constraints. Only Empyrion 2 would bring a better implementation of current "weak" game mechanics. I think the majority of the community would react positively to an announcement of Empyrion 2, depending on how it's handled. I can see people who recently got the game feeling a bit upset that their new purchase is now "obsolete", but I think the general reception would be good. The question is though, what would Empyrion 2 be? The same game, but with better core mechanics support? I'd be fine with that. For me, if Empyrion 2 was the same game but: - Turrets work (responsive) - First person combat is better (weapon handling, LoS calculations) - Walking on MOVING vessels (gasp!) - Competent AI able to control HV's, SV's and CV's (current "patrol vessel" AI is pretty weak) - More persistence when it comes to trading etc. POI's actually produce and consume things That's just a quick brain dump. Off-topic for this post, but there's some relevance when discussing weak core game features perhaps needing E2 to address...
What have the developers said about this problem? Why aren't they fixing it? I haven't seen it in my game yet. With 2 or 3 minigun turrets on a HV, a few times I wondered why a turret I could see from my cockpit didn't fire while the others did, and I figured it's either not necessary that it does or it's at a bad angle and can't hit. That's where my idea that it may take too long to figure out which turret(s) are supposed to shoot which enemy comes from. Other than that, I've seen multiple minigun turrets either firing at the same target or each one shooting a different target. When attacking another ship in my CV, the turrets were firing and it seems some have a low range, so I need to get close. Sometimes the sentry turrets seem to be firing at predators, but I can't see what they're doing. When I was attacked while mining, the CV fired at the attacker and disabled it. My first CV didn't have shields and I don't know if it fired; it didn't long enough to say anything. Enemy turrets also shoot me like they're supposed to. So there wasn't anything I'd call an issue. Of course it doesn't mean anything, I'm just starting and haven't seen much combat yet. Of course, the turrets need to fire and must not wait. Well, I have a bug/wishlist myself that's gotten pretty long. And I totally agree with what you say about foot combat. I've started the story mission where you have to go through the Ilmarinen, and it's really well made and reminds me a lot of system shock. But the combat totally sucks. Not only enemies are covered by some invisible stuff so you can't hit them when you should, they also spawn out of nothing. You can send your drone in and find the corridors and hallways ahead all empty, yet when you open the door yourself and go in, they're suddenly crowded and you get killed yet again. I'm still not done yet, and I've ruined 4 heavy armors, used over 100 bandages, 20 emergency rations, about 300 shotgun shells, almost 500 laser rifle cells, about 100 homing missiles, some plasma cannon cells and some sniper ammo. I got killed countless time (maybe 50 times?) because no matter what I do, there's no protection against the enemies, and I don't have anything better than two heavy armors I can keep repairing until they're worn out, and a signle armor boost. One or two hits, and you're dead, and you can't defend yourself because your weapons have to be reloaded all the time before you could really start shooting. The armors need at least 10 times their durability and 20 times the armor, and we need personal shields that protect us and reload quickly. I had to stop yesterday and go to sleep because I ran out of food, so now I have to warp back to my refinery and get some more food and bandages and ammo and come back. If I had the volume limit enabled I would not be able to carry the weapons and the ammo and bandages and food required to even consider going on this mission. And I'm not even carrying all the different kinds of medicines that I should be carrying since that is just too much. We don't have enough slots in our inventory for that. Some of the turrets you just have to stand there and let them shoot you so that you have a chance to hit them. Why can't we use the drone? The drone can do mining and beam tons of resources into our inventory just fine, and that it can't shoot the same way it can use the drill doesn't make any sense. It could beam a bullet or explosives right into the enemy. Being totally helpless entirely spoils the experience. You know you get killed, sometimes multiple times, on almost every encounter, with no way around it, and like you said before, you can either give up or go into god mode. If I weren't respawned without loosing anything, I would have had to quit. I've had to quit Halo (in Halo 3), Heavy Gear and a couple other games because there was just no way to get any further.
I don't doubt the bug exists, but honestly I've played for 2,200 hours (admittedly many in creative) and never seen what Scoob describes either. I've noticed a delay of maybe less than a second before my turrets fire on some occasions, but nothing even remotely approaching 15 seconds. I have to wonder how common this bug actually is? Or the better question: what actually causes the delay?
Hmm, I suggested I could try it out if I had his savegame so we could see if I'm seeing the same issue or not. It's not impossible that only some users are having the problem and others don't. I don't have the savegame.
I'm sorta surprised, considering the number of hours you have. For me, it's been a constant for as long as I can remember, so very very obvious that turrets simply are not responding. A turret might initially seem to work ok (not great, they're never snappy when initially engaging a target) but when it needs to switch to the next target (say ground troops around your CV's LZ) there is ALWAYS a several second delay. It's never been otherwise. I've played LOTS of vanilla, usually single player (so no server weirdness in theory) and limited time on my own server. I generally play modded games now, currently Reforged Eden, and I see the same issue with turrets. I've had various PC's during the time I've played, 2600k & 1070, 3900x, 5800X3d, all excellent for their time but all suffering from this turret issue. I cannot begin to speculate why the issue might be totally consistent for some, but not for others. However, it remains a well-documented issue that is immensely frustrating. As mentioned, in the first few seconds of loading a save, turrets work GREAT, then they degrade rapidly. To be clear, this "Fifteen Seconds" isn't an exaggeration on my part. After a longer session, that's how long my turrets were taking to both initially react to a target, then move to the next target. No issue with not being in range then coming into range. No. Enemies were in-range at all times, the turrets simply did not respond.
