[1.2.2] Netherdyne Mass Driver Mod- Version 1.3.2 is now LIVE!

[Northstar1989]

476.5 Tons. Far is on but I turned of aerodynamic structural failures as the slug would implode upon leaving the barrel (Making for a boring launch).

Oh and...http://img.photobucket.com/albums/v239/RyongVonKaiser/boom_zpsvhro3ixo.jpg

OK, it took me a bit of tweaking and testing of my own to figure out what was going on with you, as I've definitely experienced downward recoil when firing straight up before... (at least I *THINK* it was downward recoil- it would slam the Mass Accelerators into the launchpad, and struts/clamps seemed to fix it...)

Turns out that what was going on is that the payload was getting a little bit caught on the loading rails (probably clipping slightly into them) and the Mass Accelerator was thus trying to accelerate the ENTIRE firing platform forward instead of just the payload to a degree.

I was just building ultra-lightweight horizontal launch platforms of my own- often the payload would get a tiny bit stuck on one of the loading rails (I used Firespitter helicopter landing pads as rails, for what it was worth), and the Mass Driver would thus pull the ENTIRE platform forward- never mind the fact that, physically, it shouldn't be able to accelerate itself... (its kind of like the Kerbals-on-ladders physics bug: it's a result of how KSP calculates physics rather than of the source of force itself...)

I don't know how to fix this, but I do know this- recoil is currently unlikely to be simulated correctly, as there seems to be a tendency of the Mass Driver to pull themselves along with the payload they are firing. The most reductive way I could imagine if finding if recoil is still currently being simulated correctly is if one were to build a spacecraft that approaches a single Mass Accelerator ring in-orbit (with some radial batteries and a command pod attached around the ring's rim), and the Mass Accelerator were to accelerate that spacecraft...

It's also possible that I wrong about recoil entirely, or that the mass accelerators were pulling themselves apart during vertical launches because they were actually trying to fire themselves UPWARDS, instead of recoiling down...

Regards,

Northstar

[Rivvik]

OK, it took me a bit of tweaking and testing of my own to figure out what was going on with you, as I've definitely experienced downward recoil when firing straight up before... (at least I *THINK* it was downward recoil- it would slam the Mass Accelerators into the launchpad, and struts/clamps seemed to fix it...)

Turns out that what was going on is that the payload was getting a little bit caught on the loading rails (probably clipping slightly into them) and the Mass Accelerator was thus trying to accelerate the ENTIRE firing platform forward instead of just the payload to a degree.

I was just building ultra-lightweight horizontal launch platforms of my own- often the payload would get a tiny bit stuck on one of the loading rails (I used Firespitter helicopter landing pads as rails, for what it was worth), and the Mass Driver would thus pull the ENTIRE platform forward- never mind the fact that, physically, it shouldn't be able to accelerate itself... (its kind of like the Kerbals-on-ladders physics bug: it's a result of how KSP calculates physics rather than of the source of force itself...)

I don't know how to fix this, but I do know this- recoil is currently unlikely to be simulated correctly, as there seems to be a tendency of the Mass Driver to pull themselves along with the payload they are firing. The most reductive way I could imagine if finding if recoil is still currently being simulated correctly is if one were to build a spacecraft that approaches a single Mass Accelerator ring in-orbit (with some radial batteries and a command pod attached around the ring's rim), and the Mass Accelerator were to accelerate that spacecraft...

It's also possible that I wrong about recoil entirely, or that the mass accelerators were pulling themselves apart during vertical launches because they were actually trying to fire themselves UPWARDS, instead of recoiling down...

Regards,

Northstar

No its actually Kerbal Physics. I believe Kerbal bases the physics of the Mass Drivers' accelleration based on its difference to your vehicle's.

I.E. Kerbal does not move your active craft through space, instead, it moves space around your craft.

Therefore: Anything near enough your active projectile that is being measured against the projectile's speed in relativity will more than likely get torn asunder due only to the difference in acceleration. (In this case None vs "Plaid")

In the video I'm rendering, the tank fires the slug while remaining active, and remains intact. Upon firing with the slug as my active vessel, the tank is shred apart.

EDIT:

Edited January 30, 2015 by Rivvik
Mooveeee

[Northstar1989]

No its actually Kerbal Physics. I believe Kerbal bases the physics of the Mass Drivers' accelleration based on its difference to your vehicle's.

I.E. Kerbal does not move your active craft through space, instead, it moves space around your craft.

Therefore: Anything near enough your active projectile that is being measured against the projectile's speed in relativity will more than likely get torn asunder due only to the difference in acceleration. (In this case None vs "Plaid")

In the video I'm rendering, the tank fires the slug while remaining active, and remains intact. Upon firing with the slug as my active vessel, the tank is shred apart.

EDIT: http://youtu.be/RZa-_SqJIr0

So, recoil is only simulated when you control the slug rather than the accelerator thanks to how KSP physics work? Now I'm confused...

I guess that would explain why I always experienced recoil with my vertical launches, though- I always made sure to control the rocket at liftoff rather than the Mass Accelerator...

Regards,

Northstar

[Rivvik]

So, recoil is only simulated when you control the slug rather than the accelerator thanks to how KSP physics work? Now I'm confused...

I guess that would explain why I always experienced recoil with my vertical launches, though- I always made sure to control the rocket at liftoff rather than the Mass Accelerator...

Regards,

Northstar

Your "Recoil" is actually the destruction of your Mass Driver array due to it's "speed".

Kerbal sees the surrounding contructs of you active vessel as "in motion".

Basically its the theory of relativity used in the Kerbalest of ways. From the active vessel, Kerbal's engine sees that all other things are moving, while the Active vessel is not. The "Motion" experienced by the active vessel is simulated against the actual motion of the space around it.

Put a dog in a sealed car and start driving, and it thinks its in a room with the world moving around it, while observers on the street know darn well the car is moving inside the world. That dog is the Kerbal Engine.

[Tommygun]

It would be interesting if this could be made compatible with RoverDude's Asteroid Recycling Technologies mod.

As you mine the asteroid you can use the rock as reaction mass for the mass driver and propel the asteroid with it.

You would need a smaller mass driver though for that, maybe 2.5 meters.

[Northstar1989]

It would be interesting if this could be made compatible with RoverDude's Asteroid Recycling Technologies mod.

As you mine the asteroid you can use the rock as reaction mass for the mass driver and propel the asteroid with it.

You would need a smaller mass driver though for that, maybe 2.5 meters.

I might release a smaller Mass Driver (the current one has a 3 meter aperture) if this mod becomes popular enough. It should be a simple matter of using the re-scale factor in the config and adjusting mass/force accordingly. I'd need to do some research on how Mass Driver power levels scale with size... But you can ALREADY use the Rock resource as reaction mass (if I can get the recoil working correctly)- just fill a container with it and eject it in the opposite direction you want to travel. Of course, right now recoil ISN'T working properly all the time, so that doesn't really work so well... You might end up pushing your ship in the wrong direction.

Regards,

Northstar

[stellarator]

I cant' fire it! When y press "Arm acelerator", nothing happens, please help!

[Northstar1989]

I cant' fire it! When y press "Arm acelerator", nothing happens, please help!

You need to make sure the Mass Driver and payload are separate vessels. The Mass Accelerator won't work right if it tries to accelerate something that's part of the same vessel (it will do nothing or likely explode).

Take a look at this album (which I was planning on posting anyways for more examples for the players) to see a successful launch. Note that in the 2nd screenshot, you can clearly see from where the camera is centered that the Mass Driver and rocket are two separate vehicles.

I did this by placing a small separator-style decouple between the two (one of the ones that detaches at both ends) and then firing it off (you don't see it in the 2nd screenshot because it exploded upon falling off the rocket and onto the launchpad...) Although, I suppose you could also try and build a crawler with rover wheels (or tank treads from a mod) and roll your rocket over from the Runway to the Launchpad, a throw-away separator is probably the easiest way...

Javascript is disabled. View full album

Other things to note:

- The power-level is reduced to 49% on this Mass Accelerator stack. By (lots and lots of) trial-and-error I determined this to be the maximum safe power-level for this particular rocket and Mass Driver stack. The maximum safe power-level for any rocket and Mass Driver combo will vary based on the size and mass of the rocket, the length of the Mass Driver stack, the level of structural reinforcement (struts, launch clamps, KAS ground-pylons, etc.), and the aerodynamic design of your rocket (see below).

- It is important that your rocket is not only streamlined, but aerodynamically-stable. This means you need most of your mass up top, and most of your drag towards the bottom of your rocket (PRO TIP: landing legs and/or stabilizer fins at the base of your rocket help IMMENSELY for this). As drag is tied to mass in the stock aerodynamics model, making an aerodynamically-stable rocket is quite difficult in stock (no, there's nothing *I* can do about this: it's one of the shortcomings of the horrible current placeholder aero model... The same difficulty in maintaining aerodynamic stability can be observed with long/tall stock rockets with very high liftoff Thrust-Weight-Ratio...) however in FAR you can design aerodynamic-stability into your rocket simply by keeping the Center of Mass high (placing denser fuels such as hypergolics in the upper stages makes this MUCH easier if you are playing with RealFuels) and the Center of Drag low (even adding lander-legs so you can recover the launch stage will add drag to the bottom of the rocket in FAR, which is *precisely* where you want it...) If your rocket is NOT aerodynamically-stable, it will tend to flip over after exiting the Mass Driver, and will make some pretty fireworks when it crashes into the ground (or tears apart due to aerodynamic forces in FAR), but won't get you into space...

- Make sure your Mass Driver has enough electricity to operate- the acceleration isn't free! (Mass Drivers respect conservation of energy and all that...) Attaching lots of batteries to the Launch Clamps (or ground-pylons, etc.) holding the Mass Driver in place helps with this, as does simply attaching more Launch Clamps (each launch clamp produces electricity at a set rate) or solar panels, etc...

- Make sure your Mass Driver is well-supported. They *DO* experience recoil, although currently the recoil appears to be in the wrong direction (in the same direction the payload is firing- which is why some players have noticed the Mass Driver rings, batteries and all following their rocket into the air...) I am hoping to fix the recoil-direction bug in the future, but either way you will have to deal with recoil in one direction or another- so make sure you have plenty of launch clamps, pylons, or struts!

As always, I hope you guys enjoy playing with the Mass Driver mod, and let me know if you have any problems with it!

Regards,

Northstar

P.S. As always, my example screenshots are from a Career Mode install with Real Solar System 64K (which adds difficulty by up-scaling the planets and thus increasing Delta-V requirements to orbit, and is one of the reasons Mass Drivers are particularly pragmatic for my space program in the first place...), MechJeb2 (for the informational displays), FAR, Deadly-Re-Entry, Realfuels, Procedural Parts (which helps *immensely* with producing a nice streamlined shape for my rocket that is stable at high speeds), Procedural Fairings (also helps with streamlining), and NovaPunch2 (adds some useful engines- such as the one I used in the SSTO featured above...)

Edited February 4, 2015 by Northstar1989

[michaelhester07]

Nice to see one of my parts taking a spinoff of it's own. I've been lurking but havent played KSP for a while due to playin other game. I think i packaged the source code for the dll that you need for the mass driver. If I didn't i'll see if i can dig it up and post it.

[Gaalidas]

All this talk about physics and the world moving around your active ship rather than your active ship moving through the world reminds me of a thought I had when I was three years old. I was looking at the barrier in the middle of the freeway and thought to myself "is the car moving, or are we stationary and the world is moving around us?"

yeah, I was a strange child.

[michaelhester07]

The source code for the mass driver was included with the science mods in my mod. It compiles with Visual Studio 2013 express and links to the DLLs found in the KSP folder.

The DLLs linked against the 32 bit KSP so this doesn't work in 64 bit. The DLLs also linked against the .25 version of KSP but I didn't see any issues using it in .9 last friday.

@ Gaalidas:

The idea of the world moving and you standing still is one that I like because it allows faster than light travel to exist. My source for this thought

Let c be the speed of light.

Generally accelerating anything with mass to the speed of light requires infinite energy. I would assume to follow that it is possible to get to .51c or .6c with finite energy. How much that energy is we don't know as we don't have an engine capable of that yet. Let's say we did though.

Take 2 objects then and have them fly away from each other at .6c. If the frame of reference is one of those objects then the other object is going faster than light.

Here's an extension too. It should be possible to find out what velocity is 0 speed with reference to the universe itself if the speed of light cannot be broken. If there is a universal frame of reference for speed then it stands to reason in the scenario where we put 2 objects going away from each other at .6c that one object would require more energy to do so than the other. This effect should be detectable at smaller fractions of c. If there is no difference in the energy required for each object to get to .6c then there is no frame of reference and faster than light travel is actually possible with standard propulsion.

That's my thought experiment on that matter.

[Northstar1989]

Michaelhester07,

Do you have any insight into the recoil-problem? I was under the impression that the Mass Drivers simulated recoil (although I could be wrong), yet they DON'T seem to be working that way anymore. Making using orbital debris as reaction-mass, recycling momentum from returning capsules, and things like that ENTIRELY unfeasible (or unrealistic- since the Mass Drivers sometimes seem to get pulled in the SAME direction as their payload, rather than pushed the opposite way) as it currently stands...

Regards,

Northstar

[michaelhester07]

It's a simplistic approximation of recoil:

                           double f = powerLevel * acceleratorForce/100;
                            var spent = part.RequestResource(resourceName, dt * resourceAmount * f);
                            if (spent == 0)
                                f = 0;
                            double m = vLaunchTarget.RevealMass();
                            float a = (float)(f / m);
                            dt = Math.Min(dt, accelerationDuration); //for slow computers... don't apply more than the duration of acceleration
                            vLaunchTarget.ChangeWorldVelocity(accelerateVector * (a * (float)dt));
                            //for every action there is an equal and opposite reaction
                            m = this.vessel.RevealMass();
                            a = (float)(f / m);
                            vLaunchTarget.ChangeWorldVelocity(accelerateVector * (-a * (float)dt));

There's the code that calculates the force. It uses that equation force=mass*acceleration and solves for acceleration. Then for the duration of launch power it applies the acceleration to the payload in the "up direction" according to the accelerator, and on the launcher in the "down" direction according to the accelerator. If I recall "up" is the side with the black ring on it (i haven't used the accelerator in a while).

The recoil will be there, just if your launcher is significantly heavy it might not be visible. It's also possible that if your launcher is heavy enough and the framerate fast enough that the floating point error drops the launcher's acceleration.

[Northstar1989]

It's a simplistic approximation of recoil:

                           double f = powerLevel * acceleratorForce/100;
                            var spent = part.RequestResource(resourceName, dt * resourceAmount * f);
                            if (spent == 0)
                                f = 0;
                            double m = vLaunchTarget.RevealMass();
                            float a = (float)(f / m);
                            dt = Math.Min(dt, accelerationDuration); //for slow computers... don't apply more than the duration of acceleration
                            vLaunchTarget.ChangeWorldVelocity(accelerateVector * (a * (float)dt));
                            //for every action there is an equal and opposite reaction
                            m = this.vessel.RevealMass();
                            a = (float)(f / m);
                            vLaunchTarget.ChangeWorldVelocity(accelerateVector * (-a * (float)dt));

There's the code that calculates the force. It uses that equation force=mass*acceleration and solves for acceleration. Then for the duration of launch power it applies the acceleration to the payload in the "up direction" according to the accelerator, and on the launcher in the "down" direction according to the accelerator. If I recall "up" is the side with the black ring on it (i haven't used the accelerator in a while).

The recoil will be there, just if your launcher is significantly heavy it might not be visible. It's also possible that if your launcher is heavy enough and the framerate fast enough that the floating point error drops the launcher's acceleration.

That's essentially how I thought you coded it. So it seems recoil is not working as designed much of the time... (it's occurring in the wrong direction or not at all)

Regards,

Northstar

[stickman939]

I was very interested in using this mod, but it detexturized my VAB/SPH, the parts selection list, and hid the save/load/new/exit buttons at the top right.

I'm using these mods;

B9

FAR

Distant Object

Deadly Reentry

HullCam

Docking Alignment (NavyFish)

SCANSat

HyperEdit

ATM

and Tweak Scale

I have no idea what it is I'm doing wrong. :/

[Northstar1989]

I was very interested in using this mod, but it detexturized my VAB/SPH, the parts selection list, and hid the save/load/new/exit buttons at the top right.

This mod does NOTHING with the general textures, so I *HIGHLY* doubt it was responsible for your issue. Most likely, it was a problem with one of the other mods you're using (my first guess would be Active Texture Management- because, like the name implies, it handles TEXTURES...)

Have you tried the good old trick of removing all your mods and then adding them back in one by one (and re-loading the game each time) until you figure out what mod or combination of mods is the problem?

There is one other possibility- there *might* be some compatibility issues with Distant Objects mod. The original mod this part came from (Stanford Torus mod) included some code to increase the render distance of spacecraft so you could see your Stanford Torus from a distance. I thought I removed all of this code from this pre-release, but it's possible some of it slipped through. *IF* you can confirm that is the issue (by running nothing but Distant Object and this mod, separately and together), I'll try and hunt the issue down- which might require me to edit and re-compile the .DLL, which is *NOT* something I want to deal with trying to figure out how to do right now...

Regards,

Northstar

[dsonbill]

Mass Accelerator:

http://imgur.com/TXZCKO2,qO1G2ZN

Relay Vessel:

http://i.imgur.com/gz70zKa.jpg

Load Path:

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

Flight pics:

http://imgur.com/bFD2dJD,ZvzH4xk

I'm planning on cleaning up this post in a little while. If I don't, just know that it's pretty awesome.

[Northstar1989]

Mass Accelerator:

http://imgur.com/TXZCKO2,qO1G2ZN

Relay Vessel:

http://i.imgur.com/gz70zKa.jpg

Load Path:

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

Flight pics:

http://imgur.com/bFD2dJD,ZvzH4xk

I'm planning on cleaning up this post in a little while. If I don't, just know that it's pretty awesome.

You know how to post IMGUR images to the forums so they're visible without needing to click on the link, right? For an album, you use the tag for the album and "Imgur" between two brackets, with a / symbol before the second "Imgur". For an individual image, it's the link and "img" instead. So, replace the * symbols with brackets and..

*Imgur* tag */Imgur*

*img* link */img*

So, THIS is what you get for your links:

Also, NOTHING is visible in your last image- you're either zoomed too far out, or it's simply too dark...

Regards,

Northstar

Edited February 21, 2015 by Northstar1989

[CaribouGone]

Hey!

i like this mod so far, but i ran into many of the same issues people reported earlier: drivers exploding, ships vanishing, and lots of lag.

but i had an idea. it sounds like a lot of the problems stem from forces acting (and ending) faster than the physics engine can handle. so, rather than applying all the force at once, would it possible to spread the thrust over the course of several seconds? that way, you could gradually increase the acceleration during the first second, similar to throttling up a rocket. not only will it provide a smoother ride for Jeb, it will hopefully cut down on the lag upon firing the driver. also, it should guarantee that there is thrust being applied to the mass driver (if the lack of recoil was indeed from things happening too fast to be calculated).

having a known duration for the thrust will help with estimating our resultant velocity, as well.

speaking of estimation, tweaking the max thrust value to some easy number would be nice too. 11,760 is a weird number. an even ten or twelve thousand would make math a lot easier.

[Northstar1989]

Hey!

i like this mod so far, but i ran into many of the same issues people reported earlier: drivers exploding, ships vanishing, and lots of lag.

but i had an idea. it sounds like a lot of the problems stem from forces acting (and ending) faster than the physics engine can handle. so, rather than applying all the force at once, would it possible to spread the thrust over the course of several seconds? that way, you could gradually increase the acceleration during the first second, similar to throttling up a rocket. not only will it provide a smoother ride for Jeb, it will hopefully cut down on the lag upon firing the driver. also, it should guarantee that there is thrust being applied to the mass driver (if the lack of recoil was indeed from things happening too fast to be calculated).

having a known duration for the thrust will help with estimating our resultant velocity, as well.

The mass drivers accelerate at a certain force. There is no way to have a known duration for the acceleration, because a lighter craft will pass through the mass-driver faster than a heavier craft at the same power-setting...

speaking of estimation, tweaking the max thrust value to some easy number would be nice too. 11,760 is a weird number. an even ten or twelve thousand would make math a lot easier.

The maximum force is based on the real life StarTram gen-1 designs. It equates to a force of about 30 g's on a 40 ton craft at maximum power. The actual maximum force value would be 11,767.98 kN/s if I went for 100% realism, so I already rounded down a little for simplicity... (and because it's always best to round conservatively in case a real life figure is over-optimistic)

As a rule of thumb, for each g your craft is under it will accelerate at a bit less than 10 m/s each second. So, to figure out the approximate acceleration your craft will be under, divide the force on the craft by the mass of the craft and then again by 10 to get the approximate number of g's.

The only way to figure out the duration of the acceleration is to get out a ruler (I suggest using a ProceduralParts tank as one) and measure the exact height of your mass driver stack, and then punch some numbers based on the mass of the craft and the power-setting on the mass driver. I can't abandon real-life physics (or KSP physics, for that matter) of how a body acts under acceleration in order to get a consistent duration of acceleration- and tying the power level to the mass of the craft would prevent players from having any control over the final exit-velocity of the craft or rate of acceleration (unmanned craft can put up with a lot more g's than manned craft with Deadly ReEntry installed- which will kill crew if g-forces become excessive, for instance...) by tweaking the power-level.

Regards,

Northstar

Edited March 22, 2015 by Northstar1989

[CaribouGone]

that g rule of thumb is useful. i found acceleration through F=ma, but never thought to put it in terms of g.

out of curiosity, a kerbin g is also 9.81 m/s^2. right?

but the problem still remains: if i accelerate at 50m/s^2, for one second, my final velocity should be about 50m/s faster, right?

but if i accelerate at 50m/s^2 for some unknown fraction of a second, my final velocity is a number i can't calculate.

if i'm remembering physics class correctly (i'm sure i'm not), this whole issue is due to the fact that acceleration found through F=ma is instantaneous, which is mostly useless info unless it can be treated as constant and exist for period of time.

i was never suggesting power be tied to the ship's mass. the available acceleration should definitely depend the ratio of driver power to craft mass. it would be neat if the driver could magically know the target's mass, and tell us power in terms of g's, relative to the ship.

also, while it wouldn't allow for nearly as precise control, tying the power of all units together, so that only one menu would need to be tweaked would save a lot of time.

while i definitely respect trying to maintain realism and abide by the laws of physics, there's a fine balance between realism, and gameplay. i know what i'm suggesting is not at all how a coil-gun would work. but its well within the means of the ksp engine to apply force over time. that is basically what a rocket does, after all.

the idea behind my suggestion was that 1: a set unit of time would make estimating change in velocity from F=ma much easier. (in it were 1 sec, (F/m)=change in V)

and 2: if ksp wants things to behave like rockets, why not play along? while i know very little about computing, i got the feeling that the massive lag and kraken attacks were the result of instantaneous forces freaking the physics engine out.

to me, sacrificing a bit of realism to make the game behave properly is worth it. besides, the end result is the same: a big machine that accelerates things absurdly fast. i don't think many people are going to care if they were secretly under thrust a moment longer than they should have been.

now, don't get me wrong, this mod is really cool as is. the parts look good; its fun to use; and almost free dV is always welcome. but calculating final-velocity needs to be easier before this joins my always-install list.

[Northstar1989]

Caribou, the forces aren't instantaneous. The mass driver exerts force on the spacecraft as long as it is passing through the ring sections. The thing is that most of the ring sections are very short, so they don't exert force for a very long period of time...

There are calculations that can be run to predict exit velocity based on the mass of a craft and the force exerted on it (and the distance those forces are exerted over). The thing is that actually re-designing the interface to allow players to see the predicted exit velocity is something that's a bit over my head from a coding perspective...

I work with one modder (FreeThinker) who might have the expertise to do this. I'll try and ask him again if he might be interested in helping me refine this mod.

Let's be very clear though- the length of the mass driver, the force exerted over each distance-segment, and the mass of the craft are the only variables you control in the equation. The exit-velocity of the craft is dependent on these: you can't get a higher or lower exit velocity without changing one or more of them while still respecting physics.

Regards,

Northstar

[michaelhester07]

You may wish to make use of ModuleManager to disable use of the driver that's found in the stanford torus mod since this replaces it. Just a thought. Thanks for carrying this one.

[CaribouGone]

The mass driver exerts force on the spacecraft as long as it is passing through the ring sections.

Ah ha! that explains a lot, actually. i had assumed the forces were being handled in a much more simplistic way, no offense.

in fact, i feel a little dumb now.

with all else held equal, doesn't that mean a longer ship will receive more acceleration, as it would spend more time passing through the driver? i'm gonna have to make a 200m flying needle and test this.

There are calculations that can be run to predict exit velocity based on the mass of a craft and the force exerted on it (and the distance those forces are exerted over)

Uh oh, that smells like calculus. surely NASA has some equations laying around that could be borrowed. i'll poke around and see if i cant find something.

hmmm... that would be a lot of info to cram into a right-click menu as well. this might end up being a job for the people that make those tools and calculators.

do all the units need to be attached directly to one another? or do they just need to be part of the same ship? obviously, using the main center stack node would cause problems. but, with clever use of radial attachments, could i dock several short stacks together and have them function as one driver?

another issue i foresee (an in-game engineering issue, not an issue with your mod) is maintaining stability while traversing excessively long drivers. if what i asked above does work, the lazor systems mod could provide a solution. (have diametrically opposed repuslor/tractor lazers every few units to push the craft toward the center of the drive) if not, even a few set up at the "mouth" of the driver would probably work.

but, one day in the future, it would be neat if the driver could provide some sort of stabilization itself. maybe something could be borrowed from the docking-port "magnets"?

also, the mass driver doesn't accelerate EVA'd kerbals.

[hellion13]

Feel like a noob. Cant get this to work. Parts show up. I stack a few, arm button shows up but doesn't do anything. Decouple the craft and the arm button goes away. It does however make a good Stargate look alike....

Kinda want to see what a vertical one does to a Kerbal who jumps through......