Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

• linux: https://make.mudlet.org/snapshots/1aacf5/Mudlet-4.19.1-testing-pr7940-805baa6d-linux-x64.AppImage.tar (commit 805baa6)
• osx intel: https://make.mudlet.org/snapshots/d0cc3e/Mudlet-4.19.1-testing-pr7940-805baa6d-x86_64.dmg (commit 805baa6)
• osx arm: https://make.mudlet.org/snapshots/d47746/Mudlet-4.19.1-testing-pr7940-805baa6d-arm64.dmg (commit 805baa6)
• windows 64 bit: https://make.mudlet.org/snapshots/d0a749/Mudlet-4.19.1-testing-pr7940-805baa6d-windows-64.zip (commit 805baa6)
  No need to install anything - just unzip and run.
  Let us know if it works well, and if it doesn't, please give details.

I would make use of this. While people like MXP functionality, often people turn it off because it is too loud visually in the text world. That is from player feedback. For me, I may try default color, but italics, to see how that looks.

Due to Mac and PR build issues, I am not able to load this on my own, so if you have screen prints of how this looks in the Settings menu it would be good to see them in the comments or dropped into the PR description to follow along.

-Tamarindo

Could I have access to this feedback? I haven't seen the same requests myself while playing on some of the bigger games out there - and as far as I know, the link behaviour is pretty much the same across all clients.

I'm coming at this from a point that - counterintuitively, more options is not a good thing. What you want instead is good, reasonable defaults that "just work" for most folks. You can't please everyone, unfortunately, but that can't be the goal either.

I’ll share some pics or a video later!

I agree that in some cases, the default option should always be solid — the "no-need-to-configure default" that people get used to. The issue here is that underline might not be the best default (in my opinion), but it’s been the default for too many years now.

We’re starting to add more MXP usage, and that’s become a thing with players. It feels rigid, and underlines everywhere — like for exits, lists, room interactions (e.g. kill the mob, ask the questman, grab the object, etc.) — can be overwhelming.

When you use hyperlinks to enhance player experience, especially for touch-based gameplay, you want to add things. As I mentioned, things like hotkeys to trigger those links are great. But for some players who are used to more traditional output, too many underlines can feel cluttered. With the new functions setHyperlinkStyle()/setHyperlinkStyleColor() ; , you could decide make "link" exits show up in bold blue, the “kill” actions underlined or italic — whatever works for you, or just one default that you like. You could even bind a key to toggle them. After a few times, the player just knows there's something clickable there.

From Mud side, I’m aiming to create 3–6 “doable” link/hotkey actions in a room — basically:
1 click / 1 touch / 1 hotkey… maybe even voice commands someday? I think links have an important role to play in making gameplay more comfortable — in a way that aliases or macros can’t fully cover. You want to define, within the MUD, what the shortcut or clickable does, and tailor it to the context.

And the touch use-case isn’t just for mobile — I had a player tell me they love "links" because they use a 15” touchscreen portable monitor. On the other hand, some hate the link saturation and all the underlines, haha.

Sorry for the long comment — got carried away 😅

Thanks for the context, so you are a game that is stepping into MXP adoption. Would it make more sense then to be able to control this from the game side and put together a good, comprehensive design that works - rather than offloading the work onto the players?

Think CSS in the web, where you can control the links as the content creator. While technically you can use CSS clientside as well, experience shows that hardly anyone uses this.

Not only will this work better out of the box for your playerbase, but this will potentially work in other clients too! I am thinking that the OSC8 spec could be extended with formatting, then support for that in Mudlet could be added, and it would be a much bigger win for the MUD community than just 1 client offering per-player customisation.

Oohh yes this is not only MXP, thats why i put the hyperlink tag thing. but the read (yor kde link) applies for this too.... if you overwhelm the player and mud-side in customize the things via: (one link for accessible mode, one link for "exits_link_on mode", one link avialable for mobile-mode, and all that ... then the not mobiel players wants the link too because..he just wants jaja... i think u need to offer some default thing that its there for everyone and its good, not overwhelming, and had some configs if someone want customize a lil...

Oh, indeed about your suggestion i dont put MxP links in the mud.. i do a thing that called "mudlinks", can share more if someone wants, so depends it's mudlet or zmud that go for mxp or a webclient that has osc8 but not mxp sends osc8 or mxp, or the next thing coming ... that could filter in sometime if its a player in mode accesible or not maybe... dont know yet.. but the idea is offer one default thing available for everyone, and has some lil setup options.. well zmud and cmud can deactivate the underline for example.
I'm not a fan of mxp by the way at all, jajaj but the "do things" shortcut via click, hotkey, is what i see useful..

So coming back, im thinking this might be not for Mxp only. Just Mud side sended links, with a common client default set, an user choice set if the user want and the option if he really loves more customization to make some "in case this adjust" via trigger/script etc.

But, anyways its a try thing, i will send images later, i believe is a plus that dont hurts and add a lil value in player experience.

3 samples of list with links:
A) mud-provided color and underline default
B) italic+ blue type
3) 3 list in an iamge: current not optional, underliline disable nocolor, italic+color (custom by user)

I added OSC8 style hyperlinks (but not mxp ones) into my game and the immediate feedback from the players was that there was way too much linkified text being auto-styled into underlined text, and the visual clutter was too distracting. I ended up having to scale back my link adding project and provide an off switch for it, because neither of the two main clients in use allowed players or the game to style the links in a non-distracting way.

My experience with terminal clients has been that link styling behavior is not always consistent.

• Some terminals will only style the linked text when it is being hovered over, for example. In clients like that, it doesn't matter if you linkify a large chunk of text because until it is hovered, it has no extra style calling attention to it. In that case, it is preferable to linkify longer passages of text, because doing so provides a larger touch target for the user without adding distraction. The downside to the hover scheme is that touch devices don't usually have a hover function to discover links without clicking on them. Discovery has to be through server provided context.

• Other terminals will auto-underline linked text all the time, hovered or not. On those, the extra "look at me, I'm clickable!" styling is ok when the density of links is very sparse, but it quickly turns into a noisy mess of underlines when there is a lot linked text. On clients with this behavior, it becomes preferable to linkify the smallest amount of text, to avoid drowning out the non-clickable parts. That has the side effect of making links smaller targets to hit, even though they are more immediately identifiable because they are always visible.

• The xterm.js terminal component provides the first method (configurable style on hover) for implicit links, but unfortunately only allows the second method of non-configurable, always-on wavy underline for OSC8 links. There is an open discussion on xterm.js github about this for anyone who wants to weigh in.

My personal preference is to auto-style linked text only when it is being hovered, and not auto-style it otherwise. If a terminal is capable of displaying an OSC8 link from the server, it is also capable of displaying static styling sent from the server. There's no easy way for a server to change the styling on a hover, so leave that to the terminal client.

But, I can understand why a user might want to have more control over link auto-styling, even if it is just a 'link styles always on / link style on hover only / link styles off' selector.

Thanks for the input, @RahjIII. It looks like the discussion in xterm.js aligns with what I mentioned earlier #7940 (comment) - the desire to be able to style the links server-side, which I'm all for.