Critique: Smoke Shed - Hitbox - Inconsistent size.

[mvgulik]

Most of the stuff in the game that can be build has a hitbox that relates to 1/11 tile. With some 1/22 tile exception I think.
But the Smoke Shed ...

I don't know what its using for its hitbox. But it ain't using 1/11, 1/22, or even a 1/44 tile related size.
(goes for both X+Y size by the looks of it)

QA/Floating-point hiccup ... I hope.

[loftar]

Most of the stuff in the game that can be build has a hitbox that relates to 1/11 tile.

That is true, but that is only an artifact of the pre-floating-point coordinate system and so wasn't really intentional as such; new bounding boxes are free to be any valid floating-point value in size. If you're arguing that we should keep bounding-boxes to consistent fractions, then I would at least argue that the more reasonable fraction would be the default placement granularity, which is 1/8 of a tile.

That being said, you might also just not need to be maximally autistic in placing bounding-boxes exactly adjacent to each other. Losing a small fraction of a tile here and there might not be the absolute end of the world, hm?

[mvgulik]

Adding some previous posts related to the subject.

By the way, as the FP test-server thread indicated, floating-point positioning technically allows for pixel-perfect placement of carried/built objects, but in practice I found this mostly annoying since it made it impossible to align objects properly. Therefore, when Ctrl-placing objects, the client will by default lock positions to eighths of a tile. This is adjustable, though, by way of a new :placegrid console command that will set how many positions to lock placement to. I've found :placegrid 2 to be fairly useful in common situations. Also, :placegrid 0 turns off locking entirely to allow for arbitrary placement of objects.

If you want something similar to the previous placement mode, then try :placegrid 11. The placement will be offset by half a pixel compared to the previous mode, but they should line up in the same way relative to other objects placed with :placegrid 11.

--- --- ---

Most of the stuff in the game that can be build has a hitbox that relates to 1/11 tile.

That is true, but that is only an artifact of the pre-floating-point coordinate system and so wasn't really intentional as such; new bounding boxes are free to be any valid floating-point value in size.

An artifact you say. It seem to me that something that has been in a game for a really long time becomes a bit more that just an artifact.
But than again. Considering a bug is only a bug if the related creators say it is a bug, and until than technically its just an undocumented and unofficial feature. I guess labeling the current system as an "artifact" makes sense to bypass taking its long time existence into consideration.

If you're arguing that we should keep bounding-boxes to consistent fractions, ...

Yes, I do.
Don't you think having some consistency behinds objects sizes is a good thing?
The alternative seems to me that a system that uses arbitrarily picked object sizes, would creating a system that would fight users that try to space-optimize there stuff. (or that do so to limit hearthlings getting stuck/blocked by the gaps between default placed objects, like for example with Drying frame's)
(Needles to say that users that only use the default client are probably not doing much space-optimizing, because I imagine that's a real cumbersome and annoying trail and error process in that client)

... then I would at least argue that the more reasonable fraction would be the default placement granularity, which is 1/8 of a tile.

It makes more sens to me to use that what is already there, and having adjusted the default placement granularity from 1/8 to 1/11 tile a long time ago.
But the latter would be more or less an official commitment to it, which seems to potentially conflict with the "eternal Alpha" self labeling of the game.
I don't know what it would take to update the game to overall fit a 1/8 tile system (or some other (even)value). Figure plenty of graphics would need to be adjusted for this (or perhaps not, looking at some of the stockpiles), and it seems to make more sens to do something like that between worlds instead of during one (unless properly documented/announced ... if you like to have some user feedback on the subject that is).

That being said, you might also just not need to be maximally autistic in placing bounding-boxes exactly adjacent to each other. Losing a small fraction of a tile here and there might not be the absolute end of the world, hm?

Do you really think its just about being "maximally autistic in placing bounding-boxes exactly adjacent to each other". Or that it is more about having a underlying system where the users don't have to be "maximally autistic" to place there stuff in a less space wasting manner ?
Don't you think that having an easy to understand, and thereby also easy to use, placement system is a good thing for a game ?

+
Note that in the image the bounding boxes are overlapping, which means building the second one is blocked by the first one.
(visually Smoke Shed have the same width as ovens, ... just a little big bigger.)
If they where having a similar sized gap, instead of an overlap, it would be a somewhat different situation as building the second one would not have been blocked.
The latter could be seen as using new free sizes, while taking in account the current dominant system. The former is in my view clearly showing that that was not taken into consideration.

[mvgulik]

(both highlighted (green/blue) hitbox's used "placegrid 11") (Courtesy of Ender client)

Guess ":placegrid 0" is going to be of potential future use.
(especially for those afflicted by that autistic placement habit, of course.
Bad, bad users!. You should be ashamed, getting accustomed to doing something that was never intended to be done in the game in the first place.)

[Fostik]

end of the world, hm?

Yes, please

[mvgulik]

Noooo. I have not made that tree-maze yet!

(Hm ... o yea, planting trees the autistic way is currently a bit troublesome. O well, well see.)

[ghandhikus]

That being said, you might also just not need to be maximally autistic in placing bounding-boxes exactly adjacent to each other. Losing a small fraction of a tile here and there might not be the absolute end of the world, hm?

You mean half of the playerbase? I played with tenths of people in haven and everybody who used amber did place stuff near each other to pack them well. Look at some screenshoots to see how chests and industry buildings are stacked. It's all about space efficiency.

[yozzik111]

end of the world

Confirmed!

[mvgulik]

Hm ... seems bounding-/hit-boxes have acquired something resembling a general overlap margin.

Guess that's one (not officially confirmed) potential solution. (lol)

(Spotted after Game Development: Seaworthy Movement patch.)

(None-officially solved ... for now)

[shubla]

Guarantee for all hitboxes to be non-intersecting would be very nice indeed.