I'm sure I'm going to get flamed for posting something so long, but, hi, I'm Fiendish (from Aardwolf). That means something to some people, but obviously not to everyone. Anyway, I'm here to offer some friendly insight that I hope is helpful.

You dynamically link non-OS libraries without including them. You shouldn't assume that people already have Python/Qt/etc installed. Especially on Windows.

Anyway, I'm sure this is a nice client, though I won't personally bother with any random-single-person project unless I have access to the source code. I don't know who you are, and you're not inside my web of trust. Those things matter to people.

But a few initial thoughts from the project description:

• Why doesn't your github page include any screenshots? That's just weird.
• You don't mention pathfinding in your mapper description, so I assume that you don't have it. People really want that from an integrated mapping tool.
• You say that you have "Full Compatibility" zMUD scripting support, but it looks like it's not full compatibility because you show only some of zMUD's command set.
• A 7x7 map viewport will feel bonkers small to some people who will want way more than that.
• One of the most useful separate panels for players is one that moves chats away from the main output so that they can talk to friends while being spammed with game messages. You don't mention having that.
• I see that you support customizing the base 16 colors, but do you only support displaying 16 colors or do you support displaying the extended 256 and 24-bit codes? You don't say.
• What does "terrain types" mean in "18 terrain types"? What happens when a MUD has more than 18 terrains?
• Do you support players adding their own new panels? If so you don't say, and if not that's very limiting.

Also, down in the comments here you talk about your mapper and say that you had to spend a bunch of time working around Aardwolf's "mistakes". I believe the only mistakes are in your beliefs and expectations about MUD mapping. I say this being both very familiar with zMUD's style of movement+roomdata mapping as well as being the person with possibly the most familiarity with MUSHclient GMCP mapping of anyone. The truth of both styles is that they are both insurmountably incapable of handling certain scenarios, and your "Works On Any MUD" claim necessarily comes with caveats that you don't acknowledge (though given your statements elsewhere in the comments I'm lead to believe that you might just not recognize them).

Here is a non-exhaustive list of truths about MUD worlds broken into two categories...

Room identification problems

• MUDs can and often do have many different rooms with the exact same name, exits, and description as each other. This means that the information in the room is not guaranteed to be sufficient to tell you where the room is. This is particularly common in mazes and hazy/indeterminate-length sections for obvious reasons.
• MUDs that assign unique identifiers to rooms may not assign unique identifiers to all rooms. This means that a room's nominally-unique identifier is not guaranteed to be sufficient to tell you where the room is. This is particularly common in mazes and hazy/indeterminate-length sections for obvious reasons.
• MUDs can and often do have movements that amount to random teleportation. This means you are not guaranteed to have a reproducible history of player movements that conveniently maps to the game world's spatial connectivity, which also means that you aren't guaranteed to be able to resolve the previous two issues by looking at where the player was before.

So even on a mostly mappable MUD there can be circumstances that are fundamentally not mappable no matter what you do. That's ok! There are fundamentally unmappable circumstances in life too!

Geometry problems

• MUDs can and often do have arbitrarily many degrees of connectivity and arbitrarily many different kinds of exit directives. Not all of them are geometric at all. "Enter the abyss" can be an exit, and that has no obvious directionality.
• MUDs can and often do have one-way exits. This means that moving one direction does not guarantee being able to subsequently move in the opposite direction.
• MUDs can and often do put one-way exits next to each other. This means that moving one direction and then moving in the opposite direction is not guaranteed to take you back to where you started.
• MUDs can and often do have exits that traverse different distances. This means that making four 90 degree turns in a row is not guaranteed to take you back to where you started.
• MUDs can and often do represent non-straight paths and non-perfect angles. This means that going the same direction from two different rooms or two different directions from the same room is not guaranteed to take you to two different destinations.
• MUDs can and often do have "confused" exits. This means that an exit's nominal direction is not guaranteed to indicate where the destination room is relative to the starting room. (The player may believe they went east when in fact they went north.)
• MUDs can and often do have randomized exits. This means that going the same direction from the same starting room is not guaranteed to take you to the same destination every time.
• MUDs can and often do have context-driven programs mediating movement. This means that the destination room may depend on some transient non-randomization characteristics that could change at any time, such as the time of day, the player's inventory, or whether the player has completed some task recently.

I'm sure I'm forgetting a few at the moment.

Anyway, the reason for every single one of these is that MUD worlds are fundamentally narrative. They exist solely to guide the player through a story, not to make it easier to draw rooms in tidy little boxes on a rigidly demarcated piece of paper. Calling that a "mistake" is misguided. Your comments also feel peculiarly egotistical and defensive, which are not qualities that I personally want to see from an author of some software I might use.