OpenMW 0.23.0

[Zini]

The one listed in the error message? openmw_inventory_window.layout

[Tolchock]

Okay, I have spent a few hours testing, and I think I've found a few bugs:

* Traders (e.g. Arrille) are not selling some items (e.g. clothing, potions, unenchanted weapons)
https://www.dropbox.com/s/r2zo3ybtgys44 ... gItems.png
* Replies to the Background topic are not displaying at all for some NPCs (e.g. Fargoth)
* Race selection Menu does not depict character heads:
https://www.dropbox.com/s/xk205c7n394b1 ... ection.png
* Certain (scripted?) explanatory windows don't appear in the 'training area' of the Census and Excise office (e.g. book, potion and food windows) when you select the item for the first time
* Arrille's disposition doesn't increase after you return Fargoth's ring
* Female characters (mer?) are using male walk animations (I think)
* Female Khajiit don't use the correct gender to refer to themselves:
https://www.dropbox.com/s/78yc0w1w6ron7 ... hajiit.png
* In this screenshot of Elone's dialogue, clicking the down button won't show the already read topic 'Vvardenfell district'. In order to see it, one must jiggle the scroll up and down. I think the problem occurs when the list of topics is too long for them to be all contained in one window, and then one clicks on a topic above, which automatically makes the list move upwards.
https://www.dropbox.com/s/nvuljbpcsq8rp ... enfell.png

[psi29a]

That one is the latest... from repo.

[pvdk]

I had a fix for the non-latin path problem in the launcher ready for 0.23.0, but I was away on holiday and Ace didn't get my message. I reckon this won't make it into 0.23 anymore, will it?

[K1ll]

Linux targz RC packages:

32 Bit
64 Bit

[psi29a]

Linux targz RC packages:

32 Bit
64 Bit

bbrick@Wintermute:~/Downloads/test/openmw-0.23.0-Linux-64BitRC$ ./openmw.x86_64
./openmw.x86_64: error while loading shared libraries: libOgreMain.so.1.8.1: cannot open shared object file: No such file or directory

You ship almost all libs except for libOgreMain... apparently you are not compiling them statically?

[nnayo]

I have to confirm it is not statically linked:

The missing .so, on my system, are (from "ldd openmw.i686" command):

• libOgreMain.so.1.8.1 => not found
  libOgreTerrain.so.1.8.1 => not found
  libboost_system.so.1.53.0 => not found
  libboost_filesystem.so.1.53.0 => not found
  libboost_program_options.so.1.53.0 => not found
  libboost_thread.so.1.53.0 => not found
  libboost_date_time.so.1.53.0 => not found
  libboost_chrono.so.1.53.0 => not found
  libBulletDynamics.so.2.77 => not found
  libBulletCollision.so.2.77 => not found
  libLinearMath.so.2.77 => not found
  libBulletSoftBody.so.2.77 => not found
  libMyGUIEngine.so.3 => not found

and launching this program, I get:

ERROR: MyGUI EXCEPTION : Error cast : dest type = 'MWDynamicStat' source name = '0x11a27698_EncumbranceBar' source type = 'ProgressBar' in layout 'openmw_inventory_window.layout'
in MyGUI at /home/kfg/i386lucid/home/kfg/openmw/libs/openengine/gui/layout.hpp (line 37)

I hope it helps.

[scrawl]

I don't have this error. Maybe there's an older version of openmw_inventory_window.layout somewhere on your system and it's using that one instead of the one in the package for some reason?

[Zini]

I had a fix for the non-latin path problem in the launcher ready for 0.23.0, but I was away on holiday and Ace didn't get my message. I reckon this won't make it into 0.23 anymore, will it?

Nope. It requires a version of boost that is too new. Ace proposed to change the code and the cmake scripts so that only the Windows build requires the new version (where it doesn't matter that much). But I am very reluctant to allow different library version requirements on a per platform basis. Sounds like a recipe for disaster to me. At most this is the last resort and definitely not something I want to merge in the last minute before a release.

[psi29a]

I don't have this error. Maybe there's an older version of openmw_inventory_window.layout somewhere on your system and it's using that one instead of the one in the package for some reason?

Shouldn't it be checking for local versions first before using an installed version? Will test later.