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

[CaribouGone]

hellion, once you decouple the craft from the driver, switch back to the driver with [ or ]

when you decouple, control is probably going to the "projectile"

also, make sure you have a command part on the mass driver, or it will be unusable.

as i said in the post right before your's, the driver doesn't seem to do anything to kerbals.

Northstar1989, i may have figured out the acceleration problem i've been rambling about.

rather than deal with acceleration and time, velocity can be found through kinetic energy.

this site describes force (on the projectile) as a function of distance from the magnet. the integral of that function is in units of Newton-meters (equivalent to joules).

once that number is found, just plug into and solve for v (this will be velocity gained, in case you're already moving).

the integral in our case should be easy, because the force-penetration curve will be a horizontal line. the distance over which we integrate will be the length of the ship, plus the width of the stack (and any gap between the ship and driver; i'll try to keep that to a minimum once i get motivated to test this theory).

i figured this out assuming only one mass driver unit. if all stacks are at the same power level, i think you should be able to just add the energy gained from each unit together (or increase the range of the integration).

again, i haven't tested this yet. i've been distracted by games that don't require knowledge of physics and math. but according to that site, these calculations work in real life. i'll post some pictures and numbers soon enough.

[3MMM]

Have you ever thought of adding a new set of parts witch are bigger, so it may be possible to launch 3.75 m parts?

Or maybe add a cfg/plugin so this is TweakScale compatible?

EDIT: Actually you just need to change the cfg file... if you rescale it to 3 you have a ~5m radius(I think..)

P.S. Could you add a *decoupler*, a sort of 'ring' to cover up that hole in the middle so if we liked to put a launcher underneath it to take it to orbit( if we are so mad to try this) it would seem more "realistic" .

Something like this maybe:

Edited April 21, 2015 by 3MMM
added image

[cipherpunks]

Now I do realize that I'm pervert, but...

This mod would make good fireworks with RSS/FAR/DRC/PF, if not massive lag.

Someone tried it with those mods? Any known caveats?

Yes I do use procedural fairing encasing my ship (using interstage ring and an empty tank from PP on top of that), but a) parts are torn from mass driver itself due to aerodynamic stresses; ship is being deconstructed due to same reason; and c) ground support ends up suspended stationary at height like 1km I don't know why, and some sections of it are sometimes missing. Launchpad itself gets destroyed at times too.

Edited April 26, 2015 by cipherpunks
clarify

[Svm420]

How does the network ring work?

[dunebugmi]

Hi I'm new to the forum. Thank you for your work on the Mass Driver Mod. I have played around with the mass driver quite a bit and wanted to publish some findings. First, If you have trouble getting your mass driver's payload into the correct position, vector, and state of individuality/un-attachedness at the same time, there is another mod I found essential called Hangar, by allista. The hangar mod stores parts or complete rockets virtually until you want desire their release. The hangar objects are similar to the cargo bay on a C-17. Anyway I found that if you strap a hangar onto a mass driver, the hangar will create the payload un-attached and on demand. Even better, the payload is bound in all but one direction by the hangar walls. This came in handy when I was trying to fire a payload perpendicular to gravity or in an air resistance or otherwise accelerating environment-- when using decouplers for this my payload would fall away faster than I could arm and fire the mass driver.

The specific hangars useful for this were the spaceport and the spaceplane hangar. Maybe I should mention this to the NorthStar guy as well.

There is another mod that functions similarly called extraplanetary launchpads, by skykooler & taniwha. Instead of storing premade vessels, EL allows you to build new vessels by drilling for ore. In similar fashion to the hangar mod, once your vessel is built, EL creates a new, unnattached and individual ship upon its launchpad. This was a great way to build and launch new vessels offworld, espescially in vacuum or low atmosphere environments.

Finally, I wanted to mention that I have been altering Squad's aerodynamic fairings that came with ksp1.0. I find that if I change the melting temperature to that of Silicon Carbide I can use the fairing to protect all of the parts inside it suitable for being mass driven in atmosphere. I also needed to offset the center of mass in order to keep the fairing-stored vessel from flipping-- at mass driver speeds flipping creates torques and angular momentum that destroy everything. I am still experimenting, trying to get closer and closer to something more realistic, but in the meantime I'll post the code I have changed. Does anybody on here already have a solution like this?

maximum_drag = 0.02

minimum_drag = 0.02

angularDrag = 0.2

maxTemp = 5200

CoMOffset = 0, -10.0, 0.0

[Northstar1989]

Just catching up on the posts a bit now- sorry if I was a little harsh on you guys the last few times I posted...

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.

Yes- in theory, at least, a 200 meter flying needle should spend more time passing through the Mass Driver and thus receive more acceleration than a comparable, shorter craft of the same mass. No guarantees the ship will survive the structural stresses of being 200 meters long and accelerated at over a dozen g's, though. Your rocket is likely to pull apart at the joints between inline parts this way if it's not of uniform density...

Uh oh, that smells like calculus.

It *is* calculus- which is part of why I've thus far avoided including any tools to actually predict exit velocity. It's not only calculus- it's calculus with a hefty dose of coding and the need to reference craft files to find things like the length of the craft...

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.

Indeed. I *love* calculation-aids for KSP, but creating informational tools and calculators with advanced math and coding underlying them isn't exactly my specialty...

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?

If you're referring to the ability to mass drivers to network together to fire sequentially as a craft passes through them, they all need to be directly attached inline to each other. However, using something like kOS it might be possible to dock several independent "stacks" of Mass Drivers together with clever use of radial attachments and have the Mass Drivers fire off at precisely the correct time to catch the craft as it passes through. Each "stack" would independently try and place the vessel on rails, though- so it might cause issues if the tail end is being placed on rails by one stack and the nose by another stack at the exact same time...

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.

Never messed with the LAZOR system, but yeah, that might work... Let us all know if you come up with anything awesome...

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"?

Well, considering the docking-port magnets don't even work that well (in 0.90, they didn't even work at all- which is creating some SERIOUS annoyances for my 0.90 RSS 64K Constellation-style Duna Mission I'm carrying out and uploading to YouTube before even thinking about to updating to 1.0- especially as RSS 64K has become basically a must-have mod for me...)

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

I should've known somebody would try this out sooner or later.

It's realistic, though- they're made of flesh and bone, not metals that electromagnets can act on.

Regards,

Northstar

- - - Updated - - -

hellion, once you decouple the craft from the driver, switch back to the driver with [ or ]

when you decouple, control is probably going to the "projectile"

also, make sure you have a command part on the mass driver, or it will be unusable.

as i said in the post right before your's, the driver doesn't seem to do anything to kerbals.

Northstar1989, i may have figured out the acceleration problem i've been rambling about.

rather than deal with acceleration and time, velocity can be found through kinetic energy.

this site describes force (on the projectile) as a function of distance from the magnet. the integral of that function is in units of Newton-meters (equivalent to joules).

once that number is found, just plug into http://latex.codecogs.com/gif.latex?%5Cfrac%7B1%7D%7B2%7Dmv%5E%7B2%7D and solve for v (this will be velocity gained, in case you're already moving).

the integral in our case should be easy, because the force-penetration curve will be a horizontal line. the distance over which we integrate will be the length of the ship, plus the width of the stack (and any gap between the ship and driver; i'll try to keep that to a minimum once i get motivated to test this theory).

i figured this out assuming only one mass driver unit. if all stacks are at the same power level, i think you should be able to just add the energy gained from each unit together (or increase the range of the integration).

again, i haven't tested this yet. i've been distracted by games that don't require knowledge of physics and math. but according to that site, these calculations work in real life. i'll post some pictures and numbers soon enough.

The problem with that is, heavier vessels pass through the mass driver more slowly- and thus gain more kinetic energy. There's also the issue to gravity to be worried about... The short of it is, doubling the power-levels doesn't double the kinetic energy (and vise-versa) and the kinetic energy gained has interactions with payload mass and driver-orientation (a vessel leaving a horizontal stack will leave the mass driver traveling much faster than one leaving a vertical stack as it doesn't have to fight gravity- which is something to consider when trying to launch a vessel using Mass Drivers from the surface of the Mun... Which would probably require Extraplanetary Launchpads and building the Mass Drivers on site- as it would take an insane rocket to lift a 50-meter long stack of Mass Drivers to the Mun in one piece...)

Regards,

Northstar

- - - Updated - - -

Finally, I wanted to mention that I have been altering Squad's aerodynamic fairings that came with ksp1.0. I find that if I change the melting temperature to that of Silicon Carbide I can use the fairing to protect all of the parts inside it suitable for being mass driven in atmosphere.

You changed the heat tolerance to that of Silicon Carbide (one of the most heat-resistant materials known to man). Now THAT is amusing, and VERY "Kerbal." Learns fast, this padawan does.

I also needed to offset the center of mass in order to keep the fairing-stored vessel from flipping-- at mass driver speeds flipping creates torques and angular momentum that destroy everything. I am still experimenting, trying to get closer and closer to something more realistic, but in the meantime I'll post the code I have changed. Does anybody on here already have a solution like this?

maximum_drag = 0.02

minimum_drag = 0.02

angularDrag = 0.2

maxTemp = 5200

CoMOffset = 0, -10.0, 0.0

I'd have to check which axis you offset the mass along, but it sounds like your *real* issues is that you need the Center of Mass forward of the Center of Drag/Lift to prevent the fairing-enclosed payload from spinning out in the atmosphere. That will give it aerodynamic properties more like an arrow or dart- as opposed to, say, a baton...

There is an easier (and less cheaty) solution than offsetting the Center of Mass for the fairings (which makes little sense realistically). Install Procedural Parts and RealFuels mods, and place a small Procedural Parts fuel-tank *just behind* the nose of the fairing filled with LeadBallast (a resource from RealFuels specifically-intended for use to change the Center of Mass of vessels to improve their aerodynamic stability...) Add enough ballast up there and your faring should fly straight and true through the atmosphere no matter how fast you expel it from your Mass Driver.

You can get away with using less ballast if you take special effort to place the heavier parts of the payload more towards the nose of the fairing (even if this mean, for example, placing the payload inside the fairing backwards). Since the fairing completely covers up all the parts inside it from generating drag or lift, all you need to worry about is getting your Center of Mass as close to the nose of the fairing (and as far in front of it's Center of Lift/Drag) as possible...

All this is predicated on using a realistic aero model like FAR or nuFAR, of course. I couldn't tell you what the 1.0 aero model would do as I haven't even tried it out yet (I'm still using 0.90, which is why I haven't even officially updated this mod to 1.0- as I've had no firsthand experience bug-testing it before declaring it ready for a 1.0 release...)

Regards,

Northstar

Edited May 23, 2015 by Northstar1989

[AaronLS]

Northstar, I think these lines for both parts are missing a negative. I always have to invert the networked parts as I stack them. I looked at the same settings on fuel tanks, and they match this pattern instead. No clue other than just looking at the pattern stackable fuel tanks follow. I edited mine locally and can stack them without inverting now.

Instead of:

node_stack_bottom = 0.0, -1, 0.0, 0.0, 1.0, 0.0, 3

This:

node_stack_bottom = 0.0, -1, 0.0, 0.0, -1.0, 0.0, 3

It'd be neat if there was some way to mount a docking port such that you could dock in the loading position of a rail gun in space, and have the firing automatically decouple the port just a moment before firing. Maybe something shaped kind of like 3MMM's model, so you RCS down the "barrel" of the mass driver to dock with the loading position docking port.

It's hard to RCS into the loading position and remain stable long enough to switch to the driver and fire it.

Anyhow, as it is it's really cool mod. I want to put one in orbit with a solar sail mod so that I can restore its orbit after each firing.

Edited May 29, 2015 by AaronLS

[Northstar1989]

Anyhow, as it is it's really cool mod. I want to put one in orbit with a solar sail mod so that I can restore its orbit after each firing.

Will look into the rest sooner or later...

KSP-Interstellar Extended (one of the other mods I work on) has working solar sails. Of course, it also has working Propulsive Fluid Accumulators and plasma thrusters, which might be an easier way to restore the position of your mass driver between firings...

Regards,

Northstar

[AaronLS]

I added a docking port to the master part like so. I have to leave early tomorrow morning for a week long business trip, but when I get back I'll look at adding that to the firing process. Then I'll try and figure out if it's possible to add a GUI slider that can control how far the port is offset. Not sure where to begin with that or if it's possible. I'll probably hunt through other plugins to try and find one the does "design time" part manipulation as an example.

Long term a proper implementation would probably be either an alternative master part, one with/without docking port, OR another slave like part to act as the loading chamber. It'd be nice if it could be left up to the player to place a regular docking port anywhere they wanted, and somehow flag it as the "pre-firing decloupler" but I don't know that there is anyway in the GUI to support this. If I can't solve the "slider" problem, then maybe a brand new docking port part with a different name, and just understand that when the mass driver fires, then our code will find ALL of your loading chamber ports and decouple all of them. This would solve the positioning problem and give the player alot of flexibility in where they put these special ports, or if they want multiple ports.

More ambitiously, I was thinking about how to emulate a magnetic "capturer" such that instead of having a docking port offset way back, have another electromagnetic ring. It would implement docking port behavior, with a larger acquireRange setting, but would visually look like a another electromagnet ring, so the docking port capture node is in the space inside it, and appear that the craft is magnetically held inside this loading chamber/capturer ring. The craft would still need a docking port to be "captured" but our port, maybe a small "Ferrite Tracking Ring" could be a new part on craft that implements the craft side of the docking port so that it could be placed mid-craft. Either that, or not use docking ports at all and just implement capturing physics so that "anything" could be held in the capture ring, but that seems more ambitious.

// *** BEGIN: Docking Port ***
// add a docking port, the actual attach node is offset 0.2828832 to account for the size of the docking port
node_stack_chamber = 0, -6.7171168, 0, 0, 1, 0, 1
MODEL
{
    model = Squad/Parts/Utility/dockingPort/model
    position = 0, -7, 0
}    
MODULE
{
     name = ModuleDockingNode
     referenceAttachNode = chamber
     nodeType = size1    
}
// *** END: Docking Port ***

Edited May 31, 2015 by AaronLS

[Svm420]

Hope this mod doesn't fade away. Really want to see an update for 1.04. Thanks!

[AaronLS]

Hope this mod doesn't fade away. Really want to see an update for 1.04. Thanks!

I am making solid progress on adding some of the features I mentioned before. I rewrote all the code to apply some of the physics in a different way. By default mine isn't going to be as powerful, however I will have a field in the part config that you can multiply the power if you want to jack it way up. I just think it's a way overpowered to provide such as huge boost during launch for essentially zero cost, and I don't think even the world's most powerful magnets come close to being that powerful. Even conceptual designs of electromagnetic assisted launchers come in the form of very long tracks that slowly accelerate the payload (which would be a neat idea for a facility mod).

But it can definitely be fun to play with such a powerful launcher, so I want to make sure you have that option to jack the power way up if you really want to.

Once I have something workable I'll post source on github and a release. Probably within 2 weeks.

If people try mine and feel they much preferred the old one, I can probably make compiling the old one an easy step and provide that as another release option.

[Svm420]

Any news on this mod please don't say its dead

[AaronLS]

Hey Svm, thanks for the encouragement. Hopefully this will live up to your expectations. It's pretty rough around the edges as I've been involved in other things and haven't had time to work on this. I've made a short video on its operation since its quite different. Pretty much rewrote all of the code.

I created a ring that acts as a magnetic docking port. It will pull a nearby vessel, and when the vessel intersects it will become "docked". It's a little bit unrealistic in the way it operates currently. The previous version was a little bit risky as you'd get your vessel in position but it'd just be floating there and you'd quickly have to fire the magnets before it floated out of alignment. This solves that problem by allowing you to lock your vessel in place, and the Magnetic Ring Controller allows you to automate the process of decoupling and firing the magnets.

If I can find time to add some polish to this and get it up to production quality, I'll probably start a new thread for it since I can't edit the root of this one.

The main thing I'm not happy about is the docking ring will not apply torque to align the vessel. Some of the math regarding rotation is new to me and haven't had time to get up to speed. Looks like things have evolved beyond just being simple matrix math since I haven't done 3D in several years. I also want to making the docking ring more intelligent, and have it auto-reduce power as the vessel gets closer, to nullify the violent oscillations and hard docking.

Video:

Download from GitHub: https://github.com/AaronLS/KerbalMagnetMod/releases/tag/v00.01-alpha

[Kerbas_ad_astra]

Thanks for bringing this back, Aaron! I set up a quick test (hyperedit an eight-ring driver and a five-ton drone (i.e. a 3-ton small ore tank, an RCS tank and thrusters, some control and docking hardware) into orbit, launch the drone, see what the relative speed is immediately after launch) and it looks like my driver can impart about 700 kNs of impulse to its payload (5.3 tons * 132 m/s) -- enough to push the little guy most of the way into Minmus orbit, all the way into Gilly orbit, or part of the way into Ike orbit (or different masses of stuff into orbit around each). When I get my USI bases stood up, I can envision using this to launch small shipments of spare parts and occasional top-offs of life support supplies from moon mines to an orbiting or planetside habitat. It may also be handy for amusement park rides. (Someone tell Danny2462 about it!)

Edited September 11, 2015 by Kerbas_ad_astra

[Aelixander]

Hey there!

First off, this is a really awesome mod you got here.

If I may make a suggestion: instead of having 3 parts, why not 2? You could put all the function of the small control module, into the control ring. I would think that would really make things easier for everybody involved.

Incidentally, I really like the look of this mod.

In the video, you said to be careful of ships and things nearby. If this was mounted on my station in Kerbin orbit, would these rings tear it apart?

Thanks!

- A

[Kerbas_ad_astra]

Hey there!

First off, this is a really awesome mod you got here.

If I may make a suggestion: instead of having 3 parts, why not 2? You could put all the function of the small control module, into the control ring. I would think that would really make things easier for everybody involved.

Incidentally, I really like the look of this mod.

In the video, you said to be careful of ships and things nearby. If this was mounted on my station in Kerbin orbit, would these rings tear it apart?

Thanks!

- A

No, the station itself will be fine, but if you have ships besides your "target" within physics range, they'll also get acted on by the magnetic forces. (This gives me some ideas for a BD Armory hazard...)

[AaronLS]

What Kerbas said. Won't tear apart your vessel, but nearby debri/vessels will be accelerated towards the magnets and thus risk of collisions.

My thinking with the control module was not to clutter up the magnets with additional UI. It also makes it clear which controls are global and will affect all magnets. Otherwise each magnet would have both a "This Magnet: On/Off", "All Magnets: On/Off".

The Safety/Auto-undock+fire controls are already a little non-intuitive to use, almost making the instructional video a required viewing to use, and having mixed options on every magnet seems like it'd add confusion. I wanted them to be on their own part so at least it's clear that all of those controls relate to controlling the entire vessel's magnets.

Opinions?

[Kerbas_ad_astra]

What Kerbas said. Won't tear apart your vessel, but nearby debri/vessels will be accelerated towards the magnets and thus risk of collisions.

My thinking with the control module was not to clutter up the magnets with additional UI. It also makes it clear which controls are global and will affect all magnets. Otherwise each magnet would have both a "This Magnet: On/Off", "All Magnets: On/Off".

The Safety/Auto-undock+fire controls are already a little non-intuitive to use, almost making the instructional video a required viewing to use, and having mixed options on every magnet seems like it'd add confusion. I wanted them to be on their own part so at least it's clear that all of those controls relate to controlling the entire vessel's magnets.

Opinions?

The magnets themselves can remain as-is, but I think that it does make sense to add the overall control to the magnetic chamber, since that's the centerpiece of the driver anyway (maybe, in the absence of someone with model experience to make it look different, it can be dressed up with some MODEL{} nodes to add some stock-part greebles). I might try playing with the config to see if adding the control module to the chamber looks alright, and also think of ways to simplify the control process.

[Aelixander]

T (maybe, in the absence of someone with model experience to make it look different, it can be dressed up with some MODEL{} nodes to add some stock-part greebles).

A simple color-change to the skin of that model would do the trick. from red to blue, or green, or make the white parts metallic or something to make them stand out a little more. Perhaps your flag on the controller?

Personally, a simple light would to the trick for me.

Green light - I am ready to go.

Blinking green light - I am charging up to accelerate.

Red Light: FIRE!

Etc.

[Aelixander]

Okay, so I finally had a chance to download this mod.

I downloaded the Netherdyne_Mass_Driver_Mod-0.1.1 from page 1

and AaronLS's KerbalMagnetMod-master

...and I can't get things to attach in a stack. Just radially....

Uhm, am I missing a thing?

[Kerbas_ad_astra]

Okay, so I finally had a chance to download this mod.

I downloaded the Netherdyne_Mass_Driver_Mod-0.1.1 from page 1

and AaronLS's KerbalMagnetMod-master

...and I can't get things to attach in a stack. Just radially....

Uhm, am I missing a thing?

You just want the "CertifiedSilly.7z" folder from the GitHub link in Aaron's post. You should find a "CertifiedSilly" folder inside, which is what goes in your GameData folder.

[Aelixander]

You just want the "CertifiedSilly.7z" folder from the GitHub link in Aaron's post. You should find a "CertifiedSilly" folder inside, which is what goes in your GameData folder.

Thank you. =D

[Northstar1989]

First of all, sorry to be AWOL for a while guys. Real life has really been getting in the way of Kerballing, as has a certain frustration on my part than 1.0x just isn't stable on my computer like 0.90 was. I'm hoping 1.1 will be better- because the frequent CTD's in 1.0x (even completely unmodded) have driven me bonkers and to other games in my free time!

I've also been working on a video project to carry out a Constellation-style mission to Duna in Real Solar System 6.4x in what limited Kerbal time I have been spending, as well as trying to get back into the swing of KSP-Interstellar Extended (another mod I helped get off the ground and develop) modding...

OK, down to business a little. I will have to take a look at the actual files Aaron released, but immediately, I noticed this:

By default mine isn't going to be as powerful, however I will have a field in the part config that you can multiply the power if you want to jack it way up. I just think it's a way overpowered to provide such as huge boost during launch for essentially zero cost, and I don't think even the world's most powerful magnets come close to being that powerful. Even conceptual designs of electromagnetic assisted launchers come in the form of very long tracks that slowly accelerate the payload (which would be a neat idea for a facility mod).

Actually, Aaron, the force the Mass Driver produces (which leads to varied acceleration based on the mass of the cargo launched) is based on real-world figures. The Mass Driver is a replica of the performance expected for the StarTram project (the generation-1 design, to be precise: which still had some room left for improvement in future generations of the design...) Which could produce, to be precise, 30 Earth-gravity's (g, or 9.81 m/s²) of acceleration on a 40-ton cargo. It was simply a matter of calculating and back-calculating the numbers from there to get the maximum force the part can produce.

So, the part is not overpowered. At least not compared to the real world. The problem is REALITY can seem a bit overpowered in a Kerbal-sized universe. For what it's worth, though, even at this level of performance tracks of mass-drivers many kilometers long were planned. I haven't been able to construct a stack more than 500 meters long that remained stable upon launch on Kerbin (although I suspect a larger stack might be usable in orbit, if I were to somehow get one there- which would probably require either HyperEdit or Extraplanetary Launchpads, as there is no way I'll be launching something that tall AND massive anytime soon...)

Keep in mind also that the reason every real-world design includes very long track lengths (often 10-12 km or longer) is both to reduce the acceleration rate to something humans can more easily handle (when designing the system to only accelerate a tiny capsule, rather than a giant 40-ton rocket carrying lots of cargo...) and to not only escape the atmosphere, but do so as horizontal speeds closely approaching orbital velocity- so only a tiny push is necessary to reach orbit.

It's been known as far back as Aristotle and Archimedes that the faster you travel through a think medium like air or water, the more drag you encounter- and that this requires an exponentially faster entry speed to exit that medium with a slightly faster exit speed, or travel through a slightly thicker medium. Real world mass driver designs are meant to launch on a shallow trajectory (which GREATLY increases path-length through the atmosphere), after a long low-g acceleration (not to exceed 3 g's for a manned capsule, typically) and still be traveling horizontally at close to orbital velocity at apoapsis: which all mean that a MUCH longer mass driver track is necessary than what is needed, say, to simply launch straight up at high enough speeds to catapult a cargo at high G's onto a suborbital trajectory that narrowly escapes the atmosphere and is moving very slowly at apoapsis...

Anyways, I appreciate your efforts to keep this mod alive Aaron. I hope you will carefully think about what I posted. If you'd be willing, I'd love to officially bring you on as a co-developer of this mod- however I really strongly do wish to keep the "standard" version of this mod as closely based on real-world performance as possible. So, it will kind of be a requirement that you be willing to develop a version that is based on real-world designs for which hard numbers can be found for the expected performance (at least, how many g's you could accelerate such-and-such a mass rocket at), such as StarTram...

Regards,

Northstar

- - - Updated - - -

Aaron, I will send you a PM- but to be clear, I would very much like to bring you in on this project. I am thinking of starting a version 0.2.x thread for a re-designed version incorporating some of your changes. It would be nice to have somebody with more proficiency in code and code-writing working on this project (for the most part, I just ripped some existing code from the little-known Stanford Torus mod: with the author's permission, of course- and then then tweaked the config to match real-world data for the force produced, and for practicality increased things like the collision tolerances to reduce the chances of spontaneous explosions with long Mass Driver stacks...)

Also, keep in mind the CDDL-1 license does require us to attribute previous contributors to the project- thus, even if you go off and start a new thread without me, you would need to attribute both the creator of the Stanford Torus mod and myself (if you worked off my version) for the project. You could work off the original ST version to shorten the attribution list if you wanted, of course. Regardless, I would prefer to work WITH you rather than compete with you anyways. Your work would likely displace mine, as you are better at coding- but I could still do a lot to spread word about the mod, helping to bring in more users, as well as doing more real-world performance research (at which I am very good- being a real life scientist) and such, if we worked together.

Regards,

Northstar

Edited September 17, 2015 by Northstar1989

[Northstar1989]

AaronLS,

Still haven't heard back from you one way or the other. Did you get my private message?

Regards,

Northstar

[Aelixander]

Northstar, if you do make a new thread, let me know =D

And if I can help, let me know. I am learning blender, and I know Photoshop well. I have a head for programming, but no piratical experience.