[Dev Blog] Desktop Tuesday, a peek inside the modding API


#1

This is one for all you modders out there!

Will definitely mean a lot more to some of you than it does to me!

Nevertheless I like reading the words.
http://stonehearth.net/2014/01/14/desktop-tuesday-a-peek-inside-the-modding-api/


#2

Joffers, what do you expect?


#3

so our poor modders are having to guess at which parts of the interface are meant for modding, and which ones should be hands off.


Introducing Mixintos and Overrides

Had they called it “Mixintons” we could have had a very British mascot and all… :frowning: I’ll assume that mixintos do little more than simply extending the original JSON.


Don’t hook into an change the definition of functions in the LUA code. There will be an official events mechanism that you can hook into get notified when significant things happen in game (like entities being added to the world).

I think as long as it’s abstract, i.e. not every mod tries to modify it on its own, we should be okay for now. The events system is kind of lacking in some aspects.

The Lua I/O library is going away, for obvious reasons.

Aaaand RP is officially dead.


An interesting update for the asset modders, a death sentence for lua modding. Unless they allow requireing lua modules, in which case I’ll just wrap one up. But that would be somewhat, eh, pointless in terms of security improvements.

I guess I can stomp in r2699 for now.


#4

perhaps this will be the motivation to finally start working on my mod! :+1:

rubs his hands together maniacally, pretending to pet an imaginary white cat perched upon his lap


#5

This will make things a lot easier. When it comes to changing and adding in models.


#6

I know whenever Devs update their games. But what did the Lua I/O library allowed you to do?


#7

There will absolutely (eventually) be an official way to write mods at the lua level, even though there may not be a way to overwrite specific functions. Also, more events are coming. Are there any events in particular you all would like exposed?


#8

At the moment, I would like something that allows mods on the server side to be loaded without having to create a JS and define a call handler.

Ideally, I would ask for a similar loading process that RP currently has - i.e. something similar to my manifest.json:rp entries (require and server_init being the most important ones).

On the event side I would probably like entity_created, if possible something to choose the world generator and the name generator. But events are really not a big deal; I can happily patch these myself. Unless, of course, the require workaround I’m using doesn’t work anymore either.


#9

Something about that shape and size will certainly be included eventually.


#10

I don’t doubt that something like that will be included, but the question is kind of when. If I’m a complete scaremonger for a second, I would assume that this is not in the next update and lua modding itself is kind of dead in the next few weeks/months to come.

I mean, I probably sound like a toddler who just had been taken away his favourite toy, but the news don’t sound very exciting at all for the lua side. We have this freedom right now (which was admittedly being required by smashing down more than one wall) and now there’s a chance that it pouffs away.

Of course, without knowing in detail what the update does this is all just worst-case-won’t-happen assumptions here, but just from the blog post it sounds like this update was aimed at the artists while fixing severe holes on the lua side. If those holes aren’t somewhat replaced with similar bindings, lua is kind of screwed.


#11

I do agree with @RepeatPan Being a bit worried about Lua. Otherwise I’m pretty Happy with whats been said, guess I can focus on art for awhile until the lua side is fixed anyways this is alpha and barely anything is here to begin with!


#12

and there was much rejoicing to be had

thanks Team Radiant!


#13

An official way to add mods to the game. Much sooner then expected. And much easier to update the mods to the new version. It might not even break with a new version.
Exciting. :fireworks:

Mind telling us what you plan to make? :blush:


#14

with pleasure… :smile:


#15

Looking forward to this patch. It seems like there are some components hard-coded at the moment, e.g. I can add another type of tree or plant, but adding it in addition to the existing ones is not working (even if I adjust it in some of the Lua-code). Hope this will be also possible soon so that we can start adding some more variety.


#16

There are two things that need to be taken care of; Landscaper:get_tree_type needs to return your tree type and get_tree_name needs to be patched in order to return the proper mod prefix (if the tree is outside of stonehearth). Preferably, this is done in one step; i.e. by having get_tree_type return a special string (or a table, if we want to get very fancy) which is then checked by your own get_tree_name. If it’s a special case, get the mod name from somewhere (the table/an internal hashtable) and return that; otherwise use the old approach.

That should do the trick. This is actually not possible with current RP as I have no “proper” way of messing around with Landscaper (although api.world_generation / stonehearth:world_generator_chosen might be useful). Should the next update disappoint in that area I’ll add a few events.

My grep actually fails to find the Landscaper itself, so there might be a completely easier (and saner) way to do this.

Edit: Landscraper; I should really go to bed. But yes, world_generator_chosen would allow these modifications on generator._landscaper. However, since get_tree_name is a global function (as temporary solution I guess?) I would not necessarily recommend messing around with it unless you’re very sure that there are no side effects.

Of course, as usual, this is just if you’re not planning on messing around with the stonehearth.smod directly anyway.


#17

Thanks for laying out some details. I have also found different references including the settings for the probability of each tree-type to occur based on the terrain-type. However, the idea should be that this is handled a bit different inside the Lua-code, i.e. in a way that you can simply add some .json- and .qb-files and there you go (the Lua-code reads all types from e.g. the manifest).

Just wanted to bring this to the attention of the devs… although I think it is on their list as the same was the case for the profession and the code was just replaced in the last patch with a more flexible version.


#18

Of course it’s going to be different and if I recall correctly since the glacier biome is supposed to come kind of early, we can expect that the whole world generation becomes modular soon-ish. The recently introduced scenarios and habitats might be a first step in said direction.

I’m just saying that it’s possible now too, with just a little bit more effort.