[Suggestion] FoV in Mumble
draos.9574:
After this the camera will be changed including a configurable field of view. Some overlays like this and my own overlays need the field of view angles.
I suggest to add the field of view angle to the mumble interface. The identity field of the mumble interface or the context field can hold the value. I would prefer the context field because of the faster access but this will not be my decision.
Nabrok.9023:
You can’t change the context field. If you did, positional audio wouldn’t work unless you happened to have the same FoV setting.
Lawton Campbell.8517:
I would argue that the identity field is also the wrong place for it, but there’s literally no where else to put the data within the Mumble link API (somewhat related: does anyone know what the description field is used for? Can we co-opt that for additional machine-readable data? EDIT: looks like it’s used for the plugin description string, not really usable).
Can you explicitly lay out all the fields you need? Is it just FOV? The identity field is limited to something crazy small and I’m worried that we don’t have much of the 256B left.
draos.9574:
After the definition of the identity field in the mumble data the field can store 256 wchar_t which means 512 bytes. One fov angle should be enough because you can calculate the other one.
One other option could be to replace the JSON inside the identity for more data and simply memcpy the bytes into the identity field. This would create some problems with older programs but can store more data and could be faster to read and write.
Lawton Campbell.8517:
After the definition of the identity field in the mumble data the field can store 256 wchar_t which means 512 bytes.
That’s not really how it works. Yes, it’s 512 bytes, but with the current encoding that’s only enough for 256 JSON characters. We’re currently using about ~110 of them, and adding FOV would only cost up to an additional 30, so it’s not the end of the world.
One other option could be to replace the JSON inside the identity for more data and simply memcpy the bytes into the identity field. This would create some problems with older programs but can store more data and could be faster to read and write.
Yes, but at that point there’s no reason to use the Mumble link format since … it won’t really work with Mumble anymore. I’m fairly unwilling to break compatibility with existing programs — which is a bit of a nightmare since I’m currently not familiar with any that use this API.
In any case, I don’t see any better place to put it and really don’t foresee having a better interface for it. I’ll put a PR on Github for anyone to raise objections on, otherwise it’ll go in.
Remfin.4892:
Is there really a reason it needs to be in the Mumble data? Conceptually there’s nothing stopping you from making your own “MumbleLinkGW2Ext” memory-map for that kind of non-standard Mumble data…
I know it’s non-optimal, but if you’re really worried about breaking compatibility it’s an option. The primary reason for having it in the Mumble location (so it works in Mumble) has already been achieved with the data that’s there
Lawton Campbell.8517:
Is there really a reason it needs to be in the Mumble data? Conceptually there’s nothing stopping you from making your own “MumbleLinkGW2Ext” memory-map for that kind of non-standard Mumble data…
I know it’s non-optimal, but if you’re really worried about breaking compatibility it’s an option. The primary reason for having it in the Mumble location (so it works in Mumble) has already been achieved with the data that’s there
Conceptually, I completely agree with you. Practically, I don’t forsee adding enough additional functionality to warrant another transport that relays almost entirely the same data. If there’s reams of other fields that you’d like (and I can reasonably expose), then it’s definitely something to look into. But for just FOV it’s really hard to justify the expense, if you will.
The other important point is that, because the mumble link is an existing interface, a modification to it will arrive much sooner than a brand new largely untested one (though it’s more an issue of me being unfamiliar with the client codebase).
In any case, I’m open for debate on this, either here or on the corresponding Github issue.
aRestless.6213:
YES! I was about to ask the very same thing! Thank you for considering to put this in!
The only other thing I’d like to see in the Mumble data is a flag if the map is opened. Because… opening the map pretty much breaks every application that relies on the Mumble (camera) data.
Even more exciting would be to know the dimensions of the currently shown portion of the map while in map view or even on the mini map – but I think currently my own project would be the only one benefitting from that, so I don’t really think it’s worth the effort.
Edit: Oh there actually is something that’s missing in the Mumble position data, which is the current floor on the map. Unfortunately we can’t convert player position to floor through the web APIs.
Avatar of Furin.6814:
First off, putting in FOV will definitely help any overlays out there.
The only other thing I’d like to see in the Mumble data is a flag if the map is opened. Because… opening the map pretty much breaks every application that relies on the Mumble (camera) data.
I know the programmer who made the overlay mentioned in the first post, and I have done some minor overlay programming myself. I believe the above is not 100% necessary. I think we got around this problem by detecting the position of the camera, which actually goes into a height that is only obtainable by going into map view. So you can just detect the height of the camera and use that to see if the user has opened his map.
Even more exciting would be to know the dimensions of the currently shown portion of the map while in map view or even on the mini map – but I think currently my own project would be the only one benefitting from that, so I don’t really think it’s worth the effort.
Edit: Oh there actually is something that’s missing in the Mumble position data, which is the current floor on the map. Unfortunately we can’t convert player position to floor through the web APIs.
I agree with both of the above. We have so far been unable to do any kind of overlaying over the in-game map because we have no idea where on the map the user is focused, nor do we know how zoomed the user is. So to be able to overlay over the in-game map we would need to know the zoom level and relative position on the map the user is looking. Floor would also be extremely helpful.
aRestless.6213:
I think we got around this problem by detecting the position of the camera, which actually goes into a height that is only obtainable by going into map view.
Yep, that’s what I wanted to try for the next version of my overlay. But since you can zoom out pretty far at certain world bosses, I think height isn’t sufficient. It’s probably more a fixed position relative to the character and the direction the character is facing (when you’re coming out of map view the camera will always be facing to your character’s back). But without testing I don’t know how consistent that is if you’re moving while in map view, so…. yeah, I don’t know if a flag would actually be necessary, but it wouldn’t be bad either.
So to be able to overlay over the in-game map we would need to know the zoom level and relative position on the map the user is looking. Floor would also be extremely helpful.
I’m tracking the mouse (click, drag, mouse wheel) to accomplish this. And yes, it’s a mess.
draos.9574:
Yep, that’s what I wanted to try for the next version of my overlay. But since you can zoom out pretty far at certain world bosses, I think height isn’t sufficient. It’s probably more a fixed position relative to the character and the direction the character is facing (when you’re coming out of map view the camera will always be facing to your character’s back). But without testing I don’t know how consistent that is if you’re moving while in map view, so…. yeah, I don’t know if a flag would actually be necessary, but it wouldn’t be bad either.
You can do it maybe better. You can check the distance from camera to avatar and the y-coordinate of the camera front. If you are in the map, the y-coord is currently always 0.95 together with the distance between cam and avatar it will be work good.
Back to topic:
If you really want to include an external interface beside the mumble one, can you think about an offline version of the current /v2/account endpoint?
aRestless.6213:
You can do it maybe better. You can check the distance from camera to avatar and the y-coordinate of the camera front. If you are in the map, the y-coord is currently always 0.95 together with the distance between cam and avatar it will be work good.
Thanks! Might not hold with the new camera options though, so we probably got to wait for that patch.
aRestless.6213:
Sorry for two posts in a row, but I just noticed another thing that’s missing in the identity field, and that’s the race. The profession is already included, but the race is not.
Lawton Campbell.8517:
Sorry for two posts in a row, but I just noticed another thing that’s missing in the identity field, and that’s the race. The profession is already included, but the race is not.
Oof, that’s a good point. I’ll try to slip that in.