[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  SMAUG
. -> [Folder]  SMAUG coding
. . -> [Subject]  Actflags causing crashes [SWR]
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Actflags causing crashes [SWR]
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  3  

Posted by Evre   (19 posts)  [Biography] bio
Date Tue 24 May 2005 04:47 AM (UTC)  [ quote  ]
Message
That did the trick. Flags are setting properly now! Again, thanks to everyone who helped me with the problem. I pray I didn't try your patience /too/ much.

For those who need to perform the bugfix as well, the erroneous instance appears twice, the first one starting near line 1939 in my build.c (Under do_mset), and the second one underneath the next parent else statement a few lines down.

With that bug out of the way, I can get the project back on track! Yay!
[Go to top] top
Posted by Samson   USA  (683 posts)  [Biography] bio
Date Tue 24 May 2005 03:57 AM (UTC)  [ quote  ]
Message
Took another really close look at this, and compared it to a non-FUSS SWR package and I think the fault may well lie with me on this one :)

The fault lies in build.c in the flags section where the TOGGLE_BIT calls are made. As they are posted in the bad code, they are:


TOGGLE_BIT( victim->act, value );


They need to be:


TOGGLE_BIT( victim->act, 1 << value );


Taking note of the 1 with the 2 less-than signs before the value. That makes all the difference. Toggling the value directly is why it's changing seemingly unrelated bits. Toggling with the added part, it only affects the flag you tried to change.

This is a direct result of one of the SMAUG FUSS fixes being ported across to SWR/SWFOTE improperly. The issue it intended to address was fixed but this bug was introduced by accident.
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Nick Cash   USA  (626 posts)  [Biography] bio
Date Mon 23 May 2005 07:07 AM (UTC)  [ quote  ]
Message
Just wanted to say I've used SWR for a long time and never had a problem such as this.
~Nick Cash
http://www.nick-cash.com
[Go to top] top
Posted by Gatewaysysop2   USA  (142 posts)  [Biography] bio
Date Mon 23 May 2005 05:47 AM (UTC)  [ quote  ]
Message
All of your backups have this bug? How far back do they go then? Do you only have backups to a point or do you have them all the way back to the stock code?

More imporantly, can you reproduce this in un-touched, stock code? If so that would be of prime interest to whoever maintains the particular SWR codebase that you're using because it may be an actual bug.

If not, that is if you cannot reproduce this in a freshly downloaded copy of the codebase, you definitely introduced the problem with something you did.

I don't know SWR, don't use it, but I'm still gambling that you somehow and most unintentionally introduced this with a change you made. Been there, done that, several times in fact. It happens.

So in short, please check if you can reproduce this with a stock version of the codebase you are using. That's probably the best place to start if all your backups have this issue.

Wish I had better advice but I think we need to know for sure if this was a stock issue or something you introduced.

"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence
[Go to top] top
Posted by Evre   (19 posts)  [Biography] bio
Date Mon 23 May 2005 04:18 AM (UTC)  [ quote  ]
Message
Unfortunately, all of my backups have the bug, I just hadn't noticed it until recently, so that's out of the question. I'll run GDB and see if I can't grab the value of "value".

I looked through the forums earlier for some tips on changing the languages, classes, and races. I changed all instances of WOOKIEE to TEST_SUBJECT or SHADOW depending on whether or not it was a race or language reference (The names are placeholders at this point, so excuse their foolishness). When I said "Text Strings" I meant I changed messages sent to the players like "You feel a disturbance in the force" would be changed to "You feel something is amiss" - things like that.
[Go to top] top
Posted by Gatewaysysop2   USA  (142 posts)  [Biography] bio
Date Mon 23 May 2005 04:08 AM (UTC)  [ quote  ]
Message
Maybe what would be of interest is whether or not "value" is somehow different from what it should be.

Like I said, try going back through any backups you have until you can no longer reproduce the problem. That should give you at least a rough idea of what change introduced this so you'll know more specifically about what the issue may be.

What exactly did you change to do with text strings, by the way? I don't know that that has anything to do with this, but it could so that information might be useful.
"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence
[Go to top] top
Posted by Evre   (19 posts)  [Biography] bio
Date Mon 23 May 2005 03:46 AM (UTC)  [ quote  ]
Message
I don't suppose you (or anyone else reading this) knows what "flow" the data takes when setting a flag? Like... it hits the handler... handler references to the mud.h code... and from there it goes to the build.c code. I realize this isn't exactly how it works, but there's a course the data takes via stacks and whatnot (that's what I gather from reading through GDB's backtraces, anyway). So any advice on how to trace through the MSET code would be greatly appreciated. (I've already checked the do_mset in build.c to no avail.)

This line of code,
else
TOGGLE_BIT( victim->act, value );
is actually the bit that /sets/ the flag, isn't it? So would that imply an issue with the way TOGGLE_BIT is set up? I'm pretty well lost at this point so I'm trying to get any help I can.
[Go to top] top
Posted by Gatewaysysop2   USA  (142 posts)  [Biography] bio
Date Mon 23 May 2005 03:34 AM (UTC)  [ quote  ]
Message
You mentioned somewhere back about something to do with changing text strings? It's a longshot, but not knowing what you did at all, I would say that may be something to look at.

Beyond that, all I can say is try any backups you have and see how far back you can reproduce the problem. When you hit a wall and it stops happening, you should know exactly what you did and hopefully you'll be able to fix it without having to completely revert to stock.

In all honesty, there's probably a simple explanation for all this, no doubt a single change somewhere that went awry. It shouldn't be all that hard to fix once you narrow it down.

Hope that helps.
"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence
[Go to top] top
Posted by Evre   (19 posts)  [Biography] bio
Date Mon 23 May 2005 03:02 AM (UTC)  [ quote  ]
Message
It is quite useful, however I'm running into trouble trying to isolate the exact source of the issue. Do you possibly know how the flags are set/toggled? I've only found two areas where the code is defined and that's in build.c and mud.h (And mud.h simply defines). GREP just turns up a bunch of build.c references, but when I look in there I fail to see anything obviously wrong. You've all helped me a great deal and it's doubtful I would've been able to narrow it down so far without the direction given here.

You've my thanks, everyone.
[Go to top] top
Posted by Gatewaysysop2   USA  (142 posts)  [Biography] bio
Date Mon 23 May 2005 02:48 AM (UTC)  [ quote  ]
Message
Uhm...

You just said *exactly* what I was asking you to check for, whether or not you realize it. I quote you:

Quote:

Apparently when I set the PROTOTYPE flag, several flags are set (As I suppose they're supposed to be) - Among them are "sentinel" "scavenger" "r3" and "r3" (it displays twice).


This is, almost without a doubt, your problem. Obviously you're setting more flags than you want to be, and quite possibly you're un-setting flags that you shouldn't be in the process. When you set the prototype flag, that should be the only one that changes. That's how it's SUPPOSED to work. You should never have multiple flags setting themselves/unsetting themselves after you MSET a particular single flag on something/someone.

You need to figure out what it was you changed that caused this problem, because it is almost assuredly the root cause of your crashes.

Beyond that, and as I said earlier, having a crash when it tries to read pcdata from a mob, and having it crash because a mob goes linkdead (should never happen), that seems like an obvious indication that somehow your NPC flag is being stripped or something. The fact that you have flags being set/unset like this when you never toggled them in the first place lends strong credence to this possibility.

I hope you find this useful. :)
"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence
[Go to top] top
Posted by Evre   (19 posts)  [Biography] bio
Date Sun 22 May 2005 05:27 PM (UTC)  [ quote  ]

Amended on Sun 22 May 2005 11:04 PM (UTC) by Evre

Message
Still in the process of figuring out exactly what's going on, but I thought I'd go ahead and share some newer issues. Apparently when I set the PROTOTYPE flag, several flags are set (As I suppose they're supposed to be) - Among them are "sentinel" "scavenger" "r3" and "r3" (it displays twice). The R3 flag is just a placeholder isn't it?

Well, I've tried most of the flags and only prototype neglects to cause a crash. Another curious thing is that after I set the prototype flag on an NPC, I set him to AGGRESSIVE as well. This is what I got;

mset guard flags aggressive
Build: Evre: mset guard flags aggressive

vnum:<#2000> / wizinvis: 0
look
Research Facility Kierkeguard - Foyer {2000[indoors]
The cool, calm ambience of the room accents its mixture of lavish oak and steel furnishings. The room itself is of fair size for a foyer. Paintings of pleasant landscapes dot the light blue walls, perforated with simple half-oval light fixtures that give off a soft white glow toward the smooth white ceiling.
Obvious exits:
North - Research Facility Kierkeguard - Entryway
(Link Dead) (Blue Aura) A security guard stands watch here.

He went /link dead/. o.O A few moments after that the MUD crashed, which is strange as well because there was a delay this time. Is this common behavior for NPCs? And, on that same token, what exactly does the blue aura imply? I had assumed prototype but when I checked my secretary, who doesn't have the prototype flag, she's got a blue aura as well.

- EDIT -

Rather than double post, I'll just add on to what I've already posted... The bug's been there for as long as I can recall, actually, though I don't have any backups dating back before I first starting changing text strings, but I do recall that a few days after I first got the MUD running I logged on and tried to show a friend how to create a "monster" but the MUD kept crashing. I didn't realize it at the time but it was because I was setting the AGGRESSIVE flag.

I tried changing the thirst/hunger code back to normal, but the bug persists. Lacking any other option, I'm going to go through and post anything relevant to flag setting -

In build.c
if( IS_NPC( victim ) )
{
value = get_actflag( arg3 );

if( value < 0 || value >= 31 )
ch_printf( ch, "Unknown flag: %s\n\r", arg3 );
else if( 1 << value == ACT_PROTOTYPE && ch->top_level < sysdata.level_modify_proto )
send_to_char( "You cannot change the prototype flag.\n\r", ch );
else if( 1 << value == ACT_IS_NPC )
send_to_char( "If the NPC flag could be changed, it would cause many problems.\n\r", ch );
else
TOGGLE_BIT( victim->act, value );
}
else
{
value = get_plrflag( arg3 );

if( value < 0 || value >= 31 )
ch_printf( ch, "Unknown flag: %s\n\r", arg3 );
else if( 1 << value == ACT_IS_NPC )
send_to_char( "If the NPC flag could be changed, it would cause many problems.\n\r", ch );
else
{
ftoggle = TRUE;
TOGGLE_BIT( victim->act, value );
}
}
}
if( ftoggle )
send_to_char( "Flags set.\n\r", ch );
if( IS_SET( victim->act, ACT_PROTOTYPE ) || ( value == ACT_PROTOTYPE && protoflag ) )
victim->pIndexData->act = victim->act;
return;

In mud.h (for the TOGGLE_BIT code)
#define SET_BIT(var, bit) ((var) |= (bit))
#define REMOVE_BIT(var, bit) ((var) &= ~(bit))
#define TOGGLE_BIT(var, bit) ((var) ^= (bit))

(ACT flag structure from mud.h is posted earlier in this thread so I won't bother reposting it.)

That's all the relevant code I can think to find at the moment. If I'm spamming with too much of this stuff or if I'm not heading in the right direction, don't hesitate to tell me. Thanks.
[Go to top] top
Posted by Gatewaysysop2   USA  (142 posts)  [Biography] bio
Date Sun 22 May 2005 01:30 AM (UTC)  [ quote  ]
Message
What I was asking is exactly what was said. Namely, are you certain the flags you're trying to change are the ones being changed? Maybe if something is off, you're telling it to apply the sentinel flag but really it's adding/removing a different flag altogether. Have you tried settings flags that work and using MSTAT to see if the correct flag has been added/removed from the mob?

Also have you tried digging up a backup from before any recent changes to see if you can replicate this behavior? If not then you can be certain it was something you changed and it's only a matter of back tracking.

If you can do this even with a stock copy of the distribution, that would be of even more interest, because it would indicate that there's probably a bug of some kind.

Anyway, more information is always useful so please post again with what you've found out.
"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence
[Go to top] top
Posted by Evre   (19 posts)  [Biography] bio
Date Sat 21 May 2005 07:40 PM (UTC)  [ quote  ]
Message
I'm not certain what you're asking here so I'll just detail the problem in hopes that it'll answer your question;

Using mostly Stock SWR code (The flag coding hadn't been changed), I attempt to set a sentinel flag (aggressive does it as well, haven't tried the rest) on a self-made mob (mcreate secretary etc etc) using mset secretary flags SENTINEL, which causes the crash. The mob is one of my own making, and upon an mstat, it shows that it has the IS_NPC flag. As far as the flag code itself goes as far as checking for NPC data that isn't there, I don't see why it would if I haven't changed it from stock?
[Go to top] top
Posted by Gatewaysysop2   USA  (142 posts)  [Biography] bio
Date Sat 21 May 2005 05:14 PM (UTC)  [ quote  ]
Message
Hmmm.

Just an off the wall idea here. Are you certain the flags you intend to change are the ones being changed? Maybe it's changing the NPC flag instead, which I'm sure would cuase problems if you lifted it from an NPC. :-o

Just an idea. It would explain why it crashes on the line that checks for NPC status and then checks the con_drunk stuff. If it doesn't think it's an NPC it'll blow right past and attempt to check data that the mob does not have, which would probably cause the crash.

"The world of men is dreaming, it has gone mad in its sleep, and a snake is strangling it, but it can't wake up." -D.H. Lawrence
[Go to top] top
Posted by Evre   (19 posts)  [Biography] bio
Date Sat 21 May 2005 06:18 AM (UTC)  [ quote  ]
Message
Ah... that's happy news. The one time I get lazy and neglect to comment my changes it bites me in the rear... A lesson hard learned, I suppose.

If I recall correctly, the last change I made was to the hunger and thirst code - with the ifchecks that determine what effects to place on the player should they become too hungry or thirsty, they had a check that ignored anyone that had level = IS_AVATAR or something to that effect, so I think I changed it to apply to anyone whose level was under 1. It didn't seem like the best idea, but it did sound like the quickest way to rid myself of that horrid system.

Regardless, thank you for your time and patience.
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

7,641 views.

This is page 1, subject is 3 pages long: 1 2  3  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]