[VOXEL REMOVAL PREVIEW BUILD ROUND#4] System and Mechanism

[tsunamayo]

ROUND#4 - System and Mechanisms

Now systems and mechanism have been migrated to the new grid scaling feature. I see the light at the end of the tunnel, the only big feature missing now is a new tech for lights. Then a some cleanup and more bugfixes and I will release the build in experimental. It took a lot of time but there was a lot of changes besides the new grid tech...

Most construction blocks base size can now be increased. The grid a brick can lock onto will match its base size.

• Press the new T key to increase the grid scale, or SHIFT-T to decrease it.
• A UI indicator showing the current grid scale is added.

• some bricks have been removed.

  TO DO:

• Codex will show bricks that can be grid-resized.
• Some options to be added like grid preview size and vertical lock.
• The starter block will also be made grid-resizable.
• Lights
• custom color UI

Preview build to check the blueprint conversion process. Auto-save is desactivated, do not spend time building in this build. Please report any issue with your builds!

Issues:

• Voxel paint conversion to decal is not working for shape other than the cube. It was tricky and the result is messy and unoptimized - so you will have to do some touch up (but not in this build yet). -Docking save will be lost.

[tsunamayo]

Build is up! Thanks a lot guys, having many testers like you is extremely helpful to pull out some big change like this.

[Kaiser-Indrasil]

Then a some cleanup and more bugfixes and I will release the build in legacy.

@tsunamayo I would really advise against this. Legacy branch is the only one where the Hull Bricks collision boxes are not borked between child entities. Unless you're willing to fix them in this update series, please upload the new version to the Experimental Branch.

[tsunamayo]

@Kaiser-Indrasil sorry I meant Experimental, it would make no sense otherwise...

[Kaiser-Indrasil]

@tsunamayo Ah! Good stuff. Onto the testing then!

[CurioInventorium]

I can confirm that the issues I had with the glass wedge and the deleting of blocks are fixed. Still have the problem with the controls not being accessible when seated in the Slim Line Ship (attached in Round #3 update)

I did find that the turrets were no longer linked up properly when I spawned in the Triavrium Interstallar Mk2 ship (also attached in previous update)

A bit disappointed that hinges don't go down to 1/8 scale and that logic blocks/switches don't scale at all. Still looking forward to building things with this updated system though! Awesome work! 😃

[Kaiser-Indrasil]

In general, the mechanisms underwent the conversion process really smoothly. I will have to adjust the speed at which mechanisms move but that's about it. However, I have encountered a strange bug.

Bug 1: One of the logic panels on my Agni fighter. It's underneath the portside air intake. The panel is positioned on top of two mechanisms - a piston (1) and a hinge (2) - which are operated by an ABBA circuit. The panel opens normally but when I attempt to close it, only the hinge works. I've played around with timings but the problem persists. What fixes it, strangely, is clicking F on the Logic Gate I marked with a violet circle and exiting its settings window. That retracts the piston.

Pic 1

Bug 2: All my guns seem to have lost their links. Bug 3: You can attempt to link the logic blocks to barrels but the link won't be established (as is expected).

Bug 4: One of my landing legs got soft-locked. I removed all the blocks that might've been colliding with it, still doesn't move. It's the same BP as the Bug 1. Might be the same issue as the Bug 1, too.

Still on the list:

(old) Bug 5: Seems like a lot of stats have been changed since the last experimental patch. The ships still feel very sluggish compared to the Experimental branch and it's thanks to this stat conversion. Most notable changes are:

• 5 times smaller mass
• over 23 times smaller forward thrust
• over 25 times smaller agility thrust
• much bigger heat dissipation
• much more HP
• much weaker shield HP

Power management hasn't changed that much because despite the reactor nerf, all the systems use adequatly less power as well, so it almost balances out. It would be better if the figures were closer though.

Here's the new stats (again, same BP):

And here's the old stats:

(old) Bug 6: Some lights remain in perma RGB Rainbow mode (old) Bug 7: Emissive lights (like buttons, reactors, thrusters etc.) colour conversion rendered the bright ones too bright, the dark ones too dim, but both of them are too washed-out, except for the middle colour hue. These ones are fine. (old) Bug 8: Volumetric Sensor doesn't switch off

[Kaiser-Indrasil]

Bug 9: You can't attach addons onto the guns (both lasers and beams) at their highest size (4m). Also, the firing effect does not scale with the size of the gun.

Bug 10: The bigger the block, the more lag it makes when searching for a place to put it down:

Bug 11: The 1-to-4, 1-to-2, and 2-to-1 blocks don't offet blocks anymore:

Btw I absolutely love that we can go into such fine detailing like this now. Thank you, Tsuna! <3

[ProPeach]

Looks like weapon barrels still don't transfer properly, their hitbox is still there in old blueprints and their effect on the gun stats is still there, but they're invisible. I remember you mentioning that you'd like to redo the weapon addon system so I'm not sure if this is relevant now.

I'm unable to place anything on a handle when building a handheld weapon, seems like the grid doesn't line up

The larger reach for larger scaled bricks is brilliant and completely necessary, but the reach doesn't apply to deleting smaller bricks too. Here I have to move close enough to be on the 1m reach scale to delete a 1m sized brick, even though the placement ghost shows my reach should be far enough. https://user-images.githubusercontent.com/27857711/116448603-36321000-a851-11eb-8b39-aad8dad928ae.mp4

Do you still plan on having that grid increment toggle for placing scaled blocks? Atm they all abide by their own individual grid, meaning the player has to keep track of more grids even than before this big refactor. This could be a huge learning curve for new players which already have trouble getting used to stretch tech

Maybe we don't need another manual toggle, which would help declutter the hotkey list- Ideally, blocks of similar size should automatically snap to eachothers face no matter the offset. For example here when looking at a 16m cube holding a 16m cube, the placement ghost could snap to the existing shape

Then, when holding a shape on a different scale than the shape you're looking at, you could place it in 1m increments (for shapes above 1x scaling), for example here placing a 2m cube on a 16m cube. Placing shapes below 1x scaling is totally fine as is.

As a byproduct this would also solve things like placing 1/2 scale systems in the middle of a ship etc

This smart toggling switch should account for most, if not all building scenarios and save us all another hotkey to have to toggle every time

[ProPeach]

The hover pod likes to slide around when placing it https://user-images.githubusercontent.com/27857711/116452597-cd00cb80-a855-11eb-887e-ed814c8e0ab1.mp4

[Uncle-Ulty]

I've identified this bug on a 16x16 piston placement

https://user-images.githubusercontent.com/73253472/116457020-4938e600-a839-11eb-9aa1-7995ef9a640f.mp4

[ProPeach]

Seems to be a problem at all scales, sideways pistons place incorrectly

Also - If the piston base is not in frame, something goes wrong with the piston shaft 😄

https://user-images.githubusercontent.com/27857711/116458713-d93c5700-a85c-11eb-89b9-c1e3495a0e2c.mp4

[ProPeach]

Quick suggestion for later when QOL changes are the focus With all the different scales, keeping count of the block ratios can be a little tough unless you're super quick with your mental maths. Just a small addition to the scaling measure to show how many increments you've stretched would be super useful

[ProPeach]

On very large builds, the ringworld can appear behind in even if it is actually in front of it when player is far away https://user-images.githubusercontent.com/27857711/116463366-86fe3480-a862-11eb-9f92-0adcacc7aa35.mp4 Here's the blueprint I used to save you some time, but I'm not sure if bp saving and loading is working correctly yet Large Stick.zip

[Uncle-Ulty]

Seems to be a problem at all scales, sideways pistons place incorrectly

Also - If the piston base is not in frame, something goes wrong with the piston shaft 😄

Hrmmm.mp4

I was waiting for the "2001: A Space odyssey" theme song in this video...

[TIKIRobo]

material paints don't display properly

[tsunamayo]

Piston fixed. @ProPeach regarding the grid I think this would create some confusion, what if you want to place a large block on top of a smaller one but keeping it locked to the larger natural grid? Grid offset are an "advanced" key for builder that want something specific, no need to bother newcomer with that. I will add a vertical lock for building block though, that will be togglable in an upcoming building options. Like hull will get a lock, but seat wont. In your case you had a vertical offset because you didnt used a larger starter block at first, so the larger grid is offseted... (starter block cant rescale yet ;) For sure we will have a bit of exploring on the controls at first to get the grip on that new tech.

[tsunamayo]

I think I will make hoverpod only grid scalable... It will be more user friendly, you just wont be able to place 3x3x3 size but that doesnt seems too bad.

[TIKIRobo]

https://user-images.githubusercontent.com/56371294/116485754-d6cc0400-a840-11eb-8ee7-d6e02af4cc34.mp4

mirror mode seems to be broken on the largest blocks

[ProPeach]

@tsunamayo in the instance of placing a larger block on a smaller block, I was suggesting that the larger block move in increments of 1m so it can be properly placed on the smaller block. Larger blocks wouldn't really have a "natural" grid as they could be places on the 1m scale freely, apart from the first example I showed with the face snapping. It's the individual natural grids which I think will cause the most confusion, I see quite a few players confuses as to why they can't place block systems on top of bricks currently and this is a similar issue but larger. If offsetting worked like this, we wouldn't need scaleable starter blocks

I was just using that image as an example to show the offsets problems that could happen when building, I know the starter block was causing the original vertical misalignment. 👌

[tsunamayo]

humm, do you think the system of having block snapping to a grid is confusing? It is kindof the basis of the whole thing... Like then 1m block could be placed in 0.25m increment too? I think it adds more complexity than anything... I think I need a smarter grid visualization - but once you understand that things comply to a grid it is pretty logical. It should also clarify the system situation. Again I will want to put some additional grid option in that build menu for advanced builder (like being able to lock to a smaller grid too)

[tsunamayo]

@ProPeach also do you cant see any barrels at all? how does it looks in preview, and what if you place the barrel yourself? It is all fine on my side.

[Kaiser-Indrasil]

I agree with @ProPeach on this one - I've seen many people get confused when they couldn't place a big 1m block at smaller 0.25m increments. And this isn't an advanced feature. Most people complaining about it were literally new players asking for a feature that they thought would be a more intuitive approach.

Avorion has something like this: when holding a ghost block, you hold Ctrl key to temporarily change the block's size to the one you want to place it upon. And you hold the Alt key to center your ghost block to the face of the block you want to place it upon.

They've got stretchable and scalable blocks as well, with dynamically adjustable grid not confined to the specific block scale. And it's damn intuitive to build there.

[ProPeach]

Block snapping to a grid isn't a hard concept to grasp no, it's just that with each scales block having their own grid, keeping track of lots of different grids would be the point of confusion, especially with the vastly different sizes of them. So I think the experience can be made much more intuitive with some additional offsetting tools Anways, it sounds like you've got some more things in the pipeline later so we'll see how that works out, hopefully my concerns are unfounded!

Regarding the barrels, I can place new barrels on new guns totally fine, it's just that loading in some blueprints from older versions of the game creates those invisible barrels.

Here are some bps that show the issue https://steamcommunity.com/sharedfiles/filedetails/?id=2186636546 https://steamcommunity.com/sharedfiles/filedetails/?id=2350203719

Weirdly, it isn't an issue on some bps, like this one https://steamcommunity.com/sharedfiles/filedetails/?id=2312618500

[tsunamayo]

The keeping track of different grid part that confuse me. Grid cascade is not arbitrary, you start at the higher grid, then each sub-grid splits the largest one in two. @Kaiser-Indrasil I am sure Avorion system must be working well, but I didnt understood the placement, and it involve two keybind. I dont see how it could be more user friendly for beginners but maybe I am missing something. Now there is 32m blocks, and the smallest grid is 0.125cm wide. Surely you are not asking for the 32m to lock to the smallest one? That would be anarchy, impossible to build a fitting ship.

[ProPeach]

Starting with the larger grid and working down is logical, but doing the opposite is more where the problem happens. For example you start working at 16m scale, place some 2m blocks down, then want to continue placing 16m blocks on the 2m blocks. You might be able to place one 16m block, but it will be strangely offset in terms of the 16m grid so that won't play nice with the next 16m block you place next to it like in the first image I posted earlier.

In a weird way, the solution I proposed for that image reminds me of the old brick studs. On that system wherever a brick is on the grid, no matter how weirdly offset it was, you knew that if you place a brick on that brick's stud it would snap perfectly to it, which was brilliant. The toggle I was suggesting would intelligently swap between this behaviour and moving the ghost in fixed increments depending on the scale of the brick in your hand, which would remove the need for a manual toggle.

The increment would change based on the scale of the block in your hand so avoid that anarchy.

For sizes 2x to 32x, the increment could be 1m

For sizes 1/4x to 1x, the increment could be 0.25m

For the 1/8x size, the increment could be 0.125m. No smart toggle is nessesary as the face size is the same as the increment size

[tsunamayo]

I see, indeed I think the problem we saw is because we started to put higher scale block onto the base 1m. Of course the natural way to build is to start with the bigger frame and then move on to details. I think I need to see more case where you need / want to build at an offset. When building a hull frame for example I expect people to want to conform to a grid so things aligns themselves. I see it as a security, you cant misalign stuff. But for details, or placing systems you might want smaller offset. I think we need more mileage before I make further changes. The old stud tech and the stud-offset tech was a mess...

[ExodistSKY1]

Was the new "Novoxel" branch removed from the Betas menu?

[Kaiser-Indrasil]

@ExodistSKY1 No, you need to type in the password "atlastnomorevoxel" again, if the branch disappeared from the list.

[ExodistSKY1]

The "Side Rounded" block does not stretch

[Kaiser-Indrasil]

The Trap Door doesn't retain the colour after the conversion. Moreso, when I try to paint it, it paints the door instead of the door frame.

[tsunamayo]

The Trap Door doesn't retain the colour after the conversion. Moreso, when I try to paint it, it paints the door instead of the door frame.

Yes it is the case for seat too, I removed the secondary paint feature for technical and user friendliness reason. Paint is gonna paint the door, but you will be able to color the frame with a different material.

[pinesh]

Will we get the bevel height slabs back? There seems to be no more slab to work with the bevel blocks (at the bevels smallest size)

[Kaiser-Indrasil]

@tsunamayo Seeing as the frame was the element that's always been recolorable, would you consider swapping them? So that we could recolour the frame and change the material of the door?

[tsunamayo]

@Kaiser-Indrasil You are sure about this? It makes much more sense to have a paintable door and a material frame. Surely you need a paintable door.

[Kaiser-Indrasil]

@tsunamayo At the first glance, the door takes up much more space than the frame, so surely it should be repaintable.

The problem with this approach, however, is that you have to consider the surrounding surface that the frame would be fitted into by players as well.

You don't attach anything to the door, so it doesn't matter if it doesn't match up with its surroundings.

However, given that the frame would end up sitting in a multitude of different surfaces, and make immediate contact with them, it's logical that it should be compatible with as many colours as possible.

That's why I think the frame should be recolorable.

[TIKIRobo]

why not being able to repaint both? nobody wants a steel frame but also none wants a steel door