linuxgurugamer 17,777 Posted March 27, 2018 Share Posted March 27, 2018 (edited) 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 Quote Link to post Share on other sites
leatherneck6017 257 Posted March 27, 2018 Share Posted March 27, 2018 Fantastic! Thanks for adopting another important mod. Quote Link to post Share on other sites
t12213roy 7 Posted March 28, 2018 Share Posted March 28, 2018 Awesome, and thanks for updating this as well as your time in dealing with my issue over the weekend. Quote Link to post Share on other sites
magico13 2,151 Posted March 28, 2018 Share Posted March 28, 2018 (edited) 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 Quote Link to post Share on other sites
linuxgurugamer 17,777 Posted March 28, 2018 Author Share Posted March 28, 2018 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 Quote Link to post Share on other sites
Jebs_SY 130 Posted March 28, 2018 Share Posted March 28, 2018 (edited) 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 Quote Link to post Share on other sites
magico13 2,151 Posted March 28, 2018 Share Posted March 28, 2018 (edited) 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 Quote Link to post Share on other sites
linuxgurugamer 17,777 Posted March 28, 2018 Author Share Posted March 28, 2018 (edited) 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 Quote Link to post Share on other sites
magico13 2,151 Posted March 28, 2018 Share Posted March 28, 2018 (edited) 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 Quote Link to post Share on other sites
Jebs_SY 130 Posted March 28, 2018 Share Posted March 28, 2018 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 Quote Link to post Share on other sites
linuxgurugamer 17,777 Posted March 28, 2018 Author Share Posted March 28, 2018 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. Quote Link to post Share on other sites
TDplay 59 Posted March 29, 2018 Share Posted March 29, 2018 Hooray, a working AVC version for 1.4.1! Thanks, linuxgurugamer! (can I abbreviate it to LGG or would that offend you) Quote Link to post Share on other sites
linuxgurugamer 17,777 Posted March 30, 2018 Author Share Posted March 30, 2018 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 Quote Link to post Share on other sites
Jesusthebird 144 Posted March 31, 2018 Share Posted March 31, 2018 (edited) 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 Quote Link to post Share on other sites
linuxgurugamer 17,777 Posted April 9, 2018 Author Share Posted April 9, 2018 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. Quote Link to post Share on other sites
azander 57 Posted April 19, 2018 Share Posted April 19, 2018 Why not at: "PRIORITY": remote|local|none "OVERRIDE": remove|local|none with each defaulting to "none" if omitted? Quote Link to post Share on other sites
linuxgurugamer 17,777 Posted April 19, 2018 Author Share Posted April 19, 2018 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 Quote Link to post Share on other sites
Mark Kerbin 420 Posted April 24, 2018 Share Posted April 24, 2018 Great work as usual @linuxgurugamer +1 Respect. Quote Link to post Share on other sites
linuxgurugamer 17,777 Posted June 5, 2018 Author Share Posted June 5, 2018 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 } Quote Link to post Share on other sites
DStaal 2,331 Posted June 5, 2018 Share Posted June 5, 2018 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. Quote Link to post Share on other sites
linuxgurugamer 17,777 Posted June 5, 2018 Author Share Posted June 5, 2018 How about: IGNORE_OVERRIDE = modname And I can include a list of mods shich should be ignored. Quote Link to post Share on other sites
DStaal 2,331 Posted June 5, 2018 Share Posted June 5, 2018 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. Quote Link to post Share on other sites
Freshmeat 405 Posted June 11, 2018 Share Posted June 11, 2018 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. Quote Link to post Share on other sites
linuxgurugamer 17,777 Posted June 15, 2018 Author Share Posted June 15, 2018 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 Quote Link to post Share on other sites
Gordon Dry 548 Posted June 16, 2018 Share Posted June 16, 2018 @Freshmeat Yeah, kill process is your friend in this case. Quote Link to post Share on other sites
Recommended Posts
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.