Cargo Transportation Solutions (WIP)

[Talisar]

It's attaching to the wrong node. It's hard to see, but there are actually 2 separate nodes on the top of that adapter piece, and the upper one is intended for the trusses/arches/cargo bay. It's fiddly, but you just have to make sure it snaps to the upper one instead of the lower. That will also leave the lower one available for stacking payload parts (like a clamp-o-tron )

Here's a pic I did with the node sizes smaller to illustrate:

You see they are VERY close together, and it's even harder to notice when they're the correct sizes. The one for the payload is flush with the base and the other is at the same level as the rim of the "Bowl" for attaching the trusses to.

[Talisar]

Of course, such hatch/ladder thing must be done outside unity unless you're crazy , I was more speaking about base shape colliders.

It's likely possible unity do some "magic" makes collider smarter then we think (because unity know itself better than us) and sometime "the thing to do is not the best thing to do".

Actually, I do the opposite. I model the colliders in 3ds Max, but I just use the basic unity box colliders for airlocks and ladders most times. It makes it easier to adjust (I never get them placed right the first time...or the second...or the fifth...)

A lonely plug-in itself will not contribute that much to memory usage.

It's less about the memory usage than it is about the relative ubiquity of FireSpitter. It does a very good job as a replacement for the stock moduleAnimateGeneric, as well as adding other functionality. Since a lot of other mods use it as the stock replacement, it's a pretty common one to find, and people won't like having to update 2 plugins when it can be done with one. I know it sounds like a small matter, but watch around the time that KSP updates come out, and chaos ensues.

In any case, since my rework seemed to fix the problem, it was obviously caused by me and not any fault of FireSpitter I was pretty sure that was the case.

Edited May 2, 2014 by Talisar
grammar is hard

[Darkstar One]

Looks very promising!

Will use when it shows up in the Add-on-Release section

[Talisar]

I don't think that will be too long. I'm just waiting on a little more feedback about the parts that I re-made the colliders for, and I need to get the textures polished and finalized. Once that is done, I'm planning on doing a release containing all the current parts minus the command pod (it still needs more work, and I think I'm going to move that into it's own project)

There are a couple of things that I am looking at for this pack, such as tweakable rescaling, but the parts are playable as they are and more fluff can be part of future updates.

[Tallinu]

The third cargo arch is put in the wrong height (lower than it should) due to those nodes size/snap mismatch again.

Why are you even attaching things backwards like that? I understand that you're trying to make a fully-surrounded space but the fact that KSP allows you to make parts physically overlap doesn't really mean it's a good idea. Your joints are going forward, then back, then forward and creating a much longer series of much springier connections, like a twisted up slinky.

O O-O
| | |
| | |
| | |
| | |
O-O O O-O
    | | |
    | | |
    | | |
    | | |
    O-O O

Any kind of bending force on that sort of construction is going to be three times as bad, making the craft far more fragile and harder to control. Even perfectly straight thrust would make it all compress (or stretch) three times as much.

Maybe a couple more versions of these parts could be put together, with this full wraparound look, to avoid "needing" to do this?

[Talisar]

Maybe a couple more versions of these parts could be put together, with this full wraparound look, to avoid "needing" to do this?

Ahh, I see now. I didn't understand what he was trying to do. Yes, making a fully enclosed version (Arches on both sides) is very easy, just a config edit. If you make a file named TALMediumCargoFrameTube.cfg (or anything else actually, but that's the name I'll use in updates) and paste the following in it you'll get the part:

PART
{

// --- general parameters ---

name = TALMediumCargoFrameTube
module = Part
author = Talisar

// --- asset parameters ---

MODEL
{
model = ModsByTal/Parts/Cargo/Models/TalCargoFrame
texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture
scale = 1, 1, 1
position = 0.0, 0.0, 0.0
rotation = 0, 0, 0
}

MODEL
{
model = ModsByTal/Parts/Cargo/Models/TalCargoArch
texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture
scale = 1, 1, 1
position = 0.0, 0.0, 0.0
rotation = 0, 0, 0
}

MODEL
{
model = ModsByTal/Parts/Cargo/Models/TalCargoArch
texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture
scale = 1, 1, 1
position = 0.0, 0.0, 0.0
rotation = 0, 180, 0
}

scale = 1
rescaleFactor = 1

// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z

node_attach =        0.00,  0.00, -1.50, 0.0, 0.0, 1.0, 3

node_stack_top =     0.00,  1.00, 0.00, 0.0,  1.0, 0.0, 3
node_stack_bottom =  0.00, -1.00, 0.00, 0.0, -1.0, 0.0, 3

// --- editor parameters ---

TechRequired = veryHeavyRocketry
entryCost = 68400
cost = 21000
category = Structural
subcategory = 0
title = TCS Arched Cargo Frame Tube
manufacturer = Talisar's Cargo Solutions
description = A 2 meter long structural frame with sufficient inner diameter to store 2.5 meter thick parts inside.  This version includes arched support on both sides, creating an enclosed tube.  This part is slightly wider than standard parts and should be used in conjunction with Talisar's Cargo Solutions Adapters and Seperators.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision

attachRules = 1,1,1,1,1

// --- standard part parameters ---

mass = 1.5
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 3
crashTolerance = 5
maxTemp = 2900
fuelCrossFeed = True

breakingForce = 10000
breakingTorque = 10000

}

And for the larger version, (TALLargeCargoFrameTube.cfg for preference):

PART
{

// --- general parameters ---

name = TALLargeCargoFrameTube
module = Part
author = Talisar

// --- asset parameters ---

MODEL
{
model = ModsByTal/Parts/Cargo/Models/TalCargoFrame
texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture
scale = 1.5, 1.5, 1.5
position = 0.0, 0.0, 0.0
rotation = 0, 0, 0
}

MODEL
{
model = ModsByTal/Parts/Cargo/Models/TalCargoArch
texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture
scale = 1.5, 1.5, 1.5
position = 0.0, 0.0, 0.0
rotation = 0, 0, 0
}

MODEL
{
model = ModsByTal/Parts/Cargo/Models/TalCargoArch
texture = FrameTexture , ModsByTal/Parts/Cargo/Models/FrameTexture
scale = 1.5, 1.5, 1.5
position = 0.0, 0.0, 0.0
rotation = 0, 180, 0
}

scale = 1
rescaleFactor = 1

// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z

node_attach =        0.00,  0.00, -2.25, 0.0, 0.0, 1.0, 3

node_stack_top =     0.00,  1.50, 0.00, 0.0,  1.0, 0.0, 3
node_stack_bottom =  0.00, -1.50, 0.00, 0.0, -1.0, 0.0, 3

// --- editor parameters ---

TechRequired = veryHeavyRocketry
entryCost = 68400
cost = 21000
category = Structural
subcategory = 0
title = TCS Arched Cargo Frame Tube (Large)
manufacturer = Talisar's Cargo Solutions
description = A 2.5 meter long structural frame with sufficient inner diameter to store 3.75 meter thick parts inside.  This version includes  arched support along both sides, creating a fully enclosed space.  This part is slightly wider than standard parts and should be used in conjunction with Talisar's Cargo Solutions (Large) Adapters and Seperators.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision

attachRules = 1,1,1,1,1

// --- standard part parameters ---

mass = 1.5
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 3
crashTolerance = 5
maxTemp = 2900
fuelCrossFeed = True

breakingForce = 10000
breakingTorque = 10000

}

I'll include them in the next update (which I expect to be a release)

Edited May 4, 2014 by Talisar

[Tallinu]

For anyone having difficulty attaching things to the cargo adapters, here's a quick pictorial guide. Make sure you don't have part clipping enabled or things will still try to attach to occupied nodes and these steps won't help at all.

Javascript is disabled. View full album

Edit: Thanks, and you're welcome.

Edited May 4, 2014 by Tallinu

[Talisar]

[ IMGUR ]HdKJO[ /IMGUR ]

without the spaces

-edit: Thanks for making that guide up

[Justin Kerbice]

Why are you even attaching things backwards like that? I understand that you're trying to make a fully-surrounded space but the fact that KSP allows you to make parts physically overlap doesn't really mean it's a good idea. Your joints are going forward, then back, then forward and creating a much longer series of much springier connections, like a twisted up slinky.

...

Any kind of bending force on that sort of construction is going to be three times as bad, making the craft far more fragile and harder to control. Even perfectly straight thrust would make it all compress (or stretch) three times as much.

Maybe a couple more versions of these parts could be put together, with this full wraparound look, to avoid "needing" to do this?

You know, it's a test release after all, so I do testing, even improper, incorrect, crazy assemblies.

I even wasn't aware of this "springy connection", maybe that's why my two attempts to send something in Kerbin using cargo bay made the rocket going sideways .

Are you sure about your forward/backward joints and the issue they create ? As Squad didn't release so much informations of their internals stuffes, it's not easy to know what's going on under the hood.

Thanks for the tips, and for the assembly guide you've posted later.

[CaptainKipard]

I'm getting a ridiculous amount of lag in the VAB when:

- Opening the cargo bay

- Moving the rocket. The more truses there are the worse it gets.

- A bit when surface mounting on the trusses

So I had a look at your mesh in blender and not only are your colliders still much too complex, there are DUPLICATES of each collider. What did you do?

[Talisar]

So I had a look at your mesh in blender and not only are your colliders still much too complex, there are DUPLICATES of each collider.

Hmm, you are correct about the duplicates. Not quite sure how that happened, but easily fixed.

What did you do?

Well, it's pretty obvious that I made a mistake, eh? Hence the reason that I am waiting on more feedback before moving forward.

[CaptainKipard]

Cool. I was just wondering, will you work a bit more on the textures, or do you consider them done? I would at least bake some ambient occlusion and multiply them in your colour map. It's a quick job but it makes a big difference.

[Justin Kerbice]

Cool. I was just wondering, will you work a bit more on the textures, or do you consider them done? I would at least bake some ambient occlusion and multiply them in your colour map. It's a quick job but it makes a big difference.

Good point ! I would like to know more about this AO baking. Usually, I just create a shading map which greatly improve the volume look of the model (in opposite to "flat look" seen in some parts ere or there).

@Talisar: have you, or someone else, tried it with FAR, cause unless for mostly role-players, cargo bays are basically useless in KSP, in term of efficiency.

Don't you think so ?

[Talisar]

The textures are the next major thing I am working on, once all the fiddling with models is complete. The ones there are not final by any means. I also have to do the math for getting the masses of the parts to make sense, as well as place them in the tech tree.

As to FAR, I haven't done all the homework yet, but my understanding is that FAR automatically looks for certain words (such as fairing, and cargo bay) in the name of the part, which this one has. I'll look into it more to be certain, but I believe the cargo bay itself should be compatible with FAR, and the adapters that include mounting points for procedural fairings should help with getting the "open air" pieces out of the atmosphere.

Edited May 4, 2014 by Talisar
Doh, grammar again

[CaptainKipard]

One more thing that's just popped into my mind. I don't know if you've already done this but if you want a realistic center of mass for the arch section you can recalculate it automatically in blender. If you press T there should be an option on the top.

[Talisar]

I thought about this, and purposely placed the center of mass where it is. While less realistic, I think it's better for gameplay reasons to have the part's COM to be centered on the build axis

[Talisar]

Updated the main download to include the updated cargo bay and arch models. Also included the fully enclosed, cylindrical version of the arched trusses. This is likely to be the finalized "content" update to the pack, with further updates being aimed providing improved textures, balancing the masses of the parts so they make sense, and placing them intelligently in the tech tree. No promises, but future updates should not break craft.

[CaptainKipard]

- The colliders are still duplicated.

- The cargo frame has four colliders at this point. That's two duplicates of two different colliders. 16 shapes all together.

- The colliders for all the truss backbones are still rounded unnecessarily. You should make the cross sections rectangular like you did with the curved sections.

- Docking ring and Hollow ring colliders should be made less complex, like the one for the cargo bay. Basically for every two cylinder faces, you should have one collider face. Everyone else does it that way.

- Your UVs overlap. That's really bad practice. I know why you did it, because I used to do it too, but if you want to bake AO (which you realy should) you will need your UVs to be separate.

- Generally speaking you went beyond the standard 24 faces for cylinders. 36 isn't too bad, but coupled with the complex colliders it's not a good idea.

- The 3D details of your models aren't pronounced enough to be warranted. I'm talking about the side mount, and docking ring specifically.

On the bright side, you've aligned the faces of your models to be perpendicular to the four cardinal directions, which at the moment makes surface mounting work nicely, but unfortunately when and if you simplify your colliders they will need to be aligned again.

I really don't think you should call this finalised. There's enough problems here to warrant a do-over. Visually things are ok, but technically they are not.

Edited May 6, 2014 by Cpt. Kipard

[Talisar]

- The colliders are still duplicated.

- The cargo frame has four colliders at this point. That's two duplicates of two different colliders. 16 shapes all together.

I've double checked both my setup in 3ds and my unity setup, as well as re-exported from the beginning. There is only one set of colliders. I'm not sure why you are seeing 2, maybe it has something to do with however you are importing my files into blender?

- The colliders for all the truss backbones are still rounded unnecessarily. You should make the cross sections rectangular like you did with the curved sections.

This is on purpose.

- Docking ring and Hollow ring colliders should be made less complex, like the one for the cargo bay. Basically for every two cylinder faces, you should have one collider face.

This is a good point, I'll probably revisit that area.

Everyone else does it that way.

A good enough reason to look into it, not a good enough reason to just do it

- Your UVs overlap. That's really bad practice. I know why you did it, because I used to do it too, but if you want to bake AO (which you realy should) you will need your UVs to be separate.

Setting up and using textures is (as I have repeatedly mentioned) a very weak area for me. This area is going to be worked on extensively

- Generally speaking you went beyond the standard 24 faces for cylinders. 36 isn't too bad, but coupled with the complex colliders it's not a good idea.

I understand your reasoning behind this, but I disagree. The ulitmate size these are intended to be warrants the increased number of faces, at least on the visual mesh.

- The 3D details of your models aren't pronounced enough to be warranted. I'm talking about the side mount, and docking ring specifically.

Again, I know why you think this but I disagree. For both of those parts you indicated, I desired that small amount of 3d detail, and prefer the way it looks actually modeled rather than using normal maps to achieve it.

On the bright side, you've aligned the faces of your models to be perpendicular to the four cardinal directions, which at the moment makes surface mounting work nicely, but unfortunately when and if you simplify your colliders they will need to be aligned again.

I will likely be revisiting the colliders, but it won't be hard to keep them aligned. Not having them line up is one of my major pet peeves when building.

I really don't think you should call this finalised. There's enough problems here to warrant a do-over. Visually things are ok, but technically they are not.

As you see, the issues you've brought up are either things that I specifically wanted or are fairly easy to adjust. Nothing warranting a do-over by any means. In any case, what I mean by finalized is that I am not going to be adding any new parts, removing any parts, or making any changes to the current ones that will cause craft breaking issues. Anything further I do with this pack until release should mostly be pretty much under the hood. The reason for this is so that anyone who is interested in trying out the parts but holding off can do so without much fear of mucking up their saves.

[Justin Kerbice]

I've double checked both my setup in 3ds and my unity setup, as well as re-exported from the beginning. There is only one set of colliders. I'm not sure why you are seeing 2, maybe it has something to do with however you are importing my files into blender?

I saw this issue myself with some stock parts, some models are duplicated (dummies for example, which may come from unity transforms).

[CaptainKipard]

Ok good response but:

I've double checked both my setup in 3ds and my unity setup, as well as re-exported from the beginning. There is only one set of colliders. I'm not sure why you are seeing 2, maybe it has something to do with however you are importing my files into blender?

No, I've double checked with a couple of other mods including my own and only yours has this problem. You must be doing something wrong in your 3D app or Unity.

This is on purpose.

How come?

A good enough reason to look into it, not a good enough reason to just do it

Of course, but that reason is proximate. Ultimately everyone does it because physics calculations in games like this don't require meshes to be anywhere near the complexity of the visible mesh. As for surface attachment there are very simple ways in the VAB to get around the lack of a more rounded collider.

In any case, what I mean by finalized is that I am not going to be adding any new parts, removing any parts, or making any changes to the current ones that will cause craft breaking issues.

I'm not entirely sure, because I haven't tested it, but from what others have said, I think that a changed collider is craft-breaking.

Edited May 6, 2014 by Cpt. Kipard

[Talisar]

No, I've double checked with a couple of other mods including my own and only yours has this problem. You must be doing something wrong in your 3D app or Unity.

I'll check it again, but I've used the exact same workflow for all of my parts. Are you seeing duplicates on all the parts, or just the arches?

How come?

I have parts planned for the future that I want to have surface attachable on that section at a 45 degree angle.

Of course, but that reason is proximate. Ultimately everyone does it because physics calculations in games like this don't require meshes to be anywhere near the complexity of the visible mesh. As for surface attachment there are very simple ways in the VAB to get around the lack of a more rounded collider.

True, and I'll keep that in mind.

I'm not entirely sure, because I haven't tested it, but from what others have said, I think that a changed collider is craft-breaking.

I haven't had any issues when I've done it, but to be sure I'll prioritize the collider simplification and do one more push before I finalize the finalization

[CaptainKipard]

All of your parts suffer from this and one of them has even more colliders, as described earlier.

[CaptainKipard]

I promised Justin Kerbice I'd post some info on baking Ambient Occlusion a few days ago. Sorry for the delay. I'll post it here. I hope it's useful.

Basically all it does is cast very soft shadows from the surrounding geometry. Calculating AO at run time is very expensive so often artists just bake an AO map and incorporate it into the diffuse/colour map.

Baking in Blender is easy:

1. Make sure your model is unwrapped correctly. UV islands should have a few pixels space between them. There should be no overlapping UVs (this isn't always necessary but I'll let you figure that out for yourself. For now keep them separate)

2. Go to World tab.

3. Check "Ambient Occlusion"

4. Select "Raytrace", Contant QMC, Increase samples to 15 (Lower numbers give you more grainy results)

5. Select your object. Go to Edit mode. Select all. (This step might not be necessary but it allows you to see the baked result in 3D view.

6. In the UV window create new image. Call it whatever. No alpha

7. Go to Object mode. Keep the object selected.

8. Go to Scene tab.

9. Under "Bake" Select Ambient Occlusion.

10. Check "Clear" and "Normalized". Give it a margin of a few pixels

11. Click "Bake"

12. Save the image.

The best way is to import the AO map as a new layer in your image editor and set the layer mode to "Multiply". You might know that colours on computers are stored as RGB numbers with black being #000000 and white being #FFFFFF. If you multiply something by 000000, you get zero, which is black, and if you multiply something by FFFFFF you get the original colour. Multiplying by something grey (e.g #808080) gives you a shadowed effect.

Edited May 9, 2014 by Cpt. Kipard

[Justin Kerbice]

I promised Justin Kerbice I'd post some info on baking Ambient Occlusion a few days ago. Sorry for the delay. I'll post it here. I hope it's useful.

[...]

Thanks .

As far as I see, it's similar to what I do, I'll explain later in a more appropriate location.

Something which may be usefull for readers here, if the generated layer is too dark, it's better to lower opacity (or a pure white color may looks grey for example).