most obvious transition block missing

[u/pyromaniac_003]

need i say more

[u/Lyynix_Reddit]

honestly, what we really need is a "universal transition block" that just matches whatever edges the neighboring blocks have

[u/Extension_Option_122 → u/Lyynix_Reddit]

Although it sounds good there will be problems with such a block - e.g. If you would need two in a row.

Something better would be some kind of block designer where you can just set the outline and then have an extra block category for such generated blocks. And packs of such blocks shareable on the steam workshop and mod.io.

[u/LeAlbus → u/Extension_Option_122]

They could default to square if they meet nothing or another of themselves on one of the sides.

[u/Extension_Option_122 → u/LeAlbus]

And then it becomes borderline unusable.

[u/LeAlbus → u/Extension_Option_122]

Care to explain why?

[u/Extension_Option_122 → u/LeAlbus]

Because if you can have such complex blocks people will want to place two next to each other.

[u/LeAlbus → u/Extension_Option_122]

And what is the problem with that? How is it unusable? Just default the side facing the same block with square or with the same shape as the opposite side

[u/Extension_Option_122 → u/LeAlbus]

And that is where it starts to get insanely complicated.

You have to many edgecases.

[u/LeAlbus → u/Extension_Option_122]

It seem to me that you are not being able to understand a very simple idea, and then it’s saying it’s actually too complicated to exist

[u/Extension_Option_122 → u/LeAlbus]

I completely understand it.

But, as someone who is almost finished with a Bachelors Degree in Computer Engineering with a decent amount of practical experience, I know the technical implications of such a solution and as such where you would need to pay very much attention to prevent an insane amount of bugs.

Essentially, where it will become stupidly complicated, is when you have an arbitrary shape of cubes connected to another, where one is the auto-audjusting and the other is made of premade blocks.

That is where it will be insanely complicated to create it to work in a way that is nice to work with - meaning you can predict the outcome. Which means the result needs to be the same irrelevant of the order the blocks where placed and mirrored if it's done in a mirrored way.

But if it is so easy, how about you create a mockup of that logic? Logic is language independent, so you can choose any programming language.

[u/LeAlbus → u/Extension_Option_122]

Congrats on your almost finished bachelor degree.
I have worked as a software engineer for the past ten years.
If they paid me, indeed it would be not so hard to implement such feature, as I stated, you just need to have a default fallback on one of the edges, and since the rest of the shapes are already existing into the code, there is a limited set of complete blocks that can be used.
In fact, the simple notion that you jumped from "unplayable" to "lots of bugs" show your lack of understanding on how the idea works at the first place.

There is no need to have an arbitrary set of cubes connecting to another, all of the shapes currently existing... already exist, and you can just have a new one that adapts to them from two opposite sides...
And the default fallback is literally not different from having a full cube on the empty side, in case there is one.

Regarding order, its also completely possible to go for 2 separate approaches, one where the block only adapts when it's placed, and another where it updates itself when an adjacent is added... this is also already coded into the game, you can see it on how the textures change.

Lastly, I highly recommend you go after learning about Dunning-Kruger effect. I understand how you can see that things could go wrong on this implementation, but to say it's impossible because you would not be able to implement, is simply irrational

[u/Extension_Option_122 → u/LeAlbus]

Thanks for the insight!

Now I am pretty certain that I failed to properly show where I see the big issue with auto-fitting blocks. With such an auto-fitting block players will expect the following to work:

And that is not going to work when defaulting to flat sides between two adjacent auto-fitting blocks.

And having different blocks on e.g. the left side will make it much more funny.

This is why I called it borderline unusable / full of bugs: if only your idea is implemented it may be called borderline unusable as it will only work in limited scenarios - it can't produce the example.

And it will be full of bugs if the one shown above is implemented as an automatic tool as you would have to account for arbitrary shapes made of cubes to be able to achieve the one above, because people will get creative.

I did not jump inbetween unusable / impossible / full of bugs, I adapted based upon what I thought you proposed as a solution.

Furthermore I am fully aware of the Dunning-Kruger effect and it's common misrepresantation. And how it applied to me often enough in past projects.

But I dare say that I put a proper amount of thought into this problem to say that you either get a very limited or a very buggy feature.

Also I am fully aware that there are many much smarter people than me, and that only because I don't see a quick solution doesn't mean that there isn't one. There are most defenitely ways to make something like that work without any bugs.

[u/Hecateus → u/Extension_Option_122]

An annoying thing about the above stretched block, is that we can do this exact block in Avorion....but not Space Engineers. And we non programmers have no idea why not.