Minecraft Version

1.16.1

Forge Version

32.0.108

Mod Version

2.1.2-25

Describe your problem, including steps to reproduce it

A quick program, which will measure the pressure of the block below a programmable controller using all sides with a threshold of 5
https://pastebin.com/V2F1DHsy

When measuring the normal tube at 10.1 (using a creative compressor to power the controller and pressure the tube) it will always evalute to false. Regardless of setting it to >= 5 or <= 5 it will always take the left code path.

Edit: Appears to be related to using $drone as the position of the programmable controller. Using a GPS tool to set an absolute position works fine. Either as direct input to the condition widget or first using a coordinate operator and adding the gps position to a variable.

It's a bit counter-intuitive to work with $drone as the y coordinate is like 1 or 2 below the drone's visual position. You'd have to offset it for this to work the way you're wanting it to.

Best way I've found to get a hang of this is to rename the drone to $drone at specific times so I can see what the actual internal value is.

Maybe even both? Add $position for the correct position of either a drone or programmable controller as well as $controller for the controller position. Which then of course will be the same as $position. $drone could be kept as the position of the drone and the drone above the controller (just document it).

So $position could be just to just get the position regardless of a drone or controller.
$drone is still there for backwards compatibility.
And $controller could further be used to detect, if running in a drone or controller and e.g. skip the disabled widgets while still having a generic program.

Using (0,0,0) has technically the issue when someone places the controller at this location, but this either requires breaking bedrock or a modded void world or similar. But I would guess the chances for it are negligible.

Could also be $self or similar when trying to maintain the semantic with $drone and $player. As $position would be somewhat ambiguous.

Pretty much what I'm planning, but to make it totally clear:

• $drone - old var which gets the blockpos above the drone. Leaving this as-is for compatibility reasons even though it's unintuitive.
• $drone_pos - new var which gets the blockpos the drone is actually in (and for a controller, the fake "minidrone" position)
• $controller_pos - new var which gets the blockpos of the controller itself, or (0,0,0) if used by a real drone
• $owner - existing var which gets the head position of the drone's owner
• $player=<name> - existing var which gets the head position of the named player, or (0,0,0) if the player is offline

The mod has always used (0,0,0) as an "invalid" pos for other things, so I'm OK with this even if it's not ideal. Just don't build there :P

I'm thinking of adding $owner_pos and $player_pos for consistency (so all new vars end in _pos), but they would just be aliases for the existing $owner and $player variables.

And $controller could further be used to detect, if running in a drone or controller and e.g. skip the disabled widgets while still having a generic program.

Could be a bit more tricky, since right now it isn't even possible to insert a drone/api with such widgets into a controller. Might be possible, but significant redesign work needed, so not a priority.

For Programmable Controllers, $drone will get the position of the fake "mini drone" that the controller renders. When idle, or the program hasn't actually told the drone to go anywhere, this will be the block above the controller (since that's where the minidrone sits when idling).

However, interestingly (and this is code that's been here forever, like 1.7.10 days...), when the position is retrieved from the drone object (which could be a real drone or a programmable controller), 1 is explicitly added to the Y coordinate: see https://github.com/TeamPneumatic/pnc-repressurized/blob/1.16/src/main/java/me/desht/pneumaticcraft/common/event/DroneSpecialVariableHandler.java#L31-L33

There's even a comment there querying it. It's definitely weird, but I am reluctant to change it now, since it could break a lot of existing programs. But yeah, what it means is that $drone for a programmable controller will get the block one block above the mini drone, which when at rest means two blocks above the controller itself.

So it's counter-intuitive for sure, but not so easy to fix at this point without breaking backwards compatibility. What I could do though is add another special variable, say $controller_pos, which gives the blockpos of the programmable controller itself (or 0,0,0 if a real drone uses it). I could also add another $drone_pos variable which gives the actual blockspace the drone entity is in and document $drone as being deprecated.

Fixed in 2.2.0 release