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

Alewx · September 29, 2016

3 hours ago, Soundwave__007 said:

@Alewx

The F3 menu shows only the stuff after the wings crashed on the runway.

Spacetape will just disapear, i tried that already.

I will try to attach the wing with a attachmentpoint to the mainbody. maybe it works, if not i activate unbreakable joints for testing.

Reveal hidden contents

Hmm I guess for a non node attachment it is too heavy.
But that it does not say it would break is quite strange.

Sresk · September 30, 2016

Hmm I'd like to use this for some of my SSTO part hwo does this impact aero dynamics... also I'm not pleased with it averaging the max temp allowed as that greatly impacts the front ofthe craft is there any way to change this?

Alewx · October 1, 2016

On ‎30‎.‎09‎.‎2016 at 6:46 AM, Sresk said:

Hmm I'd like to use this for some of my SSTO part hwo does this impact aero dynamics... also I'm not pleased with it averaging the max temp allowed as that greatly impacts the front ofthe craft is there any way to change this?

I'm a bit suporised as there is a dedicated setting for the max temperature processing.

Sresk · October 1, 2016

The settings I saw where use the lowest temp, and 2 ways of averaging the temp. The problem is that the nose should still have the same max temp max temp... this may not have a good solution... I'll just have to weld things without the nose cone or intake and then put that on the front.

Also I just welded a bunch of mk2 tanks together with an intake on the front as I tend to use that set up as an engine nacelle and then mount various engine on the back. (other than it averaging the temp) it worked pretty well. Except that the attachment node was WAYYY out in the back of the surface so if I attached my engine directly to the node it was floating in space several meters behind my welded part. Is there a settign I missed?

Lerpon · October 3, 2016

Does 2.3.3 work also for 1.1.3? or next update?

Alewx · October 4, 2016

2.3.3 seems to work with 1.1.3 but 1.2 will require an update.

Fwiffo · October 14, 2016

@Lerpon I can attest to what @Alewx said. I've been using it a bunch with 1.1.3.

Looking forward to the 1.2 update :-)

Fwiffo · October 14, 2016

Any interest in making this mod play friendlier with @Snark's IndicatorLights?

It assigns new modules to parts, sometimes multiple modules with the same name. Currently UbioZur replicates some of them in the welded part, but it's fairly naive and the indicator lights on the weldment tend not to work. I don't think it would be rocket science to summarize the rules for how its special modules should be handled during welding, and would be willing to take a crack at it if you're willing to take a crack at coding it.

Edited October 14, 2016 by Fwiffo

Turtles4Life · October 14, 2016

Will this be updated for 1.2?

Alewx · October 16, 2016

Update to UbioWeld Continued 2.3.4

Recompile for KSP 1.2
Slightly improved under the hood
added new Basic Moduleattributes

Download version 2.3.4 for KSP 1.2

On ‎14‎.‎10‎.‎2016 at 8:42 PM, Fwiffo said:

Any interest in making this mod play friendlier with @Snark's IndicatorLights?

It assigns new modules to parts, sometimes multiple modules with the same name. Currently UbioZur replicates some of them in the welded part, but it's fairly naive and the indicator lights on the weldment tend not to work. I don't think it would be rocket science to summarize the rules for how its special modules should be handled during welding, and would be willing to take a crack at it if you're willing to take a crack at coding it.

I need to investigate how the mod works before I can tell you anything about it.
But for the special case that the mod addds multiple modules with the same name, just add the module into the advanced config as a new "ModulesToMultiply". that would already do the trick for the first problem.

Space Scumbag · October 16, 2016

Ooh wee, thanks for the new update. This is one of the most important mods for me.

Fwiffo · October 17, 2016

On 10/16/2016 at 6:15 AM, Alewx said:

I need to investigate how the mod works before I can tell you anything about it.

@Snark has phenomenal documentation on his GitHub wiki. His modules follow a sort of MVP pattern.

I've been working on a fairly intricate craft making heavy use of weldments and IndicatorLights, which may be a perfect example / test subject for this. Feel free to grab the Hopper-Mk3-Beta1.zip mentioned in that post and poke around in it. In particular, the preweld file (Hopper-Mk3-Preweld.craft) compared to the post-weld parts generated from it (for the left pylon, right pylon and tank).

Post-weld work had to be done to get the IndicatorLights to function properly. e.g. If you look in Hopper-Mk3-RightPylon.cfg, you'll see stuff like:

	MODEL
	{
		model = Squad/Parts/Command/mk1LanderCan/model
		position = -0.032, 0.08, 0.232
		scale = 1, 1, 1
	}
	MODEL // IndicatorLight for Mk1 lander can (squareLamp index 0)
	{
		model = IndicatorLights/Meshes/squareLamp
		position = -0.032, -0.194, -0.627
		scale = 1, 0.25, 0.5
		rotation = 0, 180, 0
	}

	...

	MODEL
	{
		model = Squad/Parts/Resources/SurfaceScanner/SurfaceScanner
		position = 0.826, -0.27, 0.225
		scale = 1, 1, 1
		rotation = 0, 270, 270
	}
	MODEL // IndicatorLight for Surface Scanner (squareLamp index 1)
	{
		model = IndicatorLights/Meshes/squareLamp
		position = 1.046, -0.267, 0.274 // was 0.826, -0.223, -0.004
		scale = 1, 0.5, 0.5
		rotation = 0, 90, 270
	}

	...

	MODEL // IndicatorLight for Fuel Cell (rectangularIndicatorModel index 0)
	{
		model = IndicatorLights/Parts/fuelCells/rectangularIndicatorModel
		position = 0.612, 0.276, 0.969
		scale = 0.111, 0.8, 0.5 // 0.5, 0.65, 0.111 for squareLamp
		rotation = 0, 315, 0 // 0, 45, 0 for squareLamp
	}

His mod added those IndicatorLights meshes to the original parts, and as far as I can remember UbioZur included them just fine in the weldment (so that part works).

Further down you'll notice several ModuleControllableEmissive's. This is where UbioZur needs some intelligence added. Each emissive needs to be wired up to the same mesh it was associated with in the original part. On the modded stock parts, there's typically only one lamp mesh (or if multiple, they're all wired to the same behavior), so it's unambiguous. But since a weldment might wind up with several identical lamp meshes intended to exhibit different behaviors, he has a special syntax that include's a simple index number (after the colon) to tie each emissive to the correct mesh:

	// IndicatorLights emissives
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Meshes/squareLamp:0
		emissiveName = crewIndicator
	}
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Meshes/squareLamp:1
		emissiveName = surfaceScannerIndicator
	}
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Parts/fuelCells/rectangularIndicatorModel:0
		emissiveName = fuelCellIndicator
	}

	...

	// IndicatorLights controllers for lander can
	MODULE
	{
		name = ModuleCrewIndicatorToggle
		toggleName = indicatorToggle
	}
	MODULE
	{
		name = ModuleCrewIndicator
		emissiveName = crewIndicator
		toggleName = indicatorToggle
		slot = 0
	}

	...

	MODULE // IndicatorLights controllers for Surface Scanner
	{
		name = ModuleResourceScannerIndicator
	}
	MODULE
	{
		name = ModuleBiomeScannerIndicator
		emissiveName = surfaceScannerIndicator
		inactiveColor = ModuleResourceScannerIndicator
		readyColor = blink($ToggleLED, 200, $Off, 200)
	}

	...

	MODULE // IndicatorLights controller for fuel cell
	{
		name = ModuleConverterIndicator
		converterName = Fuel Cell
		emissiveName = fuelCellIndicator
		activeColor = $ToggleLED
		inactiveColor = #282828 // better "off" color (doesn't seem to work)
	}

Some unique emissiveName's need to be generated for each one (similar to how you do so already for attachment nodes), and correlation maintained with the emissiveName's on the original controller modules that came in along with them.

I know this all sounds SUPER complicated at first glance, but once you've actually gone through the exercise of setting up some indicator lights on a sample part, it's quite straightforward. His mod is really well thought out and seems to be gaining traction from other players/modders, so it would be absolutely stellar if UbioZur were made more compatible with it. Even if it doesn't get things 100% perfect, I'm sure there's low hanging fruit that could be implemented to massively cut down on the amount of post-weld work required.

Note if you're going to look at my weldments, be aware he made some enhancements in the last release to address problems I found with parts that have multiple science modules. I haven't yet worked those enhancements into my craft (that will be in upcoming Beta 2) but there's likely a bit of straightforward special handling needed around it as well (e.g. set experimentId field on ModuleScienceDataIndicator's). Also the Notes.txt file in the zip is a little old (from before I started integrating IndicatorLights)

Ping me (or maybe even Snark) if I can help with this at all. I'm hoping it piques your interest.

On a different topic, during construction of this craft I also noticed a few other "best practices" your mod might adopt to improve the success rate of weldments. If you're interested, take a look at the points marked "solved" in this post. The main one is the ordering of ModuleAnimationGeneric, which I opened an issue for (not trying to nag, just want to make sure you saw it).

Thanks for all your hard work maintaining the UbioZur welding mod - it's really awesome!

ps. Another one I caught; adding here to consolidate "documentation":
The lowScienceThreshold and highScienceThreshold values should not be accumulated/multiplied when there are multiple ModuleScienceDataIndicator's.

Edited October 22, 2016 by Fwiffo
Add note about ModuleScienceDataIndicator thesholds

Yargnit · October 17, 2016

So I've been trying to use this to up-size my 1.2 carrier to full Nimitz size. from it's current scale. (roughly 2/3 size) http://i.imgur.com/1GK0cTI.png However I'm running into an issue similar to what large fairing exhibit where they just take ages to load into the flight scene after being launched. Currently with 900ish parts merged down to 5 main parts, plus a smattering of other parts attached (less than 20) I've been waiting for at least 15 minutes for the flight scene to load. Task manager still shows the CPU working, but I'm not sure exactly whats going on. The parts themselves that are merged are basically just hundreds of mk3 fuel tanks for the hull, so despite the huge part-count it's not exactly a complex craft.

I know this is probably a Kerbal issue and not one that the mod can directly fix, but I'm wondering if you might have any ideas? My guess based off the similar fairing issue is it has something to do with trying to take the separate colliders for all of the parts and merge them together to make a single one for the merged model, but that's just a shot in the dark. Any thoughts would be greatly appreciated. (Now more like 20 minutes going on after writing this post, i can still see KSP's CPU use moving, and RAM slowly climbing, but we haven't loaded yet)

Update; it took 45 minutes give or take for the craft to load into the scene, and it appears to hang for just as long when flying within render range of it.

Edited October 17, 2016 by Yargnit

Alewx · October 17, 2016

1 hour ago, Yargnit said:

So I've been trying to use this to up-size my 1.2 carrier to full Nimitz size. from it's current scale. (roughly 2/3 size) http://i.imgur.com/1GK0cTI.png However I'm running into an issue similar to what large fairing exhibit where they just take ages to load into the flight scene after being launched. Currently with 900ish parts merged down to 5 main parts, plus a smattering of other parts attached (less than 20) I've been waiting for at least 15 minutes for the flight scene to load. Task manager still shows the CPU working, but I'm not sure exactly whats going on. The parts themselves that are merged are basically just hundreds of mk3 fuel tanks for the hull, so despite the huge part-count it's not exactly a complex craft.

I know this is probably a Kerbal issue and not one that the mod can directly fix, but I'm wondering if you might have any ideas? My guess based off the similar fairing issue is it has something to do with trying to take the separate colliders for all of the parts and merge them together to make a single one for the merged model, but that's just a shot in the dark. Any thoughts would be greatly appreciated. (Now more like 20 minutes going on after writing this post, i can still see KSP's CPU use moving, and RAM slowly climbing, but we haven't loaded yet)

Update; it took 45 minutes give or take for the craft to load into the scene, and it appears to hang for just as long when flying within render range of it.

That is quite normal, because Unity has to deal with every single object. It might look simple but under the surface is happening a lot more, so loading such a huge craft is taking quite some time. but 45 Minutes seems a bit ridiculous.
What CPU and GPU do you have? Also welding the whole craft into just a single part or 5 is not always the best idea, it is a bit try and error to find the best solution for a welded craft.

6 hours ago, Fwiffo said:
@Snark has phenomenal documentation on his GitHub wiki. His modules follow a sort of MVP pattern.

I've been working on a fairly intricate craft making heavy use of weldments and IndicatorLights, which may be a perfect example / test subject for this. Feel free to grab the Hopper-Mk3-Beta1.zip mentioned in that post and poke around in it. In particular, the preweld file (Hopper-Mk3-Preweld.craft) compared to the post-weld parts generated from it (for the left pylon, right pylon and tank).

Post-weld work had to be done to get the IndicatorLights to function properly. e.g. If you look in Hopper-Mk3-RightPylon.cfg, you'll see stuff like:
	MODEL
	{
		model = Squad/Parts/Command/mk1LanderCan/model
		position = -0.032, 0.08, 0.232
		scale = 1, 1, 1
	}
	MODEL // IndicatorLight for Mk1 lander can (squareLamp index 0)
	{
		model = IndicatorLights/Meshes/squareLamp
		position = -0.032, -0.194, -0.627
		scale = 1, 0.25, 0.5
		rotation = 0, 180, 0
	}

	...

	MODEL
	{
		model = Squad/Parts/Resources/SurfaceScanner/SurfaceScanner
		position = 0.826, -0.27, 0.225
		scale = 1, 1, 1
		rotation = 0, 270, 270
	}
	MODEL // IndicatorLight for Surface Scanner (squareLamp index 1)
	{
		model = IndicatorLights/Meshes/squareLamp
		position = 1.046, -0.267, 0.274 // was 0.826, -0.223, -0.004
		scale = 1, 0.5, 0.5
		rotation = 0, 90, 270
	}

	...

	MODEL // IndicatorLight for Fuel Cell (rectangularIndicatorModel index 0)
	{
		model = IndicatorLights/Parts/fuelCells/rectangularIndicatorModel
		position = 0.612, 0.276, 0.969
		scale = 0.111, 0.8, 0.5 // 0.5, 0.65, 0.111 for squareLamp
		rotation = 0, 315, 0 // 0, 45, 0 for squareLamp
	}
His mod added those IndicatorLights meshes to the original parts, and as far as I can remember UbioZur included them just fine in the weldment (so that part works).

Further down you'll notice several ModuleControllableEmissive's. This is where UbioZur needs some intelligence added. Each emissive needs to be wired up to the same mesh it was associated with in the original part. On the modded stock parts, there's typically only one lamp mesh (or if multiple, they're all wired to the same behavior), so it's unambiguous. But since a weldment might wind up with several identical lamp meshes intended to exhibit different behaviors, he has a special syntax that include's a simple index number (after the colon) to tie each emissive to the correct mesh:
	// IndicatorLights emissives
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Meshes/squareLamp:0
		emissiveName = crewIndicator
	}
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Meshes/squareLamp:1
		emissiveName = surfaceScannerIndicator
	}
	MODULE
	{
		name = ModuleControllableEmissive
		target = IndicatorLights/Parts/fuelCells/rectangularIndicatorModel:0
		emissiveName = fuelCellIndicator
	}

	...

	// IndicatorLights controllers for lander can
	MODULE
	{
		name = ModuleCrewIndicatorToggle
		toggleName = indicatorToggle
	}
	MODULE
	{
		name = ModuleCrewIndicator
		emissiveName = crewIndicator
		toggleName = indicatorToggle
		slot = 0
	}

	...

	MODULE // IndicatorLights controllers for Surface Scanner
	{
		name = ModuleResourceScannerIndicator
	}
	MODULE
	{
		name = ModuleBiomeScannerIndicator
		emissiveName = surfaceScannerIndicator
		inactiveColor = ModuleResourceScannerIndicator
		readyColor = blink($ToggleLED, 200, $Off, 200)
	}

	...

	MODULE // IndicatorLights controller for fuel cell
	{
		name = ModuleConverterIndicator
		converterName = Fuel Cell
		emissiveName = fuelCellIndicator
		activeColor = $ToggleLED
		inactiveColor = #282828 // better "off" color (doesn't seem to work)
	}
Some unique emissiveName's need to be generated for each one (similar to how you do so already for attachment nodes), and correlation maintained with the emissiveName's on the original controller modules that came in along with them.

I know this all sounds SUPER complicated at first glance, but once you've actually gone through the exercise of setting up some indicator lights on a sample part, it's quite straightforward. His mod is really well thought out and seems to be gaining traction from other players/modders, so it would be absolutely stellar if UbioZur were made more compatible with it. Even if it doesn't get things 100% perfect, I'm sure there's low hanging fruit that could be implemented to massively cut down on the amount of post-weld work required.

Note if you're going to look at my weldments, be aware he made some enhancements in the last release to address problems I found with parts that have multiple science modules. I haven't yet worked those enhancements into my craft (that will be in upcoming Beta 2) but there's likely a bit of straightforward special handling needed around it as well (e.g. set experimentId field on ModuleScienceDataIndicator's). Also the Notes.txt file in the zip is a little old (from before I started integrating IndicatorLights)

Ping me (or maybe even Snark) if I can help with this at all. I'm hoping it piques your interest.

On a different topic, during construction of this craft I also noticed a few other "best practices" your mod might adopt to improve the success rate of weldments. If you're interested, take a look at the points marked "solved" in this post. The main one is the ordering of ModuleAnimationGeneric, which I opened an issue for (not trying to nag, just want to make sure you saw it).

Thanks for all your hard work maintaining the UbioZur welding mod - it's really awesome!

This will take some time, no matter how well the documentation is. I still have to make it workable in a generic way.
With Welding Continued, we implemented a method to have it working on the values and less on single modules, because when you design it that way, you have to make a new update for every single mod that appears and adds a module.
And the way back to handle every module in a special way is nothing I want to return to, it would increase the workload to maintain welding exponential. the goal is to make welding able to handle everything, but based on the user defined configuration in the addition file, which provides the data to process the single values correct.

Also remember Welding is not able to produce an everything is fine solution. There will often be cases where it will take some post welding editing to get everything correct.

Yargnit · October 17, 2016

18 hours ago, Alewx said:

That is quite normal, because Unity has to deal with every single object. It might look simple but under the surface is happening a lot more, so loading such a huge craft is taking quite some time. but 45 Minutes seems a bit ridiculous.
What CPU and GPU do you have? Also welding the whole craft into just a single part or 5 is not always the best idea, it is a bit try and error to find the best solution for a welded craft.

I just remember back in the day (when welder 1st came out) merging a lot more parts (something like 4k+ panels) into one without any issue. Also the fact that I could have launched this current ship completely unwelded and it would have just taken a few seconds to load rather than the better part of an hour. My next step is to try welding it into like 50ish segments that are like 15-35ish parts each and see how that performs, I just know that back before KSP release this wouldn't have been an issue as long as I was selective with which parts I merged. Also, CPU/GPU 100% not an issue (OC'd 6700k, 32gb, & 980)

Like I said, pretty sure it's just a KSP issue ever since they changed stuff for fairing segment auto-strutting and stuff (when large fairing started taking minutes to load) but just taking a shot that you might have a better idea than just working around it.

So I did some further testing; if you keep your welds in the to 30 something parts each you can put several dozen of them on a craft without issue. I think I did something like 1000 raw parts welded into 30 part chunks and they loaded fine. (even loading 2k parts in 30 part chunks wasn't a disaster) But start getting 50+ or espesially 100+ part welds in there and the loading speed tanks. Funny enough, a 1k part weld will load fine and almost instantly, by itself. But attach even a few other minor parts to it and performance tanks rapidly. A single 1k part weld loads in a few seconds, attach another <100 part weld to it, or a couple dozen random loose pieces, and you're up to a couple minutes load time already. My 1k part weld, with 2 ~75 part welds, 2~25 part welds, and a dozen assorted parts on it was 45 minutes when the same 1k part weld alone was a matter of seconds. Very odd

Edited October 18, 2016 by Yargnit
Further testing

Fwiffo · October 21, 2016

Hey @Yargnit thanks for sharing that. Was that "further testing" under an old KSP version or more recent ones (1.1.3 / 1.2)?

Edited October 21, 2016 by Fwiffo

Alewx · October 21, 2016

3 minutes ago, Fwiffo said:

Hey @Yargnit thanks for sharing that. Was that "further testing" under an old KSP version or more recent ones (1.1.3 / 1.2)?

These results are already quite confusing.

Yargnit · October 22, 2016

Those were from 1.2.

Also, different question, and clue how to place welded parts into custom categories? Specifically the 'Construction" category added by Roverdudes Konstruction mod. The label doesn't show up as an option in welder when welding parts, and indeed in the .cfg files of parts he has in that tab they are listed as in 'none' so I'm not sure how they get assigned to there. (even if I have to do it manually after welding, just to keep from cluttering any other tab)

Fwiffo · October 22, 2016

Hey @Alewx, I know I'm always suggesting stuff which represents more work for you ;-).

A while back I highlighted a problem or two relating to massless parts. IIRC you made some improvements (which is awesome) but the mod still doesn't handle massless parts quite the way I think it should.

In KSP, the mass of physicsless parts does not disappear. It gets added to the the parent part. This impacts the total mass of your craft, as well as its COM.

The mod gives you the option to "Ignore massless parts", but AFAIK that only let's you a) treat them like normal parts, or b) discard their mass altogether. Neither of these options maintains fidelity with what you created in the VAB/SPH.

e.g. I will often position parts very precisely to achieve perfect balance in my craft (with the help of RCS Build Aid). After I weld sections of it and reassemble them, the resulting CoM is off slightly and needs minor adjustment. I think the above is why.

Would it be feasible to make the mod treat physicsless parts the same way the game does, for the purposes of calculating the weldment's total mass and (more importantly) CoM?

I know I inquired about making some code changes to tackle this. I haven't managed to as of yet (at the time I thought a simple change to just add the discarded mass to the final part would be sufficient, but now I realize getting an accurate CoM is a bit more involved), so thought I'd bring this up again.

Edited October 22, 2016 by Fwiffo

Fwiffo · October 22, 2016

37 minutes ago, Yargnit said:

Also, different question, and clue how to place welded parts into custom categories? Specifically the 'Construction" category added by Roverdudes Konstruction mod. The label doesn't show up as an option in welder when welding parts, and indeed in the .cfg files of parts he has in that tab they are listed as in 'none' so I'm not sure how they get assigned to there. (even if I have to do it manually after welding, just to keep from cluttering any other tab)

I'm guessing you already tried playing with the "category" field in the .cfg?

It sounds like that mod is perhaps doing something special to group parts? I remember I used to use Filter Extensions and in it you actually set up new "virtual categories" based on rules (e.g. I had one to put all my manufacturer = "Fwiffo Industries" or Author = "Fwiffo" parts into one tab). Maybe he's doing something similar?

Fwiffo · October 22, 2016

@Alewx Is it safe to add FlagDecal to the ModulesToIgnore section of moduleAttributeList.xml?

The mod is adding this module to my weldment (I guess it exists on pods while in the Editor?), but when my craft incorporating the weldment launches, the FlagDecal part gets removed (not sure if KSP is doing it, your mod, or something else). That triggers "PartModule indexing mismatch" warnings in the log, and KSP goes and tries to remap PartModules (between the saved craft which is missing the module, and the one in the weldment's CFG file which has it), which was causing me substantial grief. E.g. If you have multiple ModuleEnviroSensor modules in the part when the remapping occurs, they get screwed up and the last one says "NO POWER!" in its display. (See #6 here)

I noticed your mod adds its own WeldedFlagDecal to the end of the CFG file, which seems sufficient. I've been manually removing FlagDecal from my weldments, and leaving that one, to make them work properly.

If I add FlagDecal to ModulesToIgnore, with the welder still add WeldedFlagDecal?

Is there any reason not to make this change to the moduleAttributeList.xml that gets distributed with your mod?

Thanks!

Edit: Well, I did find one case where FlagDecal is needed. On a part where I turned the flag off, I had to leave that module in and comment out WeldedFlagDecal instead, to avoid getting a white box. Could you elaborate a little to me on how FlagDecal / WeldedFlagDecal are supposed to work?

Edit2: I've also been commenting out these modules; might make sense to add them to global ignore list as well?

SCANRPMStorage (dynamically added by KAS?)
ModuleTCA (dynamically added by ThrottleControlledAvionics)

Edit3: If I'm interpreting things correctly, ModuleEnviroSensor_sensorType should be added to BreakingModuleAttributes. Presently if you weld together multiple science sensors only one ModuleEnviroSensor gets included (it should include one for each different experiment type e.g. PRES, ACC, GRAV, etc).

Edited October 22, 2016 by Fwiffo

Tarheel1999 · October 22, 2016

3 hours ago, Yargnit said:

Those were from 1.2.

Also, different question, and clue how to place welded parts into custom categories? Specifically the 'Construction" category added by Roverdudes Konstruction mod. The label doesn't show up as an option in welder when welding parts, and indeed in the .cfg files of parts he has in that tab they are listed as in 'none' so I'm not sure how they get assigned to there. (even if I have to do it manually after welding, just to keep from cluttering any other tab)

Currently RD sorts his mods by manufacturer using custom code. Just match the manufacturer's name of the parts in that mod.

Alewx · October 23, 2016

On ‎22‎.‎10‎.‎2016 at 11:39 AM, Fwiffo said:

@Alewx Is it safe to add FlagDecal to the ModulesToIgnore section of moduleAttributeList.xml?

The mod is adding this module to my weldment (I guess it exists on pods while in the Editor?), but when my craft incorporating the weldment launches, the FlagDecal part gets removed (not sure if KSP is doing it, your mod, or something else). That triggers "PartModule indexing mismatch" warnings in the log, and KSP goes and tries to remap PartModules (between the saved craft which is missing the module, and the one in the weldment's CFG file which has it), which was causing me substantial grief. E.g. If you have multiple ModuleEnviroSensor modules in the part when the remapping occurs, they get screwed up and the last one says "NO POWER!" in its display. (See #6 here)

I noticed your mod adds its own WeldedFlagDecal to the end of the CFG file, which seems sufficient. I've been manually removing FlagDecal from my weldments, and leaving that one, to make them work properly.

If I add FlagDecal to ModulesToIgnore, with the welder still add WeldedFlagDecal?

Is there any reason not to make this change to the moduleAttributeList.xml that gets distributed with your mod?

Thanks!

Edit: Well, I did find one case where FlagDecal is needed. On a part where I turned the flag off, I had to leave that module in and comment out WeldedFlagDecal instead, to avoid getting a white box. Could you elaborate a little to me on how FlagDecal / WeldedFlagDecal are supposed to work?

Edit2: I've also been commenting out these modules; might make sense to add them to global ignore list as well?

SCANRPMStorage (dynamically added by KAS?)

ModuleTCA (dynamically added by ThrottleControlledAvionics)

Edit3: If I'm interpreting things correctly, ModuleEnviroSensor_sensorType should be added to BreakingModuleAttributes. Presently if you weld together multiple science sensors only one ModuleEnviroSensor gets included (it should include one for each different experiment type e.g. PRES, ACC, GRAV, etc).

The flagDecal will just get the flag assigned once at loading or at changing of the flag. the weldedFlagDecal is just an Extension, which replaced the normal flagDecal, because it works on multiple of them.
The White square means it is registered as a flag decal surface but it does not get the flag assigned, due to it beeing disabled at the welding time.

The new attributes for sensor can simply get added.
The ignoremodules also can simply get added.

Yargnit · October 23, 2016

On 10/22/2016 at 3:29 AM, Tarheel1999 said:

Currently RD sorts his mods by manufacturer using custom code. Just match the manufacturer's name of the parts in that mod.

I tried renaming a parts manufacturer to the same one he uses for parts in the construction tab, and they still don't show in there.

Alewx · October 24, 2016

16 hours ago, Yargnit said:

I tried renaming a parts manufacturer to the same one he uses for parts in the construction tab, and they still don't show in there.

Did you ask RoverDude? I do see a chance that the whole category is based one some source that is contained in his mod.

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation