Taking Questions about Mixintos and Overrides

Hmmmm okay. I was thinking it had something to do with one of my heads since it’s the only one that wont choose a beard variant for some reason while the other ones work. o.O

I got that message in the log, too, and I’m touching different things than you. The log registers it even without any mod.

It sounds a lot like a translation error. libjson interprets the (compiled) entry as “boxed”, which it cannot resolve (probably because it expects an array or an object) to lua.

It probably means that either the mixinto or the final JSON was not properly transported to lua and therefore, whatever you did, is not going to show up. Or, at least, this certain entry is not.

With RP and the console, you could check by running luas_run PrintTable(radiant.resources.load_json("stonehearth:small_oak_tree")) for example and see what the lua looks like.

Out of interest, what does Jofferson’s current version say? My personal mixintos seemed to work fine, but I haven’t really touched anything too serious.

I could probably squeeze some mixinto stuff into the third position on my list, however…

Edit: Right, I’d have time to take a look if you want me to - I do need to know what you were doing, however. If you could send me your projects (or a very simple test case) then I could have a look. Otherwise, you want to figure out which mixinto exactly is causing the error - and then which part of it.

I noticed that error sometimes in the log too.

Not sometimes. ALWAYS.

By the way, this needs to be fixed, or Avairian won’t be able to have his mod as he wants :sweat_smile: (unless he wants to touch the code files)

I’m going to change my mod and overriding the json files, as the tree variants arrays are simple (unlike the human customization variants) and will be able to have more variants. Nevertheless, modding the human variants with overriding of qb + variants in mixintos still has to be tested.

If you talk about the random generator acting up, I very much expect them to switch to their own PRNG at some point. Until then, I’ve posted a fix for that. You’re free to re-distribute that smod anywhere or simply include that line in your code.

I would personally recommend to not hold too much for the tree variants. For your project, I wouldn’t touch the trees at all.

The issue is like I have mentioned somewhere else, even if you override everything, the entity is still called stonehearth:small_oak_tree. Let’s say I’ve written a very badly scripted mod (rp_chainsaw) which allows cutting down every tree ten times as fast and yields a thousand logs per tree. For that, it simply mixintos all stonehearth:*_*_trees.

Now your candy tree can be cut down by my chain saw and produces lots and lots and lots of wood - something which is not necessarily intended.

Overwriting and mixintos are powerful tools, but you have to keep in mind that other mods will, in the end, expect at least the original entity. They can’t (and shouldn’t have to) know what you have done to its definition.

My offer still stands regarding the json_to_lua error, send me an smod where the error happens and I’ll take a look.

1 Like

Mmm… you’re right… But then I’ll have to deal with overlapped trees Q_Q
The json_to_lua error is not mine, is a general error, that happens in the world generation (I think, because I always catch it twice and not always even put the flag on the ground before closing the game).

I guess it’s time for me to get all your other tools and try them u_u
I need to see what really happens with the entities.

Proper approach (in my humble opinion): Have your trees as own entities rather than mixintos. Then get Jelly, override jelly:index:trees with your own JSON containing definitions for your own trees.

That way, not only can you get only your trees to spawn, but also in whatever configuration you please*

Never happened to me. The error likely happens when the entity is created, as that seems to be the time when mixintos are applied. So a broken mixinto won’t throw an error until whatever you’ve mixed into is loaded for the first time.

* While Jelly does work as one would expect, there’s still one or two things that are a bit odd when you want to do completely customised stuff. If you simply want to replace trees in the rough same way the game does it (or would do it with override), Jelly is your man.

I’ve just executed the game without any mod folder besides radiant and stonehearth, and the log catched that error twice (and I closed the game before placing the flag). So don’t look at me… Remember that Jofferson considers the stonehearth folder full of errors…

I’m just waiting for the team’s modding api to advance, I don’t want third party tools that might break, but if this is the fastest solution for the moment (and by your footnote seems perfect for me), I’ll take it gladly, as I’m doing lots of things atm and don’t have much time left to dedicate to modding x_x

(In fact they’re really helpful tools, I think I couldn’t live without having something that checks for errors in my mixintos).

Is there a way to see debugging information with the latest release? (Besides the cpu bar)

1 Like

Well, that’s the price early adaptors have to pay. I’m really planning on providing support for things that are used, however (RP doesn’t seem very used to me besides my own mods, which is why I’ll gladly let it die/replace it). That being said, the recent change of model_variants was quite a heavy one too - I would imagine that this is the worst that happens to Jelly stuff too (besides switching from Jelly to the official API, of course).

It’s the fastest and for modding authors cleanest way currently available. For what you want to do, it will totally suffice - the examples that aren’t working as you would expect are things like “I want to spawn clustered trees in the mountain”, which the normal game doesn’t either.

Hm, weird then. I’ve never had it happen to me with all the stuff I’ve made. It’s true that SH.smod is heavily “bugged” from Jofferson’s point of view; but all of these are orphaned, i.e. nothing points towards them so I doubt that they can cause any trouble. They’re about as harmless as having invalid aliases in your mod that all point to non-existing files.

Depends on what you consider debugging information. You can turn on some loggers to get additional information and personally I’m using rp_console to test scripts/dump stuff, but that requires some lua and game knowledge.

1 Like

Yes, xD
Well, to tell you the truth, I wasn’t thinking on start to mod this early, I preferred to wait, but at the same time I wanted to see my stuff in action into the game, so…
What I mean, is that I don’t mind waiting at all, I just wanted to fix the mod since it’s posted in a web and people that download it would make disgusted faces when seeing it doesn’t work =T

uh, I completely forgot about RP -.-‘’’ I feel dumb now. I’ll take a look at it (finally). It will be really interesting if it still works, I think I’m going to have fun :smile:

It does work to some extent, I think rp_time_is_money is acting up with the fog of war however. Keep in mind that RP will be phased out pretty soon, however, because it was still built before we had any modding tools… A lot of stuff in there has become obsolete by now :wink:

What isn’t obsolete will be carried over to Jelly in one way or another.

1 Like

Giving this very interesting thread a push… just played around a bit and I think the related entry from one of the past Destop Tuesdays is a nice starting point for all wannabe-modders out there:

http://stonehearth.net/2014/01/14/desktop-tuesday-a-peek-inside-the-modding-api/

2 Likes

@sdee hope you did not get bored as there where not so many questions lately :wink:. I am playing around with adding own recipes and @RepeatPan’s post further up is quite a good starting point:

So far adding new recipes works fine if you add new categories (like above “My First Pony Farm”). However, trying to add another recipe to an existing category causes Stonehearth to create another category with the same name. Any way to get this done with the actual build or is this maybe on the to do list for future changes?

2 Likes

I wrote this code some while back, but it should still work (the JSON path might needs adjusting if I recall correctly). You’re welcome.

1 Like

Thanks @RepeatPan for your fast reply. I have assumed that you will come up with a small “hack” to solve this challenge. Would love to see the “Modding UI” supporting such kind of adjustments without touching the Lua-Code as that might be one of the more common requests (e.g. adding own weapons).

Oh, that code is standalone sure enough. You can insert it into any mod, or even an own, as long as it’s executed on the server (similar to my math.random() fix.)

However, yes, it would make sense to have some functionality for this. However, even I can’t think of a proper solution for this (except maybe offering built-in functions to do what I just did, which is more or less a GROUP BY). By changing the data structure to an object, you lose the ability to sort properly (unless you add an index or position or weight attribute too, therefore making things more complicated than they already are).

I thought about implementing such a helper function in RP, maybe Jelly, but as for now, there’s no real demand. I’m just sure that this isn’t necessarily something that should be done by mixintos.

Yes. Right now it’s a huge pain that mixintos work best with maps, while the handlebars templating in Ember only takes arrays. The recipe format was written so the UI doesn’t have to do any parsing, but I expect the recipe format to change when we allow for dynamically added recipes, and when we do that, we’ll probably use a different format for specifying categories.

2 Likes

@sdee @RepeatPan
Is it with the current alpha-version possible to give an entity 2 different commands? For example renewable resource and chopping. It used to be possible, as I used it in one of my mods. They might have changed it since then. As it might conflicted with mass gathering command.

In the stonehearth/call_handlers/resource_call_handler.lua it says this:

function ResourceCallHandler:harvest_entity(session, response, entity)
  local town = stonehearth.town:get_town(session.player_id)
  if entity:get_component("stonehearth:renewable_resource_node") then
    town:harvest_renewable_resource_node(entity)
  elseif entity:get_component("stonehearth:resource_node") then
    town:harvest_resource_node(entity)
  elseif entity:get_component("stonehearth:crop") then
    town:harvest_crop(entity, "/stonehearth/data/effects/chop_overlay_effect")
  end 

With my non-existing code knowledge it seems it only can choose 1. And renewable resource as first priority?

I haven’t touched SH code in ages so all I can share is some memory about this:

All AI harvesting tasks share one table. That means, if you queue somebody to harvest a renewable resource, you cannot queue them for harvesting them normally. In addition, the object becomes unharvestable until it was replenished, even for the, well, “final” harvest.

The code you have posted does basically exclude this, yes. If a resource is renewable, it cannot be harvested normally - at least, not with this command. It’s not checking whether the resource is currently available (and shouldn’t in my opinion).

The whole system isn’t built to support multiple resources from one entity (yet). That was an issue I ran into with rp_growing_trees too.

You could create your own command which calls the town-function itself I suppose. There shouldn’t be any harm in doing that - harvest_entity will, however, continue to be the one that’s used for the “normal” harvest command.