/*
* Channel types.
*/
#define CHAN_GOSSIP "gossip"
#define CHAN_AUCTION "auction"
#define CHAN_QUESTION "question"
#define CHAN_ANSWER "answer"
#define CHAN_QUOTE "quote"
#define CHAN_GRATS "grats"
#define CHAN_WIZ "immtalk"
#define CHAN_SHOUT "shout"
#define CHAN_TELL "tell"
#define CHAN_REPLY "reply"
#define CHAN_SAY "say"
#define CHAN_GROUP "gtell"
#define CHAN_CLAN "clan"
#define CHAN_YELL "yell"
sprintf( buf, "%-20s %-14s %5d %4d %6d %4d %5d\r\n"…)Granted you would have about 4 insertion operators for each variable in the string. I personally don't consider that to be that big of a deal, but others might.
std::ostringstream out;I can see how that would get a bit tedious, but maybe only 1 or 2 levels of annoyance. Before anyone complains that the ostringstream version increases code size, know that the sprintf code I snipped above takes up exactly the same number of lines, since each arg supplied is on its own line (for readability presumably).
out << setw(20) << left << text1 << " " <<
<< setw(14) << left << text2 << " " <<
<< setw(5) << int1 << " " <<
…etc.
std::ostringstream out;
out << setw(20) << left << text1 << " " <<
<< setw(14) << left << text2 << " " <<
<< setw(5) << int1 << " " <<
…etc.
sprintf( buf, "%-20s %-14s %5d %4d %6d %4d %5d\r\n"…)
std::ostringstream out;
out << format("%1$-20s %2$-14s %3$5d %4$4d %5$6d %6$4d %7$5d\r\n"")
% "my" % "format" % 35 % 81 % 71 % 6 % 45 ;
The only caveat is that a certain amount of care will have to be done when removing elements from those lists. For example, if you choose to remove the warrior class from the class table, you have to check to ensure that either no NPC's or players are warriors and forbid the deletion, or ensure that there's a fallback class which all former players/NPC's will become.
That kind of thing is easier to manage in C++, because you aren't as likely to be using array indexes directly. It might even be the case that you don't actually delete the elements immediately, but flag them for deletion on the next startup.
We'll certainly appreciate the help! Right now, we're still at a point where things are in flux quite a bit, but eventually we'll need people to help with lots of the non-code aspects of the driver. In particular, I'm hoping to eventually retire all the "stock" ROM areas and create new ones that do a better job of teaching both players and builders how things work, and also make it clear that this isn't a "download and play" game system, but one where you can and should build your own world.
There's been talk of a ROM area respository, and ideally I'd like to make it easy to import areas if you really do just want to cherry-pick pieces, but that's a ways down the road I think.
I would certainly build areas if needed, or anything else I could offer. I do hope to get my hands on the code too though because one of the reasons I want to see an updated codebase is for my own personal edification. I have coded in the past and can code, I simply am not at the level that would likely be required for something like a MUD. As an example of what I can code, I took the CircleMUD base that I downloaded, searched up how the tells worked in it and created a tell_self function which operated much the same as the tell function except that it sent just one tell, to you, instead of giving the message of "You can't send a tell to yourself" or sending "You tell <your name> 'blah" and "<Your name> tells you 'blah'". It required finding that function, understanding it enough to edit it into a new function, and changing the is_a_tell function from a strict boolean function to one that returned a character instead for three levels of data 'y' (normal tell) 'n' (can't send tell, maybe sleeping, whatever) 's' (tell to yourself).
However, at the same time, I couldn't figure out how to get the reply function to work with it so that you could reply to yourself if you were the last person to send yourself a tell. There were simply things in the function I didn't understand.
But I do look forward to helping in any non-code aspect because, at heart, I'm a designer. I like to think like an end-user, etc… often I can be a coder's nightmare because I will suggest a lot of things and keep them busy. But I'm not leading the project so all you have to do is say "No." and you seem like the person that would be able to do that. I'd love to help with the code in any way I can, but I don't think I'll be much help there.
As for the areas, I love your thinking. I tried one of the other current codebases suggested in the other thread, it was an update on Circle I think. Either way, I looked to the site of the project and read a thread by one of the people leading it in which he stated that there was no way to really remove the stock areas without possibly messing some of the codebase up and that a user should just unlink those areas. While that might work, the areas are still there in the game when they shouldn't be. It seems very inefficient, and spells like teleport or vanish (that my MUD has, I don't know about this one) that use random rooms for results could possibly end up with a problem where they send someone to an area not linked to the rest of the MUD.
I have lots of ideas already, but I'm holding off to see where it is at first. I don't want to repeat or parrot things that are already in it or already in the works. Hopefully I can log in to the next roundtable.
Edit:
One idea which seems relevant in some ways to the current discussion is this:
Perhaps there could be a normal color setting which would be equatable to the current "complete" color setting of many MUDS which is a full ansi color setting. Then there would also be a "rich" color setting which can be set by users with better mud clients which supports a larger range of colors that those clients can read (via MXP?) so they could experience oranges and browns and a lot of other standard colors.