Zugg Software :: View topic

Posted: Thu Jun 12, 2008 2:01 am

I think that an onReconnect native event would be very nice indeed.

Wizard Joined: 26 Mar 2008 Posts: 1547

Why? If I can ask. I know my onConnect activates when it reconnects.

Posted: Thu Jun 12, 2008 2:26 am

How do you know you are re-connecting? There are things one wants to do on re-connect that may be different from the original connect, since you may already be live in the MUD. Right now I keep a flag that I reset on quit so I know whether this is the first time or not. An onReconnect event would be a lot cleaner.

EDIT: an onReconnect event would fire if CMUD detected a connection loss and then re-established then connection. The connection loss could be due to the user quitting the MUD or the connection dropping. This event would not fire if the application were closed and reopened before an attempt at connection.

Adept Joined: 27 May 2008 Posts: 299

theres some things you might want to do only onreconnect versus on a initial connect

Wizard Joined: 26 Mar 2008 Posts: 1547

Posted: Thu Jun 12, 2008 9:13 am

Make it a parameter! true if it's the first connection, false if it's any other connection :D

Posted: Thu Jun 12, 2008 9:38 am

I am already doing that. I have an ONINPUT trigger monitoring "quit" to reset the parameter. I must say that this type of methodology is rather kludgy, though effective. As I said, onReconnect would be be much cleaner. I don't think that it would take much to implement it. In fact, what would happen is that CMUD would be taking care of the flag, rather than my trigger, which would make running the application the tiniest bit faster.

Posted: Thu Jun 12, 2008 10:54 am

Why's it kludgy? The intention would be to allow the functionality you want (detecting when a connection is a reconnect) without changing the current functionality (OnConnect is raised every time it connects). Having a separate onReconnect would break scripts that're intended to be run every connection regardless of when during the session they are, and would require having two events with the exact same code. Seems perfectly sensible to me to use a single event for this purpose.

Posted: Thu Jun 12, 2008 5:17 pm

I think a parameter is a good idea. I'm already thinking of adding some more useful parameters to various events. I don't think the distinction between onConnect and onReconnect is enough to warrant an entirely new event type.

Posted: Thu Jun 12, 2008 11:52 pm

I understand what you are saying, Zugg. It was only a small wish.

As for what you said, Fang, it wouldn't break anyone's code. The onReconnect event would fire and then the onConnect event would fire, in that order. So if you didn't care about reconnection, then you just would abstain from having any thing coded for it. That's how events are handled in most systems.
However, using a native parameter on the onConnect event works just as well. Kludgy refers to my managing the parameter not CMUD.