This is the only keyword that cannot be used multiple times within a shop entry, as its presence means 'finish the previous shop and start a new one'. Each Vnum may have only one shop associated with it, and each shop can only have one keeper associated with it, of course you can copy a shop and just change the SHOP: line for another shop.
These three are special, as they have no arguments, the default for ALL shops
is 'not KILLABLE', 'no CASTING' and 'not ROAMING'. Unless you specifically
want one or more of these, just leave them out of the shop definition.
**You are NOT currently allowed to make a shop mob killable.**
This is the 'Buy Types' entry, and is one of the keywords where multiple entries makes perfect sense. Use this to specify the 'types' of objects this shop will buy, if you don't want your shop to buy anything, don't include any. There is no limit on how many types a shop may buy, and you can place them all on one line, or one type per line, or any combination, duplicates don't matter either, code will ignore duplicates.
This is the 'Produces Objects' entry, and is one of the keywords where multiple entries are sensible. Use this to specify the Vnums (Virtual Numbers) of the objects you wish this shop to produce is endless quantities. If you just want your shop to sell only what you load onto it, or what some character sells it, don't use any of these entries. Note that you must load one copy of an object you wish the shop to produce into the shopkeeper's inventory, before they will start producing that item. This is deliberate and will not change, since removing an object from a shopkeeper's inventory via the .zon file is much more difficult than loading one.
In general, shops tend to produce items from their own zone, but they do not have to, either use lookup on the test mud to get the Vnum you want, or ask a higher level god what the Vnum of a desired object is, object Vnums change only VERY rarely.
In most cases (though not all) a shop should be willing to buy back anything it produces, some examples: A smithy, that produces armor and weapons, should be willing to buy armor and weapons (though prices will vary, see PROFIT). On the other hand, a restaurant that sells food and drinks, very well might not buy anything at all, just think about what you are doing with this shop.
This entry specifices the shop's operating hours, if you leave out all HOURS entries, the shop is assumed to be always open. This is a keyword where multiple lines are fine. Valid hours are from 0 (midnight) to 23 (11 pm). This keyword has a special case, rather than using numbers, you may use a string of 'O' (open) and 'C' (closed), one per hour.
which would mean: Shop is closed from 11pm to 7am, open from 7am to 1pm, closed from 1pm to 2pm, and open again from 2pm until 11pm. If you use this format, multiple entries do NOT make sense.
This keyword only applies to non-roaming shops. Basically if a shop is not roaming, the shop proc will be disabled when the keeper is not in his shop. Multiple entries of this keyword are not sensible, the number is the Vnum (Virtual Number) of the room the shopkeeper loads into.
This determines the shopkeepers prices, the default value is 100 (which means this shop sells things for 100% of their value). If you do not include a GREED entry, it will be set to 100. Valid values range from 10 to 1000, and you had better have a damn good reason to ever set it below 100. Multiple entries will overried each other.
This determines the prices that a shop will PAY for objects sold to it. The default is 100, which is a 100% markup, meaning the selling price is twice what the shop will pay to buy it back.
A shop has default GREED 100 and PROFIT 100 (the defaults), then: Object valued at 1000 coins, shop sells it for 1000 coins (100%) and would buy it back for 500 coins. (Assuming the shop WILL buy it back, see BT)
These used to be the 'temper' values, for when a buyer didn't have enough money or tried to attack the shopkeeper. They were never really implemented, and still aren't, they both default to 0. Until we actually do something with them, probably best to leave them out.