Top Posters
Top Uploaders
Users Online
Stats
Zylara's Bugfix List
This list of fixes was archived from Zylara's list as originally posted on GeocitiesThe formatting may not be pretty, but I chose to copy it as seen.
Updated Aug. 20, 1999
SMAUG = Simulated Medieval Adventure multi-User Game
MUD = Multi User Dungeon
*********************MAIN 1.4 BUG/FIX LIST*********************
-------------WHO ARGUMENT REMOVAL
From: "Li'l Lukey" lpherson@mncs.k12.mn.us
If you want to type just "who" instead of "who 1". All you have to
do is remove the line near the top of mud.h that defines REQWHOARG.
#define REQWHOARG to /* #define REQWHOARG */
and in act_info.c comment out the stuff for ifdef REQWHOARG
----------SHIELDWORK and POSSESS
ASSIGN_GSN: Skill shieldwork not found.
This is unfinished, just comment it out of the one line in mud.h
and two lines in db.c
ASSIGN_GSN: Skill possess not found.
Just an unfinished feature, doesn't hurt anything, don't remove it.
Removing it will cause problems instead of it just saying 'not found'.
-----------------HELL IS SET TO WRONG VNUM
From: Rjael mud@mini.axcomp.com
Hell apparently still has problems, although an unhell won't
crash the mud.
From: Kevin London
I will fix hell, we use a different vnum on realms and I always
forget to set it back for smaug.
From: me (Zylara)
In act_wiz.c in the funtions do_hell and do_unhell change the
victim->in_room->vnum != 8 to a 6 instead of 8
char_to_room(victim, get_room_index(8)); to 6 also.
-----------MOBS DEFPOSITIONS
From: Sevoreria Dragonlight
I discovered mobs we created were not moving even when we installed
the area. In smaug 1.4 there are several new positions. Smaug 1.02a
defpos 8 was standing, but now it is sitting. All you need to do is
find the make_mobile function in db.c and scroll down to find the
defposition and position values (which should say 8 if you haven't
changed them) and change the values to 12 (which is the new position
for standing).
-------------KICK and SLICE
From: "Li'l Lukey" lpherson@mncs.k12.mn.us
I found a bug in the do_slice function. It seems that do_slice was
probably a copy and paste of do_kick. In the first ifcheck located
in do_slice in skills.c, notice how it checks the gsn_kick instead
of checking gsn_slice like it should.
if ( !IS_NPC(ch) && !IS_IMMORTAL(ch)
&& ch->level < skill_table[gsn_kick]->skill_level[ch->class] )
{ ^^^^ <----------change to slice
send_to_char("You are not learned in this skill.\n\r", ch );
return;
This skill still needs some work done on it to get it working.
------------PROFANITY CHECKER
From: Kevin London london@cs.utk.edu
init_profanity_checker doesn't work properly yet, you can comment
out the init_profanity_checker function if you wish to get rid of
the following errors when compiling:
act_comm.c: In function `init_profanity_checker':
act_comm.c:3180: warning: implicit declaration of function `re_comp'
act_comm.c: In function `is_profane':
act_comm.c:3295: warning: implicit declaration of function `re_exec'
------------------REQUEST PIPE
Error messages on request pipe and what does it do anyway?
From: Altrag altrag@realms.game.org
Requests are used for the web interface. try "echo webwho >>REQUESTS"
sometime and watch the WEBWHO file get updated. pretty snazzy, eh?
From: Kevin London Internet: london@cs.utk.edu
You know the webwho on the smaug page, this goes through the request
pipe. To get rid of it take -DREQUESTS out of the Makefile if you
aren't going to use REQUESTS.
----------NEW WEAR LOCATIONS BUG
From: Gabriel Androctus
There is no equipment in the game that I have found to fit the
four new wear locations, and it crashes the mud if they are used
before being fixed. Viewing characters wearing items with these
wear locations causes the mud to crash.
From: Barak Taylor
In mud.h #define MAX_WHERE_NAME 22 needs to be changed to
#define MAX_WHERE_NAME 26
Change where_name in act_info.c to
" ",
"missile wielded ", <--- add a comma
"worn on back ", <--- add the next 4 lines
"worn on face ",
"worn on ankle ",
"worn on ankle " <--- no comma here
(NOTE: These places in the code actually have the greaterthan
and lessthan symbols placed around the wear location words..
but my html editor is giving me trouble and won't let me use
the shortcuts for them either.)
From: me(Zylara)
I changed face to before ankle as every where I found the wear
flags, face always came before ankle. Also I noticed that these
new wear locations are not added into the ibuild (menu) options
nor are they added in to grub.c.... but neither will cause any
problems, just will not be an option available for choosing.
-----------IMMHOST AND PASSWORD PROBLEM
From: "David Lear" thelears@erols.com
We resolved the problem. Seems as though one of the implementors
was trying out immhost. He had added two sites for his character.
This seemed to cause the problem. The immortals that were on when
he set his site info were able to continue logging on. The others
became unable to, they received the "incorrect password" message
when attempting to log in. As soon as we removed the immhost data,
everyone was able to log in. Uri
From: Nivek---Kevin London
Realms uses immhost.c and it works just fine. Have you changed
the code at all? The code I have, says Wrong password, not
incorrect password. I did fix some things in immhost but I can't
remember if I did them before or after the 1.4 release. Either
way 1.4a should be out soon.
---
From: Xantha
okie, immhosts are nice, with one small problem.
I set up a host for my imm, Xantha. typed immhost, and it showed
the host I could use.. That's wel and good, but sometimes I log in
from a different host. I just wanted to see how it worked.
immhost delete xantha 127* doesn't work to get rid of it.
From: Kevin London
First you can add multiple hosts for one immortal.
IE immhost add xantha 127*
immhost add xantha 281.21.2.3
Or whatever. Then any of those hosts will be allowed.
Also that is a quirk I forgot to fix
immhost delete xantha 127 should get rid of it
(IE it doesn't strip the *) Nivek
-----------RACIAL LANGUAGE BUG
I get bug reports of "Invalid racial language: Nanny"
mostly in character creation. How do I fix it?
From: me(Zylara)
The directions are given as if you have not added any new races
or languages yet. The reason for this is Gnomes does not have a
language setting (set to 0), in the ../dist/races/ dir open up
the gnome race file and set it's language to 1048576. Then go
into act_comm.c, all the way down to the
bool can_learn_lang just before
int countlangs add in gnomes here, like this:
LANG_CLAN, LANG_GITH, LANG_GNOME, LANG_UNKNOWN };
and add it here too, right below the first part:
"halfling", "clan", "gith", "gnome", "" };
In mud.h where the languages are, right under races, add:
#define LANG_GNOME BV20 /* Gnome Language */
right under the gith one. Then right below that in VALI_
LANGS add: | LANG_HALFLING | LANG_GITH | LANG_GNOME )
Then make clean and make to put your changes in, log on
to the mud and do the following:
sset create skill gnome
slookup gnome to find the sn of it
sset 265 type tongue this was the # on mine
sset 265 guild -1
sset 265 code spell_null
sset save skill table
Then you need to go into all the class files in your
dist/classes dir and give them each the new language,
what level they get it at, and what their adept % is.
Which means adding the line between gith and goblin:
Skill 'gith' 1 99
Skill 'gnome' 1 99
Skill 'goblin' 1 99
If you want you can go into ../dist/system/tongues.dat
and create the different sounds of the language, or it
will just use the default one.
--------------MAX CLASSES and CHOOSING SEX AT CREATION CRASHES
From: sammael@bigred1.rconnect.com
I have discovered that when new chars enter the game, I seg
fault and drop no core. Following a step by step log dump, I
find that my game seg faults on one of these lines from comm.c:
case m: case M: ch->sex = SEX_MALE; break;
case f: case F: ch->sex = SEX_FEMALE; break;
case n: case N: ch->sex = SEX_NEUTRAL; break;
-
From: Matthew mshirey@vetmed.wsu.edu
It appears that you can have MAX_RACE set to a number that is
actually greater than the number of Races that you have but
MAX_CLASS must be set to exactly the number you plan to use.
I get a core dump if MAX_CLASS is not set right.
-
From: me(Zylara)
Smaug 1.4 crashes when the MAX_CLASSES in mud.h is not properly
set, usually after the 'what's your sex' question in the new
character's creation. The paladin and nephandi classes are not
working so change the MAX_CLASS to 8 if you don't want to use the
paladin class, 9 if you do. Paladin is useable but Nephandi is
unfinished. Make the following changes:
mud.h
#define MAX_REXITS 20
#define MAX_SKILL 400
#define MAX_CLASS 9 <-------- change to 8
#define MAX_NPC_CLASS 26 or leave at 9
#define MAX_RACE 15 and include
#define MAX_NPC_RACE 91 paladins
If using paladin, you may want to add the paladin to places it
has not been added...like act_obj.c for part of the 'object not
useable by' code, and other things like antiwarrior flag. Do a
grep for warrior or cleric to find the places. To clans.c and
also make them a guild, if you are using the guilds.
-
Kevin London wrote:
I am adding it so that won't happen with MAX_CLASS and also so
that you will be able to do everything online. Should be out
in the next release which should be out -soon-, depending on
how long it takes me to write some of the docs. Nivek
-----------------PALADINS TAKING DAMAGE IN PRE-AUTH
When a player comes in as a paladin, they start taking damage
right off because of their alignment. Also Paladins have not
been added to the program in the pre-auth area, so they do not
get a weapon when they exam the weapon chest in the tree.
From: me(Zylara)
To stop this you only need to set their alignment up a little,
in comm.c in the case CON_GET_NEW_CLASS section add these two
lines, you can set the # on what ever you want (1000 to 350):
if ( toupper(arg[0]) == toupper(class_table[iClass]->who_name[0])
&& !str_prefix( arg, class_table[iClass]->who_name ) )
{
ch->class = iClass;
if ( ch->class == 8 ) /* add these two lines */
ch->alignment = +500; /* to stop paladin damage */
break;
}
For the program on object 104 (the weapon chest), just opedit
the chest in room 104 to add a line for the paladin class:
command: opedit 104 edit 1
17 if class ($n) == Warrior
18 or class ($n) == Ranger
19 or class ($n) == Paladin <----add this line
20 mpoload 127 1
Other things for paladins...add a program on Mistress Tsythia
for the paladins coming into the game, so hvak1 will get an answer
from hvak2 about who is entering these realms.
You will also need to mpstat Silvina in the newbie academy and
add to the program a section for paladins and build on a hall for
the paladin class. As it is right now the paladins just sit there
because there is no hall for Silvina to portal them to.
-----------------VAMPIRE IN LIMBO.ARE
From: me(Zylara)
On running the startup or smaug:
Sun Sept 19 23:46:58 1998 : Reading in area files...
(help.are)
Exception: STATUS_ACCESS_VIOLATION (or somthing close to this)
This is caused by mob #80 from limbo.are, to fix it I compared
smaug 1.02a limbo.are with the 1.4...a difference in this line:
1.02a has a line- 67 3 0 0 1769236847 1769236846 0
1.4 has- 67 3 0 0 0 0 0
In the limbo.are file I just changed 1.4 so it looked like 1.02a
67 3 0 0 0 0 0
to look like this:
67 3 0 0 1769236847 1769236846 0
-----------DEITY ERRORS
From: Tavolir
Last night when I first ran 1.4 it started core dumping on me. I
looked in the log file and it had stopped just after loading the
deity files. I looked in the code and found the following in db.c:
log_string( "Loading councils" );
load_deity( );
log_string( "Loading deities" );
load_councils( );
These are around the wrong way so change them to:
log_string( "Loading councils" );
load_councils( );
log_string( "Loading deities" );
load_deity( );
This is NOT the bug but it does help to keep the logs straight.
The bug lies in the /dist/deity/deity.lst file which reads:
test.dty
$
There is some problem with the test.dty file, so remove the
reference to it, so the deity.lst file reads:
$
And the core dumps should go away.
From: me(Zylara)
This comes up when loading deities:
Wed Jul 29 :: Loading deities...
Wed Jul 29 :: test.dty
Wed Jul 29 :: [*****] FILE: $ LINE: 0
Wed Jul 29 :: [*****] BUG: Fread_deity: no match: Avatar
Wed Jul 29 :: [*****] FILE: $ LINE: 0
Wed Jul 29 :: [*****] BUG: Fread_deity: no match: 0
Wed Jul 29 :: [*****] FILE: $ LINE: 0
Wed Jul 29 :: [*****] BUG: Fread_deity: no match: Deityobj
Wed Jul 29 :: [*****] FILE: $ LINE: 0
Wed Jul 29 :: [*****] BUG: Fread_deity: no match: 0
Wed Jul 29 :: $
Wed Jul 29 :: Done deities
The correct vnums for the avatar and deity object are:
As defined in mud.h
#define MOB_VNUM_DEITY 17
#define OBJ_VNUM_DEITY 64
If these two are created in limbo.are you won't get the
FILE: $ LINE: 0 BUG: Fread_deity: no match: Avatar lines.
---------------MISSING BODY PARTS AND OTHER LIMBO.ARE VNUMS
From: me(Zylara)
If you have players saying that a spell does not work, then
you are probably missing a spell object that is suppose to
be in limbo.are. So along with all the bodyparts from the
email below I have also added the whole list of objects you
need to have created in limbo.are. Right off of olist 1 99.
From: Ryan supfly@geocities.com
I noticed that if you killed certain mobs you would get the
death_cry: invalid vnum bug. So I looked through the code
and figured out that the invalid vnum was for bodyparts that
were not included with limbo.are, but still included in the
part_vnums array. So here it is, if you are missing one of
these object vnums and one of your mobs is set to have that
bodypart, you get the bug when it dies and that bodypart is
called for.
2) coin gold (a gold coin)
3) coins gold (%d gold coins)
10) corpse (the corpse of %s)
11) corpse (the corpse of %s)
12) head (the head of %s)
13) heart (the heart of %s)
14) arm (the arm of %s)
15) leg (the leg of %s)
16) guts (the spilled guts of %s)
17) blood (the spilled blood)
18) bloodstain (the bloodstain)
19) scraps (the scraps of %s)
20) mushroom (a magic mushroom)
21) ball light (a bright ball of light)
22) spring (a magical spring)
23) skin (a skin of %s)
24) meat fresh slice (a slice of raw meat from %s)
25) shopping bag (a bag)
26) bloodlet (bloodlet)
30) fire (a magical fire)
31) trap (a trap)
32) portal (a portal)
33) black poison powder (black poisoning powder)
34) scroll scribing blank (a blank scroll)
35) flask empty (an empty flask)
36) parchment paper note (a note)
37) quill pen (a quill)
43) holy symbol faith (a symbol of faith)
44) brains (the brains of %s)
45) hands hand (a hand of %s)
46) foot feet (a foot of %s)
47) fingers (the fingers of %s)
48) ear (the ear of %s)
49) eye (the eye of %s)
50) tongue (the tongue of %s)
51) eyestalks eyestalk (an eyestalk of %s)
52) tentacles tentacle (a tentacle of %s)
53) fins fin (a fin of %s)
54) wings wing (a wing of %s)
55) tail (a tail of %s)
56) scales (the scales of %s)
57) tusks (the tusks of %s)
58) horns horn (the horn of %s)
59) claws (the claws of %s)
63) extrademinsional portal (an extrademinsional portal)
64) sigil deity symbol (the symbol of %s)
80) feathers (the feathers of %s)
81) forelegs foreleg (a foreleg of %s)
82) paws (the paws of %s)
83) hooves (the hooves of %s)
84) beak (the beak of %s)
85) sharpscales (the sharpscales of %s)
86) haunches haunch (the haunch of %s)
87) fangs (the fangs of %s)
99) final object (a newly created final object)
For most of the bodyparts all you have to set on each one is
its short, long, type, weight, level 0, and if you want it to
be set as food you need to add the wear take flag, value0's
setting, and an actiondesc if you want it to have one. Just
oinvoke a heart or guts and ostat them to see their settings.
You also need to create the mob # 17 for the deities avatar,
if you have not made it yet.
-----------------WATCH
The watch command is inhibited by the fact that the ../watch
directory is not included with the distribution.
From: Kevin London
Oops, just make the watch dir and that should work.
--------------PLANES and PLANES.DAT file
From: Rjael mud@mini.axcomp.com
Tue Jul 28 19:34:55 1998 :: Reading in plane file...
../system/planes.dat: No such file or directory
Tue Jul 28 19:34:55 1998 :: [*****] BUG: load_planes: can't
open planes file for read.
From: Altrag
Started on it but we got the "no new projects so we can clean
this thing up to release" message before i did much with it,
basically its just a couple pointers and a couple functions.
From: me(Zylara)
To fix this error just go into ../dist/system/ and create a file
named planes.dat and in it put a: #END same as morph.dat file.
-----------------POLYMORPH
From: Rjael mud@mini.axcomp.com
While having its own .c file, does not have any but the mpcommands
in commands.dat. There is no revert command in tables.c. This may
not be a bug, but its a feature that everyone wanted to play with.
From: Kevin London
The new code does not have a revert command anymore it is off of a
timer that you put on the morph. There is an immortal command morph
and unmorph that will work, as well as the spell polymorph that
checks to make sure you can morph into the thing.
From: Moclamoose@aol.com
Since the commands are already in the code all you have to do,
in this order:
cedit morph create
cedit morphstat create
cedit morphcreate create
cedit morphset create
cedit morphdelete create
cedit save cmdtable
i hope this helps....Morph is pretty cool Megaboz
------------------CLAN/GUILD VAULTS
From: Rjael mud@mini.axcomp.com
Clan vaults not found.
I noticed there isn't a Paladin guild setup for the Paladin class.
Vaults also a fixit feature of 1.02a.
From: me(Zylara)
To fix the SMAUG clan vault errors seen in the startup log. The
easiest way to fix the 'can not open clan vault' is to GOTO each
of these rooms and drop a ball light or something else simple.
21434 21178 21188 21071 21210 21139 21240
21144 also in this room, the thieves guild storeroom, type:
redit flags clanstoreroom then do foldarea newdark.are
smaug 1.2a and 1.4 do not have the thieves clanstoreroom set.
---------------SKIN CODE
From: LrdElder tdison@swetland.net
I don't know if this is the reason it was not installed already,
but there is a bug in it, where a player can skin corpses as often
as they like. Also you have to setup the actual skin itself. If I
remeber right it should have the object vnum of 23.
cedit skin create do_skin
cedit skin level <---level you want it to be set as
cedit save cmdtable
From: me This skill also needs a little more work.
----------SOME BUILDING COMMANDS HAVE CHANGED LEVELS
From: xantha@mud3.gator.net
If your character logs in and the mud crashes, here's a posible
explanation for it. At least I know it's what was causing mine.
The new code restricts loadarea and savearea to level 54 (and a
few other things). So, if your player is a creator and at level
53, when they try to log in, the game loads their area. Well,
since they aint the level they should be, the game goes into a
tissy and throws everybody out. Solution: Raise them a level.
Either that or adjust loadarea and savearea. I know since I did
it, mine quit crashing.
From: me(Zylara)
It is prolly a good idea to check and set ALL your building/Imm
commands and make sure they are set to the level you want them at.
As well as setting each help file to the same level as the command.
Open up commands.dat and help.are...or use cset, cedit, restrict,
and hset commands, while loged onto your mud. Don't forget to use
the file saving commands cset save, cedit save cmdtable, hset save.
--------------MPADVANCE only works if person doing it is level 58/+
From: Rjael mud@mini.axcomp.com
mpadvance is now crippled, but sufficiently high mobs can still be
forced to advance/demote at will.
One quick note: I looked back at the command which worked to demote
someone, and here it is...
force puff mpforce rjael advance self 2
A signifigantly high mob can demote or advance a player through
this chain. I imagine that it should work in both directions, with
advancing and demoting at will. I just did this with a 60th level
character to achieve level 65.
force puff mpat dorian mpforce dorian at rjael advance rjael 65
Now granted, the imm has to be on. But if you know what you're doing
you can bump the imp before he realizes anything has happened. Then
you just clean the wizlist and you've taken over a mud.
From: Kevin London
Yes but immortals less than level 58 can not force a mob to do any mp
commands. In an up and coming release when you switch into a mob you
won't do mpcommands but there are reasons to allow that for now, so
just don't give switch or level 58+ to untrusted imms. Nivek
-----------PAGER COLOR
From: Cronel pejro@sion.com
I found d->pagecolor is never initialized. So until some function
sets it (such as do_who for instance) your d->pagecolor is 0 (black);
this will cause pages 2 and subsequents of everthing you get through
the pager (such as help files) to be invisible. In 1.2, this was
initialy set in the CON_PRESS_ENTER case in nanny.c, so I just fixed
it by calling set_pager_color(white) there.
*********************** IMC STUFF ***********************
Since I removed IMC from 1.4, I am not sure what the exact fix is
for the IMC lock errors, so I will just include what info I have.
Problem:
gcc -c -O -g3 -Wall -Wuninitialized -DREQUESTS -DSMAUG imc.c
imc.c: In function `lock_prefix':
imc.c:1085: warning: implicit declaration of function `lockf'
imc.c:1085: `F_TLOCK' undeclared (first use this function)
imc.c:1085: (Each undeclared identifier is reported only once
imc.c:1085: for each function it appears in.)
imc.c: In function `unlock_prefix':
imc.c:1102: `F_ULOCK' undeclared (first use this function)
*** Error code 1 Stop. *** Error code 1
---
From: Altrag
try flock
---
From: Gerry Smith
On FreeBSD 2.2.6, add an #include for unistd.h
in imc.c: replace line 1084
if (lockf(imc_lock_file, F_TLOCK, 1) <0)
with
if (flock(imc_lock_file, LOCK_EX) <0)
and line 1101
lockf(imc_lock_file, F_ULOCK, 1);
with
flock(imc_lock_file, LOCK_UN);
Morpheus
---
From: "Charles H. Gucker" cgucker@toof.net
Might just want to add that to the imc.h file the alias
F_TLOCK LOCK_EX
F_ULOCK LOCK_UN
for BSD machines, much like we have for sun.
---
From: "Charles H. Gucker" cgucker@toof.net
For anybody who wishes to get imc working, please read the following:
Imc uses one directory
In this directory, you should find the following files:
config
icec
iced
lock
mail-ids
mail-list
mail-queue
rignores
If you are missing any of these files, please make them.
There is one file that needs to be setup for the configuration
of Imc to work, the others are files maintained by Imc itself.
In the Config file, Please cut and past this, as a refference.
# Version config_file_version
# LocalName local_imc_name
# LocalPort local_imc_port
# InfoName long name of mud
# InfoHost host and port #
# InfoEmail admin email contact
# InfoWWW mud web site
# InfoFlags imc flags (use hide for building ports to "hide" it)
# Connection Name:Host:Port:ClientPW:ServerPW:RcvStamp:NoForward:Flags
here's a mock config file.
Version 1 --should be set to 1 on all muds
LocalName Storm --IMC Mud Name (the "short" name Imc uses
for you mud, try to keep lessthan 8 chars)
LocalPort 4691 --Imc Port, an "odd" port not used by players
InfoName Storm:&r Call of the Knight&w --long name of mud can use
&color codes
InfoHost storm.org port 4000 --host name and port number
InfoEmail wisdom@storm.org --admin email contact
InfoWWW www.storm.org --web site addy if appl
Connection hub2:hub2.imc2.org:9010:BjASUAkL:7AhjaYaQ:0:0:reconnect
--Connection info setup by Imc, so you don't
need to touch
[FYI, a Real config file won't have the spaces and no --comments]
Now, to get this information (passwords and all), Please send an
email to help@imc2.org with the following information:
Your Muds Name: (long name)
Your Muds Requested Imc Name: (shorter than 8 chars please)
Your Muds Game Port #: (I.E. 4000 )
Your Muds Imc Port #: (the "odd" port # (semi random))
And any other specific questions that are not answered in the
help imc or help ice files.
Also, if anybody is interested in information on how to run a "hub"
and help offset some of the load on the main hubs, please also
ask. Charlie Imc Network Admin
********************UPDATE TO 1.4 BUG/FIX LIST*******************
First update to the bug/fix list May 27th 99:
--------------'LANGUAGE' COMMAND LOOKING IN WHOLE MUD
From: Cronel pejro@sion.com
So I was just idling, looking at code for the heck of it in
act_comm.c, do_language, then noticed something strange. In
do_language, when you try to learn a language, the code is
supposed to look in the room for a teacher. Well, it actualy
looks in the whole mud. I tested it. I loaded a mortal,
transferred him to another mob (Domick) and had him type
"lang learn elvish".. And the mud replied "Abbigail tells you
..(etc)". So it found Abbigail even though she's in the other
room. Here's the culprit (around line 3081 in act_comm.c):
for ( sch = ch->in_room->first_person; sch; sch = sch->next )
if ( IS_NPC(sch) && xIS_SET(sch->act, ACT_SCHOLAR)
&& knows_language( sch, ch->speaking, ch )
&& knows_language( sch, lang_array[lang], sch )
&& (!sch->speaking || knows_language( ch, sch->speaking, sch )) )
break;
Notice the first, line, it's "sch->next" when it should be
"sch = sch->next_in_room". That's it. --cronel
------------------------ALARM CLOCK
From: Cronel pejro@sion.com
Ok recently this player from Australia, I think, started triggering
my ALARM thing, which is in comm.c. But he triggered it over and over
and over, and so I was able to see that the ALARM anti-lag mechanism
was not really working as it should because of a very minor detail.
This ALARM thing is supposed to report the section of code where it
found the lag (where the signal went off). This is why all over the
new_descriptor() function there are statements like
alarm_section = "accept";
But someone's fingers slipped and instead of showing this section it
just concatenates the local buffer to itself so you end up with like
ALARM CLOCK! In section ALARM CLOCK! In section ALARM (and so on)
which is very funny to see as it happens, heh. Anyway to fix it just
change this, in comm.c, line 427, in function caught_alarm():
sprintf(buf, "ALARM CLOCK! In section %s", buf );
into this:
sprintf(buf, "ALARM CLOCK! In section %s", alarm_section );
Just a very small thingy, and I'm not even sure this alarm deal is
actualy very useful.
------------------'COMMANDS' COMMAND GLITCH
From: Jose Luis Sogorb jlalbatros@mx2.redestb.es
When you type "commands" to see all commands available, those
beggining with 'm' ( or 'p' as second letter) do not appear.
In act_info.c (in do_commands function), it says:
&& (command->name[0] != 'm
&& command->name[1] != 'p')
but I think it must be:
&& (command->name[0] != 'm'
|| command->name[1] != 'p')
Tell me if I am right ;)
--
From: Altrag altrag@realms.game.org
He's right.. it (currently) says, if the first letter is NOT
a 'm' AND the second letter is NOT a 'p'.. ie:
!m && !p
which reverses to mean (trust me, if you dont know yer boolean ops):
m || p
So we're skipping it if the first letter is an 'm' -or- the second
letter is a 'p'. We want to be skipping if the first is a 'm' -and-
the second is a 'p'. * Altrag (Altrag@game.org) *
--
From: Cronel pejro@sion.com
Right. Note that this leaves the following commands visible:
mea (mpechoat)
mer (mpeachoaround)
mez (mpechozone)
What I did was check the code string instead of the name, ie:
strncmp("do_mp", 5..) --cronel
In act_info.c change to look like these:
if ( command->level < LEVEL_HERO
&& command->level <= get_trust( ch )
&& (command->name[0] != 'm'
|| command->name[1] != 'p')
if ( command->level < LEVEL_HERO
&& command->level <= get_trust( ch )
&& !str_prefix(argument, command->name)
&& (command->name[0] != 'm'
|| command->name[1] != 'p')
---------------SMALL "CHECK_TOTAL_BANS" ANNOYANCE
From: Cronel pejro@sion.com
while this probably has nothing to do with phaedra's
bans not working, i was looking at the ban code because of that
and i discovered this little thing;
there are two functions to check for bans, check_bans and
check_total_bans. the first is used to check all types of bans
but it takes a character; the second is used before the character
name is known (when the descriptor is accepted) and of course
it only checks level 65 site bans (no character, hence no level
or class information).
i wont bore everyone with how site bans are checked since
everyone can see it in ban.c, suffice it to say that depending
on the presence and position of wildcards in the host being
banned, it calls str_cmp, str_suffix, str_preffix and strstr.
well, as it so happens, while in check_bans everything is checked
fine, in check_total_bans str_suffix is being called when
str_prefix should be and viceversa.
this will result in that level 65 site bans with wildcards
only at end or start of the host string (not both) will not take
effect until the player enters the character name and check_bans
is called. as you see no biggie, just thought i'd report it.
to fix it just:
line 1102 of ban.c should be changed from
if ( pban->suffix && !str_suffix( pban->name, new_host ) )
to:
if ( pban->suffix && !str_prefix( pban->name, new_host ) )
and viceversa, line 1113 of ban.c should be changed from:
if ( pban->prefix && !str_prefix( pban->name, new_host ) )
to:
if ( pban->prefix && !str_suffix( pban->name, new_host ) )
thats all. --cronel
--------------MENTALSTATE PROBLEM WHEN FIGHTING WIMPY MOBS
From: gfinello@mail.karmanet.it
I just discovered a problem in the 'damage' function, module fight.c:
if ( dam > victim->max_hit / 4 )
{
act( AT_HURT, "That really did HURT!", victim, 0, 0, TO_CHAR );
if ( number_bits(3) == 0 )
worsen_mental_state( ch, 1 );
}
if ( victim->hit < victim->max_hit / 4 )
{
act( AT_DANGER, "You wish that your wounds would stop BLEEDING
so much!", victim, 0, 0, TO_CHAR );
if ( number_bits(2) == 0 )
worsen_mental_state( ch, 1 );
}
The two worsen_mental_state calls should be called upon the victim...
not the hitter. Otherwise YOUR mst will be screwed for hitting your
opponent too hard, while it's supposed to be the other way around.
Change them to:
if ( dam > victim->max_hit / 4 )
{
act( AT_HURT, "That really did HURT!", victim, 0, 0, TO_CHAR );
if ( number_bits(3) == 0 )
worsen_mental_state( victim, 1 );
}
if ( victim->hit < victim->max_hit / 4 )
{
act( AT_DANGER, "You wish that your wounds would stop BLEEDING
so much!", victim, 0, 0, TO_CHAR );
if ( number_bits(2) == 0 )
worsen_mental_state( victim, 1 );
}
----------------------POISON WEAPON/DUAL-WIELD BUGS
From: gfinello@mail.karmanet.it
Searching through the code for the causes of a weird bug, I ended
up finding another two. They are both related to the use of poisoned
weapons. Like the "fights and mental state" bug I previously
discovered, the negative effect of a poisoned weapon's successful hit
is directed toward the wrong target too. Here is the code block.
fight.c:damage
if ( dam > 0 && dt > TYPE_HIT
&& !IS_AFFECTED( victim, AFF_POISON )
&& is_wielding_poisoned( ch )
&& !IS_SET( victim->immune, RIS_POISON )
&& !saves_poison_death( ch->level, victim ) )
{
AFFECT_DATA af;
af.type = gsn_poison;
af.duration = 20;
af.location = APPLY_STR;
af.modifier = -2;
af.bitvector = meb(AFF_POISON);
affect_join( victim, &af );
ch->mental_state = URANGE( 20, ch->mental_state
+ (IS_PKILL(ch) ? 1 : 2),100 );
}
The last line should be changed to :
victim->mental_state = URANGE( 20, victim->mental_state +
(IS_PKILL(victim) ? 1 : 2), 100 );
--------
As for the second bug, look at the if's condition. It calls in
the if_wielding_poisoned function and here is its code :
bool is_wielding_poisoned( CHAR_DATA *ch )
{
OBJ_DATA *obj;
if ( (obj=get_eq_char(ch, WEAR_WIELD)) != NULL
&& IS_OBJ_STAT(obj, ITEM_POISONED) )
return TRUE;
return FALSE;
}
This function returns TRUE only if ch is wearing a poisoned weapon
in the "wear_wield" position. This means that if ch is wielding a
normal weapon and dual-wielding the poisoned one, the poison effect
of the second one will never kick in. Not even on a mob that will be
hit only with the poisoned one (ie. piercing) because immune to the
normal one's damage type (ie. slashing). If we swap the two weapons,
BOTH will show poisonous capabilities, without the deteriorating
effect on the normal one that poison would impose. The hit messages
will depend on the "wear_wield" position too.
Unfortunately for this bug I have not a quick solution, due to
my lack of time right now (it has been a busy week). If you want to
try it the problem is : one_hit(), that decides which one of the two
weapons will be used, does not tell it to damage(), that handles of
the venomous weapon effect, and dam_message(), that handles the hit
messages. Only the damage type info (blasting, piercing etc.) is
passed between them, so the last two are forced to obtain the
weapon's poisoned status with is_wielding_poisoned(), that is
probably older than the dual-wield skill. Dam_message() can be fixed
quickly enough but damage() is called more often in all the codebase,
so it requires more attention and testing to avoid solutions that
will apparently work well, then crash in unforeseen situations.
Good luck.
--
From: Benjamin M. Walsh s0206237@monmouth.edu
The function is_wielding_poisoned only checks the persons wielded
weapon, if they are dualwielding it doesn't check the second weapon.
You need to add a second if statement after the first:
if ( (obj=get_eq_char(ch, DUAL_WEAR_WIELD)) != NULL
&& IS_OBJ_STAT(obj, ITEM_POISONED) )
return TRUE;
-Zanthus
--------------CRASH IN "RESET" COMMAND WHEN SWITCHED
From: Cronel pejro@sion.com
One of my builders noticed a bug in "reset"... It's very visible and
very reproducible... do this:
- goto any mob in the game
- switch into the mob
- type "reset"
- kaboom......
Yes of course, Its the "I'll access pcdata without checking if the
guy is switched" bug we all know ... :) The offending lines are:
line 1053, reset.c:
if ( !pArea )
pArea = ch->pcdata->area;
line 1058, reset.c:
else
pArea = ch->pcdata->area;
and line 1007, reset.c
if ( pArea && pArea != ch->pcdata->area && pArea !=
ch->in_room->area )
My fix was to disallow use of the reset command while switched, but
you may wanna fix it in other ways, such as having it find the area
anyway like;
pArea = !IS_NPC(ch) ? ch->pcdata->area :
((ch->desc && ch->desc->original) ?
ch->desc->original->pcdata->area :
NULL);
etc.. --cronel
------------"RESET EDIT" HEADACHE
From: MudPrince MudPrince@aol.com
If a builder puts more than one object into a container, then
types instazone, only the first object is reset into the container.
When I try to fix this, by manually adding resets, I run into this
I type: reset edit 47 put 102 201
It does exactly what I want it to, but instead of editing
reset #47, it always edits reset #1. (First in the list)
-
From: Cronel pejro@sion.com
It's in edit_reset, look:
if ( !str_cmp(arg, "edit") )
{
argument = one_argument(argument, arg);
if ( !*arg || !is_number(arg) )
{
send_to_char( "Usage: reset edit \n\r", ch );
return;
}
if ( !(pReset = find_reset(pArea, aRoom, num)) )
{
send_to_char( "Reset not found.\n\r", ch );
return;
}
(more code for "reset edit (blah)" follows..)
As you see it's obvious that the number string is parsed into
"arg", and then it uses "num" to find the reset. But "num" is never
initialized (to atoi(arg)), and since it's assigned 0 at the beginning
of the function, "reset edit" will *always* edit the first reset no
matter what. Amazing bug! Amazing in the sense that it's incredible no
one has seen it yet, everyone must be using insta(zone/room).
As it is obvious, all that you need to do is insert the line:
num = atoi(arg);
*before* the line:
if ( !(pReset = find_reset(pArea, aRoom, num)) )
I checked other parts of the same function (delete, and other
reset commands) and they are all ok as far as parsing the number
goes. This one's the only one. --cronel
-----------------------FUNKY 'E' RESETS
From: Cronel pejro@sion.com
A player went into a Thieves Alley room in Darkhaven (vnum 21063),
and found he could "get ring" even though there was no visible
ring in the room and also upon getting the ring from the ground,
it was auto equipped to position finger ("worn on finger"). I went
to investigate and found that the ring wasn't even visible to a 65
imm. Went into the code and voila, it was a bug in the reset code,
of the 'E' reset. I don't think this was ever reported or noticed
before, so here's how it goes;
In that room, there are two resets. One of them is the thief that
roams around Darkhaven (vnum 21052). The last one equips the ring
(vnum 21055) to this thief (an E reset). However, the ring is
prototype, and the thief is not.
In an E reset the object is first loaded, then given to the mob
with a call to obj_to_char() and then equipped to the mob with a
call to equip_char(). However, obj_to_char refuses to give a proto
item to a non proto mob. The call fails. Then equip_char is called
without checking if the previous call succeeded; equip_char() doesn't
check that the object being eqipped is actualy in the inventory of
the character, and sets the object and the char as if everything was
ok. One of the things that it does is set the obj->wear_loc to the
given wear location (finger in this case). This explains both the
object being invisible in the room and the auto-equipping of the
object when you get it.
So in short what this will produce is that if there is a reset of
a proto item being equipped to a non-proto mob, the object will
be left lying on the ground with all sorts of weird side effects.
And we got first an area bug, fixable by removing the proto flag
from object vnum 21055, and second a code bug, that I would fix by;
around line 1382 of reset.c (case 'E' of reset_area()), modify
it like this (to fix the reset bug):
obj->level = URANGE(0, obj->level, LEVEL_AVATAR);
obj = obj_to_char(obj, mob);
if ( pReset->command == 'E' )
{
if( obj->carried_by != mob )
{
bug( "'E' reset: can't give object %d to mob %d.",
obj->pIndexData->vnum, mob->pIndexData->vnum );
break;
}
equip_char(mob, obj, pReset->arg3);
}
lastobj = obj;
break;
and around line 1322 of handler.c, at the beginning of equip_char()
add this (to catch other instances besides the reset bug):
if( obj->carried_by != ch )
{
bug( "equip_char: obj not being carried by ch!" );
return;
}
--cronel
--------------------DREADED 95 SKILL TRASHING BUG
From: Kilth DruidDarky@aol.com
The 95's are out to get me!
Well.. after having a bug reported, i looked into the skills: feed,
steal, ect.. After looking at the reported problems.. such as BP
needed to use the feed skill? I looked at the Mana: and it read 95..
suddenly.. I was surrounded by 95's. Round, Mana, Slot.. those had
95's.. all the max learns for it were at 95.. I see a pattern
repeating in the skills table, but not everything is set to 95.
What exactly causes this little problem? Thanks. Kilth
--
From: "Rustry" rustry@dxcc.com
Look at the following 1.4 code:
struct skill_type
{
char * name; /* Name of skill */
sh_int skill_level[MAX_CLASS]; /* Level needed by class */
sh_int skill_adept[MAX_CLASS]; /* Max attainable % in this skill*/
sh_int race_level[MAX_CLASS]; /* Racial abilities: level */
sh_int race_adept[MAX_CLASS]; /* Racial abilities: adept */
Should not race_level and race_adept be dimensioned at MAX_RACE?
With all the chat about adding races and classes on this list in the
past month or so, how come nobody has picked up on this? Or am I
REALLY missing something here???? Thanks, Rustry
--
From: Cronel pejro@sion.com
A little while ago someone posted a msg asking for help cause they
were getting the dreaded "skill trashing" bug wich is associated with
adding classes (trashes skills with the value 95 all over the place).
The fix for this was discovered inadvertently by Rustry back in
november! He found a bug, didn't know it was this bug. Like a day
later Altrag realized it and sent a short post.
The bug consists in that, inside the "skill_type" structure, the
new "race_level" and "race_adept" arrays (which make racial skills
happen) are dimensioned by MAX_CLASS, not by MAX_RACE. And throughout
the code they are accessed as if they had MAX_RACE items. So if you
have more races than you have classes, some part of the skill will be
trashed. The bigger your ( MAX_RACE-MAX_CLASS ) is, the more that
will get trashed.
In stock code I think there's 15 races and 9 classes so you will
get at least the next 3 or 4 members of the skill trashed.
The catch, I think, is that this is overwritten *before* the
code reads the skill from the skills.dat file (this happens in
fread_skill(), tables.c). So for some fields you may not notice that
they were trashed at all; most notably the code, which is *allways*
read or set to something, so I don't know if this bug could account
for people's "code" being set to some invalid hex address instead of
its proper do_kick or whatever... But yes it could account for skills
like vampire skills which don't have mana, and get their mana set to
95, if you have enough races added, etc....
Anyway all you have to do is go to mud.h, search for this:
struct skill_type
{
char * name; /* Name of skill */
sh_int skill_level[MAX_CLASS]; /* Level needed by class */
sh_int skill_adept[MAX_CLASS]; /* Max attainable % in this skill */
sh_int race_level[MAX_CLASS]; /* Racial abilities: level */
sh_int race_adept[MAX_CLASS]; /* Racial abilities: adept */
and change it to this:
struct skill_type
{
char * name; /* Name of skill */
sh_int skill_level[MAX_CLASS]; /* Level needed by class */
sh_int skill_adept[MAX_CLASS]; /* Max attainable % in this skill */
sh_int race_level[MAX_RACE]; /* Racial abilities: level */
sh_int race_adept[MAX_RACE]; /* Racial abilities: adept */
Then make clean, make. --cronel
-------------------SLIST FULL OF MOB PROGRAM LINES
From: Mud Admin mudadmin@rocketmail.com
Ok, I was in room 21014, typed slist, and saw the following on slist:
SPELL SKILL LIST
------------------
Level 1
Skill: aggressive style Current: 100 Max: 95
MinPos: answer $r, an intrepid Ranger ...
endif
if class($r) == augurer
mpat hvak2 mpfor hvak2 answer $r, a novitiate
Augurer ...
endif
mpechoat $r ...Please leave north to experience the Darkhaven Academy.
mpechoat $r ...You may now "save" to make your character permanent.
endif
Skill: cook Current: 100 Max: 95 MinPos: fighting (defensive)
Skill: kick Current: 100 Max: 85 MinPos: fighting (berserk)
Anyone know how to fix this bug? Thanks.
--
From: Cronel pejro@sion.com
What triggers this are skills with invalid values in their "minpos".
So surprisingly enough, it's related to the preexisting bug I posted
earlier, which trashed skills, "minpos" being one of the fields it
trashed even in stock SMAUG versions (without any modification to
races or classes). However, the bug only exists in 1.4, not in 1.02a.
It's this, in do_slist, act_info.c, there is a switch that sprintf's
a string to "buf", about the minpos of the skill being listed. If it's
POS_STANDING, it prints "standing" to the buffer, and so on.
However, this switch doesn't have a default case, meaning that if
the minpos is set incorrectly, it will never set "buf" to anything,
leaving it with its original value. Later on, thus "buf" is output to
the player.
The "original value" of a buffer like "buf", which is a non-static
local buffer, can be virtualy anything. Whatever is on the stack at
the point where the function is called will become the value of the
buffer. I've checked and found that the "comlist" of all progs is
actualy copied to another local buffer, in the function "mprog_driver"
in mud_prog.c, so it's totaly possible that the contents of that
"hvak" mud prog are there on the stack when do_slist is called.
Also, this "original value" will be visible only for the first
skill with an incorrect minpos. As soon as a skill with a correct
minpos is found, "buf" is filled with the string corresponding to
it, so the next incorrect skill will be showing that value (seemingly
correct, but not really).
So as you see this explains all the "symptoms". I went into
skills.dat and voila, the "agressive style" skill has an invalid
minpos (a value of 195 in the file, which is loaded as 95 when the
mud is run... definitely invalid, and obviously trashed by the 95
bug). So everything checks out.
What I'd recommend is a) fixing the other bug that trashes skills
and b) adding a default case to the switch so even if there are
trashed minpos for other reasons, the buffer is filled with something
and it's exposed with a bug() line.
For b) just look for this code in act_info.c, inside do_slist:
switch (skill_table[sn]->minimum_position)
{
case POS_DEAD:
sprintf(buf, "any");
break;
and change it into this
switch (skill_table[sn]->minimum_position)
{
default:
sprintf(buf, "Invalid");
bug( "do_slist: skill with invalid minpos, skill=%s",
skill_table[sn]->name );
break;
case POS_DEAD:
sprintf(buf, "any");
break;
--
From: me Zylara
After fixing these two bugs, your slist -in the academy- will give
you a long Log: [*****] BUG report. Since most of the weapon and
language skills will be messed up you will need to go into
../dist/system/skills.dat
and reset the minpos on any skills that are reporting invalid ones.
--------MAX_WHERE_NAME--------setrace hp_regen/mana_regen
From: Ron Kinney minex@dod.hpi.net
I was examining some of the parameters for the races when I came
upon hp_regen and mana_regen. These are unimplemented in SMAUG 1.4,
but the code does read/write to the race file. I thus decided to go
ahead and implement it myself. However, I want to make the stats
store a percentage value (ie, 50, 100, 200, etc).
set_race human hp_regen 100
set_race human save
-->This causes the mud to crash.
BUT
set_race human mana_regen 100
set_race human save
-->This does NOT cause the mud to crash.
The two pieces of code look almost identical. Does anyone else's
mud have this problem? I can't seem to figure out what is causing
the crash. Minex
---
From: Cronel pejro@sion.com
This is an off-by-one error that produces a stray pointer, which is
the reason we only see it now (stray pointer = erratic). It's somewhat
related to the old where_names bug in a uhm conjectural way...
Here's the scoop. The actual bug is in line 1627 of tables.c,
in this for (function write_race_file):
for ( i = 0; i <= MAX_WHERE_NAME; i++ )
fprintf( fpout, "WhereName %s~\n",
race->where_name[i] );
The race->where_name[] array is actualy MAX_WHERE_NAME items
long. As you see it accesses from 0 to MAX_WHERE_NAME, because of
the "<=" (should be "<") so it's basicaly an off-by-one error. It
tries to access one more element than there really is.
So why hasn't this showed up before? Because there's something
bellow the array (in memory); you guessed it, the "mana_regen" and
"hp_regen" members. So what's happening is this. Whenever you save
a race, it tries to access one more member of where_names, and finds
mana_regen/hp_regen. Since these are 0 most of the time, and
where_names is a pointer to char, they are interpreted as a pointer
to char; it results as NULL. And this NULL is sent to fprintf, which
prints it as "(null)". So if you've ever saved your races (and not
modified mana_regen/hp_regen), go to your .race files and you'll
see a line like:
WhereName (null)~
But as Minex said, if you modify hp_regen or mana_regen it crashes,
or doesn't... What happens is simply that the now non-zero
hp_regen/max_regen get interpreted as a pointer to char. So
fprintf() sees it as a non-NULL pointer, and tries to write the
string there... So as in all stray pointer bugs, Anything Can
Happen (TM), it can point to an invalid memory location (and it
crashes) or it points somewhere valid (and it prints trash to the
file, as I've seen happen).
The easy fix is simply to change the "<=" into a "<". Also see
around 1806, there's a would-be bug in the opposite direction
(while loading the race);
if ( wear < MAX_WHERE_NAME+1 )
{
race->where_name[wear] = fread_string_nohash( fp );
++wear;
}
else
bug( "load_race_file: Too many where_names" );
The first line should be;
if ( wear < MAX_WHERE_NAME )
I say this is the easy fix because it is my impression that whoever
coded it got confused as to the number of elements in the arrays and
the number of wear locations. This confusion stems from the fact that
there is both a MAX_WHERE_NAME and a MAX_WEAR. So it's related to the
old wear_names bug as reported on Zylara's bug list. So, to me, the
real fix would be to completely get rid of MAX_WHERE_NAME, by making
both the global array "where_names" and the "where_names" arrays
inside the race structures be MAX_WEAR items long, and modify the
three instances in tables.c where MAX_WHERE_NAME, change them to
MAX_WEAR.
Of course you don't *need* to do this because the actual bug is
fixed by changing the "<=", but my point is that the
MAX_WHERE_NAME/MAX_WEAR confusion is what caused the introduction
of the bug in the first place (IMHO) so just delete it if you plan
to finish coding the race edition or something related to it...
--cronel
---
From: Roger Libiez samson1@aviastar.net
Be aware of one thing when fixing this also, if you've saved any
race files, they'll all need to be fixed before you reboot the mud
after compiling the bug fixes. Otherwise you'll end up with a bunch
of errors in your logs as it tries to parse the now invalid extra
Where_name entry. And those regen entries will likely also be
worthless and need to be reset to something sane. I'm going over
mine now, and it decided to stick some rather nasty values in there,
some positive, some negative. And the where_name entries it chose
to randomly grab are proving rather interesting :P
-------------SOME CSET CONFIGURATIONS NOT SAVING
From: Cronel pejro@sion.com
I just remembered this one I found some time ago when I
tried to lower the level to get objects without take flag.
Certain fields of the system data are never actualy saved
to sysdata.dat, resulting in that they're not persistent
across reboots even if they're modifiable via cset...
I looked at the whole sysdata and to save_sysdata/load_sysdata
and found that the only two that seemed like they should be
saved and arent being saved are "level_getobjnotake" and
"imc_mail_level". I also found that "imc_mail_level" cannot
be cset, and that there's a "max_sn" that is never being used
as far as I can tell.
Hope it makes it into 1.4a --cronel
------------CON_GET_NEW_CLASS or WARRIOR DEFAULT FIX
From: Tandaur tandaur@ix.netcom.com
Ok, i recently came across a bug in the class selection during
character creation. The way stock is, if you enter an invalid
class name ie. L, it will set your class to 3 (defaults to warrior).
The way i fixed it is basically to do the same check for invalid
races in CON_GET_NEW_RACE. Here is the little fix:
in comm.c in the CON_GET_NEW_CLASS case, in nanny.
after :
for ( iClass = 0; iClass < MAX_CLASS; iClass++ )
{
if ( toupper(arg[0]) == toupper(class_table[iClass]->who_name[0])
&& !str_prefix( arg, class_table[iClass]->who_name ) )
{
ch->class = iClass;
if ( ch->class == 8 ) /* stop paladins from getting messed by */
ch->alignment = +500; /* having too low an align to start with */
break;
}
}
add :
/* patryn / tandaur - ok lets fix this wrong class thing */
if ( iClass == MAX_CLASS || class_table[iClass]->who_name[0] =='\0' )
{
write_to_buffer( d,
"That's not a class. \n\rWhat IS your class? ", 0 );
return;
}
NOTE: you might not have that paladin align fix in your code,
so don't freak out if it isn't in there.
Other small problems -- pre-auth and missing help files.
---------------------MORE PALADIN STUFF
-------------SPELL SOLOMONIC INVOCATION ALWAYS FAILS
From: G.S.Wilson gswilson@home.net
I'm having trouble with the spell 'Solomonic Invocation'. Everytime
I try and cast it, it says 'I failed'. I'm the right lvl, my skill
is 95% and i'm a good (1000) human Paladin.
-
From: me Zylara
If you do a slookup 'solomonic invocation' you can see that the
value, which is the vnum of the object create by this spell, vnum
65 does not exist.
Flags: 16384 Guild: -1 Value: 65 Info: 520 Code: spell_smaug
^^^^^^^^vnum 65
So you just need to create object vnum 65 in limbo.are and use the
slookup see what some of the setting need to be...like it is a light
that is a silver cross. A Paladins holy symbol needed for casting
some of the spells a Paladin gets.
Here is how mine looks...prolly not like RoDs but its only an example.
ostat 65
Name: paladin holy silver cross symbol
Vnum: 65 Type: light Count: 1 Gcount: 1
Serial#: 1309 TopIdxSerial#: 1309 TopSerial#: 1309
Short description: a gleaming silver cross
Long description : A holy cross lies here, gleaming brightly.
Wear flags : take hold
Extra flags: glow magic bless metal
Magic flags: none
Number: 1/1 Weight: 2/2 Layers: 0 Wear_loc: -1
Cost: 0 Rent: 0 Timer: 0 Level: 8
In room: 0 In object: (none) Carried by: Zylara
Index Values : 0 0 -1 0 0 0.
Object Values: 0 0 -1 0 0 0.
Affects wisdom by 2.
Affects affected_by by 4. --------(detect evil)
Affects intelligence by 2.
You may want to add a program that only lets Paladins wear it.
---------------------PALADIN NULL TITLES
From: DruidDarky@aol.com
Paladins don't have titles past (forgets what level) but after
I think 40 or 45, they start using the Immortal Titles. Open
your class file for Paladins, and think of some titles to insert;)
Kilth
-
From: me (Zylara)
All I did on this was copy and paste the next to last few titles
out of Cleric and Druid, since they are both the same and pasted
them into the right place in the Paladins class file found here:
../dist/classes/paladin.class then at the end of that same file
I deleted the last few title that where set to NULL. 6 titles.
Remove these: Add these before Imm titles start:
Title Title
(null)~ Avatar of an Immortal~
(null)~ Avatar of an Immortal~
Title Title
(null)~ Avatar of a Deity~
(null)~ Avatar of a Deity~
Title Title
(null)~ Avatar of a Supremity~
(null)~ Avatar of a Supremity~
Title Title
(null)~ Avatar of an Implementor~
(null)~ Avatar of an Implementor~
Title Title
(null)~ Master of all Divinity~
(null)~ Mistress of all Divinity~
Title Title
(null)~ Avatar~
(null)~ Avatar~
-----------NEPHANDI RESTRICTION/problem if you add more classes
From: "Benjamin M. Walsh" s0206237@hawkmail.monmouth.edu
Don't know if this was reported yet or not, but in 1.4 you still
have the alignment check for the nephandi class. This means that
when someone creates new classes in addition to the old ones
their 10th class will have the following restriction:
In update.c comment out as follows:
/* Nephandi alignment restrictions -h */
/* if(ch->class == 9)
{
if(ch->alignment>-250)
{
set_char_color( AT_BLOOD, ch );
send_to_char( "Damn you heathen! Go forth and do evil or
suffer the consequences!\n\r", ch );
worsen_mental_state( ch, 35 );
return;
}
} */
The above statement should be removed/commented out unless it
fits with whatever new class a person makes. Also, there is a
restriction on paladin alignment that should be removed by anyone
who is creating entirely new classes. -Zanthus
-------------MAGIC MISSILE AND FEATHER IN PRE-AUTH
From: Jaroslav KUBU kubuj@mvcr.cz
My players are not able to use the feather, found in pre-auth.
When they zap it on target in battlegrounds, they got answer :
You aim a purple feather at a carrion crawler.
Aim in what direction?
--
From: gfinello@mail.karmanet.it
The 'purple feather' is a normal spectral gate's object. It's
a staff with some charges of 'magic missile', an attack spell.
Unfortunately in the stock 1.4 that spell has been released with a
wrong target type. If you type slookup 'magic missile' you will
find it has a target of type 'ignore'. Also on RoD it was meant
to have a 'ranged attack' capability (note the range field in the
slookup response), but this caused some problems and it was disabled.
To correct the problem do an slookup 'magic missile' to obtain the
'sn' number of the spell (should be 107), then type:
sset (sn) target offensive
sset (sn) range 0
sset save skill table
Just changing the target should make it work, but it's better to
set the range to zero too.
-------PIXIES NOT BEING SEEN BECAUSE OF FLYS NOT BEING FLIES
From: "Ferret" smaug@roadpizza.com
Is there a bug about Pixies, specifically Pixie Mages, not
getting keys when they are done with the validate section?
If there is, how do I fix it? Thank you. . - Claude
---
From: me Zylara
In 1.02a flys was spelt wrong and it was corrected in 1.4 to
read flies...so you need to find all of the wrong spellings
in the programs that where already in the stock areas. I only
found these listed below in the newgate.are file, out of all
the stock areas:
aassign none
aassign newgate.are
in room vnum 120
mset 106 flags prototype
mpedit 106 list
mpedit 106 edit 4 act p flies north.
/s
mset 106 flags prototype
in room vnum 119
mset 105 flags prototype
mpedit 105 edit 2 act p flies in from the west.
/s
mset 105 flags prototype
in room vnum 100
mset 101 flags prototype
mpedit 101 edit 3 act p flies in from below.
/s
mset 101 flags prototype
in room vnum 101
mset 100 flags prototype
mpedit 100 edit 3 act p flies in from above.
/s
mpedit 100 edit 4 act p flies in from the north.
/s
mset 100 flags prototype
aassign none
foldarea newgate.are
------------MISSING HELP FILES
These help files are missing in 1.4, so you might want to add
them into your help.are file. Use hedit and hset.
1.) FOR
Syntax: for (argument) (command)
Syntax: for (argument) (command) (target)
For allows an immortal to perform a command at or even on a large
number of targets. The arguments include: all, mobs, gods.
Example: for gods gl, you will 'glance' in the room of every god
who is online (include link-dead)
You can also perform an action on the argument target.
Example: for mobs poke #, you will perform the 'poke' social on
every mob in the game.
'For' does not override private flags.
2.) BOARDS
Syntax: boards
This command displays statistics on all boards in the game. Example:
imm.brd Vnum: 1200 Read: 50 Post: 51 Rmv: 55 Max: 50 Posts: 1 Type: 0
The first column lists the board's filename (imm.brd)
Vnum - object vnum to which the board is attached (object vnum must
be present to read the board, allowing a board to be placed in
one or many places by simply placing that object where needed)
Read - minimum level required to read that board
Post - minumum level required to post to that board
Remove - minumum level required to remove notes not addressed to 'All'
Max - maximum number of posts the board is set to hold
Posts - the current number of posts on the board
Type - 0 = note board 1 = mail board
See Also: BSTAT BSET MAKEBOARD