Player[color].camera methods#40

things like Player[“White”].camera.getPosition() and Player[“White”].camera.getRotation(), etc would be helpful.

some suggestions, maybe?
camera.getAttachment() - gets the object that the camera is attached to (or nil if unattached)
camera.getLookat() - gets the object that the camera is looking at (or nil if unattached)
camera.getUpVector()
camera.setPosition(vec3)
camera.setRotation(vec3)
camera.setUpVector(vec3 or nil) - nil defaults to global up
camera.setLookAt(guid, duration)
camera.setAttachment(guid, duration)

I would also request a Player[color].getViewportTransform() so that you could translate world cords to screen cords for XML Positioning(example, a hotkey to bring up a radial menu for action selection.)

Addendum for the set methods: speed parameter, with Nil being the default speed, 0 being instant.

We don’t currently sync cameras position and rotations across the network to save on bandwidth. I’m curious what use case this would enable?

The main benifit would be for XML. Currently, there is no method of making a 3d xml menu face towards a specific player. This means the best way of setting up 3D xml menus on objects or tables is to lock them specific rotations for objects, or relative to the users sitting position. However, once a player moves their camera position, those locked 3D xml positions no longer function as well, or at all, depending on the menus job.

Example usage:
Easy Character Stats for Mini’s.
Above the mini there is an xml panel that can be turned on or off while hover over the mini. It Scales in size relative to the camera’s distance to the mini, and rotates to face the camera’s position. This ensures that no matter where on the table, you can easily view the XML Panel to quickly access the minis basic information.

On Hover Menus.
Instead of relying on the context menu with right click(which can easily be cluttered), we can create our own menu using event triggers to make a 2d menu become visible. However, currently that 2d menu will spawn pop up somewhere on the screen, instead of where we want it(the triggering event). Having the ability to translate world Cords into Screen cords means that when you trigger a menu, the menu can appear next to the player’s pointer, allowing for more intuitive xml menus.

I would use the functions to create radial menus and object overlays for various ccgs and ttgs.

I’m not sure how viable use in the XML would be as IIRC you’d have to re-draw the UI whenever the camera shifted, assuming you want to have the menu continue the camera while open (though, I guess a UI facing the camera at first draw would work)

my own thinking was an extrapolation of what I’d love to be able to do with the spectator view camera - this seemed like a logical extension of that is all. I can go into more depth on that ticket instead if you’d rather.

Hmm, could go with only updating it if the player camera moves more then x units. That way I only have to call setAttribute(“radial_menu_color”,”rotation”,””..get_inverse_rotation_of_camera) if the player is moving around, and then only when its visible to the player based of their camera rotation.

I wanted to create a new game mod that uses the camera positions/angles:
The goal would be to look at a certain point cloud (lets say 50x50 voxels) that would make a correct 2D picture when viewed from the correct angle. Like the projection would be a correct picture/object, but looked at from another angle would be more random because the “depth” of each voxel is randomized/distorted. The player that finds the correct viewing angle first, wins the round.

I could imagine other fun use cases as well:

• You could change the direction of a looked-at object, just by viewing from a different angle. That could be used in a game where players “control” an object (like flying/pushing it)
• You could program an “intelligent” help/tutorial that “knows” when the player is looking the wrong way or at the wrong object and tell him that, but otherwise stay quiet
• Maybe even create a game where the player camera is “flying” through the air controlled by the viewing angle and/or keys, like a small spaceship

regarding feature implementation:

• this could be optional
• this could be script-activated via command (like registered)
• this could be communicated only to the host

Thanks for looking at this idea closely and considering it for implementation

One thing that would be great to also add if we do get these camera functions (fingers crossed) would be having a pop-up at the top of the screen that says something akin to “Press Escape to regain control of the camera”, so that you can never get screwed TOO badly by camera movements, since it’s pretty core to the TTS experience

As for what it could do, you could do great tutorial stuff without having to have an object to look at, which is the only way to do it currently and is pretty annoying to do. You could also do some fun stuff like if you look up and away from the table it’d be a trigger to switch something from the table.

If the option to have access to the player[color].camera info is not feasible with the keeping packet size down. Can we have a new XML panel variable to render 3d coords as 2d? So they only show up when a player can see the 3d coordinate. Can use the already existent offset variable to control where it shows up in regards to the 3d coord. This also means that all the math is done client side as part of the xml. And an option for edge snapping or smooth scrolling on to the window if the object is only partially visible?

@Knil wrote: “We don’t currently sync cameras position and rotations across the network to save on bandwidth. I’m curious what use case this would enable?”

I see the problem. Perhaps rather than sync, can you do a request/response sort of thing? I can live with something where the data turns up within a few frames after the request. (ala web Request)
Or only sync every N frames?

Perhaps implement a mod option to enable camera sync at mot load time, but save the bandwidth if the mod doesn’t need it?

Even a camera event zone which triggers if the center of the player’s view enters the zone

Another point: camera focus is central to creating a good VR experience. Your immersion is much improved when the game can be aware of what you are looking at. Actually that is true whether you’re using VR or not!

Today I am particularly annoyed that the camera has a collider. If I want the camera to colide with things, I can attach it to an object. Most of the time I want it to be just a transform {position, rotation, velocity, angularVelocity, up, right, forward}

Please give us at least API for getting transform of current player’s camera

I’m working on an add-on that uses the classic UI on sheets of paper as a primary way of interacting with automated game rules. I used the classic UI because the XML UI on objects does not show up when using the ALT key to do quick zooms of those paper objects. It is tempting to automate camera movement to speed up the turn as the players commonly interact with a single sheet of paper each turn. So, I’d like to save the current camera position for all the players on a team when their turn starts, then set their cameras to an angle that views the single sheet of paper for that UI manipulation (perhaps a camera state preset saved in the game), then restore their cameras at the end of the turn. The original camera angles are assumed to be looking over a minature map.

You can certainly use Player[color].lookAt(…) to set the camera to desired locations. What you cannot do is discover where the camera is if the player has changed their point of view. Thus, your plan can mostly work, but you cannot return to a player selected location.