Pointing your attention to the better to “read” part 
Maybe I’m just too dense, but I still don’t see what you’re getting at. 
Ah well, sooner or later you’ll be sharing your mod I think so I could wait until then to see what you mean. 
It’s not a Mod maybe exchange the word read with parse I hope that lightens it up
Oh! That makes more sense then; I was too stuck on it being a mod…
You’re making a mod creation tool for Stonehearth?
I’m trying to, yes, thats why I wanted to know some stuff about the JSON data and why I made some suggestions to the format of the JSON
I see, well good luck with that; I hope you’re prepared to change every part of your software as the game gets developed
If you have some other questions about other stuff just go ahead. 
Right now it is easy for me to implement new stuff or even changes since most of my code is generic for entities so far
And the only problem I have so far is with the models [] because it contains objects, and that is a bit hard to visualize so a user without programming knowledge can add stuff to it
Well you’ve pretty much got two different choices in adding one model either it’s always one model, or a random choice between several models. I’m not sure how you designed your program but that’s how I see it as, maybe it helps…
Also you should eventually have support for stonehearth:customization_variants. It’s more complex but it’s also much more flexible than model_variant as it chooses models depending on previous choices (e.g. a hearthling that gets brown colored hair also has a chance of getting a brown colored beard, but not a blonde colored beard).
Right now its based on classes for each property in components and entity_data so I can easily add new properties to both without changing much of my code.
That is the hard part, I have to construct an object based on the user iput and the user has to know what he is doing. I think the only one property is the root property everything else has to be user input, chosing names for the properties and stuff like that
Right now I think I have to hardcode the model_variants part so a user can chose between one type or the other. Let’s look at the brightbell_crop.json there are 4 variants, all dynamically named, not predefined ones like the default one. So a user has to provide both, the key and the value whereas for example with the unit_info a user only has to provide the values because the keys are predefined.
do you have read the dreams??? I had a dream in which a sheep bit me, and turned me into a sheep! But I could still talk. It was weird.
Well, I haven’t read the dreams myself, but I do remember when Yang added them in her stream a while back.
But let’s not derail the thread.
2 Likes
Das ist mein Thread, Finger weg
1 Like