Well second checking your build now, you do have front-facing thrusters, yet no value for backwards speed. Did you shut down some thrusters prior to the screenshot ? Edit : ok, found the "bug". The "arrows" show good thrust vector, but the thrusters list show "back/front" as if it was the thruster's position. Maybe it would be less confusing if they replaced "front" by "forward" and back with "backwards", left/ right and up/down I have no idea right now but it sounds ok. Edit 2 : checked again : you have 8 thrusters facing "forward" (1st image)... how does your ship go forward ?
We had a nice rain yesterday. Not as much as I had hoped. but still good. Will wait to see what today brings. Well my starter HV still works good after it's refit. So I'm fine with that. My SV still not sure. Haven't really dug into that one mainly because with the HV > SV docking. My head started thinking of a new design. Now my CV Starter. I removed the rcs's compleatly. Removed the mid size thrusters all 6 of them and went to the small thruster 2 in each direction spaced around the corners of my starter brick. Well I must say, I was able to clean it back up, patched all the new holes and even painted it all white. I was shocked. Not only had I been able to bring it into spec. The damn thing flew with max speed of 60. And acted like it had a tier 2 RCS in it. Think it turned faster then my SV So for now I'm going to wait and see what the next set of changes will do to how this new CV works. CPU should only be applied to active powered devices. At least to my way of thinking.
As I said before the ship isn't finished yet. So Truster for the big Push are still missing...or at least have been. Two Large Truster will do that in the future. Also the downward Trust will change from the current 4 Larger to 16 or more Medium. In Space I do not need the heavy Lifting abilities of those Large Truster.
Ok. So I have to edit my previous post then (and maybe you could do the same ?) because I thought they changed the arrow displays... Too bad. Edit : done.
UGH POLITICS I appreciate some of your points but PLEASE FOR THE LOVE OF ALL THAT'S DECENT LEAVE POLITICS OUT OF IT. Its destroyed almost everything now. Sports KNEELERs etc TV/Movies are propaganda now. PLEASE leave it out of my games.
Personally, the "socialist / leftist" stuff gave me a good chuckle, but I gotta agree with @Softwalker001 - best leave that commentary on the bench. I can't actually find a link to proper Forum Rules, but memory is telling me Politics is one of the few forbidden subjects 'round here. Would have to ask @Hummel-o-War to confirm that though (and seriously, I wonder where that forum rules thread went? I swear we used to have one). Anyway, I assure you there's nothing political about the design decisions at work here. Stupidity? Sure, I'll agree on that point, but it comes from a lot of other factors, none of which have anything to do with an "ideology" being enforced. So... much as I enjoyed the laugh, strongly advise you pick a new angle of attack henceforth.
Eleon is in France, and with that I'll stop talking about it. Just don't wake up ten years from now realizing you wasted those years on crap.
There are no incoming conveyor belts. At no point in time, in either Q&A was conveyor belts mentioned except to tell Spanj that they WEREN'T going to add them. Moreover, at the end of the latest Q&A they had to say it repeatedly for the mentally challenged that CPU has nothing whatsoever to do with server/client performance. Eleon is in Germany. All the devs are German, except I think Taelyn is Finnish.
Yeah, but those aren't conveyor belts. There was a suggestion thread in response to the Q&A about pistons and rotors where Hummel confirmed that they're not going to behave like SE's rotors and pistons. More like integrated devices that can move around, but are still part of the same grid. I suspect like a rotating VTOL engine pod that can turn and burn in each direction with a delay. But it'd be just like one big animated device, rather than a dynamic moving grid.
Hadn't run across that bit of info. Was thinking Minecraft style pistons. Thanks for the clarification.
I was wrong about France. Eleon just sounds like a French word to me. We all know Germany and France are in the same boat. With respect to Conveyor Belts, I saw the Devs confirm it but it was before the conversation turned to 10.6 and CPU. They said it was still a way off. With respect to CPU not having anything to do with server/client performance, that is exactly how you can tell that CPU is an ideological decision, not a practical one. And back to my main position on this, Empyrion has two things that must be done before time is wasted on ideological austerity escapades, and one nice to have but not absolutely necessary thing. 1. Physics and AI (Most Essential) 2. Optimization (Essential) 3. Talking NPCs to include human NPCs that should be giving out missions. (nice to have) Check out X-Rebirth. I have led a fleet of 11 CVs including 3 Drone Carriers with 300 drones each into battles against 5 or 6 CVs with over 50 fighters and hundreds of their own drones. We are talking about epic space battles involving more than 100 vessles that literally look like a scene from Star Wars, and all this with no lag. The only real problem with X-Rebirth is that after awhile every area starts to look the same because they don't have planets. Physics/AI, Optimization, Talking NPC mission givers. Everything else at this point is rearranging the deck chairs on the Titanic.
This update seems to work badly for those who play SP only. It creates an additional artificial time sink to mask the lack of content and AI development by making the logistics of doing anything in the game require more stages. The old CPU system forced specialization if you worked to a 7500 CPU max. You could not have a jack of all trades size 5+ battleship with 1 million SU storage, 2-3 combat armour layers and sufficient thrust to be viable at 7500 CPU. Had this limit been set as a hard cap as well as a hard size 5 class limit, specialization would already be in the game without any of this faffing about. It was not set as a hard cap and neither was the size limit so people threw the kitchen sink at every design in sizes exceeding, 20, 30 or 40 with lo and behold performance issues. It is mentioned that performance is an issue that this CPU change is an attempt to address but it is a problem of the devs own making. Sadly the game is heading in a direction that it need not go had caps been been implemented at the levels that were set as soft limits. No monstrous size 30+ lagfest ships or bases and anything over size 2 would have to start specializing to an increasing degree as size/mass increased. A missed opportunity to do things simply.
A server can simply override size limits anyway. If people want their lag-fest ships, they're going to make their lag-fest ships. I just liked the idea of the CPU from a conceptual level. I was hoping it'd make building a bit more interesting. Frankly, I think it'd be a better idea to remove CPU from hull blocks first and foremost, condense all CPU down into the CORE which can be upgraded like any block with the multi-tool and, finally, make it so that devices can be dynamically modified to alter their CPU usage. For example, if I want a shield generator on a small craft, let there be one SV/HV shield generator, you can even make it cost 2000 CPU without it doing anything, but let me "tweak" it in-game to output the way I want to. More shields needed?(to a cap) turn the knob so that it uses more CPU and more Power. Less shields (to a minimum) to deflect a couple of shots when dropping into a hot LZ? turn the knob so that it uses less CPU and less power. Turning the device off should also turn its CPU usage off. For example if I have strategically placed thrusters on my craft, let me decide which ones can be off and which are on based on A) What my current need is and B) my CPU budget. Say I am on a high gravity world and have just loaded up hundreds of tons of ore on my cargo SV. Under normal circumstances, my SV could probably take off and reach space where my CV is waiting for it to unload. But what's this? 2.7 G and my bottom thrusters aren't cutting it. No problem, I'll just turn on my auxiliary bottom thrusters to help me get off the ground and into space, but I'll also cut my rear thrusters as I'll be taking off vertically. The exchange adds CPU usage to my bottom thrusters but cuts it from the rear, balancing the usage of the vessel while not allowing it to just use any thrusters it wants.
The thing is the Devs say that CPU will have 0 impact on performance. While it is true that performance decreases with structure size, Empyrion lags on top end PCs while the player is flying a small starter SV in single player. And every shot causes a lag spike. Optimization is the problem here. Not only does Empyrion need the coded algorithms and tiered resolution blocks and textures to properly reduce quality of objects with distance, as well as to not render what is not seen on screen, but Empyrion has MAJOR memory allocation issues. Have you ever noticed that Empyrion doesn't release memory when you close it out? That lag continues until you click on other apps on your desktop after you have closed out Empyrion? Optimization can be achieved code wise via many different approaches. The problem here is the Devs are not doing it. One brilliant solution was employed by Valve when they developed Half Life 2. Half Life 2 was released in 2004 yet it delivered 2010 graphics with no lag on crappy PCs. No other game could hold a candle to Half Life 2 in the graphics department. Other games with greatly inferior graphics could only run on high end PCs, yet Half Life 2 was blowing them away on crappy PCs. How did Valve achieve this miracle? Well apart from the conventional algorithmically rendering of lower and lower quality objects as distance increases, not rendering non visible objects, and brilliant memory management, Valve did something no other game developer has done that I am aware of. They created their own proprietary file type - the gcf file. The gcf file was a revolution in file technology. It allowed the PC to read and write data to memory more than twice as fast as conventional files. This really helped the conventional optimization algorithms do their thing many times more efficiently, such as only rendering what is visible. The gcf file allowed the game to instantly load objects to memory when viewed, in a way no other file can or could. There may be other copycats out there now. The point of this walk down great game design memory lane is that no matter how much you have going on onscreen, no matter how big the objects are, how complex, or how voluminous, it IS ALWAYS POSSIBLE to optimize the game so that it never renders data above a certain threshold. That threshold can be set as low as you are willing to do the coding work to achieve. It is possible for Empyrion to be optimized to the point where I could fly my size 92 308 meter long Harbinger CV that I built for some stupid reason in PvP with many other ships on a crappy 2015 PC with 4 GB of RAM with no lag in 1080 resolution. This would take MANY man hours of coding to achieve and this is not what I am saying needs to happen. But Empyrion NEEDS optimization BADLY. A decent PC needs to be able to fly a decent sized vessel in a crowded scene with no lag. That is a bare minimum must have. The Devs are simply not willing or not able to develop the code to properly optimize the game nor are they able to develop the code to deliver proper physics and AI. It is probably a money issue, and this is the catch 22 of our current Western economic model. The Devs need more paying Early Access players in order to hire more coders. But they won't get more paying Early Access players until they implement good physics, AI, and optimization. And they don't have the money to do that. I guarantee you that if Eleon implemented excellent physics, AI, and optimization they would exponentially increase their paying Early Access player base. If they put talking NPCs handing out missions and as followers, Empyrion would go supernova. It would begin pulling players from Space Engineers, X-Rebirth, Star Citizen, and every other space game in droves. This would mean increasing their monthly budget to powers of 10. But it’s a Catch 22. Maybe Eleon can do a Go Fund Me. If all the players made a donation that was going to go towards coding the physics, AI, and optimization, that might be enough to get past the Catch 22. But how many players are there in total? 1000? 10,000? So a $10 donation could add up to $100,000. How much money would it take to hire the talent needed to solve the physics, AI, and optimization problem? This is the topic that will truly decide the destiny of Empyrion. CPU is only taking the game down. Once Empyrion has these fundamental problems solved or vastly improved, Eleon should be able to sustain itself at a level of largess that will allow for the hard work to continue to be done on Early Access dues alone. Look at how much money Star Citizen has raised from its fans and it’s still not really done. Imagine how good a job of Physics, AI, and Optimization Eleon could do with a fraction of that. Say $5 million. Not to mention great voice acting talking, recruitable NPCs. It would be nice. Empyrion is so close to achieving something that has never been done before that will create a legacy in gaming. CPU will destroy all hopes of that happening.
Can't agree less...more than 4000hours SP ONLY and I felt a little but no hard restrictions designing my Vessels and Bases. Just as I like them. There was no OLD CPU System - the Devs and Mods stated a hundred times that those numbers are PLACEHOLDERS at Best and the CPU System is not yet activated...not too many listened to this explanation and started to build their Vessels and Bases around this Number of 7500. And now, once again, some Players seem to sit on their Ears when Devs and Mods try to tell them that there is NO HARD CAP! You vessel will even fly if you go 500% over the "limit".
