Cart Modelling Guidelines v1.34 + Inter-Plugin Communication

[Tosh]

You've already seen [thread=7854]The Cart[/thread] addon, haven't you? Wanna make your own cart? There you go.

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_1>1. Basic Considerations</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_2>2. Importing into PartTools</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_3>3. Car Body</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_4>4. Wheels and Anchors</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_5>5. Suspension and Wheel Deploying</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_6>6. Lights</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_7>7. Glass and Metal Parts</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_8>8. PART.CFG Reference</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_8_1>8.1. Engine Parameters</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_8_2>8.2. Steering Parameters</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_8_3>8.3. Suspension Parameters</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_8_4>8.4. Compensation Parameters</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_8_5>8.5. Light Parameters</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_8_6>8.6. Keys and Axes Bindings</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_9>9. Cart Programming Interface</a>

<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_10>10. On Modifying and Distributing</a>

<a name=cart_sect_1></a>1. Basic Considerations

<div style="float:right; padding-left:1em; padding-bottom:1em"></div>When modelling in Blender, Z axis (blue arrow) is 'up'. Y axis (green) is 'forward'. X axis (red) is 'right'. Note that Unity engine uses other conventions: in the game Z is 'forward' and Y is 'up'; and it may give you a real headache if you plan using PartTools to export your model (see below).

Scale is always 1; that concerns global scale in scene setup, scale value in PART.CFG file and each specific object's scale. In Blender you may press Object/Apply/Scale to reset scale to 1.

Object rotation is always (0, 0, 0), if no other value is explicitly specified. Use Object/Apply/Rotation to reset.

On the right is the picture showing how Transform panel should look like:

Also remember that all the objects in the scene must have the same material assigned (ofc unless you assign materials in PartTools).

<a name=cart_sect_2></a>2. Importing into PartTools

In addition to .DAE models exported with Blender, Cart plugin supports .MU models created in [thread=15998]PartTools[/thread] utility, with all these fancy normal-mapped textures, ladders/airlocks, animation and stuff.

Following should be considered when importing you model into Unity:

• Objects hierarchy is not supported. All the objects listed below (lights, wheels, anchors etc..) must be parented to the main PartTools object, and should not contain children.
  
• What's Y in Blender becomes Z in Unity, and vice versa. I.e. lights (see <a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_6>Section 6</a>) shine along their local Z, wheels (<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_4>Section 4</a>) steer around their anchor's local Y, rotating levers (<a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_5>Section 5</a>) look towards their wheels with their local Z axes, and so on.
  In the following text, when mentioning some axes, I will mean Blender's axes, not Unity's ones.

Yes, I know it's pain in the butt. But that's the thing we gotta deal with

<a name=cart_sect_3></a>3. Car Body

Model car body and its node_collider as usual; see [thread=3730]Blender tutorial[/thread] for an explanation. Place the car at (0, 0, 0) point facing forward (along an Y axis) and with roof up (along Z).

Starting from v1.34, body orientation is not much of importance; you may even create carts riding along their negative X. Just remember to double-check anchors and wheels orientations (see <a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_4>Section 4</a>), as they fully determine cart's behavior. And as for the scale -- it must be set to (1, 1, 1).

Note that at launch the cart stands on the ground with its bare node_collider (as no wheels are created yet), so basic collider requirements apply: scene origin (point 0, 0, 0) must be well above the ground. Generally making node_collider more than 20 centimeters high and placing it around (0, 0, 0) point does the trick. Anyways, node_collider's origin point must be at (0, 0, 0) as the plugin code assumes that it is there.

<a name=cart_sect_4></a>4. Wheels and Anchors

Wheel rolls around its local X axis (red), goes towards its local Y (green), and steers around local Z (blue); its maximum dimension in YZ plane is used by plugin as a wheel radius. So create a cylinder facing right, with an origin point exactly in its center. Now orient the wheel appropriately; to do so, switch Blender to Local Transform Orientation (find a switch in 3D View toolbar) and rotate a wheel until its Y axis points "forward" and Z axis points "up". Then set wheel's position; its origin defines the lowest suspension point (fully expanded suspension spring).

Scale (1, 1, 1).

Name the wheel object as follows: 'wheel<wheel-ID>{wheel-type}', where 'wheel-ID' being a unique wheel idenifier, and 'wheel-type' may be empty (no motor, no steering), '_m' (motor), '_s' (steering) or '_ms'. For example, 'wheel1_ms'.

Now create wheel anchor. Anchor is a small object to which the wheel is attached; as the anchor is not visible in the game it may be just a small cube.

Anchor's orientation is extremely important too, as it determines where the cart gonna ride and where to steer. To recap once again: anchor's local Y is "forward", Z is "up", and X is "right". Period. Use Local Transform Orientation to rotate an anchor as necessary.

As anchor's origin point determines the highest wheel position (suspension spring fully compressed), it should be placed somewhere above the corresponding wheel. A good idea would be to put anchors slightly wider than visible wheels models; that makes the cart more stable at slopes. Be reasonable though as moving anchors too far from visible wheels makes the cart behave funny .

Give an anchor a name 'anchor<wheel-ID>' where 'wheel-ID' being the same as for corresponding wheel ('anchor1', for example).

Scale (1, 1, 1).

The car may have any number of wheels, each one with its anchor.

<a name=cart_sect_5></a>5. Suspension and Wheel Deploying

Optionally you may create suspension levers for each wheel. There are two type of levers supported: shifting lever and rotating lever (though each specific wheel may have only one of them).

Shifting lever moves up and down along with the wheel. Its origin point must be placed exactly at the wheel's position; its name is 'lever<wheel-ID>' (e.g. 'lever1'), 'wheel-ID' being the same as for corresponding wheel. Scale (1, 1, 1), rotation does not matter.

Shown in the picture below are the wheel, its shifting lever (black) and an anchor (red) which defines suspension's topmost position. Note that wheel's and lever's origin points coincide.

Rotating levers swing to look towards the wheel, retracting into car's body as necessary. Rotating lever's origin is the pivot point around which lever swings; and lever's rotation should be set so that it looks towards the corresponding wheel. So switch Blender to Local Transform Orientation and rotate a lever until its Y axis points in desired direction:

Rotating levers have the names like 'rotatingLever<wheel-ID>' (e.g. 'rotatingLever1').

Scale (1, 1, 1).

In the picture above you might have noted the orange 'ghosts': those are the positions where wheel and lever move in retracted state. This means the following:

From the <a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_8_3>Section 8.3</a> you'll learn that a cart may have 'deployable' wheels. In that case, when user presses 'Landing Gear' button, the wheels are deployed from or retracted into cart's hull. Anchor's Y and Z positions show where to place a fully retracted wheel; and the lever (a) still looks towards its wheel, and ( is retracted into cart's hull.

Of course the cart with shifting levers (or with no levers at all!) may have deployable wheels too; though in case of shifting levers, as the wheel's intended to move only vertically, wheel and corresponding anchor should be placed at the same Y.

Also keep in mind that fully retracted wheels must be well inside cart's node_collider (at least, higher than its bottom plane). Otherwise the cart will jump like crazy when the wheels are deployed.

<a name=cart_sect_6></a>6. Lights

There are three types of lights in the plugin: headlights (white, toggled by player), parking lights (yellow, toggled) and stoplights (red, lit automatically when the car brakes). Their objects should have 'light_head<light-ID>', 'light_parking<light-ID>' and 'light-stop<light-ID>' names correspondingly, 'light-ID' being any string (e.g. 'light_head1', 'light_stopLeft').

Note that lights colors may be changed in PART.CFG (see <a href=http://kerbalspaceprogram.com/forum/showthread.php/8072#cart_sect_8_5>Section 8.5</a>).

As each light object is given a Self-Illuminating/Specular shader it must contain only a lamp lens without a case (lamp cases may be parts of car body object). Lens origin defines light source position, and Y axis defines direction of the light spot. For example, stoplights (generally located in the rear) should point backwards, to (0, 0, 180), while headlights point forward and down, to (-10, 0, 0).

Also it may be a good idea to place headlight's origin well above the car, so that it lights up a ground before the car, not only the distant hills. So this is the case when object origin doesn't need to coincide with its geometry. Below is an the example of correctly set headlight (on the right) and stoplight (on the left):

BTW if you set some light's SpotAngle parameter to zero, this light becomes a point light which shines uniformly in all directions.

Also remember to set object scale to (1, 1, 1).

The texture for lamp lens should be colored the same as the corresponding light source. I.e. a stoplight should be red, parking light should be yellow and headlight should be white (or whatever the colors you've set it in the PART.CFG file). If you color a stoplight lens green it won't shine in the game (though light source will still work).

Texture alpha channel determines the brightness of light that illuminates lamp lens (not the brightness of the light source shining on the ground!). You may adjust texture transparency by switching Blender to Alpha Draw Mode (a button in the UV/Image Editor toolbar) and setting brush Blend Mode to Add Alpha or Erase Alpha in the Properties tab (<N> key).

Note that spotlights are very expensive to draw; just a dozen of them shining at the same time may drop frame rates significantly. Also note that 'a dozen of lights' situation can be quite possible if several carts gather together in one location. So try to make it with as few lights as possible when modelling a single cart. You may use an [thread=9990]FPS pod[/thread] plugin to measure in-game performance.

<a name=cart_sect_7></a>7. Glass and Metal Parts

If you give some object a name beginning with 'glass' word then plugin will assign a Transparent/Specular shader to it making an object partially transparent which is useful for creating car windows. A level of transparency is also determined by texture alpha channel.

Objects with names beginning with 'metal' are given Specular shader which is useful to create glossy metal parts. Texture alpha channel defines level of glossiness (opaque areas are glossy, transparent ones are not). Of course this shall not concern you if you're using PartTools to export your model, as this utility has built-in support for any shader (except for transparent ones).

As both these shaders are slightly more expensive to draw than KSP's default Diffuse shader you ought to be reasonable when adding glass or metal parts. See Materials and Shaders article for more details.

See also [thread=18063]ShaderReplacer[/thread] plugin.

<a name=cart_sect_8></a>8. PART.CFG Reference

There are 6 sections of CFG parameters specific to Cart Plugin -- Engine, Steering, Suspension, Compensation, Lights and Key bindings. Remember that all these parameters are optional; if none is set then plugin uses its default values suitable for a light 4-wheel car.

<a name=cart_sect_8_1></a>8.1. Engine Parameters

forwardTorque and backwardTorque determine how fast the car accelerates (the higher is the faster). brakeTorque is obviously braking intensity; be careful as the high brake torque causes a 'stoppie' and may topple the cart.

The frictionTorque is very important parameter as the friction in the plugin is made proportional to speed. So it's the frictionTorque that limits cart's top speed as well as its coasting distance.

<a name=cart_sect_8_2></a>8.2. Steering Parameters

At low speed maximum steering angle is constant and equal to maxSteerAngle parameter (in degrees). Starting from steerLimitSpeed (in m/s) steering angle begins to decrease with the speed, steerSpeedFalloff being the coefficient. You may adjust these parameters to prevent a car from toppling over when turning at high speed.

And steerVisibility parameter is simply a multiplier for visible model animation.

<a name=cart_sect_8_3></a>8.3. Suspension Parameters

wheelMass is, eh, the wheel mass in tonnes. Wheels add up to the part's mass. suspensionSpring defines how strong the spring is, and suspensionDamper is the damping force. See WheelCollider article for more details.

Next, deployable parameter determines whether the wheels should be deployed/retracted when user presses 'Landing Gear' key. deployTime is the process duration, in seconds.

<a name=cart_sect_8_4></a>8.4. Compensation Parameters

These parameters define the force pushing cart to the ground. compensationLowGee is applied at the Mun to make the cart controllable even at low gravity. Value of 1 makes the cart behave exactly as it does at Kerbin (which is unrealistic but playable) and value of 0 turns this force off.

compensationSpeed is applied when cart goes at high speed to make it more stable. Consider setting this parameter to 0 if you want your cart to takeoff (or topple over when going too fast).

<a name=cart_sect_8_5></a>8.5. Light Parameters

lightIntensity and headLightIntensity define the brightness of light sources (the former one for stoplights and parking lights, and the latter one for headlights). Allowed values are from 0 to 8. Next, lightRange and headLightRange define the light range, in meters; and lightSpotAngle/headLightSpotAngle are the angles of the light cones in degrees. Setting these angles to 0 turn corresponding lights into point lights which shine uniformly in all directions.

Then go headLightColor, parkingLightColor and stopLightColor parameters, each containing three digits for Red, Green and Blue channel correspondingly. Range for each channel is [0..1].

<a name=cart_sect_8_6></a>8.6. Keys and Axes Bindings

This section contains bindings for keyToggleLights, keyBrake and keyHandBrake actions. Each binding is a Unity key code -- either the character itself (like 'k' or '1') or some named entity like 'up' for up arrow or '[6]' for Numpad <6>. See Input article for a list of available key codes.

Next go axisSteer and axisMotor, steering and driving axes. Each of them can be bound to one of KSP's control channels:

• X,
• Y,
• Z,
• Pitch,
• Yaw,
• Roll,
• and Throttle

(Although I'd not recommend using "Throttle" as no reverse gear is implemented yet).
And, in addition, each axis may be "Reversed". For example,

    axisMotor = Pitch
    axisSteer = X reversed

Note that there's no key setting for deploying/retracting wheels, as this action is bound to KSP's 'Landing Gear' control.
<a name=cart_sect_9></a>9. Cart Programming Interface
Starting from v1.34, Cart.dll plugin provides a list of properties allowing any other plugin to control the cart. Here they are:

//------ Capabilities: ------
    public bool hasWheels { get; }
    public bool hasLights { get; }
    public bool hasMotor { get; }
    public bool hasBrake { get; }
    public bool hasHandbrake { get; }
    public bool hasCruiseControl { get; }
    public bool canSteer { get; }
    public bool canDeploy { get; }
//------ Current Status: ------
    public bool wheelsCreated { get; } // false if not deployed, or packed for orbit
    public float speed { get; } // +/- meters per second
    public Vector3 direction { get; } // ...to which cart rides. In World Space.
    public bool controllable { get; } // not the same as Part.isControllable! 
    public bool onRemoteControl  { get; } 
//------ Controls: ------
    public bool wheelsDeployed { get; set; }
    public bool motorEnabled { get; set; }
    public bool steeringEnabled { get; set; }
    public bool lights { get; set; }
    public bool brake { get; set; }
    public bool handbrake { get; set; }
    public bool cruiseControl { get; set; }
    public float cruiseSpeed { get; set; } // +/- meters per second
    public float throttle { get; set; } // -1..+1
    public float steering { get; set; } // -1..+1

Note that referencing Cart class directly obliges end-users to have Cart.dll library installed; so it would be much better to access these properties using System.Reflection.
For example, the following code tests whether some part inherits Cart class:

    Type t = somePart.GetType();
    while( ( System.Object )t != null ) {
        if( t.Name == "Part" ) // stop searching
            break;
        if( t.Name == "Cart" ) {
            // Okay, it's a cart! Make it do something funny...
            ...
            break;
        }
        t = t.BaseType;
    }

And as for getting/setting properties --

    Type t = somePart.GetType();
    BindingFlags b = BindingFlags.Public | BindingFlags.Instance;
    PropertyInfo handbrakeProp = t.GetProperty( "handbrake", b );
    if( ( System.Object )handbrakeProp != null ) ) {
        // LOL the class has this property!
        bool handbrake = ( bool )handbrakeProp.GetValue( somePart, null );
        ...
    }

Yeah, I know, it's complicated... but it allows your plugin to support Cart.dll rather than require its presence. You may use cartControl.cs code as a reference, it does the same things to provide [thread=16347]RemoteTech[/thread] plugin compatibility.
<a name=cart_sect_10></a>10. On Modifying and Distributing
As the Cart Plugin is available under by-sa CC license¹ it is free to use and redistribute as soon as following conditions are met:

• You must explicitly mention me as plugin's author in an author field of Part.cfg. For example,
  author = <your name> || Cart Plugin by Tosh
  
• If you ever modify plugin code (not the model or texture!) then you must release your derivative project under the same by-sa CC license mentioning your name along with mine.
  If you've just created a new model for an unchanged plugin then you may release your model and texture under any license you like.
  
• According to forum rules you must include both plugin .DLL and the source code (even original one!) into your package. An archive must contain README.txt file with all the authors' names and clearly stated license information, Parts/ folder with your model and texture, Plugins/ folder with cart.dll, and Source/Cart/ folder with all the .CS files from an original package.
  
• You must not ask for any permission for creating new cart models or inspecting or modifying plugin code. You already have it .

---

¹With exception for .MU and .MBM files, which cannot be modified, and thus are distributed under CC BY-ND.

Good luck!

Edited August 27, 2012 by Tosh

[JellyCubes]

No words can describe how amazing this is.

[move]<3 <3 <3 <3[/move]

---

A question: a conventional object will explode if the ground comes within 0.2 m of the node_collider origin. Do the same thing happen to the cart wheels?

[Tosh]

A question: a conventional object will explode if the ground comes within 0.2 m of the node_collider origin. Do the same thing happen to the cart wheels?

I don\'t analyze WheelCollider intersections with ground in plugin code, so nothing explodes. The wheel either stands on the ground or is totally below the ground (which sometimes makes a rover jump hilariously 8)).

[Polecat Industries]

I just realized about your cart. Did you mean for the kerbals not to see where they are going?

[Tosh]

I just realized about your cart. Did you mean for the kerbals not to see where they are going?

Do you mean pod windows looking backwards? Why, who gives a darn where do they go? Bill? Jeb? 8)

Being serious I\'ve just modelled and coded a cart along positive Y (which maps to 'forward' direction in Unity); so it\'s the pod that looks back =P. Probably rotating the cart\'s model, swapping forward and backward wheels and reconfiguring controls could fix that, without rewriting the code.

[Tosh]

Do you mean pod windows looking backwards? -snip-

Well, right after two months of being lazy doing some other job I\'ve updated plugin with an option to align a cart with stock pod\'s windows. And added some pictures.

Any new cart modders?

[Emilio]

I would love someone to try to do a motorcycle, but if I can understand Blender i\'ll maybe do iy

[Dani-Sang]

I\'m not using blender but C4D, I didn\'t understand it 100%, but is is possible that you post the hyarchy of the model?

[Tosh]

I\'m not using blender but C4D, I didn\'t understand it 100%, but is is possible that you post the hyarchy of the model?

Do you mean the objects\' relationship hierarchy? It\'s a simple flat list:

BTW can your 'C4D' (whatever the heck it is) import .DAE files? If it can, then you may just open one of those included in the package and look how is it arranged.

[Dani-Sang]

Checked it out and now it makes sense along with the document. One for my To Do list Thx.

[ajor121]

Hello

I have to said that the tutorial on how to make gears is good... I have been plaing whit Blender for a one week now and I have made a plane but i have been strugoing on landing gears, sow I dice to give it a try to u plugings and I come up whit something that im ok whit. Just got a problem Dount know how to make the pluig in to let me start whit the gears down... but at least the plane can and and turn inground not for long in hi speed 8).

[Hojo_Norem]

I've been trying my hand at making some wheels and considering that it's my first time messing around with Blender (seriously, that software seems like it doesn't want to be used sometimes...)

Anyhoow, knowing next to nothing about 3D modelling I have managed to get something into the game and the wheels even work... kinda. It looks like the physics part of the wheels work; I can move and steer but the visible mesh just acts odd. The wheels spin and pivot OK but the suspension is pretty much stuck in the up position all the time, flicking dwon now and again based on the terrain.

My current work files.

I've followed the instructions fairly closely, the only real difference I can see is that the part only has two wheels, the idea being that you could build a large rover or mobile base and then just slap a pair of wheels on each side.

[Tosh]

I've been trying my hand at making some wheels and considering that it's my first time messing around with Blender (seriously, that software seems like it doesn't want to be used sometimes...)

Yep, it really needs you to get yourself used to it . But... I've never heard of easy-to-use 3D software...

I've followed the instructions fairly closely, the only real difference I can see is that the part only has two wheels, the idea being that you could build a large rover or mobile base and then just slap a pair of wheels on each side.

No, you did not : scale's not 1. Open Transform panel in 3D View (<N> key) and notice the scales for wheels and anchors are negative, which effectively inverts their axes directions! Refer to Section 1 on how to reset the scale to 1 -- and do it for all the objects in your file.

After doing that, you may find some normals inverted (in order to see that you may want to tick Textured Solid switch in Display section of Transform panel). I hope you already know how to flip normals' directions

And the last thing: I highly recommend placing both anchors at zero X, to make the gear physically symmetrical. In such a case, the craft having two gears at its sides won't fall sideways.

After applying these three fixes, the gear operates just fine.

[Dani-Sang]

Are you going to make this compatable with .mu extension? I've heard from DYJ that it doesn't work with .mu and only with .dae

[Tosh]

Are you going to make this compatable with .mu extension? I've heard from DYJ that it doesn't work with .mu and only with .dae

Yes, v1.32 supports .DAE only. I plan to release an update... some day.

[Hojo_Norem]

you did not : scale's not 1. Open Transform panel in 3D View (<N> key) and notice the scales for wheels and anchors are negative, which effectively inverts their axes directions! Refer to Section 1 on how to reset the scale to 1 -- and do it for all the objects in your file.

After doing that, you may find some normals inverted (in order to see that you may want to tick Textured Solid switch in Display section of Transform panel). I hope you already know how to flip normals' directions

And the last thing: I highly recommend placing both anchors at zero X, to make the gear physically symmetrical. In such a case, the craft having two gears at its sides won't fall sideways.

After applying these three fixes, the gear operates just fine.

Lol Shows what I know about 3D modelling. I never thought that using the scaling tool in object mode made that kind of change. I did what you said and it works fine, even trundles along at the speed I thought it should (based on mucking with your original rover).

Just one other quick question, is there a reason why you have the cart's crash tolerance to be near indestructible? The hills near my KSP are littered with numerous carts and rovers after various high speed large mun rover designs.

mental note: Do all re-sizing in edit mode from now on...

[Tosh]

Just one other quick question, is there a reason why you have the cart's crash tolerance to be near indestructible? The hills near my KSP are littered with numerous carts and rovers after various high speed large mun rover designs.

There's not a special reason... I just have a bad habit assigning "1e37" to everything I do

mental note: Do all re-sizing in edit mode from now on...

Doing it in Object mode is kinda handy... at least you can immediately see metric sizes in the Transform panel. Just don't forget to 'Apply'

[Dani-Sang]

Another question/request.

Does the plugin recognize the names of all the parts, even if they are child/parent of eachother? I need that because of complex animations etc.

+

Considering it making PartModule?

[Tosh]

Another question/request.

Does the plugin recognize the names of all the parts, even if they are child/parent of eachother? I need that because of complex animations etc.

+

Considering it making PartModule?

Both questions: no, not in the nearest release . Only .mu support is planned.

[Dani-Sang]

Some people were requesting for this how it would look in Unity.

http://i.imgur.com/LBSOZ.png

[Tosh]

Sadly Unity does not display object's origin point... it displays the marker in it's median point instead

I tried to make some screenies of Rover assembled in Unity -- but all of them were quite misleading.

Consider the following:

Yes, that's the lever pointing towards its wheel. It's origin point is located in the center of that round thingy on the rover's side (where a big red arrow points); but Unity displays the marker in the center of lever's mesh.

So, you'll need to type object's coordinates into that Transform/Position boxes, digit by digit...

Edited August 16, 2012 by Tosh

[Dani-Sang]

well.. I've no clue what you are talking about... But I've got mine working: http://www.youtube.com/watch?v=6C3R9Hdm7CU&lc=0ZTWLJsLzGf4fnDowWE8ehi4jBV9YRH8X35lr2mRw98&feature=inbox

[Tosh]

well.. I've no clue what you are talking about... But I've got mine working: http://www.youtube.com/watch?v=6C3R9Hdm7CU&lc=0ZTWLJsLzGf4fnDowWE8ehi4jBV9YRH8X35lr2mRw98&feature=inbox

Yep, I've seen it. Works perfectly

Waitin' for textures... and final release))

[vvaris]

I seem to be having problems with the getting the transparency to work, I use blender and export to dae. I have named the object glass and I even named the .dae file as glass. I have alpha cut off in the cfg file, tried removing it and assigning it to 1 or 0. Using KSP 0.16.

[Tosh]

Did you decrease texture's alpha channel? alphaCutOff has nothing to do with Transparent shaders, it affects Transparent Cutout shaders only (which are used to render some KSP stock parts, e.g. parachutes).

See the link in Section 6 for more information.