It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like:Chrome,Firefox,Internet Explorer orOpera

×
arrow-down2arrowcart2close4fat-arrow-leftfat-arrow-rightfeedbackfriends2happy-facelogo-gognotificationnotifications-emptyownedremove-menusad-facesearch2wishlist-menuwishlisted2own_thingsheartstartick
avatar
adamhm: [...]You can try starting the game with this command:
env WINEDEBUG="" ./start.sh play
[...]
I'd suspect the GPU/graphics drivers though... do you have the latest available kernel and Mesa installed?
I'm running the latest Mesa 17.3 with the 4.10.0-37 linux kernel.

This what happened in the terminal after running the suggested comment:

https://www.dropbox.com/s/azudk387k26wr7q/wineterminal.txt?dl=0
Did you install all of Wine's dependencies, including the recommended packages? Also how much RAM do you have allocated to the iGPU?

Another thing you could try is the hack Fallout 3 needs to run on Intel graphics. This was not necessary on the Intel system I tested (i3-6100, also 4GB RAM, with 512MB allocated to the iGPU) but your system is a bit older which might make a difference. Copy the following into a text file (call it fohack.reg or so) then open the registry editor (script menu --> advanced options --> registry editor) and import it, then try again:
REGEDIT4

[HKEY_CURRENT_USER\Software\Wine\Direct3D]
"VideoPciDeviceID"=dword:00000402
"VideoPciVendorID"=dword:000010de
Yes - I have all dependencies installed.

The registry modification had no effect.

As far as I know, the graphics memory in hd4600 is dynamic, but set on 256mb at default (no option to change that in the BIOS for some reason...). I did however set wine graphics memory for this prefix to 512. The effect is, there is no crash, but still the game does not start. I'm stuck in a loop - every time I hit play. the launcher disappears and comes right back re-setting all my settings and detecting video hardware all over again (loops like that happened before my change in the wine graphic memory, but there was always a crash after the second iteration of this strange loop).

I know for certain Intel hd 4600 is capable of running NV performance-wise on at least high detail. That said, I tried various different settings, including the ones set by the game by default (windowed, high, some strange resolution), to no result.

Additional info: at the very start of my adventure with this launcher, the terminal screamed about non-existent files from the p11-kit (which I've encountered for the first time, as those files were gtk related thus I guess not present out of the box on a KDE system with Qt based tools) which was kinda odd. I resolved it with no problem by simply manually adding the correct 32bit libraries to the desired location.
Post edited 17 hours ago by valgaav
avatar
valgaav: Additional info: at the very start of my adventure with this launcher, the terminal screamed about non-existent files from the p11-kit (which I've encountered for the first time, as those files were gtk related thus I guess not present out of the box on a KDE system with Qt based tools) which was kinda odd. I resolved it with no problem by simply manually adding the correct 32bit libraries to the desired location.
The p11-kit thing shouldn't be anything to worry about; it's always happened here too & I've always just ignored it.

Anyway something weird is going on here - I downloaded Kubuntu 17.04 & installed it on the other system to test for myself. I did the following:

- Install Kubuntu
- Install all available system updates
- Add Padoka's stable Mesa PPA and update again & reboot
- Install Wine (did this through Kubuntu's software manager)
- Run the FONV wrapper build script
- Run FONV

And it worked fine (well, I did have to install Zenity as that's not included with Kubuntu but that was all that was needed). Were there any problems when you ran the build script?
Post edited 13 hours ago by adamhm
Huh. I'm seeing two variables that can possibly be at fault.

1) I'm using the Oibaf repository for my Mesa drivers. Currently I'm using 17.3.0-devel (the question is what exact version is provided by Padoka? what does glxinfo | grep "OpenGL version" return?). I wonder what will happen if you use the same repo as me?

2) I just remembered my system main Wine install is: "wine-2.19 (Staging)" from the official wine repos. Is it a problem? I presumed that the script installs it's own version for the prefix. I did however install DeusEx (like 2 months ago) with one of your scripts and it worked flawlessly, so I'm not sure is it in any way related.

As for the building, it finished fine I guess. I can however delete the folder and start the building again just to be sure and send the whole terminal output to you.
avatar
valgaav: 1) I'm using the Oibaf repository for my Mesa drivers. Currently I'm using 17.3.0-devel (the question is what exact version is provided by Padoka? what does glxinfo | grep "OpenGL version" return?). I wonder what will happen if you use the same repo as me?
Padoka's Stable Mesa PPA provides stable Mesa releases, currently 17.2.2. It's entirely possible that there's a regression in 17.3.

I removed Padoka's PPA and added Oibaf's instead then updated & tested again; FONV still works though (also Oibaf's PPA is now providing Mesa 17.4.0, updated a couple of hours ago, so you might want to update in case that fixes it)

avatar
valgaav: 2) I just remembered my system main Wine install is: "wine-2.19 (Staging)" from the official wine repos. Is it a problem? I presumed that the script installs it's own version for the prefix. I did however install DeusEx (like 2 months ago) with one of your scripts and it worked flawlessly, so I'm not sure is it in any way related.
My wrappers do use their own copy of Wine, so the system's version shouldn't really matter.

avatar
valgaav: As for the building, it finished fine I guess. I can however delete the folder and start the building again just to be sure and send the whole terminal output to you.
It might be worth doing, just in case
So... I just installed Gecko through the advanced options as "let's do some random thing - let's see what happens" and... IT WORKED!

After that the loop mentioned above stoped happening, the launcher started to remember my settings, and hitting play worked out of the box.

Played for 45 minutes (character creation, activating hardcore mode, saving, looting the whole town and declaring war on everything that lives - a typical test ride) - stable and performing well as expected.
Post edited 7 hours ago by valgaav
But this is still puzzling. The question now is: Why did it work out of the box without installing Gecko from the Advanced options on your fresh install? This isn't related to any dependencies outside the wine prefix and not to mention that it is not related to hardware.

I did update mesa, but I tried to run the game after the update and it failed. I've reinstalled gstreamer1.0 plugins and it failed. Activated and deactivated winegstreamer in the wine config and it failed. The problem was fixed after installing Gecko and nothing else was done except that at that given moment.
Glad to hear you got it working :)

I do have an idea of what might be the cause though. Could you open prefix/drive_c/users and delete (or rename) your user directory inside the prefix, then try playing again & let me know what happens please?

And then if it stops working again run this and then try again: env WINEDLLOVERRIDES=mscoree,mshtml=d ./start.sh run="wineboot -u"

(or run the build script again, but run that command before trying to play)
Sure.

I've renamed the directory.

After that the loop returned and the second iteration ended with a crash (so it got back to the state before installing Gecko).

Running nv WINEDLLOVERRIDES=mscoree,mshtml=d ./start.sh run="wineboot -u" created a new directory and running the game again worked fine.

I did not have to run the build script anew. (Unless I should try this as well, then by all means I will)

So, out of curiosity, what's the problem behind this?
Post edited 7 hours ago by valgaav
avatar
valgaav: So, out of curiosity, what's the problem behind this?
It looks like it needs certain user directories to exist (at least on your particular setup), which are not normally created by my wrapper scripts but are created when "wineboot -u" is run.

I suspect it has something to do with Galaxy, similar to the issue others have encountered with FONV not starting unless a 'net connection is available (which I've also never personally experienced - I do not know what conditions are needed to trigger this behavior).
avatar
adamhm: It looks like it needs certain user directories to exist
So it is not related to gecko itself and the install triggers the creation of the dir?
avatar
adamhm: I suspect it has something to do with Galaxy.
It is a galaxy-client free install, though.

Anyway, thank you very much for the help and the work on the script (on ALL your scripts).

Thumbs up for the script for Total Annihilation. If you will ever approach Homeworld: Remastered Collectiom, running the Classic versions is easily doable (when following appdb notes) on Mesa with Intel HD (which I did with PlayOnLinux), and the remastered versions allegedly work on Nvidia/AMD proprietary drivers. Have a good day/night:)
Post edited 6 hours ago by valgaav
avatar
adamhm: It looks like it needs certain user directories to exist
avatar
valgaav: So it is not related to gecko itself and the install triggers the creation of the dir?
Yes. I have no idea which directory/directories though, but it should be easy to modify the start script to better handle this so that it doesn't cause any more problems in future (I'll update all of my scripts to do this - I have a few other small improvements to make as well).

avatar
adamhm: I suspect it has something to do with Galaxy.
avatar
valgaav: It is a galaxy-client free install, though.
The game itself has some libraries for Galaxy integration and they seem to cause problems under certain circumstances when there's no internet connection available (see this thread for details). I suspect that these two issues might be related.

avatar
valgaav: Anyway, thank you very much for the help and the work on the script (on ALL your scripts).

Thumbs up for the script for Total Annihilation. If you will ever approach Homeworld: Remastered Collectiom, running the Classic versions is easily doable (when following appdb notes) on Mesa with Intel HD (which I did with PlayOnLinux), and the remastered versions allegedly work on Nvidia/AMD proprietary drivers. Have a good day/night:)
I have got the Homeworld games here & tried them in Wine before, so I might look into making wrappers for them too at some point. I have a lot planned :)