Adjustments to object heading when opening Toolset areas

[ThornsM]

When rotated objects are used, for example their heading set to 180, they remain in that heading while the area is edited and they bake in that heading.
If the area is closed and opened again, rotated objects can find their heading changed by small fractions of a degree, maybe from 180 to 180.0000168. A result of this is that in baking an area that has just been opened, it can result in a messed up walk mesh.

Anyone know why the headings do not remain fixed, or means by which this niggle can be managed?

[7threalm]

lock the horizontal or vertical locations, also if the placables are genertating walkmesh boundries they will conflict, and push one out. You can also set them to enviromental and manually cut the walkmeshes so there is a boundry you set, a logical one

all placeables generate a walk mesh when baked, environmental objects do not.

placables act funny when the operate in the same space.

Most of bgtscc placeables are set to enviromental, and the walkmeshes are cut in manually.

its the easier to set them to enviromental so they can occuply the same space and dont generate a walk mesh, trying to go the other route is a pain in the arse.

[ThornsM]

Thanks, but the objects in question are height locked and position locked, yet that does not lock rotation.
The objects are placeables because they are needed for the walkmesh, they are stairs or sections of floor.

The entire area can consist of a single rotated placeable and still the same problem occurs. Create a new area, put a placeable in it, rotate it by 90 degrees, save and close the area. Then open the area again and it'll be at 90.000206 degrees instead, or is for me.
This often does not matter, but when you are joining floors and other walkmesh dependent objects, they have to be exactly aligned or you'll get some crazy triangles.

[7threalm]

you can also use vertical walk maps, for them, for stairs and such. (basically they create a walkmesh that is vertical /-

they look like ramps - i dont if you have them. That is the easier way with stairs and such, they generate a walk mesh around the ramp not the stairs themselves.

a quick test is set it to enviromental then see if it moves, if it doesnt then your spacing is off.

object dont have to be placable able for walkmeshes, you can make your own and trick them so they look like it

or anothe option is look at it in wireframe mode and see where the meshes are that are auto generated.

the walkmesh burn is tough, and your get frustrated in the longrun (speaking from experience)

https://neverwintervault.org/project/nw ... nsion-pack

[ThornsM]

I don't seem to have any walkmesh ramp helpers, just the standard flat ones. But the walkmesh helpers are objects too and all objects are affected by the rotation issue. So the helper will be nudged from 90 to 90.000206 degrees just the same as the stairs or floor that they cover.
I'll see if I can find a download for the ramp object, but regardless, I guess I'll just have to realign a few dozen objects each time I open the map in question.

[gedweyignasia]

Create a new area, put a placeable in it, rotate it by 90 degrees, save and close the area. Then open the area again and it'll be at 90.000206 degrees instead, or is for me.
This often does not matter, but when you are joining floors and other walkmesh dependent objects, they have to be exactly aligned or you'll get some crazy triangles.

This sounds like the level is being stored with less precision than it's held in memory in the editor. AoS might be able to dig through it and tell you exactly what's happening, but if it's being saved with lower precision there might not be a fix.

(i.e. you're positioning objects with 64 or 32-bit floats for x,y,z,theta and in the module file the placeables are kept as 32 or 16-bit floats, so the next time it's loaded the trailing 32/16 bits are lost, and you get something a tiny fraction away from where it's supposed to be.)