MSDP (Mud Server Data Protocol)

[Cephirus]

Is this something that is implemented/available to us here?

From my understanding (and admittedly, I only just learned about it) this is something that can be quite useful, especially for expanding scripting and performing additional integrations with clients, to create additional plugin displays, automaps, etc.

Something that many MUDs are taking advantage of, providing QoL benefits, like those mentioned.

[Aidon]

Adding the protocol support is likely alot easier than building the cool QoL things on top though. These instructions are likely most of what is needed: https://github.com/g7138580/protocol_gmcp/blob/master/INSTALL_GMCP.txt

It (and GMCP, very similar) basically let your client have direct access to key information (current room, current health, exits, etc) which makes scripting much easier. 

The problem is alot of Muds support the protocol but people don't use it for this - they use it to cheat/bot the game. With direct I/O access to the game you could write some amazing bots. 

FL never really had this problem but alot of muds have players who run 90% of their char on autopilot very effectively, and most of those muds use one of these two protocols. 

Some cool examples of Mudlet integration using GMCP/MSDP because why not!

http://www.midnightsun2.org/img/screenshots/1-1_full.jpg

[Lexi]

Imagine FL with a fully functional mapper/speedwalker, caputuring room numbers off of 'where' etc. O_O

[Aidon]

26 minutes ago, Lexi said:

Imagine FL with a fully functional mapper/speedwalker, caputuring room numbers off of 'where' etc. O_O

See, this is my argument against MSDP/GMCP...anyone with enough motivation could create a speedwalker to put in any room and it would auto-walk there with no lag/delay. Its not really feasible to stop it from happening if the user can capture the vnum of every room and map them perfectly from the mud. Once someone builds the system once, they can speedwalk <temple vnum> and be at your pit near instantly. edit: Its actually way worse than this now that you mention it. If I had a log every room vnum, room name, and room exit, you could also easily build an auto-chase to take a where command and run to that room on autopilot...you could a complete auto-chasing system. 

[English lad]

Honestly in this day and age not having some sort of Out of Band transmission is so rare in Muds that I forget that FL never implemented it.  MSDP and GMCP both have their pros and cons, i've have better results with MSDP, but GMCP tends to have slightly better support in terms of snippets etc - mainly because it was developed by the guys at IRE.

 

8 hours ago, Aidon said:

See, this is my argument against MSDP/GMCP...anyone with enough motivation could create a speedwalker to put in any room and it would auto-walk there with no lag/delay. Its not really feasible to stop it from happening if the user can capture the vnum of every room and map them perfectly from the mud. Once someone builds the system once, they can speedwalk <temple vnum> and be at your pit near instantly. edit: Its actually way worse than this now that you mention it. If I had a log every room vnum, room name, and room exit, you could also easily build an auto-chase to take a where command and run to that room on autopilot...you could a complete auto-chasing system. 

90% of this is possible anyway without having OOB info, you can just capture it via triggers and screen fed info.  Mudlets built in auto-mapper would do what you are describing here, the only issue would be visual representation as a lot of FLs zones don't actually follow a logical grid (which is pretty poor building practice IMO), so it can get a bit confusing from that perspective.

OOB info in itself doesn't give you any inherent advantage, its just a QoL feature that allows you to run a better interaction for users.  What can give an advantage is if you put info into the OOB that isn't available in the normal display, like VNUMs in your example above, but you aren't forced to do that, you can configure what information is and isn't shared via the protocol.

 

 

[Saisha]

I used to have a game with gmcp and frankly, it made me lazy.  When gmcp did not work or something, I could not go anywhere because I stopped learning the land and routes and relied so heavily on it.  While it is a nice function, ultimately it makes game play too scripted and I would hate to see that with FL.  Part of the reason I love FL so much is because it is not automated!  It relies on your know how, your knowledge, not how good you are with coding.

[Gifnab]

You also wouldn't be walking laglessly/without delay, as there is built in movement lag. This movement lag is compounded by spells like paralyze and ghoul touch.

Auto-chasing systems sound great in theory, til you're losing because of one of them as your client inputs a stack of commands and you get bashlocked while those commands are firing.

[Enethier]

I already discussed the usage of this protocol is a scripting thread... But I sure as hell would not use it for walking around in FL. It might work in slower paced and less aggressive servers that rely on client input delay for basic command lag... But it's asking for a bash lock in FL. 

 

The most useful thing you could do with it, if the requisite information was provided, would be to create a perfect tick timer, affect timer, or other such tool. Doing things behind the scenes so the screen isn't flooded is neat.

[Cephirus]

What I envisioned, would be something based on your character's exploration. So you start off getting the map between the tri-cities and to relevant areas where you can starting farming, but otherwise it will only show you the common rooms you have explored in an area. You would still need to "know" secret doors and stuff. Ultimately my main interest is in tracking affects being applied and dropping. Especially on caster/communer classes, having a little side window I can glance at to verify what is up and what will be dropping soon would be a huge benefit.

[English lad]

On 5/6/2021 at 8:23 PM, Cephirus said:

What I envisioned, would be something based on your character's exploration. So you start off getting the map between the tri-cities and to relevant areas where you can starting farming, but otherwise it will only show you the common rooms you have explored in an area. You would still need to "know" secret doors and stuff. Ultimately my main interest is in tracking affects being applied and dropping. Especially on caster/ communer classes, having a little side window I can glance at to verify what is up and what will be dropping soon would be a huge benefit.

Like i said above - OOB info like MDSP / GMCP doesn't make this stuff for you - literally all it does is send information without it being on the screen.  You can make a side window right now and have it populate via the affects list, have it update via on screen messages for dispels, count down time via the Time in your prompt etc.

I never understand why people are against OOB info - i guess its just old school "change is bad" mentality.  OOB doesn't magically make these UI packs appear, it just makes it a bit easier to capture information.  If the information you want to display is sent by the game anyway In band (on screen) then you can make systems that do all this stuff, you just have to build slightly smarter Capture triggers.