Modding Manifesto!

Even though it’s still early days, a lot of people are really putting in effort to get Stonehearth mods up and running. That’s great! While we’re focused much more on content than modding infrastructure this early in the Alpha, I wanted to take some time to explain our modding philosophy so you’ll at least know where we’re going.

In the short term, I’d also like to hear ideas from people on the bleeding edge of modding what would make your lives easier. Hopefully we can knock off some of the easier items even while focusing most of our time on content. So, without further ado…

The Stonehearth Modding Manifesto

This is a very brief introduction to how we think about modding Stonehearth. It's purpose is to solicit feedback on how we see Stonehearth modding working when the game reaches Beta and beyond. Some of these systems are in place now, but many will not come along until we're further in the Alpha.

Many things in this Manifesto probably will not make sense unless you’re familiar with some of the concepts exposed by decompiling the luac source. Sorry about that! Future versions will hopefully be much more clear.

Changing Existing Behavior

The simplest form of modding is simply changing just the data in Stonehearth without modding any of the behavior. Examples include adding new recipes to a crafting profession, changing the font used by the UI, or using a different Qubicle file for the worker outfit. These types of mods should be written using the [mixins and overrides system][1] Tom documented briefly on the blog.

We would also like to use mixins and overrides to change the behavior of existing game systems in a data-driven way. Ideally there would be no hard-coded game-tuning parameters in the Stonehearth mod. All the inputs would come from a json file which is aliased in the mod’s manifest. The scenario service, for example, has an index named 'stonehearth:scenarios:scenario_index' which contains all the information about scenarios in the game. To change what scenarios get loaded, modders should use mixintos and overrides on that file.

Going forward, we would like to make all parts of Stonehearth moddable this way. Adding more types of trees to different biomes or more types of berry bushes or different types of critters should be as simple as writing a mixin to add your changes to some “world_generation” index service.

Mod Programming

Mods which add brand new behavior will need to incorporate some form of scripting. We've tried to make it very easy to determine which mods are loaded, call into the functionality exposed by those mods, and expose your own mods functionality to others.

The return value of the client_init_script or server_init_script gets put into the global namespace at mod load time. For example, if my server init script for mod ‘foo’ looks like this:

local foo = {
    bar = function(int)
         print ' called!'
return foo

All other mods can call me trivially as:

if foo then
end  -- call only if foo is loaded

The 'radiant:modules_loaded' event gets triggered when all modules have been loaded. Trying to call before then has undefined results (it depends on the mod load order).

If you’re not in the same interpreter (e.g. client calling server or vice versa) or in JavaScript land, you should still be able to call public functions in mods using some combination of, radiant.call_obj or calling a published function in a call handler.

Receiving Notifications and Hooking

We would like to use event notifications (see to send notifications between mods and to "hook" certain events like entity creation. We prefer events to other mechanisms like sub-classing and monkey patching as it lets us more easily maintain backward compatibility while having the freedom to re-structure the backend if necessary.

Right now we barely trigger any events, but ideally would have an event for everything anyone would want to hook into. Create entity should probably look like this (currently there is no trigger):

function entities.create_entity(ref)
   local entity = _radiant.sim.create_entity(ref)

   -- give mods a shot a dynamically modifying the entity
   local event = {
      ref = ref,
      entity = entity
   }, 'radiant:on_create_entity', event)
   return entity

Then modders can simply do something like:, 'radiant:on_create_entity', function (info)
   if info.ref == 'stonehearth:oak_log' then
      self._oak_log_count = 1
      -- do something with oak log count in your mod later?


In a nutshell, that's the direction we'd like to go. We'd really, really like your feedback on what's missing and what would be most useful to support a modding framework based on these principals. I would especially like feedback on:
  1. What’s completely missing (e.g. we know there needs to be a mod loading / load order framework. What else?)
  2. What can’t you do that you want to do using this framework?
  3. How can we modify the framework to make it so you can do it (e.g. do we need to trigger more stuff? are certain things (like world_generation) missing parts (like a .json input file) which you’d like to mod?) Without monkey patching, re-implementing, or wrapping parts of the system?
  4. Is there anything that’s absolutely impossible to do in this framework? What is it and how would you like to do it in a way that works for all modders who might not be cooperating with each other (or even know that each other’s mods exist)?

All other types of feedback are more than welcome, of course. Thanks again, guys. The modding aspect of Stonehearth is the most exciting part of it for me, so I’d really really like to make sure it’s flexible enough to accommodate everything you have in mind.


I’m still writing this, but here you go already. I’ll just edit/post it after that.

I feel… elitist! Steve has summoned me, so excuse me if I just nag at every detail… Double excuses if I’m crashing a party I wasn’t invited to. Sorry!

  • Some code samples lack formatting. I would probably put all code-related things into inline code blocks too - just to make it more obvious. Fixed.
  • Perhaps it should be noted/changed that when one forgets to return an object, the global variable becomes a thread object. That was pretty confusing to me. I would rather have it dropped then - some mods do simply not require to be kept as object.
  • if foo then end won’t work with strict lua. It’ll throw an error. Unless you plan on removing it, which I have mixed feeling towards, then that won’t work. However, since strict lua is modifying _G already perhaps this could be used to our advantage - when a global variable is accessed that does not exist, but matches with a mod name, the mod is loaded and then its object returned. Perhaps a bit too much magic… But that could be really nice. Another way would be to have some global object (_M?) which would do that magic. I’m not sure about this, it sounds useful but perhaps a bit too witchcrafty.
  • It’s possible to call non-call-handlers with More details about this would be useful and some more info on the limitations: size is one that I know of and I think there was something about (at least server-sided) not supporting entities (C++ exception, “Not JSON!”) which is kinda off-putting.
    (I always wondered about the underscore too - does not exist. Maybe drop it if this function is meant to be used by modders? Or simply alias it.)
  • Formatting! aargh. Sorry.
  • “radiant:on_entity_create” looks pretty similar to what I have with “rp:entity_created”. It’s been said a bit but the naming in SH is somewhat inconsistent - a good example would be the recent introduction of the “stonehearth:is_harvested” event on stonehearth:renewable_resource_node.
    For me, “on_create_entity” sounds like I could still change the way the entity is created - if at all. That’s not the case; the entity was already created. I would prefer something in the past over an “on_” event. My dibs’ on “entity_created”.
  • Depending on how “dynamical” you want to create the whole thing, I would like to see proxies for these entities added. In some cases, it can be useful to replace entities A with entities B without overriding them. For example, in the Asian mod, replacing all trees with bamboo is okay - but that means that my addon is allowing them to be chopped down and apples to be collected because they’re technically still an stonehearth:*_oak_tree.
  • Yay for self no longer being a requirement to events.listen.

Let’s talk about war then.

  1. What’s completely missing (e.g. we know there needs to be a mod loading / load order framework)

That’s certainly a big deal, especially with libraries and similar. I dislike WoW’s approach by simply shipping the library with the addon itself, so that system is somewhat needed. For now, I guess RP can take care of that, however. At least, for my needs.

C-function dump: What would definitely be helpful would be some sort of dump of the C functions. luabind is hiding them all behind a C indexer, so there’s no way to see what functions are available (alright, if you dump the exe’s strings and foreach the table like I do, you can - it’s just a pain in the arse and not guaranteed to be properly). So some sort of function dump including arguments - it doesn’t matter if those are still C++ified - would be nice.

Disable mods: Some way to disable certain directories from being loaded/considered as mod would be neat. For debugging purposes and to exclude meta data (git/svn/etc).

Well, since it’s gone RFC since I begun this I think I’ll complete the list once this goes public.

1 Like

wow, you rewrote quite a bit… :smile:

I suppose I have one quick question: who is the manifesto designed for? are you targeting the modding elite (to gauge what’s missing, what can be improved, etc?) or the modding novice? or more likely both, I suppose… I only ask as some pieces might be hard to digest for the novices…

still skimming

edit: and now we know @ing someone makes them aware of invisible topics… :smile:

Well, that’s what I get for for being a nice guy I guess. :expressionless: I should have said nothing and completely abuse that inside information.

About version two: What isn’t stroke out in my first post + OCD whitespaces in foo’s definition (end needs to be 2 more left or so) and the target of “radiant:modules_loaded” ( would be nice.

1 Like

This topic is now visible. It will be displayed in topic lists.

@Ponder, just made a quick pass on the content, with only some very minor formatting adjustments (could very well have been how my phone was displaying the material)…

for emphasis, you may want to wrap single word code references in the code tags (I think there are 2-3 of those, and I couldn’t pull it off easily on my phone)…

otherwise, it looks good to me! :+1:

The luabind classinfo() function returns a C object with 3 fields: name (a string), methods (a table), and properties (also a table).

For example:

-- print all methods exposed by Point3
for name, _ in pairs(class_info(_radiant.csg.Point3).methods) do
    radiant.log.write('', 0, name)

That should get you started. Let me know when you figure out data traces. =)

1 Like

Looks like I’ve crashed the party. Sorry about that. Might as well continue then.

  1. What’s completely missing (e.g. we know there needs to be a mod loading / load order framework. What else?)

File API: Some API that could write, read and modify files - be it for settings, output or other stuff. I would refer to GMod’s file library which does a solid job. The basic points are:

  • isolated write access: Writing is only possible to *.txt files inside of “data/”. Reading is possible within the whole game folder, every file.
  • Relative: Multiple relative levels on where to operate (i.e. relative to the game root, mods folder, data folder, …)
  • Not necessarily required, but probably useful would be to have a class-based approach (instead of simple file.write/ (GMod’s File). I’m not sure if reading/writing binary should be possible that easily - while it offers some neat functionality (reading qbs for example, perhaps even modify those files?) storing data in JSON would probably be more Stonehearth-ish.

AI documentation: I guess this chapter isn’t closed completely yet so I don’t expect it, but it would be nice to have.

Loading custom textures inside mods: I think that’s not possible. I could be mistaken. Definitely something that would be useful for own buffs/effects.

Javascript debugger: localhost:1338. Please. I’d like to do that simple press-F5-and-reload-the-GUI magic too. It’s annoying to be forced to restart the game all the time. Also, since we’re about it, console.log stuff.

Querying events: Some sort of querying stuff. GMod’s hook example is a terrible one (foreach (hook_func in hooks) { if (hook_func()) return result; }) as it’s lacking priority and one malformed mod can mess things up. I’ve done it with a proposal event system in RP and I guess it works okay. It’s the best I can come up with right now. Especially for factions, this could be neat.

Timers: Feel free to glance at RP for my take on it (I guess it could be optimized by splitting it up into day/hour/minute events instead of checking all of them every stonehearth:gameloop). That components are using their own interpretation (stonehearth:renewable_resource_node, stonehearth:buffs) is really off-putting and not very general. It’s also not as tunable as I’d like it to.
Bonus points: I think it will get really weird if you plan on keeping the hourly events for coordination. I imagine something like 18:00, all settlers suddenly become tired, all apples fall from trees and a giant monster spawns - all within the same frame. But I’m aware that’s probably just a WIP.
I just really, really like my timers.

A more JSON compliant parser: Honestly, I’ve had another error in my manifest because it thought it was a better idea to merge "foo" "bar" to foo""bar than to throw an error. This is creating so many unnecessary logic errors that could be avoided. I’m looking at you, rp_alternate_naming.

Binary modules: A very, very long shot and I don’t have any project that could use them right now either. GMod (I’ve been scared from those two years) offers lua module support, which means that (specially installed binaries - different folder, not accessible by lua, therefore they need to be installed by the user; kind of “safe”) the Source Engine’s realm’s open too. We won’t need that because the game is open but support for it could come handy for special stuff that cannot be achieved with lua.
One project that I had in GMod was to write a binary module that wrapped the Midi interface. I was able to play Half-Life 2 using my electronic keyboard. It was pretty rad. It was also pretty weird to have the game play stuff on my keyboard (i.e. the other way around) - which resulted in some of the odd music videos I made. Popular examples would be databases (server administration?), music dlls (bass3 or something I think) or networking APIs (for Twitter/what not).
I know that this is a breach of the classic sandbox idea so it’s a sensitive topic. But think of the possibilities. We could have carpenters write to Twitter (“Just made a new #DinnerTableForOne! #Wood #Furniture #DeepmunFurnitureWeek)…

skip_title and the mini island: Still want.

Magic mixintos: As mentioned in the other thread, a way to modify jsons (for example by simply using "remove(key)") would be nice. Alternatively, some hook that enables us to modify/patch the json on the fly in lua - which is probably a better idea. Some event for load_json would be nifty. For bonus points, that should happen when C loads a json too.

Resizing: I’ve reported that already to you, just mentioning again that set_scale does nothing until the model variant has been switched to a different (physical) qb file. A different variant is not enough.

qb matrix modification: Long shot, don’t expect it anytime soon. A way to modify matrices, color them completely or something else would be nice. For starters, a simple set_voxel(x, y, z, color) would be nice enough - even if that means having to create a new model (i.e. instead of modifying an existing one).

model_variants modification: I don’t think we can really add or modify model variants - but I’ll need to check with the new classinfo that @Ponder provided…

lua/js mixintos: I’m not sure about this one. I don’t know how mixins work, but would assume they’re just JSON. Patching is bad and all, but if there was a way to modify lua classes (i.e. right before the module return) that could probably help too. Might be a lot more complicated, however. The same goes for JS.

Thought bubble: .oO(
The last bit is important because I think no matter how well you design the API, there will always be one case that’s not possible to achieve with it. While some things can easily be “restored” with require and friends, it’s usually much more difficult than being able to write in-place code.

Of course, the question of how willing you are to add an interface for that one’s mod desire (which can be very specific and therefore uncommon) is another thing. Even if you were (able) to do that, the delay until the next patch could easily put that mod on ice or kill it completely.

  1. What can’t you do that you want to do using this framework?

With or without doing all the stuff you guys don’t want me to? :stuck_out_tongue:

The question doesn’t have a real answer for me. Between a lack of C/engine/game documentation and a lack of events, there isn’t much. It’s mostly just annoying to patch the stuff properly (looking at you once again, world_generation) to create something nice.

I have been playing with the idea of doing full overrides of those pesky files to provide an experimental API - for example, one that would would give complete access to tree/vegetation placement, perhaps even the world generation itself. Something dead simple that can’t really be done without re-writing/re-copying a large portion of the code - or just the file itself (recent rp_developers_dreams became annoying enough…). For the world generator, this means that I would completely replace the original generator and move the current data to a json (I’ve got a first draft of that format already) - mods could then just mixin RP’s json file to add their stuff. And of course, events to modify it in lua.

Now that I think about it, there are a few things.

Event ordering: Speaking of patching json on the fly, I think it’s important that this would happen in some sort of ordered fashion. I’ve been experiencing issues in GMod where another addon was doing nonsense but got loaded before mine - rendering mine completely unusable. The only way to fix that was to remove their hook and re-insert it, or even re-insert it wrapped to make sure they didn’t interfere.
So, to be able to sort those would be neat. I don’t think that numbers would be enough though, something that would be more fine-tuned (as in, “execute my commands after mod X if present” and then some number system?) would be nice. Some meta-points (“first”, “last”) could probably help too, but then again there’s always math.huge I guess…

Component operations: Components can be added. It should be possible to remove them, too. Same goes for buffs.

lua/JS interoperation: I don’t know how well that’s implemented and it’s been a while since I’ve tried to do stuff with it. The basic idea would be to call JS stuff from lua, similar to call handlers.

Proper input on/off: Although I’ve coded something like that into RP, something more official that disables input capturers would be nice. I’m thinking of situations where all input must be dead - cutscenes, focus on <input> fields and similar. In both JS and lua. Maybe cutting off input isn’t as good of an idea as promoting some sort of “should I ignore keyboard input?” - that way we can still have rp_guitar_steve. Not sure.

Start menu: Completely aware that you know it. Just teasing that I’ve had it since three weeks! Haha! Mine!

Recipe modification: Name’s program. Enabling and disabling, removing and adding recipes. Offers possibilities for research, discovery, level/skill based systems and more.

  1. How can we modify the framework to make it so you can do it (e.g. do we need to trigger more stuff? are certain things (like world_generation) missing parts (like a .json input file) which you’d like to mod?) Without monkey patching, re-implementing, or wrapping parts of the system?

Well shoot, that’s a pretty complete list of crimes I’ve committed…

On top of my head the list would be:

  • World generation stuff (WorldGenerationService, Landscaper, Terrain* - but I assume since the glacier thing is pretty high on your list, this will come soonish in a completely different version?). As mentioned above, a json that defines vegetation would be sweet. Bonus points for a more complete documentation on how maps are generated and how we can generate our own tiles. But again, the whole biome stuff is likely to change a lot soon-ish (?) so I think that’s not that important.
  • Factions. Factions. They don’t make any sense right now to me - you give them a name ( “civ”) and at the same time every time you want to access the faction, you also have to pass the json file that describes it. Wouldn’t the alias be identifier enough?
  • Some initialiser would be nice - i.e. defining a file that is loaded to replace/patch that function. It’s a dilemma: For total conversions, patching makes probably more sense (Egypt or Asia likely behaves completely different than our little Northies) but for single mods (rp_lucky_worker as stupid example) make more sense.
  • On top of that, the current system is kinda racist. It should be possible that faction A can use faction B’s stuff. I’m thinking of OpenTTD right now, where the game is fun but cooperative playing is only possible within the same company. So some relations between factions could be neat. Seeing as some are already completely re-defining the game, new factions are already kind of a thing.
  • Proposal: Initialisation file that is called after the faction was created (defined in the faction’s json) that can patch functions or listen to events if necessary. Refactor code so it’s possible to do more fine tuning (taking from RP’s design, I would think of something like gender/entity ref/name/stats for starters, which would be separate functions that can individually be overloaded. The main create_citizen publishes pre/query/post events (overwritten functions have a higher priority - i.e. the default function would be nil events), calls the (overwritten) functions and therefore allows to customize it without dealing with any patched functions. No hassle with updates). That sounds really awkward, I could probably better sketch it as pseudo-lua class if you want me to.
  • In that sense, the start camp could use some customisation too.
  • For many of the AI actions (or general for AI stuff). An event for “I’ve started chopping down this tree” and “I’ve chopped down this tree” would be nice, as example.
  • JS can use some more events too.
  • I think to get a real “feel” of what is required it’s just necessary to lurk around a bit, see what people do and how they do it. See also below for more details on that.
  1. Is there anything that’s absolutely impossible to do in this framework? What is it and how would you like to do it in a way that works for all modders who might not be cooperating with each other (or even know that each other’s mods exist)?

That question is just a wrap-up of the others for me. What is completely impossible is in 1), what’s possible but not so quite fancy is 2) and the other stuff is 3).

Regarding “getting a feel for the community”: I think an issue could be that some aren’t going to directly ask “How can I do X?”, either because they have found a way that it works (I remember the recent “How can I place my trees?” - “I’ll just overwrite landscaper.luac” discussion. Override is a very powerful tool and I guarantee it will be abused like mad) or because they don’t know what they actually want to do or how they can achieve it.

If you are familiar with programming, you likely have a clue what “override” could be simply by hearing the name. If you aren’t, that’s one possible hurdle already. Although in this case “overrides are simply overwriting files” is quite easy explained, I’m not sure how one would go on about “You need to subscribe to events published at the world generation service. Just add a function in the table there that spawns your tree at the location given in the first parameter” (horrible example design, but I wanted to get as many fancy words in it as possible) is a bit steeper.

The way I’ve approached it so far was by simply checking what other people do and improve their ideas or simply (re-)implement what they want to do. Of course there are dangers associated with building an API solely on current demands, but to be fair I really think whatever API is built now isn’t final and it absolutely does not have to be. Not every event needs to be peer reviewed (stonehearth:is_harvested would have failed that one, I guarantee it hide) and they might as well disappear or change over time.

The important thing is to keep people in the loop. I would cite GMod again with the update go GM13 which broke every single addon, but the official document was called “Why your shit broke, and how to fix it”, so I’m not going to l link that one… Anyway: If there is a proper documentation of changes (“stonehearth:foobar is now a two-event part, stonehearth:foo and stonehearth:bar, the first parameter bla bla bla here’s some example code before/after”) nobody (or very few) have valid reasons to complain. Sometimes these logs are also the only real information about certain things and that might not even be intentional.

Not having worked in the industry at all, but I think that the sooner you start, the sooner you get a hang of it - how to do this stuff in a way the community responds to. Starting now at a nice pace, there’s just that one big meanie (Hi) and a few other dedicated people. In a few months, there’s probably dozens of people that are going to ask why your changelog is so horribly formatted.

I also think I’ve written enough for one post - hell, if you read all of this in one session I’d be impressed. I think I’ve spent… two hours on this now? It’s gotta be interesting to see discourse estimate the time it takes to read this topic…

digests most of the massive wall-of-feedback

heartily second this request… makes for easier RAD… :smile:

Off-hand, .lua instead of .luac, in-game debug window so we can see errors, and the ability to load mods from folders rather than just .smod or w/e.

All of which has I think been promised, so… yay :stuck_out_tongue: . But seriously, there’s a big difference between quality-of-life / ease-of-modding improvements and capability-of-modding improvements, and frankly it looks like Stonehearth is shaping up great in that regard. What else, hmm…

  1. Editing mod files without quitting the game (well, at least without exiting further than the main menu) - will save time. Not actually a big deal for me personally, but thought I’d throw it out there in case.

  2. A map format that’s easy to edit, for obvious reasons. Definitely something I’d like to see.

This. The less stuff that is hard-coded, the better for modding purposes. Whatever else happens, try to aim for this ideal.

Opens 50MB .txt wishlist…

Okay, I jest. I’ve had a few thoughts about what I’d like to do in Stonehearth though (but so far have been doing artwork not coding, so haven’t really looked into the nuts & bolts), so let’s see…

  1. Carts & trailers: I’d like to be able to hitch my horse to a cart / cannon / whatever & be able to transport goods / people around via it. Script-wise, you’d want to specify an attachment point (or points) to join multiple entities, and then make sure they move in a certain way. Not to mention what they do when detached - horse artillery will not want their horses running off after turning around to deploy their cannons after all.

  2. Convert a structure into a unit & back again. Two options here: first, allow pre-designed (ie like the basic alpha game house) structures, which the game can recognise as a structure (“Hello, I’m the Doctor…”). Second, allow anything built that’s within certain limitations (eg not connected to the ground, or volume smaller than X). If anyone’s used the zeppelin / airship mod(s) from Minecraft… yeah, imagine that in Stonehearth.

  3. Portal gun physics. That means displaying whatever’s visible through each portal (also useful for CCTV mods etc), reasonably realistic momentum & gravity mechanisms (Moon mod anyone?), and Portal 2’s fluid / paint mechanics (loads of other uses for liquid physics). I can see the last one being the most difficult to code.

  4. Large “units” you can live on - like ships. Fishermen after all often live at sea in order to catch lots more fish than they otherwise would. Also useful for the inevitable airships, landships, and eldritch abominations that carry lesser evils on their backs.

  5. Population control - let modders adjust how many more people (and raiders) you get per X wealth. Related to this, good job alert logic - games like Gnomoria slow to a crawl when there’s too many workers scanning for jobs every microsecond.

  6. Railway lines - complete with specialised track sections & carriages. A key component here will essentially require limiting what kind of terrain the trains can move on (ie “railway lines or crash”), which will be handy for other mods too (zerg + zerg creep anyone?).

  7. Property rights: Basically, a way to designate a building (or at least its contents) as belonging to an individual (or family, if marriages make it in) - or for public use, or for a job (eg “mayor’s office”, but the mayor may lose his re-election, die, or whatever). Doubly important if you have, say, a downstairs carpenter’s shop & bedroom upstairs - the last thing you want is a random person using the bed or eating at the carpenter’s table :stuck_out_tongue: .

  8. Mechanisms: Probably with “wireless” connections to control devices. Should allow for everything from a portcullis or drawbridge to, say, automated quarries and whatnot.

As I indicated, it’s quite possible that a lot of what I’m proposing is already doable in the Stonehearth engine, but I figure better safe than sorry, and the sooner I get my ideas across the more likely something will be done about them :slight_smile: .

unless i’ve missed your meaning (entirely possible), this is currently available, via placing your mod in this location:

C:\Program Files (x86)\Steam\SteamApps\common\Stonehearth\mods

perhaps you meant an interface to load them?

Two Three Four! things I just remembered:

  • can’t do: (2) Point3 and Point3f need better compatibility to each other. Adding and subtracting should be possible (and yield a Point3f likely), they should be implicit convertible to each other. I have no idea if that’s possible with luabind but in the worst case manually messing around with the metatable should do the trick. I don’t think I can do that though without a wrapper.
  • not implemented: (3) Something to save configuration more easily (the reverse to util.get_config, more or less). Not necessary but probably nice-to-have would be some validated configuration loading, i.e. with default values and checks to make sure that values have (at least) the proper type. Something like the stuff RP does, but prettier.
  • impossible: (1) A list of all available (i.e. loaded?) mods. If possible access to their manifests too.
  • can’t do: (2) Please complete the implementation of harvest_node, i.e. the generic “Harvest some component” I don’t think that one’s complete yet, at least it doesn’t seem to care about the component that was passed at all. But I could be wrong.

Now that’s my final list for a while.

Won’t happen, is already in place (I think? wasn’t that added in r34? It’s breaking my console so I had to turn it off…), is already possible.

GMod introduced that feature and shortly after made it possible to opt-out. It’s hell of a task if you want to get into detail - because GMod is even a bit stricter organised than SH, this will get quite difficult. If you’re interested in the general idea, Garry had a blog post about it. Personally, I don’t think it’s achievable nor desirable. It’s rarely worth the hassle in real development. I can’t imagine it work here, the architecture is too… open. Too dynamical.

What you would save in boot up time is what you lose with debugging “fragments” from previous scripts.

Render targets have little to do with Portal, they were present in HL2 already. I guess they’re way older than that, though. I could imagine them being useful, for example to keep an eye on one location while moving to another one (Traffic Giant had such a thing and that was actually nice to keep track of the jams…)

I can’t see much use for the fluids physics (or any sort of physics beyond simple kinematic) to be honest. This is going into the tiny-its-bitsy-micro managing part that players will likely not notice at all (i.e. nothing that couldn’t be simulated with some fancy effects and animations). Plus, imagine that being done on a bigger scale than the tiny rooms Portal 2 plays in.

Edit: Alright, four things. :expressionless:

[quote=“SteveAdamo, post:15, topic:5281”]
unless i’ve missed your meaning (entirely possible), this is currently available[/quote]
No that was my point - it’s already promised / implemented. As far as “ease of modding” issues are concerned, I really don’t think Stonehearth has many issues at all. Most of the stuff in this thread seems to me to be more along the lines of modding capabilities rather than quality of life.

Hmm. Another thread I’ve seen here indicated that Radiant would (might?) stop obfuscating their code etc once the game was nearer release:

[quote=“RepeatPan, post:16, topic:5281”]GMod introduced that feature and shortly after made it possible to opt-out.

Personally, I don’t think it’s achievable nor desirable. It’s rarely worth the hassle in real development. I can’t imagine it work here, the architecture is too… open. Too dynamical.[/quote]
Yeah; like I said it’s not a big deal for me personally, my point was that it would be a quality of life improvement. I can imagine that for a lot of minor things (graphic tests anyone?) it would come in handy, less so for more complicated stuff. Basically just throwing this point out there, but not expecting anything to come of it.

I’m sure, but tying it all together under “Portal stuff” sounded better :wink: .

Two things here: first, terrain features & structures like waterfalls, fountains etc, which would benefit from having reasonably well-behaved water. What does that mean…

  1. Flow mechanics (ie where does the water go?)
  2. Fill mechanics (ie waterfall into pool fills pool up)
  3. Ripples
  4. Waves & tides (seas)
  5. Arcing water (eg fountains)
  6. Splashes / spray
  7. Refractive index
  8. Reflections

Number 1 I would consider absolutely essential, and I’d be surprised if we don’t see it in the game. 7 & 8 will be needed if we’re to have even the option of better water than Minecraft (!). 3 & 6 could be done with pre-designed animations that play around objects walking in water / landing in water (then just scale up/down for the size of the object), which ought to reduce the need to model complex physics. 4 would be tough on engines, thought at least you could simply state “if body of water > X voxels, assume sea” and link that to the world gen system (for partially-explored bodies of water) to determine whether or not to get waves/tides in the first place. Still, I’d expect 4 to be the one most likely to not make it in. That leaves 5, which might be a bit of an issue for engines, but on the other hand likely wouldn’t be encountered much unless you spammed giant fountains etc: waterfalls don’t tend to arc, and just about every other body of water will be flat anyway.

Second, now that I think about it, the blobs of Portal 2 paints / gels don’t actually work like a continuous stream of liquid, but as said blobs - which is probably a lot easier to do anyway.


Alright, I was too focused on lua. It can work for graphic resources - but that’s about it.

Nonsense. I would even go as far to say that there is no really satisfying fluid simulation available today that is good looking, realistic-ish and does not require three NVIDIA Titans to run. Hell, Minecraft and Terraria struggle with water simulations (although both are not really that surprising). Starbound does a pretty decent job as far as I can tell - but that’s 2D too.

gm_botmap_v3, as example, has absolutely lovely graphic effects, including a very well made water fall. It’s a bunch of cuboid brushes and particle effects. It’s not simulating anything (except a very simple drag) yet it’s not using any real resources.

Anything for fluid simulation that goes beyond very, very simple spread-fill-and-drain would be a waste of CPU in my eyes. So far, CPU’s the bottleneck regarding the AI - I’m not sure if you want to tighten that even more for something more than eye candy.

Remember that even if you don’t see the water, it still has to be calculated. Otherwise, your river might run dry because its source was off-screen. This makes water a pain.

I don’t think P2 gel mechanics could be used at all here. Although yes, it’s little more than an entity flying around - as soon as it lands, it applies a decal on the map which then triggers stuff once a player touches it.

In the future when I start a game I want to be able to pick through a list of mods that this game will load and save, I want that list to be permanent, this game will always have those mods and to have a different set of mods I would have to start a different game.

This is well known, what is completly missing is I don’t want that list to come only from a Radiant Entertainment server. The Eclipse IDE has a great moding system. For each location on the internet where mods are available I give the IDE a name and URL. Each mod from that server is listed and I can choose to download and install them.

So on my start game screen I could have a list like this:

  • Radiant Entertainment
    - Mod 1
    - Mod 2
    - Mod 3
  • Voxel Corp
    - Mod 1
    - Mod 2


1 Like

The building of houses brick by brick is a really cool feature. I would like to see this easily moddable too.
Ideally even with 10x10x10 ‘buildingblocks’ instead of 1x1x1. So you can build all kinds of things with it.