Adding small dll to Parts-Only mods to verify install loc

[kerbiloid]

That's how the repositories were invented.
And apt-get.
And CKAN.
It will evolve into a local CKAN-2 after 50 mods each with the library instance, replaced with one library and 50 signature files..

Edited October 25, 2019 by kerbiloid

[linuxgurugamer]

10 hours ago, Stone Blue said:

Also, I thought modifying .version files *usually* breaks KSP AVC checking, if the file doesnt match the hosted one exactly

It breaks AVC if the edits aren't done properly, but the hosted file will override the local file anyway.

@severedsolo, how about keeping the InstallValidator as a stand-alone DLL, this way someone could simply delete it if they don't want the checks

 

[severedsolo]

46 minutes ago, linuxgurugamer said:

, how about keeping the InstallValidator as a stand-alone DLL, this way someone could simply delete it if they don't want the checks

I'm fine with doing that, but @Stone Blue this will actually help with .version file errors. It grumbles at you if it can't parse the JSON.

Edited October 25, 2019 by severedsolo

[paul23]

I still think this should be part of the *launcher* (so ckan) and not the game itself. The launcher should check & verify the game integrity.

[Jacke]

6 minutes ago, paul23 said:

I still think this should be part of the *launcher* (so ckan) and not the game itself. The launcher should check & verify the game integrity.

What about people not using CKAN?  And so much of this needs to be done as and after KSP tries to load .dll's and other things from GameData.  It would require all that code to be duplicated in CKAN.  And if the CKAN checker says "OK!" but it fails in KSP?

The people working on this know what they're doing.

[paul23]

23 minutes ago, Jacke said:

What about people not using CKAN?  And so much of this needs to be done as and after KSP tries to load .dll's and other things from GameData.  It would require all that code to be duplicated in CKAN.  And if the CKAN checker says "OK!" but it fails in KSP?

The people working on this know what they're doing.

Well that's the thing: verification etc is not part of the program, it's part of the os/thing that makes the program. I'd just say "then don't give support if you don't use ckan", if there's too much trouble. 

 

Quote

The people working on this know what they're doing.

I question that. This is like saying "apple knows what you are doing, so it's good we dumb down oses". Well guess what: ios (and mac) is terrible, I'm constantly fighting not only the ones I try to teach how stuff works. I'm now also fighting the os itself.

Edited October 26, 2019 by paul23

[severedsolo]

5 hours ago, paul23 said:

Well that's the thing: verification etc is not part of the program, it's part of the os/thing that makes the program. I'd just say "then don't give support if you don't use ckan", if there's too much trouble. 

Sorry, but you can't complain that everything is being dumbed down and in the same breath say "just get everyone to use CKAN" - I actually did laugh at that .

If the user is using CKAN they shouldn't have the problem that this mod is trying to solve anyway, and if they do it's a CKAN problem.

5 hours ago, paul23 said:

, I'm constantly fighting not only the ones I try to teach how stuff works. I'm now also fighting the os itself.

Well a) this is a learning tool. It will alert you to the fact that you messed up and tell you explicitly how to fix it. b) There's no "fighting" it.  It doesn't do anything for you, it just alerts you that you have a problem, and how to fix it. If you don't like it, delete the dll.

[DStaal]

It's also worth noting on CKAN that it's not perfect either: it occasionally causes it's own set of install issues, doesn't have all mods, and (especially for older versions of KSP) doesn't always run on all the same platforms as KSP.  (And on some looks fairly out-of-place even when it does run.)

[linuxgurugamer]

22 hours ago, paul23 said:

I still think this should be part of the *launcher* (so ckan) and not the game itself. The launcher should check & verify the game integrity.

Not everyone uses CKAN.  

And asking an installer to also do verification of mods which it didn't install is unreasonable.  Even the ones it did install.  I mean, if it installed them, then it thinks its installed correctly.

Regarding time, this has been tested on installs with more than 150 version files, and the a tual time it took to do read all the version files was less than a second.  Obviously that depends on the computer and disk drives, but overall its not a significant amount of time

[severedsolo]

7 hours ago, linuxgurugamer said:

Regarding time, this has been tested on installs with more than 150 version files, and the a tual time it took to do read all the version files was less than a second.  Obviously that depends on the computer and disk drives, but overall its not a significant amount of time

Indeed. The worst I've seen is 2 seconds, but that was on someone using >200 mods.

Anyway, this will be released today (once I've had my coffee and got my daughter ready for the day)

[severedsolo]

And it's done (for 1.8 at least)

 

[CBase]

Sorry, but I still did not understand why a pathname for a mod needs to be checked / protected.

Is it because of reference paths in MM when stuff depends on each other ? Can you provide an example maybe ?

I do understand you want to reduce support time spent to fix these issues, but to me it is very counterintuitive that a name of mod install directory matters, so I would rather think how can make it possible and avoid support problems instead of optimising support ?

[DStaal]

5 minutes ago, CBase said:

Sorry, but I still did not understand why a pathname for a mod needs to be checked / protected.

Is it because of reference paths in MM when stuff depends on each other ? Can you provide an example maybe ?

I do understand you want to reduce support time spent to fix these issues, but to me it is very counterintuitive that a name of mod install directory matters, so I would rather think how can make it possible and avoid support problems instead of optimising support ?

Any KSP part will generally consist of three files: a .cfg file, a model, and a texture.  The .cfg file describes the part, including what model to use and the texture  (The texture can be optional - it can be embedded/referenced in the model itself.)  All these paths are relative to the 'GameData' folder for KSP.  (But may or may not be in the same folder as each other.)

So for a KSP part to load, it's model, texture, and .cfg file have to be in the expected location relative to GameData.

As an example, here's a line out of the MK1-3 part config file from Squad:

	MODEL 
	{
		model = Squad/Parts/Command/Mk1-3Pod/Mk1-3
	}
	

If you change the name of the folder from 'Squad' to 'OfficalKerbalParts', the part will not be able to find it's model, and therefore won't load.

[CBase]

Thank you, since I only modified parts with MM so far, I did not deal with paths in model and texture nodes.

How about allowing ./ for same directory paths ? A small, pretty generic MM extension could then convert these into qualified paths.

[goldenpsp]

2 hours ago, CBase said:

Thank you, since I only modified parts with MM so far, I did not deal with paths in model and texture nodes.

How about allowing ./ for same directory paths ? A small, pretty generic MM extension could then convert these into qualified paths.

The game is very specific about expecting a part's files to be exactly where they should be.