artwhaley

I'm trying to do something pretty basic, but it's confounding me... partly because there are about a dozen variables in the KSP API that sound like almost what I'm looking for. I'm trying to build indicators into my plugin that will help you point towards prograde, retrograde, normal, antinormal, and the next maneuver node. Ideally, what the user will see at the end of all my math are pitch and yaw numbers that relate where the nose of the ship is pointed to where they want to burn... so as you approach an ascending node during an intercept, the program would start showing you how many degrees you need to pitch and yaw to point anti-normal to match planes with your target, for example. Similarly, as you approach a maneuver node I'd like pitch and yaw numbers that show the relationship of the control transform to the node... and as you plan a circularization I'd like pitch and yaw numbers relative to prograde or retrograde, whether you've got a maneuver node set or not. I've grabbed the next maneuver node via : Math.Sqrt(Math.Pow((vessel.patchedConicSolver.maneuverNodes[0].DeltaV.x),2)+Math.Pow((vessel.patchedConicSolver.maneuverNodes[0].DeltaV.y),2)+Math.Pow((vessel.patchedConicSolver.maneuverNodes[0].DeltaV.z),2)).ToString() ; And it seems to come out relative to prograde - as in a prograde burn of 1000m/s will return 0,0,1000. But I can't figure out how to figure out where the nose of my ship is pointing relative to prograde or the maneuver node. It seems like it should be pretty basic... but all of the variables I've tried so far seem to return world coordinates... or just numbers that don't make sense in context at all. Art

FREEMAN, I've had success making docking ports work that point different directions - the trick to doing so is to use TWO nodes - a nodeTransformName where the blue axis points out into space, and a controlTransformName where the green axis points into space. I've even animated the controlTransformName so you could orient the ship's control different ways for different flight modes.

Is it from the Klockheed Martian smart parts? I think there are fuel breakers in that one!

I just played around with the Aeria shuttle a little bit and I love it! It is a bit finicky to control, but that's just going to be the case with small aerodynamic vehicles and, in my opinion, a little bit of challenge to the flying skills isn't a bad thing! I don't want the shuttle to just land itself! To the question of landing gear - because COM and COL are so important, and there are so few ways to control them in a small, low parts count model - if you do add any landing gear you probably need to make sure that it has zero mass and drag. Justify it by saying that the design was tuned to cancel out their effect, if you need to, but hanging weight and drag on one side of such a small ship is going to lead to control issues. I'd assume the best way to make a skid is to just make landing gear with an invisible wheel. You'd still use a wheel collider for ground contact, and you could still use the suspension features to add shock absorption to the skid. I've barely got my first set of wheels working, so I'm certainly not an expert, but if you start playing with it and hit a roadblock, I'll happily volunteer anything I've learned to help!

I'm agreeing with the feedback on size. Here it is rescaled to .75... and I think I like it better!

I tried a version with the top hatch and cargo bay and I think it's an improvement. Two pictures added to the album.

mech_engr - I'd LOVE help with the texturing! I'll shoot you a PM to talk about details. Helix - no offense taken at all! The whole reason for posting a WIP is to get feedback on what others see, because when you've been staring at a model for a few days the things that look good-enough to you may jump out at someone else as obviously in need of work.... and vice versa - the things you feel like you just can't get right may be the things others love. I definitely took it as constructive! Art

I'm considering moving the hatch to the very top... and possibly adding a cargo bay. The top hatch is accurate to the original... the cargo bay isn't... but might be a fun item to have... and would give detail to the biggest, most boring part of the model.

Helix... I hope to get better at texturing as I go forward... and I'll keep updating it. It's way better than my last attempt, I promise. Biohazard... Yes... but not right away.

This won't solve the 'lift-drifting-left-of-center' issue... for that we'll have to actually figure out what's going on... but one decidedly non-ideal option I'd pondered for adding FAR to WhimChaser was adding a few completely invisible (fully alpha) pieces that included the surfaces necessary to make FAR happy. That way stock users could just fly it without worrying about it and those that cared could add three or four 'avionics upgrades' that node-attached to the right spots to balance the necessary forces. It's obviously an inferior solution to just getting it to work in the pieces that already exist... but if that doesn't work out, it's always good to have a plan B.

I'm thrilled to see you working on this! Ferram commenting on WhimChaser that it would be pretty impossible to make a FAR compliant ship out of it without subdividing it into several pieces - which makes perfect sense. You might get him... or someone else who's familiar with the mechanics... to talk you through the basic requirements before you start so you don't wind up, like me, trying to stuff 12 kerbals worth of features in a 1 kerbal box after the fact. (EDIT - and if someone DOES give suggestions for a minimal parts FAR functional spaceplane, please share what you learn! ) That said - any progress you make I'll DEFINITELY integrate into the future versions of WhimChaser... and if anything I've done so far can be helpful, don't hesitate to ask. If I get around to making progress on this before you get it all worked out I'll keep you updated! Art

Release Thread: http://forum.kerbalspaceprogram.com/threads/100445-Dreamer-SNC-Dreamchaser-Mod-V1-0-released%21

That helps a lot with understanding suspension... and I found the green ray and now have it pointed at the ground. Nothing I've tried has changed the sinking issue. Any thoughts on whether to use the stock module or the FS version? EDIT! I switched to the FS module again from the stock one... and it's now working with the collider oriented correctly. I'm going to fiddle around a little to see if I've really got it... or if I've still got a hangup somewhere. If it works I'll post a step by step to try to help future browsers...

New Clue. I just checked the logs... and while the model is loaded I get a whole mess of the error: NullReferenceException: Object reference not set to an instance of an object I'm betting that's related. Hmmmmm.

Okay... I set the wheelCollider to layer 27 and renamed it WheelColliders... still falls through the ground. As I've read all of your posts about it... I'm starting to think I'm seeing something different on my wheel collider than you are. If I'm understanding it... you're seeing a green 'ray' that indicates the ground direction and with a length that in someway relates to the suspension distance?... I'm only seeing the normal green, blue, and red axis markers. It's this green arrow that I rotated towards down. Am I looking at it wrong?

I rotated the wheelCollider so the disk is aligned with the direction of travel (like a wheel) and the green axis is pointed at the ground. It still falls right through to the ground.

I did try rotating the whole system to point down in unity (alligning it the same way as the image of the stock gear.) It didn't change anything except the fact that now when I load it in game I have to rotate it 90 degrees one way and 180 degrees another to get it into the right orientation for the model.

I'm not sure I understand... the wheelcollider is round so I thought it needed to be oriented with the wheel, so it would be perpendicular to the ground? I'm going off of what I see in the picture of the stock landing gear in Unity : After your post I tried spinning it to point the blue axis down... And I DID try spinning it so it lay parallel to the ground, perpendicular to the wheel. Neither of these changed the behavior at all. It still sinks right through the gear to rest on its belly. Does the "Bounds" box need a certain orientation? Does the overall model orientation matter in Unity for landing gear? With the model oriented this way it comes into KSP correctly - that is wheel pointed down - so I assumed it's correct... but it could be totally wrong? I also should add that the screen shot of my gear is showing the gear in the down position. I haven't added any animation to the model yet, because I wanted to get the pieces working in the right hierarchy first. So the gear is essentially fixed at the moment.

Okay, I feel like this is going to be one of those questions where I've done something really dumb... but I can't get my landing gear to work so I'm asking for help. I'll attach a Unity Screenshot and the .cfg file code I've tried. I've attempted using both the stock landing gear module and the firespitter fswheel module, and neither makes the wheel collide with the ground. If I take all of the modules out of the part then the wheel collides perfectly... but of course it doesn't roll, because it's not a wheel, so turning on the engines makes the landing gear explode from friction. MODULE{ name = ModuleLandingGear } MODULE { name = ModuleSteering controlAxisType = Forward steeringAxis = 0, 0, 1 steeringTransformName = suspensionParent steeringLocked = true steeringCurve { key = 0 16 key = 10 9 key = 30 2 key = 100 1 } } MODULE { name = FXModuleConstrainPosition matchRotation = true matchPosition = false CONSTRAINFX { targetName = suspensionParent moversName = wheelCollider } } (I've tried both with and without the constrainposition module and the steering module - all have the same result - wheel goes through ground and ship belly slides down the runway.) And the same result with : MODULE{ name = FSwheel wheelColliderName = wheelCollider boundsCollider = Bounds wheelMeshName = Wheel suspensionParentName = suspensionParent rotationAdjustment = 2.0 // adjust the visual rotation speed of the wheel meshes if they are off numberOfWheels = 1 //animationName = Retract disableColliderWhenRetracted = False hasMotor = False motorEnabled = False // set to false for landing gears to start unpowered. motorTorque = 2 maxSpeed = 30 // the motorTorque is 1 at 0 speed, and 0 at this speed, meaning the actual max speed is probably way lower. overrideModelFrictionValues = True forwardsExtremumSlip = 0.01 forwardsExtremumValue = 1.0 forwardsAsymptoteSlip = 0.04 forwardsAsymptoteValue = 0.6 forwardsStiffness = 6000 sidewaysExtremumSlip = 0.01 sidewaysExtremumValue = 1.0 sidewaysAsymptoteSlip = 0.04 sidewaysAsymptoteValue = 0.6 sidewaysStiffness = 500 resourceConsumptionRate = 0.2 resourceName = ElectricCharge //motorStartsReversed = True brakeTorque = 15 brakeSpeed = 0.5 animationLayer = 1 deployedDrag = 0.2 retractedDrag = 0.0 guiActiveUnfocused = True unfocusedRange = 5.0 brakeEmissiveObjectName = brakeLight onEmissiveColor = 1, 0.3, 0 offEmissiveColor = 0, 1, 0 deployingEmissiveColor = 1, 0, 0 disabledEmissiveColor = 0, 0, 0 } MODULE { name = FSwheelAlignment } In Unity the file is setup with - the top level is a game object named nosegear with parttools added, Bounds is a game object with box collider that exceeds the bounds of the wheel by a bit... suspensionParent is an empty game object located at the same center as the Wheel and the wheelCollider wheelCollider is a game object with a wheelCollider that exceeds the edges of the wheel object by a little bit.

It's exactly because that's what the first tutorial I followed did... and so now that I have a process that works I haven't wanted to mess with it and spend time learning the kinks of a new method. I probably SHOULD learn how to send blend files straight to unity - I'm sure some day I'll be banging my head against the desk over a problem that would have just been fine if I hadn't been converting to fbx! But I haven't gotten there yet... so I've just kept modelling stuff the way I'm used to because modelling stuff is more fun than relearning how to make the programs talk to each other! Art

If you load a saved game that used a part that no longer exists in your gamedata directory... the game throws up an error about any ships that used that part not being loaded... and they're just gone. Even if you immediately exit and reload the game - any ships that weren't loaded are gone forever. This can be really frustrating if you forgot that you'd used a strut or some other piece from that otherwise unused mod you wanted to delete.... or for those of us that make parts it's really annoying when we make a mistake in our config file editing and NONE of the parts in the game get loaded... so all of our test vessels explode. It would be great if, after loading a saved game where errors are generated, you got an option to abort and NOT save the new version with your exploded ships.

A built-in nose-on docking would be possible with this method, but what I was testing was the ability to build a docking port on the tail, just where it is in the demo pictures. With a separate docking port attached to the back of the shuttle, it's easy to right click that docking port and select 'control from here' and it flips all of the controls around so you can dock without having to think backwards. I was demonstrating a way to get the controls to flip around WITHOUT having a separate part - so the docking port could be modeled into the shuttle to avoid another part and another texture - and still allow the shuttle to fly normally most of the time, but with reversed controls(and a correctly reading navball, navyfish docking plugin, and mechjeb docking autopilot) when you wanted to dock.

Odyssey - I'm terrible enough at texturing it as is. I'm not quite ready to start a second skin for it! Ferram - I hadn't looked into that at all. I may pass on integration for this model then and on my next project plan for FAR from the beginning! Thanks for letting me know before I started banging my head into the desk! I haven't seen the RCS fire in the VAB. I'll see if I can replicate... not that I'd know what to do about it if I found it... but it's a start. And a dorsal attachment node is definitely in the plans to make it easy to line up the retracting docking port... and there's no reason at all it couldn't be repurposed to attach something else. I also might add a couple of nodes to the service modules... as that sort of seems like a more appropriate place to strap your luggage! Art

I did a quick test for an integrated docking port and it works! I added an extra cube to a model in blender and animated it to move and rotate from pointing straight up at the front of the model to pointing straight back at the bottom of the model. Took it into Unity, created two empty game objects - dockingNode and controlNode. Placed dockingNode at the docking port location with blue axis pointing out towards space. Placed controlNode at the location of the animated cube with green axis pointing towards space(parallel to the ship's axis of travel). Parented controlNode to the cube and took the MeshRenderer off the cube to make it invisible. Exported to KSP. Added to .cfg file MODULE { name = ModuleDockingNode deployAnimationController = 1 nodeType = size1 nodeTransformName = dockingNode controlTransformName = controlNode } MODULE { name = FSanimateGeneric animationName = change startEventGUIName = control from docking port endEventGUIName = normal axis control toggleActionName = toggle control axis } Tossed the thing on the launchpad. I had to click 'control from here' once to make control start following the pod's controlNode, but after that running the animation smoothly moved the control axis around exactly as expected! The only little annoyance was that both the command pod and the docking module add a 'control from here' button to the context menu of the pod... so there are two of those... but they seem to function identically - doesn't matter which one you click. So an integrated docking port with no additional part should be perfectly possible. Maybe someone else knows a trick to remove one of the 'control from here' buttons... or to make it automatically 'control from here' so you don't have to click one of those buttons to make it start following the transform? I made a quick video that walks through what I did in blender, unity, and ksp to demonstrate the steps if someone wants to add it to the Pteron model. (edit - in the video I added the mesh rendered BACK to the cube so that you could see it move in KSP.)

The problem with adding an integrated docking port is that it makes the 'control from here' stuff a little tricky if the docking port isn't at the very front center of the command module... which these shuttles don't lend themselves to. I added the integrated docking port to my service module parts... not the command pod itself. Now... I don't know why you couldn't animate a controltransform to move around the ship... so you would have an extra context menu button to change the axis of control? I'll try to test that later. In the end - the docking port is important enough that I do think it's worth another part to most users and they can always delete it and use the stock one if they're really concerned about their ram usage!