Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Development ➜ I have a fully functional x64 fork/port. Need a clarification.
I have a fully functional x64 fork/port. Need a clarification.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Nodens   (6 posts)  Bio
Date Mon 27 Nov 2023 08:53 PM (UTC)
Message
Hello Nick,

First of all I want to thank you for the amazing work you've put into this project all these years!

Secondly I want to inform you that I have taken upon the task of forking and modernizing MUSHclient!

I already have a fully functional x64 port with updated Lua to 5.1.5 (plan is to bring it to 5.4 but that is lower priority at the moment).

Currently I am in the process of porting it out of MFC and into Qt (a big undertaking but I will complete it :)), in order to add a lot of features such as proper theming support, native cross-platformness, better multithreading etc.

The current name for the fork is MUSHClientx64 but I intend to rename it to something else once the Qt migration is in a stable functional state. I do not have a public repo up yet but that will go up, again, once the Qt migration is in stable functional state. I fully intend to keep the project open source.

I do plan on distributing the x64 MFC port binaries on and for CthulhuMUD though, in installer and zip format, bundled with some plugins and preset settings for CthulhuMUD and I wanted to include an additional license to yours (as a sublicense for the fork). I believe according to your license terms, this is ok, but I wanted to check with you anyhow.
So please check this pastebin, when you can, and let me know if it's ok or if you would like to request any changes.
https://pastebin.com/q2S48pVw P4ss:cpebksKg6m

(Passwording the pastebin because they are often parsed for email addresses by spam operators)

Again thanks for the best MUSH/MUD/MOO client ever created!
Panagiotis Kalogiratos
Top
Posted by Fiendish   USA  (2,533 posts)  Bio   Global Moderator
Date Reply #1 on Tue 28 Nov 2023 01:34 AM (UTC)

Amended on Tue 28 Nov 2023 01:39 AM (UTC) by Fiendish

Message
Quote:
I already have a fully functional x64 port

Cool!

Quote:
Currently I am in the process of porting it out of MFC and into Qt (a big undertaking but I will complete it :)), in order to add a lot of features such as proper theming support, native cross-platformness, better multithreading etc.

This sounds awesome.

Quote:
(plan is to bring it to 5.4 but that is lower priority at the moment)

That would break compatibility with LuaJIT, so I'm not excited about this part. :(
Please leave it until the very end. 😂
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nodens   (6 posts)  Bio
Date Reply #2 on Tue 28 Nov 2023 12:56 PM (UTC)
Message
Hi Fiendish,

First of all thanks for your work on the client and specially thanks for the conversion of the VC 6 workspace and project file on the resources repo. Saved me some time having to find a version of VS that could convert those correctly (I have down to 2013 installed and it couldn't). I was about to remake a solution from scratch when I found your repo. :)

Glad that you like what I'm doing with MUSHclient :)

Quote:

That would break compatibility with LuaJIT, so I'm not excited about this part. :(
Please leave it until the very end. 😂


Or we could just fix LuaJIT ;)
The plan is to support everything 5.1+ but default to latest stable. And I will drop support to everything else scripting-wise so that Lua is the only choice. Streamlines everything and gives just one target to maintain on the scripting front (which is also the most capable for the use case as well -- not to mention that any ties to windows scripting host would have to go anyway as we go cross-platform :))

Still, upgrading Lua comes after finishing the Qt migration, on the new/upgraded features phase!
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #3 on Tue 28 Nov 2023 09:02 PM (UTC)
Message

Hi Nodens,

That looks fine, I don’t have any issues with the license.

I was about to ask whether you are planning to make it 100% compatible with the existing client, and I gather not, from what you wrote recently. That’s fine too, I would do the same.

If I were rewriting it, I would be doing a lot of what you propose.

  • Get rid of the Windows Scripting Host (WSH) and stick to Lua
  • Recompile without MFC
  • Modernise the dialogs (for example, a keybinding dialog to bind keys to actions), and allow them to resize in the modern manner to accommodate different screen sizes.
  • Get rid of stuff that would virtually be never used — Arrays spring to mind
  • Use STL instead of the MFC methods of walking lists (this will be a pain to get right). STL list walking is much simpler than MFC, because an iterator points to the current item in the list, whereas MFC advances the “pointer” to the next element in the process of giving you the current one.
  • Simplify colour handling. I would just store 3-byte RGB colours for all style runs, not the mish-mash of methods currently used.
  • Simplify exposed functions (at least partly). For example, there are multiple ways of finding the current world name WorldName and GetInfo
  • Improve the Help interface so that it works under modern operating systems. The help stuff is currently in a database, and there is currently a plugin that accesses that.
  • Maybe make world files JSON rather than XML (obvious compatibility problems if you do that).

The more you change, the less compatible it will be for existing users, so there would be a balance there. I would try to keep the Miniwindow stuff as much as you can, otherwise a lot of Fiendish’s stuff won’t work.

If you are not trying to make it 100% compatible with the existing client, no doubt Fiendish would also have some suggestions.

- Nick

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nodens   (6 posts)  Bio
Date Reply #4 on Wed 29 Nov 2023 12:46 AM (UTC)

Amended on Wed 29 Nov 2023 01:21 AM (UTC) by Nodens

Message
Quote:

I was about to ask whether you are planning to make it 100% compatible with the existing client, and I gather not, from what you wrote recently. That’s fine too, I would do the same.


The plan is to keep it 99% compatible. Even if it means that I have to use wrappers to achieve some of it. I want it to be a drop-in upgrade and have existing scripts and plugins working as-is unless they're not written in Lua. So the only functionality/compatibility I am planning on breaking is WSH.
I have no idea on the current usage of non-Lua scripts (let me know if you do) but I imagine the userbase must have mostly turned to Lua after all these years.

Quote:

Get rid of the Windows Scripting Host (WSH) and stick to Lua
Recompile without MFC


These two are top priority for the obvious reasons.

Quote:

Modernise the dialogs (for example, a keybinding dialog to bind keys to actions), and allow them to resize in the modern manner to accommodate different screen sizes.


Also high on the list and Qt makes this and a lot more very easy. The tough part is completing the migration. :)

Quote:

Get rid of stuff that would virtually be never used — Arrays spring to mind


I have never used this actually and I have not even looked up how it is implemented but like I said I want to retain compatibility on anything other that WSH.

Quote:

Use STL instead of the MFC methods of walking lists (this will be a pain to get right). STL list walking is much simpler than MFC, because an iterator points to the current item in the list, whereas MFC advances the “pointer” to the next element in the process of giving you the current one.


I will be using QObjects and Qt container types wherever possible (because cross-platformness is guaranteed and implementations are optimized for each Qt supported platform) and the rest pure STL. MFC will eventually be striped entirely from the project.

Quote:

Simplify exposed functions (at least partly). For example, there are multiple ways of finding the current world name WorldName and GetInfo


I could simplify a lot of this and use wrappers for retaining existing script functionality.

Quote:

Improve the Help interface so that it works under modern operating systems. The help stuff is currently in a database, and there is currently a plugin that accesses that.


This was already high on my todo list. Help should be working without jumping through loops, heh.

Quote:

Maybe make world files JSON rather than XML (obvious compatibility problems if you do that).


This I wouldn't do for two reasons. First is breaking compatibility, like you said, but my main issue is that JSON is not edit friendly for technically inept users.
Since we're not using a binary format, I'd rather retain the simplicity of XML, when a user who has no idea what any of that is, decides they need to edit their world file to fix/change something.

Quote:

Simplify colour handling. I would just store 3-byte RGB colours for all style runs, not the mish-mash of methods currently used.


This is a great idea and just added to the todo list.


The Miniwindow stuff, like everything Lua related, will keep working. I make heavy use of that myself. I have written chat channel plugins for CthulhuMUD, deriving from those and extending them with things like toggleable "name mentioned" alerts, persistent scrollback buffer etc etc.
The plan is to extend functionality where possible or where it makes sense (eg make it possible to threadsafe offload scripts to worker threads) but existing scripts should keep working as-is.

In general, if you or Fiendish, or anyone else have any more ideas, or eg had specific things in mind, at some point, that would be cool but the current codebase makes it hard or tedious to implement, keep them coming my way :)
Top
Posted by Mance Bratton   (1 post)  Bio
Date Reply #5 on Mon 11 Dec 2023 04:51 AM (UTC)

Amended on Mon 11 Dec 2023 04:53 AM (UTC) by Mance Bratton

Message
Some features from z/Cmud would be nice. The first two can be done in Lua, sort of, but they're work-around approximations at best and anyone who's migrating from z/Cmud to MUSH will notice the difference right away.
- #WAIT
- #SUB
- being able to have trigger, etc. settings editing window open and being able to minimize that to background and do things on the command line, and vice versa, without having to close and open the settings windows, over and over, every time.
- being able to insert (concatenate) color codes directly into text as in zscript, e.g. #SAY %ansi(15)white %ansi(10)red %ansi(12)green would show 'white red green' in those colors. I know about ColourNote and once accustomed to it, it's fine, but when I was still learning I found it very confusing.
- probably others too, Cmud was great while it was in development and then development just stopped cold one day and that's been that ever since.

Way better timer resolution, like millisecond or better. Currently timers only go to 0.1 second resolution, and if the CPU bogs down for something it can delay the timer intervals and slow down the timer, leading to problems with the script.

I would love to see Lua and LuaJIT updated to 5.3 or whatever is most recent and/or reasonable. If 5.1 could be kept as it is, the 5.3 Lua could be added separately, and then the user could set their client to use whichever version their scripts were written for. I'd love to update my scripts and take advantage of updated and new language features so I think updating Lua and LuaJIT would be a fantastic upgrade. And keeping 5.1 as a legacy option, it would let people continue to use their legacy scripts without needing to update or change them, if they're happy with that. Best of both worlds!

Shift+ctrl+0 (keyboard shortcut for timers menu) doesn't work. Whoops!

RSA and AES encryption support. We have some pretty far-out stuff in the math and utils libraries, so encryption wouldn't be out of place. It's esoteric features like these that make Mushclient so much more interesting to work with than z/Cmud. And Mushclient obviously had privacy as one of its goals, hence the out of band chat feature but because it requires direct connection to the other person's ip it's not always an option. There should be an in-band means of sending a secured message via the mud. Telnet is really insecure, also. Why not? Because someone might write a chat plugin MUD admins won't like because they can't read snooped tells anymore? Really now, if player's messages are encrypted it means whatever they're saying isn't bad enough to be worth making effort to send by email. Considering how often players become really intimate and explicit in their conversations and whatnot, if you're an imm do you want to encounter that by accident while snooping for unrelated (valid) other reasons? Not really. I was a little doubtful at first about this request, but I think it does make sense for a MUD client to provide for in-band secure chat and don't think it would harm anything.

It sounds like a complicated project, but is definitely worth doing and I wish you good luck. I hope these suggestions are ok, thanks for reading them. Let us know how it's going as you update things, I think Mushclient is great and the prospect of a major overhaul and re-engining is very exciting to me and I hope you succeed.
Top
Posted by Nodens   (6 posts)  Bio
Date Reply #6 on Mon 11 Dec 2023 06:53 PM (UTC)
Message
Hi, thanks for the suggestions!

Mance Bratton said:

- #WAIT
- #SUB


It's been literally decades since I last touched z/cmud so I can't really remember what #SUB did, heh. Wait states on the other hand are a problem that will be solved once I'm able to run scripts in their own threads.

Quote:

- being able to have trigger, etc. settings editing window open and being able to minimize that to background

All windows will be modeless as I also find modal windows annoying and with Qt there's zero technical reason to use modals:)

Quote:

- being able to insert (concatenate) color codes directly into text as in zscript,

I am adding this to my todo.

Quote:

Way better timer resolution.

Already in todo :)

Quote:

I would love to see Lua and LuaJIT updated to 5.3

As already mentioned the plan is eventually 5.3 but supporting everything up to 5.1.

Quote:

Shift+ctrl+0 (keyboard shortcut for timers menu) doesn't work. Whoops!

I was not aware of this as I have a habit of using alt-enter which opens the last options tab used. I will probably fix this and submit a PR on the current client as well.

Quote:

RSA and AES encryption support.

This is pretty easy to add but there a couple of problems with the use case. First of all most muds would definitely break if we output ciphertext directly on a channel, producing garbled output on the other end that would not be decipherable. A lot of them would break even if we output something like BASE64 encoding due to +, /, = usually being treated as special. There's really no way to guarantee that this would work properly using mud channels since it has to go through the mud engine's processing of channel text. Since you suggest this could be used for explicit rping etc, a lot of that happens via emotes and there's really no way, whatsoever, that we could inject something like that in emotes and have it appear properly on the other side, for most engines I have experience with, without coding special support for it (in which case you can just write a plugin for your mud).
But even if we manage to implement this just for channels via eg just hex encoding or something it would also prevent administration from logging things and it can cause people spamming ciphertext on public channels accidentally or on purpose. I can already see mud admins banning the client for providing this functionality so I'm really not keen on the idea, specially since, if a mud wants to, they can just write a plugin and support in code on their side. I can provide a native interface to be used via lua though but in this case I'd probably go with chacha20 as it's extremely fast, beats AES on systems with AES-NI, while being extremely faster than AES on systems without it.

Again thanks for the suggestions and if you're interested in the x64 binaries, they're here: https://mushclient.cthulhumud.com/
It comes with lua 5.1.5 and luasocket 3.1.0 x64 compiled with VS2022 toolchain. No LuaJIT yet.

(Notice this version has patched mushclient to respond to attempts at re-negotiation of telnet options as the default behavior was breaking telnet options on CM copyover, turning everything off (and basically every Diku derivative using that, that does not save negotiated options state to reapply on recover)).
Top
Posted by Fiendish   USA  (2,533 posts)  Bio   Global Moderator
Date Reply #7 on Tue 06 Feb 2024 09:51 PM (UTC)
Message
Hi Nodens,

I'm wondering if you'd be willing to consider doing the development of this publicly, like on GitHub? I don't think the community benefits from waiting until after the Qt stuff is done.
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Slysven   (2 posts)  Bio
Date Reply #8 on Tue 12 Mar 2024 02:48 AM (UTC)
Message
Hello, I'm new here and not a MUSHClient user. However I have contributed to TinTin++ in the past and I have been a Core Developer for Mudlet for over ten years. I am working with someone else who is looking to contribute MMCP (Mud Master Chat Protocol) support to Mudlet and wanted to ask both Nick Gammon and Nodens about whether it would be feasible to extend MMCP to support more than just the ASCII (or maybe Latin-1) encoding that it currently does and also for way to indicate to other peers the languages/locales that a client wants/can use.

I believe that UTF-8 would be the simplest way to go for the former and it has the advantage that it has some unused byte values (those in the range 0xF8 to 0xFE) which could be pressed into service to provide MMCP commands to negotiate these details (like 0xFF is used to end all but file transfer blocks) and which can be picked out of the data stream if necessary without them being confused for actual text data.
Top
Posted by Nodens   (6 posts)  Bio
Date Reply #9 on Tue 12 Mar 2024 06:00 PM (UTC)
Message
Hi,

The MMCP reference does not describe any character encoding requirement. The data part of a chat data block can contain whatever. It's up to the individual client if it can handle UTF-8 or whatever encoding.

So basically you can just try reading it as UTF-8 and fallback to ISO 8859-1 if that fails. Or you can send a UTF-8 BOM (EF BB BF), although this is bad practice as normally UTF-8 does not require a BOM and it's not recommended in general as the other side has to support it and things will break if it doesn't.

Meanwhile, if you're implementing MMCP, you should probably implement UPnP as well as the average user has no idea how to port forward and since this is P2P, it is a requirement.



PS I forgot to post an update here since I talked with Fiendish on discord, for whoever's interested, the x64 MFC port of MUSHclient is here: https://github.com/Nodens-/mushclientx64 (I know the repo needs some cleaning and a proper readme, I'll get to it when work settles down a bit).
Top
Posted by Slysven   (2 posts)  Bio
Date Reply #10 on Wed 13 Mar 2024 12:52 AM (UTC)

Amended on Wed 13 Mar 2024 12:53 AM (UTC) by Slysven

Message
> The MMCP reference does not describe any character encoding requirement. The data part of a chat data block can contain whatever. It's up to the individual client if it can handle UTF-8 or whatever encoding.

Yeah, that is not ideal in this day and age though - better to have some way to positively assert something rather than "sucking it and seeing" - at least IMHO.

BTW is the Discord guild public - we use it extensively for Mudlet (we've even integrated the {now archived, but MIT licenced I think} Discord-RPC library so that users can show they're playing a MUD with Mudlet - or, with some extra integration via GMCP or a MUD specific package they can even show the MUD's icon and some snippets of information as part of their User details there.

I'm discussing this in Scandum's MUDhalla Guild: https://discord.gg/m3wZeSq but you'll probably find me more active in the MUD Guild https://discordapp.com/invite/qz4UM7q - out of politeness I'm not going to list my own Client's Guild here but it is publicly searchable...
Top
Posted by Nodens   (6 posts)  Bio
Date Reply #11 on Wed 13 Mar 2024 01:44 AM (UTC)
Message
Frankly, there is no ideal solution.

You can obviously extend the protocol with something like:

CHAT_CAN_DO_UTF8 9

and use that as part of a handshake, expecting a YES/NO reply before starting to send any actual text blocks BUT unless everyone implements that, it's not going to work anyhow and it also has the drawback that your handshake on unsupported clients may completely break them depending on how they handle unknown chat commands. MMCP does not even have a way to tell you're on a new version of it.

It is much simpler to have a UTF-8 toggle on the client defaulting to on that can be turned off on a per chat basis, controlling what you send and simply test the incoming chat blocks for UTF-8 and fallback if it's not UTF-8, for the lifetime of the TCP socket. It doesn't need protocol changes and modern clients can easily support it while you retain full functionality with the original protocol.

The other way to go would be to publish an RFC with a revision of the protocol, on an agreed implementation, with a proper protocol options handshake, opportunistic end to end encryption, protocol versioning for proper handling of further revisions etc etc. And only care for clients who choose to implement that. At which point you may call it something else entirely as it will bear little resemblance or interoperability with MMCP which is a bare bones dinosaur. :P

And in my opinion this is the way to go..transferring clear text chat in this time and age is a bit weird to be honest and shouldn't be considered private chat. Keep MMCP as it is, so it's compatible and make something new following proper practices.

The discord I was talking about is the r/MUD subreddit's discord and possibly the biggest MU* related community currently. It's public: https://discord.gg/multi-user-dungeon-279748146316312576
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

6,120 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home