Zugg Software :: View topic

Wizard Joined: 22 Mar 2007 Posts: 2320

I thought this was already reported, but I don't see it now. The built-in event onConnect does not seem to fire automatically. Manually raising the event works fine. I think this may have stopped working in 2.25, and as I said I thought it had already been reported. Sorry about not reporting it myself earlier.

Posted: Wed Jun 11, 2008 4:09 pm

It's probable that we'll need to see your XML. I'll test this when I'm home, but I don't expect it to reproduce.

Posted: Wed Jun 11, 2008 6:51 pm

Seems to work fine for me here, so as Fang mentioned, we'd need to see your exact event code.

I just added an onConnect event to my own session that does: #SHOW Connected
and it worked fine when I connected to the MUD.

Wizard Joined: 22 Mar 2007 Posts: 2320

Hm. I should have tested it further. It works if onConnect is in the session package. It does not work if onConnect is in a secondary package. I just tried exactly that in a new session and new package

Posted: Wed Jun 11, 2008 9:26 pm

That is true. Only the package containing the window that is connecting will get this event. Secondary packages do not have network connections, so there isn't any definition for "OnConnect" for them. The problem is that with multiple session windows, your secondary package wouldn't know which specific window was connecting, and could get called multiple times for each session window that connects.

The solution to this is to define your own event and use #RAISE in your onConnect event in your normal session package to fire the new event defined in your secondary package.

Posted: Thu Jun 12, 2008 12:13 am

This is another example, I think, where having parameters for the default events would be extremely useful. This way you can pass a ton of information to the event handler and leave the handler to decide if it should be doing anything or not. For example, the first parameter of OnConnect could be the windowname, the second the address and the third the port. You'd probably never use the latter two, but they can be there because adding more params doesn't take a lot of effort.

From there, it's up to the event handler if it wants to fire or not. If it only wants to fire when a specific window connects, it can do that by checking the first parameter. If it wants to fire any time anything connects, it can do that too. The address would maybe be useful if you share your package out - people's window names might be different, but if they're using your package they're probably connecting to your MUD.

You can use this same principle for any event. The event for the start of a walk could have the start and destination rooms and a stringlist of the path it's taking. The OnRoomXXX events could have a bunch of info about the room.

Basically, I think events need to be global - that's the point, that's how they work. An event goes off and all the handlers anywhere for that event should be run. (Except perhaps OnLoad, because some stuff still won't be loaded when this event is raised - but still, I think it could be done in the same way if you wanted to make it a rule.) If that doesn't happen, you end up having to do weird stuff like this where you're using an event that's in the right place (though you're not quite sure where that might be) to raise another event. Why not just cut out the middleman?

Posted: Thu Jun 12, 2008 12:20 am

Actually, Fang, even the onLoad event could be added to the list. My onLoad is generic enough so that I can raise it any time I want the state of operations to look like the start of the session. I agree with you 100%.

Posted: Thu Jun 12, 2008 12:30 am

The point with onLoad is that for the first thing to be loaded, it'll be raised every time something's loaded. For the last thing to be loaded, it'll only be raised once. Since you never know what order stuff is doing to be loaded in, that can cause difficulty. Practically any time you use OnLoad, then, you'd be checking %1 to make sure that it's the package that contains the OnLoad event that was just loaded and not something else. You could change the way OnLoad works, but there's a decent argument for having CMUD do that for you, if you felt so inclined.

OnConnect, on the other hand...

Posted: Thu Jun 12, 2008 12:39 am

Yeah, but the counter point is that you don't really want everyone to have to check the arguments in onLoad to determine if the event is for the current module. It would be really easy to forget to test that and end up with your onLoad firing because some other module loaded.

Oh, yeah, that's just what Fang said ;) oops.

I can see this change being made to onConnect maybe, but not onLoad.

Wizard Joined: 22 Mar 2007 Posts: 2320

Ok, I can understand the logic of the package not having a window to 'connect'. It means I can't distribute a package which does something like check a status when you connect. I brought it up as a bug because it did work for a while. I'll have to rethink this. Maybe trigger on some standard connection text.

Posted: Thu Jun 12, 2008 5:21 pm

I'm thinking of adding arguments to onConnect so that you can determine which window is connecting to which host. And it's possible that I might be able to send the onConnect event to *modules* but not to other *windows*. I'll look into it.