Forge Welding

[Edymnion]

That isn't how it works. Most of the 3 bytes is used for orientation, activation and HP. A fourth byte would multiply the available IDs by 256.

Yes, thats what I said.

Clearly we aren't at 16+ million blocks because a lot of that space is being used for rotation facets (up, down, left, right, front, back), on/off status, etc.

The point being however that an extra byte of space is not going to be using ANY of that extra space for such things, as it is already there in the base 3 bytes. All of the extra capacity could conceivably go into nothing but new block types.

So while being a lot, it's not unlimited.

You're picking nits.

Clearly "unlimited" is impossible, because otherwise you would need infinite amounts of ram and infinite amounts of hard drive space to hold it all. What I was talking about, and even what I said:

That is effectively unlimited.

Effectively unlimited means that we end up with far more potential block IDs than we will conceivably be able to use.

If we currently have a limit of 2048 total blocks, the extra byte would indeed add 256 times more for 524,288 blocks.

That is far more than we could ever conceivably use, hence we have effectively an unlimited number of blocks to play with, hence the entire "We have limited IDs!" is no longer valid.

 

[Malacodor]

Clearly "unlimited" is impossible, because otherwise you would need infinite amounts of ram and infinite amounts of hard drive space to hold it all.

Which is what I wanted to make clear.

That is far more than we could ever conceivably use, hence we have effectively an unlimited number of blocks to play with, hence the entire "We have limited IDs!" is no longer valid.

There were suggestions made, which would need more than 500k IDs.

 

[Edymnion]

There were suggestions made, which would need more than 500k IDs.

Like what? Given that orientation, activation status, etc would not factor into any of them.

Given cube, wedge, hepta, tetra, and corner, plus 3 levels of slab, thats 8 blocks max per new block type. 525k/8 is still 65k new block types in every possible shape.

Not trying to sound snotty or anything, I'm genuinely curious what someone has proposed that would require more than half a million new block types?

 

[Malacodor]

Like what? Given that orientation, activation status, etc would not factor into any of them.

Given cube, wedge, hepta, tetra, and corner, plus 3 levels of slab, thats 8 blocks max per new block type. 525k/8 is still 65k new block types in every possible shape.

Not trying to sound snotty or anything, I'm genuinely curious what someone has proposed that would require more than half a million new block types?

32 bit colors, multiple blocks per block space, microblocks, plus whatever crazy ideas people will come up with in the future. This community is far too creative to promise them unlimited IDs.

 

[Lone_Puppy]

I'd love to have more blocks to choose from, but I think the balancing act is between the server and client side at the moment.

Naturally the difference between 10 blocks or 10 billion blocks is the ability to handle and process them. The more you add the bigger the blueprints and bandwidth requirement becomes and the more complex calculations become like collision, damage, mass, rotation, thrust not to mention video processing and god knows what else.

I'm guessing that Schine are playing it conservative for now to keep it manageable and prevent crippling the game in it's current state.

 

[Lukwan]

Well a good way to be able to do the fusing thing would be to add in kind of like a "Fuse" block, which, when you dock a ship, and then activate it, then the ships would both be fused together at the docks. so basically if you activate the fuser while in the mothership, it will delete the core of the docked ship, and then you just delete the rails.

I'm gonna want to have a big, hinged emergency cover on that button, with hazard stripes and maybe a key-lock. I figure once entities get fused, or welded or whatever...it's permanent.

 

[Malacodor]

I'm gonna want to have a big, hinged emergency cover on that button, with hazard stripes and maybe a key-lock. I figure once entities get fused, or welded or whatever...it's permanent.

Or maybe a popup with a warning.

 

[Nickizzy]

Brief low level computer refresher for anyone that doesn't know (keeping it simple to avoid unsigned vs signed and various other things out of the conversation).

A byte is 8 bits. A bit is a single binary 1 or 0. When you count in binary, 1 - 2 - 3 becomes 01 - 10 - 11. 8 bits means eight slots, for a maximum of 11111111, which is 255.

2 bytes can store up to 65,535.

3 bytes can store up to 16,777,215.

This is where we are now. Clearly we aren't at 16+ million blocks because a lot of that space is being used for rotation facets (up, down, left, right, front, back), on/off status, etc. We currently have about 700 blocks in the game, with each time we rotate a block in any direction actually being where we swap in a new block (so a left facing grey hull wedge and a right facing grey hull wedge are two different blocks, the game just switches them out on us whenever we rotate them).

4 bytes stores up to 4,294,967,295.

So adding one extra byte to the block file format, assuming the rest of the space requirements for the format remain the same opens up well over 4 billion new blocks.

That is effectively unlimited.

I'm Gonna try and work some numbers here. This issue is kinda solved, we have tons of space for block IDs but the more the laggier. This is just an idea of how many new blocks we could add(not counting when the game breaks from the lag).

4,294,967,295
That's the big magical number we have to work with. Now let's see what you get from it.
4,294,967,295 Unrotateable blocks. Blocks you can't rotate only need one bit each(?). ~4.3 billion
178,956,970 UN-rotatable slabable blocks. Like armor blocks. ~179 million
178,956,970 rotatable unlogicable blocks. Like armor wedges and all other unlogicable blocks. ~179 million(these are actually the same because 6 different bottoms, and 4 different slab stages or spin orientations).
89,478,485 logicable rotatable blocks. Doors, logic parts. ~89.48 million.
(IDK how computers and rail rotators and displays and cores fit into the mix, they all have alternate possible information.
As you can see, these are all really large amounts, so we should be worried more about lag than block IDs.

 

[Malacodor]

I'm Gonna try and work some numbers here. This issue is kinda solved, we have tons of space for block IDs but the more the laggier. This is just an idea of how many new blocks we could add(not counting when the game breaks from the lag).

4,294,967,295
That's the big magical number we have to work with. Now let's see what you get from it.
4,294,967,295 Unrotateable blocks. Blocks you can't rotate only need one bit each(?). ~4.3 billion
178,956,970 UN-rotatable slabable blocks. Like armor blocks. ~179 million
178,956,970 rotatable unlogicable blocks. Like armor wedges and all other unlogicable blocks. ~179 million(these are actually the same because 6 different bottoms, and 4 different slab stages or spin orientations).
89,478,485 logicable rotatable blocks. Doors, logic parts. ~89.48 million.
(IDK how computers and rail rotators and displays and cores fit into the mix, they all have alternate possible information.
As you can see, these are all really large amounts, so we should be worried more about lag than block IDs.

That's a naive miscalculation, you missed out HP.

 

[Nickizzy]

That's a naive miscalculation, you missed out HP.

HP? Like how much health it has? Ooooooh yea that might be important.

 

[Edymnion]

Well since we're getting into it now:
Blueprint File Formats - StarMade Wiki

That shows us the exact current bit breakdown of the block file format. Out of 24 bits, we currently use 11 bits for block IDs, and 3-5 bits for orientation based on if it has an activation status or not.

11 bits can store up to 2,048 (from 0 to 2,047) IDs.

If we devoted an entire byte of space to nothing but new IDs, we'd jump from 11 bits to 19 bits, which is the previously mentioned 524k blocks.

Although its reasonable to assume with that much bit space that we'd lose a bit of it (no pun intended) to making the format more uniform so that all blocks can have full orientation and activation statuses.

That would be 15 bits for orientation/activation/hp, leaving 17 bits for block IDs for a mere 131,071 new block types.

Still effectively unlimited since we're currently running on less than 1k.

 

[Madman198237]

Edymnion, don't forget that certain blocks (Full blocks, light bars, other symmetrical blocks, etc.) do not need 24 rotation states. You save bits for those blocks, and could then possibly use them for more IDs (I don't know how exactly this works, but I'll try anyway). As in, while a block with full rotation, logic capability, HP, etc. can only have IDs, say, from 0-2047, blocks without one or more characteristic, say without logic-ability, use the extra bits to get massively higher IDs. As in, all cubes with no rotations and no logic get IDs in the highest level.

Because I'm not so good with words, let me explain it this way (SIMPLIFICATION IMCOMING. Yes, I know these are incorrect, but I was too lazy to do all the multiplication)

Let's say level 1 is using 1 bit for ID, you can assign IDs from 1-50 (No you can't, and I know that, but this is simplified, as I noted earlier). This is only for blocks with logic and full rotations or something, and so have limited ID-bits.

But now let's say you have some inactive full cubes (No logic or rotation or anything). They can use 4 bits for IDs. Let's say that since they can use 4 bits, they can have from 0-200 IDs. So, for this category, you assign only IDs above the limit of ID #49 from level 1. So the very first full block gets an ID of 50, and so on. Logic blocks can't use these ID numbers, yet the full cubes don't need the extra bits. This makes your ID scheme a lot more compact...potentially.


Obviously, there are more that just the two "levels" based on number of bits to ID. But it's a hyper-simplified example. So, to all the more basic-computing-level knowledgeable people out there, would this work?

 

[Edymnion]

Edymnion, don't forget that certain blocks (Full blocks, light bars, other symmetrical blocks, etc.) do not need 24 rotation states.

Not as of right now they don't, no.

But there is a lot to be said for standard format and layout for everything to follow. That way when you're looking at the low level stuff you don't need to cross reference a list of what kind of block uses which format. It was a big deal when we were working with 3 bytes because of the limited space, corners were obviously cut (like we can't turn light bars on and off because they needed full rotational). If we had the 4 byte, we're not so completely crunched for space that we can afford to "waste" a bit or two on some blocks to make sure everything lines up and is easy to use for everything else.

And really, a 100k blocks is essentially the same as 500k blocks, more than we can really use under reasonable circumstances (and the unreasonable ones are going to require more than 4 bytes anyway, so don't really factor into it either).

 

[Jojomo]

I can imagine many uses for this option but if I tell them to you your imagination will get no exercise. :p

So can I - it wasn't for no reason I posted an identical suggestion shortly before this one was posted (you posted a reply in it).

I specifically wanted to know why templates weren't a solution for Edymnion and his particular situation.
[doublepost=1476066741,1476066128][/doublepost]

Edymnion, don't forget that certain blocks (Full blocks, light bars, other symmetrical blocks, etc.) do not need 24 rotation states. You save bits for those blocks, and could then possibly use them for more IDs (I don't know how exactly this works, but I'll try anyway).

This won't be done unfortunately.

Different blocks can have different sized fields, but you're going to want to check the block ID to find out what those field sizes are (e.g. IDs > 1000 have 5 bit rotation, IDs < 200 have 3 bit rotations, the rest hvae 4 bit rotations, etc). Until you know the ID, you know nothing about the other field sizes.

So any field can have variable sizes, except IDs.

An alternative would be to use a few bits to denote a block data type (i.e. the ID field size), but we're already so short of bits in Starmade that this isn't a practical solution. So IDs need to stay a constant size.

 

[Edymnion]

So can I - it wasn't for no reason I posted an identical suggestion shortly before this one was posted (you posted a reply in it).

I specifically wanted to know why templates weren't a solution for Edymnion and his particular situation.
[doublepost=1476066741,1476066128][/doublepost]

Because as I've stated before, templates are VERY limited. Namely, they are limited by the advanced build mode area settings, which are 10x10x10 by default (and which many servers are unwilling to raise much beyond 20-30x because of the potential for a misclick to crash the server).

You can't make a template of a 100m long structure if the server limit is 10m, nor can you load in a 100m long template on a server that has such a small build area.

This would allow you to have your modules be any size you want, without restriction from the build area, and without the potential server crashing side effects of accidentally dropping a 100x100x100 solid cube of something all at once.

 

[Jojomo]

Because as I've stated before, templates are VERY limited. Namely, they are limited by the advanced build mode area settings, which are 10x10x10 by default (and which many servers are unwilling to raise much beyond 20-30x because of the potential for a misclick to crash the server).

You can't make a template of a 100m long structure if the server limit is 10m, nor can you load in a 100m long template on a server that has such a small build area.

This would allow you to have your modules be any size you want, without restriction from the build area, and without the potential server crashing side effects of accidentally dropping a 100x100x100 solid cube of something all at once.

Yes, I see - building on a server does make templates considerably less useful.

No need to sell me on your suggestion: like I've already said, I made an identical suggestion shortly before you posted this one.

 

[Edymnion]

For those who were asking about "Why not just use templates?", I'm working on my carrier now and really wishing I had this. Took pictures to show why.



The center there with the red is where I'm starting the interior space on my carrier. The boxed in spots to either side are where I have lined up the number of fighters I want in each main bay into racks. These box racks are almost 300m long.



Each one of them is currently docked to some free floating rails to either side of the interior.

My objective here is to be able to move them around to first find the positioning I like for them best, and then to be able to use them as sizing blocks to build the rest of the ship out around them so I can make sure everything lines up exactly where I want it to.

That way I don't have to worry about building half the frame for the ship and realizing that I've gotten something a half dozen blocks too small and I have to scrap a ton of work to rebuild later (which has happened to me on more than one occassion).

It is MUCH easier (on both myself and the server) to simply undock those racks, put down a new rail, and redock them in order to move things around until I get them where I want them than it is to try and keep that entire thing in a template and trying to mirror paste it over and over again.

 

[Edymnion]

Working on making thrusters and engine covers, would be really nice if I could just make long thruster engine rods and weld them in place with the engine porn pre-attached. -_-