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:

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.

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?

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.

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)

My wrappers do use their own copy of Wine, so the system's version shouldn't really matter.

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.

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.

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?

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).

So it is not related to gecko itself and the install triggers the creation of the dir?
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:)

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).

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.

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 :)

That's really great news. If you'll need to test the new scripts I'm available:)

By the way, I experienced something quite strange. New Vegas froze pulseaudio at some point (pulseaudio -k was the only solution) disabling all sound in the system. Have you ever encountered similar problems under Wine or with this particular game?

All wrappers have been updated, so if you use the new FONV wrapper you shouldn't need to do any additional work to get it running now :)

No, this has never happened to me (with any game)