Perfect is the enemy of good. - Voltaire
We should nail down a feature's core as soon as possible without sacrificing OpenMW's stability. OpenMW must not crash. We can throw an error, let a user know what is going on, but we must not allow OpenMW to CTD with no reason. In this way we can gain features going forward and leave further polishing, extension and optimisation for later. It doesn't have to be perfect, it just has to work reasonably well. We can then move foreword at a steady rate without sacrificing stability and leaving the door open for other developers to build upon the work. Effort should be made for maintainability first and following, wear possible, the general architecture guidelines.
We should also be more willing to be accepting of drive-by commits and features. Some people just have an itch they want to scratch and never come back. This should not be a motivation to deny/reject something. Instead we should engage the developer and again, work them to get a good core and encourage further additional MRs they can work on. Not everyone has years of experience and OpenMW shouldn't take an elitist approach to code contribution. OpenMW is built upon the fact that people come and go, so we shouldn't fear that there won't be enough manpower to sustain the project. No one is an expert in all parts of OpenMW and the project has existed in such states, such as areas of code that hasn't been touched in years. We should encourage people to become experts in the areas they are working on and help train up people who wish to help.
When it comes to testing a feature, sometimes we just have to make the call to bring in a feature into master and then let those who use nightlies use our issue tracker for what it is meant for. We should also add an additional label "nightly" to also indicate that the issue is within our main development branch and not a bug from a stable release. It also indicates that it doesn't need a changelog entry. This also implies that our nightly users are our testers. By encouraging this behaviour, we'll track down issues faster and polish new features off faster than had we them just sitting around and rot. It also means that we can roll out releases faster.
Code Quality:
A topic that pops up from time to time. As subjective as this can some times be, we should try to make it easy by providing a clang-format file for editors that allow for consistency for developers. We can encourage its use by newbies but we should reject contributions purely because of style. Most people come to the project wanting to be apart of it and are willing to change things if guided nicely. We can revisit our code-style guidelines in the wiki and update them to. That being said, we shouldn't be afraid to take a PR/MR over and do additional follow-up work to polish it off if the original creator is incapable of it. We should also keep them attributed by keeping their initial commits.
Transparency:
I feel like we need to get away from discussions behind a closed door, discussions about OpenMW should be done in the public eye. OpenMW is not a closed cabel. Technical discussions should happen in the public forum or #development.
Mediation and interpersonal relationships withing OpenMW:
It's also come to my attention that there are those people who don't get along in the project. I believe that everyone means well here, this is a passion project after all and people can have some rather strong opinions. That even the "we will just have to agree to disagree" doesn't just stop the conversation, it just pauses things until the next disagreement comes up. I would like to believe that we are all pulling on the same rope here but perhaps there are other motivations at hand here. I'm interested in hearing from you how we could resolve this? It is something I will think further about but I encourage everyone working on OpenMW to either talk to me in private or just talk about the issues that are bothering them in the forum here for the team to discuss.
Eventual 1.0 release and OpenMW-CS version:
Currently both OpenMW and Editor are 'tied' together. Original plan was that we delay 1.0 in order to have the editor catch up; that isn't going to be the case. So for now, this is alright, when we get to 1.0 then we need a separate way to track versions. Suggestions:
* bump OpenMW major number to 1, leave minor number to 50 (for example): version 1.50 as a result with OpenMW-CS as 0.50
* have different versions for major 'apps': thus OpenMW becomes 1.0 and OpenMW-CS either stays at 0.50 or gets reset to 0.1 (considering the state of the editor).
Road to 1.0 (the blockers):
* 1.0 issues: https://gitlab.com/OpenMW/openmw/-/issu ... name[]=1.0
* MCP: https://wiki.openmw.org/index.php?title=MCP
So while MGE:XE, MCP and MWSE are 3rd party libraries that extend Morrowind.exe; OpenMW can at least provide parity with them to the extent that we can say that they are unnecessary as OpenMW already has or extends the features they provide. I think we should evaluate what is to be considered a blocker for 1.0 and which is for post 1.0
For consideration as 1.0 or even 1.1:
* MGEXE: https://wiki.openmw.org/index.php?title=MGE_XE
* MWSE-mwscript: https://wiki.openmw.org/index.php?title=MWSE
^-- This is open for debate as to what we want to do. I get the feeling that modders have abandoned this anyway. So it's just a wasted effort and we should avoid 'extending' mwscript and let it just die.
Not for consideration for 1.0 but very well can come later:
* MWSE-lua compatiblity is not a requirement for 1.0
The problem here is that this is a moving target and I don't believe OpenMW should be the one to 'track' this. It is entirely possible here that if MWSE-lua implements new features that they should also commit supporting code in OpenMW for that feature. Should they need a specific feature that isn't provided in the API, they can create a ticket to discuss with OpenMW to see what the best way forward is then they can submit a MR for the feature. This should further integrate MWSE-lua devs into OpenMW development there by creating and strengthening the bond between the two projects.
Bounties:
There have been bounties set on features by people outside the project, OpenMW has no problem with this and if anyone feels insentivised to claim a bounty they are free to do so here: https://www.bountysource.com/trackers/1 ... nmw-openmw
We will mark issues on our tracker as those with bounties available and we encourage people who would also like to support the project monetarily, they are still free to support the core developers (FAQ entry) and of course post bounties on issues that are important to them. Keep in mind that code acceptance into the repo is a requirement for the bounty and that we will treat the MR or PR with the same vigour and quality as any other. Bounties should also only but put on issues on our tracker, OpenMW reserves the right to deny inclusion of code that is of bad quality or with no related issue in our tracker.
Roadmap:
The goal here is to 'guide' development, but again no one is forcing anyone to work on things they don't want to. If someone has an itch, like working purely on making on Morrowind support, they are free to do so. Our job, as the core OpenMW developers is to guide them.
Short Term:
0.47 targets:
* Working through existing 1.0 related issues
* Polishing up Object Paging and Active Grid
* Landing double precision bullet support
* Landing movement solver
* Landing threaded physics
* Further work bettering NIF support
0.48:
* Collada support either native or via osgAnimation (perhaps worked on in 0.47 but won't be ready until 0.48)
* Basic Lua subsystem (perhaps worked on in 0.47, but won't' be ready until 0.48)
* Working through existing 1.0 related issues
Medium Term:
* Rally around remaining 1.0 issues; anything that blocks. It is to be assumed that more and more issues will come up and we'll have to triage them as we go as blockers or not.
* Improved lighting system (made more noticeable by active grid)
* Version 1 Definition of our Lua API, we should keep standard high here in terms of documentation
Code: Select all
* Single player game running seamlessly in Client/Server model
* Version 1 Transpiler to take mwscript and generate lua-based equivalent
* Support for Oblivion ESM
* Active Paging on by default when Object Paging is turned on
Long Term:
* Support for Skyrim and FO3 NIF
* Support for Skyrim and FO3 ESM
* Support for Havok data found in NIF
* Support for Facegen
* Support for Speedtree