Lua API Exposed... Sort of.

It doesn't appear that their focus is modding right now. It only hinders part of the community. There's a large portion that just want to build more content that uses existing functionality. They can do that quite easily right now. That said, I'm not in that portion. None of my ideas can come to exist because of how strict the environment is.

 

It's a beta so it was to be expected, once the game is where they want it to be and they have the time to focus on modding I'm sure it will be fleshed out much more. That's the reason I started the Lua Requests thread, so they know exactly what the community wants fleshed out in regards to the very limited Lua environment we have right now. Tiy has made their intentions for modding clear recently http://pastebin.com/jtJYTpKZ so I think its safe to say great things are coming.

 

If io.* is file operations, then I can understand the hesitation. Screwing up someone's computer, outside of the Starbound directory, is a hundred times worse than jacking up their Starbound game.

 

you'll have to interact with their embedded lua (5.1). you need the global lua state pointer at the minimum.

mild testing done with this but it's entirely possible to toss in your own custom script if you do it this way, you could also try to link up after injecting your own embedded lua but you're gonna need to use the same version.

 

Did anybody notice that the update did some changes to the function list? They added some more and changed/remove some other. Here is the new list:

 

...not sure if I should get my hopes up again.

"setSkidding". hehehe.

 

mega man style wall skidding?

 

Accursed scripting! Okay, so in \npcs\main.lua, I add to die()

local item = entity.getItemSlot("primary")

And I know I now have their primary weapon - everything about it. But when I

world.spawnItem(item, entity.toAbsolutePosition({ 0, 4 }), 1)

It kicks out a Perfectly Generic Item, and logs...

Error: Could not instantiate item (everything about the item). ItemException: No such item (everything about the item).

I know roughly why; spawnItem expects a unique name in its database, and I'm trying to feed it an object, not a name. So that's stupid of me. And I figure I should instead create a dummy drop and then just overwrite it with the characteristics of the primary...

item2 = world.spawnItem("avianstarter", entity.toAbsolutePosition({ 0, 4 }), 1)
item2 = item

...and it seems to work, except that it doesn't. Guys, I'm dumb. I can't even figure out how to get it to world.loginfo(item.thedamnitem'sname). Is there something I'm missing? Can I really not grab and change object arguments from within an NPC lua?

 

I've come to the conclusion that npcs, objects, techs are all segregated in their own sandboxes. Banned from communicating with each other. We need some civil revolution in the API.

 

Each object/npc/monster is running in its own context, but they can communicate with each other using world.callScriptedEntity. Tech currently runs on the slave, so it can't callScriptedEntity to objects or npcs or monsters which run on the master, but that will be fixed in the future.

 

spawnItem takes the objectName value found in a *.object type file - which is what you get back from getItemSlot. So you should be able to:

Code:

local item = entity.getItemSlot("primary")
world.spawnItem(item.objectName, entity.toAbsolutePosition({ 0, 4 }), 1)

 

Error: Exception while invoking lua method 'die'. LuaException: [string "/npcs/main.lua"]32: VariantException: Cannot convert from null to string

I basically haven't been able to get it to act upon or even report with loginfo anything stored on item... unless I just loginfo(item) at which point I get a dump.

 

By inspecting the Lua scripts, you'll see they have many magic variables, such as data, entity, and so on. It's pretty clear they are lua_setfenv()'ing the scripts on the engine side (and the Lua scripts seem to be used as "class files", defining methods for objects handled internally in the engine). This is why _G is nil. And it is entirely possible they aren't even luaL_openlibs(L)'ing the global environment.

Their use of Lua is just as glue code, basically providing event-oriented data and firing a couple callbacks after passing through some ifs. The Lua API seems quite basic and poorly designed (I don't say this as criticism of the game, only as indication that they do almost everything at the engine level, keeping the scripting environment to its bare essentials).


I really don't see myself doing any non-trivial modding for Starbound. Sure, it is likely some modding API will be developed over time, but since the game itself barely uses scripts I don't see it as being quite robust (not to mention that by doing most things in the engine there would be little to no referential transparency).

 

Ok guys, i found _G
Actually instead of _G it is called _ENV.
This is _ENV dump from object logic script for current version: (with formatting http://privatepaste.com/91ddf79be8)

Also i would like to point, that dumps from different 'lua-connectors' (tech, monster behavior, object logic) will have differences since they have different environment

 

Oh, they are using Lua 5.2. I didn't expect that. ;]
The concept of environment changed in Lua 5.2. _ENV is a special variable which is always available. See this.

Ignore my previous remark about lua_setfenv() then (instead, reinterpret it as "pseudo-global" environment placed in LUA_RIDX_GLOBALS before calling lua_load() or luaL_loadfile(); see this).

 

You sir, are amazing.

 

While its true that the Lua implementation in starbound is extremely minimal right now, I think that can (and will) change to allow for more complex mods, hopefully sometime around release. Awesome work with finding a global table, I'll play around with it a bit.

 

Definately. There were a couple of functions that were just added in the last update alone. I am sure they are going to expose more functionality to us, they just have to make Lua C++ bindings.

 

I'm not a professional lua user but i think they should add at least io package. Also any kind of network package support may allow some client-server mods like no mod-integrity checks or mod auto-download

 

IO package should be able to work as its part of Lua, unless they locked it down. I mean hell, coroutine is in there... I dont see why IO isn't. Possibly the fact that they dont want a lua backend for people to put malware on clients machines... who knows.