Glass Window Rotation Error

Modeling & Animation
1

Two problems:

  1. Regardless of the size of the window, it places correctly for North and East positions, but offsets by 1 for South and West positions. This also extends to the iconic file, as when placing it with dev tools, it shows own direction but when placed, rotates 90 degrees.

BeFunky Collage
BeFunky Collage.jpg3996×1329 667 KB

  1. Is there a way to prevent them from just walking through them as an open door? My large window is basically not even there to them.

Appreciate the help, as once this is fixed, I have a couple other windows to add before releasing this mod.
atlas_expo.smod (28.8 KB)

2

Do you have debug enabled? (Those little icons on top right)
If so, one of them (can’t remember which, just test it all) is useful to align the items into the correct position.

To add a collision to your entity, you can also do in that same debug, you add a hitbox and align it as you want, then it generates a json to you that you can copy into your files.

3

It’s written as a window, which originally I used that debug tool to figure out the alignment. Problem is, once you place them in a wall and then change their position, they disappear completely.

Oh, forgot to add that out of a wall, they rotate just fine when being placed with the dev tools.

4

Capture

Sorry @BrunoSupremo, but I’m not seeing how to add the hitbox either. Any chance you could show me what I’m missing?

5

Oh sorry. The option to change hitboxes (and add more) only appears when you already have at least one hitbox… :frowning:
In your json, add this:

	"components": {
		"region_collision_shape": {
			"region": [
				{
					"min": {"x": 0, "y": 0, "z": 0 },
					"max": {"x": 1, "y": 1, "z": 1 }
				}
			]
		}
	}

Just so you have a dummy hitbox. It will then show it in that debug, and you will able to edit it to fit your model.

1 Like
6

While it should work, it creates a smallish problem as a side effect: windows create cramped environment because they have hitboxes, what makes no sense as in real life rooms with windows seem lest cramped and if you need space you’d like to have a window. I haven’t tested it yet but there may be a different way to prevent Hearthlings from going through windows. Taken from wooden_window_frame_tall.json:

   "components": {
      "movement_modifier_shape": {
         "modifier": -0.5,
         "nav_preference_modifier": -0.5,
         "region": [
            {
               "min": { "x": -1, "y": 0, "z": -1 },
               "max": { "x": 1, "y": 3, "z": 2 }
            }
         ]
      }
   }

I guess setting the modifiers to -1 makes them not use the windows to pass at all. Of course you’d have to modify the region so it covers the glass part of your window. I’m not sure whether it works or is an old feature not working anymore.

For the rotation error there is a simple trick to fix it: you need to alter region origin, set x: 0.5 and z: 0.5. This way rotation is done while centered on a tile instead of an edge (what may cause the integer tile coordinates to change).

7

SO F*****G CLOSE!!!

By changing the region like you said, it fixes the rotation when placed on the ground, as well as the hitbox rotates with it. It does not, however, fix the rotation when placed in walls as windows. But thank you for sharing this as it fixes other objects thus far.

8

I remember having the very problem with some Archmod prototypes. For windows aligning to x axis (and only x) usually does the trick. Sadly there’s the disappearing window problem which makes Entity Editor useless for properly setting model origins for windows so you have to modify the .json, restart Stonehearth and place a new window via Item Stamper every time.

1 Like
9

Align to grid fixes the rotation problem, and makes the window rotate properly. But then it also places the model one square to the right too far. And if you add the model origin code after the align to X, it cancels it out.

Now, if you change the bounds from

     "bounds": {
        "min": { "x": -1, "y": 0 },
        "max": { "x": 1, "y": 6 }
     }
  },
  "stonehearth:portal": {
     "cutter": [
        {
           "min": { "x": -1, "y": 0 },
           "max": { "x": 1, "y": 6 }
        }
     ]
  }

to

     "bounds": {
        "min": { "x": 0, "y": 0 },
        "max": { "x": 2, "y": 6 }
     }
  },
  "stonehearth:portal": {
     "cutter": [
        {
           "min": { "x": 0, "y": 0 },
           "max": { "x": 2, "y": 6 }
        }
     ]
  }

with the model origin and region define, it flips it so the north and east rotations are wrong, but the south and east are right. I’m ready to nuke this game…

@pingu was telling me in a message though that it’s a misalignment with the model, being I’m using MagicaVoxel and not Qubicle. Is there anymore insight to this?

10

@pingu is right, you should have the model origin as close to the center of the model’s base (that is: centered in x and z but y = 0) as possible. This should be done via .qb, not using model_origin as it gets superbuggy when axis alignment is used. I use Qubicle so I don’t know how to fix that in MV, upload your .qb file if you want me to check it in Qubicle.

11

That is actually the intended use for that setting… That is what is for, to center things, or to move it. Even using Qubicle you can’t always get the position you want.

12

I’m trying to catch-up on what’s going on here, but there’s one thing I want to ask that I do not see an answer for yet.
Before exporting your .qb-file from MagicaVoxel, did you remember to flip your model on the x-axis?

MagicaVoxel and Stonehearth has inverted x-axis (compared to the other).
Surely this is not the cause of all your struggles, but it’s a good thing to keep in mind in case you get to models that are not identical on all sides :slight_smile:

Also, is the link in the first post updated according to your changes? Otherwise, would you mind sharing your current version?

13

It is a symmetrical object, that would make no difference.

14

Correct, I ment to say that flipping is good when objects are not identical on all sides.

15

Ok, sorry for not doing this before. Seen all this confusion above, I went ahead and downloaded you mod to see what is going on.
Here is the fix:

Summary 
{
	"mixins": "stonehearth:mixins:placed_object",
	"type": "entity",
	"components": {
		"mob": {
			"align_to_grid": ["x"],
			"model_origin": {"x": -1, "y": 0, "z": 0.2 },
			"region_origin": {"x": 0, "y": 0, "z": -0.5 }
		},
		"region_collision_shape": {
			"region": [
				{
					"min": {"x": -1, "y": 0, "z": -1 },
					"max": {"x": 1, "y": 2, "z": 0 }
				}
			]
		},
		"model_variants": {
			"default": {
				"models": [
					"file(thirdpane_beamed.qb)"
				]
			}
		},
		"render_info" : {
			"color_map": "atlas_expo:color_map:glass",
			"material_maps": [
				"/atlas_expo/data/materials/material_maps/glass_material_map.json",
			]
		},
		"stonehearth:fixture": {
			"cursor": "stonehearth:cursors:create_window",
			"margin": {
				"left": 0,
				"right": 0,
				"top": 1,
				"bottom": 1
			},
			"bounds": {
				"min": { "x": -1, "y": 0 },
				"max": { "x": 1, "y": 2 }
			}
		},
		"stonehearth:portal": {
			"cutter": [
				{
					"min": { "x": -1, "y": 0 },
					"max": { "x": 1, "y": 2 }
				}
			]
		}
	},
	"entity_data": {
		"stonehearth:catalog": {
			"display_name": "Third",
			"description": "Third",
			"icon": "file(thirdpane_beamed.png)",
			"category": "window",
			"material_tags": "clay portal crafted window stockpile_portal"
		}
	}
}

Oh, this is just for the window, but you will know how to adapt it to the door, right? Just increase the y. I also added the collision box, you will need to remove it for the door, I guess.

3 Likes
16

You area god among men. What was I missing or doing wrong?

17

Nothing, just needed some tweaks in the coordinates. Basically you need to make it able to rotate around its own center, and then shift it a little to the side., You can see this effect better by placing one with the debug on the ground, and clicking on the rotate button.