[1.8.0] KSP-AVC Add-on Version Checker Plugin - MiniAVC-V2 Now available

[linuxgurugamer]

Important update now available for KSP-AVC

New version of MiniAVC now available: MiniAVC-V2

 

Forum user @cybutek has left this most important mod orphaned, so I've adopted it and fixed some of the outstanding bugs.  Original thread is here: https://forum.kerbalspaceprogram.com/index.php?/topic/72169-*

This version only works in KSP 1.8.1 and later

The Mini-AVC-V2 dll is available at the same site as the full KSP-AVC mod

Links

Download: https://github.com/linuxgurugamer/KSPAddonVersionChecker/releases

Source: https://github.com/linuxgurugamer/KSPAddonVersionChecker

Online Changelog:  https://raw.githubusercontent.com/linuxgurugamer/KSPAddonVersionChecker/master/ChangeLog.txt

Available on CKAN

License:  GPLv3

 

https://www.patreon.com/linuxgurugamer
 

FOR DEVELOPERS...

Have a question or require some help? Leave a message in this thread or PM me.

If you wish your add-on to have KSP-AVC support even if the player does not have the KSP-AVC Plugin installed, you may use MiniAVC-V2. Just bundle the .dll in with your mod and version files. Because of the bundled nature, the player will be given the option to allow update checking on the first run. If the player does disable update checking, it will continue to run in local mode assessing game version compatibility. MiniAVC-V2 will always run from the most up-to-date version which has been bundled with any of the installed add-ons. If a player has KSP-AVC Plugin installed, MiniAVC-V2 will automatically be disabled to allow the KSP-AVC Plugin to run.

For more information read the online readme file.

 

Please note that if hosting a version file yourself, it must be encoded in UTF-8 without a Byte-Order Mark.

The source code and project is part of the same repository on GitHub as KSP-AVC Plugin.

Licensed under GNU General Public License v3

Additionally

This software searches through only the KSP GameData directory and subfolders.

This software contacts the internet to check if add-ons have newer versions available. Data is only read from the internet and no personal information is sent.

This software has the ability to open up a browser window to what is set in the DOWNLOAD field of the remote version file.

All remote destinations set in version files are up to the respective add-on developers and I hold no responsibility for how these features are used.

 

Edited June 28, 2020 by linuxgurugamer

[leatherneck6017]

Fantastic! Thanks for adopting another important mod.

[t12213roy]

Awesome, and thanks for updating this as well as your time in dealing with my issue over the weekend.

[magico13]

Quote

Disabled the remote overriding local if the versions were identical

Say there's a situation where the local config has a KSP version of 1.4.0 but the mod still works fine on 1.4.1. The mod author doesn't want to push a new release but also doesn't want the nagging "wrong version" pop ups to occur, so they update the remote config to use a range of KSP 1.4.0 to KSP 1.4.1 to hopefully fix all the players being nagged each startup. Does this mean that the mod author cannot do this and instead MUST release a new version just for updating the .version file?

Edited March 28, 2018 by magico13

[linuxgurugamer]

9 hours ago, magico13 said:

Say there's a situation where the local config has a KSP version of 1.4.0 but the mod still works fine on 1.4.1. The mod author doesn't want to push a new release but also doesn't want the nagging "wrong version" pop ups to occur, so they update the remote config to use a range of KSP 1.4.0 to KSP 1.4.1 to hopefully fix all the players being nagged each startup. Does this mean that the mod author cannot do this and instead MUST release a new version just for updating the .version file?

You know, this is why I released a beta, and contacted a lot of the major mod authors via PM, including yourself.  And NO ONE BOTHERED TO GIVE FEEDBACK, except for two regular users.

It was something I had done during testing, and forgot to remove, but I put it in the notes as I do all changes.

I'll get it updated in a few minutes

[Jebs_SY]

Everything has 2 sides... for me that "remote before local" feature also was annoying sometimes... when I had an older mod installed on a newer KSP, and I knew after testing, that it works, I edited my local version file to update for that and take this into account and remove the nag screen but stay with the possibility to receive an update when a new version comes out. In some cases this has simply not worked and with the information now I assume, that I continued to get a nag screen because AVC used the remote file, which the author didn't updated and my local change wasn't taken into account...
So an active author can push our a release but an inactive author can not update the remote .version file and the user stays with nag screens forever (or removed whole AVC functionality by deleting the version file).
So in the end I think both solution have up- and downsides... well, I am fine with both. o/

Edited March 28, 2018 by Jebs_SY

[magico13]

1 hour ago, linuxgurugamer said:

You know, this is why I released a beta, and contacted a lot of the major mod authors via PM, including yourself.  And NO ONE BOTHERED TO GIVE FEEDBACK, except for two regular users.

It was something I had done during testing, and forgot to remove, but I put it in the notes as I do all changes.

I'll get it updated in a few minutes

Sorry, I just decided to read through what bugs you had fixed after you posted the release, saw that comment and then thought of that situation. I honestly haven't used KSP-AVC in years (other than the mini-avc bugging me every time I start up my current game) so I wasn't even sure what it would do before and just wanted to know if that situation was correct. Personally I don't care which one takes priority, like what @Jebs_SY said both ways have their advantages and disadvantages so as long as it's documented I'm fine with either way.

Even though I don't use this, I am thankful that you put in the time and effort to update it.

Edited March 28, 2018 by magico13

[linuxgurugamer]

9 hours ago, magico13 said:

Sorry, I just decided to read through what bugs you had fixed after you posted the release, saw that comment and then thought of that situation. I honestly haven't used KSP-AVC in years (other than the mini-avc bugging me every time I start up my current game) so I wasn't even sure what it would do before and just wanted to know if that situation was correct. Personally I don't care which one takes priority, like what @Jebs_SY said both ways have their advantages and disadvantages so as long as it's documented I'm fine with either way.

Even though I don't use this, I am thankful that you put in the time and effort to update it.

Thank you for looking at it, it was just a bit frustrating that none of the people this was aimed at took the time to look at it.

I restored it to preserve the same functionality as before

Anyway, I'm thinking about adding a setting to make this optional.  What I'm thinking of is to add a new optional parameter in the file which would say something like (one of the following):

"LOCAL_HAS_PRIORITY": true

"LOCAL_HAS_PRIORITY": false

"REMOTE_HAS_PRIORITY": true

"REMOTE_HAS_PRIORITY": false

I would assume that most if not all authors would not include this, but it would be there for people who make local changes to override the normal behaviour.  While I can add an option to the KSP-AVC code, that wouldn't be effective if the MiniAVC is being used, this would handle that.

Comments?

Edited March 28, 2018 by linuxgurugamer

[magico13]

I like it. Remote has authority by default, but local has the ability to override that, which puts the power back in the user's hands.

An issue I thought of with my original hypothetical was CKAN. CKAN doesn't check the remote (as far as I'm aware) so it wouldn't be notified of the compatibility being updated so the mod author would have to make a new release anyway or change the ckan metadata. That's partly why I always use the min/max versions and specify an entire 1.x release, which it sounds like you've seriously improved in this avc release, so that's definitely welcomed. So whether remote has priority or not, if the author is using the version file for ckan then they have to update, so that setting doesn't matter to them.

Edited March 28, 2018 by magico13

[Jebs_SY]

9 hours ago, linuxgurugamer said:

I would assume that most if not all authors would not include this, but it would be there for people who make local changes to override the normal behaviour.  While I can add an option to the KSP-AVC code, that wouldn't be effective if the MiniAVC is being used, this would handle that. Comments?

Hello,
the thing I would fear is that a motivated author decides, to take this decision for the user and includes "remote has priority" in the online / server version and then maybe at some time loses motivation and then it's abandoned.
I like the idea, but to be on the safe side, could you implement it that way, that these values only be taken into account when read from the local side? And ignored when read on the remote side.
BR
JebsSY

[linuxgurugamer]

It wouldn't make sense to listen to the remote for this setting.

 The whole idea behind the setting is to allow uses to override the remote.

[TDplay]

Hooray, a working AVC version for 1.4.1! Thanks, linuxgurugamer! (can I abbreviate it to LGG or would that offend you)

[linuxgurugamer]

20 hours ago, TDplay said:

Hooray, a working AVC version for 1.4.1! Thanks, linuxgurugamer! (can I abbreviate it to LGG or would that offend you)

LGG is fine, but if you want to ping me, you need the whole thing:  @linuxgurugamer

[Jesusthebird]

On 3/28/2018 at 7:53 AM, linuxgurugamer said:

Thank you for looking at it, it was just a bit frustrating that none of the people this was aimed at took the time to look at it.

I restored it to preserve the same functionality as before

Anyway, I'm thinking about adding a setting to make this optional.  What I'm thinking of is to add a new optional parameter in the file which would say something like (one of the following):

"LOCAL_HAS_PRIORITY": true

"LOCAL_HAS_PRIORITY": false

"REMOTE_HAS_PRIORITY": true

"REMOTE_HAS_PRIORITY": false

I would assume that most if not all authors would not include this, but it would be there for people who make local changes to override the normal behaviour.  While I can add an option to the KSP-AVC code, that wouldn't be effective if the MiniAVC is being used, this would handle that.

Comments?

I like this idea, can I keep the train going?

If devs happen to not include this in the version cfg, would it be treated as a global parameter? or would the user have to add the lines of text themselves?

Could there be a way have a kind of generated on start 'list/cfg' that we could edit to enable/disable that option on a per mod basis? shoutout to the people with 250+ mods installed  

ive been starting to tinker with the 'ksp mod admin' program which is pretty neat and lightweight, I know it has avc integration of some kind, but I havnt gotten to that yet..If a lot of people would prefer to keep avc "as is" that may be an alternative to to the nagging issue with out of date mods that arnt really out of date. I think you can edit the update url and some other stuff, but I dont know much about it.

Edited March 31, 2018 by Jesusthebird

[linuxgurugamer]

More thoughts, I'm getting closer to implementation:

First, the following would only apply to the full KSP-AVC mod

A config file in the KSP-AVC directory would have the ability to override all mods.  The config file would contain a single value, one of the following:

"LOCAL_HAS_OVERRIDE_PRIORITY": true 

"LOCAL_HAS_OVERRIDE_PRIORITY": false 

"REMOTE_HAS_OVERRIDE_PRIORITY": true 

"REMOTE_HAS_OVERRIDE_PRIORITY": false


"LOCAL_HAS_SIMPLE_PRIORITY": true 

"LOCAL_HAS_SIMPLE_PRIORITY": false 

"REMOTE_HAS_SIMPLE_PRIORITY": true 

"REMOTE_HAS_SIMPLE_PRIORITY": false

The first four will have OVERRIDE authority; in other words, any of the first four lines will override anything in any of the .version files

SIMPLE priority would mean that 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

I'll provide a commented out config file with instructions.

 

[azander]

Why not at:

"PRIORITY": remote|local|none
"OVERRIDE": remove|local|none

with each defaulting to "none" if omitted?

[linuxgurugamer]

20 minutes ago, azander said:

Why not at:

"PRIORITY": remote|local|none
"OVERRIDE": remove|local|none

with each defaulting to "none" if omitted?

Not really a difference, except the coding involved.  But the default has to be the current behaviour, which means that the override will default to none,  and priority will default to remote

[Mark Kerbin]

Great work as usual @linuxgurugamer +1 Respect.

 

[linuxgurugamer]

Working on the final syntax now:

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

}

A new feature will be this:

// 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.4.3
	COMPATIBLE_VERSION_OVERRIDE = 1.4.1, 1.4.3
	COMPATIBLE_VERSION_OVERRIDE = 1.4.2, 1.4.3
}

 

 

[DStaal]

17 minutes ago, linuxgurugamer said:

A new feature will be this:

// 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.4.3
	COMPATIBLE_VERSION_OVERRIDE = 1.4.1, 1.4.3
	COMPATIBLE_VERSION_OVERRIDE = 1.4.2, 1.4.3
}

 

On one hand, I like the feature, as it will remove that huge list of mods at startup for me.    On the other hand - it's a bit blunt.  Those overrides for instance - 95+% of the time, they'll be right.  But there have been cases in the not so distant past where a few mods would break on a point upgrade, so that blanket statement wouldn't be correct.  I'm trying to think of a good 'except these mods' syntax, but I'm not sure what it would be.

[linuxgurugamer]

How about:

IGNORE_OVERRIDE = modname

And I can include a list of mods shich should be ignored.

[DStaal]

7 minutes ago, linuxgurugamer said:

How about:

IGNORE_OVERRIDE = modname

And I can include a list of mods shich should be ignored.

Sounds good to me.  Thanks.

[Freshmeat]

I know you got a _lot_ of work on your hands, but would it be possible to enable Mini-AVC to run without starting the game itself? I often find myself looking at the update message, thinking "Oh, thats right. I forgot to update" and then proceeds to forget all about it later on. The problem boils down to you only get the information about the update when you already have started the minutes-long process of starting the game, so you cannot react on the information straight ahead. When you shut down the game it is usually because you have to do something else.

I experimented with using CKAN just to get the information, but it will not check for mods it does not administrate, and I personally prefer to update mods by hand. Further, the program itself seemed quite lumbering when I ran it.

This suggestion is not something that should be sunk a lot of time in, I do not know how much work it takes to go from a .dll to an .exe.

[linuxgurugamer]

On 6/11/2018 at 6:25 AM, Freshmeat said:

I know you got a _lot_ of work on your hands, but would it be possible to enable Mini-AVC to run without starting the game itself? I often find myself looking at the update message, thinking "Oh, thats right. I forgot to update" and then proceeds to forget all about it later on. The problem boils down to you only get the information about the update when you already have started the minutes-long process of starting the game, so you cannot react on the information straight ahead. When you shut down the game it is usually because you have to do something else.

I experimented with using CKAN just to get the information, but it will not check for mods it does not administrate, and I personally prefer to update mods by hand. Further, the program itself seemed quite lumbering when I ran it.

This suggestion is not something that should be sunk a lot of time in, I do not know how much work it takes to go from a .dll to an .exe.

Sorry, more time than I want to invest.

Frankly, I'd suggest installing the full dll and if necessary exiting the program after it displays the complete list

[Gordon Dry]

@Freshmeat Yeah, kill process is your friend in this case.