Closed Lisias closed 2 years ago
This is another example of a less than ideal testing process - I easily caught this at a glance once I used a properly "user emulated" KSP test rig, instead of using my Development KSP beds where things are rigged to favour development!
@zer0Kerbal this is a "Lesson Learned" situation: to keep a "clean of development tools" test bed trying to imitate the most what users would have on their machines. :)
It's kinda obvious (hey, I'm supposedly the one earning a life on Software Development! :P ), but I had missed it completely on KSP development (perhaps I got too much into the "Indie" spirit? :D )
@Lisias have been thinking of setting up a VM that auto resets to a known config (Win10Pro with KSP1.12.3) image - and just have it use the read only image....
Nah - we were just too occupied with other things. If I actually played some instead of constant modding - I would have caught it, and apologize that I didn't.
Things will get easier after they get harder - I have enough saved to upgrade my core machine somewhat when the prices fall in December-January -- after that whole fun of upgrade this machine ,then take those parts and upgrade the server to TrueNAScore with the old parts...
@zer0Kerbal Try to use a CopyOnWrite volume, I had heard that REFS (new Windows file system) has it.
I have a lot of KSP 1.12.3 installations on my harddisk, all of them sharing 90% of the space on disk - this is a live saver when you are using SSDs, always more expensive and smaller than we need them.
On my rig, I have the KSP files automatically compacted, and with CopyOnWrite - I would need an HDD 2 or 3 times bigger without compression and CopyOnWrite!
@Lisias - great suggestion - will look into CopyOnWrite
I use Symbolic links - and deploy.bat to auto copy a release into a separate folder of each release - which is symbolically linked into my dev games - so really only one duplication -which isn't so bad. eventually I will move the working local repo's to a RAID drive (when I buy more drives) on the server.
since will have to (re)install windows (probably a good idea going from a i7-4790 (chip lottery winner!) to maybe a Ryzen 7 5700G with a new mobo will probably require a new install.
am thinking of https://en.wikipedia.org/wiki/ReFS
The prolem with SymLinks is that on KSP, the GameData
is not immutable - everybody and the kitchen's sink writes to it (everybody but my KSPU line of addons).
So you can't safely share directories using symlinks because one KSP installment will write its data on a folder that would be needed by another, where such data would be different.
In the end, in order to test things using a setup that an user would likely have, the only safe solution is, indeed, CopyOnWrite. Any write to a configuration file would create a "private" copy of the original, preserving file contents between installments "sharing" folders.
I "can" use symlinks safely only on my KSPU line of addons (where the GameData
is sacred) and some (but not all) of my KSP (official) ones. I'm being cautious on the "Official" brand because GOG and Steam, as far as I know, only backup GameData
and saves
. Until I really understand these tools, I need to be cautious.
Back to the bug - this only shows up if KSP-Recall is installed? So the bug isn't in GOO ? That would been the fix would have to be in KSPR?
Back to the bug - this only shows up if KSP-Recall is installed? So the bug isn't in GOO ? That would been the fix would have to be in KSPR?
The problem is on GPOSP, no question about. KSP-Recall is going to be the most visible "victim" of the problem because it's widely used, but I had heard of some other add'ons (as one related to construction) where 'resources' are used to track down activities (aka, "amount of work already done").
I think I just fixed it, I'm testing it and I will publish a new release in the next few hours.
KSP-Recall uses a stung called
RefundingForKSP111x
to counter-screw a major screw up on KSP about recovering funds. This "meta-resource" is marked as invisible and non-transferrable.However GPOSP is trying to "pump" it nevertheless!
This is a bug. Non transferrable resources are set as non-transferrable for a reason. Invisible Resources too.
Rework the Resources system to ignore non electable resources (KSP-Recall is not the only one using these things)