Dr_Goddard

February 20, 2019

On 2/18/2019 at 5:30 PM, ZodiusInfuser said:

Hey! I realise this isn't my thread, but just thought I'd show you my Unity walking sim progress since I last posted here.

Very Cool! Great algo

April 6, 2018

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.

April 1, 2018

You should only need to install the latest patched dll file

March 21, 2018

Nice work on the omni wheels!

March 19, 2018

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

March 9, 2018

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.

March 7, 2018

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.

March 6, 2018

5 hours ago, E.Nygma said:

Hi again,

I have taken a look at the document you posted, that's pure gold. Thanks very much! I think I might be able to recreate the current effect.
And, regarding the issue with the backward smoke:
t seems to me that the original creator used a fixed particle system blowing from launchpad to sea, meaning that the current part is only used as a starting point for a cone of particles, so the orientation of the part should not matter?
Can someone test this with different part orientations? In my test install an octosat with mirrored vaporvents around confirmed this behavior. Importing the original model.mu into blender unfortunately destroys the actual effect.

Thanks again,

See you soon!

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.

February 26, 2018

2 hours ago, ZodiusInfuser said:

Got some things to fix still, like why the IR Base piece gets recentered at the part origin, and how to turn off the KSPWheel scaling options (as there's already TweakScale configs), but your guide saved me a tonne of time! I don't suppose you know or can point me to a guide explaining how to set up multiple wheels in a single part?

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.

February 24, 2018

Release or die LOL it's the coder rule.

February 19, 2018

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.

February 18, 2018

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.

February 14, 2018

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.

February 14, 2018

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?

February 14, 2018

17 minutes ago, Starwaster said:

Are... are those shopping cart wheels???

LOL Yup.

February 13, 2018

Absolutely. Of course they look a bit familiar? heh heh

I can send you the .blend and .unity files .cfg and such?

It really is butt simple to set such a simple mechanism up. I think I was overthinking it like we all tend to do.

February 13, 2018

February 13, 2018

Ok. Everything is working perfectly!

I just have to make some changes to the model to improve the look of the suspension and I will post a quick video.

February 12, 2018

A few questions sir.

Is it fair to say the KSPWheelComponent Unity script is not a great simulation for what will happen in game?

Is the Unity plugin very sensitive to imbedded transforms on models imported from Unity?(un-applied?)

(i got very lazy because I was able to just chuck a model into an empty game object and Bob's your uncle.

Do you just chuck things into empty game objects and manage trransforms that way,? i seemed to get a lot of very odd behaviour.

I'll post my .unity file later. But right now I think I'm damn close to getting this.
I probably need some help with suspension transforms. I'll keep you posted.

Thanks!

February 11, 2018

Hey @Shadowmagej thanks for all your hard work on the API it's really amazing.
I have just gone through a week of study and Blender/Unity acrobatics to get to the point I can ask some intellligent questions..
(BTW do people realize they can import a blend file as an asset in Unity and update it on the fly?)

Anyway, i think I could do a fresh perspective on the tutorial.I'm gonna give it a try.

Meanwhile, I have a small remaining problem. It is lik

e my wheel has a bump it rebounds off of at each revolution.

beyond that everything seems normal.

I have only the wheel collider ias far as colliders in the model.

November 10, 2017

This *MAY* be a problem with the part CFG files themselves.
There was a breaking change made to some of the CFG files about a year and a half ago.
Specifically the part names of some legacy parts were changed in the CFG files I suppose for consistency or perhaps compatibility with the sequencer or something.
In any case, you would either have to fix the names in the config files, which might break something else, or make the ships over again.
There is a program that might let you edit the part names inside your craft files.
This could be very tricky, but might work.
https://kerbaledit.codeplex.com/

November 1, 2017

On 10/31/2017 at 12:11 AM, HZ1 said:

Help I have no interface appears in Infernal robotics. versions 1.3

Clean install might help.

This is what typically happens if you have files from the IR mod in your KSP root directory... found out by experience.

Make sure you don't have multiple copies of IR files.

October 31, 2017

1 hour ago, ss8913 said:

so I'm confused.. 2.0.14 is the plugin/core.. where are the parts?

This is MM (Module Manager) You need this for almost every mod in KSP

Trust me, If you fallowed "all" my instructions. all the links are current as well as functional in 1.3

IR for 1.3 / KJR issues

List of IR download files to work with KSP 1.3

Remove "Active struts" as well as "strut" Folders" they are currently incompatible with KSP 1.3 - Unless you opt to use the unofficial Recompiled .dll linked below

Steps to install Infernal Robotics

1) Install Core Download which is the plugin and "core Files" of IR (No parts are in this download)

2) Install Parts Pack (Legacy is the original parts, and Rework are the new white parts. You can have both installed if you wish)

3) Remove folders "IRActiveStruts" and "Struts" as they are currently incompatible

4) Optional - If you wish to use the Surface sampler - Install the Surfacesampler.dll linked below into GameData/MagicSmokeIndustries/Parts/Rework_Utility/Plugins

5) Optional - KJR unofficial recompile will work with KSP 1.3 and IR 2.0.12 - Linked below

6) Optional - KAS Magnet / Grasper Breaking? Increase "breakForce" under the KAS module in the part cfg to "= 999"

7) Optional - Unofficial recompile of Active Struts Plugin linked below. Curtesy of Whale_2

Core Download

Infernal Robotics (Ziw) 2.0.12

https://github.com/MagicSmokeIndustries/InfernalRobotics/releases

Parts / Plugin

Legacy Parts (Ziw)

https://github.com/MagicSmokeIndustries/InfernalRobotics/releases/download/2.0.0/IR-LegacyParts.zip

IR Rework Parts (Zodiusinfuser) - See Active Struts notes above

https://mega.nz/#!rdlHkLAJ!ZizDvd8s7zCIG529FtO8b7wM0avJ8yC3pldIaf6BGFw

Surface Sampler dll (DMagic) - Place into "MagicSmokeIndustries/Parts/Rework_Utility/Plugins"