Nekres.1943

This is a suggestion to add a hold key bind for "walking". This could be used to setup low, medium and high pressure zones on joysticks that are set to map onto the specified walk key bind (hold). Currently, mapping a single stroke of the walking key will make it desynchronize with the walk mode very quickly (meaning you suddenly start walking when giving the highest pressure on the joystick) With a "Walking (Hold)" keybinding we could have the Low Pressure Zone of a stick to press and hold the key and when transitioning to a higher pressure zone it would release said key without ever getting out of think with the walk mode of the game. This would make it more immersive when using controller with the Action Camera.

Thanks for doing this. My birthday is at the end of october 😛 Number: 28 IGN: Nekres

Special Forces Module Preview: https://gfycat.com/InbornMediocreFlyingfish www.blishhud.com

Any news on this? Is this feasible? continentId, regionId, mapId, floorId, sectorId, Victory, Downed, Defeated, MainMenu (see first post), BossBattle especially helpful for overlays are in bold.

Haha I knew it. Hopefully my suggestion about adding a holdable walk keybinding doesn't go under.

I edited it for clarity. I meant holding the key enters walks mode. Releasing the key exits it. We only have a binding where a single "press & release" enters walk mode and another "press & release" exits it which makes it hard for joysticks to utilize it via pressure zones.

This is a suggestion to add a hold key bind for "walking". This could be used to setup low, medium and high pressure zones on joysticks that are set to map onto the specified walk key bind (hold). Low pressure would hold the specified walk key while medium or high zone releases it. I've tried pressing the key two times.First on low pressure (after exiting the sticks dead zone) to enter walk mode and then again when entering the medium pressure zone to exit walk mode. This works only to some degree and breaks easily. One reason for that is that the controller doesn't know about the previous walk state. It would be cool to have a immediate toggle (hold for walk, release for run normally) just like action camera already has two bindings one of which toggles as long as you hold the key. This would make it even more immersive when using controller.

It's true that it's soothening any existential dread. Although it has a lonely characteristic which it shouldn't have considering its accessibility.It's an opportunity for any butt passing the central well area.I rate the "staring into the void"-bench 5/10

Hello anet, sometimes the only bench with a look toward the mists is occupied and my character cannot properly rest from battle. Can you please place more benchs. For example, another bench in this perfectly suited area?https://i.imgur.com/ZrFATeB.jpeg (Please, do not let the bench face the waterfall when characters sit on it. Make it face the walkway. In the picture the direction my char is facing. ) Rarely a bench should face outward (into the void of mists). It looks better placed inward facing the walkways and fire places. Just look at parks in your local area. I don't understand why the single bench near the bank faces off the cliff into the void when there is a fireplace and a talk area to face to. Consider adapting a more immersive butt resting philosophy. Thank you very much. Our worn warrior butts greatly appreciate,Best Regards

Floor ids are completely arbitrary and differ per map. Current floor detection is impossible and thus current sector detection BREAKS on maps with sectors lying ontop of each other.Another thing mentioned is reducing overall queries to said endpoint. Given sector id directly would also improve it as you don't have to query for floor to get the current sector (if given floor id). For said endpoint it makes sense to just throw all four ids in there, especially floor. ExampleSector detection on a flat map: https://gfycat.com/CompetentReadyGilamonsterThis would not work flawlessly on - for example - Verdant Brink with sectors being ontop of each other as there is no way of calculating a floor. Floor is the most important out of the four but because it makes little sense to not include all four while we are at it(!) I listed them all four. This would give us the complete hierarchy of IDs of a maps context from biggest to smallest. continent > region > map > floor > sector. Perfectly suited for any of said complex subresources of the continents endpoint such as:https://api.guildwars2.com/v2/continents/<continentId>/floors/<floorId>/regions/<regionId>/maps/<mapId>/sectors?ids=allhttps://api.guildwars2.com/v2/continents/1/floors/1/regions/4/maps/15/sectors?ids=all And little extra weight on the overall size of Mumble Link since we are only dealing with those ids.

Dear ArenaNet, I would like to request specific information exposed via the Mumble Link API. I know that we already use a lot of space in there but as discussed there is still much room for more information in the extended context.Previously I requested some states from the customized soundtrack system (Ref.: https://wiki.guildwars2.com/wiki/Customized_soundtrack ) to be exposed that would help with seamless overlay development and popular marker and path helper tools: Victory ~Downed $Defeated ~$MainMenu ~ - Possible by setting the value on detecting a log-out event and before mumble goes inactive. Aknowledged limitation: Has to go from in-game to MainMenu..BossBattle ~~ = As seen used by the customized soundtrack system.$ = A well known and highly popular (and tolerated) third party addon exposes it already for other developers to use. I would like to still expand on that with information that would improve readability of the continents API endpoint and its very complex subresources. Ref.: https://wiki.guildwars2.com/wiki/API:2/continents The information I would like to see are ids relevant to the map id that is already exposed: continentIdregionIdfloorIdsectorIdMost importantly I'd like to explain why I would want the floor id. Floor ids are arbitrary values that do not just depend on height of the player and differ per map (i.e. floor 1 on Queensdale can be different compared to floor 1 on another map.). They cannot be calculated and it makes it difficult to distinguish between sectors given the subresource found under the continents endpoint and impossible on non-flat maps for the reasons explained earlier.Knowing the sector could save resources and performance for marker and path systems and augmented stuff. On the other hand giving the sector id directly would reduce queries as one does not need to query the floors first to get a specific sector object. Same goes for the continent id.So because there aren't many more sizes to a maps context (continent > region > map> floor > sector) I request that you consider - if you look at the complexity of the "continents" subendpoints - that it makes sense to just expose all four of above ids - while we are at exposing the most important of them that is floor - to improve access to the very complex continents endpoint. Furthermore, it was stated that the API nor MumbleLink exposes enough data to detect the current floor which means that the continents endpoint and a large portion of its data contained in subresources is in fact useless for augmented overlay developers that rely on MumbleLink. A pity because it would open up huge space for improvements in regards to performance and resource handling.Ref.: https://github.com/arenanet/api-cdi/pull/2 (Highlighted statement: https://i.imgur.com/nAdaOSD.png) Thank you. Best Regards,Nekres

Reference: https://discord.com/channels/384735285197537290/694129718689005619/770584808287633408 (GW2 Development Community) We had a bit of a discussion on the discord. For context here's the stance from Jonagar It is a valid point but with a bitter twist. It implies the assumption that we would want more detailed solutions in mumble link if we get even a glimbse of this. "If we have X, why don't we have Y from the same category as well?" It feels like it doesn't consider that we third party developers do not love the game. I can tell you that the majority does not want it to be ruined. We know that any more detail than for example a Bit for IsAlive could make it easy and therefore give incentive for a bad script kiddy to create a malicious program. I know the boundaries of requests. It's difficult for me to phrase it better so please let me try to clarify further as I am not native.What I am trying to say is that the benefits of having just a Bit for IsAlive far outweighs the risk the argument implies would be created. I already have several use cases.For example: Make Overlay disappear. There are many overlays out there. TacO is one of them. In BlishHUD we create immersive User-Interface elements that look and feel like GW2 elements. As seen in the following gif I am unable to make permanent custom UI elements disappear with the game's UI elements when dying which breaks the immersion. (BlishHUD and TacO - the most popular overlays that exist - add immersive icons to the top left array of menu icons)https://gfycat.com/UnfortunateTightIlladopsisContextual music on dead status. I am currently working on a bugfree and improved version of the contextual music with the ability to load the audio tracks from youtube links. https://www.twitch.tv/videos/814045340Marker pack creators for the highly popular Markers and Paths feature from TacO or BlishHUD could make use of the Bit to toggle, hide or reset depending on the Bit. Especially good for marker packs related to events and bosses. roleplay for 3D voice audio. Ability to mute when dead. These are just some off the top of my head.I hope we can get this bit. Thanks for coming to my TED talk,Nekres

Also, it's ending 00:00 CEST 25th.. with a fire work. ..tfw.. the 25th is my birthday.

50 - Nekres

Suggestion: There is little use in hiding the menu strip in/out off combat dynamically.I would prefer a "Show on mouse hover" option for those tiny UI elements and / or chat. It may be worth artifically adding to the element boundaries in the calculation so that it actually begins to fade in when the cursor is approaching. Dunno, might need testing.