magico13

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

Recommended Posts

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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by magico13

Share this post


Link to post
Share on other sites
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 by severedsolo

Share this post


Link to post
Share on other sites

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 by severedsolo

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Hi, this looks quite interesting. I'd be interested in using it in a mod to control access to parts on a singular basis, but I'm not sure if that would work.

For example:

  • An experimental part (not yet researched) is available in the editor from one of those standard part test contracts.
  • The player launches with the experimental part, completes the contract, and recovers it.
  • Normally at this point the part is no longer available in the editor.
  • Would your mod allow the player to continue to access and reuse the part in this situation, so long as they recover it?

Hoping for a yes. lol. Thanks.

Edited by Oneiros

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by magico13

Share this post


Link to post
Share on other sites

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 by OldMold
update

Share this post


Link to post
Share on other sites

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 by severedsolo

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by magico13

Share this post


Link to post
Share on other sites
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 by severedsolo

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by severedsolo
Why you no copy link Dropbox?

Share this post


Link to post
Share on other sites
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 by magico13

Share this post


Link to post
Share on other sites

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 by BlueTiger12

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.