Rejected Big Cubes and Small Cubes

[CactusPungente]

I was building a Tie Fighter in-game, when i saw that even if i was putting a lot of effort in proportions, it was way too big to be a fighter. So a suggestion came up in my mind: why not add "smaller" cubes than the normal ones? At first sight it may seem like a waste of IDs, but i may have figured out how to do that, without using IDs aswell.

But first let me answer some of FAQ that may come up, like:
-How to use them?
-How they will look and how much smaller will they be?
-What kind of blocks shall be "small"? Will they have an effect (like a "small" power generator), and if so, how it's strenght will be calculated?
-What will be their use?

How to use them

The Devs may add a command button to press during build mode capable of switching between normal blocks positioning and "small" blocks positioning.
How will they look and how much smaller will they be

I thought that "small" blocks may look like this

Spoiler

As you see in the image "small" blocks will be half the normal dimension of a block. I thought about adding even smaller blocks, but this may be up to Devs to decide.

Will they have an effect and what kind of blocks shall be "small"

Not all blocks currentely present in-game may be smaller. You can't put a "small" weapon computer or jamming/cloacking device on your ship, the only blocks that may be "small" shall be everything except systems (weapon computers, effect computers, jumpdrive computer, jamming/cloacking computer and support computers). All other blocks (inclused some blocks that may put an actual effect on the ship like power reactors, shields, weapon barrels, etc) may be "small", at condition of making their actual "effect" 1/8 of their normal effect as normal blocks.

Spoiler: Explanation

because their volume is 1/8 the normal volume of a block

Volume of a Cube = side^3 so (side/2)^3 = (side^3)/6

The ID's problem

It can be solved by adding fractions. Going in "small" cube mode by pressing a button and then placing a "normal" cube will only take 1/8 of its quantity. For example having a grey hull cube and placing (while in "small" cube mode) one will only take 1/8 of it's value, so you will see that the quantity of grey hulls in your hand are 7/8

What will be their use

This feature if put in-game may add a lot of detail to spaceships. I , as a player, always wanted to add more details to my ship, but the blocks were a way too big to do something like that. With those altrought you may add all microdetails you want, like coloring only a fraction of a cube or doing little wedges. The only limit is your creativity!





Tell me what do you think about that!

 

[therimmer96]

It can be solved by adding fractions. Going in "small" cube mode by pressing a button and then placing a "normal" cube will only take 1/8 of its quantity. For example having a grey hull cube and placing (while in "small" cube mode) one will only take 1/8 of it's value, so you will see that the quantity of grey hulls in your hand are 7/8

I don't think you understand the ID's issue. Each individual block, even if they look and behave exactly the same, has to have a unique ID, so the game can work out which block is which when it saves them. The issue is not how the blocks will be counted in inventories.

"why not just add meta data that says this is a small block"
Because that means more data for sending over the network, and the game already struggles there. Schema is already pushing his limits on what can be sent over the network per block.

This entire idea would also cause more graphics lag, as a ship built entirely out of these would have 8 * as many blocks as a current ship of equal size.

It's a nice idea, but horribly impractical. It would ruin so much about the game it's not even worth it. This has been suggested many times, and each time it has been shot down.

 

[CactusPungente]

I don't think you understand the ID's issue. Each individual block, even if they look and behave exactly the same, has to have a unique ID, so the game can work out which block is which when it saves them. The issue is not how the blocks will be counted in inventories.

i know what you mean here, but the problem could be solved by making the preset of cubes -> "small".
What do i mean by that? simply that "small" cubes may be the new "normal" cubes, and switching between "small" and "normal" may be as switching between 1x1x1 and 2x2x2 in advanced build mode. The IDs are mantained and a bigger variety of detail may be added.

This entire idea would also cause more graphics lag, as a ship built entirely out of these would have 8 * as many blocks as a current ship of equal size.

grafic lag is an issue constant in starmade, the only way to fix it is a new graphic, but this is not the thread to talk about that

______________________________


Maybe this is not the right way to add more details, maybe something like spray painting on ships may resolve this detail issue one day, but i think that adding this feature may not be a bad idea.. simply because the cubes are someway too big now, by my point of view, to add small details a Ship Sandbox game deserves to have

 

[therimmer96]

grafic lag is an issue constant in starmade, the only way to fix it is a new graphic, but this is not the thread to talk about that

Yes, it is already an issue. But that doesn't mean we should stop considering it when people make suggestions that would add 8 times more graphics lag.

 

[CactusPungente]

Yes, it is already an issue. But that doesn't mean we should stop considering it when people make suggestions that would add 8 times more graphics lag.

You're right! Well i'll close my thread it's useless by now :P

 

[therimmer96]

Not to sound rude, but it probably is

This has been suggested countless times, and each time shot down, including officially.

 

[CactusPungente]

nah, that's not rude actually, i'm new to the forum community and my researches of old threads are not in depth, so it's good for me to have answers! Thanks for the info!

 

[Comr4de]

The ID's problem

It can be solved by adding fractions. Going in "small" cube mode by pressing a button and then placing a "normal" cube will only take 1/8 of its quantity. For example having a grey hull cube and placing (while in "small" cube mode) one will only take 1/8 of it's value, so you will see that the quantity of grey hulls in your hand are 7/8

Unfortunately that's not how the block ID system works. One sec while I type this bad boy up

Basically since it's an entirely diferent block type you won't be able to just use the same block ID. The difference between the smaller block and the regular block needs to be represented somehow lol

 

[Mariux]

Eerrrr... No. This is one of the main resons why I prefer SM over Space Engineers. It's consistancy.

 

[Ithirahad]

The ID's problem

It can be solved by adding fractions. Going in "small" cube mode by pressing a button and then placing a "normal" cube will only take 1/8 of its quantity. For example having a grey hull cube and placing (while in "small" cube mode) one will only take 1/8 of it's value, so you will see that the quantity of grey hulls in your hand are 7/8

Data values don't work that way... Unless you're suggesting that we make all our blocks hold 3 floating-point numbers rather than 3 bytes. And believe me, you do NOT want them to use 3 floating-point numbers. (Hell, I don't think you'd even want 3 shorts or ints. 'Tis lot more load time and RAM usage)

EDIT: ...Or, unless you're suggesting dividing up the current block grid by some divisor like 16 or whatever... Also a bad idea seeing as ship files (Actually, ALL entity files, including planet segments ) would suddenly get that many times larger. Yikes!

However, I do recognize the problem here, and I do like your proposed solution for it... We do definitely need smaller blocks, or at least some way to make finer details (without using the ugly sprite thingies). We just need a way to store the data. It seems to me that display blocks are doing fine storing extra data somewhere, so I don't see why we can't just put the microblock data there... The only problem is that I'm not sure if that system would scale well.

 

[DivineEvil]

The only possible advance in that regard would be single additional variable, that would allow to place certain blocks in a 'merged' state, which means that minimum two blocks, that have a variable as 1 would graphically merge with another such block to effectively produce a multi-grid block, i.e. a shape, that spans over several blocks, but otherwise would function as the initial block, and destroying or removing one of the merged blocks would reset the state of a surviving one. For example, solid block + wedge block = long wedge, etc. Many different shapes can be achieved if the system would consider only the edge-located vertexes of the two blocks to build a shape, while ignoring the vertexes located between them. Many issues may arise from that, such as collisions, texture warping, and can be just to complex from the coding perspective.

Other than that, no programming can solve a problem of enormous increasing the data value of each block and all forthcoming rendering, lag and interaction problems that would originate from it.

 

[Ithirahad]

The only possible advance in that regard would be single additional variable, that would allow to place certain blocks in a 'merged' state, which means that minimum two blocks, that have a variable as 1 would graphically merge with another such block to effectively produce a multi-grid block, i.e. a shape, that spans over several blocks, but otherwise would function as the initial block, and destroying or removing one of the merged blocks would reset the state of a surviving one. For example, solid block + wedge block = long wedge, etc. Many different shapes can be achieved if the system would consider only the edge-located vertexes of the two blocks to build a shape, while ignoring the vertexes located between them. Many issues may arise from that, such as collisions, texture warping, and can be just to complex from the coding perspective.

Other than that, no programming can solve a problem of enormous increasing the data value of each block and all forthcoming rendering, lag and interaction problems that would originate from it.

...But what if the standard block size remains as it is, but there's an additional list of microblock tiles, which includes each one's block coordinates and configuration, attached to the entity file? Sure, it creates a bit of bloat, but if it's going to mostly be used for things like furniture which don't comprise a major part of the ship it shouldn't cause too much trouble...

 

[Bench]

Thanks for your suggestion, unfortunately it's one that's been rejected before so sorry to be the bearer of bad news. You can check it out here on our Public Roadmap.