[1.1.2] Orbital Utility Vehicle v1.2.4

zer0Kerbal · May 21, 2019

1 hour ago, COL.R.Neville said:

yeah use node helper to point it anyway you want.

did. done. now about that cargo bay...

Stratickus · May 22, 2019

23 hours ago, zer0Kerbal said:

have always enjoyed this mod. Just one question about the two adapters - they both have attachment nodes in the middle - both set to attach the wrong way so won't attach.

What are those for? one has a cargo bay that doesn't work - does anyone have a patch/fix for that?

Like this?

I'm not exactly sure what you're talking about with the nodes, but the push adapter is meant to have the command pod nestled inside the adapter as an option.

As for the cargo bays, I imagine you have KIS installed. If you scroll down to the very bottom of the .cfg file, having KIS installed removes the cargo bays.

Cheers,

Stone Blue · May 22, 2019

5 hours ago, COL.R.Neville said:

yeah use node helper to point it anyway you want.

Yeah, i had done a bunch of work on this mod, hoping to revive it... lots of the nodes were reversed ... I used Node Helper to fix them...

The models and textures are quite un-optimized tho...
I was switching away from the Firespitter dependency, and setting everything up with B9 PartSwitch.

COL.R.Neville · May 22, 2019

8 hours ago, Stone Blue said:

Yeah, i had done a bunch of work on this mod, hoping to revive it... lots of the nodes were reversed ... I used Node Helper to fix them...

The models and textures are quite un-optimized tho...
I was switching away from the Firespitter dependency, and setting everything up with B9 PartSwitch.

for textures ive always just used dds4ksp. you just have to be careful with the png's since you can wipe out all your toolbar icons if you arent careful.

another thing is I'm not really a blender guy but ive found that the list of textures a model is looking for is at the bottom of the .mu files.

Seems like lots of people seem firespitter averse i like it kinda easy to work with and since its all over usi i figure its one thing that will be kept up to date. But i am just usually switching textures and thats it. If you are trying to switch models and textures I can see using b9 instead.

like for this i would strip out all the scan sat stuff, kis/kas stuff. get the command pod itself sorted. then take everything back to 143 create a craft and reattach any kis/kas stuff you want on it and weld it. just be careful with the back hatch. then bring the welded definition back to 170. sorta like doing a frame off restoration. thats usually what i do with stuff like this.

Edited May 22, 2019 by COL.R.Neville

linuxgurugamer · May 22, 2019

9 hours ago, Stone Blue said:

Yeah, i had done a bunch of work on this mod, hoping to revive it... lots of the nodes were reversed ... I used Node Helper to fix them...

The models and textures are quite un-optimized tho...
I was switching away from the Firespitter dependency, and setting everything up with B9 PartSwitch.

What are the differences between what you did and what @Starwaster did ?

I was thinking of including this in a small pack of mods that make sense together , along the lines of SpaceTux Industries Recycled Parts, but if you are going to do anything, then I won't include this. Otherwise, I'd appreciate seeing any changes that you made

zer0Kerbal · May 22, 2019

did the winch on the front of the manned cab once work?

DStaal · May 22, 2019

1 hour ago, zer0Kerbal said:

did the winch on the front of the manned cab once work?

Yeah, with KAS. Which just underwent a major overhaul - you could probably get it working again with a config change.

Stone Blue · May 22, 2019

10 hours ago, COL.R.Neville said:

for textures ive always just used dds4ksp.

No, I mean the texturing and texture layout/UV mapping...

9 hours ago, linuxgurugamer said:

What are the differences between what you did and what @Starwaster did ?

I'm not sure what Starwaster did.. vOv

Heck, I cant even remember fully what *I* did with it ~1yr or so ago... I have CRS really bad

I'll dig it up and see if there was anything significant other than some FS to B9 cfg work I did on it...

I had plans to improve the mod quite a bit, and release it... But i have so many projects like this that I have started and not been able to finish (possibly due to ADHD vOv ), I would say dont let me stop you from doing something with it. You've already picked up quite a few things I was poking into and hoping to "continue", at one time or another ... lol

1 minute ago, DStaal said:

Yeah, with KAS. Which just underwent a major overhaul - you could probably get it working again with a config change.

Yes, it did work... Idk, tho... i hear legacy mods with KAS/KIS need *quite* a bit of work for the new KAS/KIS? vOv

I think thats the one thing that was gonna kill off SEP anyway, even before the new DLC announced a "stockified" version...

Edited May 22, 2019 by Stone Blue

DStaal · May 22, 2019

1 hour ago, Stone Blue said:

Yes, it did work... Idk, tho... i hear legacy mods with KAS/KIS need *quite* a bit of work for the new KAS/KIS? vOv

I think thats the one thing that was gonna kill off SEP anyway, even before the new DLC announced a "stockified" version...

There's a new mechanic, in that there's a 'source' and a 'destination' for connectors in all cases now - so mods that relied on being able to just plop a connector port on and connect it to any other connector port need a redesign. That covers SEP, WBI, MKS, KBPS - which all made heavy use of that.

This mod basically has a replacement winch model. The winch barely even changed models in KAS, it just became the source of a new type of connection - I expect you could copy-paste the config from the new KAS winch and that would be it. (At least for that part.)

Tonka Crash · May 23, 2019

1 hour ago, Stone Blue said:

I think thats the one thing that was gonna kill off SEP anyway, even before the new DLC announced a "stockified" version...

29 minutes ago, DStaal said:

That covers SEP, WBI, MKS, KBPS - which all made heavy use of that.

KPBS, WBI have both been updated for KAS compatibility. A PR for MKS was submitted weeks ago to get it updated. @zer0Kerbal posted a patch for SEP in that thread to fix it. These are the easy ones with relatively simple config file changes. The only real problem I've run into is Extraplanetary Launchpads has code built around KIS & KAS that's throwing exceptions and has broken functionality that's more than just a .cfg file update.

zer0Kerbal · May 23, 2019

2 hours ago, DStaal said:

Yeah, with KAS. Which just underwent a major overhaul - you could probably get it working again with a config change.

am looking into it. like you said - should just be another relatively simple MM patch to remove old and add new. Which would be better - the resource transfer or the heavy duty winch?

10 minutes ago, Tonka Crash said:

KPBS, WBI have both been updated for KAS compatibility. A PR for MKS was submitted weeks ago to get it updated. @zer0Kerbal posted a patch for SEP in that thread to fix it. These are the easy ones with relatively simple config file changes. The only real problem I've run into is Extraplanetary Launchpads has code built around KIS & KAS that's throwing exceptions and has broken functionality that's more than just a .cfg file update.

SimpleConstruction has been working for me - just need the lastest EL.dll and using NSSC with the survey stakes and mallet. Even have those stacking now using KIS.

Tonka Crash · May 23, 2019

2 minutes ago, zer0Kerbal said:

am looking into it. like you said - should just be another relatively simple MM patch to remove old and add new. Which would be better - the resource transfer or the heavy duty winch?

I'd start with copying the heavy duty winch to replace the winch in this one.

zer0Kerbal · May 23, 2019

3 minutes ago, Tonka Crash said:

I'd start with copying the heavy duty winch to replace the winch in this one.

the following makes me think about including the old parts...

    MODULE
   {
       name = ModuleKISPartMount
       mountedPartNode = portNode
       sndStorePath = KIS/Sounds/containerMount
       allowRelease = false
       MOUNT
       {
           attachNode = bottom
           allowedPartName= KAS_Hook_Anchor
           allowedPartName= KAS_Hook_Magnet
           allowedPartName= KAS_Hook_Harpoon
           allowedPartName= KAS_Hook_GrapplingHook
       }
   }

Tonka Crash · May 23, 2019

@zer0Kerbal The problem is those parts are no long being distributed as part of a current KAS install and they aren't supported in the new KAS, so even if you do allow them to attach to the winch they won't attach to other ships or asteroids like they did in the old KAS. Eventually Igorz will get around to updating them.

You might try the stock grabber as an alternative although it's kind of big. Today, I've been experimenting with a mini grabber from the Stock Mining Expansion with a crane design that uses the KAS winch on the end of the boom.

zer0Kerbal · May 23, 2019

1 minute ago, Tonka Crash said:

@zer0Kerbal The problem is those parts are no long being distributed as part of a current KAS install and they aren't supported in the new KAS, so even if you do allow them to attach to the winch they won't attach to other ships or asteroids like they did in the old KAS. Eventually Igorz will get around to updating them.

You might try the stock grabber as an alternative although it's kind of big. Today, I've been experimenting with a mini grabber from the Stock Mining Expansion with a crane design that uses the KAS winch on the end of the boom.

added benefit - can attach (really) attach mini/micro grabbing unit to the winch in the VAB unlike the magnet/anchor/harpoon/hook.

Stone Blue · May 23, 2019

41 minutes ago, Tonka Crash said:

KPBS, WBI have both been updated for KAS compatibility. A PR for MKS was submitted weeks ago to get it updated. @zer0Kerbal posted a patch for SEP in that thread to fix it. These are the easy ones with relatively simple config file changes. The only real problem I've run into is Extraplanetary Launchpads has code built around KIS & KAS that's throwing exceptions and has broken functionality that's more than just a .cfg file update.

Ok... I know CobaltWolf was talking about needing to make new plug models or soemthing for SEP, due to the KAS/KIS overhaul... So I thought there was moar involved than just patching ... vOv

linuxgurugamer · May 23, 2019

4 hours ago, Stone Blue said:

I think thats the one thing that was gonna kill off SEP anyway, even before the new DLC announced a "stockified" version...

The end of SEP was announced hours before the DLC announcement. Totally unrelated

DStaal · May 23, 2019

13 hours ago, Tonka Crash said:

KPBS, WBI have both been updated for KAS compatibility. A PR for MKS was submitted weeks ago to get it updated. @zer0Kerbal posted a patch for SEP in that thread to fix it. These are the easy ones with relatively simple config file changes. The only real problem I've run into is Extraplanetary Launchpads has code built around KIS & KAS that's throwing exceptions and has broken functionality that's more than just a .cfg file update.

True, but in comparison there's a theoretical model mismatch between what they were doing and what the new KAS was doing, while there isn't one here. It was a solvable mismatch, but it was there. (And yeah, I've been reading the stuff on EL. Haven't been testing that out, even with EL installed - AFAICT the latest EL still warns on startup that it's not comparable with 1.7.)

linuxgurugamer · May 23, 2019

For all interested, I've started integrating all the patches as well as adding the B9PartSwitch module as the primary color/fuel switcher. I didn't remove the others, but updated the configs so there won't be any conflict.

The repo is here:

https://github.com/linuxgurugamer/OrbitalTug

If you just want to download the zip, it's here:

https://github.com/linuxgurugamer/OrbitalTug/raw/master/OrbitalTug-alpha.zip

For now, I'll be curating the mod (ie: being a common location managing all supplied patches). I do intend to do a full adoption in the future, but am rather busy right now. Also, I'm not too familiar with the KAS/KIS internals, so any patches which addresses those issues will be appreciated.

Changes are:

Merged patches by @Deimos Rast and @LeLeon
Merged patch by @Starwaster
Added B9PartSwitcher code, will be primary if it's there

Note that the "merged" patches are still in a patch form (ie: MM patch), but are now in the full zip. As time goes on I will be doing an actual merge to eliminate the need for the patches

Edited May 23, 2019 by linuxgurugamer

Tonka Crash · May 23, 2019

40 minutes ago, DStaal said:

AFAICT the latest EL still warns on startup that it's not comparable with 1.7.)

I went looking to suppress that message since it's about as valid as the compatibility messages from miniAVC. It turns out that EL doesn't use the KSP-AVC infrastructure at all, the check is internal to EL, same with Kopernicus. So the only way to suppress it is to change the code. I tested EL in 1.6 and it has the same problems as 1.7 if you update KIS/KAS. I've actually been able to build things with stakes in 1.7, it's just the launchpads that seem broken.

DStaal · May 23, 2019

1 hour ago, Tonka Crash said:

I went looking to suppress that message since it's about as valid as the compatibility messages from miniAVC. It turns out that EL doesn't use the KSP-AVC infrastructure at all, the check is internal to EL, same with Kopernicus. So the only way to suppress it is to change the code. I tested EL in 1.6 and it has the same problems as 1.7 if you update KIS/KAS. I've actually been able to build things with stakes in 1.7, it's just the launchpads that seem broken.

I tend to give these types of messages a pass - there really is no good way to conclusively say what versions of KSP a mod will be compatible with in the future, and no good way for an external program to say whether a mod is currently compatible other than asking it. The latest KSP-AVC has a good solution, I think. I take the ones by the mod itself more seriously - both because it has better ability to test what it needs, and because it also has the ability to disable itself if the test doesn't pass. (Which some mods have done.)

linuxgurugamer · May 23, 2019

1 hour ago, Tonka Crash said:

I went looking to suppress that message since it's about as valid as the compatibility messages from miniAVC. It turns out that EL doesn't use the KSP-AVC infrastructure at all, the check is internal to EL, same with Kopernicus. So the only way to suppress it is to change the code. I tested EL in 1.6 and it has the same problems as 1.7 if you update KIS/KAS. I've actually been able to build things with stakes in 1.7, it's just the launchpads that seem broken.

The internal check done by the mods that do is done for very good reasons, but it doesn't have any relation to the external .version file which is usually included with the mod. The .version file is used for, among other things, notifying you of any updates to installed mods. The internal checks are only to be sure the mod will run properly on the game, they don't (to my knowledge) do any external checks for updates.

linuxgurugamer · May 23, 2019

2 hours ago, linuxgurugamer said:

For all interested, I've started integrating all the patches as well as adding the B9PartSwitch module as the primary color/fuel switcher. I didn't remove the others, but updated the configs so there won't be any conflict.

The repo is here:

https://github.com/linuxgurugamer/OrbitalTug

If you just want to download the zip, it's here:

https://github.com/linuxgurugamer/OrbitalTug/raw/master/OrbitalTug-alpha.zip

For now, I'll be curating the mod (ie: being a common location managing all supplied patches). I do intend to do a full adoption in the future, but am rather busy right now. Also, I'm not too familiar with the KAS/KIS internals, so any patches which addresses those issues will be appreciated.

Changes are:

Merged patches by @Deimos Rast and @LeLeon

Merged patch by @Starwaster

Added B9PartSwitcher code, will be primary if it's there

Note that the "merged" patches are still in a patch form (ie: MM patch), but are now in the full zip. As time goes on I will be doing an actual merge to eliminate the need for the patches

Following up to my post:

I will accept patches and changes in any form. Ideally they would come in as a git PR, but I recognize that not everyone is fluent in git. So the following applies:

In order of preference:

Patchfile via PR to git repo
Direct change to file(s) vi a PR to git repo
Patchfile via post in this thread (please put it into a code block)
Direct change to file via an external link such as Dropbox, GoogleDrive, etc.
Any other method which gets the idea across. It must be complete, you can't just say "remove fuel from yyy"

zer0Kerbal · May 24, 2019

Okay -

first attempt at updating KAS/KIS successful.
- Winch working with supplied model. Placement a little off, but working.
- Am debating about leaving old KAS modules in, so will work with older KAS versions.
- am thinking should remove patch from part.cfg and make separate patch file.
Restock light patch. First attempt working.
- issue for manned cab - two separate lights, now one control.
- lights not bright enough on 0.4 setting, so am bumping to 0.6
adding CCK patch and icons
patch to correct attach nodes on adapters done.
am debating about adding attach nodes to engines and symmetrical attach nodes to core (x4)
- comments?

Will supply here until completely correct then will do as @linuxgurugamer asks and do a PR on github.

KAS

Spoiler


// Correct KAS
@PART[OrbitalTugPod]:NEEDS[OrbitalTug,KAS]:Final
{
	MODEL
	{
		model = OrbitalTug/pod/widgets/OUVWinch
		texture = fwdAdaptor, OrbitalTug/adaptor/fwdAdaptor
		scale = 0.9,0.9,0.9
		position = 0,0.85,0.18
		rotation = -90,0,0
	}
	
	MODEL
	{
		model = KAS/Models/CommonConnector/Connector
	}
	
	node_stack_front = 0.0, 1.11, 0.2258241, 0.0, 1.0, 0.0, 0  //node_stack_top
	
	// Remove old KAS 
	!MODULE[KASModuleWinch] {}
	!MODULE[ModuleKISPartMount] {}
	
	MODULE
	{
		name = KASLinkWinch

		// AbstractLinkPeer
		linkType = MdCable
		linkTypeDisplayName = #kasLOC_99004 // #kasLOC_99004 = Cable-35
		attachNodeName = front
		allowCoupling = true

		// KASLinkSourceBase
		jointName = mediumCableJoint
		linkRendererName = mediumCableRenderer
		coupleMode = NeverCouple

		// KASLinkSourcePhysical
		connectorMass = 0.01
		connectorInteractDistance = 0.5
		decoupleIncompatibleTargets = true
		sndPathLockConnector = KAS/Sounds/winchSmallLock
		sndPathDockConnector = KAS/Sounds/plugdocked
		sndPathGrabConnector = KAS/Sounds/grab
		sndPathPlugConnector = KAS/Sounds/plug
		sndPathUnplugConnector = KAS/Sounds/unplug
		sndPathBroke = KAS/Sounds/broke

		// KASLinkWinch
		connectorLockMaxErrorDist = 0.12 // Meters.
		connectorLockMaxErrorDir = 25 // Degrees.

		motorMaxSpeed = 3 // Meters per second.
		motorAcceleration = 0.4 // Meters per second per second.
		motorPowerDrain = 0.5 //0.7 // Units per second.

		sndPathMotor = KAS/Sounds/winchSmallMotor
		sndPathMotorStart = KAS/Sounds/winchSmallMotorStart
		sndPathMotorStop = KAS/Sounds/winchSmallMotorStop
	}
	MODULE
	{
		name = KASRendererPipe

		// KASRendererPipe
		rendererName = mediumCableRenderer
		pipeTextureRescaleMode = TileFromTarget
		pipeDiameter = 0.035
		pipeTexturePath = KAS/Textures/ProceduralSteelCable
		pipeNormalsTexturePath = KAS/Textures/ProceduralSteelCableNRM
		pipeTextureSamplesPerMeter = 10

		sourceJoint
		{
			sphereOffset = -0.1490
		}
		targetJoint
		{
			sphereDiameter = 0.035
			model = *CommonConnector*/head
			modelPartAttachAt = 0.0, 0.0, 0.0,  0, 0, 0 	// 0.0, 0.0, 0.0,  180, 0, 0
			modelPipeAttachAt = 0,0, 0.15,  0, 0, 0			// 0,0, 0.15,  0, 0, 0
			parkAttachAt = 0.05, 0.01, -0.11,  0, 0, 0	// -0.155, 0.0, -0.0792,  180, 0, 0
		}
	}
	MODULE
	{
		name = KASJointCableBase

		// AbstractJoint
		jointName = mediumCableJoint
		anchorAtSource = 0, 0, -0.1490
		anchorAtTarget = 0, 0, 0.1490
		maxLinkLength = 80
		linkBreakForce = 400

		// KASJointCableBase
		cableSpringForce = 2000
		cableSpringDamper = 1
	}
}
// zer0Kerbal

KIS

Spoiler

WIP

Lights

Spoiler


// IF Restock present, adjust lights to use Restock Light Module
@PART[OrbitalTugPod,helperDrone,DronePod,OrbitalGrapplerJR]:NEEDS[OrbitalTug]
{
   @MODULE[ModuleLight]:NEEDS[!ReStock]
   {
      @name = ModuleStockLightColoredLens
      %lightR = 1.0
      %lightG = 0.9
      %lightB = 0.8
      lensBrightness = 0.6
   }
   @MODULE[ModuleLight]:NEEDS[ReStock]
   {
      @name = ModuleColoredLensLight
      %lightR = 1.0
      %lightG = 0.9
      %lightB = 0.8
      lensBrightness = 0.6
   }
}
// zer0Kerbal

CCK - PR attempted to add files / patch.

Spoiler


// IF present, add CCK tag and Editor Categorgy
@CCKExtraFilterConfig:NEEDS[CCK,OrbitalTug]
{
   Item 
   {
      name = Orbital Tug
      tag = cck-tug
      normalIcon = OrbitalTug/Textures/FilterIcon
      selectedIcon = OrbitalTug/Textures/FilterIcon_Selected
      usedByMod = OrbitalTug
   }
}

@PART[adaptorCarrier,fwdAdaptor,OrbitalTugCore,OrbitalTugPod,helperDrone,DronePod,OrbitalGrapplerJR,engineOnArm]:NEEDS[CCK,OrbitalTug]
{
   @tags ^= :^:cck-tug
}
// zer0Kerbal

Adapter attach nodes

Spoiler

// correct node orientation
@PART[adaptorCarrier,fwdAdaptor]:NEEDS[OrbitalTug]:After[OrbitalTug]
{
@node_stack_mid = 0.0, -0.01, 0.0, 0.0, 1.0, 0.0, 1
}
// zer0Kerbal

Engine Attach Nodes/Core Attach Nodes

Spoiler


// change node size from 2 to 1 to match rest of parts
@PART[OrbitalTugCore]:NEEDS[OrbitalTug]:After[OrbitalTug]
{
   @node_stack_top = 0, 0.76, 0, 0, 1, 0, 1
   @node_stack_bottom = 0, -0.76, 0, 0, -1, 0, 1
}
// zer0Kerbal

Edited May 24, 2019 by zer0Kerbal

linuxgurugamer · May 24, 2019

1 hour ago, zer0Kerbal said:

am thinking should remove patch from part.cfg and make separate patch file.

Let's not make changes for changes sake. While I'm not totally a fan, having the patch for a particular part in it's file is not totally strange.

I'm working on a minor update. No functionality changes, just doing the following for consistency:

Indenting with tabs using same format as the ModuleManager.ConfigCache
Removing excessive lines between parts and any patches following

I'm also going to create a branch called: SeparatePatchsFromParts

In this branch, I'll be pulling all the patches out of the part files and into patch files for the appropriate mods.

By creating this branch, you can see both ways, and let me know how you all would like to proceed.

I should have it up in about 15-20 minutes

[1.1.2] Orbital Utility Vehicle v1.2.4

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