Dr_Goddard

Hey Rudy, can we get into discussions with the kOS dev team to make this API connect with kOS? Also, maybe I can resurrect some legacy parts if the need arises. I am willing to try and re-source some parts if it makes sense.

You should only need to install the latest patched dll file

Nice work on the omni wheels!

Putting the Kexapod through it's paces. This is a demo of almost everything the robot can do to this point. Hope you enjoy. Craft and necessary files repository: https://github.com/pgodd/Kexapod/commit/4bd9da79683a692ec625232e8aab949c14fe3d61

If you aimed two IR lasers downward from each foot, angled with a convergence, an IR detector aimed at the convergence would have a varying strength of return with the most powerful return being when the beams converged on the walking surface. I'm working with a client who uses a very similar principle to get measurements with an accuracy of a few mm. The components are cheap and easy to get. Good work on the terrain adaptation. I'd love to get a peek at your code. I can trade you my gait generation and steering solutions.

Good on you! i will give a tip. Experiment with the image used by the particle system. This is perhaps 50% or more of the realism of the effect.

The vapor blows in the direction of the prevailing wind as suggested by the flag on the flagpole. Randomness, including vapour blowing in the opposite direction for short erupts is a function of randomness injected by the particle system component. If you want a different behaviour or a different model, you may have to invest several hours in experimenting with the effect in Unity as I did. Simply copying the part won’t get you any results.

You'd be not supposing correctly. @Shadowmage made some explanations of the solution earlier in this thread. I'd be talking out my sphincter if I tried to comment without looking it up. Good job on the wheels! Glad to help.

Release or die LOL it's the coder rule.

So the function would be to attach an object and move on rails? @zodiusinfuser and I are good friends, no problem there. Whatever models make you happy.

That was easy. I'm not sure what you mean by the rails. Did you want a linear rail device like a slider on a track? Can you give a real world example? Just BTW, the parts I've drawn will not automatically align themselves without code to make that happen. You might want to consider a round analogy of this part.

Just a bit of a walk-through of making my wheels work with KSPWheel. I read everything I could before embarking on using KSPWheel. As you can imagine over the course of development with many-many versions and many mod devs integrating KSPWheel into wonderfully complex models, some information is deprecated. I thought a quick and straightforward walk-through using my recent wheel development as a basis would help beginners like me. I first created my pinionWheel model in Blender and made sure to apply all transforms and rotations before dragging my .blend file into my Unity assets. This is a great way to model because you can make changes in blender on the fly and they update in Unity as soon as you save the file. I created an empty gameObject at 0,0,0 , renamed it pinionWheel, and added partTools by clicking on add component. Then I dropped my pinionWheel model into the scene and positioned it under the pinionWheel gameObject in the hierarchy tree. I arranged all the parts as you see in the tree. All the objects are meshes except the wheelCollider which is an empty gameObject(i'll get to that) The top plate is the mounting point. You can call the parts anything you want, they are identified by their name in the config file. I'll put the config file in the post at the end. It's important the root part has a collider mesh, or you can make a separate gameObject with a collider mesh attached if you want to put the object into a layer26 [wheelColliderIgnore] to prevent interference wit the wheelCollider(wheelCollider explanation coming). This root part also MUST have a rigidBody component. This is just to show the topPlate is a mesh, not an empty transform. I had real problems with using empty transforms. @ShadowMage you seem to be telling me I shouldn't have these problems, but the example car in the UNITY scene you provide on GitHub is built like this, and it works... so cool. You're gonna need a wheel. This wheel is three parts. Not necessary at all, but that's the way I rolled it this time. I found if I child the hub and axle off the tire parent it works nice. Wheel components must share a COMMON location 0,0,0 and rotations should be 0,0,0. The rest of the parts transforms don't really matter. The wheel must also be positioned so Y+ is up and Z+ is forward. (The objective is to get the wheel pivot point along the X axis. The Rotator is my steering axis. It is directly in line with the centre of the wheel. In the case of my model, everything pivots with steering except the topPlate. So all the parts are children of the topPlate. In my model, I wanted the chainPlate to move up and down with the wheel when the suspension moves. So the wheel parts are a child of the chainplate. Last but not least... wheelCollider. The wheelCollider is the magic component that does it all. But it's not a collider at all in UNITY. It's just an empty game object with the same origin and rotation as the wheel in your model. Just an aside. I found the scripts @shadowmage provided for UNITY to be a bit counterproductive for me. I just couldn't get the part to function properly in the UNITY game simulation. So I spent a lot of hours messing around in UNITY when the scripts are NOT AT ALL NECESSARY to making the KSPWheel API work for you. All you need is a properly organized gameObject hierarchy. No standard wheel colliders. No bounds box. No colliders necessary except for your non-wheel parts if you like. You must have at least ONE collider object in the model or you can't grab parts in the ship editor. So aside from the empty wheelCollider gameObject there is NOTHING SPECIAL about any of the parts. Without the KSPWheel.dll this would be a regular static part, except it would have no collider attached to the wheel and it will sink into the ground. KSPWheel generates the actual wheel collider it uses programatically. All the setup and configuration is done in the config file. PART { // This is a very basic... the most basic wheel setup possible I think... KSPWheel rig // --- general parameters --- name = wheel module = Part author = Dr_Goddard // --- asset parameters --- mesh = Wheel.mu scale = 1 rescaleFactor = 1 // nodes are not placed correctly yet. I wanted to look into the "new way" I've been hearing about. // --- node definitions --- // definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z, [node size], [crossfeed, def=1 i.e. true], [rigid attach, def=0 i.e. false] //node_stack_bottom = 0.75, 0.75, 0.0, 0.0, 0.0, 0.0, 1.0 node_stack_top = 0.0, 0.75, 0.0, 0.0, 1.0, 0.0, 0 node_attach = 0.0, 0.75, 0.0, 0.0, 1.0, 0.0, 0 CenterOfBuoyancy = 0.0, 0.5, 0.0 CenterOfDisplacement = 0.0, -0.3, 0.0 buoyancy = 1.5 buoyancyUseSine = False // --- editor parameters --- TechRequired = Start entryCost = 0 cost = 200 category = Ground subcategory = 0 title = Wheel manufacturer = Squalid-State Devices description = You just have to be different don't you? // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,1,0 // --- standard part parameters --- // --- Standard Part Parameters --- mass = 0.15 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 50 maxTemp = 2000 breakingForce = 100 breakingTorque = 100 MODULE { name = KSPWheelBase wheelColliderName = wheelCollider // remember the wheelCollider empty object at 0,0,0? This is it. wheelColliderOffset = 0 wheelRadius = 0.4 wheelMass = 0.07 suspensionTravel = 0.15 //I saw old references to a minimum .25 for suspension travel... but it seems it was improved since loadRating = 1.5 minLoadRating = 0.25 maxLoadRating = 3 maxSpeed = 100 groundHeightOffset = 0.4 //this is your wheel ride height adjustment //boundsColliderName = Bounds } MODULE { name = KSPWheelRotation wheelMeshName = tire //this is the tire mesh in the model. Remember, all the other spinning components (hub/axle) are children. rotationAxis = 1,0,0 } MODULE { name = KSPWheelSuspension suspensionName = chainPlate //This is my parent suspension part. Everything that moves up/down with suspension should be //a child of this suspensionOffset = 0 suspensionAxis = 0, 1, 0 } MODULE { name = KSPWheelSteering steeringName = rotator //this is the parent part of components that move with steering maxSteeringAngle = 30 steeringAxis = 0, 1, 0 } MODULE { name = KSPWheelMotor maxMotorTorque = 2.6 maxRPM = 2500 } MODULE { name = KSPWheelBrakes maxBrakeTorque = 12 } //MODULE //{ // name = KSPWheelDamage // wheelName = wheel // bustedWheelName = bustedwheel //} MODULE { name = KSPWheelDustEffects } MODULE { name = KSPWheelSounds } } I hope this helps someone. Edit: I noticed my .CFG file calls pinionWheel just "wheel". Just imagine it says pinionWheel where is says wheel and yer good. I needed to change it for debugging.

The suspension does wonders for the realism of movements. Sorry about the video quality, I do all my development on an old Macbook I need some help with the setup to use 6 wheels. I have to add actuators to turn them in the right direction. Will KSPWheel resolve any of the setup for multi wheels on it's own?

LOL Yup.