OpenMW 0.48.0

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
psi29a
Posts: 5354
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

OpenMW 0.48.0

Post by psi29a »

Placeholder while we polish up 0.47...

Main work already in the pipeline for 0.48 are: Also, before we can release 0.48 we need to be very clear about our intent for: Lua Documentation /API and OpenMW-CS ESM compatibility (and non compatibility)

So after experiencing how things went with OP/AG with 0.47 which allowed other things to come in: groundcover, a2c, lighting... ; perhaps we can try to keep this release smaller, tighter and polished for a faster development and release cycle. I wanted 0.47 but again we fell into a yearly release tying up loose ends.

We also have a queue of other things waiting to be reviewed, rebased and merged here:
https://gitlab.com/OpenMW/openmw/-/merg ... penmw-0.48

Update: VR is being pushed back to 0.49
User avatar
Greendogo
Posts: 1467
Joined: 26 Aug 2011, 02:04

Re: OpenMW 0.48.0

Post by Greendogo »

To speed up releases, once the first of the major intended features is finished, that could signal a wrap up and an initialization of 0.49. just a thought, to keep things simple. Lots of smaller stuff will surely come along for the ride.
User avatar
psi29a
Posts: 5354
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.48.0

Post by psi29a »

That was the intention for 0.47; but there was a lag with the amount of work that needed to be done to get OP in shape, especially when the original author went missing.

The hope is that the people behind these major features stay around. :)
User avatar
Greendogo
Posts: 1467
Joined: 26 Aug 2011, 02:04

Re: OpenMW 0.48.0

Post by Greendogo »

Yes, it's much easier to update and maintain an already working feature than it is to make someone else's half finished feature work correctly for the first time.

Example: I have been observing the GamePad GUI pass hands recently and I'm nervous as to how that's going to land. :?
User avatar
Capostrophic
Posts: 794
Joined: 22 Feb 2016, 20:32

Re: OpenMW 0.48.0

Post by Capostrophic »

So I plan to add a bunch of NIF things (gasp) before too long:

1) Sort out TCB and Bezier interpolation woes
2) Use tangents/bitangents from the NIF file so that the normal maps for Oblivion and later games just work
3) Add a NiFogProperty placeholder to slightly improve the compatibility with models that use it to disable fogging
4) Maybe get in the rest of NIF branch (so basically include Skyrim texturing and physics definitions to make much more models load, but the physics won't work right).
User avatar
psi29a
Posts: 5354
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.48.0

Post by psi29a »

Considering how 0.47 has now officially taken longer than 0.46 in terms of getting released, when the goal was to reduce the time to release, perhaps it's time review what happened and what to do next. I think this had mostly to due with the late-term addition of features that would resolve the primary pain points of our new distant static system (Object Paging). So we could have either launched 0.47 without these fixes; and moved on to 0.48 or waited. I made the decision that we would wait so that lighting would be fixed when "Active Grid" is enabled... fixing a long standing lighting problem in OpenMW as a whole. I think it was worth it, but this is a special case and we're in a much better position now to just say "no" to feature creep.

We also have a much better CI and release building infrastructure and have many more testers involved that are still helping in the 0.47 RC phase.

We have pulled the trigger on further development and have now merged the initial Lua framework for 0.48; at this moment we're waiting on the final bits to fall into place for reverse-z for our graphics pipeline. In the mean time we've had lots of bug-fixes and long-standing issues being closed by our growing development team (both new and re-joining members). We are in a really good position here to say that after 0.47 is officially released, that we can start the 0.48 RC process which means:
* smaller release
* less work for our PR team
* hopefully smaller RC process due to smaller amount of changes

Which translates to faster release cadence. This is especially important now that we're asking for feedback from the community about our Lua API. A smaller, yet quicker release cadence is probably a good thing moving forward so that Lua modders won't be left in the cold by either targeting a 'stable' but old release or a 'bleeding edge' nightly/daily that could have their API changed out from under them. So let's meet in the middle.

We still have a bit of time to wrap things up, but if the VR side of things aren't ready by the time reverse-z is finished; I think we can pull the trigger and keep VR for 0.49;
User avatar
lysol
Posts: 1513
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: OpenMW 0.48.0

Post by lysol »

psi29a wrote: 25 Jul 2021, 21:06 We are in a really good position here to say that after 0.47 is officially released, that we can start the 0.48 RC process ...
[...]
This is especially important now that we're asking for feedback from the community about our Lua API. A smaller, yet quicker release cadence is probably a good thing moving forward so that Lua modders won't be left in the cold by either targeting a 'stable' but old release or a 'bleeding edge' nightly/daily that could have their API changed out from under them. So let's meet in the middle.
This sounds great to me.

Regarding VR, we could basically do the same again when VR arrives if it does not arrive in time for the RC-phase of 0.48. Just start the RC phase for 0.49 as soon as VR is merged and make it yet another small release with one very major new feature.
User avatar
AnyOldName3
Posts: 2660
Joined: 26 Nov 2015, 03:25

Re: OpenMW 0.48.0

Post by AnyOldName3 »

Object paging was big, so obviously took it a while to finish regression hunting, but with smaller features like the alpha testing rework and async physics we were still fixing issues in the RC stage. If releases get too close together we'll miss regressions, so will need more time feature-frozen to keep attention on the RCs, and then risk killing developer interest if we spend too much time in feature freezes. We need to be careful with this. I'm pretty confident we can get to two releases a year without problems, but think three will be risky, and four's right out.
User avatar
psi29a
Posts: 5354
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.48.0

Post by psi29a »

AnyOldName3 wrote: 27 Jul 2021, 00:23 ... but think three will be risky, and four's right out.
Was that a cleverly disguised holy hand-grenade reference? :lol:

There was a time when we had 3 or 4 a year with a much smaller development team (before scrawl), obviously with a lot less 'features' than now.

Anyway, let's shoot for 2 and see how that goes. Baby steps. :)
User avatar
AnyOldName3
Posts: 2660
Joined: 26 Nov 2015, 03:25

Re: OpenMW 0.48.0

Post by AnyOldName3 »

Early on, the features were simpler and interacted with fewer other features, so they had less chance of landing broken, and had less chance of breaking other things. They wouldn't have needed as long to mature.
Post Reply