Addressing gui script via messaging (SOLVED)

Questions
#1

I am trying to reference a gui script in a prototype I am making. Looks to me like I am doing it correctly after reading the message passing docs. Does anyone see what I am doing wrong here?

Screen Shot 2016-05-13 at 7.25.52 PM.png1548×989 176 KB

I’m thinking that with this scene tree the message id should be ‘main:/controller#gui’. You should be able to see the the script, error, and collection tree in the screen grab. That settings.register_listener is a module that manages game state, and I am trying to set it up to be able to auto fire msg posts to objects that subscribe to it when the game state changes.

Thanks for any help!

#2

If it helps, here is a snippet from the module code that actually calls the msg post

local state_listeners = {} 

-- broadcast messages to our listeners
broadcast_message = function(message_name, message_table)
    for hex_id, listener_id in pairs(state_listeners) do
	msg.post(listener_id, message_name, message_table)
    end
end

M.register_listener = function(id_hash)
    state_listeners[hash_to_hex(id_hash)] = id_hash
end
#3

Whoa, this will be challenging to explain… So basically there are three parts of a URL: the socket, path and fragment. In your example they are “main:”, “/controller” and “#gui” respectively. The resulting URL is not a hash of the concatenation of these strings. The internal representation is an object with the three fields:

local url = msg.url("main:/controller#gui")
print(url.socket)
print(url.path)
print(url.fragment)

Gives:
DEBUG:SCRIPT: 786443
DEBUG:SCRIPT: hash: [/controller]
DEBUG:SCRIPT: hash: [gui]

For convenience, we provide a lot of magic to create them, like allowing a string to be specified and even a hash. In your example, you use a hash and the engine then assumes this is the path you are interested in, and assumes the socket to be the same as the calling script, and the fragment to just be omitted. When resolving the URL on that socket (your collection), the engine tries to find the game object with path “main:/collection#gui”, when the path actually is “/controller”. In this case that is extremely confusing, as it looks like the engine perfectly understood your URL and reports it back to you.

The fix is to change controller.gui_script to register URLs instead of hashes:

settings.register_listener(msg.url("main:/controller#gui"))

The next annoying thing is since the URL is a complex object (the three fields), it cannot be used as a key into a lua table (which is something we should look into fixing as it causes a lot of grief). So in the settings module, you need to key the url by its path:

M.register_listener = function(url)
    state_listeners[url.path] = url
end

This will work fine as long as your settings module does not need to simultaneously care about different dynamic collections, loaded through collection proxies. Because that will mean the socket will be changed for each different one, and you would need to consider that when registering the listeners.

5 Likes
#4

:clap::clap::clap:
Wow thanks for the detailed explanation @Ragnar_Svensson!

I like the idea of explicitly passing a URL as I could see this being easier to debug if issues arise

Here are the final updates that I made to the scripts I posted if it helps anyone:

gui_script:

function init(self)
    self.msg_url = msg.url('main:/controller#gui')
    settings.register_listener(self.msg_url)
end

settings module script:

-- broadcast messages to our listeners
broadcast_message = function(message_name, message_table)
    for url_path, url in pairs(state_listeners) do
	msg.post(url, message_name, message_table)
    end
end

-- register/unregister listeners for state changes
M.register_listener = function(url)
    state_listeners[url.path] = url
end
4 Likes