Diagonal Access (is it a bug?)

[SakuraKoi]

The denial in this thread is a strong one and quite amusing indeed.

Obviously this was never intended and will never be. At best it is tolerated because it would complicate building corners (as well as reduces workable space for digging). This by no means makes a bug a feature nor justifies it.

Do I care for its removal? Nah, however prepare yourself if you mean to talk others into (ab)using it because it is supposedly a feature.

[Slvrsrfr]

i try not to use it, but the game would be harder without it, imho. it's a tough call for sure.

[Ecu]

2 hours ago, Nightinggale said:

Each cell will have 8 cells to interact with instead of 4. You said it yourself that it's twice as many. That's not exponentially. However twice the CPU load from something, which already has too high CPU load is still really bad.

As I already mentioned, just because you double the potential neighbors to check, does not necessarily mean that you double the overall computational stress.  It really depends on how their algorithm works.

[Gurgel]

2 hours ago, SakuraKoi said:

Obviously this was never intended and will never be.

Obviously it is coded in. And that makes your complete point invalid.

[Cairath]

10 minutes ago, Gurgel said:

Obviously it is coded in. And that makes your complete point invalid.

Technically, absolutely all software bugs are coded in. They don't sneak into your code uninvited while you compile it. 

[supparino]

What about pepperoni access?

[bonzaiferroni]

3 hours ago, Nightinggale said:

but fixing this problem will cause other problems, in particularly building tiles in a corner will become really annoying

I think it would be a good solution to treat building sites differently from buildings, allow diagonal access for building sites to avoid unfinished corners. That would also mean allowing access for digging/deconstruction. However, enforce line-of-sight access for interacting with buildings. That would disallow exploits without adding hassle to building.

[Nightinggale]

4 hours ago, SakuraKoi said:

Obviously this was never intended and will never be.

Back when Street Fighter II was developed, they ran into a problem where if the player did an attack before completely finishing the first attack, the result would be different than just doing the two attacks one after the other. They ended up deciding to keep it like that and call it a feature and the concept of attack combos in fighting games was born.

Now you are saying attack combos is a flawed concept because it wasn't a planned feature. The part about if it's planned or not doesn't really matter. The real question is if the result is a wanted result or not.

[Ellilea]

I don't know, I really can't see the devs going:

"Yes, when the corner is dug out/deconstructed there should be no gas or liquid access, but the duplicants and sweepers can take things out of there because reasons".

It's not logical and therefore I doubt it was intended. Pretty damn sure it was simply a consequence of something more like:

"Yes, let the duplicants dig/build/deconstruct diagonally, otherwise it will be annoying."

And simply no thought/additional coding was done for the gases/liquids to flow through, because it didn't seem important/necessary/highPriority or because it was forgotten amongst all the other stuff going on.

Doesn't take a mind reader to deduce that.

[axxionx12]

I think the main point is feature vs bug vs working as intended vs exploit resides in a highly subjective grey zone with the devs having the final say. Everyone's input is valuable and is best when we're all respectful. Remember, the devs have asked people to be civil and cut the elitist passive aggressive crap.

 

Personally, the idea of pulling materials safely through a diagonal seems unintentional and allows people to easily avoid more complexity solutions. I had to concoct some weird solutions to try to address sweeping hot solids in a vacuum and enjoyed the mental exercises.

[nakomaru]

@Ellilea And then what about the step after that? When they realized the combination of these two rules? Do they leave it in the game, like how they introduced the conveyer drop off? Do they patch it out like drip cooling? Maybe they have decided already, or not. Saying it's obvious what they think about it as @SakuraKoi does is silly without any response from them.

[Gurgel]

4 hours ago, nakomaru said:

@Ellilea And then what about the step after that? When they realized the combination of these two rules? Do they leave it in the game, like how they introduced the conveyer drop off? Do they patch it out like drip cooling? Maybe they have decided already, or not. Saying it's obvious what they think about it as @SakuraKoi does is silly without any response from them.

Quite frankly, this is such an elementary thing that it must have been already in the very first test implementations. This can really not be a bug. Now, what people use it for is something else, but that the game does no have diagonal tile interaction must also have been a very early decision. Take these two together and you get: Not a bug, not an exploit, works as intended. 

May be a potential game-balance issue, but I don't see that either and apparently Klei does not too.

[SakuraKoi]

Yup, those leaps and bounds in logic and selective perception is outright awesome~

Seriously, how can you intend for something to happen when you did not know it would happen? What about perhaps knowing about it and simply accepting it as consequence?

Please don't make common sense cry, she has to deal with enough foolishness already. Don't ever become a designer of anything if you think that this is intentional and on the same level as an accidental feature, which, again, was not intended but has gone beyond being tolerated and even accepted.

 

On a side note, due to being similar in that 2D, I wonder how it works in Rimworld since I forgot if walls can be built like tiles here (diagonally) and if colonist can grab through.

8 hours ago, Cairath said:

Technically, absolutely all software bugs are coded in. They don't sneak into your code uninvited while you compile it. 

Indeed. Disregarding that non-sense, one actually has to present this supposedly obvious bit of code(+dependents) which obviously separates grabbing reach from building reach and digging reach. This could be the case in Rimworld but sure does not appear to be like in ONI (because all reaches reach the same), all coders code differently, there are countless ways to code a system, just due to the virtue of the fact that the engines are different.

One can make it simple, one can make it independent, one can do it otherwise. Write more code? Require more processing resources? There is so many things a programmer can do to follow the directives of the (lead) game designer... and precisely the reason why I'd rather design, merely knowing enough about programming to make my demands reasonable.

[Gurgel]

12 minutes ago, SakuraKoi said:

Seriously, how can you intend for something to happen when you did not know it would happen?

That is the very nature of a "simulation". You do not do it to see behavior you "intended". You do it to see what can be done with the mechanisms you put in. What is so hard to understand about that?

There seems to be some mental block some people run into with that very idea. I do not understand that one at all. Maybe because I have done some simulation-based research myself and written some (simpler) simulators. 

Now, there are other ways to design a game and, for example, an adventure game or a shooter has very little or no non-anticipated behavior. That is one reason these can be tested very well with standard Q/A, you just work down a list of designed moves. For a simulator, that does not work. You need lots of people with vastly different backgrounds to just try and see what they can do with it. And that is perhaps the primary reason why this game is so "public preview" heavy in its testing.

And please stop invoking "common sense", "obviousness", absolute statements about what the designers "must have" intended, etc. when you do not even understand the basic design principle and the idea behind it. 

[Moah]

On 27.7.2019 at 2:00 PM, Ecu said:

Diagonal access is clear to me, but how do you put the food in this tile?

[Saturnus]

7 minutes ago, Moah said:

Diagonal access is clear to me, but how do you put the food in this tile?

Conveyor ore chute

[Moah]

1 minute ago, Saturnus said:

Conveyor ore chute

Thank you, i forgot this new building.

[miauly]

13 hours ago, Cairath said:

Technically, absolutely all software bugs are coded in.

Almost all modern software is complex enough for developer not being able to predict its behavior fully. So you can clearly draw the line between "code added to do specifically so", like for example fixed temp output, and "bits of code added for other purposes creating an additional effect" like matter duplication (possibly). At least for someone who has access to the actual code and change history, the line between bug and feature is clear even in the absence of technical documentation stating intent.

But a more obvious counter-argument to your point is that almost all modern software comprises for 90% at least of code implemented by someone else. Libraries and frameworks are not coded by the same person who implements the game, and they behavior is documented sketchy at best. Reading their code in full before using them to internalize it like your own is unrealistic. Thanks to that, almost any development process these days implies that developers have a limited understanding of what their code does. This makes a pretty large gap between intended behavior - how developers wanted things to work - and actual behavior. And as I said above, if you have access to the code and changes, you can distinguish intended things from unintended. Without this access, you can derive similar, although less accurate conclusions applying your general coding experience.