Since Terminal is just a collection of basic properties, it seems extremely unlikely that having an extra ITerminal abstraction is making anything easier even for mocking/testing. (We removed a lot of other unhelpful interfaces some time ago and seems we just missed this one.) Replace ITerminal usages with the concrete class name.

Further, the class name Terminal makes it sound like it is doing something. Rename this (perhaps to TerminalOptions) while we are at it, to better describe what it holds.

Logging in, quitting, and logging in immediately again can result in two versions of the player being loaded. We need the login system to search for matching players from the PlayerManager first before trying to load the player from the document DB.

Similarly for logging in to a new terminal while the player is already connected; the old terminal is disconnected but we end up with a second copy of the player Thing in the world.

@duaneking adds: "On login, check for prior session and attach to it if it exists?"
Indeed, a viable approach.

Add an app.config setting like "FirstCreatedCharacterIsAdmin" which is true by default. (Normally a new admin will be the first to create a character, before the MUD is even live.) This will make it easier to ensure the MUD starts with a valid administrator. The messaging around granting the role should be loud and clear during login prompt and/or character completion. (It should be easy to disable this setting, if a MUD admin would prefer to have to go straight in to the DB to assign the role manually where needed, for example, if a live MUD absolutely has to reset all player data for some reason.)

(For reference, Player roles have recently been restored as a single SecurityRoles flags-based property persisting with the UserControlledBehavior. Role granting/revoking commands are restored as well.)

The // <summary> at the file headers is not as useful to IntelliSense and similar systems as when the comment is attached to the class. Since each file should generally not have multiple classes anyway in our code base, we should finish moving these summary comments to be attached to the actual classes and such instead of the file header.

Performing a search for // <summary> may be helpful to identify which ones still occur at the file header (around line 6). When both have a summary, the useful information should be merged into the class summary so the file header summary can be safely deleted.

I think there's only a few of these left.

Oh look I did this for you, invited you to the org, and there is now pull requests waiting for your approval :)

It's not always obvious where the data for the MUD instance is held. It would help to auto-generate an obvious shortcut from the running bin dir to the GameConfiguration.DataStoragePath where we store the databases.

Looks like the client isn't authenticating after receiving welcome. Possible OS X issue.

When attempting to use the View command with multi-word talent names, an error is returned.

Since this is a specific case for character creation we might not need some sort of delimiter like quotes and could simple look for a string.Contains type of thing. Unless this command is used elsewhere in the code then a more robust solution would make sense.

Anyone have any thoughts or input on the more general case if needed?

Hey Dave,

I wanted to get back into this project and wanted to know which repo I should fork: yours or the WheelMUD one? Yours seems to be further ahead and there's no easy way to contact you so I hope this gets there.

Thanks,
Jeremy

Currently some enums use pretty large numbers. Especially WearLocations using things like "1073741824" it's really hard to tell at a glance if there's a mistake in there setting multiple bits, etc.
We should either use the shifting pattern like = (1 << 9) or perhaps at least use a hex form like = 0x0200 which are both easier to reconcile for such issues.

To address this ticket:

• Reconcile all our enums to ensure we are using [Flags] where appropriate.
• Ensure all [Flags] enums are using a single consistent approach that is not such massive integers.

Currently when GameActions are exported, we have to also attach a bunch of metadata attributes to them to make them usable. e.g.

[ExportGameAction]
[ActionPrimaryAlias("clone", CommandCategory.Admin)]
[ActionDescription("Clones an object.")]
[ActionSecurity(SecurityRole.fullAdmin)]
public class Clone : GameAction

It is too easy to forget to add some of the metadata that is required for an action to function properly. Every action needs careful consideration of supported aliases and such to even be usable.
The action creator should also be required to provide a helpful starting description and security level, and so on. These things could be required as members when defining a class that derives from GameAction, making the only part we have to remember to add for metadata be the ExportGameAction attribute.

IIRC one of the reasons we used metadata to start with was brevity, but latest C# syntax makes it easy to one-line properties with hard-coded values now anyway. Also, an individual game admin will eventually still be able to customize commands without touching the Core code, by inheriting from the base command and overriding the values they want to override (while exporting their own version with a higher priority, once we respect a priority level on the ExportGameAction attribute via #62).

@duaneking adds:

I would like to see attributes removed from the system so that we can do more dependency injection anyway.
I think Attributes are great for some things but not for full export-import of game world data.

Sometimes a MUD may reach a state where the live instance has crashing issues that need to be directly investigated, due to failing reproduction attempt on the dev's local instance. At these times, it may be helpful to have a way to launch the MUD in a state where it won't allow any non-local-IP connections.

One way to solve this would be as follows:

• Add an app.config flag like AllowOnlyLocalConnections.
• In the console output, this mode could also print warning output confirming that it is launching in this mode.
• The admin console could further have a new command like ACCEPT-REMOTE-CONNECTIONS which would put the game back into a state of accepting remote connections again. E.G. if the dev needed some time to attach a debugger or whatnot before letting players connect (as it may be the malicious act of a connecting actor causing the crashes), they could use this approach. Or if they just want to work on the game locally, but occasionally test with connections from a remote machine, this could be an option to protect from random connections. Etc.
• Document the option in the advanced setup documentations.

In the new DataFormatter, we have a more efficient output processing that handles prompts and such better too, but at least one bug remains. Output for mixed spaces and color codes is generating extra spaces. We should solve this. However, changing these algorithms can easily cause regressions for other working scenarios. We need to first write a bunch of unit tests for DataFormatter to preserve the cases that are working well, then write a unit test for the problematic case, then solve the problematic case.

The problematic case is exposed by the DefaultPerceivedRoomRenderer's exits output. It is printing like:
[space][space]Routes:[space][space]east (where east is color-coded)
but it should be printing like:
[space][space]Routes:[space]east

We should consider moving WRM to its own repository since it isn't actually WheelMUD but an example. We could add a example/addon repository where they can download it and others.

Make a lightweight Splash Screen class to put each splash screen in, and start with representing each one's output as string[] to imply the <%nl%> that will be added when turning that data into an actual splash screen? Might feel cleaner and would pave the way for us to store other calculated metadata about them (like their maximum line width to render without splitting lines, so we could make an informed decision about which splash screens to choose from for a given client's limitations).

When creating and naming a new character, it is currently possible to choose a name like "new" which will not be possible to load, because typing "new" at login will try to make a new character instead. We should not allow "new" to be chosen as a character name.

For the scope of this ticket, in addition to the blocking it already does for duplicate character names and the like: I think we should start with a hard-coded block-list of, say, ["new", "character", "name", "quit"] in GetNameState, as well as blocking the name if it matches any registered Actions primary/secondary alias.

We can track additional ideas for good automatic name blocking here, although many may be best to save for later. When we're done with the first pass, we can move these ideas to a new ticket or discussion thread to track for later. E.G.

• Having world start-up build a name ban list from all the mobile/object keywords that exist for the world so far, to help block players named like "goblin", "sword", and so on to interfere with the targeting commands of other players, etc.
• Perhaps allow admins to log new banned names from in-game commands, that get saved to a simple DB list and get loaded at server start-up into the banned list too.
• v1.1+ Perhaps an old-character archiving process might also put the char name into another simple name list, so archived players attempting to return can get a custom message that their characters have been archived (and get told how to ask for archive restoration).

Initially we used StyleCop for style enforcement, but now we are on VS 2019... VS 2019 apparently supports a good amount of this stuff out-of-the-box now. We should consider standardizing on some set of rules supported by default by VS 2019, and removing StyleCop related files.
https://docs.microsoft.com/en-us/visualstudio/ide/code-styles-and-quick-actions?view=vs-2019

When updating this, also remember to update the documentation on this.

Right now when executing a command that throws an exception, CommandProcessor's TryExecuteAction will:

• Print a lot of details in Debug builds directly to the player, and...
• Print minimal details directly to the player in Release builds.

Instead we should:

• Always print a lot of details to the server log (e.g. as printed in the console when server is running in console mode).
• Print a lot of details to the issuing player, if the issuing player has admin privileges. (Regardless of Debug/Release mode), else...
• Print minimal details to the issuing player, if the issuing player does not have admin privileges.

These core scenarios should also be unit tested to help protect from regressions; failing Action code should continue to just fail the Action and avoid bringing down the whole server. (Could be filed as a separate issue after code completion.)

The old CodePlex forums contents have been saved there. I have the newer forums contents preserved and ready to migrate to muds.gamedev.com as well; just need to wrap up some minor conversion details and pull the trigger.

We have a list of some of the better design articles/discussions we had from past archived discussion boards, that would serve as a good high-priority migrate-to-GitHub list. I don't think they were all formatted with the nice User Stories approach so some may be easier to migrate than others.

DESIGN ARTICLES:
Weight, Volume...?
Quests
Bounty System
Grouping User Story
Trading User Story
Non-Killing XP ?
Item Properties and Behaviors
Non-Reboot Code Updates
Flashback
Socials
"Commands" command
Weapon Combat - Real Time
Stacking / Non-Stacking
part of "Mob Attributes" ?
Control and Relinquish.
Converse Mode
Board, Note, Scribe
OnLine world Creation (OLC)
Everything as a Behavior
Sensory Messages

Figured out how to render a GitHub file as HTML, E.G.:
http://htmlpreview.github.io/?https://github.com/DavidRieman/WheelMUD/blob/master/Documentation/Design/UserStory_WorldInteraction.htm

So HTML is a viable documentation medium, where appropriate for advanced formatting, as we can link things like World Interaction User Story with a full [text](URL) link.

(GitHub doesn't support coloring markdown.)

A pattern emerging with the Renderers and such is to have things be composed with a priority system, such that a game system or custom plugin or a particular admin's customization or the like can be "dropped in" as a replacement for a Core default system, without modifying Core source at all. We should bring this pattern to Actions, to take not just the "most recent" binary with a given action, but to first sort by a Priority number from the exports, so we end up composing (or re-composing at runtime) the most recent of the highest priority version of each named Action. (This should still be compatible with extending new Actions into the system as well.)

@duaneking adds: "This will require interfaces and standardization of the world schema."

Currently the Glance command uses direct analysis of just the current room to come up with the output. Ideally:

• The Glance command should be using helper methods to figure out if the user is targeting the room ("glance" or perhaps "glance room" or "glance at room") or an object (like "glance sword" or "glance at sword").
• It should probably use the same extensible Renderer system as look/examine. E.G. perhaps in addition to PerceivedThingRenderers / PerceivedRoomRenderers, we can add another classification like GlancedThingRenderers / GlancedRoomRenderers.

After the above, follow up:

• Need to think more about how our Thing Name, FullName, Title, KeyWords, and Description properties are used. This may require further discussion / planning / streamlining / documenting: Open discussions or tickets as necessary to line up next improvements. Then we can close this ticket.

(Support administrative option to allow multiple Player Characters to be attached to one User Login Account.)

An administrator should be able to make a number of large functional choices while setting up a new MUD, with simple configuration choices, say, in the app.config. The advanced setup markdown files should describe this process, but we should be careful not to make it seem like required setup; an evaluating admin or developer should be able to "F5" jump-in with no code or configuration changes required up front.

For this feature specifically, we should have an app configuration setting which makes it easy to toggle between two login modes, for AllowOnlyOnePlayerPerUser (true or false). This can be set to true to start, allowing the faster user and player creation process that the majority of existing MUDs utilize: that the login ID they use is also automatically their unique player name.

The alternative (false) setting should mean that the user ID does not have to be the same as their player name. Once they've established their username and passwords, the character creation process is something that occurs separately. We maintain a list of players belonging to that user, and the user gets to select which character they want to log in with. When they quit with that character, we can also back the user out to that character selection state, where they can choose to further disconnect, select to go back in game with a different character, or create another new character.

We basically just need to make using the default 1:1 mode be a degenerate case of the 1:many mode, where we automatically push you into character creation with a character name that matches the user name you selected, and the flag is checked to alter behavior at other times like using the in-game quit command, as appropriate. Thus, the 1:1 mode would store a relational table of User data, and also a relational table of "character IDs (and names?) which belong to a given User ID".

Update: The first part of this (better separating the notions of User data from Player Character data) is done. We also have the UserAccountIsPlayerCharacter flag in app.config, but IIRC we still only fully support the 1:1 username-is-also-player-character-name mode, so far. But it's a start.

The Examine and Look actions do almost the same thing. Compare the strengths of each one (such as usage of Sensory system, target searching, argument handling, and guards), and combine them into one command with both their strengths and a combined set of ActionAliases, then delete the extra file.

@duaneking adds:

I think the issue equates to the strength in the perception being used.
Glancing at something and investigating it intently are the same action with different levels of effort.

Although I can see some specific game system wanting there to be some difference (like one costing more stamina cost or something for a chance to find hidden stuff or something), I think the default Core version would be sufficient to assume that players just want the best possible result between the two. Although there is indeed a difference in meaning, it seems they do show up as "similar" on synonym lists. I do see a use case though for "glancing at something" as a way to ask "just give me a high level overview I can read quicker, with key notes like exit directions" and for that I have seen "glance" used as a command. WheeMUD does also have a glance command that I think is intended to work that way, but probably needs work to use the same Renderer system as other similar commands. (Filed #45 for that.)

Ultimately, I think by default we don't want to impose on builders to provide a short, medium, and long description for everything they build. But I think a short and long description should cover us pretty well for a Core experience, and might be pretty obvious when each of the two would get used. Thoughts?

We can hope that any programmed additions to the functionality of a command would also result in a diligent update to "help" contents of that command, and that any upgraded code you take for an improved version of a command would similarly cause you to fix the associated "help" content with that command. In another light, such help content updates should occur in the same PR as an update to the command functionality itself. The reality is that these things will not often happen, if the help content is not something the coder is running into while updating the command code itself. In short, the command help content needs to be intricately linked to the source code itself, especially since we are not supporting localization at this time. Until then, commands help contents could be a required attribute on the command interface, per #63.

For starters, these could be implemented as single large string properties, using string continuation characters to prevent the source lines from getting too wide. Code printing the help would still rely on the engine's token colorization and automatic word-wrapping for long paragraphs (according to the client's reported terminal width), as it does with the old loose-file help topics. This could be a new property on commands; the "Description" as exists today would be better suited to a "Short Description" name and relegated to usage in code that lists commands with a short description next to the command name (e.g. "commands command").

(Long term: Eventually, a large healthy MUD may have non-developers wanting to contribute help content updates: To accommodate this we should be able to have players commit suggested updates in the in-game message boards, including coloring. Tooling from there can make it easy to print and copy in-game message board contents with the expanded color code tokens, into the source file, to be present even in an immediate non-reboot update.)

Right now when you enter a value for race or profession, you still have to type "done". This is redundant and slows down creation for testing.

(Eventually we could have a review step that lets you see all your selections, and go back to repeat given step if you changed your mind. Or at least a "start over" option after review to try again. Start a Discussion on this for preparing to track next steps too.)

Per the telnet protocol issues at hand, it seems the server should robustly accept things like CR NUL or CR LF as ending lines of input from the client, but the server should only be sending CR LF to the clients (regardless of which OS the server is running on). E.G. we should be sending "\r\n" explicitly as the line endings for output going to the client. Scattered through our code, we may be sending just \n sometimes or Environment.NewLine sometimes. Technically this is a bug and could theoretically lead to specific Telnet client implementations not understanding our intentions since we're not adhering exactly to the protocol.

(I think we should use Environment.NewLine for output going to the server's console logged output though.)

We should make the server consistent here.

EDIT: I've added a new AnsiSequences.NewLine for this ticket to use - This should make it more self-apparent and discoverable why we want to use \r\n explicitly here.

Upon first launch, we copy some initial game data to a folder like (on Windows) "C:\Users\UserName\AppData\Roaming\WheelMUD\WheelMUD\Files".

The first "WheelMUD" mean the WheelMUD framework, while the second "WheelMUD" is just the game name - so if you were developing more than one with a unique game name in app.config, they'd target two application data folders.

However, the "Files" folder is redundant. We should just copy the contents to the next folder up (e.g. the second WheelMUD in the example above).

Where we today use something like:

var ab = new AnsiBuilder();
ab.AppendLine("<%red%>Test<%n%>");
...Send(ab.ToString());

We should wrap that pattern up into a method that makes it natural to do one-liners, something like:
...Send(AnsiBuilder.SingleLine("<%red%>Test<%n%>"))

Migrate documentation again, into github via ReadMe documentation file trees.

Once the character creation process is finished and the player enters the world, providing the results of a Look command or priming the player input buffer with LOOK might help alleviate the uncertainty.

Update the "help colors" response (Files\Colors.txt) to include demonstration of bold (<%b%>), underlines (<%u%>), a table of color combinations, etc.
(See Colors.txt for TODO comments.)

I put the referenced file in the path from the exception and the command worked. The error handling needs to be more robust or the file needs to be located correctly as a part of the build perhaps?

In our WR&M reference implementation of character creation, Race is currently one of our last selections. I think we should move it to be after login name+password selection but before gender, since race selection could theoretically enforce what gender options you have available to select from, but would be more awkward to do enforcement the other way around. (E.G. in the future, a race of tree-creatures or fungi-based peoples might flavorfully provide option(s) other than the traditional humanoid gender options.)

Better yet, why do we even select a gender rather than pronoun sets? Gender may have some purpose beyond the scope of a family-friendly reference implementation, so perhaps it can be omitted entirely from the reference implementation. Instead we could add a char creation step for pronoun selections (even if all that serves is a cue for other players doing whois commands and whatnot to determine how to speak to another individual). It might be good to assign some sort of PronounSet reference to any Thing to be able to perform better interactive language construction via property getters on Thing too, e.g.:
"The sinister mage tried to cast a fireball, but his spell backfired! He exploded!"
"The goblin swung their dagger at Player Name, but she dodged the attack!"
"The goblin swung their dagger at a fragile bottle. It is destroyed!"
etc.

> whois deb
Deb is one of those sneaky rogue types.
class:  Rogue
clan:  McClan
pronouns:  he/him/his
...

(Issue depends on #107 getting solved first.)

Where we define OverflowPromptFormat in BufferHandler, we should also define an OverflowPromptFormatMXP for use with connections that have negotiated to use MXP (e.g. zMud style Telnet clients). When printing the More prompt for an MXP client, we should use the MXP Secure Line API to print this prompt. The format should include clickable links for the various commands (more/previous/repeat/all), so the user can opt to either send the keyboard command as normal, or to click the links if they prefer.

There are 5 folders in WheelMUD/systemdata/SQL which may be in varying states of usefulness/functionality. We should do a case study to see where one is at. If switching works, provide documentation .md file for how to configure the switch (any necessary DB setup details and connectionstrings details etc?) - this could be in, or linked from, Configuration.md

If a folder is found to be non-functional and difficult to salvage, we should just delete it.

After exploring the first, log a new issue to track doing this for remaining DBs.

The password change process got broken when we moved account password handling to better separate User (login account info) from Player behaviors. We moved to using a salted password hash. The in-game password change process needs to be updated as well to:

• Require the old password to guard against "left the computer for a minute" attacks.
• Save a new salt and hashed password to the associated User.
• The new usage format could be "password oldOne newOne newOne" (or we could use a series of prompts, if we build out the prompts system first).

When we "look" in a room, the exit Things are rendering like this:

Here you notice:
  [StandardExit]

This is one of the earliest defects someone is likely to notice upon logging in.

DefaultPerceivedRoomRenderer has some TODO notes we could use to guide this - I believe the Perceive helpers mentioned already exist and likely already work well enough. Exits are a little weird in that their Name is not currently helpful, as we are programmatically assigning "[StandardExit]" from a list of exits. (Eventually we'll stop loading these from the Relational DB when we get a default zone to be seeding the Document DB instead. Eventually we'll want to make their texts possible to be customized between the multiple rooms they might be a child of, too, but that'll take some thought and discussion.)

For now though, we should make the DefaultPerceivedRoomRenderer query the perceived exits, and if there are any, provide output like:

Here you notice:
  Routes: West, East

with some basic coloring, before listing all the other Things perceived in the room. I think ExitBehavior's GetExitCommandFrom(thisRoom) is what will get the texts like "West" and "East" (or "Enter" or "Up" or whatever the route is).

One thing that is a bit annoying with many MUDs is that the splash screens are dumped with a single format (and assumed minimum character width, and assumed color support, and so on), regardless of your actual Telnet capabilities. Our engine currently does this as well. For example, a debug breakpoint in TelnetOptionNaws ProcessSubNegotiation shows we have printed a splash screen to the client before we even know what size their window is. Presumably we don't know their level of color support and whatnot either.

We should try revising the initial info we print to the connection to a minimalistic, non-colored:
Connected. Negotiating... or Establishing connection...
or something like that. Then only after an initial set of Telnet negotiations (maybe all of them) have completed, we move on to rendering the splash screen. If this works, some potential benefits we could file as follow-up tickets are:

• We can ensure color codes are omitted, even on the splash screen, for clients that can't handle them .
• We can have multiple splash screens optimized for different terminal sizes (such as a more detailed ASCII presentation only on big-enough terminals to fit the width and height within one page).
• Terminals that aren't wide enough could fall back from ASCII art splash screens to just some basic word-wrapping welcome text with the MUD name.
• Etc.

During Telnet negotiations, I believe we generally figure out the Connection.Terminal.Width via TelnetOptionNaws.

First, I don't believe we ever default the window size to a "best safe guess" like 80x20, so if NAWS negotiation does not work, these values will just be 0. We should instantiate with some non-zero Width/Height just in case.

Next, we aren't using the Terminal Width to inform some systems that could make use of it. For this ticket, we should fix the Character Creation options that currently use a fixed number of columns (like 4), by:

• finding the widest option (like skill or talent) string.
• calculating total columns against the widest option string and spacing between the options, for the connection's unique window width, to optimize.
• this could still hard-code some maximum number of columns or maximum respected terminal width, as it may look really weird to the user to have only a couple rows filling their really wide terminal, etc.

GitHub made it easy to migrate our branch name to the industry's new default branch name.
I am looking forward to joining this movement at a low risk moment, soon (probably while no PRs are open).

Some things to remember to check after migration:

• Automatic builds and tests still working.
• File preview links (like User Stories HTML) still working.
• Various other links still working.
• Communicated the change.

Usually during MUD development sessions, right after we spin up the game instance, we want to also connect a telnet client to the game instance. It would be sweet if the admin console gave us a basic "connect" option. When run, it would try to see if we have a "telnet.exe" available, or perhaps other clients (configurable via app.config or via multiple connection commands?) to open with an automatic localhost connection to the correct port. This way a developer can opt to close the telnet app window each time they're done with it instead of having to juggle the extra window while they don't need it, knowing a simple "connect" command will pop it right back open and reconnect quickly.

A link to the GitHub markdown docs should include Readme.md and all subsequent Documentation, somewhere within the VS SLN or Projects.

For now this will probably be at the Project level since Solution format doesn't seem to support much in the way of dynamic inclusion of such things.

Per discussion at #85, a proof of concept shows a few lines of code can have our server handle WebSocket connections (on another port) in addition to Telnet connections. Routing text from those events through the command handler and output destined for the client back shouldn't be large problems (if we ignore output formatting for now).

Beyond those basic issues, we'll need to figure out appropriate abstractions for things like the Connection itself. E.G. would a WebSocket connection do the equivalent of the Telnet options negotiation? For now would these connections just pretend to be 80 column displays, and then provide a mechanism for disabling client-side word wrapping and other formatting concerns, as WebSocket-specific renderers become more advanced? (In some cases we already have multiple modes of rendering, E.G. using advanced features for MXP-supporting clients and rendering differently otherwise. Perhaps this is a similar model.) We don't have to solve all these things now though, but we should be thinking about this stuff as we explore the implications of housing two different styles of clients (where one expects the server to do all the display formatting, while the other arguably does not have to be such a model).

For the purposes of this ticket:

• Implement a functional WebSockets connection handler that can accept multiple incoming WebSockets connections on a given port.
• The new client connection starts receiving, verbatim, the same output as a Telnet connection receives, E.G. starting with the Splash screen.
• Lines sent to server through the WebSocket connection are routed through the command processer, the same way input lines from Telnet would be.
• User should be able to point a tool like Telsocket at this connection to be able to fully create a character, log in, and use commands in game.
• Additional instances of Telsocket and Telnet should be able to connect as well, simulating simultaneous live players of each connection type.
• The output the user receives in Telsocket won't be pretty at all (won't be colored and such), but the point of this is just to prove the technology for housing the additional connection type with a single server.
• Record / discuss any discovered hurdles, so we can assess the overall difficulty of creating and maintaining this stuff as a full feature set, and whether we want to move forward with additional phases of WebSocket support (per discussion thread #85). File additional Issues here as appropriate.

Bonus:

• The port used is configured via app.config (next to the Telnet port).
• If the port is blank, the server does not attempt to open this connection type at all.
• Same for the Telnet port, since an admin should be able to easily choose to only support one or the other.

Right now the "help colors" output renders just enough to do paging, but it says "97%" scrolled. Nothing more displays when telling it to render More, so this scenario is a bit awkward.

• Perhaps the colors.txt having a blank line at the end is interfering?
• Perhaps the paging will prompt even when there is only one line left, which could have been rendered in place of the paging line to begin with? Look into the algorithm used.
• The output seemed to be scrolled for me despite the pager; Is it even honoring the connection's cited total columns correctly?

Bonus:

• The paging prompt (at least the non-MXP one) also isn't very pretty/distinctive from natural output; could use some ANSI coloring to highlight the option letters or something, at least.
• Telnet.exe+WheelMUD doesn't seem to be negotiating the actual user's rows+columns correctly. Is this our fault or a limitation of that app?

After looking into and hopefully fixing some of the above, let's discuss and/or split out remaining issues to new tickets?

It would be great if we could break all of these down into known software pattern descriptions so we can easily describe that as well as educate.
https://github.com/WheelMud/WheelMUD/blob/fd6ee4f1f213bfc3785384961f2001c42f46c6c9/Documentation/Development/KeyCodeConcepts.md

A good example to add to this document (or even its own sub-page) would how we use the Repository pattern in the DAL for things like looking up PlayerRecords. (Also, compare to the Document loading pattern for the Player object tree itself.)

Although some of these were fixed already, we may be missing other opportunities to release stream resource locks and such in a timely manner. We should do a pass looking for common IDisposables like StreamReaders, StreamWriters, and so on, and wrap them properly in using(...) { ... }

Perhaps assess an object inheritance tree or whatnot to find which classes we use that might be IDisposable without even realizing it.

With the latest syntactic sugar, we don't even need the { } scope for these. e.g.

using var stream = new MemoryStream();
using var compressedStream = new DeflaterOutputStream(stream);
...
return returnBytes;

We have a relational DB for first reads of user info, and a document DB intended to hold the rest of the world data.
Right now (on Windows) these end up in folders like the following:
C:\Users\UserName\AppData\Roaming\WheelMUD\WheelMUD\Files\WheelMud.net.db
C:\Users\UserName\AppData\Roaming\WheelMUD\WheelMUD\Files\Databases\Embedded\WheelMud.net.db

This is inconsistent. So the SQLite .db file should probably end up in the "Databases" folder that RavenDB enforces.

The old output formatter had a severe flaw with MXP handling: A player who knew the <%mxpsecureline%> sequence could have been able to trick other player clients into entering secure line mode, and thus cause damage. The new DataFormatter intentionally does not make this conversion from the output. Instead, we will need to add an API specifically for MXP secure lines, and make it extremely clear from the API that any output rendered this way must not contain any user-generated content. (See MXP Line Tags specs.)

As such, any code which generates and sends MXP Secure Lines to the client will probably need to conditionally check if their terminal has UseMXP and if not, write output as normal instead of calling on this new MXP API.

After this ticket, there should be no output renderers which still use <%mxpsecureline%>. The "who" command for example should produce clickable links again for MXP-supported clients, and should produce output for non-MXP clients that doesn't render MXP tags on screen (without attempting to use MXP secure lines).

I've found that the "help colors" command is, at least for me, is consistently failing to word wrap correctly in Telnet.exe:

What's strange about this is the word wrapping is working against at least zMUD (per the window size specified by zMUD and not just the automatic word-wrapping that client does on its own side). Not sure yet if other clients have issues or not.

It is also not replacing the escaped \<\% and \%\> sequences with the non-tokenized output. As seen above, the way the colors.txt was written used to demonstrate to the user how to type <%red%> for example to produce red output, next to a sample of the colorized result itself. (I'll probably move this part into another ticket if needed.)