Gotmachine

[1.2.2] UpgradesGUI v1.5 - Upgrades info and selection in VAB/SPH part tooltips

Recommended Posts

Upgrades GUI

This plugin is a collections of interface tweaks aimed at making the part/module upgrades feature introduced in 1.2 more user-friendly. Note that the plugin doesn't add any upgrades. If you want to have them in your game you need to download other mods that implement the upgrade feature.

screenshot

VAB/SPH part tooltips show upgraded stats

  • The part stats are now updated according to unlocked upgrades.
  • The part cost is now updated according to unlocked upgrades.
  • All module widgets now show the updated stats according to unlocked upgrades.
  • The part upgrade module widget show the detail of part stats/cost modifiers.
  • If "showUpgradesInModuleInfo" (stock field) is set to true the upgrade config, the module widget now show the details of every upgrade currently unlocked for this module
  • Some QOL tweaks to the tooltip stats : dry mass, mention of multi-mode engines, better formatting of engines thrust/ISP
  • (bonus feature) Non-stock modules using cost/mass modifiers should have their modifiers taken into account too.

Upgrades selection

  • This allow to customize which upgrades are applied to placed parts in all modes (Career, Science and Sandbox)
  • Parts with upgrades now have a clickable "upgrade widget" in the tooltip widget list
  • Clicking on the widget show a list of upgrade widgets that can be toggled to enable/disable upgrades for this part
  • Upgrades exclusivity/overrides rules and R&D unlock status can't be bypassed
  • Vessels with customized upgrades will work perfectly if the plugin is removed, all this is done within the stock upgrade implementation.

R&D tech tree feature

  • In the nodes part list, upgrades have a pale green background to better differentiate them from parts.

Download & source

Soon to be available on CKAN !

LATEST RELEASE and source from github.

Disclaimer

I'm far from a skilled programmer, so the code for this may be ugly. As far as I know, it does the job and doesn't break the game. However, keep in mind that I don't really know what I'm doing. If anybody has the time to review and comment my code, I'm open to suggestions and pull requests :)

KSP-AVC disclaimer

This mod doesn't include mini-AVC, but it has a version file that allow version checking trough the KSP-AVC Plugin.

Licensing

This masterful work of art is released under the unlicense. So public domain, feel free to do anything, especially updating this plugin if I'm not around.

Changelog and bugs

Known bugs and glitches

  • None at the moment

v1.5 for KSP 1.2.2 - 19/04/2017

  • (Issue #5 fix) : NRE when PartStats{} node is absent from PartStatsUpgradeModule bug
  • (Issue #4 fix) : ModuleDataTransmitter (and others) doesn't revert to base stats bug
  • (Issue #3 fix) : Incorrect state of upgrades at init bug

v1.4 for KSP 1.2.2 - 18/04/2017

  • New feature : upgrade selection system
  • Refactored a lot of things
  • Re-fixed nullref on creating the upgraded parts prefab (thanks @Oort for the perfect bug report)
  • Removed mini-AVC dll, KSP-AVC is still supported
  • Changed plugin name to "UpgradesGUI"

v1.3 for KSP 1.2.2 - 28/03/2017

  • Fixed an issue causing an exception within the GameDatabase, this resolve the issue with toolbar icons disappearance (Thanks @Rodger)
  • The module widget list in the part tooltip is now sorted alphabetically (this reproduce the stock behaviour)

v1.2 for KSP 1.2.2 - 24/03/2017

  • The "custom prefabs" parts now try to call OnLoad() on their modules, with the HighLogic.LoadedScene set to LOADING, in an effort to better replicate what happens with the real part prefabs. This fix the issue with Kerbalism custom modules, and may prevent the same kind of error from surfacing in other plugins. Thanks @ShotgunNinja for guidance on what was happening.
  • Added some error-checking so if things go wrong, the plugin should fail a bit more gracefully.

v1.1 for KSP 1.2.2 - 23/03/2017

  • Added KSP-AVC support for version checking

v1.0 for KSP 1.2.2 - 22/03/2017

  • Initial release
Edited by Gotmachine
  • Like 19

Share this post


Link to post
Share on other sites

heads up Kerbalism users, this causes an NRE to fire when you hover over pods with crew capability. Notified ShotgunNinja of the issue

  • Like 1

Share this post


Link to post
Share on other sites

I can't investigate right now, but this is most likely an issue on my side (I'm doing shady things in this one). This said, the NRE are probably harmless beside messing up the tootip module text.

Will fix that as soon as possible, thanks for the report.

  • Like 1

Share this post


Link to post
Share on other sites

Just released version 1.2 with a fix for the problem that was causing NRE with Kerbalism :

v1.2 for KSP 1.2.2 - 24/03/2017

  • The "custom prefabs" parts now try to call OnLoad() on their modules, with the HighLogic.LoadedScene set to LOADING, in an effort to better replicate what happens with the real part prefabs. This fix the issue with Kerbalism custom modules, and may prevent the same kind of error from surfacing in other plugins. Thanks @ShotgunNinja for guidance on what was happening.
  • Added some error-checking so if things go wrong, the plugin should fail a bit more gracefully.

Hopefully things should go smoother with this one.

  • Like 5

Share this post


Link to post
Share on other sites

Nice idea for a mod, should really be stock!

But when I tried it, it stopped any of the buttons in the stock and blizzy toolbars from loading in the VAB for me. I removed just this mod and the buttons all showed up again.

  • Like 1

Share this post


Link to post
Share on other sites

@Rodger I can't reproduce the issue, tried with a few plugins that add a toolbar icon in the VAB : RCSBuildAid, SmartStage, TransferWindowPlanner and LightsOut, they all show up with or without blizzy Toolbar installed.

Could you please put your KSP.log file on pastebin after a launch the game > go to the vab > quit the game session ?

  • Like 1

Share this post


Link to post
Share on other sites
13 hours ago, Gotmachine said:

@Rodger I can't reproduce the issue, tried with a few plugins that add a toolbar icon in the VAB : RCSBuildAid, SmartStage, TransferWindowPlanner and LightsOut, they all show up with or without blizzy Toolbar installed.

Could you please put your KSP.log file on pastebin after a launch the game > go to the vab > quit the game session ?

Logs were too big for pastebin, but here's my ksp log and player log https://www.dropbox.com/sh/gbvc6miuv2ka9pz/AADXF3Ghl7spquBKmDWSalyHa?dl=0
 

  • Like 1

Share this post


Link to post
Share on other sites

@Rodger Thanks for the logs, I still can't reproduce (that's a rather heavily modded install, a combination of part-plugin is triggering this), but I think I know what is happening. I'm doing something very likely to fail in corner-case situations and I probably need to find a more robust way of doing it, but in the meantime I may be able to prevent this issue with a little more error checking.

Could you try replacing the GameData\UpgradesUIExtensions\UpgradesUIExtensions.dll with this updated one, see if the toolbar icons show up and send me back the log (even if it they show up, there might still is a silent error that may cause trouble) ? Thanks a lot.

  • Like 1

Share this post


Link to post
Share on other sites

Finally found a much simpler, better and robust solution, so here is the "official" fix :

v1.3 for KSP 1.2.2 - 28/03/2017

  • Fixed an issue causing an exception within the GameDatabase, this resolve the issue with toolbar icons disappearance (Thanks @Rodger)
  • The module widget list in the part tooltip is now sorted alphabetically (this reproduce the stock behavior)
  • Like 3

Share this post


Link to post
Share on other sites

1.3 works for me too :)

And had an idea for a QOL feature - an EC/s/ton display for solar panels?

  • Like 1

Share this post


Link to post
Share on other sites
On 29/03/2017 at 4:42 AM, Rodger said:

And had an idea for a QOL feature - an EC/s/ton display for solar panels?

That's a bit specific but I will look into it. Maybe I could also add the dry mass ratio for resource holders (parts having nothing else than a resource, so fuel tanks mostly) : dry mass / resource capacity.

For now I'm trying to add a big feature : give the ability to player to select which upgrades will be activated (among unlocked ones) on part placement. This would work by having an "upgrade list" with the same layout as the current module list in the part tootip. This is a screenshot of what I have in mind :

draft%20interface%20upgrade%20selection.

  • The first upgrade (in grey) is disabled because it has been overwritten by a latter one
  • The second upgrade (in green) is currently activated. The player can click it to disable it (it would turn yellow), this would cause the first upgrade to become the activated upgrade.
  • The third upgrade (in red) isn't researched yet.
  • Not shown in the screenshot, a yellow upgrade (disabled by the player) can be clicked on to re-enable it.
  • The tooltip part/module info is updated dynamically as updates are enabled/disabled by the player.
  • The "Upgrades" button on top is a toggle to switch between the normal module list and the upgrades list.
  • The first green toggle is showing that all unlocked upgrades for this part are enabled. If the player do a custom upgrade selection, it would turn grey. If the player click it while it is grey, all unlocked upgrades become activated for this part (the upgrade status for this part is reset)
  • The second green toggle works in the same way as the first, but is for ALL parts.
  • On part placement in the VAB/SPH, the placed part get the same upgrade status as defined in the tooltip.

I'm currently testing that all this can be done within the stock upgrade system, to ensure that this system is fully compatible with stock and other plugins. I've got most of the upgrade selection code working, but there are a few things that I need to validate, and the hijacking of the stock GUI is causing me some trouble, so this is far from done.

  • Like 5

Share this post


Link to post
Share on other sites

Is any of this compatible with DangIt?? It would be great to have that such that one of the things you could upgrade is the reliability of components. 

Share this post


Link to post
Share on other sites
39 minutes ago, Calvin_Maclure said:

Is any of this compatible with DangIt?? It would be great to have that such that one of the things you could upgrade is the reliability of components. 

Upgrades is a stock feature introduced in 1.2 and is compatible with both stock and custom modules from plugins. I'm only providing a better user interface for this stock feature, in an effort to promote its usage in various mods. Like you, I think upgrades would be nice to have not only for DangIt, but also for a lot of other mods.

This said, it is perfectly possible to set up upgrades for DangIt Reliability modules, but you need to ask @linuxgurugamer for this, or if you know how to do modulemanager patches, you can do that yourself. You can find some information on the upgrade configs in these posts :

If you want to see some examples, I know that M.O.L.E by @Angel-125 use the feature quite heavily :

 

Edited by Gotmachine
  • Like 3

Share this post


Link to post
Share on other sites

For the the most courageous (or foolish) among those using this plugin, here is a prerelease with the upgrade selection feature in action :

V1.4-PRE1 for KSP 1.2.2

WARNING : this is a very little tested version that may have bugs and mess up your game.

New feature : upgrades selection

  • This allow to customize which upgrades are applied to placed parts in all modes (Career, Science and Sandbox)
  • Parts with upgrades now have a clickable "upgrade widget" at the top of the tooltip widget list
  • Clicking on the widget show a list of upgrade widgets that can be toggled to enable/disable upgrades for this part
  • Upgrades exclusivity/overrides rules and R&D unlock status can't be bypassed (no cheating / unintended usage)
  • Vessels with customized upgrades will work perfectly if the plugin is removed, all this is done within the stock upgrade implementation.

Please report any bug or glitch you may encounter. Feeback and comments are appreciated too !

  • Like 2

Share this post


Link to post
Share on other sites

I ran into the disappearing VAB menu bug as well. Drove me nuts these past few days trying to pin point what was causing it as I'm running heavily modded (just got a new computer and wanted to see what it could handle).

When I put in the .dll that is first suggested the bug goes away and I get the VAB menu icons back. But if I download and install the new V1.3 update then I lose the VAB menus again. I only didn't try the V1.4 because its a test version and I didn't want to risk running into something else wonky.

Here is the log file with the menu missing (using the V1.3 download)

No VAB Menu Buttons

Here is the log file with the specific .dll overwriting the V1.3 .dll

Has VAB menu buttons

There is a very large difference in the two file sizes that i find strange. The only thing that I can think of that might have caused that is that when I did the first one I went into the alt-f12 menu and checked the dump log file box, but I immediately unchecked it. I didn't do that with the second one. I'm a bit new to this kind of stuff so apologize if I didn't do this right.

Oh, I'd taken out nearly all the 100+ mods I'd been using as well. The only mods in the GameData folder during these log generations are

000_Filter Extensions
000_Filter Extensions Config
000_Toolbar
000_USITools
Quick Mods (for exit and start)
UpgradesUIExtensions V1.3

 

 

 

  • Like 1

Share this post


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

I ran into the disappearing VAB menu bug as well. Drove me nuts [...]

Sorry for that, and thanks for the detailed bug report. I did something dumb (again) in the 1.3 code.

This should be fixed in the final 1.4 release (see OP for details).

  • Like 2

Share this post


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

Sorry for that, and thanks for the detailed bug report. I did something dumb (again) in the 1.3 code.

This should be fixed in the final 1.4 release (see OP for details).

Not a problem! I'm just glad it wasn't me doing something silly which is what 90% of the problems I run into end up being, lol. Thanks for a great mod and am looking forward to your newest update!

  • Like 1

Share this post


Link to post
Share on other sites

@WarezcrawlerThe NRE is caused by the fact that your PartStats {} node is commented in your PartStatsUpgradeModule :

Spoiler

    MODULE
    {
        name = PartStatsUpgradeModule
        showUpgradesInModuleInfo = true
        UPGRADES
        {
            UPGRADE
            {
                name__ = Communotron32
                techRequired__ = basicScience
                IsAdditiveUpgrade__ = True    
                //PartStats {}
            }
            UPGRADE
            {
                name__ = Communotron64
                techRequired__ = precisionEngineering
                IsAdditiveUpgrade__ = True    
                //PartStats {}
            }
        }
    }

This cause the node property to be null, triggering the null reference exception when I try to access it. I will fix this in next version with a check so this case is handled properly.

Meanwhile I suggest that (since you do nothing with it) you remove the whole PartStatsUpgradeModule (this way you wont get an useless empty part stats module in the module list), or at least uncomment the PartStats {} in your patch.

To further talk about your patch :

  • The PARTUPGRADE{} nodes are defined inside the part. They won't be recognized and this will cause the UPGRADE{} nodes to be "untracked", a situation that should be avoided. PARTUPGRADE{} nodes MUST be defined as top-level nodes (like PART{} nodes). I suggest that you define them in a separate file, something like "UpgradesDefinitions.cfg".
  • In UPGRADE{} nodes, the "techRequired__" isn't needed, I suggest that you remove it to avoid confusion. This field is only useful in the above case ("untracked" upgrades), as a fallback so the game know where to put the UPGRADE{} in the tech tree when there is no corresponding PARTUPGRADE{}.

Here is a corrected patch (with some cost modifiers in the PartStatsUpgradeModule) :

Spoiler

// longAntenna - Communotron 16
@PART[longAntenna]:FOR[GTI]
{
    @MODULE[ModuleDataTransmitter]
    {
        //antennaPower = 500000
        showUpgradesInModuleInfo = true
        UPGRADES
        {
            UPGRADE
            {
                name__ = Communotron32
                description__ = Antenna power increased by a factor 10
                antennaPower = 5000000
                packetInterval = 0.4
                packetSize = 4
                packetResourceCost = 11.0
            }
            UPGRADE
            {
                name__ = Communotron64
                description__ = Antenna power increased by a factor 100
                antennaPower = 50000000
                packetInterval = 0.4
                packetSize = 8
                packetResourceCost = 10.0
            }
        }
    }
    MODULE
    {
        name = PartStatsUpgradeModule
        showUpgradesInModuleInfo = true
        UPGRADES
        {
            UPGRADE
            {
                name__ = Communotron32
                PartStats
                {
                    cost = 100
                }
            }
            UPGRADE
            {
                name__ = Communotron64
                PartStats
                {
                    cost = 200
                }
            }
        }
    }
}

PARTUPGRADE
{
    name = Communotron32
    partIcon = longAntenna
    techRequired = basicScience
    entryCost = 10000
    title = Communotron 32
    description = Improoved technoligy have led to factor 10 improovements on the good old Communotron 16.
}
PARTUPGRADE
{
    name = Communotron64
    partIcon = longAntenna
    techRequired = precisionEngineering
    entryCost = 10000
    title = Communotron 64
    description = Improoved technoligy have led to factor 100 improovements on the good old Communotron 16.
}

// SurfAntenna - Communotron 16-S
@PART[SurfAntenna]:FOR[GTI]
{
    @MODULE[ModuleDataTransmitter]
    {
        @antennaPower = 250000
    }
}
// longAntenna - Communotron 16
//@PART[longAntenna]:FOR[GTI]
//{
// NO CHANGE
//}

// HighGainAntenna5 - HG-5 High Gain Antenna
@PART[HighGainAntenna5]:FOR[GTI]
{
    @MODULE[ModuleDataTransmitter]
    {
        @antennaPower = 15000000
    }
}

// RelayAntenna5 +50 + 100 - Relay Antenna
@PART[RelayAntenna5,RelayAntenna50,RelayAntenna100]:FOR[GTI]
{
    @MODULE[ModuleDataTransmitter]
    {
        @antennaPower *= 2
    }
}

I've found a few other issues in the current release by testing things with your patch. So thanks you !

  • Like 2

Share this post


Link to post
Share on other sites
32 minutes ago, Gotmachine said:

@WarezcrawlerThe NRE is caused by the fact that your PartStats {} node is commented in your PartStatsUpgradeModule :

  Reveal hidden contents

    MODULE
    {
        name = PartStatsUpgradeModule
        showUpgradesInModuleInfo = true
        UPGRADES
        {
            UPGRADE
            {
                name__ = Communotron32
                techRequired__ = basicScience
                IsAdditiveUpgrade__ = True    
                //PartStats {}
            }
            UPGRADE
            {
                name__ = Communotron64
                techRequired__ = precisionEngineering
                IsAdditiveUpgrade__ = True    
                //PartStats {}
            }
        }
    }

This cause the node property to be null, triggering the null reference exception when I try to access it. I will fix this in next version with a check so this case is handled properly.

Meanwhile I suggest that (since you do nothing with it) you remove the whole PartStatsUpgradeModule (this way you wont get an useless empty part stats module in the module list), or at least uncomment the PartStats {} in your patch.

To further talk about your patch :

  • The PARTUPGRADE{} nodes are defined inside the part. They won't be recognized and this will cause the UPGRADE{} nodes to be "untracked", a situation that should be avoided. PARTUPGRADE{} nodes MUST be defined as top-level nodes (like PART{} nodes). I suggest that you define them in a separate file, something like "UpgradesDefinitions.cfg".
  • In UPGRADE{} nodes, the "techRequired__" isn't needed, I suggest that you remove it to avoid confusion. This field is only useful in the above case ("untracked" upgrades), as a fallback so the game know where to put the UPGRADE{} in the tech tree when there is no corresponding PARTUPGRADE{}.

Here is a corrected patch (with some cost modifiers in the PartStatsUpgradeModule) :

  Reveal hidden contents

// longAntenna - Communotron 16
@PART[longAntenna]:FOR[GTI]
{
    @MODULE[ModuleDataTransmitter]
    {
        //antennaPower = 500000
        showUpgradesInModuleInfo = true
        UPGRADES
        {
            UPGRADE
            {
                name__ = Communotron32
                description__ = Antenna power increased by a factor 10
                antennaPower = 5000000
                packetInterval = 0.4
                packetSize = 4
                packetResourceCost = 11.0
            }
            UPGRADE
            {
                name__ = Communotron64
                description__ = Antenna power increased by a factor 100
                antennaPower = 50000000
                packetInterval = 0.4
                packetSize = 8
                packetResourceCost = 10.0
            }
        }
    }
    MODULE
    {
        name = PartStatsUpgradeModule
        showUpgradesInModuleInfo = true
        UPGRADES
        {
            UPGRADE
            {
                name__ = Communotron32
                PartStats
                {
                    cost = 100
                }
            }
            UPGRADE
            {
                name__ = Communotron64
                PartStats
                {
                    cost = 200
                }
            }
        }
    }
}

PARTUPGRADE
{
    name = Communotron32
    partIcon = longAntenna
    techRequired = basicScience
    entryCost = 10000
    title = Communotron 32
    description = Improoved technoligy have led to factor 10 improovements on the good old Communotron 16.
}
PARTUPGRADE
{
    name = Communotron64
    partIcon = longAntenna
    techRequired = precisionEngineering
    entryCost = 10000
    title = Communotron 64
    description = Improoved technoligy have led to factor 100 improovements on the good old Communotron 16.
}

// SurfAntenna - Communotron 16-S
@PART[SurfAntenna]:FOR[GTI]
{
    @MODULE[ModuleDataTransmitter]
    {
        @antennaPower = 250000
    }
}
// longAntenna - Communotron 16
//@PART[longAntenna]:FOR[GTI]
//{
// NO CHANGE
//}

// HighGainAntenna5 - HG-5 High Gain Antenna
@PART[HighGainAntenna5]:FOR[GTI]
{
    @MODULE[ModuleDataTransmitter]
    {
        @antennaPower = 15000000
    }
}

// RelayAntenna5 +50 + 100 - Relay Antenna
@PART[RelayAntenna5,RelayAntenna50,RelayAntenna100]:FOR[GTI]
{
    @MODULE[ModuleDataTransmitter]
    {
        @antennaPower *= 2
    }
}

I've found a few other issues in the current release by testing things with your patch. So thanks you !

Thank you so much for your response. I had a had time understanding all the elements of the upgrade system from the patch notes. But I do think your description clears up a bunch of stuff on that front :cool:

Do you have any good (other) examples on the upgrade system in action? I have not really found anything yet, and that was why I started trying it out blind....

  • Like 1

Share this post


Link to post
Share on other sites

@Warezcrawler I agree, the upgrade configs are a bit hard to get right. The JPLRepo interventions in this post are very useful to understand the PartStatsUpgradeModule :

Other than that, you can take a look at how upgrades are used in the Porkjet partial rocket parts overhaul which use upgrades for the engines (but beware there are some errors in the configs)

  • Like 3

Share this post


Link to post
Share on other sites

Just released version 1.5 with important bugfixes (upgrade selection feature was severly broken in 1.4, sorry to all).

Also take note that I changed the mod name to UpgradesGUI. It will appear soon on CKAN under this name, and the "Upgrades UI Extensions" entry on ckan will be removed.

v1.5 for KSP 1.2.2 - 19/04/2017

  • (Issue #5 fix) : NRE when PartStats{} node is absent from PartStatsUpgradeModule bug
  • (Issue #4 fix) : ModuleDataTransmitter (and others) doesn't revert to base stats bug
  • (Issue #3 fix) : Incorrect state of upgrades at init bug
  • Like 3

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now