In Lands Of Pabulum codebase, I notice there are only the levels of "Immortal", "Builder", "Leader", "Head", and "Implementor".
While this is all fine and dandy, I had a thought. Wouldn't it give us more control over immortal commands if there were more immortal levels?

Thus, I proposed to expand the immortal levels to maybe 15 different ranks to spread out commands more among those I trusted more. I've come up with a list of rank names that can be used, and would like to implement these as the ranks.

My question is: How would I go about doing this? Is there some way that I can do this in-mud, or will it require serious file editing?
Since I'm a coding newbie, I'll need a little help pushing through this if there's code editing involved, unless it's basic stuff.

Thanks for the help, everyone. It's much appreciated.
-Zec.

Well if you are willing to share them and would like to see them in the next release of the base which is coming up soon post them here and I'll get them in the next release.

Zecred, you know you can bestow commands to people you trust? You don't necessarily have to make them immortals. 15 new ranks sounds a little overkill to me - just my opinion.

Well, I made a list of 15 ranks that are role-play inspired. It's more of a convenience and intrigue sort of thing. Like, what would be an Implementor in the old wizlist is now an "Unquestionable". It's that sort of scheme. Very cool ranks though, if I may say so myself. I may post them later as ideas for others, or I may not. Depends on if I want them unique to my mud or not.

-Zec.

I mean this in the nicest way possible, so please don't be offended, but to say you may or may not share depending on whether or not you want them unique to your mud would sound awfully silly in the context of bug fixes. I wonder how other people would feel if those maintaining the base would say the same thing? "I found a nice memory leak, I'll post the fix or I may not. Depends if I want the fix unique to my mud or not."

That you want to keep it private, I have NO issue with, but the way you go about it? If you have something you don't want to share, what is the point of telling people that you have it and how great you think it is? Seems kind of smug to me, but to each his own.

I dunno. My $.02 anyway. Take it for what it's worth.

Well, considering that it's not really a bug fix (It's a feature, and that's why I asked for coding assistance, not an editing of the codebase for future releases), the point here is that I made them and thus I'd ask credit where credit is due- If, of course, the rank list that I created were implemented in any other MUDs. Call it smug if you like, but maybe I'm just a bit protective of my ideas and what are done with them.

To be fair, I do appreciate the feedback, however critical it may be. I will probably be posting the ranks here as soon as I boot back into Windows and find them.

You of course are welcome to go with whatever you wish and if you choose to try and keep the idea for yourself that is fine and dandy I'll just go ahead and look and make you an example of how to add them to your code and put it here for you. If you do wish to release the idea if I use it I'll give you credit for it (within reason). If however I think your requesting more credit then it is worth considering I'm doing the code for it and you just gave the idea I just simply wont use it, simple enough right?

Of course. I'm not asking for a banner across the screen that exclaims "THAT AWESOME GUY ZECRED MADE ALL THESE RANKS". Just a mention somewhere would be great. Thanks, Remcon.

Here are the proposed ranks:

115 The Unquestionable

114 Paramounts

113 The Superior

112 The Prominent

111 The Upraised

110 Transcendents

109 The Timeless

108 Perpetuals

107 Elevated Cardinals

106 Lower Cardinals

105 The Undying

104 Terraformers

103 Manipulators

102 The Endowed

101 Mirages

Remcon, I'll let you decide what commands should go to whom for the next release. Or, I can also give my input for those and sort all the commands based on who might need them.
Thanks again.
-Zec.

By the way, I did want to ask. If you do decide to put these in, would you mind putting a piece of the changed code here as compared to the old code? I tried to do this myself, but I couldn't find where the PERM_MAX was declared. I'd like to get a good example though so I can start being able to code better.

Thanks.
-Zec.

Just as a note, adding more levels isn't really the right fix for the permissions system. Permissions aren't necessarily a linear affair; permission groups would be a better approach.

Care to give a little more detail about that one david?

Well for example you might have imms whose job is to manage players, and then imms whose job is to build, and then imms whose job is to manage other imms, and then imms whose job is to create and run quests.

It seems pretty clear that the imms-who-manage-imms are higher up in the level hierarchy so that's easy enough to do. Make commands related to managing imms be of a level such that only those imms can use them.

But does it really make sense to order commands related to player management, building and quests? Maybe you don't want builders to manage players. So make the player-managers on top of builders. But now your player managers can also build, which you might not want.

Instead, you can create groups of commands, such as:
group building: mset, oset, mcreate, etc.
group players: delete, freeze, hell, unfreeze, unhell, transfer, etc.
group quests: various quest commands, etc.
group imm-management: advance, etc.

Then, when you have some immortal, you can assign them to one or several command groups based on what they should be able to do.

Well, yes, and I've given this a lot of thought. The ranks are more for baseline trusts; Commands to whom will need them will be permitted based on the job.

The point is that the relationship between levels of trust is not always one of successive linear stages. For some MUDs, it is, and yes you can always bestow individual commands, although it's much easier to do it with whole groups at a time. Not only is it easier to add/remove them, but you can better manage group policy rather than having to go change a whole bunch of people every time you add a command.