Jump to content

[1.11.2] B9PartSwitch v2.18.0 (March 17)


blowfish

Recommended Posts

On 9/1/2019 at 1:41 AM, N3N said:

Hey,

I'm getting this Errors in my logs:

Are they a problem?

 

And than I got this "Serious Warning"" when loading KSP:

IMG-20190831-165757501.jpg

And I'm getting this Warnings in my logs:

So how do I fix this?

 

My Logs: https://www.tancredi.nl/downloads/logs.zip

Do you need more information?

 

I have the same problem. The only way I could fix it was to manually remove the B9PartSwitch.  Can't remove using CKAN because B9 is required by Near Future "Cryogenic Engines" (Nertea).  I have the Community Resource Pack installed.

Edited by enewmen
Link to comment
Share on other sites

41 minutes ago, enewmen said:

I have the same problem. The only way I could fix it was to manually remove the B9PartSwitch.  Can't remove using CKAN because B9 is required by Near Future "Cryogenic Engines" (Nertea).  I have the Community Resource Pack installed.

your issues are with BDB - have you tried to uninstall and re-install with the latest version?

Link to comment
Share on other sites

1 hour ago, enewmen said:

I have the same problem. The only way I could fix it was to manually remove the B9PartSwitch.  Can't remove using CKAN because B9 is required by Near Future (Nertea).

These issues with BDB do not affect the game in a very big way. It just means some of the B9 switches with BDB parts are not working correctly. All of those parts have either been fixed or replaced entirely in the dev branch of BDB, which is also very close to a full release as per cobalt wolf.

Deleting B9 part switch on the other hand WILL break BDB and most other mods that require it as a dependency and will cause serious problems. 

Just ignore the warning for now or use the development branch of BDB on github. 

Link to comment
Share on other sites

2 minutes ago, enewmen said:

@zer0Kerbal & Zorg:

Did a clean CKAN minimal install, this time ONLY installing  Near Future "Cryogenic Engines" - that also installed the B9 dependency .  Worked this time.  Thanks!

Oh because of the post you quoted, I misunderstood, you werent using BDB at all were you? Just CryoEngines. Anyway glad its sorted out now.

Link to comment
Share on other sites

B9PartSwitch v2.11.0 for KSP 1.7.3

  • Allow switching UI to not be moved to the end of the part action window
    • ModuleB9PartSwitch now accepts bottomOfWindow = false which will leave it in place
    • Modules without this new parameter are unaffected
  • Allow transforms to be scaled
    • TRANSFORM {} nodes now accept a scaleOffset which multiplies the transform's local scale
    • scaleOffset either accepts a single number for all 3 axes or 3 numbers for x, y, z which can be separated by spaces, tabs, or commas
  • Fix plume switching for ModuleEnginesFX
    • Still doesn't support switching in flight
  • Fix Texture switches getting stuck on copied parts
  • Fix node offsets not respecting part rotation when attempting to move the part with the switch

KSP 1.8 compatibility will probably come in the next update (should be very soon), just wanted to get one more out for 1.7.3 with these changes, particularly since the 1.8 version will not work with older KSPs

Link to comment
Share on other sites

Update from the 1.8 front

1.8 seems to pin the top of the top the part action window rather than the bottom.  This eliminates the need to move the switching UI to the bottom of the window (basically, you don't want it to move as you add and remove resources)

Unfortunately, there seems to now be some weirdness with where resource items appear after they've been added.  This seems to manifest in different ways regardless of whether the switching UI itself is moved to the bottom or not

ojOBI3A.png

Will continue to investigate...

Link to comment
Share on other sites

Update: this issue seems to be reproducible without B9PartSwitch.  Any part with more than one resource and the stock variant selector will show it.  So it seems it has nothing to do with B9PartSwitch specifically.  Will see if it’s been reported yet...

Link to comment
Share on other sites

17 hours ago, blowfish said:

Will continue to investigate.

It seems that it is stock KSP/Unity UI bug and it might not be possible to do anything until next KSP patch. Look at tweakscale thread, there is even more strange things happening there. I think that is already reported in KSP bug tracker, but don't recall exact link from top of my head.

Link to comment
Share on other sites

6 hours ago, kcs123 said:

It seems that it is stock KSP/Unity UI bug and it might not be possible to do anything until next KSP patch. Look at tweakscale thread, there is even more strange things happening there. I think that is already reported in KSP bug tracker, but don't recall exact link from top of my head.

Any chance you could dig that link up?  I think I might be able to get a bit of traction on it...

Link to comment
Share on other sites

6 hours ago, kcs123 said:

It seems that it is stock KSP/Unity UI bug and it might not be possible to do anything until next KSP patch. Look at tweakscale thread, there is even more strange things happening there. I think that is already reported in KSP bug tracker, but don't recall exact link from top of my head.

Bug #24014, sir. This one I know from heart. :)

That weird things are weird indeed, but it's nothing that exoteric. It happens that TweakScale (ab)uses that poor control in different configurations, depending how a thingy called ScaleType is configured - and there's a huge amount of these things, as different parts need different rules to be scaled and these ScaleTypes are part of the process. And by plain luck, a third party decided to write his own rules, and did it the way it wanted, not the way TweakScale were doing things, and by yet more luck, one of that configurations had set up the UI_ScaleEdit control in a way it ended working!! :)

Don''t try to figure out the odds of that happening. We got insanely lucky on this one. ;) 

What is needed to be done is to identify the code flow of the successful configuration to identify the working settings for the UI_ScaleEdit - something that will demand some time of trial and error, to be executed as Real Life allows. Since UI_FloatEdit and UI_FloatRange appears to be borking in the exact same way as ScaleEdit, there's a good chance that they share the same borking code - and so, figuring out one of them will help the other two.

17 minutes ago, blowfish said:

Any chance you could dig that link up?  I think I might be able to get a bit of traction on it...

Here and here.

Link to comment
Share on other sites

@Lisias I think that's unrelated.  Based on my testing this issue is specific to having ModulePartVariants on the part and is reproducible in stock KSP without any mods installed.  you just need a part with ModulePartVariants and more than one resource.

Link to comment
Share on other sites

Might not be exactly the same thing, but both issues comes from buged UI objects in stock game. That is why I have brought it to attention in B9PS thread. In TS case buttons on PAW are somewhat visible, but positioned in wrong way/place, failing to resize UI window properly. in B9PS and stock parts with multiple resources it seems to me that required objects were placed outside of drawning area of UI and causing it to not be drawn at all.

Just wild speculation that comes from experience on working of other things. Although, there is chance that I'm wrong, but I think that is worth to investigate. Perhaps to describe problem dicovered with B9PS on same bug tracker might increase chance for SQUAD to solve it sooner. Sorry in advance if my thought become missleading.

Link to comment
Share on other sites

25 minutes ago, blowfish said:

@Lisias I think that's unrelated.  Based on my testing this issue is specific to having ModulePartVariants on the part and is reproducible in stock KSP without any mods installed.  you just need a part with ModulePartVariants and more than one resource.

I'm smelling race conditions. And I didn't considered it before, the lucky strike on TS can be even more luckier than I thought, as minimalist forgings on what I expect to be a working configuration didn't gave me any results yet.

@kcs123 thanks for bringing me here. You helped me to open my eyes on something I was plain ignoring.

 

Link to comment
Share on other sites

I actually really suspect this is related to how the ModulePartVariants variant selector moves its UI to the bottom of the list and doing so in a way that some other logic isn't aware of.  There are a couple of things I can do to test that hypothesis.  Regardless though, not a B9PartSwitch issue.

Link to comment
Share on other sites

1 hour ago, kcs123 said:

Have yet to try it, but at least it is confirmed that Tweakscale work properly now. Don't know about stock part resource/mesh switching yet.

There's no stock resource switching, the switcher's presence just messes up the order of unrelated stuff.

Edited by blowfish
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...