Taking Questions about Mixintos and Overrides

Well, for sure I got any medium juniper tree, its instances were replaced with one of my 3 candy floss trees, so I got my three trees in my world at the same time.

I think you’re right, supposedly I’m adding to the array, so this might not work in the future or have unexpected results in other conditions.

I’m using the last version of Jefferson you mentioned. But sadly it says Errors: 0.
I downloaded it from here and checked, it’s version 1.2.0.0. But for some reason it doesn’t work for me, the mixintos part. Look:

The nihonjin mod, which has mixintos, clearly a folder with mixintos, and they don’t appear here. And 0 errors. Do you think is fault of my computer? I have no clue :disappointed:

Wait, I’m pretty sure that nihonjin was working.

Edit: Sure enough, it doesn’t show up. I think I have a suspect already, just to test it… If you use a string instead of an array for the mixinto (i.e. "stonehearth:foo" : "file(..)"), it should show up? It looks like it doesn’t deal with arrays properly.

Yepp. It can’t handle arrays as mixinto. I’ll get onto that…

I imagine this is related to the mixinto/array issue I found with the personality system?

1 Like

That quote in specific was more about Jefferson being unable to deal with multiple mixintos. But the discussion before (about why adding and not modifying) is exactly what your problem was.

Yes. You ended up with two elements that both identified as “stuff to print when chopping wood” - and it just took an arbitrary one, probably the one from the last mixinto.

@sdee
Not quite related to mixintos and overrides but I was wondering if you could explain how animations work with objects?

I’ve noticed that the sleeping on the ground animation and sleeping in beds animations are the same animation (sleep.json) Does this work based on some part of this:

"destination": {
         "region": [
            {
               "min" : { "x" : -1, "y" : 0, "z" : -1 },
               "max" : { "x" :  2, "y" : 1, "z" :  2 }
            }
         ]
      },
      "region_collision_shape" : {
         "region": [
            {
               "min" : { "x" : -1, "y" : 0, "z" : -1 },
               "max" : { "x" :  2, "y" : 1, "z" :  2 }
            }
         ]
      },
      "render_info" : {
         "scale" : 0.22
      }

I’ve been tinkering aorund with animating and my plan is to make futon (no not the western couch/beds) style beds into my mod at some point. Since the sleeping animations are the same no matter what the height it would be wise for me to just use the animation already in stonehearth if I can figure out how to do this.

I guess I can ask @Tom as well since he was making the animations on the livestream and @Ponder because I don’t want him to think I’m choosing sides . :wink:

We can guess what destination is doing based on @Ponder’s side note regarding entity scaling:

Spinning that thought a little further I would say that destination is likely part of the pathfinding/AI - the area in which/next to an AI has to be to be considered “at” the entity.

That being said, the “height” you wish to modify is a hardcoded constant in the AI (sleep_in_bed_adjacent_action.lua; bed_location.y = bed_location.y + 1 - setting it to 50 results in quite weird things). You won’t come far without overloading the AI action.

(Also, for those kind of questions we would have the modding request thingy… if there was a new thread already)

If you want to get really creepy, what actually happens is that it’s playing the animation while the entity is moving from its current location to the bed in a very straight, linear manner. Without the animation, you would see the settler “sliding” onto the bed. The animation merely “hides” that effect right now.

1 Like

Hmmm looks like I’m going to have to start thinking about the lua code. Decompileing luac files still not working right? I’ve been trying to ignore lua and luac like the devil, so I’ll have to kickstart my work with it. o.O

Thanks for the responce. :blush:

1 Like

Well, depends on what you define as working. Is it producing lua files without complaining, the answer is yes. Are the lua files error free or similar, the answer is maybe. There’s plenty of files that are broken with the current update, I’m aware of two and know of at least one other that affects the game after a day or two - I suspect the current AI scheduler thingy.

In any way, I wouldn’t recommend messing in the AI code unless you really need to. There’s no way (and there’s not going to be one) to override lua files - so you have to do the dirty patching yourself. Which means re-writing major parts of the code, keeping that code uptodate in case of an update, and and and…

Hmmm very true. Might as well just look into the files and try to figure out what’s going on to prep for later, since I have very limited programming experience. :wink:

there’s the ol “can do” attitude we need! :wink:

give it a go, and just bounce your questions off the folks here… hopefully you can find a reasonable solution to your problem…

Is it possible now to add custom idle animations with a mixinto?
I don’t want to touch the lua files :worried:

I did not try it yet, but my guess would be yes. If nothing has changed you do not need to edit an existing Lua-file, but you will have to create a new one for your animation…

2 Likes

Has anyone gotten a mixinto to work since Alpha 2 dropped? My overrides are all working but even the simplest mixintos are failing. :confused:

Mixintos work fine for me. Make sure that your mixinto is correct - especially the change of model_variants from an array ([]) to an object ({ } with each key being the model variant’s name) could cause errors.

Jofferson does not catch these errors right now, I believe - but it should at least show an unchanged mixinto, too.

Edit: And Jofferson 1.3.1 does that.

1 Like

Trying to figure out htis new model_variant set up, especially the "eyebrows"
I’ve been trying to figure this out but it seems to not be working. . . Anyone know why this isn’t working?

{
    "type": "entity",
    "mixins": "stonehearth:mixins:base_human",
    "components": {
        "render_info": {
            "animation_table": "stonehearth/data/rigs/humans/skeletons/male.json"
        },
        "model_variants": {
            "default": {
                "models": [
                    "stonehearth/entities/humans/male_1/body.qb"
                ]
            }
        }
    },
    "entity_data": {
        "stonehearth:customization_variants": {
            "root": {
                "variants": [
                    [
                        "topknot"
                    ]
                ]
            },
            "topknot": {
                "variants": [
                    [
                        "topknot_black", "topknot_grey"
                    ]
                ]
            },
            "topknot_black": {
                "models": [
                    "file(head_topknot_1_black.qb)",
                    "file(head_topknot_2_black.qb)"
                ],
                "variants": [
                    [
                        "nothing",
                        "eyebrows"
                    ]
                ]
            },
            "topknot_grey": {
                "models": [
                    "file(head_topknot_1_grey.qb)"
                ],
                "variants": [
                    [
                        "nothing"
                    ]
                ]
            },
            "eyebrows": {
                "models": [
                    "file(beard_black)",
		    "file(goatee_black.qb)"
                ]
            },
            "nothing": {}
        }
    }
}

When the game loads it’ll only load head_topknot_grey for the heads. Tried adding the “eyebrows” variant to that variant as well and it still spawned… :frowning:

If you are using mixinto remember about additive stuff as usual.

As for the customization variants,

if variant.models then
	local variant_name = "default"
	local random_model = variant.models[1]
	local model_variants_component = entity:add_component("model_variants")
	model_variants_component:add_variant(variant_name):add_model(random_model)
end

if variant.variants then
	for _, variant_set in ipairs(variant.variants) do
		local random_option = variant_set[math.random(#variant_set)]
		self:customize_citizen(entity, all_variants, random_option)
	end
end

This should shed (some) light. Basically, eyebrows has to be reachable through some variants from root.

In your case, root, topknot, [ topknot_black, topknot_grey ], [ [ nothing, eyebrows ], [ nothing ] ] eyebrows is only reached if topknot_black is used.

If I am reading this code properly, then there’s the xkcd issue.

But that’s just for the model, not the variant. In theory, there should be some citizen that has head_topknot_1_grey.qb as model. Feel free to post your mod so I can throw a few prints into the SH code to look for it - but right now it looks like the bit is still WIP.

I’m using an override at the moment.

I’ll message you a link to the smod I’m using. It’s still odd that only the topknot_grey is the only one working. I have male_2 set up as well and it seems to add “eyebrows” (technically beards) every so often but it only seems to use one of the hair variants. . . Very odd.

Yeah, I tried a simple mixinto and they don’t work. Probably because the team is changing the formats and establishing the mod api…
What I know, is that finally they work as they should, because my old mods overwrote somehow the models with my own list of models, and now they add, as a mixinto should do (horrible images of several trees overlapped come to my mind x_x).

The problem is that now I can’t do anything. Overriding seems fine, but why a mixinto that only changes the name/description of an entity doesn’t work? Is it because of its true nature (adding?) I’m trying to fix my candyland mods, but if I don’t get the mixintos to work this is going to take time…

Yeah, I am having that problem. Mixintos to change things like in-game name, description, scale, not working.

It seems that mixintos are purely additive, i.e. cannot overwrite existing attributes.

… funnily enough, Jofferson is doing exactly the same. Uh… Okay? That shouldn’t be this way.

As for the Candyland… Jelly could solve some issues that you have - because you can override its landscaper completely. :wink:

Edit: It seems as if properties cannot be overridden but everything else (adding properties to objects and items to arrays) seems to work just fine. Uh. I think it’s rather a scary coincidence that Jofferson, by accident, simulated the game’s “broken” behaviour so well…