Taking Questions about Mixintos and Overrides

Doh… I know the reason behind this…
It’s because the first model is smaller than the others, and as the three variants are in the mixinto, all of them appear, but the overlap doesn’t show up because the first model is hidden inside the other two variants.

But if I have similar models or recolorings, the variants don’t show correctly because of the overlapping. Sigh…

In short, adding variants to a tree leads to this result.

3 Likes

You are definitely doing more complex things with mixintos and overrides than we have been so far, so I’m really glad you’re shining a light in all these dark, unexplored places. :stuck_out_tongue:

I’ve taken a look at your code, but I think I’m going to actually have to test it myself before I can figure out exactly what’s going on.

3 Likes

I’ve been getting this error in my log every once in awhile with my mod:

lua.code | unrecognized object type 'boxed' in json_to_lua!

I believe it has something to do with one of the head variants I have created but I’m not quite sure what would be the cause. Json lint says it’s a valid file so I’m not sure if that’s the issue. . . Any ideas?

2 Likes

That’s an Alpha 2 related issue. I don’t think it’s related to mods. Probably it’s a thing related to the trapper. But anyway, thanks for pointing it out :smile: it was about time someone mention it.

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).