[VOXEL REMOVAL PREVIEW BUILD ROUND#8] More Bugfixes + system finer grid.

[tsunamayo]

ROUND#8 - More Bugfixes + system finer grid.

More bugfixes! This build also adds a finer grid for systems.

TO DO before the release:

• ship HP and new destroy mechanism.

Some more bugfixes:

• Collisions on pistons fixed
• Collisions on hinge fixed.
• Washed out colors for glowing bricks fixed.
• Gravity Unit fixed.
• MMB menu paint color fixed
• paint VFX fixed.
• Decals icon fixed
• Decals not showing in ship preview fixed.
• piston issue fixed.
• Invisible gatling barrel issue fixed

[tsunamayo]

Build is up. What do you think of the finer grid for the system? I think it is a bit too finicky... It bugs me to remove some fluidity for something we wont need 95% of the time... Thanks again for all the bug uncovered - cheers

[CurioInventorium]

Good work so far! Unfortunately some issues persist.. Cylinder lights are still not being placed correctly on the start base (and most likely on any spawned blueprints).

Items still don't appear on item stands in the start base

Hover vehicles don't take off properly. The right-hand hover vehicle when started up does the same, but as soon as you raise the landing struts it clips through the building. It seems like the hover physics (?) isn't interacting with the building.

It seems a bit odd that logic blocks are 25kg each.

Switches don't align properly when a smaller grid size than they are is used. In this case 1/8 grid had been used while placing scaleable blocks. Which begs the question, why aren't switches and logic blocks scalable. A larger issue is that the block/grid scale isn't shown when a non-scalable block is selected, meaning potential confusion as to why a block suddenly doesn't match the grid.

Following from previous image, here's the switch aligning when the grid is set 1/4. But that could only be done by first selecting a scaleable block and changing the scale. If I change the scale to 1/2, then the switch doesn't align on the grid again.

[CurioInventorium]

Additional to my previous post; It looks like the non-scaleable blocks centre themselves on the grid square they're over.

[tsunamayo]

@CurioInventorium Hi, thanks for your feedback. I am not sure to understand the last one, I keep you posted. Whatever grid setting your previous brick had should in no matter impact the placement of other non-scalable block. Switch button ect dont are not scalable because it do not make sense, dont you think?

[CurioInventorium]

@tsunamayo Just have an experiment placing a scaleable block down at 1/8 grid scale and then changing to a non-scaleable block without changing the grid scale to 1/4. You'll most likely find that the non-scaleable block (in my test case, a switch) will align itself to the centre of placement points of the 1/8 grid, instead of the 1/4 grid that they are made too.

Switches and other logic blocks being scaleable down to 1/8 and maybe up to 1 meter makes perfect sense. It would allow creation of switchboards, or allow emphasis of the importance of the switch. Like having a big red self-destruct button or a control panel full on smaller configuration switches. Same goes for rotators and hinges. It seems odd to create a system of scaling, but then only limit it to a range of blocks. Surely it makes coding all this more of a nightmare to keep it all separate.

[BigBadKangaroo]

I would love to see smaller logic Blocks. Would make a good use for details. But to be honest, they really don't need to be scaleable!

[tsunamayo]

So yes it is a regression, I am pushing a new build asap. I dont really see the point of having 1m switch! Like they are supposed to be used by the players, so it feel weird! Everything that is player centered will have a fixed size. That being said I will make the holo projector scalable.

[tsunamayo]

@CurioInventorium the new build is up - thanks for being quick on the ball!

[CurioInventorium]

Switch positions itself correctly, but blocks aren't happy now.

[ExodistSKY1]

-Stickers (Markings and Details) are invisible when placed and on spawned in ships

[Kaiser-Indrasil]

Yeah, the grid's entirely borked: Just pretend the 3 silver blocks to the bottom left are the main original grid, and the blocks should align to the lateral faces like this:

[Kaiser-Indrasil]

Yeah, this is hardly an improvement. Sure, we can offset vertically now but the big thing about the brick system from the voxel branches of the game was that if you wanted to place a brick on a side face of an offset brick, it would share that vertical offset.

Meanwhile, on the preview branch it just doesn't work anymore, doesn't align laterally, and is very frustrating to work with. I need it to align to the corners marked by the arrows:

[RockefellerDoctor]

I've noticed that the new voxel-less rebuild is a lot more taxing on GPU that the old build.

[tsunamayo]

@RockefellerDoctor could you give me a blueprint example? Does it have a lot of lights?

[tsunamayo]

@Kaiser-Indrasil the finer grid change is only for system and weapons, so it must be a bug, let me check.

[ExodistSKY1]

Can we get the switches, buttons, logic, etc. to also be placed on the 1/8th scale. It does not make sense for them to be larger than 1/4th I will agree with that, but it makes much more sense for them to be scaled down as well. It will and could look far better than only keeping them on the 1/4th scale

[ExodistSKY1]

To add to the "offsetting" conversation. I do not really do too much fancy work, but the reason why I would like to be able to adjust the larger blocks to the smaller blocks is to make my builds more efficient for the game.

This one was made with the 1m blocks

I would like to make it more efficient by placing larger blocks in the the same place as the 1m blocks. this cannot be done with the current system. So having an offsetting system will help me to reduce the strain on the game

my larger build I started with the 32m blocks but I switch consistently between the 32m and 16m blocks for the main portion of the hull... I do not build my entire ship shape at first I move section to section and when i loose inspiration I will move to other locations. as you can tell in this screenshot even trying to place the 32m blocks in place of the 16m blocks is tiresome and tedious and only ever works half the time with other methods.

[tsunamayo]

@Kaiser-Indrasil I am very confused, is it a new regression in this particular build? I cant reproduce the issue. Or is it another feedback on the grid placement debate (I think I got the message)? cheers

[tsunamayo]

@ExodistSKY1 okay regarding switches I definitely dont want to overuse the grid-scaling mechanism. It is not making sense - it have to be one size. And I dont want to break existing builds. Also honestly 1/8 is too small and feel finicky to work with.

[Kaiser-Indrasil]

@tsunamayo Oops, I thought it was for hull blocks as well. Sorry for the confusion

[Kaiser-Indrasil]

Okay, this is not what we were ultimately hoping for, but it's a step in the right direction. The reason why we're not quite there yet is:

1. This needs to extend over to the other scaleable blocks, especially the hull blocks.
2. We need to be able to use other grid gradations than 1/4th of the block's size.

Just like Exodist said, I don't build my ships in an orderly manner. I build them chaotically, working on one section and moving onto the next when I lose inspiration. The key to this approach is that I need to be able to place blocks in whatever order I want, without any arbitrary pipeline. Without the game forcing me to place the biggest blocks first. Because sometimes - actually most of the time - I come up with a cool section for the ship, a cool shape, and then build around it. The current system featuring 9 different grid sizes that I would have to keep track of without being able to change between them, would be a massive hindrance and force me to adapt a different ship building pipeline.

I would probably end up using pistons to offset the bigger stuff anyway lol.

My idea for the solution to this problem would be to do the following:

• Have the button "G" toggle between different grid sizes
• Max grid size cannot exceed a given block size, so for 1m blocks grid list would contain: 1/16m, 1/8m, 1/4m, 1/2m, and 1m
• Switching between Block size doesn't change the Grid size, unless the Block size is smaller than the Grid size. If so, the game automatically changes the Grid size to the picked Block Size.
• OR Have the Grid size revert back to the Block size you switch to. Doesn't make much difference to me. I just need to be able to change Grid size separately from the Block size.

There. No tricky align-block-to-a-certain-corner-of-the-face-of-the-block-the-player-is-facing shenanigans. No local grids. Just separate grid size, separate block size. Easy as.

Plus, that wouldn't really disrupt your personal way of building ships. You wouldn't have to change both block sizes and grid sizes all the time. You would just stick to the biggest grid/block size you need and only switch when you want to build finer details.

[Uncle-Ulty]

On the last round I wrote this suggestion:

"-About the block's scaling and grid, wouldn't be easier to be able to choose which grid you wanna use? For instance, "T" for size and "Y" to select the grid."

The best way to deal with several sizes is to have a way to lock/unlock a certain grid. This grid gonna be created based on the first start block. This basic "master grid" will rule the entire build the same way it works on the current builds.

On current builds, the 1m block grid is aligned based on the first start block. We can maintain that, but make the bigger scale grid align based on 3 start block surfaces (This requires some aesthetic redesign of the start block to indicate those surfaces, and maybe a special HUD to show where is the 'master grid")

[Kaiser-Indrasil]

@Uncle-Ulty The Master Grid approach sounds a bit too arbitrary and difficult to grasp. It would be better if we were able to change the Grid Size independently of the Block Size. Everything else could stay the same.

[Uncle-Ulty]

We already use the master grid approach with 0,25m and 1m blocks, and it works, e.g. workshop. The idea is to keep the strategy and add a command to change (lock/unlock) the desired grid for more freedom.

[Uncle-Ulty]

when I say the "master grid" I mean all the grids (1/8,1/4, 1/2 ... 16, 32) gonna be created at the same time based on the start block. Those grid/grids gonna form the master grid (all the grids), and gonna rule over the build. But, we can add an option to select which grid we wanna use. This removes local arbitrary grid problem and creates a safe way to guarantee alignment into a 1km ~100km build.

[Kaiser-Indrasil]

Okay, so I understand your approach like this: We keep the Block Size=Grid Size, unless we hit a key to unlock the Grid Size. But then, what Grid Size do we unlock it to? 0.25m? 0.125m? 0.0625 (1/16)m? You would need to be able to choose what Grid Size you wanted to switch to, so you don't need to have a surgeon's steady arm to place a 32m block at 1/8m grid. That's why I think the solution I came up with would be more practical. Unless I misunderstood something?

[tsunamayo]

yeah @Uncle-Ulty this is exactly my approach, the master grid is defined by the starter block. Now you can scale the starter block. This is why I proposed to have the starter block define a maximum grid, ie your starter block is 2m, you can place your 4m+ block onto the 2m grid. I think it make sense, as you never ask for a 4m grid at the start. @Kaiser-Indrasil mate I never said I solved the grid issue in that build, I just said I added finer grid to the systems / weapons... Honestly I dont like your solution as newcomers would have to use a lot more keys.

I have still a few bullet under my sleeve:

• Grid override by placing a new starter block onto the entity (why not)
• Key / UI for finer grid control (it is facultative, only for expert builder),
• Toggle for global grid / local grid <-- I think that would my preferred choice. Still facultative, I can give it inside the UI and give a keybind. In global grid there would not be any vertical offset for hull blocks.

I still really dont get how you can be so allergic to having a global grid, finding it arbitrary ect. How do you build at an offset in Minecraft or in Space Engineers ;)? It is kinda a natural way of doing, that's how hull block wored before... A lot of my confusion came from all your example with large blocks, when we never had offset talk / issues with block before. This is why I failed to see this at being a big deal. The issue is the new system cant replicate what we had with bricks, where apparently people where using offsets and slab a lot more than what I thought.

[Uncle-Ulty]

@Kaiser-Indrasil , when I say lock/unlock is to choose a different grid (different grid scale) to use, based on the global/master grid (all the grids).

for instance: You want to place a 4x4x4 Gun, but the 4x4x4m grid doesn't align too well with your exterior hull, so you can reduce de grid from 4 to 2 or lower, to have finer control (when I say change grid, is to change between (1/8,1/4...8,16,32).

or, a real example, my starwatch competitor, I couldn't place more shield inside the turbines due to the 1m grid. If it was possible to select a finer grid, I could place more shields and warp drives. This is very good in curvy shapes.

@tsunamayo I like these ideas, but to set the limit of the grid in the beginning? I don't like it cuz players can change their minds in the middle of the building (e.g. me). In my opinion, the best approach is to create all the global grids based on the start block.

-Grid override? idk... it can work, but I'd rather have a way to get back to the original grid (a home point grid).

-finer grid control would be something good, or as I said, select a different grid (I mean, a different scale grid). This is good! tbh, it can be useful in the opposite way, you can use a larger grid, so you can place some object at the same intervals.

for instance: you make a beautiful pillar to your Parthenon replica, but you want to copy-paste on a specific interval. well, if this interval is a grid scale multiple, it can help you to place and paste them.

[ExodistSKY1]

If i can adjust any blocks larger than 1m on the meter grid, and any blocks smaller than a meter on the meter grid, I think that could suffice

[ExodistSKY1]

@ExodistSKY1 okay regarding switches I definitely dont want to overuse the grid-scaling mechanism. It is not making sense - it have to be one size. And I dont want to break existing builds. Also honestly 1/8 is too small and feel finicky to work with.

I would have to disagree about the switches, buttons, logic, monitors etc overusing the grid scaling, most builders from what I have heard and seen are only using the 1/8th blocks for fine details in smaller locations nothing outlandish.

I am not saying turn them into 1/8th scale, I am suggesting that they also can be used on the 1/8th scale to include keeping the original 1/4th scale. this would make the space needed for logic drastically reduced if the player decides they wanted a smaller ship, it would not take as much valuable real-estate.

[Kaiser-Indrasil]

@Kaiser-Indrasil mate I never said I solved the grid issue in that build, I just said I added finer grid to the systems / weapons...

Yeah, that's my B, I misread that one 😅

Honestly I dont like your solution as newcomers would have to use a lot more keys.

They wouldn't have to if they didn't want to. In my solution, every time you switched the Block Size, the Grid Size would revert back to it, staying the same as the Block Size. You would just have to switch the Grid Size manually with the G key if you needed to place a big block at a finer increment. Best of both worlds.

I have still a few bullet under my sleeve:

• Grid override by placing a new starter block onto the entity (why not)

Yeah, but that means I would have to place a Starter Block every time I wanted to place a block at an offset that's misaligned with the current grid. I think my approach is more elegant.

• Key / UI for finer grid control (it is facultative, only for expert builder),

G, G, G! If you wanted to stick to the original Grid without offsets, you wouldn't ever need to use it! That's the beauty of it!

• Toggle for global grid / local grid <-- I think that would my preferred choice. Still facultative, I can give it inside the UI and give a keybind. In global grid there would not be any vertical offset for hull blocks

But I want vertical offset too... For every block...

I still really dont get how you can be so allergic to having a global grid, finding it arbitrary ect.

Well, back on the voxel branches, I've never used blocks because I hate that I couldn't offset them on the Brick Grid. Not only the system blocks, but hull blocks, too. I would've saved hundreds of bricks if not for the fact that I couldn't offset blocks.

How do you build at an offset in Minecraft or in Space Engineers ;)? It is kinda a natural way of doing, that's how hull block worked before...

Ever since I discovered offsettable bricks in Starship Evo, the building system in SE become obsolete and primitive to me. I loved being able to offset bricks and make any shape I want, in any order I want. It really boosted my creativity. In SE I always found myself blueballed by so many shortcomings of the building system.

A lot of my confusion came from all your example with large blocks, when we never had offset talk / issues with block before. This is why I failed to see this at being a big deal. The issue is the new system cant replicate what we had with bricks, where apparently people where using offsets and slab a lot more than what I thought.

Exactly. I've never brought that issue up because instead of complaining about blocks not being offsettable and not being able to move them around the Brick Grid, I just used bricks exclusively instead. I guess I should've been more vocal about it from the start

[Kaiser-Indrasil]

okay regarding switches I definitely dont want to overuse the grid-scaling mechanism. It is not making sense - it have to be one size. And I dont want to break existing builds. Also honestly 1/8 is too small and feel finicky to work with.

The argument about not wanting to break existing builds is very valid but nevertheless, I can't help but notice how oversized the switches are.

Go ahead and measure a light switch in your home with a tape. I bet it won't be bigger than a few CM.

Now, how big are the switches in the game? 25cm, with the moveable part that's about 3/4ths of that? Make it around 18cm. That's 4-6 times as long as a real-life switch!

How big is the button, then? That's right, the size of an average pancake. Even the buttons on the old arcades are not nearly as enormous.

And the switches in aeroplanes' cockpits? They are miniscule! 1-3 cm on average. And, densely-packed, too.

Now, asking for that level of miniaturisation would be ludicrous and it would be really hard to hit these switches anyway. Aside from the fact that the scale tech doesn't go that small.

But that doesn't change the fact that in current state of the game, the logic blocks as a whole are, pardon the pun, flippin' ginormous.

1/8m, which is 12.5cm, would be a perfect size compromise between visibility and usability.

I'm aware that it would brake the existing builds quite a bit, and I don't want it too. However, maybe you could integrate them into the scale tech, but only on 2 scales, the 1/8m and the existing 1/4m?

[Kaiser-Indrasil]

You must understand that many people's building workflows are very different from yours. The building process should feel organic and conform to each individual player's building style. It should be forgiving and let them correct errors quickly and efficiently. It should allow them to change their mind on the fly, so they can tweak their design without being punished for not doing it a certain way. It should let us build in whatever order we want. That's what made the brick building so amazing

[tsunamayo]

yeah but it should be easy to pick-up. This is not blender. I need to find solutions that fits all styles, yours is quite extreme, again more akin to a total freedom 3d software which cant be my focus. But I heard your opinion and finally understood the issue, no need to drag this further and shoot on the ambulance (not sure we say that in the english tongue)

[ExodistSKY1]

I understand the argument for building from big to small. It makes perfect sense in a structured way. But I also understand building on numerous different grids for example working in-between 32, 16, and 8m to get the exact shape I am envisioning. This is what makes this game, this building system and the stretch tech so desirable, from the novice to the expert its simple and fun. We have the creative freedom to choose how we want to go about making our ships, hover craft, Hopefully mechs soon!, and buildings and stations.

I see Indrasils builds as just placing blocks where they can fit, no different with legos, and that is something from childhood to as old as you can get! simple to start and you can only improve!

[ExodistSKY1]

back on to the Bug topic:

The lighting seems to be slightly off on larger builds

attached is the BP: Invasion Fleet Carrier dont worry Tsuna it will mainly be hangars.zip

[AlienXtream]

@tsunamayo i see you have made several comments about why you dont want X or Y scalable and they are good reasons. if i may suggest a "compromise" of sorts however. i assume that, bar some niche cases, its more a less a boolean value inherited from your base placeable object scripts for what blocks can and cant be scaled (obviously there would be case by case issues but for most things)? if you keep the vanilla (i.e your) rules for scaling as you envision them but, when you eventually make stuff for modding, expose that boolean to be modded (would probably need to be so anyway for custom blocks to be able to be scaled). that way you can keep the vanilla rules for the 99% of cases but the 1% of people that need/want it can still use it (eventually). alternatively you might consider having the switch and logic inputs have a half size variation intended for use on mechs where space is a premium. at the end of the day its your game and you have to set the rules. while some features like copy-paste were ultimately good things keeping to your rules where there is little to no logical argument against it is a good idea. afterall, if we got every little tiny detail part and scale option we wanted we may as well open up a 3D modeling program... having the restrictions to have to work around is a good thing and can lead to some really creative workarounds to the problem. other than the case of the NYI mechs having smaller switches is not really needed and would be too finicky to use reliably

[Kaiser-Indrasil]

no need to drag this further and shoot on the ambulance

I love that idiom even though I only have a vague idea on what it means ;D

[bombel28]

Thank you for the great work! I found following: Logic is not working correctly... I have a volumetric seonsor and a button connected to OR-gate, which triggers a switch. I cannot activate / deactivate the switch with the button. When unlinking volumetric sensor, everything is fine. Maybe, volumetric sensor is sending permanent "active". In earlier version, it was active only while in sensor area, I think.

[Uncle-Ulty]

shoot on the ambulance:

I loved this expression, so I asked uncle Google the meaning.

In brazilian portuguese we have a similar expression: "Chutar cachorro morto", "To kick a dead dog". But the french one seems less agressive xD.

[ProPeach]

-Stickers (Markings and Details) are invisible when placed and on spawned in ships

Expanding on Exodist's report, there's some strange behaviour linking the codex and the visibility of stickers. I opened the codex, and stickers on all ships disappeared. Restarting the game is the only way I've found of getting them to reappear. https://user-images.githubusercontent.com/27857711/118029341-fc3a3100-b35b-11eb-929f-024781552a0d.mp4 Player.log

[tsunamayo]

Yep I reproduced the issue with the codex and the decals.

[tsunamayo]

So I repushed a build with the decal fix. I am working on damage, I keep you posted.

[CurioInventorium]

Pistons don't fully retract when switched off. I've attached the blueprint of a building where I was showing how to do moving landing pads. Work Platform.zip

Also, Piston shaft disappears from view when the base is not on screen. Looking up slightly so that the base is no longer in view and the shaft disappears

[ProPeach]

• Sticker placement ghost has an inconsistent alignment on angled surfaces like a slope or tetra https://user-images.githubusercontent.com/27857711/118163506-f73bb700-b419-11eb-8d41-26d2b9a91f26.mp4

• Stickers still have a very high minimum stretched height, 0.75m for a 1/4x scaled sticker which makes their bounding box very large

• Icons in the Codex tab are also very dim compared to other icons in the Codex

[ProPeach]

Not sure if this is within the scope of this lighting pass, but the reflected bloom effect looks very strange here considering the shape of the actual light block with its solid sides.

The intensity of the reflection is also very high, even on more "matte" painted surfaces Shadows cast by the sun also seem much stronger than the light from the brick itself

Also on a more minor note, the pulsing of lights is perhaps too noticeable, in my opinion it should be either much more subtle or simply not there. Maybe slow it down, and decrease the intensity of the pulse? https://user-images.githubusercontent.com/27857711/118165095-d1afad00-b41b-11eb-95b5-72adcdd04ff5.mp4

Regarding the lighting itself, what do you think of reducing the ambient world light level? Now that the lights can be stretched large enough to illuminate large areas, some deeper shadows would really make them stand out. This is an enclosed hangar in complete "darkness", but it feels like it's 6pm on a Summers day :D

I think this is the most beautiful SEVO has ever looked in terms of lighting (pulled from #2838), mostly due to heavy AO and a low ambient light for deeper shadows. The current light feels quite sharp and harsh, rather than softer and smooth. I might be using terms incorrectly as this isn't my field, but I hope the example helps!

[ProPeach]

• Unable to paint stickers with the material paints. Systems also can't be painted with materials paints

[ProPeach]

• More on material paints - You can paint a brick with a material paint, but you cannot remove it with the paint in your hand like you can with regular paint using LMB and RMB

• Not sure if this is intended behaviour so please correct me if so - Seems like material paint and regular paint are now on different "layers". You can paint a brick copper for example, then paint it grey. If you remove the grey, copper remains underneath. This means that if your build is grey coloured and you want to repaint it to dark steel, you can't simple repaint it with the dark steel because it doesn't remove the grey, you need to remove the grey and repaint it with dark steel

• Slightly offtopic, but could you enable the finer system grid for mechanisms too? I'm thinking of situations where you need a higher mass limit for a larger turret, but can't place a rotor along the centre line of an odd width hull because most of the scales are centred across an even grid

• Mechanism mass limit calculations don't seem to update when you remove blocks. Place some huge, heavy blocks on a small rotor till it reaches the mass limit, then remove them all. If you place even a small brick on the rotor now, it will still say it is over the limit

[ProPeach]

• The codex icon for which ship you're working on, as well as the one in the HUD in the bottom right corner does not update Here's I'm working on a Starship (Go SN15!), but another ship is shown in the little icon. The stats for the Starship blueprint are shown on the actual tab though.

As well as the ship icon being wrong, the heat and power stats are incorrect too

[tsunamayo]

@ProPeach I am not "fixing" the specular shape on the side of the light, I think even AAA games are not dealing with this. I will try to tweak the ambient a bit. New light have no ambient factor to it (at least yet). Just like real time lights in others games really. The one before was pure ambient, so it was very smooth and soft. If the specular is too strong, use a dimmer light or paint the surface. It is uses the same physically correct equation as the sun, so I dont really want to tweak those, at least up until I have ambient added to the light (in that case I will just reduce light strength) Not sure to understand the issue with the shadow.

For now you are using Material as a decoration tool, but they are supposed to be gameplay element, ie give hull different stats (weight / armor). So you cant "remove" a material - only replace it. If you want to upgrade your hull you dont want to remove the paint. cheers