linuxgurugamer

[1.5.1, 1.6.1, 1.7.2] KSP-AVC Add-on Version Checker Plugin - MiniAVC

Recommended Posts

I was just wondering, are you going to update this? It tells me that it is incompatible w/ 1.6.

Share this post


Link to post
Share on other sites
30 minutes ago, IMLL1 said:

I was just wondering, are you going to update this? It tells me that it is incompatible w/ 1.6.

It is not incompatible and the version file is valid for ksp 1.5.1 and higher. Are you sure you got the correct version (this adopted one, net the original from cybutek)?

 

Share this post


Link to post
Share on other sites
2 hours ago, 4x4cheesecake said:

It is not incompatible and the version file is valid for ksp 1.5.1 and higher. Are you sure you got the correct version (this adopted one, net the original from cybutek)?

 

I think I did...

2 hours ago, 4x4cheesecake said:

It is not incompatible and the version file is valid for ksp 1.5.1 and higher. Are you sure you got the correct version (this adopted one, net the original from cybutek)?

 

Wait do I want MiniAVC or KSP_AVC?

Share this post


Link to post
Share on other sites
22 minutes ago, IMLL1 said:

I think I did...

Wait do I want MiniAVC or KSP_AVC?

Personally, I prefer KSP_AVC because you can just add zero miniavc to get rid of all the miniavc versions bundled with almost every mod so the game doesn't need to load 50 mods and 50 miniavc^^

Well, miniavc can do the same job if you move it into the GameData directory but KSP_AVC + zero miniavc can be installed with two clicks in CKAn, so I go with that^^

Share this post


Link to post
Share on other sites
1 hour ago, 4x4cheesecake said:

Personally, I prefer KSP_AVC because you can just add zero miniavc to get rid of all the miniavc versions bundled with almost every mod so the game doesn't need to load 50 mods and 50 miniavc^^

Well, miniavc can do the same job if you move it into the GameData directory but KSP_AVC + zero miniavc can be installed with two clicks in CKAn, so I go with that^^

So are you saying that most mods come w/ MiniAVC? Cause I don't install via CKAN, I go the old fashioned way. What does MiniAVC do compared to KSP_AVC?

Share this post


Link to post
Share on other sites
2 minutes ago, IMLL1 said:

So are you saying that most mods come w/ MiniAVC? Cause I don't install via CKAN, I go the old fashioned way. What does MiniAVC do compared to KSP_AVC?

Many mods include a copy a MiniAVC, no matter how you install them. That's why zero MiniAVC exists...to disable all the MiniAVC.dlls^^

Actually, I'm not exactly sure what are the differences. MiniAVC will check every mod it can find in it's own folder and subfolders. Usually, this is just the mod it comes with but if you move a single MiniAVC.dll file from the mod folder to your GameData folder, it will check every mod which got a .version file so other copies of MiniAVC become obsolete.

KSP_AVC will also check all the mods which got a .version file as well + provides a fancy mod list in the main menu^^

The advantage of KSP_AVC + zero MiniAVC is: You don't have to worry about any extra copies of MiniAVC anymore. They will be disabled by zero MiniAVC and KSP_AVC will still notify you about any mod updates. But if you just run MiniAVC and you don't want like 20/50/100 copies of it, you have to delete the copy in every mod you got on your own, sparing the one in the GameData folder to keep an eye on updates, so more work for you.

Share this post


Link to post
Share on other sites
On 2/3/2019 at 10:54 PM, 4x4cheesecake said:

Many mods include a copy a MiniAVC, no matter how you install them. That's why zero MiniAVC exists...to disable all the MiniAVC.dlls^^

Actually, I'm not exactly sure what are the differences. MiniAVC will check every mod it can find in it's own folder and subfolders. Usually, this is just the mod it comes with but if you move a single MiniAVC.dll file from the mod folder to your GameData folder, it will check every mod which got a .version file so other copies of MiniAVC become obsolete.

KSP_AVC will also check all the mods which got a .version file as well + provides a fancy mod list in the main menu^^

The advantage of KSP_AVC + zero MiniAVC is: You don't have to worry about any extra copies of MiniAVC anymore. They will be disabled by zero MiniAVC and KSP_AVC will still notify you about any mod updates. But if you just run MiniAVC and you don't want like 20/50/100 copies of it, you have to delete the copy in every mod you got on your own, sparing the one in the GameData folder to keep an eye on updates, so more work for you.

MiniAVC will check version files in it's directory tree, but not in other trees (ie: mods).  Which is why it is included in individual mods.  It has an option to not check, and having the multiple dlls isn't harmful and doesn't take too much time.  But for those who don't like them, there is ZeroMiniAVC (which, BTW, i also maintain)

Share this post


Link to post
Share on other sites
9 minutes ago, linuxgurugamer said:

having the multiple dlls isn't harmful

It harms my eyes whenever someone posts an log and I want to check the installed .dlls since it is the most reliable mod list :P Of course, you can clean it up in a texteditor with a simple 'replace' command but no reason to cause a mess in the first place when there is a simple solution with a combination of ZeroMiniAVC + full AVC^^

Share this post


Link to post
Share on other sites

Does the COMPATIBLE_VERSION_OVERRIDE syntax work? My understanding is this should disable compatibility warnings for versions defined in the KSP-AVC.cfg. If I'm wrong please correct me. Do I have to configure something else?

Below is my KSP-AVC.cfg. I see no difference in the compatibility warning messages presented with or without the block of COMPATIBLE_VERSION_OVERRIDE lines. Setting local vs remote priority did nothing that I could see.

I'm tired of seeing warning messages about incompatible versions every time I launch KSP. To me a simple version check is overly cautious and provides no useful info, but I do like seeing when there are updates available, so I don't want to completely remove KSP-AVC.

Spoiler

KSP-AVC
{

	// OVERRIDE_PRIORITY authority; will override anything in any of the .version files. This includes any of the 
	// simple overrides in the files


	// OVERRIDE_PRIORITY has the following possible values
	//	remote	remote file overrides local file
	//	local	local file overrides remote file
	//	none	local file overrides remote file
	
	OVERRIDE_PRIORITY = remote



	// SIMPLE_PRIORITY has the following possible values:
	//	remote	remote file has priority over local file
	//	local	local file has priority over remote file
	
	SIMPLE_PRIORITY = remote

	// SIMPLE_PRIORITY can allow an individual .version file to specify which file should have priority.
	// This will allow one of the following lines in a specific .version file will take priority:
	//	"LOCAL_HAS_PRIORITY": true
	//	"LOCAL_HAS_PRIORITY": false
	//	"REMOTE_HAS_PRIORITY": true
	//	"REMOTE_HAS_PRIORITY": false

	// KSP-AVC now can be configured to automatically allow
	// multiple KSP versions to be compatible with other versions (see below)
	// This would be in a .version file to explictly say that this override
	// is not allowable for that specific .version file

	// "DISABLE_COMPATIBLE_VERSION_OVERRIDE": true

}

// This would be in a separate file, to be created by the user. This is entirely optional
// and is intended to allow a user to tell KSP-AVC that, for example, all mods which are 
// listed as compatible up to version 1.4.1, would also be compatible with 1.4.3, etc
KSP-AVC
{
	// This tells KSP-AVC that any mod with the first version listed is also compatible 
	// with the second version on the line
 	COMPATIBLE_VERSION_OVERRIDE = 1.4, 1.6.1
 	COMPATIBLE_VERSION_OVERRIDE = 1.4.1, 1.6.1
 	COMPATIBLE_VERSION_OVERRIDE = 1.4.2, 1.6.1
 	COMPATIBLE_VERSION_OVERRIDE = 1.4.3, 1.6.1
 	COMPATIBLE_VERSION_OVERRIDE = 1.4.4, 1.6.1
 	COMPATIBLE_VERSION_OVERRIDE = 1.4.5, 1.6.1
 	COMPATIBLE_VERSION_OVERRIDE = 1.5, 1.6.1
 	COMPATIBLE_VERSION_OVERRIDE = 1.5.1, 1.6.1
 	COMPATIBLE_VERSION_OVERRIDE = 1.6, 1.6.1
}

//
// This section lists mods which will not allow the compatible override
//
KSP-AVC
{
	IGNORE_OVERRIDE = Kopernicus
}

 

Share this post


Link to post
Share on other sites

@Tonka Crash Oh, I didn''t even know this feature exists :o

I took a look at it and so far I can tell, there is actually a NRE while this config node is read. I was able to fix the NRE, so AVC actually creates a dictionary which contains these values but this doesn't seem to be enough, I'm still getting the incompatible game version displayed on game launch.

There is actually a comment which intrigues me, saying

// need to add code to check the compatible list here

maybe that's related, maybe it's for a different part, not sure yet^^

*grabs a shovel to dig deeper into the code*

Share this post


Link to post
Share on other sites
1 hour ago, 4x4cheesecake said:

@Tonka Crash Oh, I didn''t even know this feature exists :o

I took a look at it and so far I can tell, there is actually a NRE while this config node is read. I was able to fix the NRE, so AVC actually creates a dictionary which contains these values but this doesn't seem to be enough, I'm still getting the incompatible game version displayed on game launch.

There is actually a comment which intrigues me, saying


// need to add code to check the compatible list here

maybe that's related, maybe it's for a different part, not sure yet^^

*grabs a shovel to dig deeper into the code*

I started the compatible stuff, but never finished it

Since it wasn't documented anywhere, I didn't expect people to use it, at least not without asking me

Share this post


Link to post
Share on other sites
2 minutes ago, linuxgurugamer said:

I started the compatible stuff, but never finished it

Since it wasn't documented anywhere, I didn't expect people to use it, at least not without asking me

Well, if you don't mind, I would like to try to get it working and if I'm successfull, you'll get a PR :)

Share this post


Link to post
Share on other sites
3 minutes ago, 4x4cheesecake said:

Well, if you don't mind, I would like to try to get it working and if I'm successfull, you'll get a PR :)

Not only won't I mind, I will be grateful if you can.

 

Share this post


Link to post
Share on other sites

@Tonka Crash Would you mind to try my version of AVC to test the override functionallity? :)

https://github.com/4x4cheesecake/KSPAddonVersionChecker/releases/tag/1.2.0.8_beta

This AVC version compares KSP_VERSION from the .version file of a mod with the settings for COMPATIBLE_VERSION_OVERRIDE in the AVC.cfg. These version numbers need to match.

In order to exclude mods from the version override, use IGNORE_OVERRIDE node, for example:

KSP-AVC
{
	IGNORE_OVERRIDE = Kopernicus
	IGNORE_OVERRIDE = Environmental Visual Enhancements
}

(The name is taken from the .version file)

edit: I just noticed that I missed the entry "DISABLE_COMPATIBLE_VERSION_OVERRIDE" so this doesn't work yet...it's enabled everytime^^

Edited by 4x4cheesecake

Share this post


Link to post
Share on other sites

@4x4cheesecake It's working, but I was confused by some of the results. If I explicitly list every version like I have in the .cfg above I got no warnings. The KSP-AVC box just goes away after running the checks. I currently don't have any mods waiting for updates so I couldn't verify that functionality.

BUT, I then commented out a couple versions and got what seemed to be spurious warnings. Just understanding what was being checked was the cause of my confusion. Again I went in with assumptions about how I thought things should work without knowing how they really work. I had COMPATIBLE_VERSION_OVERRIDE set for all released versions from 1.4.5 and later, so I expected warnings for mods with a KSP_VERSION_MAX of 1.4.4 or lower in the .version file. For some mods I was still seeing a warning even though KSP_VERSION_MIN and KSP_VERSION_MAX covered a range like 1.4-1.4.99. I didn't think I should since 99 > 5. One approach would be to make KSP-AVC behave this way, but having figured out what was going on I don't think it's the best approach.

Looking at the mods that were giving me warnings it appears KSP-AVC is only checking against the KSP_VERSION field which I'm guessing is intended to be which build of KSP the mod was actually compiled against. This is absolutely fine with me and probably the most valid check for mod compatibility. But, It's confusing when the warning given includes the version I wanted to exclude. The simple fix is to change the warning  to include the actual value that trips the warning. 

I'd suggest changing the format of the warning along the lines of TransferWindowPlanner 1.6.3 was compiled on KSP 1.4.2 to run on 1.4-1.4.99. If I saw that 1.4.2 the first time around it would clue me in that the overrides I'm setting are KSP_VERSION and didn't use KSP_VERSION_MAX like I assumed. The downside is showing more info to newbies gives them more things to get confused about and may get them wound up that the mod isn't compiled against the latest and greatest KSP even if the valid range covers the current release.

In the list of mods in the KSP-AVC window in the upper left corner it would be nice to continue to see out of date mods (based on KSP_VERSION) highlighted in yellow no matter how the COMPATIBLE_VERSION_OVERRIDE is set just to give some indication (if the user bothers to look) which mods were compiled against older versions of KSP. Like I said, it would be nice, but not essential.

Share this post


Link to post
Share on other sites

Thanks for testing :)

11 minutes ago, Tonka Crash said:

Looking at the mods that were giving me warnings it appears KSP-AVC is only checking against the KSP_VERSION field which I'm guessing is intended to be which build of KSP the mod was actually compiled against.

That's correct and what I've tried to say:

2 hours ago, 4x4cheesecake said:

This AVC version compares KSP_VERSION from the .version file of a mod with the settings for COMPATIBLE_VERSION_OVERRIDE in the AVC.cfg.

Sorry if this wasn't clear.

It's easy to change this behaviour to cover a range of versions but I thought it would be better to check just the KSP_VERSION to keep a better control about different versions. But I have to admit, that it can be confusing. I'll try to implement both methods, to cover a range and/or a single version, depending on the config settings so the user can decide.

22 minutes ago, Tonka Crash said:

In the list of mods in the KSP-AVC window in the upper left corner it would be nice to continue to see out of date mods (based on KSP_VERSION) highlighted in yellow no matter how the COMPATIBLE_VERSION_OVERRIDE is set just to give some indication (if the user bothers to look) which mods were compiled against older versions of KSP. Like I said, it would be nice, but not essential.

Haven't checked this window during my tests, I'll take a look at it :)

Share this post


Link to post
Share on other sites
5 hours ago, Tonka Crash said:

Looking at the mods that were giving me warnings it appears KSP-AVC is only checking against the KSP_VERSION field which I'm guessing is intended to be which build of KSP the mod was actually compiled against. This is absolutely fine with me and probably the most valid check for mod compatibility. But, It's confusing when the warning given includes the version I wanted to exclude. The simple fix is to change the warning  to include the actual value that trips the warning.

AVC should use the KSP_VERSION_MIN and KSP_VERSION_MAX first, if they don't exist, then it should use the KSP_VERSION field.  The Min and Max have priority

5 hours ago, Tonka Crash said:

I'd suggest changing the format of the warning along the lines of TransferWindowPlanner 1.6.3 was compiled on KSP 1.4.2 to run on 1.4-1.4.99. If I saw that 1.4.2 the first time around it would clue me in that the overrides I'm setting are KSP_VERSION and didn't use KSP_VERSION_MAX like I assumed. The downside is showing more info to newbies gives them more things to get confused about and may get them wound up that the mod isn't compiled against the latest and greatest KSP even if the valid range covers the current release

Do that for your tests, but please don't change it.  As you say, it will simply create problems with confusion

5 hours ago, Tonka Crash said:

In the list of mods in the KSP-AVC window in the upper left corner it would be nice to continue to see out of date mods (based on KSP_VERSION) highlighted in yellow no matter how the COMPATIBLE_VERSION_OVERRIDE is set just to give some indication (if the user bothers to look) which mods were compiled against older versions of KSP. Like I said, it would be nice, but not essential

No.  See my comments about the MIN and MAX

@4x4cheesecake these comments are really for you

7 hours ago, 4x4cheesecake said:

This AVC version compares KSP_VERSION from the .version file of a mod with the settings for COMPATIBLE_VERSION_OVERRIDE in the AVC.cfg. These version numbers need to match.

Again, see my comments about the MIN and MAX, they MUST have priority

Share this post


Link to post
Share on other sites
6 hours ago, linuxgurugamer said:

Again, see my comments about the MIN and MAX, they MUST have priority

That's no problem, I'll change the behaviour to this :)

Share this post


Link to post
Share on other sites
9 hours ago, linuxgurugamer said:
15 hours ago, Tonka Crash said:

In the list of mods in the KSP-AVC window in the upper left corner it would be nice to continue to see out of date mods (based on KSP_VERSION) highlighted in yellow no matter how the COMPATIBLE_VERSION_OVERRIDE is set just to give some indication (if the user bothers to look) which mods were compiled against older versions of KSP. Like I said, it would be nice, but not essential

No.  See my comments about the MIN and MAX

Uhm...why not keep the highlighting (or set total different color) in the expandable mod list?

As soon as you start to cover a range of versions instead of an explicit verson number, you may install a mod which doesn't work and without any hints in any directions, you may not notice if you have installed a wrong version.

edit: just to be sure there are no misunderstandings (and it is easy to do^^), this is how it would look like:

Spoiler

EiyOMlO.png

In this case, EVE is not listed in the compatibility issues window but still highlighted in the expandable mod list. Maybe switch it to a different color (blue-ish?) to have a separation from mods which have an update available but I actually like the idea :)

edit2:
little update :)

What's working so far:

  • Version override, respects version min/max
  • Keep highlighting in expandable mod list (waiting for some feedback)
  • .version file entry can disable version override for a specific mod
  • ignore override for mod name (configurable in the avc.cfg)

to do:

  • override priority
  • maybe some refractoring of the override code, I'm not very satisfied so far, even though it's working fine
Edited by 4x4cheesecake

Share this post


Link to post
Share on other sites
3 hours ago, 4x4cheesecake said:

Uhm...why not keep the highlighting (or set total different color) in the expandable mod list?

As soon as you start to cover a range of versions instead of an explicit verson number, you may install a mod which doesn't work and without any hints in any directions, you may not notice if you have installed a wrong version.

That's fine

Share this post


Link to post
Share on other sites

I've got a feature request for KSP-AVC: Would it be possible to add an optional config token to specify the minimum interval between online checks?  The specific use case I have is:

I have AVC installed in my development KSP installation so that I can be sure that I keep mods up to date, but I sometimes launch KSP a dozen or more times in short order when I'm doing development work.  I'd like to suppress the repeated checks - if the mods were up to date 15 minutes ago, they're probably still up to date.

What I had in mind was something like a "MinimumUpdateFrequency" token that specifies the number of hours that need to elapse before AVC will go ping online to check.  A value of 0 means "every time", which would also be the default.  A larger number means "If I've checked in the last N hours, I don't need to check this time".

Admittedly, this is a corner case, but it'd be nice to cut down the overhead for restarting KSP when in an iterative development phase.

Share this post


Link to post
Share on other sites
9 minutes ago, MOARdV said:

Admittedly, this is a corner case, but it'd be nice to cut down the overhead for restarting KSP when in an iterative development phase.

I second this use case. I have to run ZeroMiniAVC in my dev install because of this. I can see having a 12hr or 24hr check (or even user settable) as being very helpful.

Share this post


Link to post
Share on other sites
31 minutes ago, MOARdV said:

What I had in mind was something like a "MinimumUpdateFrequency" token that specifies the number of hours that need to elapse before AVC will go ping online to check.  A value of 0 means "every time", which would also be the default.  A larger number means "If I've checked in the last N hours, I don't need to check this time".

Sounds reasonable to me and I have an idea how this can be added easily (and it would be much more fun than creating an UI :o). Since I'm already working on some changes for AVC I could add this feature as well but I'll wait for a response from @linuxgurugamer ;)

21 minutes ago, Stone Blue said:

I second this use case. I have to run ZeroMiniAVC in my dev install because of this. I can see having a 12hr or 24hr check (or even user settable) as being very helpful.

ZeroMiniAVC just affects MiniAVC, right? MiniAVC doesn't have a config file, it doesn't even include the code to read the config from AVC. So, adding this feature to MiniAVC, would make it less mini and more AVC.
I didn't add the "Override Compatibility" feature in MiniAVC so far for the same reason. I think, it is supposed to be "mini" and just perform a simple version check, nothing else.

Share this post


Link to post
Share on other sites
31 minutes ago, 4x4cheesecake said:

ZeroMiniAVC just affects MiniAVC, right? MiniAVC doesn't have a config file, it doesn't even include the code to read the config from AVC. So, adding this feature to MiniAVC, would make it less mini and more AVC.
I didn't add the "Override Compatibility" feature in MiniAVC so far for the same reason. I think, it is supposed to be "mini" and just perform a simple version check, nothing else.

Yes, just MiniAVC... but the point still stands. I prefer full AVC for my play installs, over mini. But I dont install full AVC in my dev install, due to the same reason MOARdV brings up...
I mentioned Mini, because it comes packaged with lots of mods... but causes me the same grief as if I had full AVC installed in my dev install.

i LIKE MiniAVC and full AVC, and the method that they are meant to be used in, as far as general users go. I dont mind, even prefer full AVC in my play installs... but the use case for having them in a dev install, which I manually, and quite often check for updates on my own, is quite an annoyance when a dev install gets restarted quite often.

Right now, having AVC or MiniAVC in a dev install is "all or none"... you either deal with the annoyance, or dont have it installed at all... a nice compromise would be to have a check such as MOARdV proposes.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.