Post 1.0 Plans

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
Post Reply
User avatar
Starsheep
Posts: 54
Joined: 06 Jun 2018, 16:09

Re: Post 1.0 Plans

Post by Starsheep » 11 Jul 2018, 07:47

AnyOldName3 wrote:
10 Jul 2018, 23:18
This is a decision which will determine if OpenMW remains a way to play Morrowind, or becomes the basis for new pet-project games, other open GameBryo/Creation Engine reimplementations and real games plenty of people will spend actual money on. I don't think we should be thinking in terms of the next one or two years of implementation and maintenance work, but five to ten.
Reading these columns since a few weeks now, I can't help but wonder as well how you guys picture openmw in one, five or ten years. The following considerations might seem to stray a bit from the conversation but I'm hoping that bringing a broader, out of the box view might help focusing on more immediate choices, like which scripting system do you want to implement.

It took a decade to achieve an -almost- feature complete multiplatform foss implementation of a game that's been released 16 years ago. However excellent this game is (was), your audience here is a niche. It's actually a niche of a niche, targeted at nerds (in the good sense) who want to play the game in a stable way on multiple systems, plus a couple devs happy to delve and learn, for the sake of it of for adding competences to their resume.

But what's next? I felt the intention to extend the engine flexibility to produce a fully open source engine for... original creations? But what's going to be your audience? We're in 2018. There are big boys out there and you're going to compete with monsters like Unreal or Unity.

Without entering the whole debate of foss vs closed source, I'll just take the example of Gimp and Photoshop. I'm a photographer/retoucher by trade: I produce content, use available tools for it, make sales.
Photoshop is light years ahead of its counterpart on the quality and productivity levels, despite the fact it really lacks competition and Adobe is laying a bit back on its commercial success tbh. It's not free, I pay a monthly free for it, but it's largely compensated by the output result, the time I save and the extra satisfaction and amount of clients I'm able to serve.
The image manipulation audience is waaay wider than the gaming community on a single title from 16 years ago. Despite this, Gimp is still lagging a lot behind. What's the perspective for OpenMW development in a tiny niche? As we saw recently, with Scrawl's gone, it's like half of the manpower away, at least on the graphic side of things.

In the mind of a producer, making content for a decent game requires tens of thousands of man-hours. Anyone planning to venture on such an endeavour needs to sustain himself, pay his rent or his mortgage, buy his groceries and raise his kids, while hopefully making a dime on top of it. If so much time is invested, it needs to be compensated somehow and it needs an audience hence sales hence money. And money (aka target population) is and will always be the core of any kind of motion for interesting productions. What's the chance for a guy or a team to make a big hit out of a small budget and an engine that replicates graphics and mechanics originating from 2002, with 98% of the player base running Windows? Damn slim. The best bet is to go for a modern commercial solution, make more sales out of it and soften the cost of proprietary software.

But...

On the other hand, BGS announced a month ago that TESVI was in pre-production. And that's a godsend.

A lot of the fan base is going to get a nostalgia trip on the last three episodes of the franchise, waiting for the next big thing to happen. There's time ahead, a big minimum of two/three years. Among this player base, there are definitely a handful of capable developers waiting to be recruited.
In that perspective, OpenMW could mutate into OpenOblivion, then OpenSkyrim, with David's TES4MP and TES5MP along, and the glory of being able to play these titles in a stable way, with 4k textures with no mipmaps for pubes and scripts running like a crossroad in India without fearing a tragic random logless CTD. You'd be surfing on the massive amount of mods already hosted on the Nexus, without even talking about the modding tools like MO2, xEDIT etc.. Millions of man hours devoted to creating content for these games, already made, already documented, most of it stable and finished.

See what's graphic modders have been doing so far: as an example, Boris from enbseries spends more time figuring out how the shaders have been implemented in the binaries than actually coding his own functions. Imagine the results of his work if he had an open framework to make his algorithms shine the way they should. Oblivion was the worst, requiring a dozen dll (w)hacked inside to make it -somewhat- stable.

Embrace that. Make it easier for content that has already been produced, documented, and for which communities are still active. This is your audience, your talent pool, your way to get people onboard and make things move forward.

If you're still wondering where you should go with the future scripting system, here is your clue.

Make it work with what's existing already. Make it happen and reinforce the fact that the TES series is unique in its longevity thanks to its modding capabilities and that 7, 12 and 16 years later, people are still wandering the provinces of Tamriel. Keep walking this path, get Wrye, Boris, Fore, ElPresidente and many more onboard and maybe in ten years from now, one of you could land a job somewhere in Maryland, and perhaps convince Howard to release the sources of their next engine, or at least expose much more of its innards to the community. What a game-breaking change (no pun intended) that would be for the whole industry.

On a final note, I want to emphasise the fact I'm not undermining everything that's been done here in any way. OpenMW is a jewel of its kind. I've been amazed how you guys have been able to get it that far on just your free time and DAMN it's stable and well designed. Congratulations for that. If you've been able to pull it off until now, there aren't any reasons not to keep going.

User avatar
psi29a
Posts: 4363
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Post 1.0 Plans

Post by psi29a » 11 Jul 2018, 09:15

Starsheep wrote:
11 Jul 2018, 07:47
On a final note, I want to emphasise the fact I'm not undermining everything that's been done here in any way. OpenMW is a jewel of its kind. I've been amazed how you guys have been able to get it that far on just your free time and DAMN it's stable and well designed. Congratulations for that. If you've been able to pull it off until now, there aren't any reasons not to keep going.
Thank you Starsheep, I really like your post and I don't think anyone here would accuse you of undermining anything.

Keep in mind, in the beginning, OpenMW was just the name on the face of OpenEngine, an ambitious project that was not just focused on Morrowind. This isn't re-writting history, take a look at the git history yourself. It wasn't until Scrawl, Zini and others around 2011 made the decision to refactor the code-base (again) to reduce OpenEngine to just OpenMW (removing another layer of abstraction) and focus exclusively on Morrowind that OpenMW became _the_ OpenMorrowind project thanks to this we focused on one game, re-affirmed our FAQ and end-game goals to be _the_ Morrowind engine drop-in replacement.

We are still on this trajectory.

We have not lost sight of the original goal, OpenMW however wants to eventually be more than just a Morrowind engine drop-in replacement. By OpenMW, I mean those contributing... so please, if you have contributed, step up here, this is your moment because you are the ones taking it in the direction you want. There seems to be confusion about who 'leads' OpenMW, there is no cabal. Contributors _drive_ OpenMW so when someone says OpenMW and/or Team, it's in reference to all current contributors. People who have contributed the longest are usually the ones reviewing and accepting merge/pull requests. Zini just happens to be the longest contributing member, so many things get deferred to him but that doesn't mean he can't be convinced. Case and point: oldscript+ vs newscript; that was driven by OpenMW contributors pushing for it.

cc9cii for example has been working behind the scenes to add support for oblivion, skyrim, fallout additions to NIF. This is _his_ thing and it enriches the possibilities for OpenMW and for modders, not take anything away from Morrowind.

If contributors want to spend their time improving OpenMW in this manner, great! OpenMW has gotten here through the efforts of people contributing to a FOSS project for many different reasons.

If you wish to effect change in OpenMW, contribute. Yes, there is push-back, ask anyone... the push-back is mostly to improve the PR/MR, driving up quality, before being merged in. There have been contributors that have one-off contributions and were rejected on the grounds that OpenMW wasn't yet ready (post 1.0).

MWSE math functions, I would have loved to see this included, but it still has a PR that we can re-open if anyone wants to champion it for inclusion. https://github.com/OpenMW/openmw/pull/75 This was closed because, as far as we are aware, there no mwse mods that use only these functions so OpenMW wouldn't benefit anyone having just these. In addition to this, we'll be providing these functions anyway via newscript so the way forward would be mwse compatibility through newscript.

It is nice to have a plan for 5~10 years down the line, it gives people that want to contribute a sort of guideline of things that can be worked on. This doesn't _exclude_ things that can be potentially worked on however. If people want to push for MWSE compatibility, they are free to contribute to that end goal.

The willingness to help and contribute has to come from Wrye, Boris, Fore, LePresidente and others. If you and others would like to contact them, feel free. :)

User avatar
AnyOldName3
Posts: 1191
Joined: 26 Nov 2015, 03:25

Re: Post 1.0 Plans

Post by AnyOldName3 » 11 Jul 2018, 12:16

Just a few things regarding Mod Organizer:
  • It's LePresidente, not ElPresidente. If anyone's trying to find him, the correct spelling should help.
  • There are other people with power over MO, including Silarn, AL12 (al12rs on the Nexus) etc.
  • I've also worked on Mod Organizer, and did a fairly extensive revamp of its Python plugin system. This also included making this plugin https://www.nexusmods.com/morrowind/mods/45642 which covers the vast majority of MO/OpenMW interop. Anything further requires major work on MO which no one there has time to fix (as there are other features which would take priority).
If we're going to be asking the MO team for input, the best way to contact them is via the MO2 development Discord. However, I'm not sure that there's much we can take from MO as its main feature is its VFS, and ours is already superior.
AnyOldName3, Master of Shadows

User avatar
Starsheep
Posts: 54
Joined: 06 Jun 2018, 16:09

Re: Post 1.0 Plans

Post by Starsheep » 11 Jul 2018, 13:23

AnyOldName3 wrote:
11 Jul 2018, 12:16
However, I'm not sure that there's much we can take from MO as its main feature is its VFS, and ours is already superior.
Well MO's VFS is pretty much the only thing that OpenMW doesn't need. Everything else would benefit OpenMW through the launcher (a bit crazy/overkill), or at least with some degree of integration on MO side in a medium/distant future, likely through a MO game plugin.

Of course I'm shooting for the stars here, knowing that in the meantime, MO is already very usable at the moment to build a heavy loadout, with a bit of a workaround (thank you!) to generate our openmw.cfg.

User avatar
AnyOldName3
Posts: 1191
Joined: 26 Nov 2015, 03:25

Re: Post 1.0 Plans

Post by AnyOldName3 » 11 Jul 2018, 13:49

I wrote the majority of an OpenMW game plugin when I was creating the interface for Python-based game plugins, and determined that an awful lot of stuff that should be left up to the game plugins (such as whether the game uses ESP files or something else instead) in MO is actually hardcoded. I did some investigation, and determined that it would be a big job to sort it out. It's probably way less work than, for example, my shadows PR, but it would still need someone to do it, and I don't have infinite time to fix all the problems with the open-source software I use.
AnyOldName3, Master of Shadows

User avatar
psi29a
Posts: 4363
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Post 1.0 Plans

Post by psi29a » 11 Jul 2018, 15:58

BTW.... OpenMW-CS with AstroBoy dae/collada model... there are some errors due to animations not yet being translated to OpenMW. ;)

So technically OpenMW now supports dae/collada statics (via OSG). Boom!
Screenshot from 2018-07-11 16-55-51.png
Screenshot from 2018-07-11 17-38-50.png
Could not locate UpdateCallback for <channel> target astroBoy_newSkeleton_spine01/blendParent1
A RigGeometry should not have multi parent ( )
A RigGeometry should not have multi parent ( )
A RigGeometry should not have multi parent ( )
A RigGeometry should not have multi parent ( )

User avatar
Passerine
Posts: 5
Joined: 07 Dec 2015, 15:10

Re: Post 1.0 Plans

Post by Passerine » 19 Jul 2018, 11:16

This is really exciting to see! I've got a few suggestions in mind, which I'm just sorta posting here since I haven't got a GitLab account with which to directly push these suggestions to the document, but in any case that I could see really enhancing OpenMW's flexibility or that I've just got on my personal wishlist:
  • The same way OpenMW is proposed to add a tag system for item records, Fallout 4 adds a tag (keyword/KYWD) system for several record types including item records, actor records, and object mod records. Fallout 4's system then allows the presence of a certain tag (or tags) to be checked against in many of the places where any other object/instance qualities can be checked against. I suggest expanding OpenMW's proposed item tag system to be able to be applied to any object or instance and for those tags to be able to be checked against in scripting or in any other function involving checking against an object/instance's qualities.
  • Fallout 4 adds an Object Mod (OMOD) record type - it's used to handle armour and weapon modifications in the game's crafting system, but also to handle dynamic variations in actor appearances and properties. I could see Morrowind's actor part record type being rolled into a similar system, which would then also serve as a basis for handling any other ingame variations on or modifications to items, actors, etc.
  • From, I believe, Fallout 3 onward, the records for music cues/music categories in Bethesda's engine have a subrecord used to assign each music cue/music category a priority rating; when multiple music cues meet their conditions for being played, the cue with the highest priority is the one that gets played. This is used, e.g., to have combat music cues take precedence over exploration music cues, and to then have boss battle combat music cues take precedence over regular combat music cues. I recommend adding a similar system to the document's proposed music framework.
  • I imagine this wouldn't be a fundamental element of OpenMW's music framework and so wouldn't need to be in the immediate scope for OpenMW's music framework, but I'd like to see the format for music/audio records expanded to allow for more complex handling of music/audio files, ala Wwise (i.e. supporting a "blueprint" system for music/audio definitions allowing for, e.g., a music track comprising different audio files that are played together or in a queue based on specific game conditions). If it is in fact a matter of "this has to be taken into account in stage 1 in order to be properly realised in stage 2," then I would like to see this functionality taken into account.
  • Rather than requiring content directories to be bound to an omwaddon plugin or otherwise binding a user's content directories (and/or the load order thereof, and/or the "enabled"/"disabled" status thereof) to their plugin load order, allow users to have arbitrary content directories for their game and then to be able to arbitrarily reorganize the load order for those content directories. Let me tell you: Having seen the light of Mod Organizer, going back to not being allowed to properly organize my mod list's content directories would be a *nightmare.*

User avatar
Zini
Posts: 5533
Joined: 06 Aug 2011, 15:16

Re: Post 1.0 Plans

Post by Zini » 19 Jul 2018, 16:25

The same way OpenMW is proposed to add a tag system for item records, Fallout 4 adds a tag (keyword/KYWD) system for several record types including item records, actor records, and object mod records. Fallout 4's system then allows the presence of a certain tag (or tags) to be checked against in many of the places where any other object/instance qualities can be checked against. I suggest expanding OpenMW's proposed item tag system to be able to be applied to any object or instance and for those tags to be able to be checked against in scripting or in any other function involving checking against an object/instance's qualities.
Makes more sense to use record variables for that IMO.
Fallout 4 adds an Object Mod (OMOD) record type - it's used to handle armour and weapon modifications in the game's crafting system, but also to handle dynamic variations in actor appearances and properties. I could see Morrowind's actor part record type being rolled into a similar system, which would then also serve as a basis for handling any other ingame variations on or modifications to items, actors, etc.
Sounds more like a stage 2 task.
From, I believe, Fallout 3 onward, the records for music cues/music categories in Bethesda's engine have a subrecord used to assign each music cue/music category a priority rating; when multiple music cues meet their conditions for being played, the cue with the highest priority is the one that gets played. This is used, e.g., to have combat music cues take precedence over exploration music cues, and to then have boss battle combat music cues take precedence over regular combat music cues. I recommend adding a similar system to the document's proposed music framework.
We kinda have such a system in the stage 1 document, but more limited with a range of hard-coded priorities. You bring some good examples. I'll have a look at the document and see if we are covering them adequately or if an expansion of the system is needed.
I imagine this wouldn't be a fundamental element of OpenMW's music framework and so wouldn't need to be in the immediate scope for OpenMW's music framework, but I'd like to see the format for music/audio records expanded to allow for more complex handling of music/audio files, ala Wwise (i.e. supporting a "blueprint" system for music/audio definitions allowing for, e.g., a music track comprising different audio files that are played together or in a queue based on specific game conditions). If it is in fact a matter of "this has to be taken into account in stage 1 in order to be properly realised in stage 2," then I would like to see this functionality taken into account.
Complex. Need to think about that a bit more.
Rather than requiring content directories to be bound to an omwaddon plugin or otherwise binding a user's content directories (and/or the load order thereof, and/or the "enabled"/"disabled" status thereof) to their plugin load order, allow users to have arbitrary content directories for their game and then to be able to arbitrarily reorganize the load order for those content directories. Let me tell you: Having seen the light of Mod Organizer, going back to not being allowed to properly organize my mod list's content directories would be a *nightmare.*
OpenMW needs to know which assets belong to which content file. Therefore content directories must be bound to content files. Otherwise we would have to drop a whole lot of useful features. That shouldn't cause any problems to the end user anyway. Could you give me an example where not having the ability to sort the load order of asset directories independently from content files has caused you problems?

User avatar
AnyOldName3
Posts: 1191
Joined: 26 Nov 2015, 03:25

Re: Post 1.0 Plans

Post by AnyOldName3 » 20 Jul 2018, 01:56

Could you give me an example where not having the ability to sort the load order of asset directories independently from content files has caused you problems?
Depending on how annoying something needs to be before it's a problem, simply having more content files to organise than is strictly necessary could count. At least in pre-2.0 Mod Organizer (the feature may have been lost when the VFS implementation was replaced), it would give warnings when two different mods provided conflicting assets but had ESP files which were ordered differently, but in any other situation, having the order tied together isn't helpful and just confuses things. AL12 is a MO dev who's often pretty good about noticing gotchas in this kind of situation, so asking him for input might be a good idea.

A potential problem with content-file-for-everything is if a retexture mod is to be used with a total conversion mod which uses the original assets, but not the original ESM, it can't have Morrowind.esm as a master or needs to have two versions. If there are multiple games made for OpenMW, having retexture mods tagged with their intended base game is a good idea, but it should be made simple for users to tweak the content file to say that it has a new master instead in cases where compatibility is obvious.

Another thing with the discard-the-current-MO-like-system idea that I can't remember if we've discussed is that right now, OpenMW mods can be put in different places all over a computer, such as on different drives if disk space is a concern or into different folders so they can be kept organised. I can't remember if the document specified whether all omwaddons get dumped into one folder or if I can put them anywhere I want and just add their path to a list somewhere. It's completely possible that this is a thing it said and I did think to check it and then just forgot, but some clarification/a reminder would be helpful.
AnyOldName3, Master of Shadows

User avatar
Passerine
Posts: 5
Joined: 07 Dec 2015, 15:10

Re: Post 1.0 Plans

Post by Passerine » 20 Jul 2018, 04:16

Zini wrote:
19 Jul 2018, 16:25
OpenMW needs to know which assets belong to which content file. Therefore content directories must be bound to content files. Otherwise we would have to drop a whole lot of useful features. That shouldn't cause any problems to the end user anyway. Could you give me an example where not having the ability to sort the load order of asset directories independently from content files has caused you problems?
Well, if you can't arbitrarily sort, reorganize, and enable/disable your content directories without it affecting your plugin load order:

What does the end user do about handling different content directories overwriting the same assets?
Are you supposed to configure your plugin load order based on resolving content directory conflicts rather than on resolving actual plugin conflicts, and then just manually put together a patch plugin to make up for your plugins as a result of that not having their conflicts properly resolved? Or do you make new sets of content directories entirely to pack at the end of your plugin load order, as a kind of content directory equivalent to the way badly conflicting plugins tend to call for specially-made merge patches/compatibility patches being placed at the end of one's load order? Suddenly having to create merge patches/compatibility patches for plugins and for content directories doesn't sound fun. Additionally, being unable to control how content directories override each other is a potentially massive problem for playability when scripts are packed into a content directory rather than into a plugin, as they are in Skyrim/Fallout 4's Papyrus scripting system and as they are in MWSE's Lua scripting system.

What does the end user do about enabling/disabling a content directory mid-playthrough?
For a recent personal anecdote, I've got a New Vegas playthrough going now with the mod New Vegas Redesigned - it's a mod that redesigns the appearances of the characters of the game, and which in order to do so properly needs you to have a particular set of body meshes installed for the characters in your game, but which does not actually say which set of body meshes in particular you need. I took a more-or-less wild guess on which body mesh mods (content directories) I should apply to my game - and then an hour into my save I realized that the characters in my game had broken textures. I tried swapping out one mod for another (disabling the content directory of the first and installing and then enabling the content directory of the second) - still didn't work. Eventually I figured out that New Vegas Redesigned expects you to have a specific custom body mesh for females, but then the base game's body mesh for males, so that's the final setup of my content directories for body meshes that I came to in my game having by that point enabled and then disabled a number of different content directories for different body mesh sets in my game. If all of this were done under a system of content directories having to be bound to one's plugin load order, and to one's save with that, would the registry in my save of my plugin load order now have all these dead records for all the sets of body meshes I've enabled and then disabled as I've played on it?
My New Vegas anecdote may sound like an extreme example but consider that, if you have content directory conflicts (as in my "what does the end user do about handling different content directories overwriting the same assets?" example) that go unnoticed until you've already started your playthrough of whatever you're playing in OpenMW, you'll have to play the same game of creating, enabling, and potentially disabling content directories mid-playthrough in order to properly resolve them.
And then there's the nightmare that would ensue for your save if there were a content directory that you really couldn't enable/disable at all without having to enable/disable an actually gameplay-affecting plugin alongside it...

Post Reply

Who is online

Users browsing this forum: No registered users and 17 guests