Ask a simple question, get a simple answer

[zimberzimber]

Apperantly, you can't pick up items from both sockets and surfaces if you're standing on their tile. I assume they were designed for altars and other object which you can't stand inside.

[minmay]

Apperantly, you can't pick up items from both sockets and surfaces if you're standing on their tile. I assume they were designed for altars and other object which you can't stand inside.

You can if they have wall placement mode instead of floor placement.

[Isaac]

But [of course] this then reverses it, and you can no longer interact with the objects from outside of the same cell.

@zimberzimber
Is pixel perfect placement important to what you are doing?

[zimberzimber]

@zimberzimber
Is pixel perfect placement important to what you are doing?

Pretty much.
I've created an object with tiny spaces on the ground that fit for holding herbs.
Can't upload an image until next week.

[Isaac]

@zimberzimber
Is pixel perfect placement important to what you are doing?

Pretty much.
I've created an object with tiny spaces on the ground that fit for holding herbs.
Can't upload an image until next week.

I have a script that simply spawns the items into the cell, then moves them to a determined offset. Numerically the locations are consistent, but in preview, [for some as yet unexplained reason] the objects models rarely appear in the expected (pixel perfect) location assigned to them.

[zimberzimber]

Wouldn't the items move if you are to walk over the cell? That's the main reason I don't want to spawn them just like that.

[Isaac]

Just off the top of my head [untried], you might be able to redefine the sockets using 'wall' placement, and then use a floor_triggered script to rotate the sockets to face the party; and [necessarily] use a keyed table [0-3] with appropriate offsets for each item ~to not appear to shift position... even though the sockets may have to switch cells.

[minmay]

@zimberzimber
Is pixel perfect placement important to what you are doing?

Pretty much.
I've created an object with tiny spaces on the ground that fit for holding herbs.
Can't upload an image until next week.

I have a script that simply spawns the items into the cell, then moves them to a determined offset. Numerically the locations are consistent, but in preview, [for some as yet unexplained reason] the objects models rarely appear in the expected (pixel perfect) location assigned to them.

Sounds like you're moving them at the wrong time. For example if this is the entire source of a script entity:

Code: Select all

etherweed_1:setWorldPosition(24,0,24)

it's pointless because the game hasn't decided on the item's default location yet and will just overwrite your change. But if this is the entire source:

Code: Select all

function a()
  etherweed_1:setWorldPosition(24,0,24)
end
delayedCall(self.go.id,0,"a")

then it will happen at the right time.

zimberzimber, you want items that can't be pushed, but otherwise don't behave as if in a surface or socket. Your first instinct should NOT be to use a socket anyway. The hack Isaac suggests, aside from being kind of ridiculous, won't accomplish it, because being in a surface/socket doesn't just restrict the squares you can pick up the item from, it completely changes the allowed distance for picking up items, among other things.
Instead, use ItemConstrainBoxComponent. It lets you define an arbitrary 3D box that items cannot be pushed into or dropped into. If you completely cover an item's possible push paths (which can be done with just one ItemConstrainBoxComponent, or you can use 2 very thin ones to avoid blocking other areas), that item won't get pushed. You do have to cover the whole path and not just the starting point, though.

[Isaac]

The hack Isaac suggests, aside from being kind of ridiculous, won't accomplish it....

Can you prove that?

[minmay]

The hack Isaac suggests, aside from being kind of ridiculous, won't accomplish it....

Can you prove that?

Yes, but instead of exhaustively proving the difference, I will explain it more precisely. If an item is not in a surface or socket, and there's not something in the way, you can pick it up if it is at the party's elevation and its world x distance and world z distance from the party are both under 2.5 meters. If an item is in a surface or socket, not only must the party be on the right square facing the right way, the distance requirement is relaxed to (what appears to be) the maximum clickable distance, considerably higher than 2.5 meters. Here is a demonstration: paste this in the console:

Code: Select all

s=spawn("beach_puzzle_statue")
 s.socket:setOffset(s.socket:getOffset()+vec(4,0,0))
 a=spawn("rapier")
 b=spawn("rapier")
 b.model:setEmissiveColor(vec(-1,0,1)) -- visually mark as the non-socket rapier
 s.socket:addItem(a.item)
 b:setWorldPosition(a:getWorldPosition())
 b:setWorldRotation(a:getWorldRotation())

Now stand in front of the statue (step forward once after pasting) and try to pick up the rapiers while standing there. You will find that you can only pick up rapier a while standing in front of the statue, but cannot pick up rapier b without moving closer to it, despite rapier a and rapier b having identical transform. The only difference is that rapier a is in a socket. Therefore, sockets change item pickup distance.