Mode: Creative v. 1.5.5 3444 No changing game files How often - is unknown Critical - Very Critical The bug consists in the fact that during the construction of CV - the size class has greatly INCREASED -> from 3 to 18 (!) Description and history: I took a fragment of the garden from the previous CV, and began to build a similar CV, adhering to the structure and design of the previous CV (!) ... during the construction process, I used "hot commands" to quickly replace blocks (any block in hand + SHIFT + right mouse button to remove a block or module) ... also actively used the "N" construction window - selected a section, copied / cut / pasted (!) Important - the number of "controller containers" (with a maximum volume of 320.000) = 7 pieces (and in the previous version of this CV = 6 pieces. Important - I increased the number of K1 generators from 3 pieces -> to 7 pieces. Important - the number of engines - I DECREASED - removed 2 of the "VERY BIG" ones, and replaced them with 4 pieces of the "BIG" engine (to reduce the consumption of CPU points (!). As a result (grand total) - the number of modules (constructors + weapons + turrets) = 1: 1 - the number of engines - SIMPLIFIED - there are more of them, but in terms of CPU points = less (!) - the number of building blocks (including xenu) = INCREASED 2 times (there was 7000 xeno-substrate, now 18000 xeno-substrate) TOTAL: class size INCREASED from 3 => 18 (!) THEN I did the COMPARISON TEST == >> I took the old version of CV, which is 3 size class, and made an EXTERNAL ATTACHMENT (!) (See screen) I added a LOT of xeno building blocks + added 2.5X MORE different modules: + fuel tanks from 52 pieces => up to 62 pieces + generator with 7 pieces => up to 15 pieces + oxygen tank with 12 pieces => up to 25 pieces + added x4 "VERY BIG ENGINE" + added 2 repair stations + added x2 times the number of medical devices TOTAL: the size class of this test CV == 6 (!) : please note SIZE CLASS = (6) : Pay attention to the NUMBER OF DEVICES (!) = (624) : THEN WHY during construction - class size was increased to 18 (?????????) : please note SIZE CLASS = (18) : Pay attention to the NUMBER OF DEVICES (!) = (244)
Your triangle count went from 22.9K to 183K that is the most likely reason why the size class got so high.
It's sad to hear that the number of block vertices strongly affects the value of the class size (!) Is there a command that changes a block from one form -> to another? (for example, "pyramid" is replaced by "full cube" (?) ================================== In general, the game has a VERY MUCH STUPID MOMENT, for example: > the number of vertices in the block -> affects the size class (which is stupid == block is ONE, and it should NOT matter how many faces it has, or what shape it is (!) > some blocks - for example "heavy building windows" == >> are DEVICES ... > all building blocks = ABSORBE (consumption, use) CPU points (!) (this is generally ABSURD (stupidity) - in real life it is identical that an ORDINARY BRICK from which a house is built - REQUIRES CONTROL OF A COMPUTER to absorb or repel water from the rain, or stay elastic to support the weight of other bricks on top (!) Agree that it would be STUPID (!) Then WHY is there such stupidity in the game (???? !!)
replaceblocks is a command worth looking into. As for blocks costing cpu, I don't find it stupid at all in all honesty and am perfectly fine with it.
It's very strange that it doesn't bother you that blocks spend CPU points (?!) When you lack these CPU points - then you will think - WHAT TO CHOOSE - more armor blocks, or increase the volume of the AMMUNITION DRAWER (?? !!)
I find it strange that other people have a problem with it Just adds to the fun of building something for me. Forces you to chose what's important for what you want it to do, in all honesty I'm not likely to change my mind on the issue.
... and ... This horse was beaten beyond death. A short search in the forum for "CPU" will reveal the ugly truth... Some like it, some don't. If we were to make some statistics, we would see clearly that the majority of players against CPU were mostly Old Timers present on the forums when the feature became a thing, and the majority of players being "fine with CPU" are mostly newcomers that came after the fact and had no discussions on it prior to the feature being implemented. Parallels can be drawn with many other domains of society to see what is going on here, which has more to do with social perceptions and "group compliance" than any kind of objective assessment regarding utility/ fun/ relevancy of X game feature. Majority of players are not building stuff for the benefit of others, and may not see the "fun" in making building too complex. But then again, this was debated a lot so no need to repeat, but @bbk.3164 I suggest you make a quick search on CPU and see what was mentioned about it, pro and against. I, too, disagree with building blocks costing CPU (and many builders also) but I understand why this was done (server/ PC performance). I humbly suggest that because bbk.3194 may not be a native English speaker, your usage of "you" here might sound strange if you (!) are talking about your personal interpretation, and not a general one.
It is the number of rendered faces that matter. Building a 9x9 cube with all full blocks, only the exterior faces have to be rendered because the full blocks mesh together. Even if you use god mode to clip into the blocks you can only see the exterior faces because the interior block faces are meshed into one giant block. Build the same 9x9 cube but use all pyramid blocks (or even worse, 4 way connectors). Every single block has to be rendered all the time because the faces of the blocks don't mesh together. Use god mode to clip into this 9x9 cube and you can't see through it like before, you can only see as far as the next block because they are all rendered. This is why the shape of block used matters as far as class size. Some blocks are MUCH more performance demanding than others (4 way connector as an example). This has an extreme impact on performance, both in SP and MP. Remember, that is exactly what class size is. Class size is a performance rating and nothing more. It has nothing to do with the physical size (although physical size IS a small part of the overall calculation). We asked the devs years ago to change the name from class size to something else because it is very confusing when it is a performance rating and not a rating of the physical size. They obviously didn't take our suggestion seriously.
Thanks for the detailed explanation Then - from your words: -> "that a simple 9x9 cube has ONLY EXTERNAL visible edges, but inside - the edges are connected, therefore invisible", And -> "a curly block (pyramid) even INSIDE a 9x9 cube should ALWAYS SHOW all its edges" == >> it follows that (conclusion): CONSTANT DRAWING OF THE FACES OF THE PYRAMID, WHICH ARE INSIDE THE 9x9 CUBE, AND WHICH ARE HIDDEN FROM THE SCREEN == >> then this == GRAPHICS OPTIMIZATION PROBLEM (!) Ideally, a normally optimized graphics should be like this: * show on the screen ONLY THOSE ELEMENTS that should be visible to the user (!), and those elements that are "on the back" of any element - it is logical, respectively, MUST NOT be shown and drawn, and therefore - it makes no sense to keep it drawn, but cache to draw on the screen at any time if the user turns the camera in his direction (or enters the 9x9 cube in god mode) (!) In addition, I noticed that all the modules will be drawn only at a short distance (for example, at a distance of less than 100 meters I see 100 modules - fuel tanks, generators, etc. ... and at a distance of 101 meters - I already see 99 modules (! ) and this is NORMAL to reduce the load on the video card (!) Therefore, it remains very strange that the game engine CONTINUES "DRAWING" the faces of the "pyramid block", even if they are INSIDE a 9x9 cube, but the player is OUTSIDE this cube (!!!)
That would be the programming environment, not a "Choice of the Devs". They have chosen a Programming Engine (Unity), one of the most popular for game development. They are bound by the rules of that engine. IIRR they recently updated to the latest version. I'm not a programmer, but have been a Tech for a long time. As I understand it, the problem you are finding here about how the blocks are rendered is NOT in their control, the programming engine determines rendering decisions. There are some programmer types on here, feel free to correct me ... Wouldn't be the first time I've been wrong in my life.
Aside from server spawn limitations, I really find the whole "size class" value to be largely useless and meaningless, as it has nothing to really to with this physical dimensions of a ship. A ship that is 300 feet in length can be of the same "size class" as a ship that is 10 feet in length. "Size Class" is really "Server Load Class", and some things do create heavier loads - like glass windows.
