[DGD] Adding a door to a room

[Arjen]

Bart,

You are absolutely right. I have to get used to the concept that driver and
mudlib are two separate things.
I'm indeed using Gurbalib. But this is a mailinglist about DGD driver, so I
think I will try to find the answer myself or somewhere else.

But it is indeed the exact kind of error you pasted below. Even on the same
line (217) in the file /std/modules/m_messages.c

I think that it is an initialization sequence issue. The call to
simple_action is premature. The door object itself is not yet placed in the
inventory of the container object (room) the moment the function is called.

Thanks for your help so far.

Arjen

-----Original Message-----
From: dgd-bounces at dworkin.nl [mailto:dgd-bounces at dworkin.nl] On Behalf Of
bart at wotf.org
Sent: vrijdag 26 februari 2010 21:29
To: All about Dworkin's Game Driver
Subject: Re: [DGD] Adding a door to a room

>From a first glance, I'd think your guess is right, but I'd need a bit more
info.

While I can make a few guesses, its better if you provide the following
additional info:

- what mudlib are you using with DGD? The features you are looking at are
completely handled by the object library (mudlib), and not by DGD, so
without
this information people can at best comment on your question with guesses.

- most mudlibs, including the one I think you are using, provide much more
error information then you posted. On gurbalib, you'll find such info
usually
in /log/errors/runtime, but when using the update command, it should appear
on
your screen directly. Anyway, a complete error would look something like
this:

Bad argument 1 for kfun call_other
Object: /sys/obj/player#173, program: /std/modules/m_messages, line 217
  21 _F_call_out       /kernel/lib/auto (/sys/obj/player#173)
  13 _F_call_out2      /kernel/lib/auto (/sys/obj/player#173)
 566 do_quit           /sys/lib/player (/sys/obj/player#173)
 217 simple_action     /std/modules/m_messages (/sys/obj/player#173)

If you want people to look at this, you should really provide a complete
error, and as said, the mudlib you are using, if this is some standard part
of
it, or, post a copy of your code online somewhere (do not send it as
attachment to the mailinglist, that will not work) so people can look at it,
else this is really just guesswork.


On Fri, 26 Feb 2010 16:23:19 +0100, Arjen wrote
> All,
> 
> I have a question regarding the use of (i think) room events/messages?
> 
> I stumbled upon a problem when adding a door object to a room. The drivers
> keeps throwing "Bad argument 1 to kfun call_other".
> 
> I could narrow it down to the function call to
> m_openable::set_open_state(state). In the Create function of the door
> object, this method is called. It looks like it fails on
> m_messages::simple_action call, because the environment of the door 
> is not yet initialized.
> 
> Can somebody confirm this? If so, than i'm finally going to 
> understand DGD a bit more :-)
> 
> But the real question i have is about the messages that are send 
> back and forth. What does the call to m_messages::simple_action 
> actually do? Is that call also responsible for calling the function 
> door::do_on_open() ? I'm getting a bit lost in the concept of events 
> / room messages and stuff. Can somebody point me into the right 
> direction? Is there documentation about these parts of DGD that I missed?

Those things are part of the object library (mudlib) running on DGD, not of
DGD itself. If you are using the lib I think you are using then no, there
isn't too much documentation on this part.

The general idea however is that events provide a generalized way to
communicate things like players moving, doors opening/closing etc etc etc.
An
object can define events, and other objects can then subscribe themselves to
such events. Subscribers will be notified of the event being triggered. I
believe events are a common design pattern.

Events are triggered when something happens, a simple action MAY cause an
event but doesn't have to, and not all events are caused by the m_action
module, they are all over the place as a generic way to inform other objects
that something happened, where something can be things extremely visible to
players, but also things deep inside the system that you won't see at all as
a
player.

By far the best documentation, and the only definite answers in such cases
are
in the code itself.

Regards,
Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/

___________________________________________
https://mail.dworkin.nl/mailman/listinfo/dgd