Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Kalixt Shawxo

Pages: [1] 2
Dead Souls Support / Re: lights, lighting, ambient light
« on: November 21, 2007, 10:40:46 pm »
okay, guess I missed that in the faq... I'll have to adjust it.


Newbies can see in the dark, and can understand all languages.

It's kind of a legacy feature from before I picked up maintainership...
I've thought about getting rid of it because it's confusing, but I
think it has upsides as well.


Dead Souls Support / lights, lighting, ambient light
« on: November 21, 2007, 09:15:25 pm »
This is a weird problem.

I made a virtual area (a basement) that is supposed to be dark, no working lights, and I configured it by walking thru with my admin character. The idea is if you don't have a light source (flashlight, torch, whatever) then you can't see anything. It seemed to be working, but then I went thru with my regular character and my daughter's character... it's not as dark, and you can navigate fine.
I even went so far as to lower all the lighting and it can still be seen.

Here's what the lighting settings are :
Code: [Select]
Code: [Select]

the results of looking at the same room at the same time by two different characters are as follows;
my admin:

 Kalixt /domains/zombieland/z-hotel ]> l
It's too dark to see.
 Kalixt /domains/zombieland/z-hotel ]>

and my regular character:

> l
The hotel basement
You are in a large basement. The lights do not appear to work, or you simply
can't find the right switch, there are no windows, and the walls are plain grey
concrete. There seems to be various piles in the darkness.
It seems to be even bigger than the hotel above it.  There is a door to the
Obvious exits: n, s, e, w, se, sw
You smell something rank in the dark.
First Admin Kalixt is standing here.

they are both in the same room. both are human.

any ideas?  Running 2.6


Dead Souls Support / Re: upgraded to 2.6... minor problem
« on: November 16, 2007, 02:25:13 am »
maybe it's just me.....

But I had a backpack with everything in it that I wasn't wearing, and no, I wasn't wearing the backpack. But after the upgrade I went to get something from my pack and I didn't have it anymore.

Also Cratylus, since I had updated the rooms.c and exits.c with the code to allow the HideExit() function, (THANKS to Shadyman) and I now have to go put that back in, were there any updates to either of those files that I should look out for?  I noticed the HideExits caused errors after the upgrade.

Any chance of adding that function in on the next release?


Dead Souls Support / upgraded to 2.6... minor problem
« on: November 15, 2007, 10:05:42 am »
I did the liveupgrade to 2.6, and my creator character and player characters lost everything that they were not wearing.



Thanks!  Ill give it a try. The mob message was not necessary, just a placeholder in the code from being converted from it's original use.


You want to use the efun userp(), which returns 1 for an object if it has ever been interactive, like so:

Code: [Select]
int CanReceive(object ob) {
  if (!userp(ob))
    return 0;
  return room::CanReceive(ob);

My version doesn't send a message to the mob, it's a waste of code unless the mob is made to respond to it.

Please explain *exactly* whom you want to exclude. I'm
a little confused now. Thx.


Sorry, I am trying to prevent ALL NPC from entering, but it allows all real players to come and go. The code from the wizard hallway is dependent upon level and badge.

I am probable unclear due to the frustration having something that appears to be simple, simply not work.

aww crap...... it's not working, the new version lets the rats out.

Apparently I don't quite understand the living(ob)

so, I updated it to:
Code: [Select]
int CanReceive(object ob) {
    if(!living(ob) && ob->GetRace() != "human") {
message("info"," Reject NPC", ob);
return 0;
    return room::CanReceive(ob);

so, hopefully that makes it check for both NOT being a living object and NOT a human race character.

UPDATE:  that doesn't work, and neither does:

Code: [Select]
int CanReceive(object ob) {
    if(living(ob) && ob->GetRace() != "human") {
message("info"," Reject NPC", ob);
return 0;
    return room::CanReceive(ob);

Thinking I was just mis-reading the living(ob) use....

so I'm back to just discriminating against non-humans with
Code: [Select]
int CanReceive(object ob) {
    if(ob->GetRace() != "human") {
message("info"," Reject NPC", ob);
return 0;
    return room::CanReceive(ob);

Okay, I am stuck on that wiz_corr_south.c..... not only can I not figure out a way to make it work to filter out NPC vs living characters, if I copy the working code into the new room, it doesn't even update and work as written to filter out non creators.

Here's the original code:
Code: [Select]
int CanReceive(object ob) {
    if(living(ob) && !creatorp(ob) && !present("testchar badge",ob)) {
message("info","Creator staff only, sorry.", ob);
return 0;
    return room::CanReceive(ob);
I understand that to say if that the room can reject the character if it is living AND not a creator AND doesn't have the badge.
Otherwise, the character can enter.

so I figured the correct code (even though the above will not even update on the other page) would be:
Code: [Select]
int CanReceive(object ob) {
    if(!living(ob)) {
message("info","Reject NPC.", ob);
return 0;
    return room::CanReceive(ob);
Which I figured said the room can reject the character if NOT living, else it will enter.

It seems to be working.  The strikethroughs are because I found the error right before entering this. It didn't like the commented out info at the bottom of the file.

happy coding!

Is there any way to just tell it to only let player characters and not let ANY npc through, (even human npc)  I might want to make a thief hanging out in the alley stay in the alley if I can later.

Forgot to answer this part.

Yes, take a look at the hallway north of the NPC menagerie
in the creator lab area:




thanks for the input... Im still learning.
I'll see if I can consolidate the declaration.

Oops! I do remember reading the random() was x-1.  Silly mistake

I have a string of rooms, (like 9) in a row that form the alley, the rooms on each end have the code to stop the rats from leaving the alley, but it allows the rats to move around within the alley. so 9 rooms generating random number of rats that can move about all 9 rooms I figured was better than one room with a higher random number.

haven't changed the races... gonna have human, animals, and zombies. but no Orcs, elves, or others. But I may put a human thief in the alley (NPC) and don't want him leaving the alley.... that's why I was thinking about a way to allow only real (not NPC) characters to leave the alley. that would cover animals and non-player humans. the OR idea is good too.


I have several comments.

1) You may not redeclare a variable twice. (I know its true for local variables. Im pretty sure this holds for global varaibles also)
2) Its more concise to declare and initialize in one statement. private int rats=random(x)
3) random(2) will generate either 0 or 1. NOT 2.
4) instead of placing code for preventing the rats to leave in other rooms, why not just prevent them from using the north and east commands? This is easier and it keeps all the code for that room in that room.
5) Race is a string in  stock DS (unless you changed it). a) You may have player races which are something other than human. So this may not be desireable. b) Also, there are several events which can change the player's Race from its original value to something else, "undead" comes to mind. Therefore, I would suggest you use your original idea and go with GetRace()=="rat". Then later if you add a wolf to the room, you can add an or statement and include the wolf to keep him in too.

Hi guys!

I have an alley, that I want a random number or rats to populate, and I think I have it done the easiest way, but I wanted to make sure I'm not missing anything.
at the header of each room in the alley, I put
Code: [Select]
#include <lib.h>
inherit LIB_ROOM;

private int Rats;
    int Rats = random(2);

this gives us 0, 1, or 2 rats.... and I then have down in the body of the room
Code: [Select]
"/domains/ZombieLand/npc/rat" : Rats,

to keep them in the alley, at each room at the end of the alley I have a
Code: [Select]
int CanReceive(object ob){
    if(ob->GetRace() != "human"){
message("info","You are repelled.",ob);
return 0;
    return ::CanReceive();

I did originally have it as GetRace() == "rat", but I changed it to "not human" so that if I add other things to the alley (spiders, etc) I would be covered.

Is there any way to just tell it to only let player characters and not let ANY npc through, (even human npc)  I might want to make a thief hanging out in the alley stay in the alley if I can later.

thanks in advance!

Dead Souls Support / Re: Hiding exits?
« on: November 10, 2007, 10:19:32 pm »
Thanks guys...... one minor issue. It works for hiding AN exit, but not multiples?

for example, I can do  a
Code: [Select]
and it works but
Code: [Select]

Code: [Select]
do not work.

I am mapping a huge courtyard, 5x5 rooms. and the rooms in the center have 8 directions for the surrounding rooms, since it is a big "open" area, but the edge rooms have a few hidden exits out of the courtyard, like in corners and between building at the edges.

Thanks for the help... I'm getting there.

Dead Souls Support / Hiding exits?
« on: November 10, 2007, 03:19:14 pm »
okay, I am missing something and I can't seen to figure out what.

I read the post on the HideExit() at

But I am missing something in the use. If I put in HideExit("northwest"); it doesn't work, and generates errors on the room.

the SetObviousExit() is a bit much for typing on every room that has a hidden exit.

Can anyone help me figure out what I'm missing?

thanks in advance.

Dead Souls Support / Re: error on DEMO MUD
« on: November 08, 2007, 01:22:31 am »
Got another one, going DOWN from the humpback bridge to the river
Code: [Select]
Humpbacked bridge
You are on an old, humpbacked bridge. Although the bridge has seen better days, the noticeable cracks in its surface seem to have in no way affected its
stability. Some peculiar writing is scrawled on the bridge. The bridge spans a small yet nonetheless formidable river. A town is visible east of here, and a
dark forest looms west. A small path winds down below the bridge to the riverbank.
Obvious exits: east, west, down
> d
/domains/town/obj/riverwater.c line 5: Illegal to redefine 'nomask' function "AddShadow"

/domains/town/obj/riverwater.c line 5: Illegal to redefine 'nomask' function "RemoveShadow"

/domains/town/obj/riverwater.c line 5: Illegal to redefine 'nomask' function "GetShadows"

*Error in loading object '/domains/town/obj/riverwater'
Object: /domains/town/room/riverbank (/lib/props/inventory.c) at line 48

'<fake>' at /secure/save/creators/k/kalixt (/<driver>) at line 0
'cmdAll' at /secure/save/creators/k/kalixt (/lib/command.c) at line 141
'do_go_str' at /verbs/rooms/go at line 47
'eventGo' at /domains/town/room/bridge (/lib/exits.c) at line 87
'eventMoveLiving' at /secure/save/creators/k/kalixt (/lib/player.c) at line 256
'eventMove' at /secure/save/creators/k/kalixt (/lib/player.c) at line 236
'eventMove' at /secure/save/creators/k/kalixt (/lib/interactive.c) at line 530
'eventMove' at /secure/save/creators/k/kalixt (/lib/props/move.c) at line 42
'CATCH' at /secure/save/creators/k/kalixt (/lib/props/move.c) at line 42
'create' at /domains/town/room/riverbank at line 37
'SetInventory' at /domains/town/room/riverbank (/lib/props/inventory.c) at line 185
'eventLoadInventory' at /domains/town/room/riverbank (/lib/props/inventory.c) at line 122
'eventLoadItem' at /domains/town/room/riverbank (/lib/props/inventory.c) at line 48
Trace written to /log/catch
*Error in loading object '/domains/town/obj/riverwater'

You remain where you are.

Looks like a water problem.


Dead Souls Support / error on DEMO MUD
« on: November 08, 2007, 01:07:12 am »
Hi, was on the DEMO MUD, in Town and tried to go E of the Village Path and got the following:

Code: [Select]
Village Path
As it travels from west to east, Village Road becomes less of a road here and more of a dirt path. The shore of the eastern sea is almost visible from here.
The village schoolhouse is north, and the shore is east. The village stables are south.
Obvious exits: east, south, north, west
> e
/domains/town/obj/seawater.c line 5: Illegal to redefine 'nomask' function "AddShadow"

/domains/town/obj/seawater.c line 5: Illegal to redefine 'nomask' function "RemoveShadow"

/domains/town/obj/seawater.c line 5: Illegal to redefine 'nomask' function "GetShadows"

*Error in loading object '/domains/town/obj/seawater'
Object: /domains/town/room/shore (/lib/props/inventory.c) at line 48

'<fake>' at /secure/save/creators/k/kalixt (/<driver>) at line 0
'cmdAll' at /secure/save/creators/k/kalixt (/lib/command.c) at line 141
'do_go_str' at /verbs/rooms/go at line 47
'eventGo' at /domains/town/room/vill_road4 (/lib/exits.c) at line 87
'eventMoveLiving' at /secure/save/creators/k/kalixt (/lib/player.c) at line 256
'eventMove' at /secure/save/creators/k/kalixt (/lib/player.c) at line 236
'eventMove' at /secure/save/creators/k/kalixt (/lib/interactive.c) at line 530
'eventMove' at /secure/save/creators/k/kalixt (/lib/props/move.c) at line 42
'CATCH' at /secure/save/creators/k/kalixt (/lib/props/move.c) at line 42
'create' at /domains/town/room/shore at line 79
'SetInventory' at /domains/town/room/shore (/lib/props/inventory.c) at line 185
'eventLoadInventory' at /domains/town/room/shore (/lib/props/inventory.c) at line 122
'eventLoadItem' at /domains/town/room/shore (/lib/props/inventory.c) at line 48
Trace written to /log/catch
*Error in loading object '/domains/town/obj/seawater'

You remain where you are.

I don't get that on mine, which is only 2.4.6 version


Wow... you rock!  Although I did write the original post kinda funny, the .45 was referencing adding another whole caliber (as a copy of the 9mm) for another gun option.... the ammo box was for the .357 ammo which is for a revolver. the .45 uses magazines.  So I did adapt the .45 box for .357 use, and I'm gonna update all the other files and I'll get them to you... maybe I can save you a little work.

I'm also working on adapting the pistol.c file to allow for different caliber revolvers, as right now it recognizes one revolver (.357) and different calibers for the automatics. right now I have .9mm and .45 ACP, gonna add in a .22LR to the autos, and I'm working on revolvers in .44 mag and .454 casull.  Three different semi autos and 3 different revolvers total.


I'm just...staggered at this code. The problem is most definitely not you.

This is code from years ago, back before I was leet in any way, and now
looking at it fills me with horror and embarrassment.

But hey, obviously my heart was in the right place.

Rather than try to fix the code you've shared (which is, to reiterate,
broken because of my errors), I've created a new set of ammo and
a new box for it, in code that actually works:


Also, this is plain unappetizing:

Code: [Select]

because it means that when the thing is addressed by name by the mud,
it may use "357round" in output to the player, which looks crude and
ungrammatical. Instead, this is better:

Code: [Select]
    SetKeyName(".357 round");

This leads us to a peculiar quirk in the parser. If a thing has a caliber
as a SetAdjective, it winds up not getting recognized as a proper adjective.
You need to drop the decimal point, and then you can use the adjective
either with or without the decimal. Yes, weird, but at least it works,
even if it works weirdly.
I am actually using the keynames as roundcaldescription such as round357mag, round9mm, round 45acp, and have not run into the key name being displayed yet.  But I was loking at it as for keeping track of them easier.

So, there you have it. You ran into some old, borken code of mine and
that was the problem. I'd like to say that'll never happen again, but,
well, probably it will. Just let me know and I'll make sure it gets
added to my to-do list, like this ammo now is.

In my defense I can only say that I wrote this under an older MudOS driver,
and maybe it worked then. Really can't say, because I'm not planning
on tracking down that old driver and testing. I'm just going to
fix the errors.
no defense needed. I really appreciate your updating the files

Incidentally, now the ammo box will not only say "This cardboard case is for .45 acp ammunition only.",
It also adds "There is not enough room in there!" because the CanReceive()
returns a 0. I don't like this behavior, and will be playing around with
CanReceive() so that it behaves a little less rigidly.

Man. I need a beer after that.

also, what happened to the code for the rifles?  M16 and 50 cal?

As I recall, it was even buggier than the code we just dissected, so I
just pulled it, intending to re-add it at some point, and just haven't
got around to it. If you'd like, I can bump it up on the to-do list,
since it's not as major a project to me as it once was.

Really the whole firearms/gunshot wounds system needs a good working
over. I came up with it so long ago that it's just disharmonious to me now.

Well, I'll be happy to test anything you got, I'm putting together a zombie-themed MUD, so I'll have lots of blunt and sharp weapons, but want to throw a few firearms in the mix. I'm not close to going public, so I'd be great for testing code for you

I also hate the term "clip" in referring to magazines, so I'm changing all that as well.

I've been out of BDU's long enough now that it doesn't hurt to hear "clip"
for "magazine" or "gun" for small arms. :)


Well, as a weapons enthusiast..."clip" has always bugged me... <g>  Now if we add an M1 Garand into the game, I'll use clip.

thanks again


Pages: [1] 2