Ideally, when a hearthling accesses the storage. But from the answers I deduce that won’t be an easy task. Perhaps I will stick to “open on approach”.
1 Like
Finally got myself to look at how it’s made. I now see your point.
For anyone else curious about this thing, I’ve made a quick lazy research.
In vanilla it’s basically made with mixins. Programmers will quickly get what I’m talking about. Basically:
Any door has several behaviour patterns assigned to it (programmers: think “interface” and multiple inheritance). Location: SH.smod/entities/…/your_door.json, “mixins” block.
There is a pattern “single door” which assigns a set of default small door animation triggered by an entity called “sensor” (which obviously has a trigger radius). Location: SH.smod/mixins/doors.
Another “destructable” pattern assigns door HP and aggro it generates. In our case it’s useless, but good to know. Location: SH.smod/mixins/…
Actual animations are suddenly assigned in another file. Location: SH.smod/entities/…/your_door_ghost.json, “mixins” block.
Location of animation mixin: SH.smod/mixins/doors/…_ghost.json.
It generally assigns a list of available animations (/data/rigs/) and default animation (closed).
I assume the logic is this:
Default “closed” animation (loop) > Hearthling enters sensor range > Door open animation (single) > Hearthling leaves sensor range, no other hearthlings in range > Door close animation (single) > Default “closed” animation (loop).
As of crafting stations, they have a defined “working” state, and the animation is tied to that state. Basically: item in the queue, heartling works on it > animate object. I see it as a more complicated way since it not only requires AI modification, but raises problems of its own. While crafting animation is looped. When dropping we need single playback without any loops (open - pause - close). Dropping to a container is almost instant while crafting never is. Ideally opening should be triggered a few moments before dropping (otherwise it would look silly), but trying to predict when is a guy going to drop a haul overcomplicates things.
So, as I’ve said - I’ll stick with the first option for now.
so you can’t just reskin / remodel a door and make it look like a chest? 
I can, but it would be a door-y chest.
And that’s exactly what I’m gonna do.
1 Like
now if only you also made a bed model as well that looked like a coffin you could invent a new race of monsters 
bring on the vampire mod 
ah-ah-ah 
Summoning @Hyrule_Symbol for help! 
Okay, so I’ve (somewhat) familiarised myself with Blender (and VoxelPirate’s import script). The questions are
- What is the purpose of helper skeleton points, like “root” or “head”? I’m currently digging door animation, and there are these bones aside from the obvious “door” and “frame”. Does the animation really need those in this case?
- Can I somehow import qb model into Blender, preserving matrices’ info but without Qubicle?
PS. Useful link for others - VoxelPirate’s Blender import guide.
The helper bones such as ‘root’ and ‘maid hand’ are markers for the animations,
‘Root’ is Essential for the animation, as it’s an indicator for where the model’s center is(being the 0point of animations) when the model isn’t centered to begin with, which is the case for most creatures,
The others like ‘mainHand’ are use as positions for addig new models such as tools and weapons(also ‘head’ isn’t a bone, it’s probably an actual head)
I’m not quite sure, as far as i know, Qubicle is the only way to go about this aside StoneVox, which i’m not sure if it still works, blender can’t read .qb files, there might be an add-on for it, but i wouldn’t bet on it
1 Like
Okay, I’ve somewhat hurried with the conclusions. I still have to edit lua, but these edits seem to be less complex.
@Hyrule_Symbol Can you take a look at this? I can’t get it to work.
What I (in my understanding) have done:
- Created a new model for iron chest. Two matrices: “chest” (bottom) and “chest_lid” (top)
- Created full /entities subfolder cloning files from wooden leatherbound chest
- Modified existing door skeleton to accomodate - moved origins and renamed bones to fit the matrices
- Created simple animations in Blender and exported them into json, replacing existing ones (“opened” is a reserve one, there is no such animation for doors).
- cloned mixins for a single door (and ghost), renamed them and changed paths
- modified chest and chest_ghost json under /entities - added mixins like in door json (but removed “destructable” mixins since I don’t need them)
Nevermind the iconic version and descriptions - I didn’t change them from the wooden chest.
What I do:
- Start a new game on the latest dev build and use dev stamp to create a chest.
What I expect to get: - A working chest that also has a door behavior (i.e. it animates when someone gets close)
What I really get: - The chest is working but I don’t see any animations.
@Drotten
There are some things I can’t figure out. The door is an immobile object (it can be built or teared down but it can’t be moved). That, as far as I understand, is also a behavior.
Chest, on the other side, is movable.
My chest is movable. Does it mean it didn’t get door behavior at all? What does the “fixtures” property in mixins do?
Also unclear how does the game resolve collisions in this case. A door has a changing collision (in opened state it is passable) while a chest is always solid.
PS. I feel a terrible itch to stuff all the knowledge I hope to get here in the wiki for future reference.
From what I understand, the only behavior you want from doors is that it will open and close. This is something you gain from the door_senor kind of sensor; it has nothing to do with whether or not the entity can be moved, just that it will open itself when someone gets close enough.
I assume you’re talking about the stonehearth:fixture component. That one’s used for stuff that are placed on structures, e.g. windows and doors. From what I gather, it’s connected to the building logic. Chests have no use for this though, so you can safely ignore it.
I like to see it more as that the door’s collision is ignored (always) for friendly people, which would help with pathfinding and stuff like that, and that it will play an animation when someone gets close enough or when someone leaves its area. I suspect that the same will happen for the chest; that, people it considers friendly, will be able to just walk through it, i.e. its collision will be ignored.
1 Like
All right. According to this, i don’t need fixtures (deleted).
This thing, however, can’t be deleted.
“stonehearth:portal”: {
“cutter” …
Don’t know what is it exactly, but it obviously has some connection to the boundary region. The game throws engine error if I delete it.
No idea what “stonehearth:entity_radius” does either. Not sure if I need this.
PS. There is some progress. At least I hear opening sounds. That means the sensor is working and triggering effects. I suspect now the problem is in the model/animation itself. Can’t track the source, though.
The suspicious thing is animation files have values x10 bigger than the skeleton. Don’t know why.
I’m not really sure either, but it’s best to leave it there then if you get an error otherwise.
Well, in melee combat it’s used to determine how far the entity can reach to strike someone. Not sure what it does for doors though, you might not need it, but there’s no real harm to keep it there either (for the game that is).
It looks odd, yeah. But it’s hard to say whether it’s supposed to be like that or not from just looking at the animation files. Best is to see the animation in effect, if the lid is moving as it should.
1 Like
Yup. The problem is, the animation still doesn’t work, only sounds.
The repository is available on GitHub. Maybe Hyrule will be able to find the problem. Or I - as soon as I get some sleep 
In what way doesn’t it work, does it not play at all, or are the parts not animating as they’re supposed to?
If it’s not playing at all then it might have something to do with that you used MagicaVoxel for this, though that’s just a wild assumption on my end.
Not playing at all.
As far as I understand, SH uses “effects” under /rigs/ triggered by sensor states.
Every effect has a sound and an animation from “animations” assigned to it.
The sound plays fine (from which I deduct the sensor works and triggers effects) but there is no animation.
My workflow was
- General model in MagicaVoxel
- Split into named matrices in VoxelShop, export to qb
- As VoxelShop can’t export to obj, export matrices into separate dae files
- Import dae into Blender
- Position, animate, export skeleton and animations into json
Unfortunately I can’t check model integrity Cubicle-wise as I don’t have it.
Ah, you used VoxelShop in the end, then it shouldn’t be a problem in that case.
Effects can have sound and an animation, but they’re not really needed. You could easily remove the sound or animation and the effect would still work. You could also add more sounds to it, though you should limit yourself to only having one animation at most per effect. Other stuff can be added there as well, such as particle effects and lights.
1 Like
i didn’t check the skeletons and animations yet, but i think the place of the model is a little off
the door doesn’t have any vertcial rotation so i think it’s okay to have the matrix’s top part incorrectly sized, bur i wouldn’t expect the same for the chest
also, the door seems to follow the trend of having the model at the edg of the plane, probably to know where’s what
here’s a image of how it should look in my eyes
i used the ‘resize’ tool and made it size itself with the model at the same location (you can do that by manipulating the arrows in the UI though i’m not so sure with voxelshop)
for all i know, you deen the matrix size identical form one another
again; i didn’t check if all of this works and i don’t really have a way of doing it
all i can say is that it’s different from how the doors are modeled
2 Likes
I think this is what determines the region to cut when placing the door / window on a wall. This makes the hole on the wall so the door fits on it.
1 Like
Understood. I find sounds useful as they help narrow the search for errors.