Question Error messages on the build port

Looks like it's a code error. The check is:

if %actor.is_pc%

And apparently the room is sent in as actor!?

Anyone know of any changes to this lately?

Rumble rebooted after the last time but I don't know who can reboot if he's not around. The closest I can get to it is if I take note of which of my triggers can actually crash the mud. I know a few of them have done it in their time, I just don't keep records of them since I try to fix them immediately.

There hadn't seemed to be any code changes before the errors but it's possible. If it happens again I can check uptime but I don't know if that would show a copyover.

How did you find the room is the actor? The unknown room field, isn't that just showing that the room trigger doesn't understand the the pc part? I'm not sure but it seems to me that the errors caused by a missing % were similar: type 2 (except I think it was sometimes type 4) unknown room field: 'is_pc' but since I didn't note them, I don't have a way of checking now other than making a bad trigger.

I rebooted yesterday.

[ Trigger: Zoo, Day, Movement Out, VNum 56013, type: 2. unknown room field: 'is_pc' ]

The error message is that %actor.is_pc% is trying to find the field "is_pc" on the %actor% variable. And, since this is a room, it fails. What is perplexing is the fact that the room is triggered with itself (or indeed another room) as the actor on a Leave type trigger!?!


I've looked in the logs. The other errors are because of a missing % at the end - easily recognisable from the error message ...unknown X field: 'foo ' with a trailing space in the description.

Thanks for the reboot. Does it look like a trigger problem? Because usually the trigger works without problems. The only thing that could be considered a problem that I've seen is 'ghost' messages where the echo will say that %actor% has left when %actor% is still there. I don't know why that happens but it's not nearly the level of thinking the room has left the room.

Thomas, could you reboot it again, please? It's doing it again. I haven't been on for a while so I don't know how long its been going on. It seems to start with the zoo and then it kinda leaks over to other zones.

I've got two main questions.
1. Isn't the zone supposed to be sleeping when nobody is there? To save bandwidth or something? Does having a global time trigger change that? The global time trigger has nothing to do with the triggers that are erroring.

2. Does it seem to be the zoo itself? I'm almost to release point but I don't want to release it if it's going to do this on other people's muds.

Krell wrote: Alternatively, perhaps it's a bug that only shows up after the mud has had a certain amount of uptime?

This seems to be very possible. Right now the uptime is:
Up since Wed Jun 25 13:28:55 2014: 38 days, 11:23
and I think the other times were quite long too. However, seems to me that the mud has been up longer times than this without problems. I don't have a way of verifying that though.

I have some new info on this situation. While working on an object trigger on the 4d buildport, I started getting error messages. The trigger was basically a copy of Rumble's Object Variables Example:
www.tbamud.com/forum/3-building/3767-tri...day-object-variables
which I was using to compare variables (it turns out that 4d does not use all these variables).

While I was working, error messages started flying past, like:
[ Trigger: Test Trigger, VNum 20999. unknown char field: 'carried_by' ]

I then went through my usual procedure of examining the trigger, the object, the errors then moving on to panicking and examining them all again from this point of view. I detatched the trigger, I sacc'd the item and the errors continued. I logged off and logged in again, in case it was me (ie cursed by the trigger gods). This didn't work very well since I couldn't tell if the errors continued without me. I switched the numeric arg to 0, disabling the trigger while keeping it around for study. The next day I decided to add extra echos and found out that the trigger had apparently attached itself to something else.

Anyone who has worked with me knows that I'm capable of making terrible errors. However, I don't think this was me.

It's also been pointed out to me that attaching and detaching isn't as good as adding a script by edit. I can agree with this but I do find it much more convenient for testing.

When you attach, there's a safe message which tells you which trigger you've attached to what:
attach obj 20999 20999
Trigger 20999 (Test Trigger) attached to a test object [20999].

It's really hard to accidentally change
attach obj 20999 20999
to
attach mob 20999 21000
especially without noticing the info line.

I really think that somewhere along the line, the program added 1 to my 20999 and switched obj for mob and attached the trigger itself. I also think the tba has been doing the same thing. Since it's attached, not edited, reboot kills the attachment. The fact that it happens when I'm not even working on the zone seems to indicate that it isn't my accident.

What I need to do now is wait until the next time it happens and add in some echos like:
/i 1 %at% %parna% %echo% My vnum is %self.vnum%!

Of course, now that I've worked this out, I'm probably not going to see those errors again, just to drive me crazier!