Well since I know there has been quite a bit of stuff that has been found etc... in the code, I'm planning to do another release soon enough.

I was wondering if anyone had any ideas/suggestions of what to toss in it for the next release. (Even if you have already suggested it before feel free to suggest it now also)

Changes so far for next release are:
-----------------
Added in some more information displayed by ostat.
Added more info displayed by show_object.
Fixed an issue where show_object only showed 2 spells on salves instead of 3.
Added in for mstat to show defposition for a mobile if it is different then their current position.
Added in a rubik's cube players can play.
Fixed a crashing issue in mobiles using bribe programs when they get bribed.
Modified the bribe programs so that location of the program wont matter.
(If you have more then 1 bribe program on the mobile etc...).
Fixed a looping issue in teleport looping if trying to send to the room already in.
Modified do_get, do_put, do_look, do_empty, do_zap, do_examine, do_fill, do_drink, do_recite,
do_pull, do_push, do_apply. (May be a few others that need done sometime, but this covers some of the main ones).
(So you can specify room/inventory/worn).
Included Hanaisse's reset information.
(Found in the doc folder).

If you give me a day or two I'll fine-tune all my building docs (txt files) and either upload them here or email to you so you can include them all.

As for changes, I forget most of what I was thinking, I should start writing things down lol.
A rubik's cute - neat! How about a poker game next?

Well I have considered it before so we will see what all I get bored enough to add as time goes on

Sure I'll give it a week or so before I do the release (currently still looking for issues and working on making it so you can turn the Rubik's cube so a different side is on front). I wish I could figure out a better display but it is just for the fun of it and something to pass the time lol.

The new Building Guide is complete (mostly) and uploaded here so you can grab it and add to your docs folder if you'd like, or it can be left separate as is.

I updated your existing text files but left what you had, so you can replace them completely.

Thanks I'll take a look at it and all and will add it in for the next release also. Thanks for all the work you have done on everything thus far and hopefully continue to do.

Ok, here is a few notes of things I noticed. (Sometime I'll dig into it deeper).

In classes file
---------------

Skills can also be added to a class using SSET, but can only set adept with this.

Actually that is incorrect. You can use sset to set the adept also using

Usage: sset  class   

3. Use SETCLASS SAVE often.
>setclass monk save
Class saved.

This shouldn't be necessary, it should be set up to save all the changes to the class in setclass already. This includes when you change the skills assigned to the class by using setclass or sset.

In mobiles file
---------------

hitroll = amount of hits mob can take (defaults to 8 if not set and adds 8 if set)

Hmm hitroll isn't exactly the number of times they can hit it's more like a chance for a successful hit I think. Lol been awhile since I dug into everything, but it does make sense lol.

armor = armorclass of the mob

Might want to toss in somewhere that higher armor is better. (Smaug and some others lower armor was better, always seemed backwards to me so I'm fairly sure I changed it lol).

pos = mobs current position (defaults to standing and overwrites long desc)

It doesn't overwrite long description it is just displayed instead of long description in some cases.

gold = amount of gold player can collect on loot

I would go with amount of gold reset on the mobile when it is reset instead. Since it can be stole (using steal), looted upon death, used by the mobile, etc....

5. Use SAVEAREA often to save completed work as you progress in case of a dreaded MUD crash.

Usage: savearea []
This command allows you to save a prototype area.

Should note that savearea only works on prototype areas where as foldarea is used for installed areas.

DETERMINING HPS/HITROLL/DAMROLL
---------------------------------

HPs are expressed as a #d#+# value so that when the mob repops, the MUD can generate a random level of HPs. What this means is; (number of dice) x (dice size) + (number). So a L1 mob might have 1d10+90 HPs or a range of 91-100 HPs depending on how it repops.
If you wish to generate a specific level of HPs, say 500 HPs, it would translate to: 1d1+499.
A general rule of thumb starts with NO LESS than 100 hitpoints PER LEVEL of mob.

Mob Level | Min HPS/LVL
-------------------------
1-10 | 10-25
11-20 | 25-50
21-30 | 50-100
31-40 | 100-200
41-50 | 200+

Think about the level of characters intended to be in your area attacking your mobiles. Then go find out what their average stats are. Pay particular attention to Hitroll, Average damage (which means damroll as well as average weapon damage), armor class, alignment and avg max hitpoints.

Damage is generated the same way as HPs; (numdice)x(dicesize)+(number). So a mob doing 5d8+12 damage will generate a range of 17-52 points of damage each time it lands a blow.
(I usually try to make the damage done by a mob comparable to that done by a warrior of the same level)

This was the old way of handling it in Smaug. LoP instead uses the minhit and maxhit and just gets the hp that way. I never really cared for the old way lol.

In objects file
---------------

wear_loc = the location where the object is worn (set automatically based on wear flag)

Well it is set automatically when it is worn. If you gave something 2/3 wear locations (which you can) it will be set to where they are wearing it. Example: you have some gloves that are set with wear locations of head and hand (Yes I know just doing this as an example) and they type wear head it would put the wear_loc to head if you did wear hand it would put the wear_loc to hand.

I notice you didn't really cover the requirements part in objects, might want to cover it a little bit.

On the objects default to level 5, You will notice that 5 is just what it set that object at not the prototype level. It uses your current get_trust actually for that in ocreate. I'll update it to default to 0 since I think it is a bit annoying personally, and you can specify what level you want it invoked at anyways.

Hmm quite a bit of stuff in here I'll need to look over sometime a bit better lol. Just trying to get a few things changed for now lol.

In races file
-------------
Like classes, races are autosaved.

In skills file
--------------

1. Use SLOOKUP to make sure the skill is not already created (and just not being used).

Using slookup isn't really needed if you try to make one that is already there it will let you know (I think).

name = The name is used for practising the skill or spell and by the 'cast' command. Mobiles which cast

It should be practicing.

You should also probably include the part about setting what class and percent and what race and percent for sset. It should also be noted that the skill won't be useable etc... until a hotboot/reboot/crash have happened and the mud loaded them up again. You might also want to cover the slots that are used for spells/skills in regards to items that use spells/skills for affects (like potions etc... use the slots for things. (Although you put in the SN it uses the slot number sometimes). (Unless thats something I changed and forgot about lol anything is possible).

Some sort of MpSleep code

Well I'm not saying no, but I've seen mpsleep used in lots of bases and seen a lot of people try to overcome all the issues it brings lol. One is that it will cause a lot of bug messages and issues in the current setup of things because your pausing the mobile that is doing the program it gives the player time to leave the room/area/game during the middle of the program while the mobile is paused and causes bugs when it trys to finish the program now that the person is gone. Some deal with it by pausing the player also until the mobile is finished which still leaves someone else having time to run in and kill the mobile or something etc... It has always seemed to me like sort of a waste of time to put in because of all the issues it causes for only a single gain of slowing the programs down. Most the time when I see a mud with it they go out their way to put it in every program to slow down the speech process of every mobile trying to make it more realistic. I've even found it boring sometimes waiting on the mpsleep to quit so I can finish reading what is being said.

Anyways I guess my point is what is truly gained off of adding this to any mud? lol

I was thinking more for other things, like transport! Say, you're on a ferry, but it's not using the script progtype, so it slowly mpsleeps it's way across the bog, while you A. Enjoy the weird scenery, B. Fish, C. Scream for your life because that's an alligator.[s]

I've actually seen something like that done without the use of mpsleep quite a few times Just using timeprogs etc... however they take a bit more work to properly setup etc... in the end they work out a little better most of the time, without adding the issues that seem to come with mpsleep.

That's what I meant by script prog, but I suppose it could work, if it was used enough to have to move constantly.