Jump to content

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


linuxgurugamer

Recommended Posts

****** New BETA *******

This is a major update to provide an override capability to tell AVC that certain mods and version should be considered compatible.

Thanks to @4x4cheesecake for doing 98% of the work.

https://github.com/linuxgurugamer/KSPAddonVersionChecker/releases/tag/1.3.0

This is a BETA, I need feedback, please

Link to comment
Share on other sites

14 hours ago, linuxgurugamer said:

I need feedback, please

I've noticed two issues regarding the new default toggles:

1) The toggle doesn't become enabled after adding one of the default values manually. Just type in "1.4.*" and you will see ;)

2) The reset button doesn't affect the new toggles. The version is actually removed but the toggle stays enabled.

I guess, part of the issue is the initialisation of the toggle states during the Start method so if anything else changes the compatibility state, the toggles are not updated.

Link to comment
Share on other sites

13 minutes ago, 4x4cheesecake said:

I've noticed two issues regarding the new default toggles:

1) The toggle doesn't become enabled after adding one of the default values manually. Just type in "1.4.*" and you will see ;)

2) The reset button doesn't affect the new toggles. The version is actually removed but the toggle stays enabled.

I guess, part of the issue is the initialisation of the toggle states during the Start method so if anything else changes the compatibility state, the toggles are not updated.

Thanks.  Shouldn't be that difficult to fix.

Link to comment
Share on other sites

On the first launch of the latest beta (LGG 1.3.0) I was seeing a very noticeable lag toggling the buttons for the compat version overrides. The game went bye-bye for a couple seconds. After a while it seemed settle down and on reloads it was fine.

Why were these extra buttons added in the right panel? Was it to dumb down the interface for people that can't read? Unless I missed a beta today is the first time I saw them. (To be honest I rarely read the directions either, and I mostly tuned out of this thread after a page discussing gui button placement)

I was thrown for a loop that I was presented with 1.3.* as an option since none of my mods should have been compiled against 1.3. More specifically I nearly had a panic attack that some ancient crud had sneaked into my install because I was presented with misleading information from this beta.

Turns out a couple of my mods have VERSION_MIN 1.3.1. Using Version Min/Max to populate this field isn't as useful as sticking with KSP_VERSION. Overall I see no point to using Version_Min/Version_Max in the Compatiiblity Override menus at all. I would tend to think users that get that far into KSP-AVC will have an above average idea how mod compatibility should work and getting misleading information is frustrating.

In the center panel I am presented a list of Incompatible Addons for KSP versions that don't exist 1.4.999, 1.5.99. This is not useful information to me. What would be useful to me is know what version of KSP each mod was compiled against. As a minimum I think capping the versions to what was actually published by Squad would be better (1.4.5, 1.5.1) and present a more realistic picture.

Personally I don't think the what I want to see is going to come out of this new effort. LGG has made it clear he wants everything based on VERSION_MIN and VERSION_MAX which I think is 100% wrong when it comes to these compatibility overrides. 

In this area I want to really see how old my mods are. Not whatever the mod author put in to avoid needing to update the version file every KSP release. Since I can use wildcard to cover every patch version of a minor release the Version Min and Version Max aren't even really needed to hide the nag messages anymore. 

So in the end it's not as useful as I think it could be, but it works to hide the nag messages at game launch, so ship it.

Link to comment
Share on other sites

I set the MinTimeBetweenAvcRuns field to a non-zero value in my dev install.  When I do so, and then restart the game before the next scheduled update, the button that would bring up the override window has red text that says "Wait for AVC processing...".  However, it looks like that won't happen when the AVC network check is skipped.

Since the MinTime feature is not part of normal player activity and it's not accessible through the GUI, it's probably okay to leave as-is. I wanted to bring it up in case it's not intended, or if it could lead to problems if local overrides were enabled (I don't have any out-of-date mods in my dev install to test against).

Link to comment
Share on other sites

9 minutes ago, MOARdV said:

I set the MinTimeBetweenAvcRuns field to a non-zero value in my dev install.  When I do so, and then restart the game before the next scheduled update, the button that would bring up the override window has red text that says "Wait for AVC processing...".  However, it looks like that won't happen when the AVC network check is skipped.

Uhm...the actual bug here is, that the dropdown list shouldn't be there in this case. I thought, I fixed that issue already...

Out of curiousity: Does the dropdown list appear while the frequency is set to -1?

Link to comment
Share on other sites

19 minutes ago, 4x4cheesecake said:

Out of curiousity: Does the dropdown list appear while the frequency is set to -1?

Yes.  I see "AVC disabled" in the center-top, but the AVC drop-down is still accessible.

Link to comment
Share on other sites

3 hours ago, Tonka Crash said:

Why were these extra buttons added in the right panel? Was it to dumb down the interface for people that can't read? Unless I missed a beta today is the first time I saw them. (To be honest I rarely read the directions either, and I mostly tuned out of this thread after a page discussing gui button placement)

This was done on stream with people making suggestions and commenting on what was seen.

3 hours ago, Tonka Crash said:

This is not useful information to me. What would be useful to me is know what version of KSP each mod was compiled against

That's not possible.  AVC doesn't look into the mod, it looks at the .version file.  And that, in many cases, does not reflect which version the mod was compiled against.  Many mods which are compiled for 1.6.1 also work fine when used in 1.5.1 and 1.4.5, and the other way as well.

3 hours ago, Tonka Crash said:

I was thrown for a loop that I was presented with 1.3.* as an option since none of my mods should have been compiled against 1.3. More specifically I nearly had a panic attack that some ancient crud had sneaked into my install because I was presented with misleading information from this beta.

Documentation on this is not complete.  But, those toggles are there merely to make it easier for users to use.  They don't have to be used.

 

3 hours ago, Tonka Crash said:

In the center panel I am presented a list of Incompatible Addons for KSP versions that don't exist 1.4.999, 1.5.99

That is coming directly out of the .version file in each mod.

 

3 hours ago, Tonka Crash said:

LGG has made it clear he wants everything based on VERSION_MIN and VERSION_MAX which I think is 100% wrong when it comes to these compatibility overrides.

No, what I want is that VERSION_MIN and VERSION_MAX have priority over VERSION.  If the Min & Max are missing, all that's left is the version.  Again, this depends entirely on the mod author. 

Link to comment
Share on other sites

@linuxgurugamer I understand exactly how KSP-AVC uses the .version file and that the .version file is only as good as the info put into by the mod author. I just happen to disagree with how you are choosing to use that information for the the compatible version override feature.

Thinking about this what would satisfy my case is another new option (STRICT_VERSION = true, defaults to false) to eliminate use of VERSION_MIN and VERSION_MAX and only rely on KSP_VERSION. If that isn't possible or you don't want to do it, so be it.

Link to comment
Share on other sites

32 minutes ago, Tonka Crash said:

@linuxgurugamer I understand exactly how KSP-AVC uses the .version file and that the .version file is only as good as the info put into by the mod author. I just happen to disagree with how you are choosing to use that information for the the compatible version override feature.

Thinking about this what would satisfy my case is another new option (STRICT_VERSION = true, defaults to false) to eliminate use of VERSION_MIN and VERSION_MAX and only rely on KSP_VERSION. If that isn't possible or you don't want to do it, so be it.

First, would the "STRICT_VERSION" be added to .version files by the mod author?  or would this be some overall setting?  

Because if a mod author wanted that, all they would need to do is not have the Min or Max settings

Second, what if there isn't a basic VERSION?

Link to comment
Share on other sites

3 minutes ago, linuxgurugamer said:

First, would the "STRICT_VERSION" be added to .version files by the mod author?  or would this be some overall setting?  

Because if a mod author wanted that, all they would need to do is not have the Min or Max settings

Second, what if there isn't a basic VERSION?

It would be in the KSP-AVC.cfg for me (the player) to control and not something a mod author would set. If STRICT_VERSION is true KSP_VERSION is used and VERSION_MIN/MAX are ignored. If KSP_VERSION does not exist in a .version file then it becomes 0.0 for that mod which would stand out as not compatible.

Link to comment
Share on other sites

Just now, Tonka Crash said:

It would be in the KSP-AVC.cfg for me (the player) to control and not something a mod author would set. If STRICT_VERSION is true KSP_VERSION is used and VERSION_MIN/MAX are ignored. If KSP_VERSION does not exist in a .version file then it becomes 0.0 for that mod which would stand out as not compatible.

I'm not against this option; but a number of mods are removing the KSP_VERSION entirely and just leaving the MIN or MIN/MAX versions.

 

Link to comment
Share on other sites

8 hours ago, 4x4cheesecake said:

2) The reset button doesn't affect the new toggles. The version is actually removed but the toggle stays enabled.

This is fixed

 

8 hours ago, 4x4cheesecake said:

1) The toggle doesn't become enabled after adding one of the default values manually. Just type in "1.4.*" and you will see ;)

and so is this

I'll be pushing another beta soon

Link to comment
Share on other sites

1 hour ago, Tonka Crash said:

It would be in the KSP-AVC.cfg for me (the player) to control and not something a mod author would set. If STRICT_VERSION is true KSP_VERSION is used and VERSION_MIN/MAX are ignored. If KSP_VERSION does not exist in a .version file then it becomes 0.0 for that mod which would stand out as not compatible

This will be in the next beta

Link to comment
Share on other sites

New beta, 1.3.0.1

  • Fixed reset button not clearing toggles
  • Fixed toggle not becoming enabled after entering value manually
  • Fixed issue when MinTimeBetweenAvcRuns > 0, the dropdown list was being shown when it wasn't supposed to
  • Added new field in config file:  STRICT_VERSION, if set true, then the Min and Max versions are ignored.

https://github.com/linuxgurugamer/KSPAddonVersionChecker/releases/tag/1.3.0.1

Link to comment
Share on other sites

9 hours ago, linuxgurugamer said:

Added new field in config file:  STRICT_VERSION, if set true, then the Min and Max versions are ignored.

As a modder, this feature concerns me.  I set MIN to the known-minimum version that a given build should support.  I set MAX to indicate the highest version (or projected highest version, eg 99) that a build will work against.  I do *not* set VERSION to the current version of KSP - especially with the more frequent (these days) cases where I do not have to rebuild every mod for every single patch release.  This feature strikes me as opening the window for a mod support headache -

"This mod is compatible with version 1.6.0.  When is it going to be updated?"

"max version is 1.6.99 - it still works."

"But it says VERSION = 1.6.0.  When is it going to be recompiled for 1.6.1?"

I sincerely hope that's not how this feature is going to be used.

Link to comment
Share on other sites

In the beta zip file there is a GameData\KSP-AVC\AVC.cfg file that doesn't seem to be used. Am I overlooking something or should this be deleted in the release version?

When it KSP-AVC runs for the first time it creates it's config file GameData\KSP-AVC\PluginData\AVC.cfg which doesn't exist initially. From a player perspective two .cfg files of the same name in two different directories is confusing.

Link to comment
Share on other sites

1 hour ago, Tonka Crash said:

In the beta zip file there is a GameData\KSP-AVC\AVC.cfg file that doesn't seem to be used. Am I overlooking something or should this be deleted in the release version?

When it KSP-AVC runs for the first time it creates it's config file GameData\KSP-AVC\PluginData\AVC.cfg which doesn't exist initially. From a player perspective two .cfg files of the same name in two different directories is confusing.

It should be removed in the release

Link to comment
Share on other sites

Ok, my first impressions of 1.3.0.1...

1) Always Compatable - I like it... This seems especially suited to parts only mods, which are moar rarely affected by KSP updates (usually due to Unity upgrades)

2) As *both* a user and a wannabe modder, I *LIKE* that VERSION_MIN/_MAX are shown and considered. While it *is* nice to know exactly what version of KSP a mod was compiled against, for archival/time reference, its generally *NOT* very useful at all. Especially for mods that dont even have dlls to be compiled. Rathere than using a STRICT version, of such short-lived KSP versions, such as 1.1.1, 1.1.2, 1.4.2, 1.4.3., 1.5.0, 1.6.0, etc ... tells us nothing substantial, except that the mod *might/should* be compatable with the later, longer-lived (final) KSP versions such as 1.0.5, 1.2.2, 1.3.1, 1.4.5, 1.5.1, 1.6.1 ... but not as definitively as if the dev adheres to using _MIN/_MAX... and using those gives that much moar reassurance and definitey (is that a word?) straight from the mod dev's mouth *EXACTLY* what versions they saying something works with, and in so doing, what they should be willing to support.
It also eliminates a whole percentage of guesswork for users... *at least those that can READ...* ... Imagine how many moar posts and pesterings there would/will be asking if things are compatable between specific patch versions, even from those who *can* read, and are willing to investigate before posting, if _MIN/_MAX are not shown or taken into account?

3) Arrow buttons to right in center, Incompatable Mod section... I guess I dont see the point in these, the way they are setup... vOv
They currently seem to do the same exact thing as the radial buttons in the Compatable Version Override section... especially for *every* other mod, that is the *same* version or *later*... I would rather rather (and would expect) it would toggle each mod individually for an override... Also, kinda weird, toggling a 1.3.x mod, seems to only affect pre-1.4.0 mods, ignoring all post-1.4.0 KSP versions, yet toggling a single 1.4.0 mod, toggles *ALL* mods for *ALL* post 1.4.0 versions... vOv

Also, toggling a mod that shows _MAX, toggles everything greater, but misses what should be included STRICT versions... ie toggling a visible 1.4.99, does *NOT* toggle a 1.4.0, 1.4.1, ... 1.4.5 STRICT version... So I'm gueesing _MIN is not considered at all? granted, I have a limited number of mods, as this is in my dev install, and not my typical play install, which may include ~100-200 mods, so my testing data is limited :P

Since toggling one of these arrow buttons, enables the override for *all* other mods with a greater version, (basically which you can do with the buttons in the Override section, then i would rather see these arrow buttons in the center section, *EXCLUDE*, or override the override enabled, for the specific mod...
ie what if you have 10 mods that *are* ok to override from 1.4.0 to 1.6.1 ... but you have that one mod, that will *not* work in 1.6.1? How do you easily, in the UI, disabled just that specific mod from the general override you've just enabled?

I am also seeing inconsistent orrides being applied using these buttons, that should/should not be enabling/disabling the version overrides... Hard to explain... I'll have to add moar AVC-supported mods over wider range of KSP versions to get a handle on the weirdness I'm seeing...

4) Version Override section ... Currently showing version numbers strictly how they are selected and toggled... ie a line each for 1.4.99 -> 1.6.1, 1.4.0 -> 1.6.1, 1.4.5 -> 1.6.1, etc... Would it be too difficult to add some code that could could do live comparison, and combine the _MIN/_MAX/_STRICT versions, into a *single* line where applicable, that would basically cover the _MIN/_MAX range... even when only implied, where any of the three fields are not present?

Also, when added, the displayed entries are not displayed numerically in order... nor even in order of when they are selected... vOv

I guess thats enuff of a wall of text for now... I may have moar to add later :P



 

Link to comment
Share on other sites

3 hours ago, MOARdV said:

As a modder, this feature concerns me.  I set MIN to the known-minimum version that a given build should support.  I set MAX to indicate the highest version (or projected highest version, eg 99) that a build will work against.  I do *not* set VERSION to the current version of KSP - especially with the more frequent (these days) cases where I do not have to rebuild every mod for every single patch release.  This feature strikes me as opening the window for a mod support headache -

"This mod is compatible with version 1.6.0.  When is it going to be updated?"

"max version is 1.6.99 - it still works."

"But it says VERSION = 1.6.0.  When is it going to be recompiled for 1.6.1?"

I sincerely hope that's not how this feature is going to be used.

It was put in by request of @Tonka Crash, and is experimental.  I am not sure whether it will stay or not, looking for feedback.

Speaking of which, thank you

Link to comment
Share on other sites

4 minutes ago, linuxgurugamer said:

It was put in by request of @Tonka Crash, and is experimental.  I am not sure whether it will stay or not, looking for feedback...

Yup... I'm not saying STRICT shouldnt be displayed, or discounted, its moar that I dont agree with _MAX not being displayed or _MIN/_MAX considered... ;)

Link to comment
Share on other sites

6 minutes ago, linuxgurugamer said:

It was put in by request of @Tonka Crash, and is experimental.  I am not sure whether it will stay or not, looking for feedback.

Speaking of which, thank you

For those that are concerned STRICT_VERSION would cause problems, my first suggestion is don't document it beyond the discussion on this page and don't include a line setting it to false in the AVC.CFG file. Odds are those that would freak out and pester mods for newly compiled mods wouldn't know how to turn it on anyway. Since it should default to off if undefined, it shouldn't affect anyone that doesn't explicitly turn it on. And if you're going to turn it on you probably have a better idea about how mod compatibility works than a noob asking "Does this work in 1.6.1?"

To be honest I grabbed a version of the source with STRICT_VERSION working like I want, so if it goes away as an option I'll just have to compile it locally. It would be inconvenient, but no worse than the dozen other mods I compile locally when I wanted to change their behavior. 

Link to comment
Share on other sites

1 hour ago, Tonka Crash said:

For those that are concerned STRICT_VERSION would cause problems, my first suggestion is don't document it beyond the discussion on this page and don't include a line setting it to false in the AVC.CFG file. Odds are those that would freak out and pester mods for newly compiled mods wouldn't know how to turn it on anyway. Since it should default to off if undefined, it shouldn't affect anyone that doesn't explicitly turn it on. And if you're going to turn it on you probably have a better idea about how mod compatibility works than a noob asking "Does this work in 1.6.1?"

To be honest I grabbed a version of the source with STRICT_VERSION working like I want, so if it goes away as an option I'll just have to compile it locally. It would be inconvenient, but no worse than the dozen other mods I compile locally when I wanted to change their behavior. 

I think what I'll do is to leave it, but to put #if/#endif around the 4 lines, so that it won't be compiled in a final release.  

My question for you is, is it doing what you expected?  In my testing, I was rather unhappy with what it was displaying, the output had no relevance to the actual mods

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

×
×
  • Create New...