Client distinguish between eye and mob for drawing, context menu, and verbs#2477
Client distinguish between eye and mob for drawing, context menu, and verbs#2477Ruzihm wants to merge 21 commits intoOpenDreamProject:masterfrom
Conversation
…g draw, context menu, verbs
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
boring-cyborg
bot
added
Client
Co-authored-by: wixoa <wixoag@gmail.com>
|
actually - one sec. z levels and mouse events are messed up when eye is a turf. edit: should be good now |
|
Setting eye to null will stop rendering - but since that's done by setting the eye position to be in nullspace, the viewport stops clearing the render target and you just get a frozen screen: Does this warrant a pull request to RT to add a viewport option to allow target clearing if there is no eye/the eye is in null space? |
I think that would be better as the default instead of an option, but I suppose that's up to the RT maintainers. |
|
So turns out that RT patch wouldn't help since a null eye should still render screen space elements in non-negative planes. PR should now account for that. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
3 participants
Adds a network message sent from the server to client to notify of mob/eye updates (currently, the client uses the attached entity which is ambiguous). I wasn't sure of a better way to accomplish this but am looking for feedback.
The client then uses this info to distinguish between eye/mob for context menu, drawing, and verbs.
Closes #1581
Closes #2081