[WIP] Mass Driver Parts and Plugin, request for modeling help!

[lo-fi]

Cool, I'll commit and sync in the morning.

By the way, I was thinking of making the rails glow after firing like overheating engines do:

http://forum.kerbalspaceprogram.com/threads/25023-Emissive-tutorial

If you can script it, I'll set it up on the model

Also, how about a small (3 secs? Or even configurable?) countdown before launch and an abort button? Could put an animated bit or two in as it's preparing to fire. I was thinking the loops closing over the front side, sequenced top to bottom would look really cool, and being completely clear of longer payloads while loading would be no bad thing.

[spiritplumber]

This is almost working perfetly, one thing that isn't is if I undock from the railgun, and then dock to it again, it doesn't work. If I move the railgun logic to a docking port, the railgun doesn't fire.

[lo-fi]

Hmmm, that's interesting about the undock, redock. Great that you're testing. What do you mean by moving the logic to a docking port?

Peter, can we add add a print() statement bound to a gui button that will dump the current state of all your plugin variables to the log? Might be really handy while people are testing.

[spiritplumber]

I tried to take the massdriver module and stick it onto a docking port, and see if that'd allow redocking.

The part as it is, does NOT let me dock to it.

The modified docking port works normally as a docking port, but the massdriver will work with a part that the massdriver starts docked to HOWEVER not with a part that the massdriver is docked to later. In that latter case, all numbers read 0, as if there was no part connected.

[lo-fi]

Perfect, that's brilliant info. I think I know whats wrong, will cast an eye over the code later.

I'll hopefully post a model release later this evening too.

Edited June 5, 2014 by lo-fi

[PeterDolan]

I tried to take the massdriver module and stick it onto a docking port, and see if that'd allow redocking.

The part as it is, does NOT let me dock to it.

The modified docking port works normally as a docking port, but the massdriver will work with a part that the massdriver starts docked to HOWEVER not with a part that the massdriver is docked to later. In that latter case, all numbers read 0, as if there was no part connected.

That's super helpful, thanks Spiritplumber. I think this is caused by the code not properly detecting parts that are connected to the docking attachment point, while they do detect those that are connected to the "top" attachment point. I'll try to sort this out soon. Thanks!

[PeterDolan]

Cool, I'll commit and sync in the morning.

By the way, I was thinking of making the rails glow after firing like overheating engines do:

http://forum.kerbalspaceprogram.com/threads/25023-Emissive-tutorial

If you can script it, I'll set it up on the model

Also, how about a small (3 secs? Or even configurable?) countdown before launch and an abort button? Could put an animated bit or two in as it's preparing to fire. I was thinking the loops closing over the front side, sequenced top to bottom would look really cool, and being completely clear of longer payloads while loading would be no bad thing.

Yes. All of that.

Another thing to think about is plasma rails. There's a form of advanced mass drivers that do not have physical rails. Instead, they ionize the space where a rail would be and run sufficient current down that pathway to create a plasma "rail", which is an excellent conductor of electricity. This costs a lot more in power, but the plasma rails do not degrade over time. Metal or other physical rails are damaged each time they are fired, which limits the lifespan of real mass drivers.

I think it would be totally rad if we could animate a virtual plasma rail that's generated during the countdown to firing. Then, we could create advanced plasma-based mass drivers that are later in the tech tree, and add a "wear" parameter to those that still use physical rails. I imagine that the driver would "wear out" by reducing its efficiency, and that a kerbal on EVA could repair it. This would make it more challenging to set up remote bases that have no kerbals present, unless you had reached a higher tech level. What do you think?

Edited June 5, 2014 by Navy4422
Language

[lo-fi]

Awesome. Got a little held up doing bits on my wheel mod. Just figured out how to make the suspension visuals works properly - ie swinging in an arc with the suspension arms, rather than the somewhat unrealistic sliding joint most have. Looking seriously sweet and can't wait to release.

Had a few hours in the car today to daydream and have some (what I hope will be) kickass ideas for animations on the driver which I'll get to shortly.

Plasma rails, huh? Love the idea! I believe might be done with particle emitters. However, to create them I think you need the paid-for version of Unity, plus I have no idea how it's done. I'll keep an eye out for tips on how you might go about that, though I believe we are in uncharted territory as far as KSP modding goes.

[PeterDolan]

Good and bad news. Thanks to spiritplumber's report, I investigated the docking question more closely, and I think we've found a bug in the core game's docking node module.

Try this: set up a ship with a pair of docking nodes connected to each-other in the middle. Undock the two docking nodes by right-clicking on node A and selecting Decouple. Re-dock the nodes. Then, right-click on node A, and notice that you can't actually undock from that part a second time. This is correlated with a message in the debug menu about a part joint being invalid.

Ultimately, this means that docking port A is unaware of being connected to a part at its top node.

I'll try to figure out a workaround for this, but it's a bit tricky, and I'm disappointed that the core docking node module won't work for us in this way.

[lo-fi]

Oh, that's a shame. I'll have a nose through the bug tracker, see what I can dig up.

[spiritplumber]

My workaround was to have both parts "be" a railgun, but that's definitely silly (I put that up on the thread above).

[PeterDolan]

Good news: I fixed the docking port problem.

I've updated the code and plugin in Github, go ahead and re-download it from there. I'll update the direct download link too soon.

Here's what has changed:

* Fixed the docking port problem. Now, if you decouple, and reconnect the part, the mass driver will be able to find and launch its payload.

* Changed the discharge power setting to a tweakable, so that you can set its power to any % of its maximum power.

I fixed the docking port issue by removing any dependency of the mass driver on the docking port. So, instead of using the docking port's attachment node, which doesn't seem to be properly populated by the docking module, I'm directly inspecting the mass driver's children and parent parts. When a ship is repacked after docking, the child and parent parts are properly populated. This is a little wonky though, as the way I'm figuring out which part is the mass driver's payload is by calculating the vector between the mass driver part and each of its children and its parent. Then, I compute the dot product of the mass driver's normalized direction vector, and the normalized direction vector to its parent and each of its children. Whichever dot product comes out very close to 1 is in the path of the mass driver, and is considered the driver's payload.

One somewhat nice upside of this is that now the mass driver is now completely independent of any other modules. Anything that can attach to the mass driver (precisely where its top attachment node is) can be fired by the mass driver.

[spiritplumber]

Peter, it works great! I cannot redock with the included part, but when I put one together out of an existing docking port, it operates flawlessly. Congrats!!!

Here's something I quickly put together that gives a testable massdriver, using stock models.

PART
{

// --- general parameters ---
name = massdriver_single
module = Part
author = Peter, with help by spiritplumber

MODEL
{
   model = Squad/Parts/Utility/dockingPortLarge/model
   position = 0, 0, 0
   scale = 0.5, 4.0, 0.5
   rotation = 0, 0, 0
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
// texture = model000 , Squad/Parts/Command/probeCoreOcto/model000
// texture = model001 , Squad/Parts/FuelTank/fuelTank2-2/model001
}

MODEL
{
   model = Squad/Parts/Utility/longAntenna/model
   position = 0.5, 0, 0.5
   scale = 2.5, 5.0, 2.5
   rotation = 0.5, 0, 0.5
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
// texture = model000 , Squad/Parts/Command/probeCoreOcto/model000
// texture = model001 , Squad/Parts/FuelTank/fuelTank2-2/model001
}

MODEL
{
   model = Squad/Parts/Utility/longAntenna/model
   position = -0.5, 0, -0.5
   scale = 2.5, 5.0, 2.5
   rotation = 0.5, 0, 0.5
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
// texture = model000 , Squad/Parts/Command/probeCoreOcto/model000
// texture = model001 , Squad/Parts/FuelTank/fuelTank2-2/model001
}

MODEL
{
   model = Squad/Parts/Utility/longAntenna/model
   position = -0.5, 0, 0.5
   scale = 2.5, 5.0, 2.5
   rotation = 0.5, 0, 0.5
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
// texture = model000 , Squad/Parts/Command/probeCoreOcto/model000
// texture = model001 , Squad/Parts/FuelTank/fuelTank2-2/model001
}

MODEL
{
   model = Squad/Parts/Utility/longAntenna/model
   position = 0.5, 0, -0.5
   scale = 2.5, 5.0, 2.5
   rotation = 0.5, 0, 0.5
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
// texture = model000 , Squad/Parts/Command/probeCoreOcto/model000
// texture = model001 , Squad/Parts/FuelTank/fuelTank2-2/model001
}



rescaleFactor = 1

node_stack_top = 0.0, 1.16, 0.0, 0.0, 1.0, 0.0, 1
node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1
node_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0

// --- FX definitions ---

fx_gasBurst_white = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, decouple
sound_decoupler_fire = decouple


// --- editor parameters ---
TechRequired = advConstruction
entryCost = 28000
cost = 440
category = Propulsion
subcategory = 0
title = Mass Driver Base
manufacturer = Robots Everywhere LLC
description = This docking port contains an advanced mass driver system (Or maybe it's just a big spring, we're not sure) that can be used to fire payloads into a suborbital 

trajectory. It is compatible with a standard Clamp-o-Tron connector and features shock absorbers for use on a planetary surface. Warrany void if used on a planet with 

atmosphere.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 3.5
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 2
crashTolerance = 30 //10
maxTemp = 3400
fuelCrossFeed = False
breakingForce = 200
breakingTorque = 200

//stageOffset = 1
//childStageOffset = 1


MODULE
{
    name = MassDriverEjection
    DischargeNode = top
    Efficiency = 0.8
    RailWidthMeters = 1.25
    RailRadiusMeters = 0.1
    RailResistanceOhms = 0.000000143
    MaxMegajoulesDischarged = 10
}

MODULE
{
    name = ModuleDockingNode
    referenceAttachNode = top
    nodeType = size1
//    undockEjectionForce = 30
}

}

[PeterDolan]

Thanks SpiritPlumber! Do you have any experience working with the models directly? I'd be happy to add you to the github project so that you can collaborate with lo-fi. If yeah, just let me know what your github username is.

lo-fi, I noticed that the docking port models all have an empty node in the model that's called "dockingNode", and I think that's necessary for the docking port module to correctly tie two docking ports together. I think this is a little silly, as it doesn't seem reasonable for the docking module to do deep inspection of the model elements themselves, but the game does that anyway when it looks for collision meshes and etc. I tried updating the model myself with blender, but when I try exporting it as a .mu file, I can't get the textures / materials to work right. When you get a chance, could you look into this for the existing model? Once we have that, and we have the geometry of the part finalized (chopping the base down to size), then we can start using the model in more persistent games and start doing game balance work on the amount of electric charge consumed, and the power of the ejection force.

Thanks everyone for all your help testing and developing!

[lo-fi]

Excellent, was going to look into whether the stock models have a dummy gameobject somewhere. I'm having a really busy weekend, but will get some time over the next few days. Nice work guys.

[spiritplumber]

Hey Peter I am super busy with my kickstarter (btw I'm the person who sent Squad the autonomous rovers as thanks for implementing rover wheels last year) so can't help with modeling, sorry... that was just me messing around with cfg files i'm a hardware person not a modeler

If anyone wants to test the mechanics for now, this is independent of other mods:

RESOURCE_DEFINITION
{
  name = Megajoules
  density = 0.000
  flowMode = NO_FLOW
  transfer = NONE
}

PART
{

// --- general parameters ---
name = massdriver_single
module = Part
author = Peter, with help by spiritplumber

MODEL
{
   model = Squad/Parts/Utility/dockingPortLarge/model
   position = 0, 0, 0
   scale = 0.5, 4.0, 0.5
   rotation = 0, 0, 0
// parent = anotherModelTransform	<---------Not necessary unless Second or subsequent part.
// texture = model000 , Squad/Parts/Command/probeCoreOcto/model000
// texture = model001 , Squad/Parts/FuelTank/fuelTank2-2/model001
}

rescaleFactor = 1

node_stack_top = 0.0, 1.16, 0.0, 0.0, 1.0, 0.0, 1
node_stack_bottom = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1
node_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0

// --- FX definitions ---

fx_gasBurst_white = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, decouple
sound_decoupler_fire = decouple


// --- editor parameters ---
TechRequired = advConstruction
entryCost = 28000
cost = 440
category = Propulsion
subcategory = 0
title = Mass Driver Base
manufacturer = Robots Everywhere LLC
description = This docking port contains an advanced mass driver system (Or maybe it's just a big spring, we're not sure) that can be used to fire payloads into a suborbital trajectory. It is compatible with a standard Clamp-o-Tron connector and features shock absorbers for use on a planetary surface. Warranty void if used on a planet with atmosphere.

// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,1,0

// --- standard part parameters ---
mass = 3.5
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 2
crashTolerance = 30 //10
maxTemp = 3400
fuelCrossFeed = False
breakingForce = 200
breakingTorque = 200

//stageOffset = 1
//childStageOffset = 1


MODULE
{
    name = MassDriverEjection
    DischargeNode = top
    Efficiency = 0.8
    RailWidthMeters = 1.25
    RailRadiusMeters = 0.1
    RailResistanceOhms = 0.000000143
    MaxMegajoulesDischarged = 1
}

RESOURCE
{
 name = Megajoules
 amount = 0.0
 maxAmount = 1.1
}


MODULE
{
    name = ModuleDockingNode
    referenceAttachNode = top
    nodeType = size1
}

MODULE
{
	name = ModuleGenerator
	activateGUIName	= Charger ON
	shutdownGUIName = Charger OFF
	  INPUT_RESOURCE
      {
        name = ElectricCharge
		rate = 10.0
      }
	  INPUT_RESOURCE
      {
        name = ElectricCharge
		rate = 10.0
      }
	OUTPUT_RESOURCE
	{
	   name = Megajoules
	   rate = 0.01
	}	 		  
}


// represents leakage
MODULE
{
	name = ModuleGenerator
	requiresAllInputs = true
	isAlwaysActive = true
	INPUT_RESOURCE
      {
        name = Megajoules
        rate = 0.001
      }
	INPUT_RESOURCE
      {
        name = Megajoules
        rate = 0.001
      }
	OUTPUT_RESOURCE
	{
	   name = Megajoules
	   rate = 0.001
	}	
}




}

[Xentoe]

how about some pictures?

[lo-fi]

how about some pictures?

I'll post some when I've finished wrangling the animation, docking node and some textures into shape, I promise! Very, very early stages at the moment

[lo-fi]

Latest model, just showing off the firing sequence animation. Finally got to grips with it, just trying it out. Peter, I've added a dummy object called dockingNode, will upload the latest model to Git presently for you guys to try out.

Edited June 9, 2014 by lo-fi

[Javster]

A crude way I can think of is teleporting any object within an area too a specific orbit

[skykooler]

Latest model, just showing off the firing sequence animation. Finally got to grips with it, just trying it out. Peter, I've added a dummy object called dockingNode, will upload the latest model to Git presently for you guys to try out.

I like that it lands to the left of the mass driver. This is actually caused by Kerbin's rotation! (When it's higher up, it covers less angular distance, so Kerbin rotates slightly underneath it.)

[lo-fi]

That occurred to me too

[PeterDolan]

Latest model, just showing off the firing sequence animation. Finally got to grips with it, just trying it out. Peter, I've added a dummy object called dockingNode, will upload the latest model to Git presently for you guys to try out.

That looks great, lo-fi! Looking forward to trying it out!

[lo-fi]

Bah. I got distracted and didn't upload. Will sort out shortly. Glad you like it

Desperately need a texture artist :/

[PeterDolan]

Now that things are generally working correctly, and we have a very nice super awesome model ( ), I'll make some posts around pleading for texturing help.