Well, it's not a Bug. It's a Feature that offsets the sprite of an object when its places adjacent to a wall.
But the results are kind of questionable because it only works properbly when the objects back is facing the wall. And it's espqcially iffy if placed in a corner.
On top of that it is used pretty inconsistently among similar objects. The office table has it, the sorting table doss not. The TV has it, the Radio does not etc.
This is what it looks like with and without:
For my mod http://steamcommunity.com/sharedfiles/filedetails/?id=537802156 i'm trying to decide between disabling it for most of the bigger objects (not TV, phone booth, shower head...) or leaving it enabled.
What do you guys think?
[Mod] AttachToWall Bug or Feature?
Moderator: NBJeff
[Mod] AttachToWall Bug or Feature?
Last edited by Meppi on Fri Oct 23, 2015 10:42 pm, edited 1 time in total.
Re: [Mod] AttachToWall Bug or Feature?
That's awesome you tested it !
Always wondered what it was really good for... never noticed the cases so noticeably!
Shame we'd need script in between everything if we'd want to do the repositioning ourselves... But I'd probably go try positioning everything around walls myself, so maybe good in my case
Always wondered what it was really good for... never noticed the cases so noticeably!
Shame we'd need script in between everything if we'd want to do the repositioning ourselves... But I'd probably go try positioning everything around walls myself, so maybe good in my case
- aubergine18
- level2
- Posts: 231
- Joined: Sun Jul 05, 2015 3:24 pm
Re: [Mod] AttachToWall Bug or Feature?
There are at least two design flaws at play here...
First part of the problem is the way objects work out what walls they are adjacent to. In scripting there is .Walls property that gives insight in to how it works. There are x and y values, that work much the same way as orientation.x and orientation.y when defining sprites... so x>1 means wall is north of object, x <1 means wall south of object, x = 0 means no walls north or south (or the object is on a wall). The same sort of thing for Walls.y. Now, imagine what happens, for example when an object has walls both north and south. The Walls.x value can't handle that situation, so it picks one over the other (I assume north but could be wrong). There is also an ambiguous state when an object is in the corner of a room... does it keep alignment with the wall that you just placed objects along, or the other wall that it's just encountered? it chooses one (again, I think east/west takes preference this time, because fuck consistency) and that's why if you put showers all the way around a room you get ugly offsets in the corners. These are design flaws in the game.
Second part of the problem is the origin point of the object itself. In the sprite definitions we generally refer to the origin point as the top-left or bottom-left corner, depending on how/where sprite is defined (because fuck consistency). On the map, the object origin point will actually be somewhere in the middle of the sprite, either top middle or bottom middle. There is a map-wide setting TopAligned which toggles the orientation mode, and then there are also sprite-level TopAligned setting that can override for a specific sprite.
Now add in orientation (rotation) of an object (.Or property in scripts) and you can see how it all starts to get so confusing with multiple things vying for priority...
It seems that amongst all the design flaws, errors in the game code have crept in resulting in the weird offsets when placed against walls. There's an acknowledged/assigned bug ticket on Mantis so it seems that IV are finally going to attempt to fix the problem (it's been around since at least Alpha 8!!!). It's pretty amazing that a 5-year-old piece of software still has such glaringly obvious bugs in it.
First part of the problem is the way objects work out what walls they are adjacent to. In scripting there is .Walls property that gives insight in to how it works. There are x and y values, that work much the same way as orientation.x and orientation.y when defining sprites... so x>1 means wall is north of object, x <1 means wall south of object, x = 0 means no walls north or south (or the object is on a wall). The same sort of thing for Walls.y. Now, imagine what happens, for example when an object has walls both north and south. The Walls.x value can't handle that situation, so it picks one over the other (I assume north but could be wrong). There is also an ambiguous state when an object is in the corner of a room... does it keep alignment with the wall that you just placed objects along, or the other wall that it's just encountered? it chooses one (again, I think east/west takes preference this time, because fuck consistency) and that's why if you put showers all the way around a room you get ugly offsets in the corners. These are design flaws in the game.
Second part of the problem is the origin point of the object itself. In the sprite definitions we generally refer to the origin point as the top-left or bottom-left corner, depending on how/where sprite is defined (because fuck consistency). On the map, the object origin point will actually be somewhere in the middle of the sprite, either top middle or bottom middle. There is a map-wide setting TopAligned which toggles the orientation mode, and then there are also sprite-level TopAligned setting that can override for a specific sprite.
Now add in orientation (rotation) of an object (.Or property in scripts) and you can see how it all starts to get so confusing with multiple things vying for priority...
It seems that amongst all the design flaws, errors in the game code have crept in resulting in the weird offsets when placed against walls. There's an acknowledged/assigned bug ticket on Mantis so it seems that IV are finally going to attempt to fix the problem (it's been around since at least Alpha 8!!!). It's pretty amazing that a 5-year-old piece of software still has such glaringly obvious bugs in it.
Last edited by aubergine18 on Fri Oct 23, 2015 10:18 pm, edited 1 time in total.
- aubergine18
- level2
- Posts: 231
- Joined: Sun Jul 05, 2015 3:24 pm
Re: [Mod] AttachToWall Bug or Feature?
Oh, one other thing I forgot to mention which might also be having a major impact on the visual placement against walls...
When I was making my CircuitIsolator mod, the cabinets are in a 3x4 sprite. However, the top of the cabinet isn't flush with the top of the 3x4 sprite. This meant that when attaching to walls, it did move a bit, but obviously not enough to fill the gap at the top of my sprite area.
So this could be happening with the base game stuff too - if a sprite isn't completely filling the 32px squares its within, then obviously attach to wall will appear not to work - not necessarily due to the game code, but due to the gaps around sprite image itself. There is no way to accommodate for this in the sprite definitions, another design flaw.
When I was making my CircuitIsolator mod, the cabinets are in a 3x4 sprite. However, the top of the cabinet isn't flush with the top of the 3x4 sprite. This meant that when attaching to walls, it did move a bit, but obviously not enough to fill the gap at the top of my sprite area.
So this could be happening with the base game stuff too - if a sprite isn't completely filling the 32px squares its within, then obviously attach to wall will appear not to work - not necessarily due to the game code, but due to the gaps around sprite image itself. There is no way to accommodate for this in the sprite definitions, another design flaw.
Who is online
Users browsing this forum: No registered users and 13 guests