[1.1.2] Orbital Utility Vehicle v1.2.4

[Kilo60]

So this mod still works in 1.3?

 

Thanks!

[Stone Blue]

1 hour ago, Kilo60 said:

So this mod still works in 1.3?

 

Thanks!

Relatively.... I'm working on some tweaks and updates for it... also implementing B9 and WBT texture switching for it

[Adov]

My game doesn't recognize the Space Tug command module as one ever since 1.3.1 came out. There are errors "no control" and "empty crew cabins" in the checklist eve though the command pod is there and is manned. Any idea what should look into?

[DStaal]

4 minutes ago, Adov said:

My game doesn't recognize the Space Tug command module as one ever since 1.3.1 came out. There are errors "no control" and "empty crew cabins" in the checklist eve though the command pod is there and is manned. Any idea what should look into?

Do you have an antenna on your ship?

You now need connection back to Kerbin for a probe core to work - stock probe cores all include a small antenna that will work close to Kerbin, but I don't think there's one in here.

[Stone Blue]

I dont know... theres a ModuleDataTransmitter in the cfg, and theres also an animated antenna mesh on it

I've been waiting for 1.4 to drop, as we are supposed to get stock texture switching... so there may not be a need for FS/IFS/B9/WBT switching patches

 

 

Edited February 21, 2018 by Stone Blue

[Adov]

Quote

Do you have an antenna on your ship?

Yes, the vessel on which I encountered this issue first does have an antenna. But that is not really related since I'm talking about the crewed Space Tug Command Module, not the probe core. The latter actually looks operational.

Edited February 21, 2018 by Adov

[Kilo60]

Great Mod!

 

However, the "remote assist helper drone" has no control at all after I undock/decouple it and switch to control it....

 

Any Ideas?

 

Thanks!

[Starwaster]

On 2/23/2018 at 8:40 PM, Kilo60 said:

Great Mod!

 

However, the "remote assist helper drone" has no control at all after I undock/decouple it and switch to control it....

 

Any Ideas?

 

Thanks!

Do they have charge?

Edit: I just checked these things out and they're lacking antenna so if you have Commnet enabled then they're not going to work properly

Now that I think back, there's a reason I have this installed but never use it, the parts are cool in concept but behave a bit wonky in implmentation.  

Edit #2: Ehhhh they're also classified as debris... I don't know what if there's any one thing wrong with these things. I'm playing with the configs on it to see if I can fix them...

Edited March 4, 2018 by Starwaster

[Starwaster]

@Kilo60

Make a file named OrbitalTug-Drone-Tweak.cfg (or name it whatever you want, doesn't matter)

and paste the following into that file then save it.

@PART[DronePod|helperDrone]
{
	vesselType = Probe
	MODULE
	{
		name = ModuleDataTransmitter
		antennaType = INTERNAL
		packetInterval = 1.0
		packetSize = 2
		packetResourceCost = 12.0
		requiredResource = ElectricCharge
		antennaPower = 50000
		optimumRange = 2500
		packetFloor = .1
		packetCeiling = 5
	}
}

Although setting the DronePod to Probe is redundant since it already has that but it also lacks a proper antenna so I just did it as one config.

@Stone Blue if you're working on maintaining this mod then you should add that in.

[xxXHonestJohnXxx]

Are there plans to update the mod to 1.4.1?

[tferroato]

I'm having a couple of problems with 1.4. The biggest right now is getting it to recognize the extending engine. I can't seem to figure out why it won't load. Anyone got suggestions?

[xxXHonestJohnXxx]

Are there plans to update the mod to 1.4.1?

 

+Update+

Having Looked into it, i  can state that maintenance for this mod has been stopped. The last update was mid 2016. For me the mod is crucial so wil give it a go to at least get it to work on 1.4.1. 

Edited March 20, 2018 by xxXHonestJohnXxx

[tferroato]

7 hours ago, xxXHonestJohnXxx said:

Are there plans to update the mod to 1.4.1?

 

+Update+

Having Looked into it, i  can state that maintenance for this mod has been stopped. The last update was mid 2016. For me the mod is crucial so wil give it a go to at least get it to work on 1.4.1. 

HOORAY!!!!

[Stone Blue]

I was hoping for some relatively quick fixes for this mod... But looking into the models, they are extrememely complicated, and could really use some optimization... which is a bit of an undertaking, and I have other projects I want to spend time on... So I may/may not be doing anything with this mod anytime soon. Especially if others might be taking a crack at it.

 

Edited March 20, 2018 by Stone Blue

[Wolf Baginski]

I just gave this a try, and many parts did not appear in in the VAB. I tried to figure what was up.

At least some of the .dds files show as only 144bytes, both when unzipped and the versions in the zipfile. It could be some glitch with the archive utility. I use Linux. But this is what the logfile says, and if somebody can check what they get for this file...

[LOG 20:38:54.942] Load(Texture): OrbitalTug/adaptor/grapplerArms_DIF
[EXC 20:38:54.946] UnityException: LoadRawTextureData: not enough data provided (will result in overread).
	UnityEngine.Texture2D.LoadRawTextureData (System.Byte[] data)
	DatabaseLoaderTexture_DDS.Read (System.String filename)
	DatabaseLoaderTexture_DDS+<Load>c__Iterator0.MoveNext ()
	UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)
	UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
	<LoadObjects>c__Iterator1:MoveNext()
	UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

This file showed a size of 144bytes. There are others. Both the Spacedock and the Dropbox versions of the archive show the same files as only 144bytes.

These seem to be the root of the loading problems I'm seeing. It might be my Linux install and its archive program, which is GNOME Archive Manager 3.16.5, but it's the first time I have ever seen anything like this.

Edited March 20, 2018 by Wolf Baginski
Checked both available versions of the archive

[Stone Blue]

ok... those 1k and 2k textures are supposed to be very small, as they are only placeholder textures....
so that shouldnt be your problem

Make sure you have a .dds of the same name, but 1.3+MB, in the /core folder...

[Wolf Baginski]

OK, I can sort of see what the idea is, and they're there, and I got some of the parts to load, but then I logged several failures of the .mu files, they wouldn't compile. But, along the way, I noticed this:

The node format for a texture is (from the Wiki)

texture = texturefilename , folder/../texturefilename

The node format in the .cfg files is

texture = stripes_blk, OrbitalTug/colors/stripes_blk

Should there be a space before the comma? I did some checking, and other mods don't seem to care about it, loading without these problems whether that space is there or not. Then I noticed this, in the description of the internal names for parts: "Underscores and other special characters are either not allowed or not recommended" Trouble is that, while many stock parts don't use that texture node at all, the textures must be specified in the .mu file, there are a few underscored filenames for textures. I'd be inclined to follow that rule, but it doesn't seem tpo matter.

I managed to stop the texture loading arrors, but I can't do anything about the problems with compiling the .mu files.

 

 

 

[Starwaster]

6 hours ago, Wolf Baginski said:

OK, I can sort of see what the idea is, and they're there, and I got some of the parts to load, but then I logged several failures of the .mu files, they wouldn't compile. But, along the way, I noticed this:

The node format for a texture is (from the Wiki)

texture = texturefilename , folder/../texturefilename

The node format in the .cfg files is

texture = stripes_blk, OrbitalTug/colors/stripes_blk

Should there be a space before the comma? I did some checking, and other mods don't seem to care about it, loading without these problems whether that space is there or not. Then I noticed this, in the description of the internal names for parts: "Underscores and other special characters are either not allowed or not recommended" Trouble is that, while many stock parts don't use that texture node at all, the textures must be specified in the .mu file, there are a few underscored filenames for textures. I'd be inclined to follow that rule, but it doesn't seem tpo matter.

I managed to stop the texture loading arrors, but I can't do anything about the problems with compiling the .mu files.

 

 

 

While it's true that spaces are an issue for names (where those names are going to be used to retrieve URI resources), they are not a problem for comma separated values.

As far as underscores in the texture names, Squad has several textures with underscores so that doesn't seem to be an issue either...

And missing textures didn't USED to be a show stopper; it would just throw warnings in the log. Might not be the case anymore...?

[Stone Blue]

Ahhh... ok...
yeah... for some reason, it looks like the texture replacement "trick" of using placeholders and the texture = key isnt working... dont know if it got broke in KSP 1.4.x itself, or something specific to the way *this* mod was working it...
 

[xxXHonestJohnXxx]

Got the OrbitalTug engine's working. Although i love the work from nli2work, yet  the OrbitalTug mod could be done more professional.  I am thinking about starting my own project based on the OrbitalTug project. But although not new to programming and Blender moddeling, i am new to developing mods in the Kerbal universe. Fixing this mod for 1.4.1 would be a nice start i think. O for those hackers wich give it a try, i just deleted all the texture references for the Engine part and also deleted half the CFG file from extendEngine.cfg. And the engine appears in KSP with the textures and works like a charm.   

[Stone Blue]

12 minutes ago, xxXHonestJohnXxx said:

I am thinking about starting my own project based on the OrbitalTug project.

if you do it... *PLEEZE* optimize the models...

 

[xxXHonestJohnXxx]

In what way do you want the models to be optimized?

[Stone Blue]

1 hour ago, xxXHonestJohnXxx said:

In what way do you want the models to be optimized?

the hierarchies could stand to be compacted.... many of the similar child objects can be combined... especially if they share materials/textures... there are lots of unecessary draw calls as the hierarchy stands...
i didnt dig too much into them, as optimization of the hierarchy would have been my first step

[xxXHonestJohnXxx]

Got the OrbitalTug working again but have to state clearly i have no idea whatsoever i am doing other then to use a pinch of common sence . In my research for finding a workable solution, getting the general idea how the workflow

for KSP is regarding to mod development. Is a nice byproduct for me.

 

The short answer is copy/paste textures arround several OrbitalTug directories and replace the 1k with the bigger(real texturefiles). I give 1 example wich applies to the other parts aswell:

Map: colors  File: stripes_blk,dds (22kb in size) 

Copy stripes_blk.dds to the following maps below>>>>>>>

adaptor,  core,  drone, pod wich contain all the same named files yet seems to be 1k dummies

I have spend enough time so far so forgive me not to post here a list wich files needs to be copied to wich map. I would highly recommend to install a clean KSP game no mods so you can check and adjust these mods quiker and when it works you can copy the files to the KSP game you play with all the bells and whistles. Because the OrbitalTug idepends on other mods you can see an error passing by but has no effect for the repairing proces and checking the OrbitalTug mod if its fixed.

 

Again as i stated befor, i like this mod very much well actually i use only the engines. But i want to develop my own version of it wich is suitable for various missions. The salvage and rescue missions generated for me a lot of cash in career mode. A verhicle for that purpose would be nice. Also i highly dislike the dependency from this mod for other mods, like a mod with helicopter parts to give an example.

Anyway i hope this helps some people my focus will shift to my own project now.

 

 

 

 

 

[Capt. James T. Kirman]

It's always a shame to see mods as creative as these ones die.