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

[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.