Modding Help Message handlers with access to player table [Solved]

JT` · Mar 2, 2019

I've been digging my quarter-inch hair out because every reference I've seen suggests that to access the player table, I need to add message handlers to the player from a scope that has access to it: quests, interface dialogs, or objects. Which is terrible for me, because I'm trying to access player functions from a primary status script.

There's an unfortunate divide in the documentation: we have Silverfeelin's (excellent) tutorial for message events, but it isn't advanced enough to answer the primary question. In the opposite direction we have bk3k's advice to "add a message handler to _ENV" which is just Greek to me -- I get that there's an _ENV table in Lua that contains every table in the game, but I already did a dump on that table using some debug code I borrowed (and deleted after) from Gardenbot which showed that there is indeed no player table in my current scope.

And yet, I've seen other mods (e.g., Ztarbound) call functions from the player table in deployment scripts...

Code:

    { "op": "add", "path" : "/deploymentConfig/scripts/-", "value" : "/zb/zb_player_init.lua"},

zb_player_init.lua:

Code:

    -- popping up the update window in a safe enviorment so everything else runs as it should in case of errors with the versioning file
    local passed, err = pcall(updateInfoWindow)
    if not passed then
        sb.logError("[ZB] ERROR INITIALIZING POPUP WINDOW\n%s", err)
        status.setStatusProperty("zb_updatewindow_error", checkingMod)
        player.interact("ScriptPane", "/zb/updateInfoWindow/updateInfoWindowError.config", player.id())
    end

    -- Add the scan interaction handler if its missing
    if not player.hasQuest("zb_scaninteraction") then
        sb.logInfo("Readded 'zb_scaninteraction' quest")
        player.startQuest("zb_scaninteraction")
    end
    --...

So my current attempt was simply to add a bunch of message handlers in a deployment script. Using a PromiseKeeper, I successfully send and receive the messages with world.sendEntityMessage(). However, as soon as the PromiseKeeper calls the callback function that was defined in the deployment script, I receive the usual "attempt to index a nil value (global 'player')" which tells me that the player table isn't accessible.

jt_player_init.lua:

Log:

So, in other words, the script is bouncing on the player.hasItem() call, claiming that it doesn't have access to the player table rather than being an inherent problem with the call itself. (This also occurs even if I don't pass any parameters in the calling message and simply hard-code the item to check for.)

This would all be infinitely easier if the freaking primary status script just had access to the player table...

----------

Essentially, this boils down to two questions:

1) How can it be possible to call player functions in the deployment script, but not call player functions in message handlers defined in the deployment script?

2) Is there a good, working demonstration on how to add a message handler that has access to the player table and whose message can be received from a primary status script?

Errors4l · Mar 2, 2019

Deployment scripts were created after primary script sources, so they got access to the (newer) player table. CF should probably have added it, but a lot of script related things seem to have been added when they actually need it. CF didn't need the player table in primary script sources, so it's not there (of course, it could have a better reason we're unaware of).

Here's a simple repository by Magicks that exposes a message handler for a player function: https://github.com/Mehgugs/Starbound-RemoteInterfaces

When you're talking about primary status scripts, I assume you're referring to primary script sources in the status controller. I don't really see what's wrong with your current code, but maybe it will help you to look at a short and simple example that works.
Attached is a mod that both logs the content of the player table and returns the result of player.hasItem (silverore) every 5 seconds.
Note that I am not using a promise keeper because both scripts are executed locally, meaning the message handler will return its result immediately (something covered here).
Note that the first two parameters of the message handler are messageType (string) and isLocal (bool). You missed that in your has_itemname handler (something covered here).

PS. When hooking onto existing functions, your current structure works fine, but it tends to lead to a long call chain when a bunch of mods do this. You could use this script to both make it easier to hook functions and reduce the call chain:
https://gist.github.com/Silverfeelin/3a6286d443d829eed58fa781790e2de5
Usage: hook("init", myInit)

JT` · Mar 3, 2019

Errors4l said: ↑

Deployment scripts were created after primary script sources, so they got access to the (newer) player table. CF should probably have added it, but a lot of script related things seem to have been added when they actually need it. CF didn't need the player table in primary script sources, so it's not there (of course, it could have a better reason we're unaware of).

Here's a simple repository by Magicks that exposes a message handler for a player function: https://github.com/Mehgugs/Starbound-RemoteInterfaces
Click to expand...

Hmm. It seems to say that it also only works from a player context, though, which is the same problem I have -- trying to call from the primary script source, I won't have access to the player table.

When you're talking about primary status scripts, I assume you're referring to primary script sources in the status controller.
Click to expand...

Yeah, I was using that interchangeably. It's a script defined with--

SONOFAGUN.

Found the problem. =)

Here was how I was triggering my "deployment script":
Code:
{ "op": "add", "path": "/statusControllerSettings/primaryScriptSources/-", "value": "/scripts/jt_player_init.lua" }
...which is very obviously not a deployment script. Because it triggered at all the times that a deployment script would trigger, I thought it was working just fine, and the absence of the player table was just a gigantic mystery. Now I know why: it was a vile FORGERY! Hoo!

(For anyone trying to read this and somehow managing to forge through the Greek, the proper path for a deployment script patched into the game is "/deploymentConfig/scripts/-".)

Note that the first two parameters of the message handler are messageType (string) and isLocal (bool). You missed that in your has_itemname handler (something covered here).
Click to expand...

Yeah, oops, that was just a tweak from the one that ignored all the parameters and called a hard-coded item name, gently massaged when I posted on the forum. I usually do use the "_,_,parameter" format but forgot to apply it to the example code I put up.

PS. When hooking onto existing functions, your current structure works fine, but it tends to lead to a long call chain when a bunch of mods do this. You could use this script to both make it easier to hook functions and reduce the call chain:
https://gist.github.com/Silverfeelin/3a6286d443d829eed58fa781790e2de5
Usage: hook("init", myInit)
Click to expand...

That's... actually quite brilliant. I like that.

It seems to be throwing errors when trying to call createHook internally, though.

Errors4l · Mar 3, 2019

Glad you figured it out.
For the function hook you should be using hook and not createHook. The script only exposes the function hook and all other code can only be used internally (by the script itself). This is why those other functions are marked local.
Put the file somewhere in your mod, require it at the top of your script then call hook("functionname", yourFunc).

JT` · Mar 3, 2019

Nope, I was calling hook("init", init_jt) (having renamed my init function accordingly). It would spit out an error on the line of
Code:
  hook[func] = true
in the library -- in other words, createHook internally wasn't successfully creating that index.

I ultimately just went back to the daisy-chained init function, since it works.

Errors4l · Mar 3, 2019

Hmm, could you send me the log after it throws an error? I've never had problems with the script myself but I'll have to update the script if there's an issue with it.

Log in or Sign up

Modding Help Message handlers with access to player table [Solved]

JT` Phantasmal Quasar

Errors4l Spaceman Spiff

Attached Files:

mh_player.zip

JT` Phantasmal Quasar

Errors4l Spaceman Spiff

JT` Phantasmal Quasar

Errors4l Spaceman Spiff

Share This Page

Log in or Sign up

Useful Searches

Modding Help Message handlers with access to player table [Solved]

JT` Phantasmal Quasar

Errors4l Spaceman Spiff

Attached Files:

mh_player.zip

JT` Phantasmal Quasar

Errors4l Spaceman Spiff

JT` Phantasmal Quasar

Errors4l Spaceman Spiff

Share This Page