I know you're doing it for fun, but if you do decide to do it for reals (meaning be competitive with the best clients out there)
Python isn't really the best language to use since it is slow enough to introduce measurable latency when you have some
degree of load from actions/highlights/triggers etc.

The two major issues that I see:

Your msg handler doesn't match prompts. Matching prompts is the fundamental operation that has to
be correct in every MUD client, otherwise you can't do reliable per-line operations (like actions/triggers/highlights etc).
You need to take into account that server output can arrive in batches that are completely arbitrary / not neatly
terminated by a complete prompt or even new line. Example:

You can do a network read and get "OUTPUT FROM S" and then do another network read and get "ERVER ...."
The simple fix is to read and process complete lines. This fails when a prompt that doesn't end with
a newline arrives, which is why you need prompt handling to be a part of the msg handler. Ideally you have
EOR/GA autodetection and an option for user-configurable prompt that is matched by a regexp (say). You
have to be careful in how you do the regexp matching if you do decide to use it.

The second major issue is that you're using regular expressions to match ANSI color SGR sequences.
This doesn't work because regular expressions can not be used to model state machines, which is really
what you need here. Think about what I said about batched input, and you should be able to see how
your scheme fails.

Making something that sort-of-works, some of the time, is easy.

But making something that's robust is all about understanding the problem and its cornercases
(meaning having an accurate model) and then coming up with an appropriate solution. Also keep in mind all the assumptions you are making, since it’s usually assumptions that you haven’t really thought through that end up biting you..



Edited 7 time(s). Last edit at 05/04/2020 09:33PM by zoskia.