Does User.onLogin Actually Trigger on a User Logging Out?

[UrsaTeddy]

The handler User.onLogin gives a signature of onLogin(username, activated).

I have no problems overriding this and doing things on the login of a user (activated = true), however it is never triggered when the user is logging out.

In addition, when a user logs out (quits the program) and I try to send an OOB message, that message is never sent (assuming that them quitting the program has unloaded all relevant classes).

Any ideas on a work around to this? I am happy to use either option, just would like a log out trigger.

... And why some might ask? Because I have a set of windows open, one per user, and thus when they leave I wish to close that window.

[Moon Wizard]

Yes, onUserLogin returns either true or false depending on whether a user is connecting or disconnecting. It will only fire on the GM client.

At the point that the user is disconnecting, you can no longer send messages to the user; since the user is already disconnected at that point.

Regards,
JPG

[UrsaTeddy]

I have tried the following scenarios ...

In all cases it is the Host who is trying to check for login/logout - no one else (at this point)

1. onInit/onClose
The user sends a disconnect OOB message which is being listened for by the Host.
The message is never received - it does receive the connect OOB message however without a problem in the onInit()

2. onLogin
The host is watching for login true/false using my own onLogin code ... it sees the connection/disconnection in that function, however it is not able to continue with some code that relies on the Session.IsHost and the activated being true/false - that is, can the host actually see the disconnection?

[Moon Wizard]

That script event is fired on the GM client at the same time that the connected/disconnected messages are posted to chat. Here's a super simple extension that triggers on that event.

Regards,
JPG

[UrsaTeddy]

Thank you for that ... it looks (in essence) identical to what I have except I am setting onLogin within a loaded LUA file rather than in the extension.xml

Would that make a difference?

[Moon Wizard]

No, it shouldn’t. Put a debug statement at the top of your function, and test with a localhost player client.

Does the extension trigger correctly?

JPG

[UrsaTeddy]

Yes I was already Debugging the onLogin. It triggers on both instances

I then have code in that function like this - note that onUserLoginPrev is a store of the previous User.onLogin function - this is mainly not to interfere with any onLogin functionality that the ruleset may have and/or another extension relies upon.

The script is NOT seeing the "ATTEMPTING TO DISCONNECT" and "EXECUTING PREVIOUS LOGIN" sections.


function onLogin(username, activated)
Debug.chat("MY ON LOGIN", username, activated)

if activated and onUserLoginPrev then onUserLoginPrev(username, activated)

if Session.IsHost
then
if activated
then
localTable.connect(username)
else
Debug.chat("ATTEMPTING TO DISCONNECT")
localTable.disconnect(username)
end
end

if not activated and onUserLoginPrev
then
Debug.chat("EXECUTING PREVIOUS LOGIN")
onUserLoginPrev(username, activated)
end

end

Should I not be testing for Session.IsHost? The problem is that the localTable variable is only instantiated for the Host as the Player does not need it.

[Moon Wizard]

OnUserLogin is only for the GM client; not for running on player clients.

JPG

[UrsaTeddy]

And the code is not running on a user client technically ... that is why I have the Session.IsHost in the code ... to ensure that even if a IsUser gets in, it will not run the code. It might be redundant but it should not stop the code from executing should it?

[Trenloe]

function onLogin(username, activated)
...

if activated and onUserLoginPrev then onUserLoginPrev(username, activated)

...

end
There's no end for this if statement. I would have expected a LUA [ERROR] saying 'end' expected (to close 'function' at line XX)

[UrsaTeddy]

oops ... I copied that from a pre-query version of the code ... it does have an end in the code.

So that is definitely not the problem.

Can you answer this question, however ... can a User send an OOB message in an onClose() event of an extension?

[Moon Wizard]

You aren’t going to be able to capture and replace other onUserLogin handlers. Once a handler is registered, it will be called, and if any handler returns true, then some handlers could be skipped.

If you want to replace a handler in another script; you will need to replace that script fully.

(Ie Multiple handlers can be registered for every handler API; and they are each called independently)

JPG

[UrsaTeddy]

So I cannot store User.onLogin in a variable and then call it before/after I call my own?

[Trenloe]

Can you answer this question, however ... can a User send an OOB message in an onClose() event of an extension?
Which onClose event? On what Object?

[UrsaTeddy]

Any object really ... I have an object (LUA file) that deals with connections to and from the game. In the onClose() event for that file, I try to send an OOB message to the Host ... will the client "shutdown" before this message is sent? Or does every bit of code execute before the closing down of the application is completed?

[jharp]

I suspect my test was faulty.

[Moon Wizard]

There are no triggers that will fire on the player client "before" the connection is shut down. Those events "do" trigger on the GM client for players connecting/disconnecting, which is what the onUserLogin event is for (GM clients).

You'll have to probably rethink your approach to work within the events available.

If the all the windows you mentioned in the first post are open on the GM client, why wouldn't you just close the windows on the GM client based on the onUserLogin event that is triggered on the GM client?

If the windows you mentioned in the first post are open on the GM and connected clients, I still don't see why you can't have the GM client trigger based on the onUserLogin event (on the GM client) to close the local window, and send OOB messages to any other connected clients.

Regards,
JPG

[UrsaTeddy]

Firstly, I got the onLogin events working 100%. The issue was the order of flag checking I was using ... there was a situation (which I was invariable testing) that was dropping out of the checking quietly.

I had to move to onLogin because the OOB message was not sending out on the Client shutting down. I was trying to keep everything in OOB format so that I did not have to override any inbuilt code or events, thus 100% avoiding interference with anyone else and any extensions they may have loaded or written.

So unless there is a way (without taking over another function like onLogin) to ensure the OOB message gets sent when the Client shuts down, then I am stuck with overriding onLogin.

[FyreM]

well, you can insure a very high level of compatibility by SAVING the "current" onLogin function, doing Your processing, then calling the SAVED version..
I have seen many other Devs start to do this recently, and from all reports it works VERY well. (as long as someone with a later prioroty Extention doesn't just overrwite YOU, but that is a simply extention priority order problem).

function onInit()
ActionSkill.onRollOriginal = ActionSkill.onRoll -- saves any pre-existing override
ActionSkill.onRoll = onRollSkill
ActionsManager.registerResultHandler("skill", onRollSkill)
end

function onRollSkill(rSource, rTarget, rRoll)
-- do your things here.
ActionSkill.onRollOriginal(rSource, rTarget, rRoll) -- now do what ever anyone else had overridden (or return to the base ruleset for this action)
end


but then again, i am new enough at this that i coudl just be talking out my *output port*

[UrsaTeddy]

@FyreM

This I know. I have always saved functions that I override whenever I use any scripting system.

The problem as you have pointed out is always the risk that someone later on in the chain does not do this.

Therefore OOB messaging is much more useful because it bypasses the eventuality that someone makes that decision that they do not want to store/execute someone else's functionality before overriding it.

Right now, since what I am working on is for private use until I am 100% confident that it is ready for sharing with others, so I know what is going on with my code.