If CPU were an isolated incident, I'd say no. Trouble is, it's become a pattern for the devs to implement something badly, then try smearing cosmetics on the pooch after they've already screwed it. Yes, I'm mangling my metaphors. It's fun. We've seen it with "Weapon Kits," which they eventually walked back to something reasonable, we've seen it with Shields (requiring pentaxid) which they haven't capitulated on but at least trivialized, we're seeing it with CPU and with the max-speed restrictions in the flight model, and who the hell even knows what they'll do with future features like "research-based progression" and "thruster obstruction." I used to have plenty of faith in the devs that even if they stayed silent, they were at least listening and would get around to fixing things, but the benefit of that doubt has long since dried up. I don't know who they're listening to, if anyone (though I have my suspicions) but somewhere along the line, EGS stopped being enjoyable. They've got a checklist of features and game mechanics they want to see, and they throw darts at it each dev cycle to decide which ones get implemented this time around - no plan or grand vision guiding them to an end goal, just a bucket of puzzle pieces they're trying to put together without first checking if that piece even belongs on the table.
First part : agreed, and I could have added other items to the list myself : the BA/CV requirement to spawn a blueprint, eternal back-and-forth on various lighting problems, knowing they may be fine-tuning something at a given time that may well disappear later, never fixing the damn motorbike, etc. For the second part, I stick to my thougth that this CPU thing was primarily aimed at multiplayer, and probably to solve PvP problems, and they knew it would generate flame wars so they just went forward with it with some sugar coating reasons we all saw. I can agree to your perception they are throwing darts to establish some kind of schedule, but I would tend to believe that if they are working (in Alpha) on optimization and then adding 3 more features just prior to a sale, that's because they see an opportunity, and still have the capability to get stuff done quickly, or they already have a backstore full of stuff they are not telling us about (like that crouch thing that was present in the very early version and that we are still waiting for...). You mentioned that thing about features being pushed out just in time for a sale recently, and I wanted to react to this with you in private, but unfortunately it's not possible. Too bad. They also probably know that if they have any intent to monetize their servers and to make it a priority, it will also not be received well. But the fact is that the bulk of sales for Early Access games comes in the months following the start of public release, and dwindle slowly after that, for most games. This means that even if they made a good amount of sales since 2015, now being 4 years later it's reasonable to think they are not in the same financial position they were following 2015, and surely are thinking of ways to get a better income than the slow rate of sales they may be having nowadays. Early Access games that can still develop and maintain servers are the ones that either had huge sales at the beginning allowing for sustained development cashflow, and/or they monetize their servers to get a steady income without which they can't afford to keep staff on a payroll. If time is money, knowing how time has passed by, we can draw some conclusions regarding the second part of that simple equation. And that "speculation" leads me to think that is why they are trying to get Multiplayer into better shape, and why CPU doesn't make much sense in singleplayer and why "breaking the workshop" seems unconsequential. This is all conjecture on my part though, as Eleon never goes public with these informations, but that can be seen in many other games right now. Good part is that development is still going on, bad part is that it always smells "money first, quality later". And here we are, sticking around their forums, for various reasons. I don't have very high expectations myself, knowing from estimated sales how much they can afford to spend on qualified programmers and animators, for example, and what is required to make quality features like the ones so many players are asking for. We can still be helpful by researching ourselves what can be done in this context instead of expecting them to risk all their assets with no garantee of future revenue.
Only a mean person would not warn others of a game in development that is taking turns for the worse in design choices that are not a genre staple, and one that is outright hated by players of the genre on top of it. You cannot name a single popular survival game that has a building punishment system in it...they all allow near unlimited building and give server settings that allow an admin to set a cap if they need to for potato servers...and most of those games use weaker game engines.
That's all possible with Empyrion : use the config file ("server setting"), or disable the feature, and no more "punishment" for building. It would not be the same if the game was all wrapped up and sold like that. There is a difference between "warning others of a game in development that is taking turns for the worse in design choices etc" while not even mentioning that some irritants have mitigation means already built-in, and trying to pull tears from the devs by announcing the intent to leave a bad review, while still playing the game. Many words come to my mind for this, but that's more your style, not mine.
Just curious, I thought they said it couldn't and wouldn't be disabled? Did they provide this option based on community concern over the feature?
They provided it based on the outrage at the initial unveiling of the system. Initially CPU was going to go in and that was it. It was intended that way in order to prevent the workshop from fracturing into CPU-compliant and non-CPU compliant sets.
Honestly I'm fairly sympathetic if they simply don't have the dollars to make the game that we'd like. Games development is hugely competitive and from what I've read the wages sometimes suck because "you're lucky to working in the industry". I've got HUGE numbers of hours of enjoyment out of the game for only $30US or something, and would totally be willing to pay for the game several times over if it meant more active development and that they'd truly listen to their community. I don't know what model they could shift to facilitate me giving them $$$ though. I think if they proposed a proportional $2US a month or something I'd be ok with that. But then many would object as they bought the game not expecting further costs! I do think a discussion about the business model would be great, but they don't seem very comfortable being transparent so I don't know if that can happen and I think there would be trust issues. There's no real way to really even tell if it is the driving issue, but Kassonnade even if I disagree re multiplayer, your reasoning on the finance stuff does seem legit.
As a side note, I'm personally wary of letting the workshop become to much of a shackle to exploring improvements, and would be fine if this did happen. But only once CPU was an elegantly working feature that improved the game like M&V does. They should create more control for CPU related experimentation, and it might be that some of the talented server managers could provide some ideas and tweaks to make it less of a pain as a feature.
M&V still isn't fully functional though. Many blocks and items have broken mass and volume. Just look at the cargo containers for HV/SV. They should weigh no more than 8kg, the weight of a steel armor block. But even though they're empty most of them weigh 300kg, which is more than their CV/BA counterparts at 250kg.
You're right. This is why I think Eleon should consider opening up more control to the server managers to configure stuff and then feed that back into the default config. I mean you don't want to be subject to casual whim of anybody, but many of the server managers have a vision and the time to tweak things and get it right.
I started doing some work towards classifying blocks, entities and devices, but it's a 14k lines mess with many things belonging in more than one category, mostly the "template" blocks which define general behavior and characteristics, that may need (or not) to be adjusted along their child devices. Most "limits" are unknown, and I'm tired of watching the game stuck on the loading screen because it doesn't accept some changes I did for testing. It doesn't crash, it just hangs there, because it can't resolve conflict between some illegal value in the config file and the target object. Players proposed a few times to maintain some kind of "config file" repository thread, where all kinds of presets could be made available for players that don't want to edit the config file. Nothing followed up.
Yikes that sounds bad. I was thinking of looking into whether the changes I'm after are something I could throw together myself on a custom server. It doesn't sound hopeful.
For the most part it's not a complex thing to do, most devices are easy to find and recognize, and if not straying too far from the original values there is no problem. Problems arise when putting in numbers too large or when changing identifiers without knowing if it is "allowed" or not, like the damage multipliers for specific materials. Edit : I recently posted a macro example for Notepad++ to change all CPU values to 1 in the config file with a single pass of the macro, for those players that still want to use CPU but don't want to grind for the extenders. Knowing that the current values are : The current values are HV: 5.000 (T1), 12.000 (T2), 30.000 (T3), 70.000 (T4 SV: 6.000 (T1), 15.000 (T2), 40.000 (T3), 100.000 (T4) CV: 200.000 (T1), 500.000 (T2), 1.500.000 (T3), 10.000.000 (T4) BA: 80000 (T1), 200.000 (T2), 500.000 (T3), 1.300.000 (T4) ... this means that players can play with CPU on and put all wanted devices without fear of busting the T1 limit (core only), then just care for the hull blocks. This brings up the question : will they allow us to also adjust CPU for blocks in the config file ? Because now we don't have these values.
I was wondering is it feasible to link CPU automatically to size by rating the CPU value of all passive blocks (steel etc) to be negative values, so they effectively add to your CPU count instead of subtracting. Could that work? If thrust, weight and volume can then be adjusted for the right flight dynamics, this would come close to allowing most of the changes I've been requesting from them around these topics to be implemented on a custom server. Pretty bad way to achieve it, but still, I might be able to build a demonstration setup to test the model I've proposed in other posts here.
I guess you mean the contrary : if you add devices or blocks with negative values they will lower your total count? Add 10 CPU with X devices, remove 10 CPU with Y device with negative value, etc? Yes, it actually works, but we don't have the hull block's values in the config file yet. I tested it with weapons, and they subtract from the total. Players could practically make their own CPU extenders with some deco block, for example, with large negative values.
"I need One Hundred.... BILLION CPU.... and sharks, with frikin' laser beams, on their frikin' foreheads."
I was thinking that too I definitely would like to link to blocks count or ship size in some way though, so amount of stuff you can support scales with the ship size. Now all I need for a scalable CPU/power model be some way to make generators much bigger so they are the size of actual ship engines. Like just expand the model to be 10 or 20 blocks long. I wonder how I could convince them to do that...
FYI we tried to convince them of this when CPU was first talked about even before 10.0 came out. They already had a partial way in place to put in size limits and that was with build "size" and that all they needed to add was a way to set a game up with size restrictions which actually would have required far less work than programming an entirely new system for it and would cause zero, that is no damage at all, to the core of the game. What we need is to actually hear from someone at Eleon that CPU is going to be in, period, end of story and then we can find out if they are willing to EXTEND it. If they add one more tear to it, giving that tear 10x the points and an actual game option to have that T5 OFF, for servers, then it will become a system that everyone would be willing to use since those that are saying they dont want it, dont want it because of the restrictions in building or that they are going to run a server that will be capable of actually running the game with large builds. Give us a Tear 5, problem solved for those that hate it. Give a way to turn Tear 5 off, their very reason for making it remains. Suddenly CPU is a thing virtually everyone can get behind.
Let's not confuse "making a problem irrelevant" with actually "solving" it. A Tier 5 with near-limitless CPU still has all the problems and drawbacks that a T3/T4 would, and the main issues around CPU aren't that the existing caps are too low. If the existing pattern is anything to go by, a T5 would require 8 extenders, still rely on rare Optronics components, and essentially be impossible to build in any normal SP game. Given that server owners can already restrict size class, there wouldn't be much point to using a hypothetical T5 as a restriction benchmark - you could easily cripple a potato server with a high-class T4 CV already. No, until they actually knuckle down and fix the underlying issues with CPU, and stop trying to appease us with a bit of number-shuffling, CPU will remain a fundamentally broken mechanic and being able to ignore it doesn't mean it's something to get behind.
