A question about scrips and items

[Fair Strides 509]

I don't think going below the ground will work. Only works on placeables and doors and stuff. Creatures are glued to the ground, even in the .git file.

[JCarter426 1,215]

It works with some modules. The walkmesh is a bit wonky at points, and it's possible to teleport to locations outside the main area, usually far below it. Even if it doesn't work, the game should ignore the Z value in such a case but not the X or Y so it wouldn't hurt to try.

 

There is one other problem though. It's possible to have the camera facing in a different direction than the player is.

[Fair Strides 509]

If you're referring to the areas on Telos, the lower areas are actually part of the walkmesh and perfectly valid in the game's logic. I've never head of the game ignoring the Z value in any cases for creatures, regardless of how they're made...

 

Edit: And if you really wanted to, there is the SetCameraFacing function to correct the issue.

[JCarter426 1,215]

If you're referring to the areas on Telos, the lower areas are actually part of the walkmesh and perfectly valid in the game's logic. I've never head of the game ignoring the Z value in any cases for creatures, regardless of how they're made...

 

No, it... those are two different things.

 

There are some areas with just corrupted walkmesh data. There's a tiny bit that counts as a walkable point, even though it's not connected to anything else. As far as I'm aware it's not actually part of any room's walkmesh - probably just garbage data. But it happens with a lot of modules, not just Telos. And it's usually far below the rest of the module. One example is 950COR. It's possible to teleport into the skybox and for some reason HK-47 is hanging out there.

 

 

As for the second thing, what I mean is that when you spawn a creature it spawns in at the nearest possible location. So if you spawn one, for example, a meter below the floor, it will usually spawn it on the floor. It ignores the Z value you input because there's no walkmesh there, instead getting the nearest workable location. Generally this location has the correct X and Y value, but if you try to spawn something inside a wall or another object or whatever, it will similarly be displaced along those axes.

 

So if you spawn a creature with an extreme negative Z value, there's a chance it will end up at one of those weird points instead of any legitimate coordinates. But it's highly dependent on the module.

 

 

If you're referring to the areas on Telos, the lower areas are actually part of the walkmesh and perfectly valid in the game's logic. I've never head of the game ignoring the Z value in any cases for creatures, regardless of how they're made...

 

And if you really wanted to, there is the SetCameraFacing function to correct the issue.

I don't want to change the direction the camera's facing, though... that would probably be more distracting. I'd only want to get the direction, and as far as I'm aware there is no such function.

[Seikan 22]

Oh and by the way, if you have the time could you create a K1 version of the script, (just as the one I tested), Since it worked pretty well, i'd like to integrate it into my mod to avoid having different helmets for males and females, but there's no rush.

 

And I also was wondering, when it comes to compatibility, since it relies on modifying the OnHeartBeat script to trigger the script itself even if it wouldn't be hard to edit it, when it comes to publishing mods using it people might not have such an easy time editing the onheartbeat script, so is it possible to create duplicate onheartbeat scripts under other names which would still work, or any way to automatize adding a script trigger to it so people who use mods with it doesn't have to do it themselves?

 

Ps: I guess an option would be to keep track of every mod using it and create a list of the needed scripts triggered by it (i don't think there will suddenly be a swarm of people using it) and have every mod that uses it use the same OnHeartBeat script which already includes the trigger for the other scripts other mods would use.

[JCarter426 1,215]

Oh and by the way, if you have the time could you create a K1 version of the script, (just as the one I tested), Since it worked pretty well, i'd like to integrate it into my mod to avoid having different helmets for males and females, but there's no rush.

 

Yeah, I'll get on the K1 soon. Just a few adjustments because K1 lacks a few functions and I have to remove that info from it, and also account for a bug in K1. I didn't feel like doing that with an untested script but since it is working then I'll go ahead with that.

 

And I also was wondering, when it comes to compatibility, since it relies on modifying the OnHeartBeat script to trigger the script itself even if it wouldn't be hard to edit it, when it comes to publishing mods using it people might not have such an easy time editing the onheartbeat script, so is it possible to create duplicate onheartbeat scripts under other names which would still work, or any way to automatize adding a script trigger to it so people who use mods with it doesn't have to do it themselves?

 

Ps: I guess an option would be to keep track of every mod using it and create a list of the needed scripts triggered by it (i don't think there will suddenly be a swarm of people using it) and have every mod that uses it use the same OnHeartBeat script which already includes the trigger for the other scripts other mods would use.

 

All that's needed for compatibility is for the other modder to add the ExecuteScript line to fire your script, in addition to their changes. So it's not difficult, but it requires awareness of other mods that edit it and cooperation and such.

 

And regarding the head stuff... I did some testing and basically got nowhere. There's no way to consistently force an NPC outside the module, it's just too random. I had another idea that seemed like it was going to work, creating an NPC with no body, just the head hook, and placing the head hook below the module... but that didn't cooperate with the DuplicateHeadAppearance function, so it was a dead end. But it was close... so close.

 

Although, I did confirm the convoluted process does work. It's still just a matter of hiding the NPC from view.