Allow to modify FSO builds and only install the best build for user system

KnossosNET / Knossos.NET

Repository for the Knossos.NET launcher, currently in development.

GNU General Public License v3.0

23 stars 10 forks source link

Allow to modify FSO builds and only install the best build for user system #88

Closed Shivansps closed 8 months ago

Shivansps commented 8 months ago

This adds a buttong to modify FSO build installs and now during a new build install only the best FSO build will be installed instead of downloading all compatible builds.

Needs some more testing.

notimaginative commented 8 months ago

Just gave this a quick test...

only the arm64 build was download on my arm64 mac
I was able to add and remove the x64 mac build through the Modify function
from a win arm64 VM I was able to add/install a x64 build through the Modify function
from a linux arm64 VM I was unable to install the linux build (as expected)

Couple of issues that I noticed:

the mac x64 build is listed on the Modify popup as MacOSX-x8664 instead of MacOSX-x86_64
when removing a mac build (either arch) it fails to completely remove the app due to the symlinks

For the symlinks bug, I think that's due to those not being in the file list. So it removes all of the individual files it knows about but leaves the symlinks and there. However the build did show as being uninstalled and reinstalling it worked as expected.

Shivansps commented 8 months ago

The pkg name should be fixed, but i dont belive there is something i can do about the symlinks.

notimaginative commented 8 months ago

I don't think the symlinks getting left around are that big of a deal. It will reinstall over them just fine, and they don't take up much space.

But there is this things-getting-left-behind issue that is present in mods too that may need to be addressed at some point and that may be a good time to revisit a method of (safely) removing left overs from engine builds like the symlinks.

Shivansps commented 8 months ago

I don't think the symlinks getting left around are that big of a deal. It will reinstall over them just fine, and they don't take up much space.

But there is this things-getting-left-behind issue that is present in mods too that may need to be addressed at some point and that may be a good time to revisit a method of (safely) removing left overs from engine builds like the symlinks.

the only solution is implementing something that i was thinking from the start but i did not due to have to support existing mod libraries. And that is simply... enforce the "devmode" folder structure for all mods, in that way we can just delete the pkg folder. Enforcing it for new mod installs while still supporting the old method on installed mods.

This is on my list to implement at some point in 2024 along with multilang and deleting installed optional mod pkgs. That would be the icing on the cake since they are non critical.

JohnAFernandez commented 8 months ago

I think we should merge now, then, since the other suggestion is targeted for 2024.