Hey, I've been reading some guides and (kinda) achieved what I wanted, which was gliding in the air (like Terraria wings) when holding jump with certain techs. Now, what I'd like to know (and also learn for possible future issues) is, how to keep a Lua script constantly running. From what I've seen looking through vanilla files, it's always attached to another file which has the "script" field; and you can't add a statement to existing functions like in OOP languages (I think?). I made the Lua script have an update function, etc. But how do I call the script, to make it work when the game loads? In this specific scenario what I want to do is: check if the player has certain Tech, and if it does, keep running the update method to make the player glide when meeting certain conditions I've given. I know I could just do it inside the techs' Lua, but for compatibility sake I think this is better. Thanks in advance, (and sorry for my English...)
In the end, I added it as a new Tech. Still, I'd really appreciate if someone could tell me how to initialize scripts on game load, and not in a certain item interactions, or specific action.
You can hook the player's scripts (need to be a bit careful not to break many other mods) to have something always running. But you said something about making sure a player has a certain tech? Funny enough the player's script environment can't access the player table. Which of course means that player.availableTechs() etc are not available from there. You could use an invisible quest though.
Thanks for your reply! However I've only been modding for a day and I'm not sure about how to "hook" that, it's like adding a patch for "scripts"? Could you please provide just a brief example? And how do you start an invisible quest without fist having to interact with an NPC or something? Also, how would you hide it? If I'm asking too many questions just reply the ones you feel like doing it, thanks!
Sure I'll grab a real example and trim it down. "scripts" is the first step. It is in most aspects an array, so you can add another .lua file to load at the end. Code: [ [ { "op" : "add", "path" : "/scripts/-", "value" : "/interface/scripted/techupgrade/bk3k_addTechs.lua" } ] ] If you are curious about the extra outside [], Starbound supports an extended patching standard. You can put your patches into batches and if the condition for "test" fails, it only aborts that batch while letting others (potentially with other test conditions or none at all) run still. In case you want to do use different sets of patches for different conditions - like looking for the influence of other specific mods. Then a script Code: local addTechs_init = init --I'm copying whatever init function existed before, redefining it, running my own, --and finally running whatever was there before init = function() eval_techs() addTechs_init() end Note that Code: init = function() end and Code: function init() end are the same thing, I just like the first syntax better myself because functions are just another type of data. Anyhow I copied the function stored under the nameSpace "init". Then redefined what "init" was. The new "init" called the old one - which may be vanilla or it may be altered by some other mod. Any function I'm not replacing will be as defined previously. The contents of the second .lua file will share the same _ENV as the first. You could see it as the second script in the "scripts" array will act as though the first script had loaded it via "requires" at the very end. Rather that's the same effect if you had done so. Also note local data from one .lua file will not be available in other .lua files. Sorry if I over-explained anything you don't need to know.
A generic script context might suit your needs. /player.config.patch Code: [ { "op": "add", "path": "/genericScriptContexts/someUniqueKey", "value": "/path/to/yourScript.lua" } ] This will let you write a script with init, update, uninit without having to worry about existing code or adding your script to an array and hooking to functions that have already been defined in the existing files. I'm quite confident the generic script context has access to the mcontroller table (to glide), and it definitely has access to the player (to check if a tech is equipped).