I've got wine-20040309 (from portage) nwwine-20030911 (from portage) nwwine-20031118 (from http://home.woh.rr.com/nwmovies/nwtoolset.txt) winex-transgaming-3.2.3 (from portage) Neverwinter nights for windows v.162 (the linux installation is completely separated) linux-2.6.3-gentoo With wine, I can start nwtoolset.exe, but common controls don't work (I've tried importing the DLLs from everywhere, but nothing: I can't access drop-down menus and OpenGL areas are buggy, that is I can see OpenGL animations where I shouldn't (around buttons) and I can't where I should). With both versions of nwwine, I get "/usr/lib/nwwine/bin/wine: could not load 'N:\nwtoolset.exe' as Win32 binary" With winex3, I get "/usr/lib/transgaming_winex3//winex/bin/wine: can't exec 'nwtoolset.exe': error=21" Generic windows applications run without problems with all four emulators. Now, since nwwine is aimed to run a unique application, nwtoolset.exe, and it's enormously difficult to make it work properly, I thought it would be a REALLY nice idea if someone provided a way to do emerge nwwine nwwine nwtoolset.exe and see it work, on the first shot ;) It wouldn't be difficult to provide it bug-free, since there are only four possible environments to take into consideration: 1)NWN 2)NWN + SoU 3)NWN + HotU 4)NWN + SoU + HotU obviously assuming that older versions can be ignored. nwtoolset doesn't require ANY entry in the windows registry, so it would be a very controlled environment. I assure you, there would be LOTS of thankful people.
I think you will have better luck asking in the Gentoo forums, as I can't help you because I don't own NWN and a lot of users don't read bug reports. please report back.
here's nwwine 20040309: http://home.woh.rr.com/nwmovies/nwwine-patch-against-20040309.diff-dwh could you release an updated ebuild?
Does the new ebuild (20040309) provide a working environment, or is it just a request for a newer version? If it is simply a request for a newer version, you would probably do best to submit it as a separate bug, then have this bug depend on that one.
it provides an _almost_ working environment -- that is, the version of nwwine currently available in portage doesn't work, fullstop. the new version I linked has several issues, but it's quite usable.
I've managed to modify a patch I had for wine-20040309 and apply it to wine-20040615. AND, I've also managed to modify the wine-20040615 ebuild for nwwine. It still has problems installation problems; yet I don't know how to solve them.
Created attachment 35308 [details] /usr/portage/games-emulation/nwwine/nwwine-20040615.ebuild
Created attachment 35309 [details, diff] /usr/portage/games-emulation/nwwine/files/nwwine-patch-against-20040615.diff-dwh
Created attachment 35310 [details] /opt/nwwine/bin/nwwine I had to modify "wine" on the last line to "wine-pthread". A better solution would be to create a "nwwine-pthread" script.
Created attachment 35311 [details] /usr/bin/nwwine I created this manually editing a copy of the /usr/bin/wine script from the wine-20040615 package. You should find a way to make the ebuild create it. Strictly speaking, one should be created, but I don't know if its content is correct.
It works SEAMLESSY. I've only noticed some really minor OpenGL problems (textures not applying to some models).
crap I forgot -- it also requires all the patches from /usr/portage/app-emulation/wine/files/
a cross platform tool to editing mods and data was born, you can check it here: http://openknights.sourceforge.net/tikiwiki/tiki-index.php?page=neveredit maybe this can help in providing a working toolset for linux
I've already tried it and it has a good potential but it's faaaaar from usable yet.
The patch/ebuild I've provided has a bug: it refuses to start if any application using standard wine (20040716) is currently running. $ nwwine wine client error:14: version mismatch 146/143. Your wine binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running? See what you can do about it; I've no idea on how to fix it.
Regarding the last comment I see in this bug report, I think there may be a fundamental problem with this ebuild: It can be installed together with differend versions or flavors of wine. This should not be possible, because pretty simply if it is, the wineserver version conflict described here is not avoidable. Could the author of the ebuild please enlighten me if I am correct regarding parallel installation of nwwine-$version1 and wine-$version2 with ($version1!=$version2) ? Thanks.
You are correct, you can't run wine and nwwine simultaneously if their versions differ. However, making them mutually exclusive wouldn't be a good idea, because nwwine is not mantained at all and I won't be able tu upgrade it any more as soon as I'll find some major errors when applying the patch to newer wine versions. I suppose that creating two separate and non-overlapping wineservers would require extra patches, which I'm absolutely unable to write.
I tried to apply the patch to wine-20041201, but I had a lot of problems. In particular, I had to manually patch winpos.c, which is responsible for GL rendering, but evidently I did something wrong because I can't see the GL contents inside aurora with the new version. So I'm releasing it "as is". Maybe someone in the wine team will be able to fix it. The older version WORKS, though.
Created attachment 45513 [details] nwwine-20041201 ebuild (non functional)
no interest in maintaining this package so it's been punted
