More bug fixes, new trig type login, and zone flags/levels. Thanks to Jamdog for the majority of work this release! For the full tbaMUD changelog check out: http://www.tbamud.com/files/changelog.txt
Code:
tbaMUD 3.59 changelog
[Apr 05 2009] - Rumble
Updated World and files for 3.59 release.
[Apr 02 2009] - Rumble
real_abils.str changed from 25 to 18. Since 18 is max str.
Changed ch to k in do_stat for quests. (thanks Frenze)
[Mar 14 2009] - Jamdog
Bug-Fix: real_shop function could hang if a shop was added with the max VNUM (Thanks Slicer)
Removed find_shop function, which was a duplicate of real_shop.
[Mar 13 2009] - Jamdog
Bug-Fix: Character deletion (remove_player, players.c), where the wrong player was potentially being deleted.
Added Zone Flags, including zedit sub-menu
Added Zone level restrictions, including zedit sub-menu
Added zlock and zunlock commands
Added areas command
Set GRID flag on zones 0, 12 and 30
[Mar 08 2009] - Jamdog
Fixed a possible crash bug in delete_object (genobj.c) (Thanks Slicer)
CAP function now recognises both preceeding color codes and ANSI codes (Thanks Slicer)
[Mar 07 2009] - Jamdog
Fixed a bug in find_shop (shop.c) and real_shop (genshp.c) (Thanks Slicer)
[Feb 25 2009] - Jamdog
Fixed new medit stats menu so that it uses the the Advanced/Standard cedit toggle
[Feb 24 2009] - Jamdog
Bug-Fix: Fixed levels command, so it only shows immortal level if it's in the specified range
Bug-Fix: write_mobile_espec now saves CON and CHA values for mobiles in world files
Bug-Fix: stat zone now shows the same as vstat zone (instead of show zone (num)
Bug-Fix: zone 'stat' info (print_zone, oasis_list.c) now shows the number of shops and triggers
Bug-Fix: zone 'show' info (print_zone_to_buf, act.wizard.c) now shows number of quests.
Added saving throws to write_mobile_espec (genmob.c) and interpret_espec (db.c)
Added 'whois' command for all players
medit: All numerical stats moved to new sub-menu, with 'autoroll' option
medit: Advanced or Standard stats sub-menu with cedit toggle (in Game Operations)
[Feb 17 2009] - Jamdog
Fixed a bug with %obj.extra% so that it now returns the list of extra flags
[Feb 11 2009] - Jamdog
Fixed a crash bug in count_quests (quest.c) affecting zlist (thanks Fsantin)
[Feb 05 2009] - Jamdog
Added "set name ", which renames a character, including pfile and index entry
[Feb 01 2009] - Jamdog
Changed documentation /doc unixshelladminguide to PDF format.
[Jan 31 2009] - Jamdog
Added room login trig types, to catch players logging in to a particular room
[Jan 29 2009] - Rumble
Corrected zcheck MAX_OBJ_GOLD_ALLOWED to compare against Val 0, not Val 1. (thanks Tails)
Created new MAX_OBJ_GOLD_ALLOWED define for zcheck. (thanks Tails)
Fixed typo in players.c. (thanks Tristen)
[Jan 25 2009] - Rumble
Added new documentation /doc unixshelladminguide. (thanks Jamdog).
Added new zone creation limits to prevent misuse of zedit making the MUD unbootable.
[Jan 25 2009] - Jamdog
Added cases for missing object types in oedit_disp_val1_menu (other, worn, treasure, trash, key, pen, boat)
[Jan 25 2009] - Rumble
Fixed pardon. (thanks Echos-Ironcastle)
[Jan 24 2009] - Rumble
Fixed command queue cancelling "--" from cancelling the next command. (thanks Frenze/Ogdin)
Fixed object timer values from not saving. (thanks Stoneheart)
Fixed latest GCC warnings in the /utils. (thanks Jamdog)
Fixed violent area spells so they would not harm group members. (thanks Nhilar)
Changed usage of qm->nr to GET_MOB_VNUM(qm). (thanks Tails)
[Jan 21 2009] - Jamdog
Added trigedit variable %move% to teleport objects.
Fixed memory leak in generic_complete_quest.
A bug fix to player attachable scripts.
A better fix to the DIKU double attack by ordering a mob to save its master.
Fix to remove weight restrictions for immortals.
_________________ Rumble
The Builder Academy
tbamud.com 9091
Last edited by Rumble on Mon Apr 06, 2009 11:40 am; edited 1 time in total
Joined: Jun 18, 2006 Posts: 1645 Location: Stourbridge, England
Posted: Sun Jan 18, 2009 9:02 am Post subject:
I am working through, hand-patching as usual, to debug the new code, and will post any I find here.
First one is:
Code:
diff -BburpN --exclude=.svn --exclude=world --exclude=help tbamud-3.57/src/act.item.c tbamud-3.58/src/act.item.c
--- tbamud-3.57/src/act.item.c 2008-08-12 00:54:32.000000000 +0200
+++ tbamud-3.58/src/act.item.c 2009-01-18 02:25:12.000000000 +0100
@@ -603,7 +603,7 @@ static void perform_give(struct char_dat
act("You can't let go of $p!! Yeech!", FALSE, ch, obj, 0, TO_CHAR);
return;
}
- if (IS_CARRYING_N(vict) >= CAN_CARRY_N(vict)) {
+ if (IS_CARRYING_N(vict) >= CAN_CARRY_N(vict) && GET_LEVEL(ch) < LVL_IMMORT) {
act("$N seems to have $S hands full.", FALSE, ch, 0, vict, TO_CHAR);
return;
}
This allows Imms to give stuff to players, even when the player's hands are full. I'm not sure this is the desired behaviour, but it makes a kind of sense.
Surely players should also be able to give stuff to Imms, even if the Imms hands are full.
The following change covers both situations:
Code:
- if (IS_CARRYING_N(vict) >= CAN_CARRY_N(vict)) {
+ if (IS_CARRYING_N(vict) >= CAN_CARRY_N(vict) && GET_LEVEL(ch) < LVL_IMMORT && GET_LEVEL(vict) < LVL_IMMORT) {
Also, just below this, there is another check for 'weight', which doesn't take Imms into account at all. I think that a weight check should probably be ignored in the same way:
Code:
act("$N seems to have $S hands full.", FALSE, ch, 0, vict, TO_CHAR);
return;
}
- if (GET_OBJ_WEIGHT(obj) + IS_CARRYING_W(vict) > CAN_CARRY_W(vict)) {
+ if (GET_OBJ_WEIGHT(obj) + IS_CARRYING_W(vict) > CAN_CARRY_W(vict) && GET_LEVEL(ch) < LVL_IMMORT && GET_LEVEL(vict) < LVL_IMMORT) {
act("$E can't carry that much weight.", FALSE, ch, 0, vict, TO_CHAR);
return;
}
obj_from_char(obj);
obj_to_char(obj, vict);
+ if ((FIGHTING(ch) == FIGHTING(vict)) && (FIGHTING(tmp_ch) == ch)) {
+ send_to_char(ch, "You have already rescued %s from %s.\r\n", GET_NAME(vict), GET_NAME(FIGHTING(ch)));
+ return;
+ }
+
if (!tmp_ch) {
act("But nobody is fighting $M!", FALSE, ch, 0, vict, TO_CHAR);
return;
Three things wrong with this code...
Firstly, if tmp_ch is NULL, this could cause a crash. You could either move this below the "if (!tmp_ch)" check, or add a check for tmp_ch in the if line, like:
Secondly, if you looking at the for loop above it, tmp_ch will either be NULL, or FIGHTING(tmp_ch) will be == vict. It will never == ch, so this if will always be false, and is therefore redundant code...
Thirdly, if neither ch or vict are fighting anything, then FIGHTING(ch) is NULL and FIGHTING(vict) is NULL, so because it checks (FIGHTING(ch) == FIGHTING(vict)), this will be true if neither are fighting - there should be a check for != NULL here too.
I think the following cures all three problems:
Code:
if ((FIGHTING(vict) != NULL) && (FIGHTING(ch) == FIGHTING(vict)) && (tmp_ch == NULL)) {
tmp_ch = FIGHTING(vict);
if (FIGHTING(tmp_ch) == ch) {
send_to_char(ch, "You have already rescued %s from %s.\r\n", GET_NAME(vict), GET_NAME(FIGHTING(ch)));
return;
}
}
So, using RANGE actually changes the value variable, putting it within the desired range, so if mode == 16, then value cannot be greater than 100,000,000 and so there would be no need to check for it after it's been set. value should always be equal to the actual value that was set.
My recommendation would be to keep the old code - no change is necessary. _________________
Joined: Jun 18, 2006 Posts: 1645 Location: Stourbridge, England
Posted: Sun Jan 18, 2009 11:32 am Post subject:
Another one that I think is related to allowing player-attached scripts. The following change would mean that %actor.pref(flagname)% can never return 1. This is because there is an IS_NPC(c) check at the top, so only mobs are dealt with here, so adding !IS_NPC(c) to an if means it would never reach that case, and therefore would always return 0:
To be honest, I think the first check should be for !IS_NPC(c) anyway because mobs don't have pref flags, or allow the change but remove the first check, so mobs return 0 for all pref checks, but someone else may want to verify this. My proposed fix is:
but I would appreciate a second opinion on this one, as I now have a headache, so am going to lie down for a bit, and return to this in an hour or two. _________________
Joined: Feb 02, 2004 Posts: 726 Location: Norway, Europe
Posted: Sun Jan 18, 2009 12:18 pm Post subject:
I agree that your last solution fixes the issue.
Grab an aspirin for the headache :)
GJ both Rumble and Jamdog. _________________ For all intents and purposes retired trigedit maintainer (new name for DG scripts from next version)
Build for yourself at the Builder Academy.
Joined: Nov 26, 2005 Posts: 1381 Location: Shelby Township, Michigan
Posted: Sun Jan 18, 2009 1:04 pm Post subject:
Jamdog wrote:
I am working through, hand-patching as usual, to debug the new code, and will post any I find here.
First one is:
Code:
diff -BburpN --exclude=.svn --exclude=world --exclude=help tbamud-3.57/src/act.item.c tbamud-3.58/src/act.item.c
--- tbamud-3.57/src/act.item.c 2008-08-12 00:54:32.000000000 +0200
+++ tbamud-3.58/src/act.item.c 2009-01-18 02:25:12.000000000 +0100
@@ -603,7 +603,7 @@ static void perform_give(struct char_dat
act("You can't let go of $p!! Yeech!", FALSE, ch, obj, 0, TO_CHAR);
return;
}
- if (IS_CARRYING_N(vict) >= CAN_CARRY_N(vict)) {
+ if (IS_CARRYING_N(vict) >= CAN_CARRY_N(vict) && GET_LEVEL(ch) < LVL_IMMORT) {
act("$N seems to have $S hands full.", FALSE, ch, 0, vict, TO_CHAR);
return;
}
This allows Imms to give stuff to players, even when the player's hands are full. I'm not sure this is the desired behaviour, but it makes a kind of sense.
Surely players should also be able to give stuff to Imms, even if the Imms hands are full.
The following change covers both situations:
Code:
- if (IS_CARRYING_N(vict) >= CAN_CARRY_N(vict)) {
+ if (IS_CARRYING_N(vict) >= CAN_CARRY_N(vict) && GET_LEVEL(ch) < LVL_IMMORT && GET_LEVEL(vict) < LVL_IMMORT) {
Also, just below this, there is another check for 'weight', which doesn't take Imms into account at all. I think that a weight check should probably be ignored in the same way:
Code:
act("$N seems to have $S hands full.", FALSE, ch, 0, vict, TO_CHAR);
return;
}
- if (GET_OBJ_WEIGHT(obj) + IS_CARRYING_W(vict) > CAN_CARRY_W(vict)) {
+ if (GET_OBJ_WEIGHT(obj) + IS_CARRYING_W(vict) > CAN_CARRY_W(vict) && GET_LEVEL(ch) < LVL_IMMORT && GET_LEVEL(vict) < LVL_IMMORT) {
act("$E can't carry that much weight.", FALSE, ch, 0, vict, TO_CHAR);
return;
}
obj_from_char(obj);
obj_to_char(obj, vict);
So immortals can give to players and players can give to mortals as well and not just immortals giving to other immortals. _________________ DG Script Reference Forum 4 Dimensions
So, using RANGE actually changes the value variable, putting it within the desired range, so if mode == 16, then value cannot be greater than 100,000,000 and so there would be no need to check for it after it's been set. value should always be equal to the actual value that was set.
My recommendation would be to keep the old code - no change is necessary.
that was simply because it'd set gold to 100 mil, but would say it set it to 2.14 bill anyway in the message if you used an arbitrarily large argument. _________________ DG Script Reference Forum 4 Dimensions
So immortals can give to players and players can give to mortals as well and not just immortals giving to other immortals.
But, this would make the check obsolete. If you are going to allow players to give stuff to other players regardless of whether the receiving player is able to carry the weight, then you would just remove the whole section of code that performs the check.
I think that this would be a bad thing. My change simply means that Imms are immune to weight issues, either by giving or receiving items. _________________
Joined: Jun 18, 2006 Posts: 1645 Location: Stourbridge, England
Posted: Tue Jan 20, 2009 5:03 am Post subject:
Sorry, was ill all day yesterday, so wasn't able to complete my patch checks. There are a couple more issues that I found, but I shall post each separately.
/* Macro to determine if a mob is permitted to use these commands. */
-#define MOB_OR_IMPL(ch) \
- (IS_NPC(ch) && (!(ch)->desc || GET_LEVEL((ch)->desc->original)>=LVL_IMPL))
+#define MOB_OR_IMPL(ch) (GET_LEVEL(ch) > 0)
/* mob commands */
/* prints the argument to all the rooms aroud the mobile */
@@ -286,6 +286,10 @@ ACMD(do_mzoneecho)
int zone;
char room_number[MAX_INPUT_LENGTH], buf[MAX_INPUT_LENGTH], *msg;
This is a badly thought through short-cut. MOB_OR_IMPL(ch) should return TRUE if ch is a mob, or an Implementor testing the mob by switching into it. So, it's true, if ch is a mob or impl, as the name suggests.
The suggested change will make MOB_OR_IMPL return true for any mob, player, imm or impl, it is no longer a check for MOB_OR_IMPL, so it should not be called MOB_OR_IMPL.
I think the following would be better:
Code:
/* Macro to determine if a mob is permitted to use these commands. */
#define MOB_OR_IMPL(ch) \
(IS_NPC(ch) && (!(ch)->desc || GET_LEVEL((ch)->desc->original)>=LVL_IMPL))
+#define MOB_OR_PLAYER(ch) (GET_LEVEL(ch) > 0)
This keeps the old MOB_OR_IMPL define, but creates a new MOB_OR_PLAYER define, which can be used where necessary. This will also prevent unexpected results by allowing MOB_OR_IMPL to work in it's original manner where it is required. _________________
Joined: Jun 18, 2006 Posts: 1645 Location: Stourbridge, England
Posted: Tue Jan 20, 2009 5:09 am Post subject:
This one was a good catch, preventing a memory leak. Unfortunately, it seems a bug was also introduced.
Code:
diff -BburpN --exclude=.svn --exclude=world --exclude=help tbamud-3.57/src/quest.c tbamud-3.58/src/quest.c
--- tbamud-3.57/src/quest.c 2008-08-12 00:54:32.000000000 +0200
+++ tbamud-3.58/src/quest.c 2009-01-18 02:25:12.000000000 +0100
@@ -306,8 +311,7 @@ void generic_complete_quest(struct char_
QST_EXP(rnum));
}
if (QST_OBJ(rnum) && QST_OBJ(rnum) != NOTHING) {
- if (real_object(QST_OBJ(rnum)) != NOTHING) {
- if ((new_obj = create_obj()) != NULL) {
+ if (real_object(QST_OBJ(rnum))) {
if ((new_obj = read_object((QST_OBJ(rnum)),VIRTUAL)) != NULL) {
obj_to_char(new_obj, ch);
send_to_char(ch, "You have been presented with %s%s for your service.\r\n",
@@ -315,7 +319,6 @@ void generic_complete_quest(struct char_
}
}
}
- }
if (!IS_SET(QST_FLAGS(rnum), AQ_REPEATABLE))
add_completed_quest(ch, vnum);
clear_quest(ch);
Yes, the create_object call needed to be removed, because read_object creates a new object structure anyway, thus it was being created twice. The problem was here:
Code:
- if (real_object(QST_OBJ(rnum)) != NOTHING) {
+ if (real_object(QST_OBJ(rnum))) {
NOTHING is not defined as zero, and in fact real_object(QST_OBJ(rnum)) will only be zero for the 1st quest, it doesn't return TRUE or FALSE, as this change seems to expect.
This change should not have been made - it was correct before. _________________
Joined: Jun 18, 2006 Posts: 1645 Location: Stourbridge, England
Posted: Tue Jan 20, 2009 5:12 am Post subject:
Fizban wrote:
that was simply because it'd set gold to 100 mil, but would say it set it to 2.14 bill anyway in the message if you used an arbitrarily large argument.
That shouldn't be happening with this code. I shall investigate this... _________________
Joined: Jun 18, 2006 Posts: 1645 Location: Stourbridge, England
Posted: Tue Jan 20, 2009 11:11 am Post subject:
Jamdog wrote:
Fizban wrote:
that was simply because it'd set gold to 100 mil, but would say it set it to 2.14 bill anyway in the message if you used an arbitrarily large argument.
That shouldn't be happening with this code. I shall investigate this...
Found the bug, and posted a fix here, because this should affect older tbaMUDs, and may affect CWG and Circle too. _________________
Joined: Jun 18, 2006 Posts: 1645 Location: Stourbridge, England
Posted: Tue Jan 20, 2009 2:19 pm Post subject:
Rumble has requested that I put all these fixes into a patch file, so I'm putting a link to the patch file here, so that anyone with tbaMUD 3.58 can bug-fix quickly and easily.
The 3.58 bug-fix patch can be downloaded from my skydrive. _________________
Joined: Feb 02, 2004 Posts: 726 Location: Norway, Europe
Posted: Thu Jan 22, 2009 3:32 am Post subject:
I see no problem in releasing 3.59 right away :) No need to force people to wait and make these changes themselves. _________________ For all intents and purposes retired trigedit maintainer (new name for DG scripts from next version)
Build for yourself at the Builder Academy.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
No need to force people to wait and make these changes themselves.
