This isn’t actually complicated. Why on earth this is not done, I do not know. But two things are mandatory I think, as someone who has been programming since the 6800 was a thing.
These should be done before anything including trying to fix CTDs. (Save for the caveats in the first neither are remotely difficult). The first alternative is probably literally a few lines of code.
- Some way of verifying the install (or speeding it up)
What we have is your classic “bug ridden cr*p” Microsoft style installer. If it doesn’t work and busts your system, tough. You get the same with Windows. “Oh but mine works”. Well bully for you. It frequently doesn’t because it’s designed and programmed by someone who assumes things work. You should assume installs will fail occasionally and write code that can at least attempt to handle this.
There are two ways of fixing this.
The ideal way is to be able to verify the installs. Each fspackage does stuff. This may be possible to verify. It may not because patches overlay each other, so it’s not trivial. I suspect it’s a tree of packages not a list. So we get a slightly better answer other than “it doesn’t work, reinstall”, which takes 36 hours where I am.
Frankly it is not good enough.
If they can’t do this, then plan B is actually dead easy. Cache the fspackage files that are downloaded, if there is sufficient space (say more than 10% free), with an associated checksum file. Then rather than download them from the internet, get them from the cache. If they fail the checksum when you use them from the cache, then redownload them.
It’d still take a while, it’s 127Gb after all and you’d have to unpack it , but it might take an hour rather than the best part of two days.
If people want the disk space they can just delete files from the cache.
Sorry, I don’t buy that this second one couldn’t be done by lunchtime today, though it might take a bit longer to test it. You download and construct the file.
I’m presuming it is verified somehow, if it isn’t your developers should be publicly executed. So just copy it to /fs2020/cache rather than /tmp or wherever it goes, and check if it’s there before downloading it, if it fails the verify then redownload it.
- Logging.
Half the ruddy problem is that you don’t know what’s going on. It’s like Apple vs Linux. Boot Linux and you get several screens of gobbledegook to most people. But for some people, it can tell them what is going wrong. With Apple and increasingly Microsoft it is “Your computer is not working properly. Please make it work by fixing the problem which is stopping it working properly. This way it might start working again”. Well thanks for nothing.
You don’t need to log everything just specific actions and phases, starting and ending of chunks of downloads from servers. In a text file, called log.txt or something.
For example, some people have problems with USB devices. If there was a log that said “Initialising driver for T16000 joystick” and a CTD occurred it wouldn’t guarantee that that was the problem. But it would give you a clue. If it crashed accessing a piece of scenery or on clicking a button, it would give the developers and people like me who try to help some clue as to where to start looking.
At the moment people are simply guessing. I don’t blame them for that, supporting this abomination must be a nightmare. It’s the standard Microsoft joke of fixing everything by turning the computer off and on again.
Look guys, that works with piddling little installs for little games where most of the game is sound and graphics anyway. It doesn’t work for this.
And program defensively. Especially installers and things that process external data. Do some basic error checking, don’t just expect it to work because it won’t.
