HWS was not mentioned at any time however notwithstanding specific playfield limits on HWS this is from the HWS Limits and Restrictions page. 1. Structure Limits Introduction: HWS has structure limits to grant a smooth game experience for thousands of players and to fix some gameplay related problems not yet addressed. 1.1 Blueprint spawn restriction on HWS - Class 7 This is the global server max class size of HV/SV/CV/BA that may be spawned via F2
Closest I've come to what I _imagine_ EGS PvP to be was in EVE Online. So this is pure speculation on my part. EVE uses pre-made hulls with limited slots for weapons, upgrades, etc. Wide range of those so a very wide variety of load outs is possible. Depending on the expected fight those can be readily changed. Every car racing series on Earth has size, weight, engine displacement (power) and equipment limitations, as far as I know. Addressing the Death Cube meta is impossible without artificially imposed, non-rational limits. A Sphere is generally the most efficient shape after all. Can't forget Murphy's 13th law; Make it Idiot proof, we'll build a better Idiot. <-- sry for the implication here, I do not think PvPers are idiots. But, almost by definition, PvPers do tend to be min-maxers, and of course they're looking for an 'edge', would be silly not to. So unless Eleon just ignores PvP in general, which I don't think they should, then some of the dev time should go to supporting that playstyle. The difficult part is figuring out which 'knobs' are effective, then what can reasonably be implemented, and then limiting any negative impact of those knobs on the other playstyles. Class Size exists. Apparently works fine across the board as a very gross limiter. - should be possible to leverage this more by opening it up to Class 2.4, Class 0.7, etc. Finer grain = greater control. Seldom noticed but existant is the max size building limits. - would require some work but various 'size templates' could be added. Would impose various XYZ limits to prevent cubes. Hashed out cooperatively with the PvP community they could define rough designations like Corvette, Destroyer, etc. - CooP Servers and SPers could choose to use them or not; they might be fun. But if they were clearly developed with & by the PvP community then it would 'theirs', and the other playstyles would be far more likely to just say, "neat" and mostly ignore it, unless intrigued. Power generation, to me, is the single most obvious knob. Without enough of it a ship can barely move. Fix up the Rotation mechanic so it draws realistic amounts of power. ** and before the new location-of-thrusters-exert-torque mechanic gets out of hand, impose an artifcial fall off so there's no further torque gain past x percentage from center. Otherwise it -will- introduce a new pizza box build meta. - add in a few size/output steps in generators. Were the above available to a PvP Server Admin they, and their community, could decide on combos that fit their unique playstyle. "Class 1.3, Destroyer-Heavy Template, T4 Power" As a real Bonus Feature for PvP Eleon could extend the 'zone' or 'faction' or 'playfield restrictions' code/options so that mixed ship Faction Fleets were supported. "Factions are allowed x of y in Playfield z at one time" Server Admin grabs a couple zone templates and tags them for a fleet zone. "Destroyers x 7" + "SV-Fighters x 4" + "Cruiser x 1" Edit: decided to recolor an important point
But that's not what Elon is saying now. Elon has been clear that this has nothing to do with performance and the class system was about performance. So maybe we're taking their conversation out of context and ask Hummel again what is this CPU feature about because I believe if the CPU feature was about performance Hummel would say so. I believe he said in the feed forums that this isn't about performance. I don't think anyone saying making bigger ships slower is an issue but this whole CPU feature is removing creative freedom instead of addressing the issue at hand.
Jeff didn't realize when he made these videos that efficiency was turned down. So there is a chance that when 10.6 goes public his ships that are running at 80% to 90% will be at 30%.. So I'm more interested in what his opinion will be once this system goes public. I think the Devs should turn efficiency up now while we're testing it because the current system is giving builders false hope.
I did specify "most" in my original post. We have a couple PvP playfields that are slightly higher than class size 1 (class 3 I think). Not all playfields are max 7, only some of them are. Still very far from your claims of class 20, 30, 40. As I also said all the issues we experience can be replicated in fully vanilla servers. You can see the same slideshow and lag in a server with nothing but 10 players and 10 class size 1 ships. You didn't have to mention HWS, I mentioned it for the reasons I listed. It's one of if not the MP server with the most powerful hardware. It still experiences those issues with nowhere near the sizes you said.
You're free to think whatever you want. Did you read what @krazzykid2006 answered to your post? This is not true : even Hummel - after I insisted - acknowledged that "it MIGHT have an effect", but see how this was expressed in another context (from Rexxus): Worth repeating : "Merging" or code-wise "baking" structures is a good method to improve the performance of 3D objects. Be it for calculations, rendering or other simulations. By changing just the hull to one object, or clustered areas, but leave the rest untouched would already boost the performance dramatically because as you said, calculating the damage block by block is what ruins the performance at the moment the most. Poor optimization is probably the single most mentioned "critic" in Steam reviews. Even in singleplayer, the game has grown enough as to force Eleon to change the minimum system requirements on Steam. And of course, in singleplayer it's not even relevant to have a CPU limit on blocks, but here we are testing and discussing a feature that evidently has not much to do with singleplayer since we can do what we want with "limits" : switch on/off, use the config file.
But if I run a server and I want to allow Class 40 ships on my server then that's my business. Those who don't like it should find another server or start their own server and stop whining. The devs do not need to hardcode these numbers or class limits. Creative freedom is just as important as survival here and this goes back to some PVPers thinking they have the right to tell the rest of the community how to play this game and they don't. If some people do not like the ship size on a server then they should find a server that limits it but they idea that everyone who plays this game should conform to certain PVPers vision is insane.
But "Might having effect" and it being totally about performance is a bit of a stretch don't you think?? Hummel isn't agreeing with that point he is just saying that it might "help" performance. I don't think it really has as much of a impact as we think it might but this is about satisfying those who whine about everything being too "OP".. That's just my opinion.
Why do we assume that HWS has the strongest hardware or they know exactly what they're doing as admins? I hear that name come up like they're the developers of this game and not ELON. The truth is this if you do a steam stat on this game there is maybe 1500 playing this game on the average. I believe it was Kassonade or someone else who posted the total of multiplayer gamers in game over a 2 to the 3 day peroid and it was some where around 200 to 300 people. Some people say well that is because of co op but Elon did a survey long before Co op was added and the survey listed single players to Multiplayers and there were more single players who took that survey than Multiplayers. Most people thought those numbers could not be accurate but looks like they are. So I think Elon should think about these things before being so heavy headed with limits and realize this game has a lot of people who love to build that are ok with restrictions BUT still who want the ability to build what they want which is very possible under the RIGHT SYSTEM. Which the current CPU numbers makes CPU not the right system in my opinion. The current CPU numbers does more to limit builders and people who want to enjoy this game causally than it does balance PVP.
No. The point si not to compare CPU with "merging blocks". The point is to understand the impact difference of having a voxel-based game instead of a "model-based" game, and to what extent doing anything that would have an effect to "reduce block counts" could potentially have "dramatic effects on pc/ server performance". So when hummel writes "it MIGHT impact pc performance" it is probably because it depends too much on things Eleon has no control on : player and server owners decisions. And of course, if CPU doesn't reduce block count in the end, then there will be no difference apart another restriction to build for no good reason, and "no pc performance impact difference". Add to that the fact that they changed flight mechanics and allowed SV-HV docking, which blurs the issues of what is doing what on the engine now, but one thing is clear : it is the block-by-block calculations that have the highest CPU/GPU cost in Empyrion.
My thing is the ships in this game really aren't big at all. They actually small compared to what you can build in other games. Also back in 2016 there was talk of increasing the gird size to add more blocks on each side of the core. Now I play mostly single player and my machine can handle just about any ship you can build. So if the game can handle it then the system I use can handle it and I've also seen certain servers handle LARGE ships as well with no issue. I think some of the performance issues has something to do with certain admins and their hardware as well. You can't always optimize your game to fit everyone's system. Some systems may need to be upgraded.
Everything in this post is BRILLIANT. Now imagine all this with good physics/AI and optimization. It would elevate Empyrion into a new league. The problem is $$$. The Devs need to carry out a fundraiser so they can hire the extra coders they need.
I encourage you to think about the possibility to add way more content with any shaving that can be done on block count (any type). This is clearly illustrated by Rexxus' explanation, and he's not the only programmer to know that. With the added complexity of per-block calculations comes all the bad sides/ glitches and network bottlenecks. In singleplayer it means not being able to "fill" the entirety of the 256 x 256 x 256 grid with any kind of build, even static. A "merge block" solution could allow making cities, huge ships, walking on these moving ships way more easily than with per-block mechanics, and with performance and accuracy benefits across the board, for both singleplayer and multiplayer. It is also much easier to make "moving blocks" of many types if there are not 100 000 other colliders around it.
This is a scary statistics page. The STEAM peak average player count is 3,157, and the numbers are drastically dropping since July 2019, but there are always other contributing factors such as other new game releases. And not everyone plays these Early Access games on Steam. But only 3,000 average players is not good for fundraising purposes. At $50 a pop that would only raise $150,000. We need 100,000 players to contribute $50 for a grand total of $5 million. That would enable Eleon to hire 50 specialized coders for $100,000 a year or 25 for two years. The total number of Empyrion players, currently active or not, has to be much larger than 3,000. Eleon would have the most accurate estimates of this. Spanj has videos with 12,000 views. 12,000 players x $50 = $600,000, enough to hire 6 high end coders for a year.
@EleonGameStudios , Looking at the screenshots throughout this thread, you can see that the result of CPU restriction is a return to ugly, blocky builds. It also seems to have taken a lot of the fun out of building. A restriction on creativity is a restriction on fun. So how do you address the problems that CPU is solving without removing the fun? You have worked hard to add new block shapes to the game. And now added a restriction on using them. That has to be frustrating. Do you remove or lower the CPU value for non-device blocks? If polygon impact on frame-rate was one of the problems then no. I don't have a good answer yet, I only know this - the introduction of the repair bays and repair templates pushed creative builds forward and added a ton of fun to building, - and now CPU has negated a lot of that progress. There has to be a way to solve the problems and keep the fun in. I'm not convinced at this point that CPU is the way. At the very least it needs to be loosened up. What about drastically reducing thruster cost and moderately reducing non-device block cost?
Might be so but when I suggested to him it might be better to wait with any release until A10.6 goes public, he agreed. (Yes Friedrich August, Kurfürst von Sachsen is actual me)
If they hired six programmers it would grind them to a productivity halt; it always takes two cultists to indoctrinate a third, 9 women can't make a baby in a month, etc. It's obvious the guy (whoever he is) that does 80% of the work knows what he wants to do with his game. If he wanted input on that he would be looking for it at the front end of the process by telling us what they planned to work on in N+1 instead of presenting stuff for critique/tuning. No idea why people spend so much time trying to influence that- W=FD ... it doesn't matter how hard you push, if it doesn't move it ain't work.
