openmw.org

You mean in this line:

SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libogre-1.7.3 (>= 1.7.3), libbullet0 (>= 2.77), libboost-filesystem1.46.1 (>= 1.46.1), libboost-program-options1.46.1 (>= 1.46.1), libboost-system1.46.1 (>= 1.46.1), libboost-thread1.46.1 (>= 1.46.1), libc6 (>= 2.11.2), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:4.1.1), libmpg123-0 (>= 1.12.1), libois-1.3.0 (>= 1.3.0), libopenal1 (>= 1:1.12.854), libsndfile1 (>= 1.0.23), libstdc++6 (>= 4.4.5), libuuid1 (>= 2.17.2), libqtgui4 (>= 4.7.0)")

?

Not sure. People may still want to build a deb without statically linked libraries. I think we shouldn't disable this option.

People spamming me with pull requests

I will start to chew through them now, but not sure if I can finish this morning.

We could still use a bit more testing with RC1 (especially the dialogue system). Then we can have a RC2 with all the last minute changes and that will hopefully be the same as the release.

Zini wrote:Not sure. People may still want to build a deb without statically linked libraries. I think we shouldn't disable this option.

People can still build their own debs, but they are on their own. However our official packages have no dependency requirement. This way we do not hinder them and they do not hinder us. The only new dependency is nvidia-cg-toolkit which Ubuntu and Debian both have, so again we are good.

Well, packaging is not my area of expertise. If you think that this is the right thing to do and no one else is protesting, then go ahead.

Zini wrote:Well, packaging is not my area of expertise. If you think that this is the right thing to do and no one else is protesting, then go ahead.

It really helps because we where locked into libogre-version because someone at Ubuntu/Debian thought it was a good idea to release OGRE with version numbers in the package name! So the libogre-1.7.3 (>= 1.7.3) is useless to every version (1.7.1 - 1.7.4) except for 1.7.3 which makes management a hell and our end users would have to modify this dependency themselves anyway to work with older (or newer) libraries.

The only other solution was to do libogre-dev (>= 1.7.1) which would work very well, as it would pull in libogre-version as well. This has the side-effect of bringing in all of libogre-dev and it's dependencies.

Since we are statically compiling for our releases, there is no reason to include libogre (nor libbullet) as dependencies for our official packages. People who wish to make debs themselves (getdeb or someone else) can add their own as necessary. I think it is the best solution.

There is a push (2 commits, same file) waiting for you.

Okay, that went better than expected. All pull requests dealt with and I also got rid of those warnings (I think; my compiler is too old to show them).

Reading this thread again, it seems we still have a few problems with the Windows build?

- After click the launcher a window asks for the morrrowind directory.
- The launcher start but the plugins tab don´t show the plugins or master files (is this normal?)
- If I click the Play Button the program starts and close.

- If I delete the openmw.cfg the launcher nor the openmw.exe starts.
- If I copy/paste my morrowind directory location in the openmw.cfg the launcher doesn´t start but the openmw.exe is ok.

My specs
Windows 7, 64 bits, SP 1
My morrowind directory d:\games\morrowind

You need to use the data directory, not the Morrowind directory. From what I read in the source this is actually stated in the UI.

I don't know if this is anything to be concerned with yet, but I was in Ebonheart and it was raining. I closed out of the game, and saw this in my terminal window (I launched the game from the command line):

That is completely normal. We haven't implemented all script instructions yet. If you go to a location where a script with one of these missing instructions is run, you get an error message.