integration: list 4D on Mudlet's Default Profiles

[Rynald4d]

If we can get 4D on mudlet's default list this may generate a new influx of players. Mudlet requires certain things: https://wiki.mudlet.org/w/Listing_Your_MUD

[lfaoro]

requirements track:

• [x] telnet GA
• [ ] include GMCP addon: https://github.com/g7138580/protocol_gmcp/blob/master/INSTALL_GMCP.txt
• [ ] Mudlet Mapper implemented
• [ ] inclusion of Recall Area, Newbie areas and Olde Yorke in the Mapper by default
• [ ] include Tabbed chat in 4d_mudlet.pkg
• [ ] include tracking of player vitals in 4d_mudlet.pkg
• [ ] distribution of 4D Mudlet package automatically on connect

[Tocharaeh]

That's the only one we're missing, right?

[Rynald4d]

They also want their mapper to work: "Include a map of the newbie area at minimum. " I'm not sure what they mean by that, we need to supply a graphical map? We already supply player stats and the map through MSDP, mudlet can handle that data. "Lastly, ensure your scripts get installed, and stays updated, by utilising the GMCP extension Mudlet makes use of." I'm not sure if enabling GMCP covers this.

[lfaoro]

GMPC is enough to build a good mapper, what we need though is sending the VNUMs also to make rooms unique and have the mapper behave properly. I've pushed that change today.

[Rynald4d]

I think giving players vnums is too much info. I remember talking about this with Molly when I was working on MSDP. If you know the vnums it can interfere with some quests. For example mazes will be easy to map.

[lfaoro]

a player that can script can also map easily a maze, I don't see an issue with this

[lfaoro]

[Rynald4d]

How would a mapping script work?

[demonnic]

Ideally, the mapping script takes in the room name, its exits, and the vnum, and uses that information to create the room in Mudlet's map, with coordinates based on where you came from. Though if you provide coord. information via MSDP then that makes the mapper yet more accurate to your starting material.

The VNUMs are optional, you don't strictly -have- to send them. But if you do then you can have Mudlet's internal roomIDs match the vnums from the game, which provides a nice easy way for the mapping script to find you. You're at room X because that's what the vnum told us. This is largely how the gmcp mappers operate, and MSDP would be essentially the same. At least with MSDP even if you don't send the vnum you don't have to make triggers for things, you can definitely know the room name and exits.

We ask for a starting map (the newbie garden, so to speak) so that new players have something to kickstart making their own map. Don't necessarily want to give them the whole thing (though you certainly can) right out of the gate but having even just the tutorial area mapped is a much gentler starting point than an empty map file.

As for the GMCP for keeping a package up to date, we have worked around this in the past by having a bootstrapping package which downloads the latest version of your client package and installs it on first run, and you can have your package handle updating itself internally. There are a few different mechanisms various folks have used for that and I'd be happy to help you find the right one for you.

The primary thrust of the 'requirements' is that we're trying to promote the best new-player experience that we can, and have attempted to lay out what we feel that means because it's not fair to just throw around nebulous statements like "best new user experience" without elaborating.

Sorry for the short novel.

[Tocharaeh]

I think an easy fix would be to have a room flag MAZE added, and then set it up to not send room vnums from those rooms. This can help protect the integrity of the mazes per Molly's wish. Our mazes have always been one of those 4D special little hells/puzzles that are intended to be actively engaged rather than passively running around letting a map do the initial work for you.

Personally, I always enjoyed solving and mapping our maze puzzles.

[demonnic]

That sounds like a fine compromise. Or you could have it send the same vnum for every room in the maze and adapt the script on the mudlet end to send you to a placeholder "you are in a maze" room in the mudlet mapper for that one.

[lfaoro]

Molly's wishes and outdated thinking brought us to 4D's near death. If we really want to keep up with times and restore 4D's playerbase we need to make compromises on Molly's wishes.

Let's add the VNUM of the room to be sent via MSDP and think about the best experience for our players first, and second get on Mudlet's list of muds asap.

We can always add code to change the behavior of MSDP to send the same room VNUM for mazes later. For now let the VNUM be sent and allow @demonnic to help us create the Mudlet Mapper integration for 4D; which is a requirement to be listed on Mudlet's connection list.

[Rynald4d]

Without Molly 4D probably wouldn't have made it this far, especially with the quality it has. What is outdated about respecting the work of the builders? They have put in effort to make something hard to map. If we supply vnums no builder in their right mind will make a maze again.

Besides, @demonnic said it's not necessary for the mudlet integration, so why would we?

[lfaoro]

Makes mapping easier and guarantees the uniqueness of the room based on the roomID, avoiding bugs and errors. Generally a better experience for the user mapping the rooms.

[J00bei]

If it makes mazes easier I am totally against it. I think a simple graphic map is fine enough if you want a mapper, then make it the traditional way there is no need to have one that require vnums to work.

Also bit of a low blow talking about the builder that contributed the most to this place like that. She was holding the fort in all the years while it was a just a handful of players still providing us content.

[Tocharaeh]

I think it is important that we maintain the integrity of Molly's vision, and respect the hard work she put into it. I don't think any one of us could ever hold a candle to her brilliant flame, honestly. Let's make sure we're giving her the proper respect, even if she is retired.

I don't think she was behind pbase life here.

Anyway, we need to be sure that the regular joe does not have access to the vnums. get mudlet what it needs to get us on the board, but we need to prevent the possibility of abuse. Few worlds out there have our quest system, and I'm worried about the possibility of abuse. Particularly the maze-side of things.

[demonnic]

I'm definitely not trying to cause any strife or drama, just trying to present what having it available gets you so you can make the decision.

[lfaoro]

@Tocharaeh @Rynald4d @loran4d what's the final decision, can we make VNUMs available for mapping or not?

@demonnic what's the main disadvantage of not having the VNUMs being passed to the mapper? Would you still be willing to help us create the Mapper and help get 4D listed on Mudlet?

[demonnic]

The mapper is a bit more likely to get lost in general usage, and sharing of maps between players becomes more difficult since everyone will have different roomIDs in their version of the map depending what order they mapped things in. Some of the IRE games have a 'crowdmap' which is maintained by the community and synced to the users who don't want to do all the mapping of new areas and such themselves.

I'm 100% willing to help whether vnums are exposed or not. They make things easier and more accurate but are not strictly necessary. In fact, without them you could pretty easily wire up msdp events to the standard generic mapper script, see https://wiki.mudlet.org/w/Generic_Mapper_Additions#Avatar_Mud for an example which does so with gmcp.

[lfaoro]

thank you @demonnic, I consider your points outline a very valid reason to use vnums and improve our users experience with guaranteed map accuracy and sharing.

@all could we please agree to let the vnums be sent to the mapper? if dungeons are the main blocker, we can add a check that when the room is flagged as MAZE we submit a fixed vnum number.

what do you think?

[Rynald4d]

Adding a maze roomflag isn't the solution, someone will have to go through 25k+ rooms to set them.

I'm surprised most muds give out room vnums, maybe it's because we rely heavily on quests.

I tried to check our plugin for mudlet, but I'm having start up problems. Can anyone comment how the mapper works with the plugin?

[demonnic]

I don't have nearly enough hard data to make claims like 'most' games provide vnums. Several of the ones with gmcp or similar protocols implemented do, but I've not actually collected or correlated that data to where I'd be comfortable saying authoritatively what the trends really are.

If providing that information is detrimental to your game or a whole bunch of work nobody has time to do then including vnums may not be your best choice. you can always add it later but if you make it available taking it away again will be tough.

[lfaoro]

Based on the current status of our game, I don't believe any feature that improves the user experience could be detrimental. I don't understand this fixation on not exposing the room vnums. No matter if the vnums are exposed or not, I can script my way through any 4D dungeon in minutes, as can any other player.

Seems the idea here is: don't expose the room vnums to make "mazes" more difficult to solve, when in actuality anyone can easily solve any maze in 4D pretty fast with a couple of scripts, and b/c of this we choose to add incongruence and errors to the mapper and deny map sharing. Doesn't seem like a reasonable tradeoff.

[Rynald4d]

When a builder makes a maze, they do it so you have to spend time to map it. If you're given a map then you don't have to make it yourself anymore. Think of it like a hard quest: it takes time to solve it, if someone gives you the solution then it's not so hard anymore. It doesn't matter how fast you can solve mazes yourself, it's everyone else we're thinking of.

[lfaoro]

I understand.

[Tocharaeh]

Do we have a status report on the progress? Have we decided to start without sending vnums, as Demonic said it was not wholly necessary to include them, and then go from there?

[Tocharaeh]

I've been playing with this mapper, and it is honestly a really intelligent program. It found a loop immediately before I was even able to manually set one. It's legit better than the oldschool zmud mappers, in that regard. I'm still exploring all of the functions (they are pretty limited, from what I can see).

Here is the point:

I'm going through an area/maze I've not gone through in a decade at least. Because of that, I'm still worried about DTs, or random time-rift rooms. I would like to think I am un-biased in my active observations, and I'm habitually a long thinker as I like to consider various implications and so on. Honestly, I don't know if sending vnums to the client for the mapper. The mapper is already sophisticated enough to recognize unique descriptions.

I went through a maze on my IMM, with the roomflags on, to see how the mapper would respond to the room vnums. This is the result of the maze below the Deathstar:

I don't see the mapper being sent vnums as an issue at this point. I would need Demon to clarify further on this, but the mapper certainly could not adjust, and saw plenty of new rooms that were simply loops.

[demonnic]

If you have gmcp or msdp to tell the mapper things like the room name and exits definitively then the generic mapper definitely works better than if it's trying to detect it based on the "best guess" triggers and lua patterns we include by default.

If you make sure you have all the "you couldn't move that way" or "you were stopped moving" triggers set up that also greatly helps. These are the things which are left to maybe trip you up with your current msdp+generic mapper setup, as those are what will make it get off track. If you try to go west, but are stopped and nothing tells the mapper that, then it will still use west for the next move, even if you go north. Which leads to compounding errors.

If you get that squared away, you'll have conquered most of the usual speed bumps in the mapper arena. Just make sure the scripts and triggers for that are kept outside of the generic mapper folders themselves, so when the mapper updates the changes aren't lost.

Including them with your base UI package is likely to be the best place.

If I've missed something you'd like me to touch on, or there's something you'd like further elaboration on, let me know =)

[Rynald4d]

@Tocharaeh : the problem with room vnums and mazes is that a vnum identifies a room, which means you don't have to map it yourself. I don't understand why the mapper was having trouble with it, it's too bad I still can't test it myself.

From @demonnic 's explanation I take that with our current msdp implementation mapping normal areas shouldn't be a problem. On mudlet's site it asks if we implement gmcp as well, is this necessary? I wouldn't mind doing it though if it gives new options.

[demonnic]

gmcp is not strictly necessary, especially as you seem to have a lot of that stuff exposed via msdp already. Implementing gmcp would allow your game to easily tell Mudlet where to download your UI, and automatically update it via the same mechanism, but that's the main thing it would gain you over your existing msdp, apart from another way to consume that information. If you don't implement gmcp, what we would do is include a snippet in the base profile which would include a way to download the latest version of your game's package. And ideally that package will include a way of updating itself once installed =)

So there's something to be gained from it, but it's by no means mandatory for you.

[Rynald4d]

We offer our mudlet package through atcp. When I tried it, it seemed to install automatically out of the box. I couldn't see it fully because i'm missing some libs, but i suppose this is enough for the package handling part?

[demonnic]

wow, atcp... I haven't heard that acronym in some time. If it's installing the package automatically then that's all that's needed, yeah =)