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!
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.