-
Notifications
You must be signed in to change notification settings - Fork 126
Client distinguish between eye and mob for drawing, context menu, and verbs #2477
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.
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
base: master
Are you sure you want to change the base?
Conversation
…g draw, context menu, verbs
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. |
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