feedback to 0.47 / bug report / feature requests

[oldChimer]

Hello there, OpenMW team,

before I continue, I must state that this post is parted into three sections (endorsement, flaming, and suggestions/requests), so don't take anything of it too serious except for the requests and suggestions.

Endorsement: it's great that you keep working on giving MW a decent modern engine which runs on (at least) today's three major OSes, and I just tested the 0.47 and liked a lot of what I saw. But with some statements in your release announcement and the reference documentation you're running very close to going proprietary and to a good part MW-incompatible. See below for what I mean.

bugs/errors, flaming:

• OpenMW has the same bug as MW (which is corrected by the MCP, from which you copied two bug fixes afaik): rain and snow shouldn't fall through solids.

• auto-zooming the map does not work, at least not in the Qt/GNU version, despite what the announcement said. Or did I mistake that and it was a preview to the next version?

• openmw's NIF and texture handling is a bit erratic: openmw does seem to be incapable of handling UTF-8 file/directory names and fqfns (like an assignment of „textures/test/körper-muskulös.dds”) contained in NIFs, and double slashes (which are auto-corrected by original MW) like in „textures/foo//bar/honk.dds” are not handled. Both result in the good old „pink error” (things appear in shaded pink instead of textured, like in MW with wrong textures or nonexistant file paths). In today's times, this is a no-go and has to be corrected.

• btw: you state in the reference docs that normalmaps have to be DX format, not OpenGL, which makes a lot of Morrowind mods unusable until all normals are converted. This, also, is a no-go and merely a programmer's preference or bias which must not be enforced on modders and users.

• about half of the mods I use — many of them quite old, but running flawless in MW, do not work under openmw or they would if their scripts were ever handled/started. Examples are Wrye World/Wrye Travel etc., the Mog race mod, White Wolf of LoKKen, Children of Morrowind, MCA, and NoM.

• I encountered a strange bug: I installed OpenMW and tried it with the German GotY version of Morrowind, then replaced the German version with the English one to have one language in the game and all mods. When I started a new character, some of the audio dialogue was, irritatingly, German and not English. Second issue: in the German version, I had used TR 21, in the English one TR 19. When I visited a place called Id Vano, which existed in TR 19, distant land showed it, but when I came closer, it disappeared and was gone when I was there (Id Vano was removed in TR 20). Does OpenMW (or the libraries it uses) use some sort of cache, and if so, how do I delete it? Things like this should not happen, especially not when OpenMW is supposed to be able to handle several different installations with different sets of mods.

• once again: do not enforce modders to write compatible alternate versions which can be run by OpenMW. OpenMW ought to be fully compatible to MW, enhancing and improving on it. Hence, OpenMW must be able to run all Morrowind mods, and, sooner or later, all(!) MWSE scripts.

suggestions and feature requests:

• area loading and navmesh building should happen seamlessly in the background (maybe even pushed into background threads), not interrupting the game play. This annoyed in MW, and it annoyed even more in Oblivion and Skyrim where you had to stare at loading screens and wait.

• please incorporate the rain/snow fix. It's silly when you stand beneath a stone arch like the river gates in Suran (or the entrance to the Earthly Delights, for that matter) and rain falls down on you, and seems ridiculous when you have perfectly animated ground cover and weather effects at the same time.

• please incorporate MW-style camera and vanity camera handling, toggle-able between MW and OpenMW style in the configurator for the benefit of the player.

• please, and this is the most urgent request, before turning to graphical goodies like new shading and ground cover stuff, focus on a full and 100% compatible implementation of the morrowind scripting engine, including the safe „backdoors” which many mods use.

• in the scripting engine, maybe a compatibility layer for MWSE scripting would up-value OpenMW even more, making it a real competitor to the combo MW/MGE/MWSE. Otherwise, many good mods will be left out completely and OpenMW will turn into a proprietary „Half Morrowind, half something else”.

That's about it. I hope I was able to get my players' and modders' point-of-view across. I'm always open for comments, dialogue and lending a hand, if necessary, so let's make sure OpenMW does not end up as a proprietary Non-MW, but a player's choice.

[AnyOldName3]

OpenMW has the same bug as MW (which is corrected by the MCP, from which you copied two bug fixes afaik): rain and snow shouldn't fall through solids.

As this isn't vanilla behaviour and is something Bethesda didn't bother implementing rather than something they implemented that doesn't work, we'd consider this a feature we want to add rather than a bug we've yet to fix. Either way, it's tracked here: https://gitlab.com/OpenMW/openmw/-/issues/5492

auto-zooming the map does not work, at least not in the Qt/GNU version, despite what the announcement said. Or did I mistake that and it was a preview to the next version?

Coming in 0.48.

openmw's NIF and texture handling is a bit erratic: openmw does seem to be incapable of handling UTF-8 file/directory names and fqfns (like an assignment of „textures/test/körper-muskulös.dds”) contained in NIFs, and double slashes (which are auto-corrected by original MW) like in „textures/foo//bar/honk.dds” are not handled. Both result in the good old „pink error” (things appear in shaded pink instead of textured, like in MW with wrong textures or nonexistant file paths). In today's times, this is a no-go and has to be corrected.

We handle Unicode paths up to the VFS root (i.e. you can use Unicode in the data= lines in your openmw.cfg), but for compatibility with the original engine, paths within the VFS aren't Unicode aware. Off the top of my head, I think it either uses the current C locale, cp1252, or the content file encoding set in the settings. If you feed the original engine paths with Unicode in, it won't interpret them as Unicode.

Doubled up slashes definitely work. There are loads of them in the vanilla data files.

I think there's likely some misunderstanding of what the original engine does here causing the problems you're seeing, as we'd have far more people than just you reporting problems with this kind of thing.

btw: you state in the reference docs that normalmaps have to be DX format, not OpenGL, which makes a lot of Morrowind mods unusable until all normals are converted. This, also, is a no-go and merely a programmer's preference or bias which must not be enforced on modders and users.

All Morrowind mods with normal maps are specifically targeting OpenMW. The original engine doesn't support for normal maps and MCP and MGE XE don't hack it in, either. There are some existing mods which use D3D8 fixed-function bump maps, which aren't the same thing, and were supported by the original engine (although they didn't look right until MCP fixed them). We support that kind of texture.

As for later Bethesda games, they all use the DX format for normal maps as they all run on DirectX, so we're using the same layout as they do for ease of transition for mod authors.

about half of the mods I use — many of them quite old, but running flawless in MW, do not work under openmw or they would if their scripts were ever handled/started. Examples are Wrye World/Wrye Travel etc., the Mog race mod, White Wolf of LoKKen, Children of Morrowind, MCA, and NoM.

There's nothing open on our tracker for any of these, so if they're vaguely common mods, it's likely they're working for most people, or we'd have had issue reports before. I'm pretty sure I've seen some of them in people's load orders, and we've got closed issues for resolved problems with som of them, so it's most likely that they're installed incorrectly. Hopefully, someone will come along and help you out with them, but you'll likely get faster support via our Discord/Matrix/IRC as much more people look at those than the forums these days. If there's anything we can't sort out, we'll put it on the tracker.

I encountered a strange bug: I installed OpenMW and tried it with the German GotY version of Morrowind, then replaced the German version with the English one to have one language in the game and all mods. When I started a new character, some of the audio dialogue was, irritatingly, German and not English. Second issue: in the German version, I had used TR 21, in the English one TR 19. When I visited a place called Id Vano, which existed in TR 19, distant land showed it, but when I came closer, it disappeared and was gone when I was there (Id Vano was removed in TR 20). Does OpenMW (or the libraries it uses) use some sort of cache, and if so, how do I delete it? Things like this should not happen, especially not when OpenMW is supposed to be able to handle several different installations with different sets of mods.

We don't cache any of this - basically the only thing we do cache at the moment is the navmesh, which definitely wouldn't cause these symptoms even if our invalidation system was horribly broken. The sound issue is likely because you're using a mixture of the two setups (e.g. they're in the same directory by mistake or you've got both sets of files enabled in your config files at once). I know exactly how to reproduce the disappearing Id Vano with MGE XE, so is there any chance you're accidentally using the original engine instead of OpenMW?

once again: do not enforce modders to write compatible alternate versions which can be run by OpenMW. OpenMW ought to be fully compatible to MW, enhancing and improving on it. Hence, OpenMW must be able to run all Morrowind mods, and, sooner or later, all(!) MWSE scripts.

We intend to support all mods that work with the unmodified vanilla engine, and are very close to doing so. There are technical reasons why MWSE compatibility would be prohibitively difficult, though - it'd literally be several times easier for the OpenMW team to recreate every MWSE mod ourselves than it would to support them directly. We've had discussions with the MWSE team about possibly writing a common API that allows future mods to support both OpenMW and MWSE while not being limited to MWScript, but no meaningful progress has been made on that front yet.

area loading and navmesh building should happen seamlessly in the background (maybe even pushed into background threads), not interrupting the game play. This annoyed in MW, and it annoyed even more in Oblivion and Skyrim where you had to stare at loading screens and wait.

This is already how things work. Once you've loaded into the world, unless you've meddled with your preloading settings, don't have enough cores to load things in the background, are travelling incredibly quickly, or are playing the game from a network share in another country, you should never see a loading screen in OpenMW. Again, are you sure you've not been using the original engine instead of OpenMW?

please incorporate MW-style camera and vanity camera handling, toggle-able between MW and OpenMW style in the configurator for the benefit of the player.

Unless you're using a newer build than you've said you are and have a camera mod enabled (I'm not even sure any exist yet) the vanity camera behaves identically to the original engine. What do you think is different? Are you sure you're not just remembering what the original looked like incorrectly?

please, and this is the most urgent request, before turning to graphical goodies like new shading and ground cover stuff, focus on a full and 100% compatible implementation of the morrowind scripting engine, including the safe „backdoors” which many mods use.

The people who are good at graphics aren't the same people as understand the MWScript implementation, so it doesn't take away from one when the other gets worked on. Also, as a volunteer project, people are free to work on what they want to work on. If we stop accepting graphical improvements, our graphics programmers will find another project's graphics to improve rather than suddenly become keen on working on scripting.

Either way, we've only got twelve open issues for our MWScript implementation, and they're very minor things very few mods rely on. Any issues you're experiencing are likely on your end, so we should be able to walk you through sorting them out.

in the scripting engine, maybe a compatibility layer for MWSE scripting would up-value OpenMW even more, making it a real competitor to the combo MW/MGE/MWSE. Otherwise, many good mods will be left out completely and OpenMW will turn into a proprietary „Half Morrowind, half something else”.

There are already a lot of people who don't see MW/MGE XE/MWSE as a competitor to OpenMW anymore. Ultimately, trying to play catchup with whatever already exists leaves us lagging behind forever, whereas aiming to surpass it means we can surpass it.

[elsid]

area loading and navmesh building should happen seamlessly in the background (maybe even pushed into background threads), not interrupting the game play. This annoyed in MW, and it annoyed even more in Oblivion and Skyrim where you had to stare at loading screens and wait.

This is already how things work. Once you've loaded into the world, unless you've meddled with your preloading settings, don't have enough cores to load things in the background, are travelling incredibly quickly, or are playing the game from a network share in another country, you should never see a loading screen in OpenMW. Again, are you sure you've not been using the original engine instead of OpenMW?

I can add to this that it's done in the background already but there is a logic to wait for some navmesh to be generated around the player. Main reason for this is to avoid pathfinding issues because of absent navmesh. There is a setting to adjust this. Set to 0 to avoid waiting. Generated navmesh is cached in memory so during single game session you should face the problem only when visiting a new location or when cache limit is reached and some tiles are evicted. Also I can recommend to change how many threads are generating navmesh. Upcoming 0.48 version adds navmesh disk cache that should almost eliminate the problem.

[oldChimer]

Thanks for the quick answer, but there's also a lot to be replied, so let me start with this:
I use the same MW installation both directly in Wine and via OpenMW, but in Wine I do only use an MCP-patched Morrowind.exe, neither MGE nor MWSE since they run buggily under Wine. The things I stated are happening in OpenMW only and are deviating from the behaviour I'd expect.

OpenMW has the same bug as MW (which is corrected by the MCP, from which you copied two bug fixes afaik): rain and snow shouldn't fall through solids.

As this isn't vanilla behaviour and is something Bethesda didn't bother implementing rather than something they implemented that doesn't work, we'd consider this a feature we want to add rather than a bug we've yet to fix. Either way, it's tracked here: https://gitlab.com/OpenMW/openmw/-/issues/5492

I hope this gets fixed anyways.

openmw's NIF and texture handling is a bit erratic: openmw does seem to be incapable of handling UTF-8 file/directory names and fqfns (like an assignment of „textures/test/körper-muskulös.dds”) contained in NIFs, and double slashes (which are auto-corrected by original MW) like in „textures/foo//bar/honk.dds” are not handled. Both result in the good old „pink error” (things appear in shaded pink instead of textured, like in MW with wrong textures or nonexistant file paths). In today's times, this is a no-go and has to be corrected.

We handle Unicode paths up to the VFS root (i.e. you can use Unicode in the data= lines in your openmw.cfg), but for compatibility with the original engine, paths within the VFS aren't Unicode aware. Off the top of my head, I think it either uses the current C locale, cp1252, or the content file encoding set in the settings. If you feed the original engine paths with Unicode in, it won't interpret them as Unicode.

Doubled up slashes definitely work. There are loads of them in the vanilla data files.

I think there's likely some misunderstanding of what the original engine does here causing the problems you're seeing, as we'd have far more people than just you reporting problems with this kind of thing.

So why does original MW handle all those issues internally, even UTF-8 names inside a NIF's texture assignments, and ignoring the difference between upcased and lowercase file paths and names, and OpenMW doesn't? I use exactly the same set of mods, active and passive ones, and the same load order in MW (both natively on Windows and in Wine) and in OpenMW. Looks like an OpenMW bug to me.

btw: you state in the reference docs that normalmaps have to be DX format, not OpenGL, which makes a lot of Morrowind mods unusable until all normals are converted. This, also, is a no-go and merely a programmer's preference or bias which must not be enforced on modders and users.

All Morrowind mods with normal maps are specifically targeting OpenMW. The original engine doesn't support for normal maps and MCP and MGE XE don't hack it in, either. There are some existing mods which use D3D8 fixed-function bump maps, which aren't the same thing, and were supported by the original engine (although they didn't look right until MCP fixed them). We support that kind of texture.

As for later Bethesda games, they all use the DX format for normal maps as they all run on DirectX, so we're using the same layout as they do for ease of transition for mod authors.

Not quite right, there are many indirect hacks using normal maps, even MCP has two or three switches concerning that. As for later Bethesda games, you're implying that OpenMW is not meant as „openMorrowind” but a general Bethesda-on-modern-OSes engine, and copying flaws of Oblivion and Skyrim and doing new visual tricks rather than bringing out a „perfected Morrowind” with full compatibility is a priority?

about half of the mods I use — many of them quite old, but running flawless in MW, do not work under openmw or they would if their scripts were ever handled/started. Examples are Wrye World/Wrye Travel etc., the Mog race mod, White Wolf of LoKKen, Children of Morrowind, MCA, and NoM.

There's nothing open on our tracker for any of these, so if they're vaguely common mods, it's likely they're working for most people, or we'd have had issue reports before. I'm pretty sure I've seen some of them in people's load orders, and we've got closed issues for resolved problems with som of them, so it's most likely that they're installed incorrectly. Hopefully, someone will come along and help you out with them, but you'll likely get faster support via our Discord/Matrix/IRC as much more people look at those than the forums these days. If there's anything we can't sort out, we'll put it on the tracker.

Already triple-checked that, none of them are installed incorrectly. The only way this assumption can be true is that OpenMW requires different load order priority than Morrowind, since (as I stated above) they run flawlessly in the same mod configuration in MW. You should have a list of known problems with mods and the load-order requirements for them in the wiki if that really is an issue.

I encountered a strange bug: I installed OpenMW and tried it with the German GotY version of Morrowind, then replaced the German version with the English one to have one language in the game and all mods. When I started a new character, some of the audio dialogue was, irritatingly, German and not English. Second issue: in the German version, I had used TR 21, in the English one TR 19. When I visited a place called Id Vano, which existed in TR 19, distant land showed it, but when I came closer, it disappeared and was gone when I was there (Id Vano was removed in TR 20). Does OpenMW (or the libraries it uses) use some sort of cache, and if so, how do I delete it? Things like this should not happen, especially not when OpenMW is supposed to be able to handle several different installations with different sets of mods.

We don't cache any of this - basically the only thing we do cache at the moment is the navmesh, which definitely wouldn't cause these symptoms even if our invalidation system was horribly broken. The sound issue is likely because you're using a mixture of the two setups (e.g. they're in the same directory by mistake or you've got both sets of files enabled in your config files at once). I know exactly how to reproduce the disappearing Id Vano with MGE XE, so is there any chance you're accidentally using the original engine instead of OpenMW?

No, you missed the point: I didn't switch from TR19 to 21, I switched from 21 to 19 where Id Vano still existed, so it should have been there while LOD would have made me believe it isn't there. That's what would happen in MGE.
No, this happens in OpenMW, I don't use MGE with Morrowind because I had such (and worse) issues with it and got bored of re-creating DL files every instant some exterior changed. I don't have both configs active; I deleted the German version from the file system, and it still(!) happened. That's why I thought of OpenMW caching it somewhere.

once again: do not enforce modders to write compatible alternate versions which can be run by OpenMW. OpenMW ought to be fully compatible to MW, enhancing and improving on it. Hence, OpenMW must be able to run all Morrowind mods, and, sooner or later, all(!) MWSE scripts.

We intend to support all mods that work with the unmodified vanilla engine, and are very close to doing so. There are technical reasons why MWSE compatibility would be prohibitively difficult, though - it'd literally be several times easier for the OpenMW team to recreate every MWSE mod ourselves than it would to support them directly. We've had discussions with the MWSE team about possibly writing a common API that allows future mods to support both OpenMW and MWSE while not being limited to MWScript, but no meaningful progress has been made on that front yet.

Wouldn't it be sufficient to take the modder's manual of MWSE and implement functions which „look MWSE” to the script and do the same thing the OpenMW way? That'd be the way I'd do it, regardless of whether the MWSE team would be willing to cooperate in a shared API.

area loading and navmesh building should happen seamlessly in the background (maybe even pushed into background threads), not interrupting the game play. This annoyed in MW, and it annoyed even more in Oblivion and Skyrim where you had to stare at loading screens and wait.

This is already how things work. Once you've loaded into the world, unless you've meddled with your preloading settings, don't have enough cores to load things in the background, are travelling incredibly quickly, or are playing the game from a network share in another country, you should never see a loading screen in OpenMW. Again, are you sure you've not been using the original engine instead of OpenMW?

Sorry, you didn't read correctly — I wrote „in Oblivion and Skyrim you had to look at loading screens and wait”, which is a comparison, not something I attribute to OpenMW. I would have explicitly written „the loading screens in OpenMW are annoying” if there were any. It is a simple reference to the annoyance in many games where gameplay and immersion are interrupted by load screens or load times.
To answer the question: I'm playing from a local non-removable, non-network FS on my machine. And I'm having „loading area” and brief lags and stuttering far more often in OpenMW than in Morrowind. That's a fact.

please incorporate MW-style camera and vanity camera handling, toggle-able between MW and OpenMW style in the configurator for the benefit of the player.

Unless you're using a newer build than you've said you are and have a camera mod enabled (I'm not even sure any exist yet) the vanity camera behaves identically to the original engine. What do you think is different? Are you sure you're not just remembering what the original looked like incorrectly?

Now you're confusing vanilla Morrowind camera handling with some other game, Oblivion perhaps. Letting go of the vanity key doesnt' change your direction of movement in vanilla MW to where the camera is facing, the camera stays locked and you can watch yourself walking forward from the angle where you let go of the vanitycam key. This is not the behaviour of OpenMW, where the direction instantly changes to where you are pointing the camera when you let go of the vanity key. In Morrowind, you have to tap the vanity key again to return to normal first or third person control, in OpenMW you're back in normal mode as soon as you release the key.
Afterthought: does the „passive preview” setting in the launcher do something more than using the vanity cam when standing still?

please, and this is the most urgent request, before turning to graphical goodies like new shading and ground cover stuff, focus on a full and 100% compatible implementation of the morrowind scripting engine, including the safe „backdoors” which many mods use.

The people who are good at graphics aren't the same people as understand the MWScript implementation, so it doesn't take away from one when the other gets worked on. Also, as a volunteer project, people are free to work on what they want to work on. If we stop accepting graphical improvements, our graphics programmers will find another project's graphics to improve rather than suddenly become keen on working on scripting.

Nobody said „stop working on graphics”, But gfx is only a small part of a project like OpenMW, don't you agree? The first and foremost goal should be 100% compatibility to the original — in every aspect.

Either way, we've only got twelve open issues for our MWScript implementation, and they're very minor things very few mods rely on. Any issues you're experiencing are likely on your end, so we should be able to walk you through sorting them out.

Of course they're on my end, since they're happening to me . But: Morrowind can run everything flawlessly, so I don't see why OpenMW cannot. If I cannot use the same set of mods the same way in OpenMW, OpenMW misses the point, not me.

in the scripting engine, maybe a compatibility layer for MWSE scripting would up-value OpenMW even more, making it a real competitor to the combo MW/MGE/MWSE. Otherwise, many good mods will be left out completely and OpenMW will turn into a proprietary „Half Morrowind, half something else”.

There are already a lot of people who don't see MW/MGE XE/MWSE as a competitor to OpenMW anymore. Ultimately, trying to play catchup with whatever already exists leaves us lagging behind forever, whereas aiming to surpass it means we can surpass it.

The problem is that „lagging behind” what MW with MCP/MGE/MWSE offer makes OpenMW second or lesser choice to any serious MW player who has played vanilla MW with and without MCP/MGE/MWSE and knows the difference between a full-blown Morrowind and OpenMW. Another fact
is that OpenMW is considerered superior only by people who buy Morrowind to use it in OpenMW and have often never played the original version with all benefits added. For example, OpenMW's lack of most MCP patches, like one-key instant casting even with a weapon drawn, makes me want to stay with a patched Morrowind for the time being, until OpenMW offers the same. Same goes for MWSE compatibility; in MW, I only need to start MW after MWSE if I want to use an MWSE-dependant mod, in OpenMW I cannot use MWSE dependant mods at all.

[elsid]

Sorry, you didn't read correctly — I wrote „in Oblivion and Skyrim you had to look at loading screens and wait”, which is a comparison, not something I attribute to OpenMW. I would have explicitly written „the loading screens in OpenMW are annoying” if there were any. It is a simple reference to the annoyance in many games where gameplay and immersion are interrupted by load screens or load times.
To answer the question: I'm playing from a local non-removable, non-network FS on my machine. And I'm having „loading area” and brief lags and stuttering far more often in OpenMW than in Morrowind. That's a fact.

That's a fact on your PC with your setup. Please share your openmw.cfg, settings.cfg, your hardware specs and OS so we can start to investigate the problem. You can go ahead and file the issue on gitlab. As already stated we're volunteers, we don't have resources, big variety of hardware and mod setups to test the engine. If your specific setup causes a problem, it's a good chance for us to investigate and fix it.

[AbuMorrow]

Those mods should be working, if they don't; be specific what you think isn't working and report it as an issue to the tracker:
https://modding-openmw.com/mods/morrowind-comes-alive/
https://www.moddb.com/mods/necessities-of-morrowind
https://www.nexusmods.com/morrowind/mod ... escription

If a mod has a bug or two while ran under OpenMW; doesn't mean it's not supported, almost all of MWscript mods are supported under OpenMW, the specific scripting bugs we know are already on the issue tracker, the ones we don't know obviously aren't, so if you know a specific script isn't working; then report it.
The badly scripted mods and bugs which don't work under Morrowind.exe are expected to not work under OpenMW too btw, but the mods themselves can be fixed by the users or the authors so they can work.

[AbuMorrow]

This should be working too, but if something specifically doesn't then report on the issue tracker too:
https://wryemusings.com/Wrye%20World.html

Is this one of the mods you're talking about?
https://www.nexusmods.com/morrowind/mods/42930/

Does it not look identical to Morrowind.exe?

Keep in mind OpenMW does have skinning issues which are planned to be fixed, but we don't know all the mods that are affected.

[AbuMorrow]

Keep in mind all the Morrowind bump map mods should work under OpenMW, you need to enable this setting:
https://openmw.readthedocs.io/en/latest ... nment-maps

There are no normal maps mods that work under Morrowind.exe, if you think there are any, be specific which ones? Any normal or bump maps mods should be working anyway, but if they don't then help by reporting them on the issue tracker:
https://gitlab.com/OpenMW/openmw/issues

Anyway none of the bump maps mods are using OpenGL format, Morrowind.exe uses DirectX for rendering so expecting them to be using the OpenGL format makes zero sense.

[AbuMorrow]

Now you're confusing vanilla Morrowind camera handling with some other game, Oblivion perhaps. Letting go of the vanity key doesnt' change your direction of movement in vanilla MW to where the camera is facing, the camera stays locked and you can watch yourself walking forward from the angle where you let go of the vanitycam key. This is not the behaviour of OpenMW, where the direction instantly changes to where you are pointing the camera when you let go of the vanity key. In Morrowind, you have to tap the vanity key again to return to normal first or third person control, in OpenMW you're back in normal mode as soon as you release the key.

We have a user reporting the camera behavior you're expecting is a feature added by MCP and it's not a vanilla behavior.

Keep in mind all of the OpenMW camera features that aren't vanilla are optional:
https://openmw.readthedocs.io/en/latest ... amera.html

[AbuMorrow]

Wouldn't it be sufficient to take the modder's manual of MWSE and implement functions which „look MWSE” to the script and do the same thing the OpenMW way?

MWSE is a hack to bring Lua and extended scripting for Morrowind.exe and requires MGE XE and is specific to Morrowind.exe and MGE XE details and internals. OpenMW is a completely a different entity to Morrowind.exe and MGE XE, if what you're thinking was possible (actually meants "simple" but I have a habit of typing "possible" instead which is confusing) someone would have implemented it by now but it's not.

OpenMW is working on its own Lua implementation which is already in the development builds, once enough functions are implemented it will be possible to have the same/most MWSE mods ported to OpenMW, we already have some mods like Dragon door ported to OpenMW for an example.
And we have Lua camera mods that aren't possible/not supported by MWSE too.