I think this one is pretty irrelevant. If you make a client that has every fracking bell and whistle already in it, then sure, its a problem. But, what I have been trying to manage with Mushclient, if I could ever connect script and object events properly without rewriting the entire client in raw c++, sans MFC, is make it universal in the sense that it "can" support features.
The idea being, if you mud decides to have an MMO style display of the character inventory, either you can adjust "that" data so that its sent differently, negotiate for it with a plugin, or otherwise *only* change it when you need to. The plugin to handle it would consist of the data management to send/receive commands *specific* to that plugin, and all you have to do is create a plugin that has a layout of the window, icons for the items, and the script needed to handle what you can do with it. Then, on the mud end, you have a universal system, possibly extending MXP, since that would be simpler, which would just go:
-negotiation-
// Any version 1.3 or higher, you could do 1.3, 1.7, if 1.8 introduced a new field, for example.
mud: <need=plugin_id, 1.3, +>
client: <have=plugin_id, 1.4>
-uses-
mud:<plugin_id, place=item_num, slot=arm>
client:<plugin_id, dragging=item_num>
client:<plugin_id, place=item_num, slot=bag=1>
Without the plugin in it, it would look and act more or less identical to Mushclient now, but have support for adding your own code, so that, if you wanted, you could even borrow the layout from such a plugin, parse "existing" data, and display an inventory, even though the mud itself doesn't support the plugin at all.
All that data negotiation does is allow the mud to send data to the client in a way that is **certain** the client will display the data in a particular way. But even without a plugin made "by" the mud admins, a client that supported such a script system could allow the user to manufacture one anyway, then just parse the "existing" output into the display. Since things like clicking, dragging, etc. would all be capturable events, you could have them do any behavior you wanted. So, instead of the plugin doing:
a player could make one that would do this, on a mud that *doesn't*:
Or, something similar, though the code is going to get complicated if you "don't" let the mud handle dealing with moving stuff around, but have to send sets of commands.
Point being, you don't need the admin to code anything, either into the mud, or a plugin. Someone is likely to do it anyway. We have plugins that, in terms of the ones I made:
1. Tell you how many potions you could make, based on how much of each ingredient you have in inventory.
2. Track the lunar cycles, to determine when one mob would appear, and show the moon phase in the status bar.
3. Keep track of how long you have been playing and warn you past a certain point.
4. Track your spells, to determine when they are 10-20 seconds from failure and need renewal.
Others... Have made ones to ghost the world window, so you can send chat and other text there, instead of having it in the main window, and other things. Someone made a mapper for a hex based map, to play a Battletech based mud, which while an external program, is "connected" to the client via a plugin, which runs the mapper, then feeds info back and forth.
Yes, in the perfect world, the admin are going to go, "Heh, and inventory with icons would be real neat!", and code one. In an imperfect world, if it was possible to create on in Mushclient, half the people that use it would already be using/adapting **my** version of one to the muds they play on. That this hasn't happened is entirely due to the fact that it just isn't possible to do at the moment.
So, no, adapting a 20k room mud to "support" something, is a non-issue. Unless its something nuts, like a 3D image of every room, or ambient sounds for areas, or something that "has to be" integrated into every room in the game, all doing so really does is simplify the data handling for the player, many of which will look for a solution, but not write one themselves. Otherwise, *someone* if you give them the tools, *will* code something for you, without even requesting, or possibly even wanting, it.