View Full Version : Possibly dumb question about chatmanager.lua
Dachannien
May 12th, 2007, 00:26
Okay, so I'm looking through the newly released documentation and using it to help me navigate the various files in the default d20 ruleset. I'm a bit confused by something though.
In chatmanager.lua, there's a function at the very top called registerControl. It sets a variable to refer to some object that's passed in as ctrl. Weak typing makes me cry, because I'm confused as to what this object is. It's referenced later on in the script, as the event handlers like deliverMessage do nothing more than call control.deliverMessage. My question is, what's the interface for this mysterious object? I'm assuming that its implementation is internal to FG, but are there any useful functions in it that I might call?
On a side note, I'm a bit confused by two other things. One, what's the sequence of event firing when dice are dragged into the chat window? And two, I see that there are methods in the Input object that let you see whether a shift key is down, but is this the only way that a script that handles a die roll can determine what state the shift keys are in (meaning you hope the user doesn't release the key before you can poll it), or does it somehow work its way into a dragdata object?
Thanks much :)
TarynWinterblade
May 12th, 2007, 07:16
Okay, so I'm looking through the newly released documentation and using it to help me navigate the various files in the default d20 ruleset. I'm a bit confused by something though.
In chatmanager.lua, there's a function at the very top called registerControl. It sets a variable to refer to some object that's passed in as ctrl. Weak typing makes me cry, because I'm confused as to what this object is. It's referenced later on in the script, as the event handlers like deliverMessage do nothing more than call control.deliverMessage. My question is, what's the interface for this mysterious object? I'm assuming that its implementation is internal to FG, but are there any useful functions in it that I might call?
The control variable in chatmanager.lua gets passed a reference to the chatwindow object located in the chat windowclass in desktop_classes.xml (lines 22 through 37 in the default d20 code)
More on the chatwindow class can be found here: https://www.fantasygrounds.com/refdoc/chatwindow.xcp.
The interesting thing that I'd like to know: is there any way to do pre-processing on the chat reciever's computer before the message is processed?
Any data changed in the messagedata variable passed to chatwindow's onReceiveChat doesn't actually change anything with the message, it just changes onReceiveChat's local copy of the message.
I did try making onReceiveChat return false, and using addMessage to process it, which worked, to an extent... it just lost like half the message in translation ;)
On a side note, I'm a bit confused by two other things. One, what's the sequence of event firing when dice are dragged into the chat window? And two, I see that there are methods in the Input object that let you see whether a shift key is down, but is this the only way that a script that handles a die roll can determine what state the shift keys are in (meaning you hope the user doesn't release the key before you can poll it), or does it somehow work its way into a dragdata object?
Thanks much :)
As far as I know, the only thing that you get is the "onDiceLanded" event of the chatwindow class. So... you'd have to poll it there.... which might result in what you're mentioning: the user releases the shift button before the dice get processed.
Hope that helps.
Dachannien
May 12th, 2007, 12:35
Ah.... I just found where that happens. In chat_chat.lua, the onInit method calls ChatManager.registerControl and passes its self reference.
So the deliverMessage function in ChatManager is just a way for scripts to access the method in whatever chat window object happens to be in use (because there can only be one chat window, and it gets registered with ChatManager when it's initialized)? I think I'm starting to understand ;)
Dachannien
May 12th, 2007, 23:47
Okay, here's another related question. I tried to do this:
function onDrop(x, y, draginfo)
local msg = {};
msg.text = "Message Text";
ChatManager.deliverMessage(msg);
return true;
end
in the script for a genericcontrol object. The onDrop event function gets called when I expect it to, and the deliverMessage function in ChatManager (that is, in chatmanager.lua) gets called as well. But when the ChatManager calls the deliverMessage function for its registered chat window, I get this error:
Script Error: [string "scripts/chatmanager.lua"]:30: Invalid messagedata - deliverMessage failed
The thing is, the ChatManager.deliverMessage function is called elsewhere in the default ruleset (such as in combattracker_entry.lua) in pretty much the same way with no problems. What am I doing wrong?
TarynWinterblade
May 13th, 2007, 06:51
Okay. I fiddled around with it a bit.
Apparently, you also have to pass it msg.font as well. It stopped giving me the error when I passed it:
local msg = {}
msg.text = "Text"
msg.font = "sheettext"
ChatManager.deliverMessage(msg)
There's some subtle irony though... try taking out msg.text and watch how it doesn't give you an error there. ;)
Dachannien
May 13th, 2007, 13:55
Weird. Thanks for the answer :)
Dachannien
May 13th, 2007, 15:50
Okay, here's some more with this whole deliverMessage thing.
On the local side, you can set several fields for a message, not all of which are documented properly (which I've mentioned elsewhere). They include, but aren't limited to, the following:
text
sender
icon
font
dice
diemodifier
dicesecret
This is great for what I want to do. If all of these fields get sent through to the other side in a message, and arrive in the onReceiveMessage event function intact, I'm happy. However, this appears not to be the case. When setting these seven fields with valid data, the message on the other side includes only data for the sender, text, and font fields.
Shouldn't a message still include all fields that are set client-side when it reaches the host?
TarynWinterblade
May 13th, 2007, 20:48
Okay, here's some more with this whole deliverMessage thing.
On the local side, you can set several fields for a message, not all of which are documented properly (which I've mentioned elsewhere). They include, but aren't limited to, the following:
text
sender
icon
font
dice
diemodifier
dicesecret
This is great for what I want to do. If all of these fields get sent through to the other side in a message, and arrive in the onReceiveMessage event function intact, I'm happy. However, this appears not to be the case. When setting these seven fields with valid data, the message on the other side includes only data for the sender, text, and font fields.
Shouldn't a message still include all fields that are set client-side when it reaches the host?
From my tests, onReceiveMessage's copy of messagedata gets the sender, text, font and icon fields.
onDeliverMessage, in chat_entry.lua, has all those, and a boolean (hasdice), which declares if the message has dice attached to it... but thus far I haven't found a spot where you get the values of dice, dicesecret, or dicemodifier. :confused:
... and my code is now riddled with:
for k, v in pairs(messagedata) do
if type(v) == "string" then
print(" " .. k .. ": " .. type(v) .. " - " .. v)
else
print(" " .. k .. ": " .. type(v))
end
end
Edit: A few more notes...
- chatmanager.lua's processDie function only gets called as the result of a /die slash command.
- chat_chat.lua's onDiceLanded function gets called anytime a die hits the chat window, on whichever machine threw the dice. This function can call chatwindow's deliverMessage, providing it with dice, dicesecret and dicemodifier fields.
- Those three fields seem to not be able to be touched once they get to deliverMessage.
Dachannien
May 13th, 2007, 22:31
I couldn't get the icon field to transmit to the host after setting it on the client and sending it through deliverMessage.
Well, I can probably do what I want to do in a more manual fashion. I was hoping it would be easy, that I could just take the fields from the client-side dragdata in a particular control's onDrop function and stick them in the corresponding fields in a message that got sent through deliverMessage to the host, which could then process the die roll. All the relevant fields get used somewhere else within the default d20 ruleset, so one would think it should work, but for some strange reason, it doesn't.
I guess I'll have to transmit the dice, modifier, and label as part of the text field instead and then process that to cause a die roll.
Foen
September 22nd, 2007, 09:19
Hi
This continues a theme, so I thought I'd not start a new thread.
I'm trying to access ChatManager.addMessage from within a customdie OnValue event handler. The ChatManager is declared at global level (in base.xml) but the OnValue event says it is a nil reference.
Any advice?
Cheers
Stuart
Toadwart
September 22nd, 2007, 10:48
Hmm, other than the obvious possiblities (mis-spelling / case sensitivity) can't think of any reason why it would be nil ... :confused:
Foen
September 22nd, 2007, 10:53
Yep, I thought of those and looked hard but it seems OK. I even ran a search for "ChatManager" across the whole ruleset (case sensitive) and my line of code came back the same as the built in ones.
*scratches head*
Maybe it's to do with the scope of Lua scripts in gameelements.xml.
Stuart
Toadwart
September 22nd, 2007, 11:34
Just a wild stab-in-the-dark but:
is the chatmanager script line below the gameelements includefile line in base.xml?
If so, try moving the chatmanager script line to the top of the file.
I'm not sure if the order in base.xml has an effect but worth a try.
Foen
September 22nd, 2007, 11:40
Bingo! Even though the call to ChatManager occurs after it has been initialised, it seems Lua cannot handle the forward reference.
Many thanks
Stuart
joshuha
September 24th, 2007, 19:16
Also, I have always found this to work no matter from where the code was called:
ChatManager.control.throwDice(...)
Spyke
January 27th, 2009, 13:43
Nothing like reviving an old thread, and I am probably being dumb, but I'm scratching my head here.
I have a disclaimer text which currently gets output to the chat window when my ruleset loads. It is coded as a function "deliverDisclaimer" and called from the onInit function in chat_chat.lua.
This works fine, but if I move the function to an initialise.lua script and call it from the onInit function there it doesn't work. I've updated the addMessage(msg) calls to be ChatManager.addMessage(msg). The initialise script is called from the last line of my base.xml.
I've tested this by boiling it down to the essentials.
This works: in onInit in chat_chat.lua (called from desktop_classes from middle of base.xml):
local msg = {};
msg.font = "systemfont";
msg.text = "Disclaimer text";
addMessage(msg);
This doesn't work: in onInit in an initialise script called as last line of base.xml:
local msg = {};
msg.font = "systemfont";
msg.text = "Disclaimer text";
ChatManager.addMessage(msg);
I've tried moving the various lines around in base.xml, trying it with deliverMessage, and trying ChatManager.control.addMessage, as suggested above, but I can't get it to work.
What's odd is that the rest of my initialise script works fine, including the ChatManager.registerSlashHandler lines which themselves include ChatManager.deliverMessage(msg) calls.
I'm obviously failing to understand the scope here. Any help would be much appreciated.
Spyke
Spyke
January 27th, 2009, 16:16
OK, I've found out why it's not working by putting a couple of console debug messages in. (Should have thought of that earlier... <sigh>)
My initialize.lua onInit() function gets called before the onInit() in chat_chat.lua, even though the includefile for the xml file that defines chat_chat is earlier in base.xml.
This means that the chat window hasn't been registered with ChatManager at the point that my initialize routine gets called, hence there's no output to the window.
I suppose this makes sense, as it means that script packages are processed before scripts in controls, which means that the global functions are available. (In fact it has to work this way, as otherwise chat_chat can't register the chat window with ChatManager.)
I ought to be able to get round this by putting my disclaimer text in a control script created from a file called later on in base.xml, but I've not cracked this yet.
To recap:
1. base.xml has:
<root ...>
...
<includefile source="desktop.xml" />
...
<script name="Initialize" file="scripts/initialize.lua" />
</root>
2. desktop.xml has an include for desktop_classes.xml.
3. desktop_classes.xml defines <chatwindow name="chat"> which has the script element:
<script file="scripts/chat_chat.lua" />
The onInit function of initialize.lua is called before the onInit function of chat_chat.lua, even though it is encountered later in base.xml, presumably because global script packages are processed before control scripts.
Spyke
Spyke
January 27th, 2009, 16:57
Finally solved by creating a new xml file included after the main desktop classes in base.xml, with the disclaimer script called from a blank panel and stringcontrol.
<?xml version="1.0" encoding="iso-8859-1"?>
<root version="2.0">
<panel name="init" modes="host,client">
<class>init</class>
<bounds>
<rect>0,0,0,0</rect>
</bounds>
</panel>
<windowclass name="init">
<sheetdata>
<stringcontrol name="disclaimer">
<bounds>0,0,0,0</bounds>
<script file="scripts/disclaimer.lua" />
</stringcontrol>
</sheetdata>
</windowclass>
</root>
This could probably be made much more elegant. But it works. And there are more pressing issues to deal with! ;)
Spyke
Spyke
January 27th, 2009, 17:13
BTW, if anyone's wondering why I'm doing this when it was working fine in chat_chat.lua, I'm trying to split the system-specific parts of my ruleset out from the basic Foundation code, to:
1. Make it easier to update when Foundation code changes.
2. Make it possible to recreate it as an extension to Foundation, if desired.
And now I'll stop answering my own posts before the forum police hunt me down. :p
Spyke
Powered by vBulletin® Version 4.2.1 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.