Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ghost cannot read papers #27421

Closed
lzk228 opened this issue Apr 28, 2024 · 3 comments · Fixed by #27999
Closed

Ghost cannot read papers #27421

lzk228 opened this issue Apr 28, 2024 · 3 comments · Fixed by #27999
Labels
Status: Untriaged Somebody go through and give this appropriate labels

Comments

@lzk228
Copy link
Contributor

lzk228 commented Apr 28, 2024

Earlier it was possible via verb, now there is no verb for ghosts.
@github-actions github-actions bot added the Status: Untriaged Somebody go through and give this appropriate labels label Apr 28, 2024
@lzk228 lzk228 mentioned this issue Apr 30, 2024
Closed
@slarticodefast
Copy link
Contributor

I did some debugging and found the code piece that is causing this.
Here is some kind of stack trace:

We start in ActivateableUISystem.cs
grafik
which leads to SharedUserInterfaceSystem.cs
grafik

grafik

BoundUserInterfaceMessageAttempt leads to SharedInteractionSystem.cs

grafik

which calls CanInteract(...)
grafik

This function returns true for Mobs or Aghosts, but false for ghosts.

This is already checked earlier in ActivateableUISystem.cs:

grafik

Simply removing the second check would probably break more stuff and I have no idea how to properly fix this, but I hope this will safe someone else some time.

@slarticodefast
Copy link
Contributor

Ok, I came up with something that works but looks super hacky in my opinion. Maybe someone else finds a better solution with this as a starting point:
slarticodefast@e5b750a

@ShadowCommander
Copy link
Member

The code is currently hard to understand, so it's a good time to write out the cases in which a player can interact with an ActivateableUI and what the end result should be.

If not CanInteract
    Deny interaction
If not in the same container
    Deny interaction
If IsAdmin
    Allow interaction always
If not in range unobstructed
    Deny interaction

If ActivatableUIComponent does not exist
    This was not triggered by an activatable UI so there should be neither deny or allow.
    Return exit early
If user is a ghost and the ui allows ghosts to view
    Allow interaction
If UI requires hands and user does not have hands
    Deny interaction

And sorting it by priority

If ActivatableUIComponent does not exist
    This was not triggered by an activatable UI so there should be neither deny or allow.
    Return exit early

If IsAdmin
    Return Allow interaction always
If user is a ghost and the ui allows ghosts to view
    Return Allow interaction

If not CanInteract
    Deny interaction
// Slighly higher because the container and in range check are slightly more expensive
If UI requires hands and user does not have hands
    Deny interaction
If not in the same container
    Deny interaction
If not in range unobstructed
    Deny interaction

@ElectroJr ElectroJr mentioned this issue May 14, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Status: Untriaged Somebody go through and give this appropriate labels
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Improve InteractionSystem range & BUI checks ElectroJr/space-station-14
3 participants
@ShadowCommander @lzk228 @slarticodefast