Gammon Forum : SMAUG : SMAUG coding : Actflags causing crashes [SWR]

Log on

Gammon Forum

Entire forum

SMAUG

SMAUG coding

Actflags causing crashes [SWR]

Actflags causing crashes [SWR]

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3

Posted by

Gatewaysysop2 USA (146 posts)

bio

Date

Reply #30 on Mon 23 May 2005 02:48 AM (UTC)

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

top

Posted by

Evre (19 posts)

bio

Date

Reply #31 on Mon 23 May 2005 03:02 AM (UTC)

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.

top

Posted by

Gatewaysysop2 USA (146 posts)

bio

Date

Reply #32 on Mon 23 May 2005 03:34 AM (UTC)

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

top

Posted by

Evre (19 posts)

bio

Date

Reply #33 on Mon 23 May 2005 03:46 AM (UTC)

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.

top

Posted by

Gatewaysysop2 USA (146 posts)

bio

Date

Reply #34 on Mon 23 May 2005 04:08 AM (UTC)

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

top

Posted by

Evre (19 posts)

bio

Date

Reply #35 on Mon 23 May 2005 04:18 AM (UTC)

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.

top

Posted by

Gatewaysysop2 USA (146 posts)

bio

Date

Reply #36 on Mon 23 May 2005 05:47 AM (UTC)

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

top

Posted by

Nick Cash USA (626 posts)

bio

Date

Reply #37 on Mon 23 May 2005 07:07 AM (UTC)

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

top

Posted by Samson USA (683 posts) bio

Date Reply #38 on Tue 24 May 2005 03:57 AM (UTC)

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.

top

Posted by

Evre (19 posts)

bio

Date

Reply #39 on Tue 24 May 2005 04:47 AM (UTC)

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!

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.

80,716 views.

This is page 3, subject is 3 pages long: 1 2 3

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.