Alewx

[1.4.*] [2.5.3] (2018-04-06) UbioZur Welding Ltd. Continued

Recommended Posts

1 hour ago, suzuki said:

That's weird.

[ERR 03:51:20.865] [WeldingTool] ERROR UbioZurWeldingLtd raised Exception System.IO.IsolatedStorage.IsolatedStorageException: Could not find a part of the path "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\net.lisias.ksp\UbioWeldingLtd\PluginData\UbioWeldingLtd\new-config.xml".

This is a already old package, April/2018 - this was one of my first releases ever for an Add'On, and that was working for me at that time (KSP 1.4.1, I think, and I think I used it on 1.4.3). And kept working, as some posters above have stated it.

And this error is not happening on my KSP test beds, I'm on the dark here.

However, I just realized that besides not suffering with this specific error, the latest release is borking relentlessly on the Update() callback - and this is happening to you also. So there's no point on trying to fix this issue, as the tool will bork later anyway. :(

Sorry for that.

I have a new release almost done that I was delaying due some other duties as it was my understanding that the current release was working (even that not perfectly). I will see how that code is working (it's some months since my last commit), and if it is minimally functional, I will release a new version ASAP (by night, if that thingy works)

Share this post


Link to post
Share on other sites
On 4/3/2019 at 6:55 AM, Lisias said:

That's weird.


[ERR 03:51:20.865] [WeldingTool] ERROR UbioZurWeldingLtd raised Exception System.IO.IsolatedStorage.IsolatedStorageException: Could not find a part of the path "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\net.lisias.ksp\UbioWeldingLtd\PluginData\UbioWeldingLtd\new-config.xml".

This is a already old package, April/2018 - this was one of my first releases ever for an Add'On, and that was working for me at that time (KSP 1.4.1, I think, and I think I used it on 1.4.3). And kept working, as some posters above have stated it.

And this error is not happening on my KSP test beds, I'm on the dark here.

However, I just realized that besides not suffering with this specific error, the latest release is borking relentlessly on the Update() callback - and this is happening to you also. So there's no point on trying to fix this issue, as the tool will bork later anyway. :(

Sorry for that.

I have a new release almost done that I was delaying due some other duties as it was my understanding that the current release was working (even that not perfectly). I will see how that code is working (it's some months since my last commit), and if it is minimally functional, I will release a new version ASAP (by night, if that thingy works)

Nice to hear. Can't wait

Share this post


Link to post
Share on other sites
Posted (edited)
On 4/5/2019 at 5:37 PM, suzuki said:

Nice to hear. Can't wait

UGH… I have good and bad news for you. :P 

The good news is that the (my) latest Ubiowelding is working fine under certain circumstances (of course, under the already mentioned limitations - KSP 1.4.x or greater, but using KSP 1.3 style parts, I don't have a clue how it will behave with MODULEPARTVAIRANTS).

The bad news is that that circumstance is Module Manager. You need to use Module Manager 3, as MM4 changed something very crucial on MMPatchLoader and this broke Welding badly. Worst, this is already a known issue but I just plain forgot about! Sorry!

My current dilema is that by "fixing" the Welding Tool to use standard Mono's Reflection to find it, I'll be exposing the Welding Tool to the same nasty bugs that plages KSPe, a very irritante bug on Mono's runtime that breaks anything that uses reflection when an DLL fails to be loaded.

Ok, "my" fork of the Welding Tool already use KSPe, so it would bork anyway - but ideally, this fix should be back-ported to any mainstream version (remember, mine is highly experimental). So I'm reluctant to use standard, flawed Mono's Reflection on something that needs to be updated to mainstream.

I think that ideally Module Manager should not had changed that bit of MMPatchLoader that rendered it unusable this way, but perhaps there're another ways to accomplish this functionality that not the one used by KSPe. Anyone has a working (and safe) replacement for "UnityEngine.Object.FindObjectOfType"?

— — — POST EDIT — — — 

That's the deal - I restored MMPatchLoader to be loadable again, as it was on the MM3, on my personal fork (experimental) of Module Manager. If you want MM4 features and Ubioweld, this is the solution. It's par on features to MM 4.0.2.

However, please remember: "Lasciate ogne speranza, voi ch'intrate" - this is not official, it's mangled to fit my needs, and any problem should not be directed to the Official Maintainers, but to myself. Kick me here (using the message button) if you need some help, don't bother anyone else if you choose to use it. 

— — — POST POST EDIT — — — 

Ouch, forgot to mention. Follows a dependency for (MY) UbiozurWelding. Please read the INSTALL.md on the zip file. It will not work without it.

https://github.com/net-lisias-ksp/KSPAPIExtensions/releases

Edited by Lisias
yeah. tons os tyops!

Share this post


Link to post
Share on other sites
1 hour ago, Lisias said:

UGH… I have good and bad news for you. :P 

The good news is that the (my) latest Ubiowelding is working fine under certain circumstances (of course, under the already mentioned limitations - KSP 1.4.x or greater, but using KSP 1.3 style parts, I don't have a clue how it will behave with MODULEPARTVAIRANTS).

The bad news is that that circumstance is Module Manager. You need to use Module Manager 3, as MM4 changed something very crucial on MMPatchLoader and this broke Welding badly. Worst, this is already a known issue but I just plain forgot about! Sorry!

My current dilema is that by "fixing" the Welding Tool to use standard Mono's Reflection to find it, I'll be exposing the Welding Tool to the same nasty bugs that plages KSPe, a very irritante bug on Mono's runtime that breaks anything that uses reflection when an DLL fails to be loaded.

Ok, "my" fork of the Welding Tool already use KSPe, so it would bork anyway - but ideally, this fix should be back-ported to any mainstream version (remember, mine is highly experimental). So I'm reluctant to use standard, flawed Mono's Reflection on something that needs to be updated to mainstream.

I think that ideally Module Manager should not had changed that bit of MMPatchLoader that rendered it unusable this way, but perhaps there're another ways to accomplish this functionality that not the one used by KSPe. Anyone has a working (and safe) replacement for "UnityEngine.Object.FindObjectOfType"?

— — — POST EDIT — — — 

That's the deal - I restored MMPatchLoader to be loadable again, as it was on the MM3, on my personal fork (experimental) of Module Manager. If you want MM4 features and Ubioweld, this is the solution. It's par on features to MM 4.0.2.

However, please remember: "Lasciate ogne speranza, voi ch'intrate" - this is not official, it's mangled to fit my needs, and any problem should not be directed to the Official Maintainers.

More like good news! What is KSPe, by the way? That could be the sole reason UbioWelding did not work.

Share this post


Link to post
Share on other sites
1 hour ago, suzuki said:

More like good news! What is KSPe, by the way? That could be the sole reason UbioWelding did not work.

Ouch, forgot to mention. It's a dependency for (MY) UbiozurWelding and (MY) MM. Please read the INSTALL.md on the zip file.

https://github.com/net-lisias-ksp/KSPAPIExtensions/releases

note: Please advise if everything works fine with that MM4 of mine (and please backup your savegames! :) ). If everything goes fine, I'll pull request (only) the fix for the Welding Tool to the Official Maintainer. Please keep in mind that "my" MM is a stunt, and can bite you (besides never had bitten me, but I don't use all the mods you use, so…).

 

Share this post


Link to post
Share on other sites
18 minutes ago, Lisias said:

Ouch, forgot to mention. It's a dependency for (MY) UbiozurWelding and (MY) MM. Please read the INSTALL.md on the zip file.

https://github.com/net-lisias-ksp/KSPAPIExtensions/releases

note: Please advise if everything works fine with that MM4 of mine (and please backup your savegames! :) ). If everything goes fine, I'll pull request (only) the fix for the Welding Tool to the Official Maintainer. Please keep in mind that "my" MM is a stunt, and can bite you (besides never had bitten me, but I don't use all the mods you use, so…).

 

Thank you! Will take a look. 

Share this post


Link to post
Share on other sites
On ‎3‎/‎13‎/‎2019 at 5:38 PM, Jammer-TD said:

Kerbal Space Program Enhanced edition.

and @Lisias it is worth the wait. take all the time you need. rushing things won't make you happy. we will wait! and still be thankful as the saying goes  "good things come to those who wait".

correction..my guess was not even close..

KSPe= https://github.com/net-lisias-ksp/KSPAPIExtensions/releases

 

Share this post


Link to post
Share on other sites
On 4/5/2019 at 6:39 PM, Lisias said:

Ouch, forgot to mention. It's a dependency for (MY) UbiozurWelding and (MY) MM. Please read the INSTALL.md on the zip file.

https://github.com/net-lisias-ksp/KSPAPIExtensions/releases

note: Please advise if everything works fine with that MM4 of mine (and please backup your savegames! :) ). If everything goes fine, I'll pull request (only) the fix for the Welding Tool to the Official Maintainer. Please keep in mind that "my" MM is a stunt, and can bite you (besides never had bitten me, but I don't use all the mods you use, so…).

 

This has always been a "must have" mod for me, having the ability to construct a general air(space)frame IMO has the game play better rather than the basic "LEGO" approach of 2000 parts of which 1700 are purely frame but still generating game lag. It also drastically enhances complex scenarios with multiple vessels and stations which would otherwise be unplayable.

 

I'm very glad that someone still has interest in keeping this going while confused how this aspect keeps getting overlooked as a native feature of the game, in any case I've been monitoring this thread for a few months now and am wondering... As the only person who seems interested and capable of maintaining this mod, why are you still messing around as a fork and not either assume this project or create your own? I also don't understand the "my" factor in your approach. Why are you developing in a way that doesn't use the standard modules? Why was a previous version of your fork requiring a non-standard installation approach? A standard of no standards is chaos...

Share this post


Link to post
Share on other sites
3 hours ago, ChinaLakeGuy said:

As the only person who seems interested and capable of maintaining this mod, why are you still messing around as a fork and not either assume this project or create your own?

I'm already overwhelmed by what I got in hands. TweakScale is a lot of work for now, and I will not manage to give it the care it needs. Look for the date of the latest release, and you will se what I mean.

I probably will adopt it for good in the (not so) near future, but now I just can't.

 

3 hours ago, ChinaLakeGuy said:

I also don't understand the "my" factor in your approach. Why are you developing in a way that doesn't use the standard modules? Why was a previous version of your fork requiring a non-standard installation approach? A standard of no standards is chaos...

Yes, it's going apart from current "mainstream" behaviour. Parts are saved somewhere else, configurations are kept in the ROOT\PluginData directory. These are non mainstream behaviours for now.

I have a component called KSPe, currently embedded into KSP API Extensions, that would allow me to give a option to the user: "my way" or "standard way", what's different from the current implementation : "my way or the highway". But yet, I need more time than I have available nowadays to overcome or fix some nasty (and stupid) bugs on Unity's Mono fork - until there, releasing KSPe (and everything that depends on it) on the mainstream is looking for trouble.  :/

 

 

Share this post


Link to post
Share on other sites

Idk if this has already been answered but, where would the files of the parts be put? and does it work in science mode as well?

Share this post


Link to post
Share on other sites
On 4/19/2019 at 6:50 PM, Lisias said:

I'm already overwhelmed by what I got in hands. TweakScale is a lot of work for now, and I will not manage to give it the care it needs. Look for the date of the latest release, and you will se what I mean.

I probably will adopt it for good in the (not so) near future, but now I just can't.

I was trying to install this, and found that the button wasn't being shown.  The issue is that you are adding the button to the ToolbarController without first registering it.

The newer toolbar controller requires that the button be registered before it is used. I've added one file and modified one other to support this.

Tested and working in a 1.4.5 install, PR submitted

 

Share this post


Link to post
Share on other sites
On 5/20/2019 at 6:50 PM, Dash8466 said:

Idk if this has already been answered but, where would the files of the parts be put? and does it work in science mode as well?

GameData\UbioWeldingLtd\Parts folder

if it works, yes. see above postings concerning which KSP versions it works with et al.

Share this post


Link to post
Share on other sites
Posted (edited)
20 hours ago, linuxgurugamer said:

I was trying to install this, and found that the button wasn't being shown.  The issue is that you are adding the button to the ToolbarController without first registering it.

Damn. I thought I had fixed this last time I made a release. :( 

I was wrong. I didn't made the Kraken damned release!!! I'm working on it, it should be available late night, after some pending activities of the day...

— — POST - EDIT — — 

I just remembered what I was doing in December on UbioWelding. Not big deal, but I think it will worth finishing it!!! Release on the weekend! :)

Edited by Lisias
post eidt

Share this post


Link to post
Share on other sites

Take the time required to get a solid release.

My posts were virtual elbows hoping to nudge this project back awake as it's a top 3 must-have from my point of view. I didn't follow up on your replies because when someone says " I'm already overwhelmed" and you can already see they're doing a bunch of things I let them be. I did peek at this way back when it first broke to see if it was something I could "jimmie" on my own for myself and saw the MM issue but it also revealed to me that knowing c# isn't enough, I don't know Unity, I don't know the innards of KSP, I also don't know the innards of the Welding module or any of it's dependency modules so I wasn't about to start jamming monkey-wrenches anywhere.

 

I'm content to let this behemoth sit in the hangar until I can redo the frame (cheated it into orbit just to see how it performed)... ;)

60258357_10211829473332313_2530002669561

Share this post


Link to post
Share on other sites

I suspect that for simple welds an ambitious player could just use the .craft file and copy and paste part data coupled with model/texture data from part.cfg. lot more work than this glorious mod, but hey, it could work. Just think of the bragging rights!:wink::P:o

Share this post


Link to post
Share on other sites
9 hours ago, zer0Kerbal said:

GameData\UbioWeldingLtd\Parts folder

if it works, yes. see above postings concerning which KSP versions it works with et al.

thank you!

Share this post


Link to post
Share on other sites

So… For ones in need of a fixed working Welding Tool, the 2.6.0.4 release.

Dependencies:

The Change Log is huge, I suggest reading it right from the source.

This thing is welding fine as long you don't try to weld parts with ModulePartVariant - it will weld the part, but the welded part will behave (and look!) erratically. The best workaround is to weld your parts on KSP 1.4 (where no but one part uses ModulePartVariant) - but them you can have problems with parts gone into the zDeprecated folder. :( 

You also need to use ModuleManager 3, as the 4 changed in a way that broke the Welding Tool. If you really want MM4, see the Known Issues file for tips.

Unless I had borked (yet another time), I think this release will be somewhat definitive for this code-tree. Kick me on the Issue Tracker (or privately if you prefer).

(and yes, it's late night - Venusian Local Time. :D)

Share this post


Link to post
Share on other sites

@Lisias would you like me to help take a crack at MM4 compatibility? If so are you willing to require MM4+ dependency or would you insist on keeping backward compat for people using MM<4?

Share this post


Link to post
Share on other sites
4 hours ago, cakepie said:

@Lisias would you like me to help take a crack at MM4 compatibility? If so are you willing to require MM4+ dependency or would you insist on keeping backward compat for people using MM<4?

I I think it's premature doing something by now. By checking MM's commit history, you will realize that that line of code was there for years.

Check: change, the last change before, oldest mention of the file before a internal refactoring, and the first time MMPatchLoader was extended with LoadingSystem. This first LoadingSystem commit was made in 2014, so we have 5 years of a public class being served this way!!

(yeah, I did my homework!! :) )

It's my understanding that classes not intended to be reused should be internal, private or whatever - so I found very understandable the reason Welding Tool decided to use it. :) 

So this is a unfortunate event and will be reverted, or it is part of a ongoing major overhaul of MM and will change again. In both cases, we need to wait and see - and if the later, I intent to tackle the problem on KSPe by creating a proper public interface to the feature, so every time MM brakes something, KSPe would be the only thing to be updated.

Doing anything else would be playing catch and mouse with MM - hardly something enjoyable to users and developers.

Share this post


Link to post
Share on other sites
9 minutes ago, Lisias said:

Check: change, the last change before, oldest mention of the file before a internal refactoring, and the first time MMPatchLoader was extended with LoadingSystem. This first LoadingSystem commit was made in 2014, so we have 5 years of a public class being served this way!!

(yeah, I did my homework!! :) )

Yes, I've recently done that same homework independently from you when I was coding unBlur, so I know exactly what you're referring to.

However, just because the class has been that way for 5 years shouldn't be taken as a guarantee of anything, especially given the unsupported nature of what the UbioZur Welding code was doing with it -- not part of any explicit contract offered by MM to other mods.

 

14 minutes ago, Lisias said:

It's my understanding that classes not intended to be reused should be internal, private or whatever - so I found very understandable the reason Welding Tool decided to use it. :) 

Not really, MM never intended for other mods to be able to call DataBaseReloadWithMM() , it has been private since 2.4.0 and internal before that, which is why blowfish said the UbioWeld code was doing unintended and unsupported things.

 

9 minutes ago, Lisias said:

So this is a unfortunate event and will be reverted or it is part of a ongoing major overhaul of MM and will change again.

I don't think so. This is a fairly major architecture change in MM hence the major version number change. The rationale is clear: improve loading times in the load screen.
This is not some random change, it is part of a well planned refactoring. It is not likely to get reverted, or to change again soon.

 

The LoadingSystem of MM is now in the PostPatchLoader class, but you will obviously not be able to use it as a conduit to make a database reload call any more.

 

29 minutes ago, Lisias said:

creating a proper public interface to the feature

I've already started writing MMWrapper.cs, but let's see if MM is willing to have something that is properly and officially supported so no cat and mouse would be needed.

 

 

 

Share this post


Link to post
Share on other sites
7 hours ago, cakepie said:

@Lisias would you like me to help take a crack at MM4 compatibility? If so are you willing to require MM4+ dependency or would you insist on keeping backward compat for people using MM<4?

Please do this it would be so helpful to be able to use the welding mod on my main install. :)

Share this post


Link to post
Share on other sites
3 hours ago, Svm420 said:

Please do this it would be so helpful to be able to use the welding mod on my main install. :)

It's usable right now if you use MM3 or my personal fork for MM4 :)

5 hours ago, cakepie said:

However, just because the class has been that way for 5 years shouldn't be taken as a guarantee of anything, especially given the unsupported nature of what the UbioZur Welding code was doing with it -- not part of any explicit contract offered by MM to other mods.

This is not a job. We are not getting paid. There's no guarantees on nothing.

But we can do people's life easier or harder - and this will reflect on what people choose to use

 

Share this post


Link to post
Share on other sites
5 hours ago, cakepie said:

Not really, MM never intended for other mods to be able to call DataBaseReloadWithMM() , it has been private since 2.4.0 and internal before that, which is why blowfish said the UbioWeld code was doing unintended and unsupported things.

You missed the point completely. If a change was made on the method, I would had it fixed by now.

I'm talking on the class definition itself.

LoadingSystem was extending Unity's, and the change that broke me is that Unity's reflection ceased to work on it's and since Moni:'s Reflection is flawed, I ended up without a reliable and sturdy mechanism to find the class.

The fix I choose is not the only the easiest, but also the safest. There're few value on working  on a new mechanism that would ending up being brittle and leading people for asking for support constantly.

And this is the reason I shoved KSPe on my fork anyway, where at least I will confine the problem on a component that already have it. If something brake (and it will, due Mono's runtime data being corrupted when a exception happens anywhere else while loading DLLs), then I have only one thing to fix and update, instead of scattered code over multiple Add'Ons.

5 hours ago, cakepie said:

I've already started writing MMWrapper.cs, but let's see if MM is willing to have something that is properly and officially supported so no cat and mouse would be needed.

My intent precisely. If they rollback that single line, problem vanishes.

Of course that the new mechanism would not be recognised by WeldTool, but this is not a problem: a punctual update on the code and we would be fine.

But, and again, what broke UbioWeld was a change apparently unneeded. No used feature was changed, my MM4 fork is working perfectly fine with my two last releases by only changing a line back - all the rest was essentially the same.

Share this post


Link to post
Share on other sites
On 5/25/2019 at 10:29 PM, Lisias said:

You missed the point completely. If a change was made on the method, I would had it fixed by now.

I'm talking on the class definition itself.

LoadingSystem was extending Unity's, and the change that broke me is that Unity's reflection ceased to work on it's and since Moni:'s Reflection is flawed, I ended up without a reliable and sturdy mechanism to find the class.

The fix I choose is not the only the easiest, but also the safest. There're few value on working  on a new mechanism that would ending up being brittle and leading people for asking for support constantly.

And this is the reason I shoved KSPe on my fork anyway, where at least I will confine the problem on a component that already have it. If something brake (and it will, due Mono's runtime data being corrupted when a exception happens anywhere else while loading DLLs), then I have only one thing to fix and update, instead of scattered code over multiple Add'Ons.

My intent precisely. If they rollback that single line, problem vanishes.

Of course that the new mechanism would not be recognised by WeldTool, but this is not a problem: a punctual update on the code and we would be fine.

But, and again, what broke UbioWeld was a change apparently unneeded. No used feature was changed, my MM4 fork is working perfectly fine with my two last releases by only changing a line back - all the rest was essentially the same.

Don't mind me. Just randomly reading stuff and I couldn't help but be reminded of this one XKCD when I read your post: https://xkcd.com/1172/

Moving along now.. o/

Share this post


Link to post
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.