Builder:Building FAQ
From Wormhole Sci-Fi MUD Homepage
This is a builder-specific FAQ, for everything you always wanted to know about MUD construction, but were afraid to ask. Please add your questions at the bottom of the relevant section. Let's have some more questions, people!
Yeah, some of the questions I'll come up with may be pretty common sense to anyone who's seen olc or maybe even the editor program, but I'm hoping to update our builder docs here so that they can be used in as versatile a manner as other means of building.
Believe me, unless you started by looking at the underlying method by which MUD zones are constructed, OLC can be pretty confusing. And debugging... well!
What is a FAQ?
This is a frequently asked question. Unfortunately, we haven't figured out the answer yet.
Contents |
Objects
Are values 4&5 in use yet?
Objects have six values, values 0, 1, 2, 3, 4 and 5. Different item types need a different-sized array of values to make them work. For example, armour just uses value 0 to define the AC bonus. A drink container uses values 0 to 3 (max drink units, initial drink units, drink type, and 'poison if non zero'... Some items do use values 4 and 5 though, such as ammunition (Values 0, 1 and 2 are weapon vnums that the ammo works for, 3 is the number of shots the ammo item contains, 4 is the number of dice, and 5 is the size of dice.) Transporters also use values 4 and 5... for the last two destinations.
Sniping rifles: what classification do they get? Fireweapon or Regular/Dual-handed weapon?
Sniping weapons use attack type 13: snipe. If you're defining a regular weapon (item type 5), you'd put a 13 in value 3.
How does one set an object to noremove, like the handcuffs in Paradoxia?
That was achieved with a flag called 'hex'. It's flag number 27 in OLC, letter 'A' if you're using a text editor.
Ok. You mentioned ammunition in an answer above; what object type is that?
Your father wanted you to have this answer when you were old enough, but your uncle wouldn't allow it. This is the answer of a Jedi knight. Not as clumsy or random as a blaster, but an elegant answer from a more civilised age. Ammo is item type 33: Ammo... the wiki has now been updated to show the values (gun, gun, gun, shots, numdice, dicesize),
How does one set up an object as a portal, such as Bertha's portals in Evolution?
Courtesy of the misleadingly-named FLUX spec_proc. Items with this procedure act as portals, when you use the ENTER command. The destination room is specified in value 0. It is quite possible for an object to have other uses (providing the usage of value 0 remains practical), as well as being a portal... so you could plausibly make a fountain that was a portal... but not a piece of armour, since the room destination's vnum would confer a massive AC benefit!
Portals bypass many of the tests that the game normally makes when you move from one room to another (for example, a portal could lead inside somebody's house)... so discuss your intentions with a senior immortal before creating a portal, and be very careful entering the destination.
What is the flag denoting furniture? (again, I point to imperfect and under construction builder docs...)
There isn't a 'flag' for furniture. It's an item type. This is for furniture that you sit, lie, rest on... etc. It is wrong to say that furniture items cannot be taken or junked... this is achieved via the flags assigned to the object in the regular way. (NODROP and NODONATE make an object junkproof, while leaving off the TAKE flag in the wear locations means the item will always remain in the room. You should do the same with transporters, rechargers, etc.)
Anti-flags do not prevent players from sitting on the couch, or whatever... although this may well be changed, since a furniture item type (with the NAVI flag) is the normal means of steering a starship. Thus, if furniture supported considerations such as min_lev and anticlass, we'd have an efficient way of limiting who can use what.
Why was Ami confused about furniture being junkable?
Items without a TAKE wearflag can not be junked or donated, regardless of flags.
Artoo asks: anybody got any idea what the UNDEAD object spec_proc does? If anything? How about CHUTE? Or PORTAL (not FLUX, which is used to create what we often refer to as portals...)?
Dr. Amigone steps up to the plate: PORTAL, if memory serves, is just like FLUX but sends the player to a specific room rather than a builder-specified one. Probably legacy from before FLUX was put in use. CHUTE also functions like FLUX, but supplies a custom message, yet I have no clue how the values are set up for this spec_proc. This spec_proc is used by the portals in Evolution. As far as UNDEAD goes, I haven't a clue, not at all.
Chute is another form of portal. You ENTER it, and it takes you somewhere. Why we need three of these... I dunno. But we have 'em.
The 'undead' one is for corpses that 'come back to life'. You see an example of these on Korriban. Create the corpse as a container (max contains zero) as all corpses are, but add the spec_proc. Use value 5 to specify the vnum of the mobile that should be loaded when the corpse wakes up. Hey presto - instant psycho aggy mobile thing.
How feasible would it be to modify the pulse object type (item type 38) to use values 1 and 2 for its minutes to appear or disappear for instead of 0 and 1? This would allow, for example, a Jawa Sandcrawler that is a portal to a subzone from the surface of Tatooine that is only present for some of the time, giving it more of that "random encounter" feel.
It's now values 1 & 2, so a pulse item can act as a portal. Or as armour (!), or anything else that only needs value 0 to be set.
Update: the jawa sandcrawler uses the 'ship' code, so you use the BOARD command to enter it.
What happens if the armour is worn and then a player tries to equip another piece while it's pulsing? (Alternately, this could read "Can I crash the test mud later?")
You want to give pulse items a take flag? Well, okay then... but they stop pulsing once they're in inventory. (And resume pulsing once they hit the floor again.) Pulse items are something of an evolutionary dead end. The kind of stuff we'd probably achieve with scripts nowadays instead. Oh, and... crash the test MUD if you want.
Hmm... a correction to the above. If it's pulse, it's not armour. It's item type 38, not item type 9. There are lots of pieces of clothing that don't use type 9... just given them the relevant wear location and have a reduction in AC in the applies... but it's not armour, strictly speaking.
I'm pretty sure this is the case, though I've not tried - does a player have to have instructions in their inventory in order to build an object, or can it be built with just the component parts?
You must have the instructions to be able to build the new item. Did you never play with Lego as a kid? Erm, anyway... remember that the player has to type BUILD <something in the namelist of the instructions>... it isn't enough to know the recipe. For game engine reasons, you act upon the instructions. You can't BUILD <target object> because it doesn't exist yet!
What does a ZONEROT container do?
It disappears (permanently) when you move out of the zone, taking all its contents with it. It's probably a bad idea to make large, 'useful' containers that are ZONEROT... it'll just upset players.
Does a vanished PULSE object count towards the max # in game, even while it isn't visible anywhere in the game?
Um... probably :)
Okay, as a character I know that different weapons have different minimum strength requirements, and also use differing amounts of movement. How exactly is this accomplished, and what are some recommended guidelines?
All objects have a weight, including weapons. It should be at least 1 for all items. A player's strength must be equal to or greater than the weight of a weapon, or it cannot be wielded. Thus, you can make a massive weapon like an iron club or a large-bore missile launcher, and permit only the strongest players to wield it. A weight of 18 will still allow most races to wield the weapon (with a little help from a strength psi), but you could make a weapon weigh as much as 23... leaving it available to nobody but wookiees.
If a weapon has a weight that is ten or more lower than the character's STR attribute, he can use it to attack 'for free' - it no longer costs move points to swing the weapon. Thus, certain tiny weapons such as scalpels can be used to avoid getting tired during a fight. The notion that "piercing weapons don't use move" is a myth; any weapon that's light will not cost move points in combat, whereas a heavy piercing weapon would.
Try to be logical about weapon weights, and also use them as a means to support balance. Wielding powerful weapons should typically cost move ponts; some less good ones might not.
Another barrage of weapon questions. Which weapon types use which basic attack skills? As OLC doesn't align with the builder docs, I find myself a bit confused again.
If in doubt, OLC is the way to go. Bear in mind that the builder documents were originally written for CircleMUD 2.2, and they haven't had much of an overhaul since Parallax MUD.
I can't seem to make a stab or chop weapon.
Stab and chop weapons are now possible. Some existing WH items have been converted to demand the new skill. Area authors, please put in some STAB and CHOP items in any new zone. Right now, few people bother with anything except bludgeon and pierce.
Do both pierces use the pierce skill?
Yup. Pierce without backstab just means the weapon can't be used to do extra damage, via the backstab (or circle) commands.
Does whip use flay or slash?
Flay. Only a few classes get the flay skill, by the way.
Are crush and pound both bludgeon, or is crush off limits like bite/claw/sting?
Pound is the one for weapons, and it utilises the bludgeon skill. Crush is really meant for creatures that slam into you, or constrict you like a python... but it uses bludgeon, too. Still, as for bite/claw/sting... have fun with them if you want to. Why not? Just watch the messages that the attacker, the victim and a bystander see... make sure they remain logical. Also, bear in mind that most mortals won't get the necessary skill to wield such weapons at full efficiency.
I hope I'm right in assuming shot(snipe) uses blast.
That's mostly right. Snipe is a special form of blast. When in melee combat, your sniping weapon works as a blaster.
Let's summarise:
0 Hit - No skill available (ie no bonuses... unless the character is a martial artist)
1 Bludgeon - Skill, bludgeon
2 Pierce - Skill, pierce
3 Slash - Skill, slash
4 Blast - Skill, blast
5 Whip - Skill, flay
6 Pierce (no bs) - Skill, pierce
7 Claw - No skill available
8 Bite - Skill, bite
9 Sting - No skill available
10 Crush - Skill, bludgeon
11 Snipe - Skill, snipe (when sniping)
Skill, blast when in regular combat
12 Stab - Skill, stab
13 Chop - Skill, chop
There are other attack types, such as injury caused by falling, by lightsabres, grenades, etc. You don't have to set these, as they work by default.
Mobs
Do mobs ignore room entry requirements like mount only, underwater, etc.? How about if they have the proper eq equipped? If so, does this mean that if I want mobs to be able to move underwater, through space, or in veh-only rooms that they have to have an object (possibly hidden) equipped?
Oh joy. A multi-part question.
There's a vehicle_only flag in the .wld file. You must give your mobile something in its 'mounted upon' wear location if you need it to enter the vehicle only_room.
Mobiles can be given SPACEOK. (15th option in MEDIT, 'o' flag in a .mob file), or you can equip them with items that set SPACEOK.
Movement under water works a little bit differently. Players need WATERBREATH, which can be conferred by an item, or via the 'water breath' power, but they also need to have practiced the 'dive' skill. The simplest way to make this work for mobiles is to forget about flags and skills, and simply set their race to FISH or AMPHIBIAN, depending on whether you're going to let them also walk about on land.
Silly one: Is there a reason that Blade Runner is missing from the classes assignable to a mob in OLC? I know that setting mobs to alternate classes doesn't really do much, but I find it rather odd for us to have a class that mobs can't be...
Great, you're going to give them the idea to have mobs whose sole purpose is to hunt down our replicant players? ::Ecks cowers::
Since this involves a class targeting a race, you can't use AGG_RACE to make it work. You'd need to write a 'greet' script to make your Blade Runner check the race of everybody who entered the room, so that he or she would say something (remember administering the Voight-Kampff test?) and then attempt to "retire" the Replicant.
Zone
Can an object be set to spawn in a mob's inventory less than 100% of the time?
It certainly can. Here's an example... E 1 23008 100 16 75 - This means equip the last mobile, if it was successfully loaded, with item 23008, provided there are less than 100 in the game, with a 75% chance of it happening. Or in English... give a placard to a striking robot to wield, most of the time.
Ships use exactly the same functionality in the '.zonlike' portion of the the file as regular .zon files. Use any commands in the same way that you would in a regular zone.
In the example with the object that loads 75% of the time, is that field available for the M, O, G, P, and E zone commands (every one where it could apply)?
The format is exactly the same for M (load mob), O (load object), G (give item to mob), E (equip item on mob) and P (put item in container)... and W (load starship) which you didn't mention. The only type that I don't believe you can attach a % chance to is X (remove)... or rather, if you can, OLC doesn't support it and nobody's tried to do it the 'hard' way.
How do I make something reboot equipment?
There's actually no such thing as reboot equipment. It's not a flag, or anything. It's a simplistic explanation that players have used for more than a decade, to explain what goes on when a zone repops.
What we do have is max # in-game. When a zone repops, as determined by the interval and repop type specified in the .zon file, each line is executed in sequence. When trying to load an object, for the purposes of placing it on the floor, in a container that's just been loaded or on a mobile that's just been loaded, the max # in-game specified in that line is consulted. You could use a different max # in-game on different lines... and you could associate a different % chance to load with it, as well.
Some items are given a low max # in-game because they are felt to be powerful... although nowadays we're tending to use a low % chance to load instead, since this reduces the stampede to loot areas of the best equipment after a reboot. (I've seen a level 110 player charge around getting rubber bands, knuckle dusters... even the scalpel. *blink*). Anyway, if you have a low max # in-game, say 1, the item will load (% chance permitting) when the zone first pops, because the areas are refreshed before the house contents are loaded, and before any players are allowed in.
If everybody cleaned out their clan donations and houses (we now have very few of those anyway) and the players with <rare item> all logged out, it would reappear at each repop... but if one party is hoarding the item, it becomes known (misleadingly) as 'reboot equipment'.
Note that a .zon file that attempts to place an object in a container will only work when the container has just been loaded. It isn't refreshed at repop unless you remove (X) the container from the room before you attempt to reload it. The contents of a container that isn't removed really are 'reboot equip' - unless you also load them elsewhere in the game... and unless players are able to JUNK the container, once empty.
Time for another relatively simple question: How do I have multiple objects allowed to exist at once without allowing more than one to be present in the room at a time? Add X to remove a pre-existing object and then reload it?
An object that loads to the floor of a room blocks all subsequent attempts to load another object of that type into the same room. Even if a .zon file says "load a fountain, vnum 3035, in room 3005, max in game 10, % chance 100", you'll only ever see one fountain in room 3005. (This is taken directly from the game. That's the instruction used, and you never see more than one fountain on the promenade, just south of reception, do you?)
The reason for the max # in-game being set high is so that the same fountain can be loaded in other rooms, without preventing its appearance elsewhere. It could say max # 5000, and we'd still get just one in each room mentioned in the various .zon files.
Please don't 'borrow' items from other zones for use outside their 'natural' vnum range, please. That's messy.
Er... how can I deliberately load several identical items into a room, then?
Not so easy. You could load them all into one container. That overcomes the 'load to room' limitation. Or you could create several items that are described the same way, but have different vnums... but then they won't stack. Finally, you could have a mobile pop in the room, who has an action string that forces it to drop your item. Or you could write a script to load extra items, maybe.
Is there a way to have an "if not" load? As in "if a mob doesn't load in this room because of a percentage chance, then I want to have it load in this room instead?"
Well... maybe you can do something along those lines, but it'll be hard if you want really close control. Remember that '0' or '1' that the .zon instructions have? If it's non-zero, you're forcing the game to play do the action ONLY if the previous action was successful. So...
Remove item xx99 from room xx99 - A 'marker' item in a godroom. Players will never see it. Load mob xx01 to room xx23 - the regular mobile instruction If successful, equip the mob with blah blah blah... If successful, load item xx99 in room xx99, max in game 1. We now 'know' the mob was put in. ... keep going all the 'if-flagged' .zon commands you need... then the 'else if' is achieved by... Load item xx99 in room xx99, max in game 1. If successful, this means we must have failed to load mob xx01 (for whatever reason) ... so anything else we do now (if-flagged) is a 'contingency' instruction.
Phew! What a mess... but it can be done.
Consider combining this with % chance to load, to create a 'schizo' zone that repops in radically different ways at different times.
World
When you randomize exits, does it move the direction descriptions with the exits?
Everything moves. Doors and their namelists, keyholes, look descriptions, voice locks, exit suck... the door might be in a different direction, but it has the same properties. It's as if D0, D1, D2, D3, D4, D5 got scrambled into some new arrangement.
Can someone confirm that doors can be flagged to close and/or lock on reset with the RSclose and RSlock flags, or do they have to be manually removed and then reloaded with the D command?
You don't remove doors! Just use the 'D' command in the .zon file to alter the door state during the repop. Whatever the door's condition was (open, closed, locked closed) it will become what you specified. Don't forget to repop the key!
As for RSclose and RSlocked, they're for internal game engine functions, I think. Try an experiment if you want, though.
Can an extradesc be cloaked?
No, but consider loading a HIDDEN, CLOAKED object into the room, with an extradesc on that instead. That will have the effect you were looking for.
If a room is given the TUNNEL flag and it's got a mob inside, how can anybody ever get in there to kill it?
Mobiles do not count towards limits imposed by TUNNEL or PRIVATE rooms. You can still crawl into a tunnel to fight the mobile... but the rest of your party will have to wait until you've moved on, and then follow one at a time.
When I put the HIDDEN flag on a door on the testmud, it overrides the description I entered with "Nothing special there..." What if I want a description in that direction?
You might use the WALL door flag? Or do you want the hidden exit to be openable. (Some sneaky folks have used hidden, non-opening exits simply to allow them to include an exit_suck in the room, you see... it's not such a daft question.
Space
Are there any plans for flags involving starships, maybe no_starship or starship only?
Starships can only enter a room if it has terrain type 11, ('space'), or if it has the room flag, PORT. You may have seen starships flying elsewhere, but I am assured by the coder responsible that only immortals can pilot starships within other room types.
In order to reduce the incidence of players who happen to own a space suit wandering out of the space station via the docking ring extension, I also gave each room adjacent to the smallbays a 'veh_only' flag. If you really want to engage in some EVA, you can... but you're less likely to initiate that EVA accidentally.
...I'm thinking specifically in conjunction with the planet templates - Maybe certain size ships can only land at spaceports, while smaller ones could land anywhere on the planet?
I had hoped that some spacecraft might be flagged as aerodynamic - able to make planetary landings - while with others you would have to dock at a station, or beam you down. That's a long way into the future at the moment, though. For now, any ship is subject to the same limitations.
Note: There is a 'ship type' variable in the .shi format, but it is my intention to use this to denote the complexity of the ship, rather than its size. So for example, a character might get the skill 'Pilot class 1 starship' at level 26. Class 1 starships include skyhoppers, orbital shuttles and certain slow freighters. Nothing to do with size, as such. More about the speed of the ship, and the amount of harm you could do with one.
I realize much of it is still experimental, but am trying to figure out whether it is reasonable to have planets that must be explored on foot - perhaps something else where a ship can only leave the atmosphere into a specific room(s) and the ship must be docked there...
You will always need to explore regular planets on foot (or on a 'mount' type vehicle). There is no intention to permit players to use a spacecraft to fire upon mobiles or players... unless those mobiles and players are in spacecraft of their own.
With the exception of the 'Battle of Yavin 4' area (a planetoid reproducing the surface of the Death Star), few planetary sites will be airless. As such, they will not permit passage by spacecraft. If you want to permit players to fly anywhere (limited to the outdoors, preferably), you'd need to give every relevant room the PORT flag.
Sounds pretty nifty, now all we need is to know which is the PORT flag...
It's the 25th room flag, 'y' that denotes a PORT. I have updated the builder documents.
...and also to know what the preference is on space and spaceports - Obviously it wouldn't make sense for some zones to have one, but should every outside/large zone have a place to land a spacecraft as a matter of course, or perhaps leave a few rooms open for it later on?
As a general principle, we're trying to reduce the reliance on transporters, in favour of alternatives that make remote places seem a little more... remote. Thus, it would be appreciated if future areas were written some consideration of our space travel capabilities. Currently, only the Space Station (docking ring), Hawkworld, Paradoxia, the Robot Factory and the Waxdroid Museum are connected by spaceflight, but ultimately we'd like to extend the network. (Of course, we can use a transporter or portal for now, until the ship code is more mature.)
As for leaving space for it... please do. Or write the rooms now. It's good practice for outdoor sites to include 'up' exits to 'flying' type rooms, anyway. Since so many players are able to fly, why not allow then to explore a 3-dimensional world? Adding additional 'up' exits that lead to the edge of space is relatively trivial, and can be done at any time.
With 'flying type' rooms: Should all in_air rooms be flagged fall_die to simulate realism (if your hover or fly spell runs out) or should players be given a break?
Has anybody ever told you that you're an evil, evil person Ecks? Actually, I think you'd fail to move (get told to invest in a jetpack) rather than moving into the room and then being killed, because you'd be trying to enter an in_air room without a 'fly' stimulant. Do I hear a feature request coming on? Or will that lynch mob get you first?
Should flying rooms above a zone be flagged for ships, to allow a) flying players to disembark over a particular section of a planet/zone and b) players to cruise over a zone in a ship and possibly get an idea of it beforehand? Or is a 3 tier system (ground, air, atmosphere) preferable, to force ships to land at a spaceport?
I'm using an 'in_air' flag for rooms above the landscape of the adventure site, and 'space' terrain for the stuff that's even further up. Be warned that some whole planets are only surrounded by only a few space locations, however. The difference in 'resolution' when travelling by ship means that scouting isn't all that informative. Since 'space' is a terrain type and 'in_air' is a room flag, it's possible for a room to have both. Your players will get slightly odd messages demanding that they need a suit or a ship to enter the 'space' terrain... but that's reasonable if you imagine that the altitude is very high, I guess.
If a player is transferred into a space zone without a breathing apparatus, will they die? I'm wondering if I can make a deathtrap that only affects players that do not have proper equipment, such as an airlock that suddenly depressurizes.
Nope. They'll survive, but they'll be trapped if all the exits from the room require breathing apparatus. You could then kill them by some means, such as a script that tells them about some watery or airless hazard, I supppose. Also, you can exit_suck to a DT, and it'll kill the player, so you could warn them they're caught in a fierce current, and give them ten seconds to swim to another room... which they won't manage if they have no WATERBREATH flagged equipment.
A portal to a DT will never kill a player, despite the nasty destination (so portal them to a room with a suck to a DT, if you want to achieve this). There is no aquatic equivalent of 'fall_die' to check if the player can breathe in space / under water. But then, let's be honest, we haven't really gone in for sub-aqua places on the Wormhole, so far.
(Amigone's addition: Sorta unrelated, but there is a door flag called !close_suck that sucks the player whenever the door is opened. This is used in Below Levels to suck a player out of an airlock if they're silly enough to open it.) It's used in Salvage, too, for the same reason... although I might make it just dump you into space, now we have a lot of space to explore. Breathing apparatus (SPACEOK flagged item) is available in Salvage.
Ok, silly question for today - if a mob is killed in an "In-air" room, is it possible to have the corpse (along with any items the player may drop) fall to the ground below?
No. I did ask for this, years ago... be we never got it. So you need to make your air-based mobiles NO_CORPSE (and have nothing in their inventory), or write a script that you can call from the room, or simply give the room the DUMP flag, which will zap any item at all the moment it hits the floor. (Exception: ships, although they look a bit like items, can be loaded or left in a DUMP room.)
The 'in_air' rooms above Hoth feature a nove script whereby if you drop an item, it falls to the ground in the room below, not the current room, sending appropriate messages. In fact, it's great fun with grenades... maybe adapt a copy of these triggers and give them to the mobile to execute on death.
Am I the only one who thinks DUMP is horribly evil in any place a player can be killed? It destroys the corpse and everything in it! (Although it would be interesting as part of a high-risk challenge zone.)
You aren't alone. Dump has never (yet) been used in any room that's in regular play. Perhaps it would be wise to make all DUMP rooms !mob, to reduce the temptation...
Can I load a starship within a starship? I want to make a 'carrier' type ship that can launch its own fighters...
Nope. You can't do this. Remember that you're in two places at once while you're on-board a ship. You're in a MUD room (e.g. 23080) and you're also in a uniquely numbered room on the ship, such as 350012 (which is room 12 in ship 35). If you try to load another ship, it'll simply appear in room 23080, parked beside the one you're on board.
Workarounds: make the 'carrier' ship immobile, built as a regular area, and create the fighter as small spacecraft. Load the fighters wherever you like, within the carrier ship and the space surrounding it. This means that 'Battlestar Galactica' will never fly anywhere, but the Vipers and Raptors could. Not a bad compromise, and it offers the possibility of close-in dogfighting around the skin of the battlestar.
Other workaround: make the fighters as objects that can't be taken, but which have the 'MOUNT' wear location, and the 'SPACEOK' flag. Individual players can then mount a fighter, and take it out into space... or walk to the control room, and fly the whole ship around, complete with passengers and carried fighters. A key limitation of this approach is that the people flying around in fighters could only disembark from room 1 of the ship... you can't have multiple launch points.
Can an existing area be turned into a ship?
It's possible. Ship files inherit a lot of their format from the .wld and .zon syntax, so a night of monkeying around with a text editor might yield a flyable version of an area such as the SS Godiva. There are some things that can't be done on a ship, however...
What can't be done on a ship?
Very little. Ships now repop like regular zones. In fact, even better, since you can specify max # items per ship as well as in the whole game world. Yay! However, some limitations remain...
No shops. Shops are assigned a particular room vnum from which they operate, whereas shipboard rooms are assigned dynamically, and the room the ship is in depensd on where it's flown. So no shopkeepers aboard. We have recently had success with a scripted equivalent that replaces the usual WH shopkeeper spec_proc. The script can be attached to a 'vending machine' object like the Slurm or lottery ticket machines, or a 'scripted shopkeeper' mobile which would be very similar. (The vending machines are nicer than a few of the old WH vending machines that are actually mobiles.)
No guard objects. These also work from a specific room vnum, so they won't work on a ship. You might use item_to_pass, blockermobs, or good old-fashioned keys. (Or... to roll out our usual panacea... use a room script! It would trap the <direction> command and check eligibility. But learn some basic scripting first... and remember to trap movements commands like LEAVE, FLEE and FOLLOW as well.)
No transporting aboard. Again, the dreaded destination room vnum. Since this is dynamic (there could be many 'instances' of a ship), you can't design a transporter and have it beam you onto a ship, or between rooms in a ship. You can beam away from a ship if there's a transporter item loaded aboard, however, and you never know what we might manage with a suitable script. Maybe something like "%at% <some unique mobile> dg_cast 'summon' %actor.name%" Just wondering... this probably needs some work! - Artoo
Scripts
Ok, time for a nasty, evil, Eckslike question. Which it should be, since I'm Ecks. Is it possible to script a zone to deliver damage in small doses each tick if a character is hungry or thirsty for more than a certain number of ticks? More importantly, is it ethical to do so on sections of a planetoid since each "room" signifies a much larger space then just a few meters or so?
In a way, it's actually fairer on a planetoid, since each move signifies a much greater investment of effort, to move from one location to the next. You could check the player's thirst level, and reduce their hitpoints by 1d6 (or whatever) for moving in a desert while thirsty. Could the person who promised 'scripting to follow' in the builder documents please add a scripting tutorial to the wiki?
Would it be possible to script within a ship? Random curiosity.
Yes. The easy part is that mobiles or objects you load into a ship could have scripts assigned to them, and would act normally.
For rooms, it's a little more complex, since the script must go in the .shi file. It's just like editing your own .wld file, though. Anyone except an incurable OLC-junkie should manage it... Just before the 'S' on a line by itself that denotes the end of a particular room, insert a line. In that line, put 'Z', a space, and then the trigger number. You can add several lines, each with a trigger number, if you wish. They will be executed in the order they are listed. In effect, the .wldlike part of a .shi file is _exactly_ the same as the .wld file.
