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

[PhoenixSpaceIndustries]

On 07/11/2017 at 10:48 AM, Mace from Space said:

@PhoenixSpaceIndustriesIf you post your GameData Folder I could possibly help you iron it out faster. Im also running heavily modded and I know of the pain tracking those issues.

Hi @Mace from Space, sorry for the delay in responding. Here is a link to my GameData folder: https://dsh.re/1b010

Thanks ever so much for your generous offer of assistance. Basically, it now loads but flickers horrendously whenever I try to do anything.

Thanks again!

Dom

[Mace from Space]

1 hour ago, PhoenixSpaceIndustries said:

Hi @Mace from Space, sorry for the delay in responding. Here is a link to my GameData folder: https://dsh.re/1b010

Thanks ever so much for your generous offer of assistance. Basically, it now loads but flickers horrendously whenever I try to do anything.

Thanks again!

Dom

Sorry, that link leads to a file called GameData without any extension. I tried to open it with anything I can think of right now but with no luck. What kind of file is it?

[Galileo]

@Mace from Space @PhoenixSpaceIndustries You cannot post entire gamedata folders. This goes against licensing of many mods and is not allowed on the forums. Please find another way to iron out the issues.

[Mace from Space]

42 minutes ago, Galileo said:

@Mace from Space @PhoenixSpaceIndustries You cannot post entire gamedata folders. This goes against licensing of many mods and is not allowed on the forums. Please find another way to iron out the issues.

Well after re-reading my own post I see the error on my side. I meant him to post a screenshot of the folder so I can check which mods we both use and therefore aren't causing the issue. Sorry for not writing that clearly

[magico13]

45 minutes ago, Mace from Space said:

Well after re-reading my own post I see the error on my side. I meant him to post a screenshot of the folder so I can check which mods we both use and therefore aren't causing the issue. Sorry for not writing that clearly

The log does contain a list of the mods in use, so you could use that. If he got them all (or at least most) from CKAN there is a way to have CKAN generate a file that will install all of those mods on another system.

[PhoenixSpaceIndustries]

@Galileo thanks for informing me of that, lucky the link didn't work!

@Mace from Space the contents of the folder are here: https://dsh.re/496e6 and https://dsh.re/40d5c. These should definitely work this time! Thanks again for taking a look!

@magico13 I'm afraid I don't use CKAN, but thanks!

 

[severedsolo]

So I think I found a bug.

ScrapYard seems to save the ID in the module when the craft file is saved.

This isn't usually a problem, if you are, for instance using KCT, because you'd normally go back into the VAB to build a new craft, where it gets assigned a new ID.

However, if you are using stock, and you use the Launchpad to launch that craft without visiting the VAB, you get the exact same craft, with the exact same IDs. If you then recover that craft, and already have that part in your inventory, you get two parts, with the same IDs in the inventory. If you then go to the VAB and build those two parts, and apply the inventory, both parts have exactly the same ID.

Now, I have to say, ScrapYard doesn't seem to care, but UPFM does, as it uses IDs it hasn't seen before to decide whether to roll new failure stats.

[magico13]

5 hours ago, severedsolo said:

However, if you are using stock, and you use the Launchpad to launch that craft without visiting the VAB, you get the exact same craft, with the exact same IDs

I never even thought about that since it's not possible with KCT... I might just do a quick fix of refreshing all parts to brand new when you launch through that menu, but I'll have to do a bit of research about when the best time to do that would be. What I may end up having to do is at launch checking if the parts are in the inventory, and if not then I refresh it instead of letting it use the ID it has right now. With KCT, since the vessel will have already been handled, it would skip that check at launch. Would that work ok for you?

 

Edit: Made that change in the latest build (though I didn't test it) which triggered a build of UPFM that should have that all ready to test.

Edited November 15, 2017 by magico13

[severedsolo]

9 hours ago, magico13 said:

Edit: Made that change in the latest build (though I didn't test it) which triggered a build of UPFM that should have that all ready to test.

Seems to be working as intended, and UPFM is picking up the new IDs and doing it's checks.

Haven't checked KCT yet but I assume that will be ok

Edited November 15, 2017 by severedsolo

[severedsolo]

Hmm, another (possible) bug.

Does Scrapyard happen to register a new "build" when you click the launch button in the VAB when using KCT? I know it does it onVesselRollout in stock.

The reason I ask, is I was doing some testing for UPFM and accidentally clicked the "launch" button twice. I scrapped the build from the Space Centre scene when I noticed, and then launched the vessel I had built.

To my surprise, UPFM reported that this part was "generation 2" (FYI it calls ScrapYardWrapper.GetBuildCount(part, ScrapYardWrapper.TrackType.NEW)) - but it had only actually been launched once.

I'm not even sure this is a bug, because technically, the build was triggered twice. However, I feel like maybe KCT should decrement the builds again if it gets scrapped before launch.

Edited December 26, 2017 by severedsolo

[magico13]

6 hours ago, severedsolo said:

Does Scrapyard happen to register a new "build" when you click the launch button in the VAB when using KCT? I know it does it onVesselRollout in stock.

It should be registering as a new build only when the vessel is moved into storage, ie when it finishes being built. That's the only call I see to it in KCT at least.

[magico13]

23 hours ago, Oneiros said:

Would your mod allow the player to continue to access and reuse the part in this situation, so long as they recover it?

That is one of the goals, but I don't believe it would work in the current state of the mod. I don't believe there'd be any way to select the part through the UI right now and I think I'd have to override something to let you launch the craft.

[magico13]

The latest dev builds now have a custom part category (found in the advanced menu) that will only be populated with parts that exist in the inventory. It's going to get long when a game has been going on for a while so I'm still looking into either other subcategories to break things up a bit or a way to allow searching just those parts. Couple that filter with the selector UI and you can easily pull specific items out of the inventory (or scrap old parts).

On that note, I just spent a few hours getting TweakScale support up and running to a more usable state. Now when you pull a part out of the inventory that has a TweakScale module or apply an inventory part to an existing part in the editor it should properly copy over the TweakScale data, causing the part to scale everything correctly. It required code changes specifically for TweakScale that cannot currently be handled through config files, so it's not something that can be replicated for any module. I will likely try to do something to make it work through a config file since I don't really want to require a recompile to support specific modules when everything else is done through configs.

You can always grab the latest dev version direct from the build server here: http://magico13.net:8080/job/ScrapYard/

Edited January 28, 2018 by magico13

[OldMold]

Quick mod conflict report for what it's worth: If both ScrapYard (latest dev build) and Janitor's Closet are installed, Janitor's Closet mod+click part dialogs no longer show up.

EDIT: Nevermind - after successfully reproducing this for like half an hour, it now magically works and I can no longer repro. *shrug*

Edited February 1, 2018 by OldMold
update

[severedsolo]

Latest dev build seems to have broken Forbidden Modules (I know I know, that's why it's a dev build).

I've just spent 30 minutes chasing around UPFM trying to figure out why on earth my Broken Module wasn't doing anything, and then thought "hmm lets just chuck the last "official" ScrapYard release in, just in case" and it magically started working again.

Not a big deal from my point of view right now as it's a dev build, but thought you might like a heads up.

Edit: Looks like last time it worked was Build #76 76 didn't work either. I forgot to turn auto-apply on. Trying to trace the last working build now.

Edit2: #72 seems to be last time forbidden modules worked.

Edited March 3, 2018 by severedsolo

[severedsolo]

And another one for the Wiki (this is not a ScrapYard issue - but I'm posting it here for posterity in case anyone comes across this problem in the future).

KSP apparently does not save modules that are added on the fly. I've got no idea when this changed, because I swear it was working when I first wrote it.

Using build 72 (the one where the forbidden modules are working) if I use part.AddModule("SomeForbiddenModule") if you recover that part without switching scenes, ScrapYard will correctly not recover it.

HOWEVER - if you switch scenes, SomeForbiddenModule doesn't get saved, which means if you switch back to the vessel the module won't exist, and ScrapYard will then (correctly) recover the part anyway, because the Forbidden Module doesn't exist any more.

I'm working around it now by using a KSPField to identify that it should have that module and re-adding it when Start() is called.

[magico13]

On 3/3/2018 at 12:11 PM, severedsolo said:

Latest dev build seems to have broken Forbidden Modules (I know I know, that's why it's a dev build).

Build 82 should fix this. I started lazy loading the modules so that creating an InventoryPart isn't as intensive but that meant the DoNotStore flag wasn't getting set until the part was already in the inventory. Now it will also load the module list if you check that flag, which really only happens when trying to add a part to the inventory.

If you've already got a module on the part you could just have a flag on that module that would prevent recovery if true, you don't have to do it based on module name. You would just use this:

SY_FORBIDDEN_TEMPLATE
{
    name = MyNormalModule
    requirement = [doNotRecoverFlag]
}
	

Edited March 4, 2018 by magico13

[severedsolo]

10 hours ago, magico13 said:

If you've already got a module on the part you could just have a flag on that module that would prevent recovery if true, you don't have to do it based on module name. You would just use this:

Would that work if the module is inherited by other modules?

So for example:

SY_FORBIDDEN_TEMPLATE
{
    name = BaseFailureModule
    requirement = [doNotRecoverFlag]
}

Would that pick up all modules that inherit BaseFailureModule? or could I use a wildcard?

SY_FORBIDDEN_TEMPLATE
{
    name = *FailureModule
    requirement = [doNotRecoverFlag]
}

Edit: Never mind. The flag is put on the event module anyway, no inheritance required.

Edited March 5, 2018 by severedsolo

[magico13]

17 hours ago, severedsolo said:

Would that work if the module is inherited by other modules?

Edit: Never mind. The flag is put on the event module anyway, no inheritance required.

Inheritance isn't supported, but the name attribute supports regex. So if they all end with FailureModule then the name could be ".*FailureModule". That works the same for the modules to save and the forbidden module, since they're the handled the same internally.

[severedsolo]

Hmm, so it seems that doing it that way causes MagiCore to freak out:

Quote

[MagiCore] Exception encountered while parsing 'SY_REQUIREMENT_PROCESSING' : 'True'. Current value: '0' Stack: Tru
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

ArgumentOutOfRangeException: startIndex + length > this.length

This is the cfg that I assume is causing the issue:

Quote

SY_FORBIDDEN_TEMPLATE
{
    name = ModuleUPFMEvents
    requirement = [doNotRecover]
}

doNotRecover is a bool defined in ModuleUPFMEvents  - full log: https://db.tt/g4lRZJoQ 

I've committed to Github in case you need an actual use case for debugging.

Edited March 6, 2018 by severedsolo
Why you no copy link Dropbox?

[magico13]

1 hour ago, severedsolo said:

Hmm, so it seems that doing it that way causes MagiCore to freak out:

This is the cfg that I assume is causing the issue:

doNotRecover is a bool defined in ModuleUPFMEvents  - full log: https://db.tt/g4lRZJoQ 

I've committed to Github in case you need an actual use case for debugging.

crap. I was afraid of that. It's because it's a capital "True" instead of "true". I'll get that fixed tonight. Alternatively you can use 1 and 0 and that will work.

Edited March 6, 2018 by magico13

[BlueTiger12]

Hi Magico,

 

i seem to have found a conflict between ScrapYard and ActionGroups Extended

These mods together cause a stutter in the VAB for me every 1-2 seconds - only when i am moving parts around. This becomes really game-disturbing when having a havy modded game because the stutters take 0.5 to 1 second then.
Ich used MemGraph and with it i can see, that every time a stutter occurd, a cleanup is performed. This is not happening when one of the two mods is removed or i am not moving any part in the VAB.

I don't know if this is allready reported. If not and i can help you with further information, i will be glad to provide them.
What do you need and which way do you prefer?

I have the output_log.txt, the ksp.log and a screenshot as well as a video of the scenario with scrapyard and AGX as well as only ScrapYard.

Unfortunatelly i am not able - or to stupid to find the option - to insert the screenshots in this post.

Installed Mods are:

• ScrapYard Build 82
• MagiCore
• Action Groups Extended
• ClickThroughBlocker
• ExceptionDetector
• MemGraph
• ModuleManager.3.0.4

Thanks for your great mods - the game is not the same without them!

 

Ps.: I don't know if this is the right place to report it, or if i should report it on the AGX thread. So sorry if this is the wrong place.

Edited March 6, 2018 by BlueTiger12

[magico13]

3 hours ago, BlueTiger12 said:

These mods together cause a stutter in the VAB for me every 1-2 seconds - only when i am moving parts around.

It is definitely going to be in part due to ScrapYard, it does some heavy calculations in the editor every few seconds when doing anything with parts. The build of ScrapYard you're running has some optimizations to help avoid that (that clearly aren't doing enough in this case) and some logging with timing of how long the calculations. If you could zip up the log and put it on dropbox/google drive/ a similar site then I'd definitely like to see it.

Some things you could do to help reduce the stutter is to make sure the auto-apply setting is disabled and to increase the timer in the settings. It's set to 1 second by default (listed as 10 tenths of a second) so you can increase that so it calculates less frequently. It won't make the stutters take less time, but it will make them occur less frequently.

[magico13]

Important FYI: The next ScrapYard release will be a breaking change. KSP 1.4 added a separate persistent id system and I am attempting to use that instead of a hand-rolled system.

If it doesn't work out, I will revert that change and keep the current method of storing a guid in a special module, but otherwise 1.3.1 inventories won't be compatible with 1.4 inventories and I don't intend on making an upgrade path.

[BlueTiger12]

19 hours ago, magico13 said:

It is definitely going to be in part due to ScrapYard, it does some heavy calculations in the editor every few seconds when doing anything with parts. The build of ScrapYard you're running has some optimizations to help avoid that (that clearly aren't doing enough in this case) and some logging with timing of how long the calculations. If you could zip up the log and put it on dropbox/google drive/ a similar site then I'd definitely like to see it.

Some things you could do to help reduce the stutter is to make sure the auto-apply setting is disabled and to increase the timer in the settings. It's set to 1 second by default (listed as 10 tenths of a second) so you can increase that so it calculates less frequently. It won't make the stutters take less time, but it will make them occur less frequently.

Well i think your optimizations are doing a pretty good job.
Without AGX, my game is pretty lag free in the VAB even with auto apply on, in a game with about 160 mods.

I included 4 videos in the Bug report:

1. Only Scrapyard installed (auto-apply on)
2. Scrapyard and AGX installed (auto-apply on)
3. All 160 Mods including Scrapyard without AGX
4. All 160 Mods including Scrapyard and AGX

You can see there is little difference between 1 and 3 but including AGX is creating a massive impact in performance. Therefore i think this is a specific conflict between these 2 mods.

As you see in 3 your optimizations are doing a pretty good job i think

Here is the Link to my Dropbox: https://www.dropbox.com/s/01jpds5p3czyslj/BugReport.7z?dl=0

Ps: I left the timer unchanged for now