I am all for it being by shipsize, but the problem is that can go up and down and be exploited in all likelihood. While it's fine for SP, I imagine it would make for server admins nightmares in MP. It's all in the execution. Because nobody wants their guns suddenly falling off because their ship took some damage and lost some blocks, but then how do you code it to prevent people from building a large ship, loading it with guns, and then removing a load of blocks. Oh, and definitely all for anything being able to dock to anything. That is something in SE that is actually better. Granted I don't know if it is possible to equalize the mass & thrust across all connected ships in Empyrion, which is kinda key to it being balanced. LOL, yeah that should have been "headcanon"
That depends on how/if they change when ships are checked for validity. A lot of things don't get updated (like center of mass and size class) after spawning, but obviously that's not ideal and might change at some point. Though at the very least, it would base on what state it's at when it's spawned, and if the BP would not be legal then it couldn't be spawned just like any BP that puts 100 turrets on something. The advantage of basing it on weight is that it's practical and has inherent pros and cons even if you exploit it. If you remove a ton of armor, then you've removed a ton of armor and your vessel is less protected. Even if you did it to exploit the system and reduce weight post-construction, you've still made your ship weaker in the process. In BP terms, if you build a large ship, cover it with guns, and then remove those guns and save it to BP, it would become an illegal BP that can't be spawned on a server where illegal BPs can't be spawned. So the only way to exploit that (and only currently because the game doesn't check this) would be to do it all by hand -after- you spawn it. If you're going to manually do that post-spawn every time, it might be an exploitable advantage, it might not be worth the trouble. If nothing else it wouldn't function with repair-t0-BP and that alone might not make it worth it or practical enough to use on a standard basis. If they do add systems to check for validity, I guess it would depend on how they'd implement an 'overweight' penalty. Perhaps the ship just loses a ton of mobility. Depends on whether or not we would consider it reasonable that a half-demolished vehicle that lost so much weight in damage that it changes class and becomes illegal (by no intention of the pilot) should also suffer these penalties. I think it's reasonable that a vehicle would reach a point where it just can't be piloted anymore, and either needs to be recycled or repaired on the spot. It would also open up interesting gameplay opportunities for salvage and rescue of crippled vehicles. edit: other things like whether or not the engine is powered up could also be part of this to stop the whole magic floating-with-no-engines crap. Actually, on that note, it seems to check some things while there is a pilot in the cockpit. If it checked size every time there was a pilot in the cockpit, it would render exploit builds functionally useless.
The problem with these classes is, wet-water military classes have little to do with the needs of a space explorer. The actual Empyrion vessel classes are things like: Mobile Base, Hypersled, Drone-shooing-off vessel, Turret assault vehicle, base assault minihover, shuttle... In short, there need to be more civilian classes.
That's a good point to consider. Mass is exploitable, dimensions are exploitable, class is exploitable, CUs also are exploitable. The only actual limiting thing is the core - it accomodates devices, dictates the size of blocks and who docks to who. What if we have not the "block size" cores, that already create a lot of questions with SV/HV classification, but the "role" cores, that lore-wise hold virtual device connectors (finite) and firmware? Player should be able to unlock basic cores in the techtree, but special ones should only be traded, recovered from derelicts or carved out from enemy vehicles (assuming they have a spare core in the lootbox just in case, like in tutorial) - a great incentive to go explore places. Cores can and probably should accomodate arbitrary number of CUs for their devices. In case of core damage to the cluster some devices become unsupported and do not function, if the underlying role does not support them. You go around in a "courier" HV, wander too close to POI and got one of the two cores scorched - the role drops down to what one core supports, that's a "runabout" and you lose power to jump board and medium engines, but still can drive your crippled HV away. If you were in a HV with a pimped-up single core, you'd be in deep trouble in that case. Examples as I see them are below. Only maximum amount and tier of things is mentioned (if combat steel listed, all steels below also applicable). Cores amount is for basic core clusters, 8 cores can be 8 "X1" basic cores, 4 "X2"-cores, 2 "X4"-cores and 1 "X8" cores. *** HV (no flight)*** Civil (no weapons): Runabout (very easy, very cheap, 1 basic core) - basic steel, open cockpit, 1 generator, 1 fueltank, 1 cockpit, 4 hovers and 4 small engines OR equivalent (in the future). Role - better than afoot Courier (2 cores) - as above + closed cockpit, 1 cargo, 1 jet OR 2 medium thrusters OR equivalent + jump. Role - urgent delivery. Motorhome (4 cores) - as above, hardened steel, no hover limit, no engine limit, all survival devices (O2, fridge, constructor). Role - outdoor camping. Harvester (6 cores) - as above + supports drills, drillturret, multiturret, harvestbox. Role - obvious. Multipurpose (8 cores) - as we have now (still no weapons). Rare: Large Hauler (unique) - hardened steel, big blocks(!), no limits. Role - bulk freighter. Mobile landing pad (unique) - big blocks, hovers only (no engines), accepts docking requests, have Repair Bay and Blueprint Builder (when it becomes a thing). Role - mobile dry dock. Tow truck (unique) - small blocks, docks other things to itself(!), no engine limits. Role - moving and rotating heavy land vehicles (think mobile pad mover). Military: Personal Defence Chair (2 cores) - basic steel, basic hover+engines, open cockpit only, 1 CU of weapons. Explorer (4 cores) - basic steel, closed cockpit, survival gear+constructor, 2 CU of weapons. Role - outdoor camping with style. Heavy explorer/APC (6 cores) - as above, hardened steel, no limit on hovers, 4 CU of weapons. Role - outdoor camping behind the enemy lines Multipurpose Armed (8 cores) - as we have now (+weapons), arbitrary number of CUs. Rare: Tank (unique) - big blocks, hardened steel, enough CU for 1-2 artillery + support. Role - heavy assault platform. Mobile fortress (unique) - big blocks, only hovers, no engines, combat steel, arbitrary number of CU. Role - mobile armed BA. [Sorry, I'm starting to burn out, will continue on SVs/CVs later, if anyone interested. Main concept is restricting engines to atmo and space with several roles getting both, and making rares like space tug and warp platform that CV can dock to].
I would simply suggest that the size class determine the multiplier on gravity for determining thrust to lift ratios. So, a size class 1 ship only requires 1 times 9.8 m/s to overcome lift requirements. This means if you want to spawn a size 5 ship, you had better do it in space or it just became a base as you would need 5x9.8 m/s or 49 m/s downward thrust in order to get it into space. This means the huge ships will stay in space and have to live around space stations. And the smaller ones will work as shuttles to bases on the planets. It also gives a purpose to moons, in that a moon with 1/6th gravity becomes a prime spot for Large CVs to be stationed as you can defend them with a ground base easy. Use that plus the CU mechanics and you effectively, create a mechanic that automatically limits size class to either planet-space vehicle and pure space vehicle. This also doesn't prevent someone from spawning a size 10 craft on a planet and mounting a huge amount of lift thrusters just to get the craft into space. That is quite realistic. The assumption is that same person would end up removing those mega thrusters after they reach space.
Note that my proposal for the CU system was designed specifically to make it not exploitable, by having the number of CUs provided per block scale sublinearly with the number of CU-providing blocks. I also never intended the system to be used for classification of ships and/or to restrict what kinds of hardware they could mount. I really don't understand why it's desirable to artificially give certain roles to certain types of ships. Sure, in games like Elite Dangerous, this is done because the ships themselves are pre-built and we get limited ability to modify them. In Empyrion, we build everything from scratch; the difference between an ore hauler and a destroyer is that one is stuffed full of cargo boxes, while the other is bristling with turrets and armor. Let physics and general ship resources like CUs be the limits within which ships must be designed. This gives players the freedom to optimize for their performance and ship systems priorities.
Because otherwise you have what exists now: No roles at all. At any given size every HV/SV/CV is just maximum punch and durability for its armor, min-maxed every which way with no real distinction except where the designer feels like adding it. You can have a super-fast tiny mosquito of an SV, yet it has maximum x4 homing missile turrets for an optimized bomber role, you can. It will have the firepower of a ship 4x its size with no drawbacks because you can hit that weapon cap on even a tiny ship. A CU system would add another layer of barriers to jump through, but unless certain devices are weighed with huge disparity between them, it won't really change what anyone can build. And if you ARE going to weigh them, then you're making roles anyways, just assigned by devices instead of the overall build.
The core problem is that it's too easy to achieve maximum stats; that is to say, no tradeoffs need be made. The CU system would help with this, but we also need device stats themselves to be modified. Consider what would happen if thrusters put out a factor of 10 less thrust and had to be exposed to space: the only ships that would have ridiculously high acceleration would be those specifically designed for that purpose (they'd be built around their main thruster cluster). Now give inventories mass: you'd see most ships trying to minimize their cargo (including ammo) and armor where possible. Now add in the CU system: designing a small ship to mount ridiculous numbers and types of weapons would require including the power, mass, and volume requirements of CU-producing blocks, resulting in the ship getting substantially larger, or it just not being able to mount that many weapons. With these changes, the SV you described simply couldn't be built. You end up getting to pick two, perhaps at most three, of: armor, weapons, acceleration, cargo. Right now you can have all of them, and that's the problem.
Empyrion already does it the right way: thrusters provide thrust, acceleration depends on thrust to mass ratio, and a ship needs enough acceleration to overcome gravity, or it's not going anywhere. Sufficiently big CV would not launch without sufficient number of thrusters, and is prone to falling when its lightly-thrustered sides are facing the ground. If you did not encounter this situation before, it's probably because you have little experience building a carrier or a mobile base on a surface of a planet, or your aesthetic sense didn't allow you to put too few liftoff thrusters on your ships. Even modern fighter planes can do pretty well as bombers. The main difference Empyrion SVs have is that they can store a truckload of missiles in a single ammo box, and if that is not enough, the pilot can pull a few more out of his pockets. While modern planes mount a few giant missiles or bombs and tend to run out of them quickly. Weapons are just inherently easy. It's armor and survivability that is hard.
But that's not hard to do. I already have a tiny ship with exposed thrusters and 8 hardpoints. The reality of the situation is that no matter how many weapons you mount on an SV, you can still only mount so many of any given weapon class, and only fire one weapon class at a time. So while you CAN have, for example 8 rocket launchers on an SV (4 dumb-fire, 4 homing), you can only practically use one of them at any given time, and their reload/cooldown times are not significant enough to swap them each time you want to fire. So in reality, regardless of loadout, you're firing 4 weapons tops. So the range of 'ridiculous' in weapons is huge, but the practical barrier of entry for what it takes to have significant damage output is actually very low. So if a small SV can pack 4 rocket launchers after CU, nothing has really changed. You've limited some versatility maybe, but the core strengths are the same. UNLESS you either scale it such that small SVs can't actually get to 4 weapons (which may be good, may be bad. Depending on how that scales it might be infeasible to run heavily-armed gunships if it's a linear scale), or you make heavy weapons cost more CU, which as I already said, IS making 'roles' just defined by weapon/device instead of the overall size of the ship.
*Wonders why so many people are trying to take the Sandbox out of the Sandbox...* We don't need Arbitrary Limits telling us "You can't do that for no reason at all whatsoever other then I SAY SO!!!", we need actual intelligent Game Mechanics, which the CU System is looking well able to provide for us. Edit: Also, don't forget, part of the purpose of the CU System is to provide REAL Balance so the Arceus Damned Arbitrary Max Weapon Count Band Aid Fix can go bye bye.
I assume that in the future we'll be able to fire all fixed weapon types simultaneously. In any case, it's trivial to build a CV with the maximum number of turrets of every kind and to have them all fire simultaneously. One goal of the CU system is to discourage weapon spamming by requiring what amount to extra support devices (the CU-producing devices), the required number of which increase nonlinearly with the number of mounted weapons. Yes, I had intended that heavier weapons would consume more CU (as well as more power and be more massive). Does this end up restricting them to larger ships? In general, probably; but there shouldn't be anything stopping someone from deciding that their SV should mount a CV-sized fixed laser and designing their ship around making that happen. If by 'roles' you mean ships that are specialized for a purpose, then I think we agree, as that is my goal as well. But I want to arrive at it without prescribing what those roles should be, and without locking a ship into a particular role because of arbitrary things like the type of core that was used to start it.
It won't accomplish what you're hoping it will by itself. The whole reason most game mechanics are abstracted is because a true 1:1 realistic system is generally not feasible. In a perfect world, everything from weight distribution to device layout to aerodynamics, recoil, hull stress, gravity, atmospheric density, and so on and so forth would all impact how ships are designed and would reach an end result of some level of realism and believability that still allows all sorts of creative possibilities, from the practical to the absurd. But few games do this. Why? Because it's a mess to program and can be a nightmare to balance. The fact of the matter is that CUs are arbitrary too. You're coming up with a fictional stat that isn't necessarily based on anything realistic, so the values you assign to it aren't going to be based on any realistic physics, they'll be based on what 'seems right', which means they can be wrong, which means that they can be exploited, which means they need to be tweaked each time something breaks the intended system because they're based on nothing more than human approximation. Or, you go with something simpler, achieve more or less the same end result with a possible loss of the truly-ridiculous possibilities, and it takes a tiny fraction of the time and implementation costs to actually get it into the game and working. And then all those man-hours get put to something else. Always have to factor the man-hours, folks. It's the reason why games just don't have everything they want done perfectly. You have to pick your battles in game development, and anything you go into whole-hog is going to come at the expense of something else. And currently there is a LOT to work on in this game.
I'm not championing the idea of classes, I'm just throwing out ideas that appeal to me, or I've seen work before and makes sense. I've already seen a couple of ideas here that are very tempting too, in particular the Size determines device capacity/availability. And more so the combination of that and 2 basic classes; Civilian and military. If the Core CU was in there too I feel that may cover Freedom, few direct restrictions, and a rudimentary class system that should work well with existing block sizes On a side note I'm disappointed that Hummel didn't mean Pig like I saw in another thread, that would've been an epic nod: War Pigs - Black Sabbath [Edit: *salute Midas* Well done for reminding us that no matter how clever or fair our eventual system is, some poor bugger has to Code it, and that stuff is seriously time consuming. And brain melting if things get too complex. Half the reason that bug testing and alphas are a thing is we have to make sure that no-ones logic failed, or if we outright didn't forsee all the consequences.]
Even if all major devices (weapons included) consume exactly 1 CU, the nonlinearity of the CU system would still prevent ships from becoming overloaded with weapons. It's the nonlinearity that ensures that nothing breaks catastrophically. All right, so what's your solution? It's already been established that class (the Eleon ship performance metric), mass, and size aren't suitable. How would you propose to determine the size of a ship? Linear dimensions? Surface area? Volume? How would you propose to differentiate between 'civilian' and 'military' ships?
For the sake of the idea, I do like a CU system, I just don't think it's necessary to implement something that complex at this stage. The reason I suggested what I did is because essentially all it would take is changing some permissions. It's making use of stats and features already present in the game, and just adjusting how they are applied. That's a mod-level change at best. I'm not talking about things breaking catastrophically, I'm talking about things not being balanced to the point that they have the intended effect. This would be easier to discuss if there was an example, though. Where was this established? I must have missed something. It shouldn't be unsuitable as far as I can tell.
Suppose device restrictions are implemented based on Eleon's class metric; then ships with tons of lights, windows, and exposed high-polygon hull blocks will automatically have an advantage. Suppose device restrictions are implemented based on mass; then ships packed with T2 RCS will automatically have an advantage. Suppose device restrictions are implemented based on size; well, first we'd need to agree on how to measure size. If it's bounding box volume, then spindly ships (or ships with disconnected parts far away from the main body of the ship) will automatically have an advantage. If it's surface area presented to the bounding box, then large ships will be at a distinct disadvantage due to the increase in volume/area ratio for large ships. If it's number of blocks, then ships will be designed with large numbers of cheap low-mass blocks like truss blocks, and will have a substantial advantage. My assertion is that none of these are suitable to be used for implementing device restrictions.
So, for starters, none of this is 'established'. Just some players looked at it and said 'mweh I dun like'. You almost had me thinking there was a legitimate reason it wouldn't work due to game/engine constraints. I would base it on weight/tonnage, personally. It could be done with the current size system, and still be better than the current restrictions, but it's an inelegant solution. I would advocate weight entirely, but I don't know how much work would be involved with changing the class system from dimension-based to weight-based. And yes, certain designs SHOULD have an advantage if they stack on certain parts. I'm not sure how tons of T2 RCS shouldn't equate an advantage. It does this currently, unless there's some balance concern I'm not aware of with current RCS. Why would that be a bad thing or need to be changed? Maybe T2 RCS is a bad example to illustrate the problem, but I'm not seeing why it would be an issue.
Ship/base limitations should theoretically be based on nothing more than Power generation ability. How much it can generate, how much it can store, how much it can deliver to devices at any one point. The CU system is a twist on this that @geostar1024 picked up and ran with. If we really wanted to limit ship abilities - that starts with it's devices. Thrusters, RCS, weapons, shields, forcefields, etc.. all rely on one thing: power.
