Jump to content

[1.1.2] Orbital Utility Vehicle v1.2.4


nli2work

Recommended Posts

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?

29gYy9L.png

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,

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by COL.R.Neville
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

10 hours ago, COL.R.Neville said:

for textures ive always just used dds4ksp.

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

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... :P  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 by Stone Blue
Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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. 

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
        }
    }

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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 by linuxgurugamer
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Okay -

  1. 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.
  2. 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
  3. adding CCK patch and icons
  4. patch to correct attach nodes on adapters done.
  5. am debating about adding attach nodes to engines and symmetrical attach nodes to core (x4)
    • comments?
  6.  

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

  1.  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

     

     

  2. KIS
    Spoiler

    WIP

     

  3. 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

     

     

  4. 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

    FilterIcon.pngFilterIcon_selected.png

     

  5. 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

     

  6. 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 by zer0Kerbal
Link to comment
Share on other sites

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:

  1. Indenting with tabs using same format as the ModuleManager.ConfigCache
  2. 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

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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...