Also, CPU could be a factor in determining base attacks - a higher CPU might mean a greater chance of being attacked or influence the size of the attack.
I think turrets already try to predict their target's trajectory, but maybe it is more obvious in space with an average ship, and more obvious with bullets (hitscan) than with slower lasers. For POIs it is up to the designers to scale the difficulty, it should not be limited/ directed by CPU because that's the "god mode" part of the game and I prefer POI builders to have all liberty to create without constraints apart difficulty scaling to fit missions/ context. For player-made bases I think it's more a question of balance, and I know that on both sides of the fences ( ships vs bases) players want the other side to have more disadvantages but I think bases (in PvP) should be the last place players can be safe and regroup. I don't know what the developer's philosophy is on that though. In PvE there is already a hacking attack and that shaman thing too, so until Eleon makes it clear what their plan is regarding this I won't even think about CPU for bases. Do we have a "specialization problem" for bases like for ships ?
@EleonGameStudios I believe a lot of angst is being caused because you are defining what is important to people's individual preferences and priorities by limiting what we can add to our builds. May I suggest that you define for the community the main ship types/classes/roles you envisage - if you want to encourage specialization then you must have an idea of what 'specialized' is. Why not share this with us. DO outline the role of each class and maybe give an example of it's intended use DO NOT give hard caps like 'no more than 2 forward facing weapons' or 'don't include a constructor' or 'should not be used for combat' Then ask the community to submit their builds that they think meet those specifications (CPU limits ignored at this point). Then look at the common factors and averages across these builds for that class/type/role and see if your expectations are in line with what the community currently think. You can then also see what sort of CPU limits are realistic. For me personally: a combat SV still needs storage (for storing loot) and a constructor (for quick repairs) A cargo-hauler SV still needs to be nimble with enough firepower to defend itself and get away. A warp-capable SV needs to be a jack-of-all rather than being specialized because it will be flying far from home and needs to be self-sufficient.
Rather simple, I would say, since there is already a check if base is powered, at the very least, so it's just another check against the CPU value in that same code block. I don't even know if changing weapon's stats can be done during runtime.
There is nothing wrong with a tiny T4 ship, but you shouldn't need T4 CPU to run a tiny ship. Once you start adding max all guns, multiple constructors, redundant thrusters and generators, it's no longer a tiny ship and will require a better CPU tier. a combat SV still needs storage (for storing loot) and a constructor (for quick repairs) A cargo-hauler SV still needs to be nimble with enough firepower to defend itself and get away. A warp-capable SV needs to be a jack-of-all rather than being specialized because it will be flying far from home and needs to be self-sufficient. if these 3 points are true, please tell me the difference between these ships, or would it be a single ship to fill all roles? The point of specialization is that if you are good at one role, you sacrifice capacity in another role. The cargo hauler SV for example, being weighed down by it's cargo (assuming it's loaded), is not going to be especially nimble. It will also likely be fairly large to support large cargo bays and the armor to protect them. This type of ship is not going to be a nimble fighter. It may have weapons and be able to defend itself, but will have a speed/maneuverability disadvantage when facing purely combat oriented ships. You would be better off making it fairly tanky, and fleeing as soon as possible if engaged rather than trying to combat enemy fighters. Unloaded, a cargo SV will probably be just as nimble or even more so than a lot of fighters due to the necessity to overbuild it's thruster capacity to move when fully loaded. This would require a higher CPU tier of course, because of the additional thrusters and generators. So an unloaded cargo SV can fill the role of combat SV but it will be physically larger and more expensive to build. A combat SV having a small amount of storage and a constructor is always useful, and unless constructors consume a ton of CPU, I don't think you would have to sacrifice much to fit one in somewhere. You probably won't be able to carry a large amount of cargo though, especially if mass/volume is turned on and you don't have the thrusters to get off the ground with full cargo. A warp capable SV can be anything you want it to be. I often duct tape a warp drive to the top of my smaller fighter craft and tool it off when I arrive in the target system before going into battle. I prefer to fight to the death so needing to warp out mid fight isn't much concern to me for a combat SV.
Well exactly, what IS wrong with doing this. Nothing! We should be allowed to do this but then again CPU has been specifically introduced to bring... . So my assumption (dangerous thing to do, I know!) was that a small T4 with all the expanded build options that this would allow us would not be balanced if it was compressed into a fast, maneuverable, tiny ship with enough firepower to dominate everything it looks at. There has to be a trade-off somewhere. I was already going down this path hence the reason I put up my other post asking for a definition of specialization.
All good points ++ I don't like to think of specalisation like this... But like this... Albeit this is still a liner example you could apply this gradient to a range of aspects. To simplify, if we had a gradient for cargo capacity, speed and firepower, the combat SV, cargo SV and warp (self-sufficient SV) would all be on different parts of the gradient with the self-sufficient SV somewhere in the middle of all gradients. And again, this is the point is it not? My definition is different from everyone else and you highlighted this perfectly by looking at my 3 examples and seeing a similar spec whereas I see 3 specialized roles. Also, your example of a detachable warp drive means that you still need storage capacity for this + pentaxid tank + pentaxid when it is not in use so why not keep this as part of the build design? The answer: preference
First of all, building a tiny CV and a tiny SV is not the same. At what type do you refer to here ? For example, adding all gun types to a SV is useless, since we can only use 1 type at a time. Why waste mass and maneuverability with the dead mass weapons and ammo ? As for constructors and most other devices, they are very cheap on CPU and not a real problem. CPU is heavily focused on thrusters, shields and RCS, and I highly doubt that will change a lot in rebalance. So in essence, "specialization" is mostly a cosmetic concept if only propulsion and defence is CPU costly, because there is virtually no penalty to use all other devices. So out goes the "specialization" if it is not better defined than "players can't mine and fight with one ship" because that is simply not true even with harsh limits. - a combat SV does not need more storage than what is needed for "combat" = ammo, extra fuel, few spare parts to repair in order to get back to BA/CV - no constructor either - cargo hauler : this needs more context. For commercial type, minimal "combat" needs (random drone encounter = 1 gatling enough), and if roleplay in multiplayer then greatly different than AI cargo seen as goodies for the PvE game - warp-capable SV can be equipped with many non-combat devices, but it doesn't have to be a combat ship : players can settle down and build from the ground up elsewhere. Again, question of context. When a concept relies mostly on "what is good for" and "what should be" it is subjective, not mandatory. So once again : what is the problem with a T4 tiny ship ?
Please give me an example of a tiny ship with enough firepower to dominate everything else, that doesn't trade-off armor for mobility.
Sorry, let me finish beating this dead horse and I'll shut up. Here is my vision of the 3 example ships I gave and roughly where they fall on my gradient example (darker = better / lighter = worse). Where would your builds fit on this I wonder? Cargo SV Combat SV Warp SV So I could make a nimble freighter by having enough thrusters and RCS and there is nothing in CPU limits that would prevent this. What isn't shown is all the other things that affect CPU like shields, warp drive, fridges, and the plethora of other devices at our disposal - hence a gradient and not tiers.
I'll have to build one that is within the CPU limits but with CPU turned off so it can factor in the discussion about the number of blocks required for T4 CPU being reduced from 8 to 3. Will get onto this later this evening hopefully.
Something else that niggles the back of my mind with respect to blocks counting against CPU ... So, you have a SV thats suffering from "too many blocks, its degrading your efficiency"... you then get into a fire fight and lose a gob of blocks. Suddenly, your HALF DAMAGED SHIP becomes super efficient and performs great! Yeah, Makes a load of sense to me.
This seems to be in short making something far more complex than it needed to be. You could have simply made it for example any CV over 7500 CPU and size 1 cant land on planets. Added a further class of 10k CPU size 2, 12.5k size 3 etc. Lastly add an engine thrust/efficiency bonus of +10% for size 1, 0% size 2, -10% size 3 etc making large size 3+ heavy firepower ships progressively slower and unresponsive and smaller ones faster, nimbler and more of a scalpel than a sledgehammer. This would make directed fire weapons more effective on smaller ships and turrets the way to go on larger ones. Lo and behold specialisation, smaller CVs for prospecting, blockade running and base building, fast destroyers with direct fire weapons to take out turrets on larger vessels, larger cruisers and battleships to soak up punishment and pound orbital facilities with artillery. No messing about trying to squeeze down current starter designs to fit the 200k-400k CPU although they are size 1 and use no advanced minerals and no need to create an extra 15 blocks of space on smaller 7500 CPU size 1 corvette combat ships that mount everything bar artillery and are built to have heavy firepower but no massive hp, large mass or poor fuel efficiency. I look forward to early custom scenario hard start solo play where I have to assault a base in a non warp non cargo SV, return to my BA and pick up a Cargo Transport carrying a Turreted HV to carry looted content and raw material while the HV sits undocked, empty and solely there to provide AA cover to the Transport for the additional drones etc that eventually appear to blow your grounded and defenceless SV to bits.
Mmm? It has just occurred to me that, if going back to the discussion about what size the extender modules should be; in a 1-block extender scenario vs a 2-block extender scenario for T4 SV, the difference between ships with the exact same size/dimension/build is that the the 1-block scenario vessel would be able to fit in a pextaid tank, shield generator and RCS in the space the 2-block scenario vessel is using to reach T4. So there would be a significant difference in changing the extender sizes to make them smaller.
Those are not "my specifications" but simple counter-examples. Here is another example to illustrate something I was rather surprised to discover: This little guy : Before CPU it had a shield, and max speed of 110 m/s, max acceleration of ~106 ms/2. With CPU obviously I busted the upper limit so I had to remove the shields (could have removed some thruster too, but just for my devious mind to savor...) but here is what I get : I am at ~ 300 CPU points under the T4 limit. I have doubled the acceleration, and it now turns 5x better. The "shape" is also quite efficient on planets, as it reaches top speed very fast and has no problem maintaining flight without thrust, no wings. A pilot would not survive such an acceleration. This is even worse than before CPU, and that ship should be a nightmare to try to hit in PvP. How come we can get to these ridiculous acceleration values, even with CPU ? Now I can add many devices too and the ship will only get "slower" but still overkill. No shield, but who cares at these values ? So the point is this : that example shows that in order to force specialization via CPU limits, unless they make the system so restrictive as to make a ship like this behave "normally", then all CPU values need to go up for all devices, not "down", like everyone is saying since CPU went live. Because if not, then it will not prevent devious minds (like me, hehe) from making ships that are not behaving "as expected" in multiplayer, and ships like that will appear and disappear all over the client's screens all the time. ---------------------------------------------------------- So we already had block counts to avoid huge builds on servers, and "CPU" will not get rid of "jack-of-all-trades" it will only slow them down a bit. And why is "slowing" them down so important ? Because this has nothing to do with "specialization", and everything to do with balance in multiplayer. AI don't care with my silly design. As for the size of extenders, given what is possible to achieve already, I don't really care, but I still don't see any sound reason not to avoid unneeded mandatory blocks & devices bloat in the game.
ok so I was doing some testing in creative experimental branch... I made a class 1 fighter SV using only 2 weapon types and a shield with no RCS requiring about 40k CPU, which would land it squarely in T4 if CPU requirements are "requirements." The thing is they are not. I equipped it with T1 through T4 CPU to see how hard the penalty hits. Obviously at T4 efficiency was 100% and it flew like a dream. At T3 CPU it was still over 90% efficient and it lost a couple m/s^2 in each direction for acceleration but still flew just fine. Turning rate didn't seem to be noticeably affected. At T2 81% it lost some more acceleration but maneuverability didn't suffer much although I could notice it wasn't as nimble as the T3-T4 variants, but still very good. Even at T1 63% efficiency the ship still flew well, had well over 100 m/s^2 acceleration in the forward direction, but other directions were getting slower and turning rate was affected pretty strongly. I added a ton more thrusters to compensate for the lack of CPU efficiency and even at 52% efficiency, I could still make the ship fly just as well as the original T4 variant. So what I'm getting at is these CPU limits aren't hard caps, you can still achieve whatever you desire your ship to do, but you might have to use twice as many thrusters and generators to get the kind of performance you want if you don't have the CPU upgrades, or if you've surpassed the maximum. My old combat SV uses 74k CPU and so would suffer from the efficiency penalty even at T4. That doesn't mean the ship can't fly, but it means I have a question to answer: Do I add more equipment to make up for the lost efficiency, or do I remove equipment to make the remaining ones more efficient, or should I just keep it as it is and accept the degraded performance? So having a CPU that is too weak for your ship isn't really that bad, it just makes it more expensive to achieve the same levels of performance. ie: less efficient.
More I think of CPU stuff, more in favor of a simple, granular 'capacity' system I become. ----- (and now I'm gonna flip-flop and propose something really confusing!) ---- I'll throw in an idea that CPU should do, but almost certainly won't do, because it would be confusing too do. (& I just woke up, ha! gonna be a good day friends ) So much so that I can only describe the general idea. Directly tie CPU cost to thrusters acceleration, as a "restrictor throttle", and as "efficiency". As a Control Panel slider. A cargo ship needs lots of Newtons when it's fully loaded. Not nearly as many when empty. Leading to the example above about empty haulers being on par or better than combat ships, accel wise. So, somehow, have a scaling CPU cost to acceleration itself. Say every KiloNewton (MN for bigs) costs an increasing amount of CPU. Power efficiency as well; by that I really mean fuel cost per Newton. So a fuel sink for Eleon Maybe rather than config every thruster, have it be per axis. So highest accel & lowest eff on Left & Right in order to dodge. Very low accel, 2-3 m/s^2 + gravity for Lift, but high efficiency since those are the ones doing majority of the work on a full hauler. Edit: so when empty, the hauler would still be 'set' for this low accel, even if the full power of lifting thrusters would give say 70 m/s^2 if not throttled back. Could still have a ~fairly low base CPU cost for each thruster, but they'd mostly cost CPU as acceleration & efficiency. Couple really nice benefits could be less punishing to builders going for a 'look'; accel & effici tied to total ship mass, so using much larger, or more than needed, thrusters wouldn't be impossible. Would be possible to build a ship that barely functions at Tier1 CPU but still works, yet it comes more and more alive as CPU is added to it. --- Like I said, confusing maybe someone else who's a much better writer than I can clarify the general idea.
Which is great news... at the current degradation curve. I think the devs did themselves and the testers a disservice by introducing a very forgiving curve if that is not what is envisioned as the final target. The degradation curve is probably at least as important to suss out as the CPU thresholds and costs.
