If you don't have the required runtimes to run the game, you will need the installer, yes. (Source)

Yep, I just figured that is a paragraph on the download post with a link to the. Net 4 runtime installer for anyone with a version of Windows to old to have it. I believe anyone with Windows 7 and up who has updates enabled should have the. Net 4 runtime installed.

Is there a need to have an install program vs. just providing a zip file of the folder structure that can be placed where we want it to live in our machine?

I think it will be easiest just to have the database in the installation directory and warn players not to install in program files. That reduces the potential for bugs outside my control.

Quote from: Steve Walmsley on April 04, 2020, 04:59:24 AM

It is folder related. If I move the install files from C:/Program Files/Aurora to C:/Aurora it works fine. That is true for both my main PC and my laptop.

No idea what is going on there.

The "program files" directories in modern (post-xp) windows versions is meant for immutable program data. It has different file permissions and backup behavior than the rest of the filesystem, and consequently is very slow to write.

Assuming that you have a base database file(s) that are meant to be changed during use, the correct way to use them in modern windows systems is to have a clean copy of them in the game folder in in the install folder, but never open them from this folder, instead on startup you check whether %appdata%/aurora4x(example_name)/ exists, and if not, create it, and then copy over all the files that are meant to be changed during use, and open them in %appdata%.

Things like this bug me immensely when trying to keep my System drive dedicated to the OS and only specific software that benefits from using a SSD.

If I have something installed on my secondary HDD, I expect it to keep as much of its dependant files stored relative to the drive I've installed it on, not to dump additional files onto another drive.... I get why developers do it, but so much of it seems to stem from outdated "Good practise" that really isn't necessary 9 times out of 10.

Just like all those games out there that despite being installed on my secondary HDD, still insist that settings, mod data, saves and such all be tossed onto my system SSD in a directory within the users Documents hierarchy, which ends up meaning my system drive has gigs of misc data sprawled around on it for applications installed on my secondary drive..... Yes Paradox.... you suck big time for doing it for every game.

Windows doesn't like things in C:/Program Files being edited, so if the database is in the same folder as the rest of the program then it's likely that protection is what is causing the long waits. Making sure it doesn't get installed in program files would fix it, as would having the database be somewhere else. %appdata% is commonly used for this sort of thing.

This is most likely the correct reason. Windows really doesn't like tinkering with the c:/Program Files folder.
In a certain sense it's a good thing (it can protect users, especially the less computer-savvy ones), but then you have these problems cropping up.

Probably do write it somewhere in the installer, or propose a different folder by default. And I would surely use 64bits, for systems that support it.

Do you have x64 Windows ?    And you compile x64  Aurora ?

If Windows x64 and Aurora  compiled by 32-bit (x86) compilator, he must be install to  C:/Program Files (x86)  folder
 

I'm going to create both 32 and 64 bit versions. In testing, the 32 bit is actually faster but I suspect that will change for larger games.

For this example, I compiled 32 bit and installed to C:/Program Files (x86) folder.

Windows doesn't like things in C:/Program Files being edited, so if the database is in the same folder as the rest of the program then it's likely that protection is what is causing the long waits. Making sure it doesn't get installed in program files would fix it, as would having the database be somewhere else. %appdata% is commonly used for this sort of thing.

Yes, got this as my prime suspect too.

Windows doesn't like things in C:/Program Files being edited, so if the database is in the same folder as the rest of the program then it's likely that protection is what is causing the long waits. Making sure it doesn't get installed in program files would fix it, as would having the database be somewhere else. %appdata% is commonly used for this sort of thing.