Taking Questions about Mixintos and Overrides


#141

I couldn’t check where the file paths pointed because it didn’t show me the mixintos. I’ve tested with just the Flagstone mixinto (big tree), but Jofferson continues to ignore its existence :cry: (though that mixinto works, just as the berry_bush one I made before).

EDIT: Finally I got the mixinto to work as I wanted, without an override. (Using three models for a juniper tree that originally/vanilla had only one). I don’t know how I did it, since I’m checking and I have the same code as I posted above…

Mixintos are additive, I already know, but you can change properties, right?
I mean, the ‘big_tree’ mixinto is overwriting the name and scale. That’s why I think my mixintos overwrite the models for the berry bush and juniper trees. I only see my models, not the vanilla ones, nor a combination between them.

On another note, I would really like for Jofferson to detect the mixintos, I thought it already did it but for some reason it doesn’t and it would be really helpful for fixing the invalid filepaths.


#142

It does detect mixintos…?

Make sure that you are using a recent version (current one is 1.2.0.0 - check by right clicking the exe, “Details”) and that “Errors” (bottom left) is zero. If it isn’t, click on it. If there is a wrong mixinto, chances are that it is showing up in the error list, not in the “normal” list. That’s kind of not pretty and I’ll have to re-evaluate how to deal with those cases.

Big difference: render_info is an object, model_variants is an array. You can overwrite properties (elements of an object) just fine, but array elements cannot be overwritten, merely added.

Let’s talk business:

{
  "property" : "value",
  "another_property" : "another value"
}

MIXINTO

{
  "property" : "mixinto value"
}

RESULTS IN

{
  "property" : "mixinto value",
  "another_property" : "another value"
}

That’s for objects.


Arrays are different:

{
  "array" : [ 1, 2, 3 ]
}

MIXINTO

{
  "array" : [ 2, 4, 6 ]
}

RESULTS IN

{
  "array" : [ 2, 4, 6, 1, 2, 3 ]
}

It’s recursive, i.e.

{
  "array" : [ 
    {
      "key" : "foo",
      "value" : "bar"
    }
  ]
}

MIXINTO

{
  "array" : [ 
    {
      "key" : "foo",
      "value" : "mixinto"
    }
  ]
}

RESULTS IN

{
  "array" : [ 
    {
      "key" : "foo",
      "value" : "mixinto"
    },
    
    {
      "key" : "foo",
      "value" : "bar"
    }
  ]
}

and not like you may expect in one element with key = foo, value = mixinto. This is exactly what happens to model_variants: Instead of modifying the model variant, you are adding another one. For example, your original mixin results in (this is not JSON but lua tables - but you should see what I mean):

stonehearth:small_oak_tree = {
   ["mixins"] = "stonehearth:mixins:tree";
   ["type"] = "entity";
   ["components"] = {
      ["unit_info"] = {
         ["name"] = "my tree";
         ["description"] = "description.";
      };
      ["render_info"] = {
         ["scale"] = 1;
      };
      ["stonehearth:commands"] = {
         ["commands"] = {
            [1] = "/stonehearth/data/commands/chop_tree";
         };
      };
      ["model_variants"] = {
         [1] = {
            ["models"] = {
               [1] = {
                  ["items"] = {
                     [1] = "/rp_test/models/trees/juniper_medium/medium_juniper1.qb";
                     [2] = "/rp_test/models/trees/juniper_medium/medium_juniper2.qb";
                     [3] = "/rp_test/models/trees/juniper_medium/medium_juniper3.qb";
                  };
               };
            };
         };
         [2] = {
            ["models"] = {
               [1] = {
                  ["items"] = {
                     [1] = "/stonehearth/entities/trees/oak_tree/small_oak_tree/small_oak_tree.qb";
                     [2] = "/stonehearth/entities/trees/oak_tree/small_oak_tree/small_oak_tree_2.qb";
                     [3] = "/stonehearth/entities/trees/oak_tree/small_oak_tree/small_oak_tree_3.qb";
                  };
                  ["type"] = "one_of";
               };
            };
         };
      };
      ["destination"] = {
         ["region"] = {
            [1] = {
               ["min"] = {
                  ["y"] = 0;
                  ["x"] = -3;
                  ["z"] = -3;
               };
               ["max"] = {
                  ["y"] = 1;
                  ["x"] = 4;
                  ["z"] = 4;
               };
            };
         };
      };
      ["stonehearth:resource_node"] = {
         ["durability"] = 4;
         ["resource"] = "stonehearth:oak_log";
         ["harvest_overlay_effect"] = "/stonehearth/data/effects/chop_overlay_effect";
      };
   };
};

So it might work (assuming that model_variants just picks the first (unnamed) model variant), but technically you are not overwriting the original definition - you’re just adding your own that, for some reason, gets loaded first. I wouldn’t necessarily rely that this trick continues to work…

But I see that maybe a tool that “simulates” mixintos and overrides could be helpful. Maybe a website instead of a C# program this time? Or I could implement that into Jefferson, I suppose - but unless you can confirm that it does show mixintos in your version, that would be wasted effort :wink:


#143

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:


#144

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…


#145

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


#146

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.


#147

@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:


#148

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.


#149

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:


#150

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…


#151

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:


#152

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…


#153

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


#154

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…


#155

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


#156

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.


#157

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:


#158

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.


The Modding Requests
#159

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.


#160

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…