Jump to content

[1.8.x] ScrapYard - The Common Part Inventory 2.0 (07/12/2019)

severedsolo

By severedsolo
in KSP1 Mod Releases

 Share

Recommended Posts

Gordon Dry

Gordon Dry

Posted
Posted

FYI, two days ago I found a lot of these in my KSP 1.6.1 RSS RO RP-1install, I just quit and didn't launch KSP since then: 

Input is null for field 'avionicsConfigName' in config node ''
   at System.Environment.get_StackTrace()
   at ConfigNode.AddValue(System.String name, System.String value)
   at BaseFieldList.Save(.ConfigNode node)
   at PartModule.Save(.ConfigNode node)
   at ScrapYard.ModuleTemplateList.FindMatchingTemplate(System.String partName, .ConfigNode moduleNode)
   at ScrapYard.ModuleTemplateList.CheckForMatch(System.String partName, .ConfigNode moduleNode)
   at ScrapYard.InventoryPart.storeModuleNode(System.String partName, .ConfigNode moduleNode)
   at ScrapYard.InventoryPart.get_savedModules()
   at ScrapYard.InventoryPart.IsSameAs(ScrapYard.InventoryPart comparedPart, ComparisonStrength strictness)
   at ScrapYard.PartInventory+<>c__DisplayClass11_0.<FindPart>b__0(ScrapYard.InventoryPart ip)
   at System.Linq.Enumerable.First(IEnumerable`1 source, System.Func`2 predicate, Fallback fallback)
   at System.Linq.Enumerable.FirstOrDefault(IEnumerable`1 source, System.Func`2 predicate)
   at ScrapYard.PartInventory.FindPart(ScrapYard.InventoryPart part, ComparisonStrength strength)
   at ScrapYard.PartInventory.RemovePart(ScrapYard.InventoryPart part, ComparisonStrength strength)
   at ScrapYard.Utilities.InventoryManagement.ApplyInventoryToVessel(IEnumerable`1 input)
   at ScrapYard.ScrapYard.VerifyEditor()
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Input is null for field 'avionicsTechLevel' in config node ''
   at System.Environment.get_StackTrace()
   at ConfigNode.AddValue(System.String name, System.String value)
   at BaseFieldList.Save(.ConfigNode node)
   at PartModule.Save(.ConfigNode node)
   at ScrapYard.ModuleTemplateList.FindMatchingTemplate(System.String partName, .ConfigNode moduleNode)
   at ScrapYard.ModuleTemplateList.CheckForMatch(System.String partName, .ConfigNode moduleNode)
   at ScrapYard.InventoryPart.storeModuleNode(System.String partName, .ConfigNode moduleNode)
   at ScrapYard.InventoryPart.get_savedModules()
   at ScrapYard.InventoryPart.IsSameAs(ScrapYard.InventoryPart comparedPart, ComparisonStrength strictness)
   at ScrapYard.PartInventory+<>c__DisplayClass11_0.<FindPart>b__0(ScrapYard.InventoryPart ip)
   at System.Linq.Enumerable.First(IEnumerable`1 source, System.Func`2 predicate, Fallback fallback)
   at System.Linq.Enumerable.FirstOrDefault(IEnumerable`1 source, System.Func`2 predicate)
   at ScrapYard.PartInventory.FindPart(ScrapYard.InventoryPart part, ComparisonStrength strength)
   at ScrapYard.PartInventory.RemovePart(ScrapYard.InventoryPart part, ComparisonStrength strength)
   at ScrapYard.Utilities.InventoryManagement.ApplyInventoryToVessel(IEnumerable`1 input)
   at ScrapYard.ScrapYard.VerifyEditor()
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

Full log and stuff:
https://www.dropbox.com/s/wd48sy2pocbdhv9/output_log.txt and stuff 2019-06-23-01.zip?dl=1

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
2 hours ago, gap said:

@Starwaster @severedsolo 

Maybe I can add something. First off, the problem is not exactly ScrapYard refusing to appy the inventory to the Mk1 pod, but the inventory not getting applied automatically to the said part when the 'auto apply' function is checked, and the pod resetting to new whenever a change is made to the vessel it belongs to. That means that I am forced to apply the inventory to it manually, at the very end of the assembling process.

Secondly, I must admit that I have started using DeadlyReentries after starting my current career, and probably after building the pod that now I want to be applied automatically. Might that be the cause of my problem?
 

It is true, besides SY and DR, I have several other mods, but none that I can think of that would interfere with SY.
Starwaster, If you want to have a look into my mod list or you need more details on the issue I described above (including save game and logs), you can find them in the OhScrap thread starting from this post:

 

I'm not seeing anything in the logs that you posted that really implicates Deadly Reentry. I do see that any mention of ModuleAeroReentry is missing from your craft files and from your save files. Which would make sense if they predated your installation of Deadly Reentry, but then it means that those aren't files that reflect your current installation state so I don't think I can get any useful data out of them.

Link to comment
Share on other sites
severedsolo

severedsolo

Posted
  • Author
Posted
3 hours ago, gap said:

Secondly, I must admit that I have started using DeadlyReentries after starting my current career, and probably after building the pod that now I want to be applied automatically. Might that be the cause of my problem?

Unlikely. I just removed ModuleAeroReentry from the craft file in a test case (which is how your craft file was set up) and SY had no issues with reapplying the inventory, even after .

Honestly mate, at this point I'm stumped. My best guess is that something interrupted your craft saving and messed up that craft file. I've been trying for the last 4 hours to get SY and DRE to not play nice together, and I just can't do it. So I agree with Starwaster, it's not DRE, and it's not SY either.

The only bad interactions happen on that specific save/craft file of yours.

Link to comment
Share on other sites
gap

gap

Posted
Posted
42 minutes ago, Starwaster said:

I'm not seeing anything in the logs that you posted that really implicates Deadly Reentry. I do see that any mention of ModuleAeroReentry is missing from your craft files and from your save files. Which would make sense if they predated your installation of Deadly Reentry, but then it means that those aren't files that reflect your current installation state so I don't think I can get any useful data out of them.

 

33 minutes ago, severedsolo said:

Unlikely. I just removed ModuleAeroReentry from the craft file in a test case (which is how your craft file was set up) and SY had no issues with reapplying the inventory, even after .

Honestly mate, at this point I'm stumped. My best guess is that something interrupted your craft saving and messed up that craft file. I've been trying for the last 4 hours to get SY and DRE to not play nice together, and I just can't do it. So I agree with Starwaster, it's not DRE, and it's not SY either.

The only bad interactions happen on that specific save/craft file of yours.

Wait guys, maybe I know what's the problem. The main save game file dates to a few days ago, when DRE was installed, but I am sure that the craft files were saved before installing DRE (and several other mods), which might explain why they are messed uo and why SY malfunctions when dealing with them. I will try saving them again in the new mod environment (or I will re-assemble them from scratch ) and see if SY manages them correctly this time...

Thank you guys for your help and sorry for wasting your precious time!

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted (edited)

Ok @severedsolo so I just reproduced @gap 's problem on a new save. So I created a brand new minimum install with just KCT, SY, OS and their dependencies and made sure I couldn't reproduce it in just that environment. Then I put in Deadly Reentry and.... still can't reproduce. I think that I do see the error you mentioned on parts that didn't explicitly have DR's module on it but I tracked that down in ScrapYard's code and that's something you're doing exception handling on so the worst that should happen is that SY doesn't try to load that module in right? And I don't know if this means anything but I only saw that error if I explicitly tried to apply a used part to it...  (as opposed to being set on automatic)

Anyway, from a Deadly Reentry standpoint, if I can't reproduce it with just DR then I should probably forget about it except that if I'm using SY too then I might have to poke at this some more. Probably start adding more mods back into the mix until I find something that breaks things. I'll let you know if anything happens.

Edited by Starwaster
Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted

@severedsolo

This seems to be where it starts having trouble. 696639599 is the id of the part that was recovered and that is apparently used to track it. But FlightGlobals changed the id of that part (in the editor? really KSP??) and so I'm thinking that SY is understandably getting confused seeing as how 618416144 isn't in inventory.... FlightGlobals just pulled that number out of the air.

This started happening when at some point I clicked Select on the inventory window.

It's happened that way three times now but I can't get it to do that reliably. 

[FlightGlobals]: Part persistentId changed from 696639599 to 618416144. Vessel PersistentId 0
 
[ScrapYard] Found inventory part on vessel that is not in inventory. Resetting. Rockomax64.BW:618416144

I can get you the full logs from that sessions later. Also a copy of the persistence file BEFORE entering the editor and after exiting it. Comparing the two might show what's getting corrupted

Link to comment
Share on other sites
severedsolo

severedsolo

Posted
  • Author
Posted
9 hours ago, Starwaster said:

I'm thinking that SY is understandably getting confused seeing as how 618416144 isn't in inventory.... FlightGlobals just pulled that number out of the air.

Ugh, I wonder if the craft file is getting saved with the persistentID and then when the same part is pulled out of the inventory FlightGlobals is finding a conflict. According to the API docs a persistentID gets changed when it finds a duplicate.

I'll have a dig at it a bit later.

Link to comment
Share on other sites
gap

gap

Posted
Posted (edited)

@Starwaster @severedsolo 

I am following your cogitations with the highest interest guys. I am afraid that my knowledge of the game is too modest for me to be of much help at this point, but I will add anyway a couple of considerations.

During my tests, the inventory was correctly applied to my old vessels when I loaded them; the problem only became apparent when I started editing my crafts; so probably part id gets changed after the craft is loaded in memory and SY's inventory is applied for the first time, though I still don't ger why that happens only with the pod and not with other parts.

To the best of my knowledge, the FlightGlobals API is a stock function, correct me if I am wrong, but if you are still looking for a mod that in my install of the game might mess with part modules (and with SY), the first mod that comes to my mind is Kerbal Krash System.

Edited by gap
Link to comment
Share on other sites
severedsolo

severedsolo

Posted
  • Author
Posted (edited)
16 hours ago, Starwaster said:

and that's something you're doing exception handling on so the worst that should happen is that SY doesn't try to load that module in right? And I don't know if this means anything but I only saw that error if I explicitly tried to apply a used part to it...  (as opposed to being set on automatic)

Two different methods (I'm not entirely sure why, that was magico's code). Quick apply just flips the ID, whereas "Apply" actually tries to reload the modules from scratch.

What actually happens is when the NRE is caught, is ScrapYard logs the exception and then stops. TBH I'm tempted to just stick a "continue" into the exception handling. If I'm interpreting it correctly, all its doing is overwriting the module with the default version from the prefab. I feel like it's better to get a "not reset" module than no module/InventoryPart at all (and besides which, if resetting the module is that important, shouldn't the module be handling that?)

Edited by severedsolo
Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted

@gap yes FlightGlobals is stock. And I’ve duplicated this without Krash. 

@severedsolo maybe there was a time when it made sense to reload the modules when switching the inventory but the more I think about it The less sense it makes. The only two times those modules should be loaded at all is once from prefab when a part is spawned in the editor for default values and when a craft is loaded to grab persistent values that might have been changed. Some modules won’t do well with reloading at arbitrary times such as ModularFuelSystems/RealFuels where it obliterates custom tank content. 

As for FlightGlobals I’m still trying to get a handle on that one. If I ONLY let Scrapyard work automatically or at least only Quick Apply it doesn’t seem to have issues...

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
On 6/25/2019 at 3:38 AM, severedsolo said:

Ugh, I wonder if the craft file is getting saved with the persistentID and then when the same part is pulled out of the inventory FlightGlobals is finding a conflict. According to the API docs a persistentID gets changed when it finds a duplicate.

I'll have a dig at it a bit later.

What I've found is that if persistentID does not refer to a valid part or if it refers to a different part than what FG was expecting when it checked the persistentID then it will change the persistentID to something else and fire GameEvents.onPartPersistentIdChanged with the parameters being old ID, new ID and vessel ID

It would probably be prudent to listen for onPartPersistentIdChanged and change that ID everywhere applicable such as in-stock inventory items. And maybe OhScrap needs a similar check? I don't know?

Looking at my current log I see that in the span of less than half an hour worth of play (really just launching a mk1 pod a few times and moving parts out and back in inventory) this has happened 96 times. (I did NOT see this in @gap's log but maybe that's because the damage had already been done in a prior play session; I don't know)

 

 

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted

@severedsolo

Ok so about the issue persistentId and things not autoapplying, I've tried to collect some info and make sense of what's going on. Specifically here tracking the journey of part 1599986447 (parachuteSingle)

Several persistence files. One before entering the editor, one after exiting the editor and one with the resulting ship sitting on the pad. And a log. zip file at bottom.

Ok so what I've noticed is that four times FlightGlobals has tried to change the id of that part but the new id never shows up anywhere. Maybe because it gets changed back by ScrapYard? Also, where exactly is the actual inventory list in the save file? I've been assuming it's PartInventory in the ScrapYard scenario. Part 1599986447 definitely exists there. But in the final persistence file it's also sitting on the launch pad on the top of my capsule. Both the part.persistentId  and ModuleSYPartTracker.id = 1599986447. If it's on the vehicle should it actually be in the PartInventory list too? Or am I misinterpreting what that list means? The tracker module still has those id's and the part still has that id but the PAW menu says the part is new.

The log after switching to the flight screen has FlightGlobals saying that it changed that part's id to 2003863965 but that number doesn't show up anywhere else ever again. Certainly not in the persistence file. Still not sure what to make of all this except that there's discrepancies with the various ids and where ScrapYard actually thinks they are and says they are. I hope this is of some use and not just rehashing what we already know. Tell me what you think.

Quote

[LOG 13:39:23.974] [FlightGlobals]: Part persistentId changed from 1599986447 to 2003863965. Vessel PersistentId 0
[LOG 13:39:23.975] [OhScrap]: Attempting to refresh part 1599986447
[LOG 13:39:23.975] [OhScrap]: 1599986447 has been recovered 1 times. No need to refresh
[LOG 13:39:24.046] ScaleModList: listSize 492 maxListSize 1362
[LOG 13:39:24.050] Autogen thumbnail for I:/Games/KSP_win_1.7.2/KSP_x64_Data/../thumbs/Scrapyard Test 2_VAB_Mk1 Pod.png from I:\Games\KSP_win_1.7.2\saves\Scrapyard Test 2\Ships\VAB\Mk1 Pod.craft
[LOG 13:39:24.283] [ScrapYard] Found inventory part on vessel that is not in inventory. Resetting. mk1pod.v2:2106052421
[LOG 13:39:24.283] [ScrapYard] Found inventory part on vessel that is not in inventory. Resetting. solidBooster.sm.v2:937718910
[LOG 13:39:24.283] [ScrapYard] Found inventory part on vessel that is not in inventory. Resetting. basicFin:2820131628
[LOG 13:39:24.283] [ScrapYard] Found inventory part on vessel that is not in inventory. Resetting. basicFin:3971622190
[LOG 13:39:24.283] [ScrapYard] Found inventory part on vessel that is not in inventory. Resetting. basicFin:1471844318
[LOG 13:39:24.283] [ScrapYard] Found inventory part on vessel that is not in inventory. Resetting. basicFin:1466138743
[LOG 13:39:24.284] [ScrapYard] Found inventory part on vessel that is not in inventory. Resetting. parachuteSingle:1599986447

 

https://www.dropbox.com/s/2c93oej17xtuasc/ScrapYard-persistence troubleshooting.zip?dl=1

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted

@severedsolo If it's important the the Kerbal parts be blacklisted then you will want to know that there are more Kerbal parts now. Six total.

Quote

  name = kerbalEVA
  name = kerbalEVAfemale
  name = kerbalEVAVintage
  name = kerbalEVAfemaleVintage
  name = kerbalEVAFuture
  name = kerbalEVAfemaleFuture

 

Link to comment
Share on other sites
  • 3 weeks later...
Beetlecat

Beetlecat

Posted
Posted
45 minutes ago, uglyduckling81 said:

The mod seems to run but it doesn't recover any parts in 1.7.3.

The list just remains empty.

I have magicore and module manager added.

Make sure you're checking the actual full scrapyard inventory, rather than the per-part inventory popup window. If you open the "advanced" set of buttons in the editor,  youll see the scrapyard button under the main filters. This should show the accumulated parts. The "inventory" window that appears from clicking the toolbar button is the current-craft part management tool. This will be blank until you select or highlight a part in the editor.

Link to comment
Share on other sites
Sebastian Bork

Sebastian Bork

Posted
Posted

I have a problem with the Overide Funds option. I use KSP 1.7.3, KCT, KRASH, Oh Scrap, Scrapyard and Stage Recovery. For stuff that is launched and recovered, or even recovered from the launchpad, the calculation seems to be about right. Unfortunately, it breaks when I edit a vessel. That is, when I recover a plane or rover from the runway directly into storage to then refill it, as well as when I edit a rocket that is already in storage. In both cases, the full value of the vessel is added to the funds, which can be repeated indefinitely.

To duplicate this, build a rocket, wait until it is added to your storage, then edit it instead of rolling it out, save the edits (with or w/o actually changing anything), rinse and repeat. For every cycle in the editor, the full value of the rocket is added to the funds. This is obviously not what should happen.

Link to comment
Share on other sites
uglyduckling81

uglyduckling81

Posted
Posted
19 hours ago, Beetlecat said:

Make sure you're checking the actual full scrapyard inventory, rather than the per-part inventory popup window. If you open the "advanced" set of buttons in the editor,  youll see the scrapyard button under the main filters. This should show the accumulated parts. The "inventory" window that appears from clicking the toolbar button is the current-craft part management tool. This will be blank until you select or highlight a part in the editor.

Ok thanks. I see that now. So those parts in the scrapyard inventory section will be free?

Also does it stockpile more than one of an item?

Link to comment
Share on other sites
Beetlecat

Beetlecat

Posted
Posted
14 minutes ago, uglyduckling81 said:

Ok thanks. I see that now. So those parts in the scrapyard inventory section will be free?

Also does it stockpile more than one of an item?

Right, those parts are what you have in inventory already and don't need to manufacture. Each one just represents one of the whole category of that part so you can have one or hundred but only one will show up.

 

 

Link to comment
Share on other sites
uglyduckling81

uglyduckling81

Posted
Posted
Just now, Beetlecat said:

Right, those parts are what you have in inventory already and don't need to manufacture. Each one just represents one of the whole category of that part so you can have one or hundred but only one will show up.

 

 

Ah good.

I had used KCT years ago and it seemed to auto use parts that were recovered.

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
24 minutes ago, uglyduckling81 said:

So if I launch the same aircraft twice in a row I need to rebuild the entire thing manually to reuse older parts?

There is no way to make it replace parts automatically?

There's an option to enable automatically reuse old parts. 

However some parts you wont be able to use old parts for because of issues where the SY inventory system doesn't recognize them as the same part.  (Real Chute parts are almost guaranteed not to be reused because of a certain persistent field which changes constantly so SY thinks it's a different part)

Link to comment
Share on other sites
  • 2 weeks later...
severedsolo

severedsolo

Posted
  • Author
Posted
On 8/1/2019 at 11:36 AM, gamerscircle said:

I have a looney tunes question.  I know that this is a hard dependency for Oh Scrap, using it with Stage Recovery - is causing huge Game Surges / Pauses at times.  Is there a way that I can use OH Scrap without this mod? 

Oh Scrap will refuse to load without ScrapYard.

Link to comment
Share on other sites
severedsolo

severedsolo

Posted
  • Author
Posted (edited)
On 7/18/2019 at 2:06 PM, Sebastian Bork said:

I have a problem with the Overide Funds option. I use KSP 1.7.3, KCT, KRASH, Oh Scrap, Scrapyard and Stage Recovery. For stuff that is launched and recovered, or even recovered from the launchpad, the calculation seems to be about right. Unfortunately, it breaks when I edit a vessel. That is, when I recover a plane or rover from the runway directly into storage to then refill it, as well as when I edit a rocket that is already in storage. In both cases, the full value of the vessel is added to the funds, which can be repeated indefinitely. 

To duplicate this, build a rocket, wait until it is added to your storage, then edit it instead of rolling it out, save the edits (with or w/o actually changing anything), rinse and repeat. For every cycle in the editor, the full value of the rocket is added to the funds. This is obviously not what should happen. 

Whoops. Should definitely fix that. Thanks. Raised #4

Edited by severedsolo
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...