openmw.org

Interesting... I didn't know that the issue with NPCs slowly changing their position over time was still present in OpenMW. Does that mean it was build in intentionally? Is it bound to some other functionality? It clearly is a bug that can cause problems, as was mentioned before. I was under the impression, that this is one of these peculiarities of the original engine that could be avoided from the start in OpenMW.

On the topic 3 - Migrating npcs

The follow report is in the UMP forum at http://www.theassimilationlab.com/forum ... xing-npcs/

"Skrawafunda
Posted 20 September 2014 - 08:31 AM
I've just finished checking the animations in-game. I've created a cell in which I've placed 9 NPCs, all Caravaners. The first one (called idle0) had the same AI package as all caravaners have (Idle2 60%, idle3 20%, idle4 10%, idle5 10%), while the 8 others all had 100% for only one of the idles. So we had one idle0 with mixed percentages, reflecting how most standing NPC travel providers are, and 8 NPCs, each called "idleX" where X is the number of idle animation the NPC only presents.
The tests were carried out on NPC with Z rotation of 90.
What the checking yielded:
1) Standing NPC usually deviate their position coordinates on the very moment you meet them for the first time, depending on the animation they exhibit. (Meaning their Coordinates in TES:CS =//= their coordinates in game)
2) The position deviation seemingly depends on the moment of animation that the NPC was playing the moment you leave the cell
3) As a result of 2), the position deviation vector doesn't necessarily have a constant value. (From my testing this usually meant that the general vector direction was still the same, with only the increases differing in value. Only in one case, idle6, the changes differed so much that the vector's direction could change from going into negative Y changes from positive changes and even then change again.
4) Some idle animations cause stronger deviation than the others
5) Only two idle animations do not cause deviations at all: idle3 and idle7. These are the only cases where NPC position in TES:CS == NPC position in game
6) Fast-travel does not only affect the providers themselves, but also any other standing(unmoving) NPCs in the cell.
Edited by Skrawafunda, 20 September 2014 - 08:33 AM."

So this problem is in the animation itself. The team is looking for a animator to fix these issues.

Or, again, when you leave the cell, you could just discard any change in NPC position if the NPC has only "travelled" via idle animation.

Yeah, I'm not entirely sure if flushing out all changes to positions after traveling would be a good idea, seems more realistic to perform a check before each animation to make sure the actors stay in the same location and reset them according to that, the resulting animation may come out a bit more yanky than usual, but judging from the animation quality of the MW animations the result should not be too noticeable.

Manually replacing the animations may be doable, but that would mean that the responsibility of fixing this bug is moved out of the scope of the openmw team, which, in all honesty, may be a good point. Since we can't seem to find an intuitive fix to this issue within the engine, it might be a good idea to leave fixing it to an external mod team.
I can imagine that when openmw is done modders may want to make a collection of fixes for issues that is beyond the scope of the openmw project, since it frankly is unrealistic for us to expect the openmw team to fix issues that has nothing to do with the engine.

I don't understand what's wrong with my suggested fix! Or why no one seems to understand it!

I think the idea is not bad, no idea if it is doable but it would solve the problem independent from the animation that is played, so it is rather universal.

If the solution would be a mod, then maybe some sort of"Official openMW mod" that fixes this (and any other similar bugs that is not directly related to the engine.) could be included with the engine?

Uncanny wrote:If the solution would be a mod, then maybe some sort of"Official openMW mod" that fixes this (and any other similar bugs that is not directly related to the engine.) could be included with the engine?

Since the mod will likely be developed independently from openmw it might not be wise to include it with the engine, but I see no issue with providing a download from the site. All this is hypothetical though, the first part to this sort of mod is to actually make it.

I do think that making this sort of mod might be a good idea though, since it will take some of the work away from the openmw devs, leaving them to focus on other things.
An example of this is the recent fix against suicidal npc. The problem was that the script instructed them to go somewhere far away, which happens to be in the middle of the ocean. This script was not accepted by the original MW engine because of engine limitations, so to fix this an arbitrary limit was introduced to the openmw engine to ignore all instructions telling npcs to move over a certain distance.

This sort of arbitrary limit may work for the vanilla game, but it will limit the mod capability of the engine, and could have been avoided through an external mod, changing the script itself.

onionland wrote:Yeah, I'm not entirely sure if flushing out all changes to positions after traveling would be a good idea, seems more realistic to perform a check before each animation to make sure the actors stay in the same location and reset them according to that, the resulting animation may come out a bit more yanky than usual, but judging from the animation quality of the MW animations the result should not be too noticeable.

Can't do that, because there are idle animations that legitimately move the actor, such that they're supposed to be in a different position at the end than when it started.

A more proper solution would be to add AI packages that will make NPCs walk to a specific spot to idle at, so if they ever end up getting moved too far away for any reason, they'll walk back to the spot before idling again.

Chris wrote:Can't do that, because there are idle animations that legitimately move the actor, such that they're supposed to be in a different position at the end than when it started.

A more proper solution would be to add AI packages that will make NPCs walk to a specific spot to idle at, so if they ever end up getting moved too far away for any reason, they'll walk back to the spot before idling again.

First, I agree with your more proper solution. However, second, they're idle animations! Who cares if they get discarded?