Weird Installation Problem

[Zincat]

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.

[Tuna-Fish]

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

[Tikigod]

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.

[Demonius]

Putting stuff in program files… does the . exe have a digital signature?

[Steve Walmsley (OP)]

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.

[Tuna-Fish]

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.

This isn't some outdated "good practise", it's following the proper guidelines on how to store data on Windows set by Microsoft. Putting all the things relevant to one program into one folder is the traditional way of doing things in windows, separating the program and static data into %programfiles% and putting everything that might get modified into %appdata% is the new, proper way of doing things.

Whether this is the right approach is another discussion, but on this Paradox (and basically all other modern games) are just doing what Microsoft orders them to do on their platform.

[clement]

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?

[Inglonias]

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

[clement]

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.