[1.4.1] ScrapYard - The Common Part Inventory - 1.1.0.107 (2018-03-18)

[magico13]

@BlueTiger12 I'm going to have to keep looking into this further but it's definitely easy to reproduce. I'm currently trying to track down the exact part of ScrapYard that is triggering it and then I'll either change something in ScrapYard or I'll make a pull request for AGX. My current guesses are that it's due to ScrapYard saving out all of the modules since it seems to be when converting the ship into a list of InventoryParts, and that seems to be triggering a lot of part changed events that is making AGX freak out. A fix within AGX might be to have it only respond to one of the part changed events each frame (or one every second even) as that's an issue I've run into with KCT and with ScrapYard in the past. I might even be able to reproduce those lag spikes with just AGX and nothing else.

 

Edit: Alright, the good news is that I think I know why this is happening. The bad news is that I can't think of a good way to fix it right now. When ScrapYard turns a part into an inventory part it saves all of the modules on the part into a ConfigNode, basically it just converts it to structured text. AGX has extra processing it does when its module gets converted to a ConfigNode and that extra processing is what's causing all the extra time to be taken when AGX is installed. I was going to try to avoid even saving modules if there aren't any Module Templates that might match by just checking the names, except that there's a default Module Template that matches all names that is used for modules with upgrades. So I can't make it easier by only checking names and I can't check anything else in a generic way unless I save the node. A real catch-22 situation. I'll keep trying stuff out.

Edit 2: Slightly better news: I made it way faster when you aren't using any parts from the inventory on the ship, but as soon as you start using inventory parts it'll slow down again as it does more detailed checks. I'll keep thinking about the problem and I'll let you know if I come up with any other solutions.

Edited March 9, 2018 by magico13

[magico13]

I've been doing a lot of work lately on getting this ready for release and would like to time 1.0 with the release of Making History. The UI in the editor has been one of my main focuses, as well as trying to tie into the stock part id mechanics. The good news is that older saves should still be compatible since converting from the old system to the new one is pretty simple to do, though I have noticed that application of an inventory item doesn't always stick correctly so you're still advised to clear out your inventory when upgrading. Additionally I've removed the smaller UI in the editor in favor of keeping everything in a singular main UI (except the modules window, which is still separate). That UI now groups like parts together, is vertically resizeable, prevents parts from being dropped or deleted when clicked on, and responds to whatever part is currently right-clicked. It's kind of cool because you can put the window directly over the bottom part list and can click it with a part in your hand and not accidentally delete the part, though that only works if the list isn't really long. Now I'm going to be working on making the modules window fully resizeable and cleaning things up a bit, but as of right now I don't see why I wouldn't release 1.0 the same day as the expansion.

[magico13]

I know I said I'd release ScrapYard today, but I got caught up in trying to finish one last feature before release and I haven't gotten time to test everything again, so I'm pushing it to the 14th (tomorrow) just to give me time for that. The good news is that there's a new pre-release and that it's the release candidate. If everything goes well then I'll release build 100 tomorrow as 1.0.0!

If you're curious what that last feature is, it's ContractConfigurator support. I'll have more details on it tomorrow, but as of this release you can create contracts that add or remove parts from the inventory as part of accepting/completing/failing a contract. This could be used to give parts as a reward for contract completion, or as part of an enhanced part test contract (we give you an experimental part unlock and 5 parts),, or something I haven't even thought of. I plan on adding a parameter for having certain parts with a certain amount of uses but I didn't have time yet. If you've got an idea of a contract but you're not sure that ScrapYard has the support for it yet, let me know and I can see about adding it.

Here's a really basic test contract that gives three of the long 1.25m tanks, two of which are tweakscaled up to 2.5m, at contract acceptance and removes them when the contract is finished:

Spoiler

// ContractConfiguration sample file

// Each CONTRACT_TYPE node represents a type of contract that can be offered
CONTRACT_TYPE
{
    // Unique name of the contract type (required)
    name = SampleContract

    // Contract text details
    title = Simple Test Contract
    description = A more detailed description of the contract.
    synopsis = We want you to do a thing.
    completedMessage = You have done the thing.



    // Contract rewards
    rewardScience = 0.0
    rewardReputation = 0.0
    rewardFunds = 1.0
    failureReputation = 0.0
    failureFunds = 0.0
    advanceFunds = 0.0

    // The PARAMETER node defines a contract parameter.  The following parameter
    // displays all the fields that are supported for a parameter across all
    // types.  See the Parameters page for examples of all supported parameters.
    PARAMETER
    {
        name = HasAstronaut
        type = HasAstronaut

        // The type of trait required.
        //
        // Type:      string
        // Required:  No
        // Values (for stock KSP):
        //     Pilot
        //     Engineer
        //     Scientist
        trait = Pilot
    }
    
    BEHAVIOUR
    {
        name = ChangeInventoryParts
        type = ChangeInventoryParts
        
        PARTS
        {
            adding = True //optional, default True
        
            condition = ACCEPTED //required
            //Options are:
            //SUCCEEDED
            //FAILED
            //FINISHED (completed or failed)
            //ACCEPTED
            //CANCELLED
            //EXPIRED
            INVENTORY_PART
            {
                name = fuelTank.long //required
                timesRecovered = 0 //optional, default 0 when adding, -1 (meaning any amount) when removing
                count = 2 //optional, default 1
                MODULES //semi-required, default none (must contain the MODULEs that the ScrapYard.InventoryPart's node contains or it will be interpreted as a different part)
                {
                    MODULE //an example
                    {
                        name = TweakScale
                        isEnabled = True
                        currentScale = 2.5
                        defaultScale = 1.25
                        defaultTransformScale = (1.25, 1.25, 1.25)
                        DryCost = 3462.3999
                        stagingEnabled = True
                        EVENTS
                        {
                        }
                        ACTIONS
                        {
                        }
                        UPGRADESAPPLIED
                        {
                        }
                    }
                }
            }
            INVENTORY_PART
            {
                name = fuelTank.long //required
                timesRecovered = 0 //optional, default 0 when adding, -1 (meaning any amount) when removing
                count = 1 //optional, default 1
            }
        }
        
        PARTS
        {
            adding = False //optional, default True
        
            condition = FINISHED //required
            //Options are:
            //SUCCEEDED
            //FAILED
            //FINISHED (completed or failed)
            //ACCEPTED
            //CANCELLED
            //EXPIRED
            INVENTORY_PART
            {
                name = fuelTank.long //required
                timesRecovered = -1 //optional, default 0 when adding, -1 (meaning any amount) when removing
                count = 2 //optional, default 1
                MODULES //semi-required, default none (must contain the MODULEs that the ScrapYard.InventoryPart's node contains or it will be interpreted as a different part)
                {
                    MODULE //an example
                    {
                        name = TweakScale
                        isEnabled = True
                        currentScale = 2.5
                        defaultScale = 1.25
                        defaultTransformScale = (1.25, 1.25, 1.25)
                        DryCost = 3462.3999
                        stagingEnabled = True
                        EVENTS
                        {
                        }
                        ACTIONS
                        {
                        }
                        UPGRADESAPPLIED
                        {
                        }
                    }
                }
            }
            INVENTORY_PART
            {
                name = fuelTank.long //required
                count = 1 //optional, default 1
            }
        }
    }
}

 

 

Edited March 14, 2018 by magico13

[severedsolo]

Is the release candidate compiled against 1.4.1? If so, you may have a problem

Can provide a log if you really need one but it's dead easy to reproduce: Just open Mission Control on a new Career game and then close it again.

[magico13]

Probably related to the debug logging setting I added since that's the only thing I can think of that would result in an NRE inside the logging function. Try build 100 and see if that works instead.

Edited March 14, 2018 by magico13

[severedsolo]

1 hour ago, magico13 said:

Probably related to the debug logging setting I added since that's the only thing I can think of that would result in an NRE inside the logging function. Try build 100 and see if that works instead.

Yup that did the trick. Cheers

[OwariTY]

Hello. I am sorry for mi english, is so difficult. In the title i see 1.3.1, but some people use your mod in 1.4.1. ¿you recommend me that or wait a update? I 

Edited March 14, 2018 by OwariTY

[KerbalBob]

Thx for the SR Update now scrapyard is giving me issues, rendering KCT not functioning.  Both of them together worked fine for a day then when I try to launch to add a new build to the list, it doesnt work nor does it give me data on how long it will take, usually by adding parts it increased, but now it stays to 0, if I disable scrapyard KCT works fine.

[magico13]

2 hours ago, Owari said:

Hello. I am sorry for mi english, is so difficult. In the title i see 1.3.1, but some people use your mod in 1.4.1. ¿you recommend me that or wait a update? I 

There is an update out now that I would recommend using.

1 hour ago, KerbalBob said:

Thx for the SR Update now scrapyard is giving me issues, rendering KCT not functioning.  Both of them together worked fine for a day then when I try to launch to add a new build to the list, it doesnt work nor does it give me data on how long it will take, usually by adding parts it increased, but now it stays to 0, if I disable scrapyard KCT works fine.

Make sure to grab the absolute latest versions of ScrapYard, StageRecovery, and KCT. For KCT that means grabbing it from the build server here: http://magico13.net:8080/job/Kerbal Construction Time Beta/

 

1.0 is out! But I still need to take more pictures and do a bit more documentation. It is now available on SpaceDock and I clicked the button to have it be added to CKAN, but that may be a few days. Assuming there's nothing game-breaking, I'm going to swap over to KCT and hopefully have that ready in the next few days. Let me know if you find any bugs!

[HebaruSan]

27 minutes ago, magico13 said:

I clicked the button to have it be added to CKAN, but that may be a few days.

Hi, I'm looking at how to handle this. The OP says this mod is used by KCT, but currently it's separate from KCT. Should we mark a dependency or a conflict between the two?

[magico13]

1 minute ago, HebaruSan said:

Hi, I'm looking at how to handle this. The OP says this mod is used by KCT, but currently it's separate from KCT. Should we mark a dependency or a conflict between the two?

KCT will add it as a recommend. There is no hard dependency between the two.

[theonegalen]

Congratulations on your Spacedock release! You've come a long way from where you started, and it has been great to see and benefit from all your hard work.

[Xenophon Muravyov]

Anyone know a way to get FMRS to work with ScrapYard/ KCT? (RP-1 / 1.3.1)

I can recover the part funds and everything, but they never go into my inventory

[magico13]

3 minutes ago, Xenophon Muravyov said:

Anyone know a way to get FMRS to work with ScrapYard/ KCT? (RP-1 / 1.3.1)

I can recover the part funds and everything, but they never go into my inventory

You'd have to not use the auto-recover feature of FMRS and would have to recover the vessels manually after you return to the main save's timeline. I haven't tested that though.

[severedsolo]

Any idea why scrapyards OnGUI would be throwing an NRE if using the development version of Unity but not the retail version? (is that the right term? The one that lets you use the built in VS Debugging tools, from this thread)It's making it very difficult to debug UPFM. If not, I'll try compiling from source later and see if I can figure it out.

Edited March 16, 2018 by severedsolo

[magico13]

5 hours ago, severedsolo said:

Any idea why scrapyards OnGUI would be throwing an NRE if using the development version of Unity but not the retail version? (is that the right term? The one that lets you use the built in VS Debugging tools, from this thread)It's making it very difficult to debug UPFM. If not, I'll try compiling from source later and see if I can figure it out.

I haven't updated my local Unity to allow debugging since the update so I haven't tried it. I'll do that tonight since it makes it way easier to work on things.

[severedsolo]

*removed because it's definitely a KCT bug and posted there instead*

Edited March 17, 2018 by severedsolo

[magico13]

Small update to 1.0.1.104 to address some issues that came up during additional testing and while updating KCT. If you're using KCT at all, you must upgrade to this ScrapYard release since the API had a breaking bug in a method that KCT relies on.

 

On 3/16/2018 at 2:27 AM, severedsolo said:

Any idea why scrapyards OnGUI would be throwing an NRE if using the development version of Unity but not the retail version? (is that the right term? The one that lets you use the built in VS Debugging tools, from this thread)It's making it very difficult to debug UPFM. If not, I'll try compiling from source later and see if I can figure it out.

 

20 hours ago, severedsolo said:

*removed because it's definitely a KCT bug and posted there instead*

These two issues are now fixed in the 1.0.1.104 release.

 

Edit: There's going to be another release on Sunday to fix a few more issues I've found when updating KCT. They're fairly edge-case, but they're easily reproducible in those cases (mostly with editing existing ships in KCT).

Edited March 18, 2018 by magico13

[OwariTY]

For some reason i am losing money. When i land, KSP uses the normal system, and i need buy again the part. Only The Command Module and parachute cost: 1010. Recovery: 986.  Anywey, the log: https://drive.google.com/open?id=1D6dXoj7vsbhViwg2_NJQ6MFFcuc4Vrqt

 

Edited March 18, 2018 by OwariTY
add image and information

[magico13]

8 hours ago, Owari said:

For some reason i am losing money. When i land, KSP uses the normal system, and i need buy again the part. Only The Command Module and parachute cost: 1010. Recovery: 986.

That's normal KSP behavior. Look at the window that pops up when you recover. It says you're only going to get 97.6% back and 1010x0.976 = 986. The only way to recover something at 100% is to recover it from the launch pad or the runway, even recovering it from any other building in the KSC only gives you 98%

[BlueTiger12]

On 08/03/2018 at 5:16 AM, magico13 said:

@BlueTiger12 I'm going to have to keep looking into this further but it's definitely easy to reproduce. I'm currently trying to track down the exact part of ScrapYard that is triggering it and then I'll either change something in ScrapYard or I'll make a pull request for AGX. My current guesses are that it's due to ScrapYard saving out all of the modules since it seems to be when converting the ship into a list of InventoryParts, and that seems to be triggering a lot of part changed events that is making AGX freak out. A fix within AGX might be to have it only respond to one of the part changed events each frame (or one every second even) as that's an issue I've run into with KCT and with ScrapYard in the past. I might even be able to reproduce those lag spikes with just AGX and nothing else.

 

Edit: Alright, the good news is that I think I know why this is happening. The bad news is that I can't think of a good way to fix it right now. When ScrapYard turns a part into an inventory part it saves all of the modules on the part into a ConfigNode, basically it just converts it to structured text. AGX has extra processing it does when its module gets converted to a ConfigNode and that extra processing is what's causing all the extra time to be taken when AGX is installed. I was going to try to avoid even saving modules if there aren't any Module Templates that might match by just checking the names, except that there's a default Module Template that matches all names that is used for modules with upgrades. So I can't make it easier by only checking names and I can't check anything else in a generic way unless I save the node. A real catch-22 situation. I'll keep trying stuff out.

Edit 2: Slightly better news: I made it way faster when you aren't using any parts from the inventory on the ship, but as soon as you start using inventory parts it'll slow down again as it does more detailed checks. I'll keep thinking about the problem and I'll let you know if I come up with any other solutions.

Sorry for my late reply. At first, thanks for your description and updates :-)

If i understand you correctly, i can avoid this problem by switching auto-apply of and only applying the inventory before i start the build, with your new sollution?

Also this sounds more like AGX would need some optimization while saving.

[magico13]

51 minutes ago, BlueTiger12 said:

If i understand you correctly, i can avoid this problem by switching auto-apply of and only applying the inventory before i start the build, with your new sollution?

Also this sounds more like AGX would need some optimization while saving.

Correct, if you wait to apply the inventory until you're ready to launch/build then you shouldn't really notice any lag until then. It doesn't do any of the module saving stuff until you've got inventory parts applied, so it should bypass the slow downs. I'm not sure what AGX can do to reduce lag on their side since they need to save that data, but it probably has some room for optimization. It's only a problem now because ScrapYard makes it save fairly frequently instead of once.

[BlueTiger12]

5 hours ago, magico13 said:

Correct, if you wait to apply the inventory until you're ready to launch/build then you shouldn't really notice any lag until then. It doesn't do any of the module saving stuff until you've got inventory parts applied, so it should bypass the slow downs. I'm not sure what AGX can do to reduce lag on their side since they need to save that data, but it probably has some room for optimization. It's only a problem now because ScrapYard makes it save fairly frequently instead of once.

Is this incorporated in any scrapyard build that is working in ksp 1.3.1 together with upfm? (i remember that for some time upfm should only be used with build 72 of scrapyard)

[magico13]

5 hours ago, BlueTiger12 said:

Is this incorporated in any scrapyard build that is working in ksp 1.3.1 together with upfm? (i remember that for some time upfm should only be used with build 72 of scrapyard)

Unfortunately the full set of improvements are only in 1.4.1 builds, but build 82 (the last one for 1.3.1) should have some noticeable improvements in editor times over build 72 and will work with the 1.3.1 version of upfm.

 

Version 1.1.0.107 released. Mostly bug fixes and a new event that's needed for KCT to update its build times properly when you apply to parts.

Edited March 19, 2018 by magico13

[severedsolo]

21 hours ago, BlueTiger12 said:

Is this incorporated in any scrapyard build that is working in ksp 1.3.1 together with upfm? (i remember that for some time upfm should only be used with build 72 of scrapyard)

Build 82 should fix the issues that UPFM was having.