OpenMW 0.11.0

A generic talk on the OpenMW project.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1151
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Github profile: https://github.com/lgromanowski
Contact:

OpenMW 0.11.0

Post by lgromanowski » 21 Aug 2011, 22:04

Zini wrote: We are now deep into the 2nd month of 0.11.0 development. Time for a small motivational speech/status report.

The launcher is almost complete and we are making good progress with the editor design.

For OpenMW itself the situation looks rather bleak. The people, who were planning to the the core features of this release, have either disappeared or are too busy with RL. The changes we made to OpenMW are either maintenance or backend-stuff. In other words we have nothing to show yet.

If we must, we can drop all core features for 0.11.0 and move them to 0.12.0 instead (I still expect most of the inactive people to return at some point; hopefully to continue their work). But we still need something for 0.11.0. Making a release with no user-visible changes is pointless.

I would like to draw attention especially to the GUI. Currently GUI is the category with the 2nd largest number of open issues. That is not surprising since MW is pretty GUI-heavy for a (semi-)modern RPG. But the lack of GUI implementation impedes the development of OpenMW in other areas. Also, the GUI is by definition a user-visible feature. If we can get some progress in this area, we will have something to show for 0.11.0.

If we happen to have any inactive/lurking coders, now would be a good time to step forward.
pvdk wrote: Since we're talking GUI here:
I figured out a way to get a semi-official font for the GUI. It turns out the Russian version of the magiccards.fnt has it characters placed in such way that we could use it as a bitmap font for MyGUI. We could use the bitmap from this mod: http://www.tesnexus.com/downloads/file.php?id=36873

Added benefit would be Cyrillic character support.
Is this an idea?
Zini wrote: Wouldn't help much, since it still would offer only English and Russian. Unless it proves to be absolutely impossible, we should still aim for re-using the original MW font with an option to switch to alternative, more modern/standard formats.
pvdk wrote: I talked about this with one of the lead developers of MyGUI and our findings were that it's impossible to support the native Morrowind font. Here's what he said:
From: Altren
To: pvdk
Looks like the only way to make it working properly is to remake texture
I believe the Polish version of the .fnt has the same placement issues as the original. With the Russian version we would however have support for the English, French, German and Italian version, as the glyps for these languages are present in the Russian .fnt (I believe). I would have to take another look to be sure.
Zini wrote: Well, since we don't have anyone on the team who has experience with this technology, we can as well listen to the advice of an external expert.
pvdk wrote: Altren was talking about the .fnt file shipped with the English version of Morrowind, not the one with the correctly placed glyphs (Which I believe could work) But maybe you're right. I did not get a reply from Altren after I gave him the proper texture.

Related question: Why are we using MyGUI? I searched my mail for old mailing-list mails about that but couldn't find anything. What's the benefit of using MyGUI instead of some other GUI system? In other words: what is it that MyGUI does that can't be done with another system?
heilkitty wrote: AFAIR, at some point, MyGUI appeared to be the most suitable OGRE GUI. The exact reasons could be found in the maillist.
Lordrea wrote: I've recovered the only thread from the old (and apparently deleted) Google Groups that seemed related to the decision to pick MyGUI.

It can be found here: <FIXME - OLD LINK> viewtopic.php?f=2&t=460

Honestly between Nico's post and the Comparison of GUIs at the Ogre Wiki I don't see why we're not using CEGUI. It has better features, better documentation (that also happens to be in English of all things!), and a stronger community backing.
Zini wrote: Well, it is too late to change it now. We already have plenty of working MyGUI code. That is unless, there is suddenly a huge influx of CEGUI-capable coders, that can replace the old MyGUI code in a short period of time and then add new stuff quickly enough to compensate for the switching-overhead.
pvdk wrote: Haha CEGUI was exactly what I was thinking of. I know it's too late to change GUI systems but it seems the CEGUI pixmap fonts support kerning, vertical offset etc. that would maybe make it possible for us to use Morrowind's original font format. Too bad :(

Thanks for recovering it Lordrea. It seems Nico's choice for MyGUI was based on something not in the comparison. Maybe because DungeonHack uses it?
Star-Demon wrote: My task is rather minor, but finals re next week, and after that I'll have nothing to do while looking for some summer employment. I'll get on adding those silly Ms added, committed and pushed very soon.

I wanted to do a video announcing the editor plans - I think it's a good time to say something about it.

Russia and Germany are the largest share of viewers I have. (I have 7000+ views between two videos.) A Russian and German translation would be good starts and should satisfy most of the demand.

TBH we should get one more really nice thing out before we talk about just some GUI improvements.
Zini wrote:
I wanted to do a video announcing the editor plans - I think it's a good time to say something about it.
We don't have anything to show yet for the editor (still in early design stage). Maybe it would be a good idea to wait at least until some framework elements are implemented.
TBH we should get one more really nice thing out before we talk about just some GUI improvements.
Well, these GUI improvements will allow us to implement more game features (since except for combat nearly everything in MW works through a GUI). Doing some GUI related tasks will actually give the player something to do besides running around and admiring our rendering engine.

As for one more really nice thing (a assume you mean something rendering-related), yeah, that would be nice. But we don't seem to the manpower currently.
sir_herrbatka wrote: for PR reasons it would be suitable to think about (small) improvements in GUI.
Zini wrote: Doesn't look like my previous posting did anything useful. Looking at the github graph it seems no one but pvdk and me contributed during the last 30 days (with pvdk doing most of the work). Two people are not enough to keep a project of this scale running. We really need more contributors. Anyone? Anything?
Greendogo wrote:
Zini wrote:Doesn't look like my previous posting did anything useful. Looking at the github graph it seems no one but pvdk and me contributed during the last 30 days (with pvdk doing most of the work). Two people are not enough to keep a project of this scale running. We really need more contributors. Anyone? Anything?
You need to maintain a presence on the official beth forums, and maybe even on the ogre3d forums. But the Elderscrolls community has a lot of programmers, like Peachykeen, Yacoby among others, so I would suggest trying to get their attention on the beth forums.
gus wrote: Well, I *should* be able to do some work next month. I if I remember well, i'm not the only one to have exams, so it's probably a temporary slow down.
pvdk wrote: I won't have any exams till the end of july, so I'm available. Won't make a difference for our troublesome 0.11 release though, as the stuff I could work on isn't on the task list.

As a side note I would like to report that the original font works with CEGUI, but auto-converting probably won't work because the y-axis offset read from the .fnt file doesn't translate all too well. I had to adjust it manually for the "w" glyph but not for the other glyphs.
Star-Demon wrote:
Zini wrote:Doesn't look like my previous posting did anything useful.
Please try to be more positive.
Zini wrote:Looking at the github graph it seems no one but pvdk and me contributed during the last 30 days (with pvdk doing most of the work). Two people are not enough to keep a project of this scale running. We really need more contributors. Anyone? Anything?
I don't have anything right now. Last exam is today, and amidst some health problems really demotivating me from getting anything substantial done, I need a job so I can pay the bills. I'd take on more tasks, but I haven't studied the code enough to really take on most of the tasks. Many are dependent on others, and I don't have much time to see what can be done right now without asking you about each one. I am learning the project as it is and learning the skills necessary to code at higher levels. That's my progress.

I will level with you - if you want more coders, here are my suggestions:

1. Be more positive.

2. The bethsoft and OGRE3D forums are a good idea. However, if we really want people to give their time out of their life for this, we have to have the spirit of the reorganization of the project and set things up where anyone can jump in. Right now - getting into this project requires a lot of assumed technical skills, many of which aren't programming. Development on windows needs to be simplified and guides to setting up and participating need to be written. I'd volunteer to do it, but I've reached my limits of knowledge on that. I really can't write it because I'm one of the people still having technical problems. My current task could be done in one sitting using rename using refactor - if things were set up right.

There are lots of people out there with all the programming skills and knowledge we need, but not the technical ones. If I went around school asking, I promise you I could find you at least 5 highly motivated people with all the programming skill and knowledge to do this - but I could promise you they would have a hard time make it past setting up. It's like we're throwing them away.

As Chris mentioned in another thread - we are still proving ourselves, and to do that we have to make the entire thing worthy of free time. Not easy, but doable.

3. I like it when you spend time laying out plans and organizing tasks so they are easy to pick up. As you've admitted, the project has been more or less organic in growth, and it's just not friendly enough to jump in on. I know it's not coding, but certainly, once you started doing more of these kinds of things - more got done and people paid attention. Anything that makes this project friendlier to others is worth as much as an update. Since you took such care and initiative to lay out the editor - I think it will go fast.

I'm willing to lend myself to any of these three things in what ways I can.

Anyways, this week is clearing up nice and I'm feeling up to doing something for OpenMW.
Zini wrote: Assuming the recent performance optimisations work out, we are pretty close to a release.

Ideally I would like to wait for the following:
- pvdk finishing up the launcher
- jhooks sorting out the path problem
- one more user visible change (terrain or maybe a GUI element)

But if one of these takes too long, we can move it easily to 0.12.0.
Greendogo wrote: I think the launcher would be a given, especially since its soooo close.

You want to wait for one more visible feature? How much work has been completed on terrain anyway? I thought it had a lot more work needing to be done?
Zini wrote: Work on the terrain has barely started. If its going to be the terrain, we will have a very late release. On the other hand I don't see people rushing to take the GUI tasks. We might end up releasing without additional features, even if that makes a somewhat insubstantial release.
sir_herrbatka wrote: Maybe instead of 0.11.0 we should tag the new version as 0.10.1?
Zini wrote: The third part of the version code is meant for maintenance releases mostly. If it were not for the launcher, that might work for us here. But the launcher does warrant a new minor version (the second part of the version code).
sir_herrbatka wrote: right... I forgot about the launcher.
Zini wrote: Its about time we start the warm up for the release. There are only two features left (the launcher and the resource files handling) and both are nearly complete.

We had some changes since the last release, most prominently a new dependency: qt

I guess with the .deb we can simply list qt as a dependency and let the package management software sort it out. The cmake scripts still need to be adjusted though.

I don't know if OS X offers something similar and I have no idea what to do on Windows (bit fuzzy about what the current qt license permits and what is good practice with qt). These are tasks for the builders: Hircine, Ace (SWE), corristo.
Please look into this problem and post here, if you have sorted it out.
Star-Demon wrote: Once that's done, please let us slovenly and depraved window users know what to do about QT both user-side and development side.
Hircine wrote:
Zini wrote:Its about time we start the warm up for the release. There are only two features left (the launcher and the resource files handling) and both are nearly complete.

We had some changes since the last release, most prominently a new dependency: qt

I guess with the .deb we can simply list qt as a dependency and let the package management software sort it out. The cmake scripts still need to be adjusted though.

I don't know if OS X offers something similar and I have no idea what to do on Windows (bit fuzzy about what the current qt license permits and what is good practice with qt). These are tasks for the builders: Hircine, Ace (SWE), corristo.
Please look into this problem and post here, if you have sorted it out.
I just found out making a .Deb is easy as running "make package"
whilst in the Build Directory.

I have a 0.10.0 Deb package made. When the code is ready for 11 let me know and i will adjust the cmake scripts for the deb packaging accordingly.\


EDIT: What is not so easy is making available the particular packages like bullet, ogre and what not available. I can't install it due the differences in packages i used.
pvdk wrote: Qt is fully GPL (LGPL and GPLv3) so I think the easiest solution for the Windows release is to ship the necessary Qt .dlls. That way users won't have to install the complete Qt SDK.

More information on Qt application shipping for Windows can be found here
information for Mac can be found here
Peppe wrote:
Hircine wrote:I just found out making a .Deb is easy as running "make package"
whilst in the Build Directory.
Make sure you are using a current version of cpack, there is a bug in earlier versions that made it generate broken packages.
The problem was that it did not include directories in the package, so installation would fail since it would not create directories before trying to install files to them.
Zini wrote: We are trying to push out the release this weekend. Currently we are only waiting for pvdk cleaning up around the launcher and hopefully for some assistance from our resident OS X expert.

@chewit: As usual, I will send you a PM when we are ready.

@Star: Since there is already a good amount of progress with 0.12.0, I would like to push out another promotional video for 0.11.0 immediately (=within days) after the release of 0.11.0.
That is, if you think you can make one for 0.11.0 at all. We are kinda lacking in-game features that can be shown in a video. I guess it would be mostly about the launcher. Stuff like bug-fixing, performance improvements, code maintenance doesn't make good material for a video. If you think, it will be too unsubstantial, we can skip the video for 0.11.0.
Star-Demon wrote: Well, I think I could show off the few new features, maybe discuss future plans - they need to be laid out very plain, though.

There's been a lot of discussion about it, so I think the quickest way for me to get at least two minutes of worthy talking and video would be to have some nice points for this release (show off launcher, GUI stuff) then edit in powerpoint-like plans for the next few releases, maybe tell the community things we want or need.

Within a few days? We'll see.

For the future: It helps if I know how to access new features ahead of time - last time I had to ask (with no answer) and then guess by research how to use the collision feature because the game has no controls other than the console and we don't make a point of showing users how to use stuff we recently put in in the release.

So I'll need a list like everyone else. :)
Zini wrote: The upcoming release (0.11.0) does not have any new features. Just the launcher and behind-the-scenes stuff, like:

- bug-fixes
- performance optimisations
- directory layout reorganisation
- code maintenance

Except for the launcher you can call it a maintenance release.

When demoing the launcher, you should mostly show the profile system and how it will make player's life easier.

There are two important points you should mention:

1. The performance optimisation was only the first round. What you can see in 0.11.0 is not the final fps rate. We have a few more tricks we can try to make it faster.

2. Even though the Launcher allows selecting multiple esm/esp files, OpenMW currently still only supports one esm and no esp files (if everything goes as planned, that will change around 0.13.0).

For the next release (0.12.0) we focus on the GUI. scroll/book/journal/container/message box at least. Maybe some more. And also more behind-the-scenes stuff.

Edit: Regarding your other points:

- We don't have any long-term plan beyond 0.12.0. We did that in the past and it never worked out. Fluctuations in the developer team forced us too often to scrap later steps of the roadmap and I won't waste any more time on it.
That we will get mulitple esm/esp files in 0.13.0 is rather speculative (you can mention it anyway, if you want). The idea of getting the tutorial working within the next few releases, is just that: an idea. I don't think we should mention it yet, before things have solidified a lot more.

- What we need: Nothing right now. At least not urgently. We recently got swamped with new and returning developers that took nearly all the tasks I had prepared. I hope in 0.12.0 we can get rid of some roadblocks that stop us from taking on more tasks. Until then we are good.
If you want, you can do your recruitment routine anyway. There are a few smaller tasks left and given a bit of time I can probably get a few more ready. But it is just not very urgent.
Zini wrote: Thinking about 0.12.0 also got me thinking about 0.11.0. My next branch seems sufficiently stable now. Maybe we should take the completed 0.12.0 issues and move them to 0.11.0 instead.

The upside is that we would avoid having a pure maintenance release (plus launcher).

The downside is that we would start from zero with 0.12.0, which probably means this release will take ages too.
lgro wrote:
Zini wrote:Thinking about 0.12.0 also got me thinking about 0.11.0. My next branch seems sufficiently stable now. Maybe we should take the completed 0.12.0 issues and move them to 0.11.0 instead.

The upside is that we would avoid having a pure maintenance release (plus launcher).

The downside is that we would start from zero with 0.12.0, which probably means this release will take ages too.
I think if "next" is OK, then we could move issues to 0.11, so users receive more "complete release".

As for 0.12 we could start some cleanup tasks i.e. add -Wextra -Wall -Weffc++ etc. into makefiles
and cleanup all warnings (there is a lot of places where some variables are unused, or passed in methods
by value (non POD types) etc.) so later we could introduce -Werror (stricter warnings policy == cleaner code).

Faster we start cleanup, then faster we get nice and readable code (I think).
Zini wrote: We had -Wall before and it was a bit too restrictive (don't even want to consider -Wextra and -Weffc++). I think the warning levels for gcc are good as they are (MSVC might require some tuning to bring it in line with gcc).

Unused variables are already reported with the current settings. If we still have some of these, obviously they should be removed. But I think that has already happened (at least in some branches).
lgro wrote:
Zini wrote:We had -Wall before and it was a bit too restrictive (don't even want to consider -Wextra and -Weffc++). I think the warning levels for gcc are good as they are (MSVC might require some tuning to bring it in line with gcc).

Unused variables are already reported with the current settings. If we still have some of these, obviously they should be removed. But I think that has already happened (at least in some branches).
OK, I'm accustomed to have -Wextra and -Werror in all code but if you think it's to restrictive then I wont force it.
Zini wrote: The release should be available for download soon. I merged the finished changes for 0.12.0 into it, so we have a bit more substance than originally expected.

I sum it up again:

- We have a launcher now.
- Some performance optimisations.
- Many bug-fixes
- more behind the scenes stuff like directory reorganisation and code maintenance
- (very) basic tab complication in the console
- MessageBox GUI

Things that should be mentioned:
- The launcher can handle plugins and multiple masters. OpenMW can't yet (still only one esm).
- We aren't done with performance optimisations. Expect more fps in the future (though probably not in the near future).

For 0.12.0 you may want to mention some of these:
- more GUI
- refactoring of the MWRender subsystem (not sure if it is a good idea to mention it in a video; important, but very technical and very behind-the-scenes)
- NPC animation

btw. how about showcasing the character creation/tutorial? Except for the missing NPC movement, it should work at least up to the point where you leave the ship and it is still our focus to get it fully working within the next 1-3 releases.
Star-Demon wrote: Will get on it.
Star-Demon wrote: Downloaded Ace's package in the other thread.

I'm getting less performance. Scenes take noticeably longer to load.
(it's a x86 package, so I don't expect it to work as well - I've often had to resort to it, though, just to make something work.)

All I can say about the launcher is:

Image

Interior statics are not positioned correctly:
Spoiler: Show
How can I force a messagebox to pop?
Zini wrote: Regarding the Launcher: Crap. I think we have another critical bug to fix. I am deeply sorry (this goes especially to all the builders). It didn't show up in my tests. pvdk, could you have a look at it again? I think the same problem was already mentioned by lgro.

That some meshes have the wrong orientation is a known problem (ages old actually). There is a issue on the tracker for it. Obviously you should choose a cell where this does not happen.

MessageBox: Enter

MessageBox "Text"

into the console.

Or play the first part of the character creation. There are several message boxes while you are on the ship.
Ace (SWE) wrote:
Star-Demon wrote:Image
Did you specify the data path in openmw.cfg?
Zini wrote: Right. This still sounds like a bug. But since currently the user has to create an openmw.cfg file with the data path anyway, maybe we can avoid rebuilding all the packages. We just need to state very clearly in the release message, that the user has to create this file.
Star-Demon wrote: data=D:\Morrowind\Data Files\
Zini wrote: Right. If you hadn't done that, OpenMW wouldn't have run. I guess you have the file alongside your executable? Can you move it to the user directory (not exactly sure where that would be on Windows)?
raevol wrote:
Zini wrote:I guess you have the file alongside your executable? Can you move it to the user directory (not exactly sure where that would be on Windows)?
I'm adding this to the release notes, let me know where the file needs to go so I can specify that.
pvdk wrote: So there's nothing for me to fix right now? I don't have access to my system or a computer on which I can compile the launcher for the next 8 days.

The launcher takes the data path from the config file but should not crash so horribly when something's wrong/not there. Will fix.
Zini wrote: Nope. That doesn't do it. I just tried it myself. Deleting the local cfg file and only having a user cfg file makes the launcher crash for me too. This definitely needs to be fixed before we can release.

Seems we need to delay the release by at least 8 days.
pvdk wrote: The problem must be somewhere in the config loading code in maindialog.cpp.

Code: Select all

void MainDialog::setupConfig()
{
    // First we read the OpenMW config
    QString config = "./openmw.cfg";
    QFile file(config);

    if (!file.exists()) {
        config = QString::fromStdString(Files::getPath(Files::Path_ConfigUser,
                                                        "openmw", "openmw.cfg"));
    }

    file.close();

    // Open our config file
    mGameConfig = new QSettings(config, QSettings::IniFormat);
}
I suspect the mGameConfig = new QSettings(...) to be the culprit. Maybe it's a permission problem. Please find out where exactly the launcher crashes by adding some qDebug() << "here and there";
Zini wrote: From a first look I see multiple problem with this code. You are not considering the global file and and only one file as it seems. I think the whole code segment must be rewritten from scratch.

The correct way of handling it is this:

Code: Select all

dataDir = None
if exists (global_file):
    if has_data_entry (global_file):
        dataDir = data_entry (global_file)
if exists (local_file):
    if has_data_entry (local_file):
        dataDir = data_entry (local_file)
if exists (user_file):
    if has_data_entry (user_file):
        dataDir = data_entry (user_file)
if dataDir is None:
    error
Also note that you should never write to anything but the user file (create one, if it isn't there). And don't copy the data settings from local/global to user.

Edit: Adjusted algorithm slightly to make it more consistent with OpenMW.
pvdk wrote: Thanks for the pseudo-code Zini. I was quite surprised by the code myself as I also noticed the global settings to be missing. I don't remember why I left it out, but something about the global part not being implemented at the time of writing the code comes to mind.

What about the ogre.cfg? Should it too be looked up in the same fashion?
Zini wrote: Yes, it should. But we still have a branch lines up for 0.12.0 that does most of the hard work. Better not waste time on changing the behaviour for ogre.cfg files now. Just sort out the openmw.cfg situation and we should be good for now.
best regards,
Lukasz

Locked

Who is online

Users browsing this forum: No registered users and 1 guest