I’m 26 years old and I live in California where I work as a Software Developer. I love the icy cold, and my dream vacation is Solstheim. If I could meet anyone from the Elder Scrolls universe it would be Todd Howard. Everyone always asks about the name, and I love telling the story and disappointing them. I needed a handle for some account that I can’t remember many years back. That was the phrase that came to mind, and so goes my origin story.
It started sometime around 2019 when a friend introduced me to the OpenMW engine. Prior to that, Morrowind was a distant thought in my mind. I was amazed that not one person, but a team, had designed an engine to run the game of my childhood. I started a playthrough and discovered the world of modding. Rather quickly I realized I enjoyed the modding bit more than the playing bit.
It wasn’t until around 2021 when the thought of contributing to the codebase came to my mind. In my playthroughs I had noticed some terrible light popping in Balmora, so I decided to investigate. One thing led to another, and before you know it I had opened up a merge request on the project’s GitLab page.
Not really, due to limitations in MWScript and the engine I was never able to create any of the mods I really wanted to. The ones I published were pretty random and I don’t maintain them much at all. Now that the Lua API is maturing and new rendering features added, these limitations are slowly being lifted. My most ambitious project is writing a Lua driven UI/HUD (named Crystal UI). In 2090 I expect to finally release it, unless someone beats me to the chase. These projects are not my priority nowadays. When I do work on OpenMW, I try and improve the engine itself in some way.
Hard to say. I can tell you the most exciting result was seeing the effect of the reverse-z depth buffer. It transformed the world of Vvardenfell as I explored it. Before this change, there was incredible precision loss as you look at things farther away. Lava fields would clip through to the mountains, ground level was filled with this awful zig-zag looking artifacts. What’s worse is that the artifacts are view dependent, so they flicker as you move your camera. Now, viewing the sea, mountains, and lava fields in the distance is a pleasurable experience.
My work with the post-processing framework was the most rewarding as I saw graphics artists come and create spectacular shaders shortly after the feature landed.
It’s a relatively modern technique for all things lighting. With the current engine, every object in the game gets assigned a list of lights. Due to hardware limitations and performance bottlenecks, this list is kept quite low. Even later titles like Skyrim enforced such limits, leading to the infamous light pop-in. In fact, most engines using forward renderers have this limit in some form. In most basic terms, clustered lighting takes a new approach by assigning lights to fixed sections of the camera view, instead of assigning them to individual objects in the world. Furthermore, it allows us to easily offload large amounts of work to the GPU. In the end, you’re left with the ability to view a virtually unlimited number of lights in the scene. Being able to look at thousands of fully dynamic point lights without the aid of baked lighting is truly a breakthrough. AAA titles such as Doom 2016 used this rendering technique.
While I share progress with the community, it is in the experimental phase only. Hopefully one day I’ll get the time and motivation to make it merge ready. This technique paves way for efficient volumetric lighting, point light shadows, and light culling. It’s far from the end of the road!
Aside from the above, I’ve been slowly working on exposing a scene graph API in Lua. This would allow you to toggle switch nodes on NIFs and render custom built scenes into textures, which can be used in the UI for things such as item previews and character dolls. It’s a powerful feature so I hope to wrap that up by the end of the year, I’m a slow worker.
I promise we do only good. The super secret plans can be found on the projects GitLab issue tracker and forums. Instead of enumerating all the plans for the future, it’s better to answer this in a different way: OpenMW Lua is a new feature, and it’s missing a lot! Slowly but surely the team is hard at work filling in the gaps and making it into a mature framework which modders can depend on. A couple recent additions were the ability to create UI elements and play sounds. The work continues, we need to be able to do more! Everything from weather, sounds, input handling, combat, AI, etc…, need to be added as a new interface to the Lua framework. As always, we’re looking for new contributors on this front.
I’d love to see advanced techniques such as path tracing and global illumination, but a better time for this would be when OpenMW is able to switch rendering backends to something like Vulkan. That isn’t to say there is not a ton of room for improvement in other areas. I’ll talk about these in the other questions. Don’t let that deter you though, if someone is motivated enough we might get these features in our current renderer, I’d be happy to help this land.
I have about 30 local branches where I have a half-baked approach to everything I’ve ever wanted to see implemented. The hardest part is sticking to one and finishing it. If I had to choose, point light shadows are at the top of my list. That will wait until we finally have the clustered renderer we mentioned earlier. Currently, a point light solution would be anti-climactic as it would likely be limited to hand-held light sources like torches due to performance concerns and needing to drastically limit the number of shadow casting lights. I also want to see a parameterized sky which we have accessible through a Lua weather controller, to drive diverse weather and custom particle VFX.
Ask anyone and you’ll get a different answer for this. Version numbers hold little meaning to me and serve as marketing gimmicks mostly, everyone uses different metrics to measure the success and maturity of projects. The general consensus, however, is that 1.0 is about feature parity with `Morrowind.exe`, within reason. Past that I would say 2.0 would need a Vulkan renderer that is supported on all major platforms, and multiplayer support.
I see through your trickery. OpenMW is the only project I work on!
OpenMW is looking for contributors, especially graphics programmers! It’s a small army of dedicated individuals over here and we love to see new faces. For me, I’d love to see someone come in and implement height fog and atmospheric scattering. OpenMW still uses the most basic form of depth based fogging which emulates the ancient fixed function fog formula. The development team, including me, are always around to help out newcomers, so if you’re interested feel free to start a discussion on GitLab or Discord. We’re all happy to answer the million and one questions you will most certainly have. Thanks to everyone in the community who helps drive this amazing project!
2024-01-26 - jvoisin - No pingbacks so far.I have two cats, a mother and a daughter tuxedo pair. My name isn’t actually Zack, but I live in South Dakota in the USA. I’m 29 years old, and work as a technician at a Managed Service Provider, basically an IT company. When I’m not working on OpenMW or my real job, I spend time attending and staffing Anime Conventions. I grew up playing Morrowind, and the following games in the series, but none lived up to the original TES3!
I discovered the project a long long time ago, I was a member of the Google Groups email list, around August 2009. I’ve used it for playing Morrowind for a long time, I can’t remember when I switched. No later than 2015, since I started making mods for OpenMW primarily around that time. I actually first submitted a merge request in late 2021, but didn’t see it through to the end. I had become busy with other things in life, and came back when the API was far more progressed. It was merged, but ptmikheev was responsible for the finishing touches.
I submitted code again after I read up on C++ a bit more. I had never written C++ seriously before contributing to OpenMW. I wanted to create mods for OpenMW Lua, that required features that weren’t added yet, so I decided to stop waiting around and just add them.
Yes, absolutely! As far as I’m concerned, it plays Morrowind flawlessly. I’m excited to see feature parity with MWSE, add in TES3MP into the master branch, and add more support for playing (or rendering) later games from the series.
MWSE is pretty cool, and very powerful. I’ve developed several of my mods to use it. My most recent larger project, Clone, included a library that allowed you to use Lua code for both engines. I’m not sure that is feasible long term. It’s difficult to write mods for both engines, since both have their strengths and weaknesses.
My biggest issue using MWSE is my platform of choice, OpenMW works on Mac and Linux, whereas MWSE of course, doesn’t without major workarounds. I do have a virtual machine set up for it, but just am much more comfy with OpenMW Lua anyways.
There is a good amount I’d like to bring over. The ability to create records is pretty important, especially NPC records. Mostly stuff that I need anyways, but MWSE mods show what can be done once the OpenMW Lua API is even more mature.
However, certainly much of MWSE is beyond my ability at the moment to add to OpenMW. The advanced C++ programmers like urm and wazabear will most likely be doing the rendering/scene graph API.
I’m not sure if I’m leading anything, but I love helping the OpenMW Lua community grow. I try to help anyone in the OpenMW discord who is learning Lua, and all my mods are free for the picking to steal code from. You can get them from my GitLab, or my Nexus Mods
I recently got into Mac and iOS app development, using Apple’s Swift programming language. I’m creating a standalone launcher for OpenMW on Mac, that will be able to work as more of a mod manager like Mod Organizer 2, as opposed to OpenMW’s launcher.
I’ve got a few concepts for my existing mods, and a few new mod ideas. Notably, I’m hoping to get started on an update to my MUNDIS mod that would allow you to travel between save games, and even between OpenMW and MWSE, bringing your character, with their stats and items to the new “timeline”, similar to the real TARDIS.
I really want to build an RTS mode, using Morrowind actors as units, and being able to build structures as in the Command and Conquer games. I’ve already implemented a lot of this in my Ashlander Architect mod, we just need to make some improvements in the AI, and implement the user interface.
I really hope for the ability to create new world spaces, similar to the later games. This will be great for adding new lands in mods. We’ll need to add support for mapping in these spaces.
It’s very promising. It may not be fully ready to use until 2090™, but given the relatively short amount of time it took to support Morrowind, I think we can make good progress. I’ve only done one small contribution to help this, but hope to help more soon. Lua might come in handy to implement the mechanics.
Adding access to more record stores is very important. This will be needed for things like dehardcoding user interfaces. Dialogue records are one of the most important features not yet added to the Lua API. I’ve got a few contributions I need to finish before I want to start on this, however.
I want to be able to create new cells, with whatever parameters needed. This would be very handy for Ashlander Architect.
Game weather is not accessible to Lua yet. There has been discussion on this, and I think it is something I will tackle in a few months, if not already done by then.
I’m very happy that OpenMW has added Lua scripting. I used to be very frustrated with MWScript, Morrowind’s original scripting language, and created huge scripts that covered every use case I could think of. I wanted to add black soul gems to Morrowind, but doing it with MWScript caused so many problems, as documented in this forum thread After support was added to OpenMW Lua for souls in items (by me, but with help from the rest of the team), it was possible to do this cleanly in OpenMW Lua instead of scripting, or by editing the source of the engine.
I am a student programmer from Oklahoma. I actually got into programming seriously because of my interest in OpenMW many years ago. I have two kids and in my free time like to play pool and hack Xboxes. But mostly, I like to spend my free time when I’m not with my kids writing code, specifically for OpenMW or some other Morrowind-related project. You will often find me on Discord helping people with, or researching my own, weird Morrowind problems.
I’m not actually sure offhand when I got into OpenMW. Probably around 2013-14, seemingly after the project moved to C++ and I got my first PC, I started my first playthrough. I vaguely remember stumbling into the project when I was trying to figure out issues with my save games in the original engine. I remember at the time, there was no MWSE, and many original bugs in the engine still existed. My saves kept getting corrupted when I saved outdoors, unless I looked at my feet, and I got so frustrated with it I never looked back once my game became stable.
I did not learn C++ specifically because of OpenMW. Actually, I had never touched C++ prior to having forked the TES3MP project and getting together a small group of people to work on it. However, my longtime interest in doing so drove me to attend college for low-level programming so that I could focus eventually on helping to develop the multiplayer components of OpenMW.
I think so. I remember back when I first started playing OpenMW, at a time when most basic mods still didn’t work, the plan was always to make the engine useful not only for other Bethesda games, but for other game developers. OpenMW itself is just now in the phase where this is starting to become more and more of a reality by the day, and I personally know many developers who are engaged in original projects specifically geared toward OpenMW.
I think on some level it is probably because no other developers is currently working on the construction set. I have seen people even ask, “Why does OpenCS exist to begin with?” My personal experience has been that I started modding long enough ago that the Bethesda form of the construction set scared me off, and I see a lot of potential in the design of OpenMW-CS. I always intended to do something with it, but eventually it broke one of my mods, I started hacking at it, and I developed a vision for what it could look like in the future when building my own games with it.
In some ways, the construction set is uncharted territory both because users aren’t really fans of it, and because the developers who were seriously involved with it are no longer active on the project. For those reasons, I see it as a mostly blank canvas to build something great on top of something that is actually fairly solid at its core, if painful to use at times. This gives so much opportunities for improvement, both because there are few if any people and mods to upset when things change, and also because almost anything could be better than what is available now in *some* respects. However, its foundation, I think, will easily allow OpenMW to support later games through its construction set once some issues with its renderer have been worked out.
Most recently, I have been working to add proper selection outlines to the construction set. Presently when you select an object, its wireframe is drawn to show that you’ve selected it. It makes the resulting scene extremely busy when you’ve gotten even a handful objects, like a table and everything on it. The OpenMW team has helped me to resolve this and to implement what I think should be the basis of a simple shader framework within the construction set.
Once this is done, we can move on to replacing the dynamically generated selection arrows with real selection widgets graciously provided by the MWSE team, and implement many more interactivity shortcuts within OpenMW-CS.
Nag me in the right direction and I will bash at this thing until it does its job. I really like it and it should be much better than it is. My own projects completely depend on it, so my mods cannot work without it being functional, especially since they’re mostly geared toward multiplayer :)
There are many related ideas I’ve come up with both from trying to use it myself and just hearing CSSE authors/experienced modders complain about it, so there’s definitely plenty to do.
I think there are many things in OpenMW whose full potential are yet to be unlocked. Features like groundcover and Lua records are only half-implemented, and one of my goals is to fully integrate these features within the OpenMW-CS so that the power they *already have* can be fully leveraged by the construction set. I hope that some of my recent developments which have been greatly assisted by the OpenMW team will open the door for a post-processing framework within the CS as well. All of that is to say nothing of support for the ESM format from later games, which actually is made very possible by the OpenMW-CS’ architecture, if tedious.
The next, and probably biggest, thing I would like to implement for 0.49 is full support for LUAL records in OpenMW-CS. I spent a lot of time decoding what they look like under the hood and learned how integrate omwscripts files into the omwaddon format. Not only will this provide modders with the ability to simply not have two plugins with some Lua mods, it will also expand the capabilities of the Lua API for most users, so that it can do what it’s already capable of with less effort on the part of the scripter.
Today, when a scripter makes an OpenMW-Lua mod, they must create a .omwscripts file along with it. The entire purpose of this little text file is to say “This script hooks up to this type of thing”, e.g, you may want a script to run specifically on the player, on NPCS, on Doors, and so on. What happens is that this text you type in, is transformed into information that is identical to what is in an .omwaddon, or even, an .esp. The engine interprets them identically – a properly formatted omwaddon or esp file, is no different than a .omwscripts file.
However, there are features buried behind doing this in an .omwaddon, which are not offered by omwscripts. Namely, with LUAL, one can attach a script to a specific object, or instance of an object, as opposed to an entire category of objects. For example, instead of attaching your script to ALL NPCs, you could hook your script up to, say, just one specific guard in Balmora, or the door that leads into Caius Cosades’ house, instead of every single door in the entire game.
I think that the subject of MWSE in OpenMW was examined a very long time ago and fell apart. It was questionably feasible even at that time. However, I do have faith that the community can find common ground across the implementations of some techniques eventually. Even if there *are* two separate engines, there’s only so many ways you can put together an MCM, after all.
I would like to say that my own developments and many of those of the OpenMW community would categorically not be possible without the awesome contributions of the MWSE team. They have helped me personally along with most of the OpenMW contributors, and carried this community for a very long time. They’re great folks.
If there were only one thing in the world I could change about OpenMW, it would have native multiplayer support. I originally got into working on the engine because of my interest in multiplayer, and I must say there’s no experience quite like it. I strongly encourage any Morrowind fan to give TES3MP a shot, whether with a friend or on a public server. I’ve had a TES3MP server in some form or fashion for about five and a half years now, and there is absolutely nothing like it in the gaming world.
I enjoy multiplayer Morrowind because it allows you to build environments that are the scale of an industrial MMO with relatively little effort, while still being high quality if your scripts worked in the first place. No other framework gives authors the capability of building multiplayer worlds with the same level of ease (and cost) as TES3MP. If nothing else it deserves honorable mention for multiplayer devs in the FOSS space.
This is my main goal and reason for becoming active in the community. The TES3MP team and I have made some strides in this regard, and many steps back, but ultimately I do hope to help make this possible. I would love at some point to be able to offer something useful to OpenMW in this regard, and have spent probably half of 2023 researching how this could be made real, including some work with the author of TES3MP.
However, OpenMW itself “thinks” very differently than TES3MP does, so it’s my opinion that the ultimate version of OpenMW’s multiplayer implementation will be very different to what is available now. Whatever OpenMW’s multiplayer implementation eventually looks like, my friends and I will have a lot to say about it along the way and do everything we can to make sure it’s the best it can be. Most of that work is very likely to be done in tandem with the original author of TES3MP, David Cernat, whom I’ve very much enjoyed working with in the limited time I’ve interacted with him.
Not really. But I am a big fan of the project and have been for a long time. I hope to see tooling and support for the engine grow over time as more independent developers get hold of it and its toolkit is made more usable.
2024-01-05 - jvoisin - No pingbacks so far.The OpenMW team is proud to announce the release of version 0.48.0 of our open-source game engine! Grab it from our Downloads Page for all supported operating systems and Dwemer devices; enjoy Morrowind’s 20 anniversary in style.
So what does another fruitful year of diligent work bring us this time? The two biggest improvements in this new version of OpenMW are the long-awaited post-processing shader framework and an early version of a brand-new Lua scripting API! Both of these features greatly expand what the engine can deliver in terms of visual fidelity and game logic.
As usual, we’ve also solved numerous problems major and minor, particularly pertaining to the newly overhauled magic system and character animations.
Unfortunately, this time you will not be able to watch a release video by his majesty Atahualpa and his excellency johnnyhostile since they are both heavily occupied by real-life matters. – But fear not! This release announcement post will cover the gist of what this new release brings in text form, so prepare for the read of your lifetime!
As covered in our feature highlight blog post from last May, 0.48.0 introduces support for post-processing shaders. With wazabear’s sweat, blood, and titanic effort, the new release takes a leap forward in eye candy and can now support advanced visual effects like bloom, godrays, ambient occlusion, and many more. Shader maestros from our community have been playing with the framework for a while, so while OpenMW’s built-in assortment of shaders might seem somewhat conservative, with a little digging around the community repositories you’ll be able to transform the way your game looks.
Pressing F2 will open the in-game post-processing HUD where you can toggle any installed pretty effects on or off, or tweak their settings. To learn more about this new shader system, please take a deep dive into the extensive documentation wazabear has written.
As we speak of graphic improvements coming in the new release, you might think post-processing would overshadow everything else – but that’s not true at all! The Lord of Lights and others also managed to get rid of two major long-standing issues with distant object rendering.
Every 3D game uses a so-called depth buffer during rendering. As objects are drawn, the depth of every sample of every object is written into that depth buffer. This way objects closer to the camera can properly cover objects farther away from the camera. That’s all fine and dandy, however, the traditional implementation of a depth buffer distributes the possible depth values very poorly. With floating point numbers from 0 to 1 being used, the scale is very imbalanced towards the buffer’s near end, or the value of 0, while numbers closer to 1, that is, the viewing distance limit, are much more sparse. The visual consequences are violent flickering, and Z-fighting of distant objects, terrain, and water when the depth buffer just couldn’t keep up with the detail. This problem was even more apparent with low values of near clipping distance OpenMW requires for compatibility with Morrowind rendering.
And, well, 0.48.0 remedies this. The reverse-Z depth buffer wazabear added heavily improves depth buffer precision at large distances without sacrificing the precision of the rendering of closer objects. This effectively eliminates the pesky flickering with no perceivable performance impact. Nice!
Now, there are still caveats when you take this seemingly magical pill. While it doesn’t require bleeding edge hardware, some platform and video driver combinations might have trouble supporting this feature. If you encounter any problems, please report them to our issue tracker, IRC, or Discord.
As for the second woe, if you ever tried a province mod from Project Tamriel, you might have noticed the unpleasant vibration of objects and characters. While this is an inevitable consequence of how computers work when floating point numbers are rounded, OpenMW now uses double precision floating point numbers for physics interpolation and object transformation matrices. This should reduce the severity of flickering by around 4 billion times at a somewhat minor performance cost and greatly extend the vibration-free playable area for any province mods released up to the year 2090.
There’s actually another unscheduled extra batch of Halloween eye candy distant objects receive: 0.48.0 brings a couple of optional visual tweaks to help improve fog rendering. You can now let fogged objects blend nicely with the sky on the horizon and toggle an alternative exponential formula for the distribution of the fog. See for yourself!
Anything else when it comes to visuals? Indeed there is. Rain ripples have been added a few releases ago, but their artificial appearance might have seemed underwhelming. Thanks to wareya, this release contains a much needed visual overhaul for these ripples – though not yet the generic water ripples, sorry! In the in-game settings, you may choose between multiple levels of detail for rain ripples depending on how well your system handles them.
wazabear just couldn’t stop on what has already been mentioned: he implemented a new rendering technique, so-called soft rendering, which smoothens the rendering of object intersections. This is particularly interesting for particles, which often clip through other objects. Enabling soft rendering for all particle systems is an option you can enable, and model artists can also enable soft rendering for other geometry using NiStringExtraData (see our documentation).
Finally, 0.48.0 contains some fixes for particle and shader lighting, making some magic effect VFX less dull and preventing snow blindness on Solstheim.
Not yet straying too far from visuals, are we? Animations are also a major part of any game’s visual experience, and 0.48.0 brings a few corrections to the painfully produced implementation of Morrowind’s state machine. Most of them are the work of Capo and lay the groundwork for further improvements coming in 0.49.0.
Some of the most notable changes are those to blocking and spellcasting behaviour. Blocking no longer prevents movement and while there are still differences that a subsequent release will take care of, this makes the use of shields significantly more comfortable.
Spellcasting animation is now played even when the character has no Magicka to cast the spell. Curiously, Morrowind doesn’t play it when you fail to cast an already used power. You might remember that there was an option to play it when an enchanted item is used – well, in another curious case, Morrowind actually has an “animation” playing when you use an enchanted item in first person view! It is just a split-second change of the hands’ position to the direction you look at… Well, OpenMW now does that “animation” too.
Something that might or might not seem like a controversial decision, we discovered that Morrowind assets define some unused animations for equipping and unequipping spells for non-bipedal creatures. Sometimes they seem clearly unfinished, but sometimes they’re actually really interesting. We decided that benefits outweigh the negatives and enabled their use. When you play Morrowind, various spellcasting creatures like the Atronachs, Dwarven Spectres and Dagoth Ur himself will use these animations. Come to them through fire and war, see them for yourself and decide what you think!
While we’re going through the visuals, we can’t forget about NetImmerse and Gamebryo’s NIF format, which is still the main format for use with OpenMW. We’ve added the support for a few records and features Morrowind modders discovered relatively recently and found useful, to keep up with the active modding scene.
Two new record types Morrowind NIF format contains have been implemented in this release: NiSortAdjustNode and NiFltAnimationNode. NiSortAdjustNode is a kind of node that lets its children, either all of them or the transparent ones, be drawn in an artist-defined order, which is useful to work around transparency sorting issues. NiFltAnimationNode is a special kind of a switch node that switches between its children automatically based on a timer, which can be useful to create complex animations.
While OpenMW had NiStencilProperty implemented for a while for its primary purpose of enabling double-sided rendering, clever stencil buffer manipulations it allows in NetImmerse never worked quite right in OpenMW. Stencil buffer is another data buffer like the depth buffer, and manipulating the stencil test and stencil buffer write allows artists to make the engine draw different geometry depending on the way the player looks at the object, make objects that look like indents in walls which will be rendered “over” the walls and so on. Thanks to wazabear, this functionality is now supported.
Another record that up to now wasn’t fully implemented is NiPlanarCollider, a particle collider. OpenMW will now respect the dimensions of the collision plane it defines.
The final NIF addition of note is the support of geometry-based particle emitters. When a geometry node is used as an emitter and a special flag is set in NiBSPArrayController, it will emit particles as if the geometry’s surface was the particles’ origin. This also allows producing very interesting VFX.
That should be it regarding the visuals. We were giving spellcasting animations a look, so now we’ll look into the magic system itself. Basically, Evil Eye fixed everything. No, seriously. All of it just works.
…
Well, actually not all of it, but it’s really close now! Evil Eye overhauled the entire spell and magic effect processing system to be much more flexible and easy to work with, fixing plenty of old flaws in the process.
We’ll start with birthsigns, of course. One of the most popular birthsigns for a Morrowind player to pick is the Lady, which gives the Nerevarine a hefty bonus to Personality and Endurance. Personality affects how much the people you meet like you, while Endurance is supposed to influence the health bonus you get every time you level up. Except it didn’t in OpenMW. You see, previously abilities would act as magical fortifications for your stats instead of affecting the base stats like they would in Morrowind. And since health gain per level is based on the base Endurance, the Lady-induced Endurance fortification could only grant the character a bit of extra Fatigue. This has been corrected. Of course, this also means that you can’t get your Personality to 125 thanks to the Lady anymore… unless if you were to convert Lady’s Favor into a Curse. Curses are a different type of a permanent spell and will magically fortify your stats like before.
When it comes to magic effects, we’ve finally made Morrowind playable in OpenMW by making the expiry of the secret EXTRA SPELL magic effect, which is intended to undress its target, make the target re-equip their equipment instead of staying naked forever. As for spell effects of lesser importance, there’s a few to cover.
First, the visual effects for Calm, Frenzy, and Rally Creature/Humanoid won’t play on actors of the wrong type. The same is true for Turn Undead. Additionally, the effects intended for creatures now apply to all creatures, even undead and daedric ones.
Thanks to the research received from Hrnchamd, the author of the Morrowind Code Patch, the position and scaling of magic VFX playing on actors has been made much more accurate to Morrowind, and in fact, better in a way: we did not replicate Morrowind’s bug where, to calculate the scale, it deems some creatures two times smaller than they should be.
Reflect now mirrors Spell Absorption in that it is multiplicative. This means that each Reflect effect source produces a distinct success roll. Reflect can now also reflect non-harmful effects, doesn’t reflect scripted spells, and properly stacks with Spell Absorption effects depending on casting order.
Some not that invisible Invisibility quirks had to be taken care of too. You will stop being invisible when you actually release an attack, not when you initiate one, and NPCs will no longer seem to be able to observe you while you’re invisible – that is, they won’t greet you or look at you.
Paralysis is obviously supposed to prevent you from picking up things. And it did – but not when you picked up things with your mouse. This has been fixed. This also concerns the state of knockout and death, if you could somehow manage to open the inventory while, well, dead.
Restore effects will now properly restore stats Drain effects damaged and when you hit a target with an enchanted projectile, the projectile’s on-self enchantments will affect the target instead of the caster.
You might know about the quirk Morrowind has where the character’s Weight affects the horizontal velocity of that character. Well, Weight is also apparently supposed to affect the velocity of any magic projectiles the character casts for some reason. Starting with 0.48.0, this behaviour is replicated if the “normalise race speed” setting is disabled.
Aside from fixing magic, there were some other fixes to game mechanics of note, particularly AI. The player’s allies won’t react to the player’s crimes anymore, weapon-wielding creatures can now open doors again (does this remind you of anything?) and all creatures can equip portable light sources during the night. Equipped light sources also won’t be extinguished underwater if they’re not actively being held.
Alright, audio. Sounds are prone to get cut off in Morrowind. OpenMW 0.48.0 improves upon this so when you get too far from a sound that is still audible, the sound will quickly fade out instead of immediately going silent. This added transition makes the audible experience of flying away from the very loud Ghostfence noticeably less jarring.
In addition, to improve consistency with Morrowind, we had to allow sounds to continue playing even when their sources are gone from the worldspace they started playing in. This is done by using the sources’ new position in any worldspace they’re currently in as the sound source in the current worldspace. An interior cell is considered a distinct worldspace, sounds still won’t play if they’re too far from you, and these still playing sounds will also stop playing when you leave the current cell.
Then there’s physics, of course. For all its primitiveness in the original 2002 engine, there are many gotchas to consider. For example, in Morrowind – for whatever reason – scripted object spawning doesn’t automatically make the object physically there until its state is updated through other means or tricks, so you can walk right through it. Of course some mods and the Bloodmoon expansion of all things rely on this behaviour, so we had to replicate it.
But there’s also something we overlooked ourselves: the momentum you carry was not reset upon teleporting and entering a new location. Wearing the Boots of Blinding Speed and jumping into a canton’s doors doesn’t allow you to smash into the other side of the canton at Mach 1 anymore.
There’s this commonly known issue in Morrowind where actors standing on tall platforms don’t tend to stay put and may end up on the ground way below. It’s an animation issue, but apparently OpenMW had a completely unrelated issue with very similar symptoms: when cells were loaded, it would snap actors down before loading all the objects in the cell, sometimes causing them to be snapped down right to the terrain level, which it was especially prone to in the rare case the object the NPC is standing on is actually from a different cell. This should no longer be a problem.
There was also a case where OpenMW wouldn’t have snapped down actors when it should have done so. When actors, including the player, are teleported, they are typically snapped down to the ground level, as spawn points tend to be notoriously inaccurate. However, flying and swimming actors were exempt from this. It was discovered that this is incorrect, so we fixed this – teleporting to inactive cells will snap down these actors as well. One problematic situation was the player’s teleportation from Magas Volar back to Tel Fyr while levitating.
The UI has also received some improvements. It’s the little things. The effect list of spells and enchanted items is now aligned left, like in Morrowind, and, if you enable the option, you can zoom the world map using the mouse’s scroll wheel.
But there are also big things. The layout and skin files our MyGUI-based interface uses are now a part of the virtual file system, which means that files from other data directories can override them. This also concerns fonts: while Morrowind’s bitmap fonts were always a part of the game’s assets, TrueType fonts OpenMW supports could not be. In fact, standard distributions of OpenMW now include TrueType fonts to be used by default. These TrueType fonts are based on the open source fonts Ayembedt and Pelagiad. While your game can of course rely on the bitmap font setup imported from Morrowind.ini instead, there is a good reason to offer these fonts as an alternative, which is as follows…
OpenMW-specific UI additions that aren’t already covered by your content files’ game setting records can now be localised! With the newly introduced YAML-based localisation support, the in-game UI was painstakingly translated to the languages our contributors speak, including Russian, German, French and Swedish. To use the translated lines, you need to change the locale using the in-game settings. Localisation files are also a part of the VFS, to be used in… ahem, let’s not jump too far ahead. Now, where were we… Ah. The TrueType fonts are offered because the original bitmap fonts may not include the glyphs necessary to display the text: for example, the fonts from the original American English release of Morrowind do not include Russian Cyrillic characters. If you’re interested in learning how the localisation works in-depth, give the documentation a look.
If you’re a modding enthusiast, one addition you should love is the introduction of data directory and BSA archive configuration directly in the launcher. You will not need to manually edit openmw.cfg anymore to register archives or work with the data directory order.
That aside, the paths to configuration files OpenMW uses can now be redefined, meaning your OpenMW installation can become somewhat portable, though you can’t quite use multiple distinct OpenMW installations on the same device yet.
Font size and TTF resolution can now be set from the launcher for quickly setting up the crispiest font imaginable for your desired screen resolution.
We know people like things to be fast. Navigation meshes were added in 0.46.0, and for all the AI improvement they bring, generating them takes quite some time on some setups. In 0.48.0, generated navigation meshes are cached to the disk, improving loading times in locations that have already been visited in a previous session. You can also generate navmeshes for your load order using the launcher, so that going through every single location in the game to do the same isn’t necessary.
Of course, this release contains a great multitude of stability fixes that are too technical to explain in this overview. Them aside, there are also many, many mod compatibility improvements, and while we’re not going to cover all of them in this overview, you might still want to know that the following Morrowind mods, to our knowledge, should work in OpenMW slightly or much better than before.
…and potentially many others.
Great House Dagoth, The Underground and Welcome to the Arena mods have also received significant improvements, and Morrowland some improvements, but they still can’t quite be called supported yet.
There’s work on that front as well. cc9cii, a person with the nickname that might ring a Sixth House bell, did some magic, so OpenMW-CS, our editor, should load content files much, much faster now. unelsson has also made some changes here and there, greatly improving terrain editing performance and addressing a few problems.
It can also properly handle Persistent and Blocked record flags now. A newcomer, VidiAquam, has added an instance editing grid and the ability to snap instances to that grid in the various edit modes. This should make creating content much easier in OpenMW-CS.
Alright, alright, now that we’re done with all the interesting stuff, we can move on to the known issues and extended changelog and- what? There’s something else? Oh, right, there is…
Yes, OpenMW has its very own Lua scripting API now, dubbed OpenMW-Lua! The Great De-hardcoding is starting ahead of schedule, and Petr Mikheev and Anton Uramer are its pioneers.
Before covering what it currently offers, we’ll have to start with an honest disclaimer: you will not be able to run MWSE-Lua mods in this release. MWSE-Lua often acts as a light wrapper over the very guts of Morrowind’s executable. Unfortunately, while OpenMW might appear very similar to Morrowind on the surface, it does not resemble Morrowind internally, and trying to replicate every single little detail of Morrowind’s data structures, architecture and the way everything is tied together for the purpose would be counterproductive and frankly, take forever.
However, OpenMW-Lua is built with the prospect of supporting multiplayer and reaching parity with MWSE in mind, so we can only hope modders will be open to the idea of porting their mods to an OpenMW-compatible API at some point in the future.
But anyway, what does 0.48.0 Lua offer? Well, it’s not much, but it’s honest work! This early revision of the API gives scripts control over the camera as well as the means to create new GUI widgets, work with post-processing shaders, and some limited access to the game world. Of course, future releases will expand on this greatly as more parts of the engine are dehardcoded.
Mods that rely on OpenMW-Lua will need to include .omwscripts extension files, which are effectively text files that list the scripts and state what they’re going to run on. Aside from these files, mods must of course contain the scripts themselves. They can also include localization files – the same ones that are used for the UI strings and can be accessed through the API. Of course, there’s a settings API mods can work with to permanently store settings to be used across multiple game sessions.
For more information about the features of OpenMW-Lua and how to work with it, please consult the extensive documentation.
We should give some practical examples of the functionality the API can already offer. All the camera settings introduced in 0.47.0 are now configurable through the in-game settings menu. Some new mods that make use of 0.48.0 superpowers have also already been released:
So that’s it for Lua in this release, with many more API improvements still to come in future releases. This is also the conclusion of 0.48.0 feature overview. Thank you for having interest in OpenMW and reading all of this, and consider also reading the full list of changes below!
Known Issues:
New Engine Features:
New Editor Features:
Engine Bug Fixes:
Editor Bug Fixes:
Miscellaneous:
Finally, after much hard work to get all the cool new features ready for release, we have our first round of Release Candidates, or “RC” for short. RCs are simply release binaries for testing, to make sure everything is in order for a release. That’s right, testing! So we would be very grateful if you would download an RC for your OS of choice, test it a bit to see if it works without any issues and report any findings you make to our GitLab issue tracker. Please make sure to check first that whatever you find is not on the tracker already and that you’re running the latest RC.
If you just want to use OpenMW without hassle rather than test things, you’re probably better off waiting for the actual release or grabbing 0.47 from our downloads page.
Thank you and we’ll see you again on the day of the release!
To join in on the forum discussion, head over to our OpenMW 0.48 Topic