[WIP][1.9-1.10][alpha] Cargo Accelerators

[allista 1,635]

Cargo Accelerators

Maxim 24: Any sufficiently advanced technology is indistinguishable from a big gun.

This mod aims to provide mass driver parts (gigantic coil and maybe even rail guns) and control aids that can propel engine-less unmanned cargo vessels with high acceleration to effectively perform precise orbital maneuvers with enough dV to go from, say, LKO to the Mun. And with careful planning even beyond.

With the help of mods like MechJeb and TCA it should be possible to organize a network of accelerators and decelerators (still not present) for moving cargo around the system cheaply and easily.

So far it provides a single part - Orbital Accelerator

It is a massive resizable coil accelerator with extendable barrel (up to ~1.5km) so heavy that I don't know any way of putting it to orbit aside from building it there or using the orbit editor (F12).

It has its own powerful reaction wheels and RCS thrusters that are capable to reorient it in space; and enough tanks capacity to store fuel for recoil compensation.

It also has dedicated UI that allows it to connect to the payload, read its maneuver node and either execute it by turning the right way and firing at precise moment with precise final delta-V; or tell you that it can't do it for various reasons.

The model still lacks textures and most colliders, as it is used to develop and test functionality rather than play. But it's enough to get a hand on things and toy with the concept.

Demonstrations

 

 

Future plans

• In-orbit construction of barrel extension segments by kerbal engineers from EC and Material Kits + Specialized Parts
• Proper model for Orbital Accelerator
• Orbital Decelerator -- a counterpart that should, in theory, catch the payload on the other end of the trajectory and decelerate it. Needs further investigation.
• Ground-based Accelerator -- an accelerator that can be positioned on the ground and launch engine-less cargo straight to orbit. Needs further investigation.

Download

• So far only from GitHub: https://github.com/allista/CargoAccelerators/releases/latest
• SpaceDock and CKAN will come when it's playable enough to be out from alpha

Edited July 23, 2020 by allista
Another video added

[Craze 13]

Nice idea! Here you need a balance for energy consumption from the reactor or storage devices.

[allista 1,635]

5 minutes ago, Craze said:

Nice idea! Here you need a balance for energy consumption from the reactor or storage devices.

Oh, balance is the pain. Energy requirement (calculated from the physical model of the gun) is so enormous that both production and storage may overturn the game twice. It was suggested to switch to another energy resource rather than EC so as not to allow a user to feed from the generators of the accelerator...

[Craze 13]

Or remove the generator from the module.

[allista 1,635]

44 minutes ago, Craze said:

Or remove the generator from the module.

Not a chance -- there's no generators in stock or other mods that are capable to fulfill the requirement. Reaction wheels alone use enormous amounts of EC.

[Craze 13]

If a person uses mods - Your mod, for example, then they will also find a mod for EC, Kerbal Atomic or Near Future

[Clamp-o-Tron 938]

You should use a "magnetic charge" resource, with a separate generator module that takes lots of time and EC to create it.

[Craze 13]

8 hours ago, Clamp-o-Tron said:

You should use a "magnetic charge" resource, with a separate generator module that takes lots of time and EC to create it.

No need increase the number of entities

[Clamp-o-Tron 938]

I mean, make time a resource to spend in addition to EC to use this

[Phoenix-D 13]

On 5/5/2020 at 1:12 PM, Craze said:

If a person uses mods - Your mod, for example, then they will also find a mod for EC, Kerbal Atomic or Near Future

Generally mods avoid being useless without other mods that aren't listed as dependencies.

Might be a good useful for a MM patch to allow it to use NearFuture or InterStellerExtended electric resources though.

EDIT:

On 5/5/2020 at 1:03 PM, allista said:

Not a chance -- there's no generators in stock or other mods that are capable to fulfill the requirement. Reaction wheels alone use enormous amounts of EC.

 

So the part cfg seems to generate only 500 EC/s if I'm reading the cfg right, with the launch using over a million. (can't figure out how to actually fire it?) Near Future Reactors produce 6k EC/s, so they could totally do it.

 

 

Edited May 8, 2020 by Phoenix-D

[allista 1,635]

17 hours ago, Phoenix-D said:

So the part cfg seems to generate only 500 EC/s if I'm reading the cfg right, with the launch using over a million. (can't figure out how to actually fire it?) Near Future Reactors produce 6k EC/s, so they could totally do it.

Yea, my bad; never used NFR or KSPIE; but does NF use EC, not some replacement? I remember the talk on the discord about how badly using big amounts of EC (both stored and generated) may upset the ingame balance. Hence the suggestion to use a proxy resource.

Anyway, dealing with so heavy and costly part, I'd rather use a built-in generator and storage that rely on a 3d-party. Just to lower the part count and reduce the number of soft dependencies.

[Phoenix-D 13]

2 hours ago, allista said:

Yea, my bad; never used NFR or KSPIE; but does NF use EC, not some replacement? I remember the talk on the discord about how badly using big amounts of EC (both stored and generated) may upset the ingame balance. Hence the suggestion to use a proxy resource.

Anyway, dealing with so heavy and costly part, I'd rather use a built-in generator and storage that rely on a 3d-party. Just to lower the part count and reduce the number of soft dependencies.

Oh, absolutely. Thing's huge enough as it is. NFC does use EC in the parts I've seen, yeah. KSPIE I bounced off pretty hard but I think has a custom resources for the big energy hogs.

[allista 1,635]

So far this is just how it will look like, not the full mechanics with resources and kerbals.

[Craze 13]

7 hours ago, allista said:

Yea, my bad; never used NFR or KSPIE; but does NF use EC, not some replacement? I remember the talk on the discord about how badly using big amounts of EC (both stored and generated) may upset the ingame balance. Hence the suggestion to use a proxy resource.

Anyway, dealing with so heavy and costly part, I'd rather use a built-in generator and storage that rely on a 3d-party. Just to lower the part count and reduce the number of soft dependencies.

NFC uses nuclear reactors with the release of the EC

[Phoenix-D 13]

On 5/8/2020 at 9:40 AM, allista said:

So far this is just how it will look like, not the full mechanics with resources and kerbals.

Nice!

 

...can you fire Kerbals with this? Please tell me you can fire Kerbals with this.

[allista 1,635]

4 hours ago, Phoenix-D said:

Nice!

 

...can you fire Kerbals with this? Please tell me you can fire Kerbals with this.

As a matter of fact, no; it is explicitly disabled in the OrbitalAccelerator.cfg, in configuration of the two magnetic dampers.

But you may try to enable it and see how things go  But the Kerbal has to be able to plot a maneuver first. Don't remember if they can do it.

The restriction may also be added with part tags, so that only special parts, say dedicated ferromagnetic cargo-shells, will be affected.

There's a video of how the same magnetic damper used in the forklifter part deals with a Kerbal 

 

[allista 1,635]

I'm hoping to release the new version in a few days that would support actual incremental barrel construction from resources and engineers 

[allista 1,635]

Yes, well, that proved to be harder than I anticipated. But it's almost done now. Just need to test it a bit.

[allista 1,635]

Tonight (20 UTC) I'm planning to stream the demo of the barrel construction, and tomorrow I'll be releasing it.

Join me in twitch and discord (for live audio conference).

https://m.twitch.tv/allitau/profile

 

[Ranchoth 35]

 

Well, if you want to do a ground-based variant, there's always the smaller, lower-tech approach of a Babylon Gun...

Or the LARGER, but possibly even LOWER tech approach of the Babcock & Wilcox Steam/Hydrogen Gun (Patent here).

100 gs of acceleration for two seconds, and dumping 28,000 TONS of water from condensed steam downrange. A respectably Kerbal design!

[theJesuit 1,217]

I'd like a ground based one to fire Ores back from the Mün to Kerbin, to aerobrake into orbit (or get caught by an orbital decelerator).

For Minmus it would need to wait until the body was at the right point of the rotational cycle.  Maybe it should be in the UI that when you fire it remembers the angle so you can rinse and repeat only at that time.

For Kerbin and maybe Duna the force might cause atmospheric heating so not that practical.

Peace.

Maybe the ground based one should be more like a turret cannon so you can aim in the directio  if it is too heavy to move.

[allista 1,635]

@Ranchoth, @theJesuit I do think about a ground based variant from the beginning; but that is a lot more difficult because of the Unity's physics model.

Orbital accelerator produces real co-axial forces that act on separate parts of the launched vessel. Which is fine in orbit. But on the ground there's gravity which has to be counteracted precisely.

Another problem is the trajectory; atmospheric launches are, of course, out of the question. But even in vacuum, launching from any planetary body would only allow you to either achieve a suborbital trajectory with high apoapsis, or an escape trajectory which is hard use for precise navigation.

In any case, I'll start to work on the concept as soon as the orbital accelerator would grew into beta testing.

[theJesuit 1,217]

@allista I was definitely thinking of suborbital, or escape trajectory.

However, capturing decelerators (which are accelerators) in orbit would possible resolve the suborbital issues - but this would be REALLY difficult to line up accurately this may not be a goer.

Actually - would ground base decelerators be something to consider too?  Imagine having different mining facilities such as at the poles, far side crater etc, mine your resource, throw it over to your equatorial base where it is caught - then transferred to the more powerful 'return to Kerbin' cannon, where it is launched, aerobrakes and the apoapsis that it ends up with is timed to coincide with an orbital decelerator, or more probably, a capture craft that the player uses to rendezvous with the projectile like an asteroid.

Empty canisters could then be fired back to the mining stations to be refueled as well.

Coming back down from orbit (not on an atmospheric body) would need quite precise calculations.  Again, not sure. now this would work.

But the suborbital shots could be on craft that have suicide burners, so capturing isn't needed.  Just accurate ballistic launches.

[allista 1,635]

Yesterday's video

 

 

Edited June 14, 2020 by allista

[allista 1,635]

4 minutes ago, theJesuit said:

@allista I was definitely thinking of suborbital, or escape trajectory.

However, capturing decelerators (which are accelerators) in orbit would possible resolve the suborbital issues - but this would be REALLY difficult to line up accurately this may not be a goer.

Actually - would ground base decelerators be something to consider too?  Imagine having different mining facilities such as at the poles, far side crater etc, mine your resource, throw it over to your equatorial base where it is caught - then transferred to the more powerful 'return to Kerbin' cannon, where it is launched, aerobrakes and the apoapsis that it ends up with is timed to coincide with an orbital decelerator, or more probably, a capture craft that the player uses to rendezvous with the projectile like an asteroid.

Empty canisters could then be fired back to the mining stations to be refueled as well.

Coming back down from orbit (not on an atmospheric body) would need quite precise calculations.  Again, not sure. now this would work.

But the suborbital shots could be on craft that have suicide burners, so capturing isn't needed.  Just accurate ballistic launches.

Suborbital shots between ground bases are more practical with the use of powered payload -- with boosters for deceleration and landing. You shoot, it flies, then lands using cheap single-use thrusters (maybe even SRBs).

As for the decelerators -- that was my initial thinking, until I perfected orbital launches to less than 0.01 m/s errors in maneuver node execution. It is impossible to execute a node any more precisely; but that's still isn't enough -- the resulting orbit is always at least a few hundred meters away from the target (if you compare, for example, the resulting ApA with the pre-calculated one). What's more, from launch to launch this error appears to be random, meaning that it is caused by some rounding/floating-point errors.

In a nutshell -- a decelerator should either have to be about 1-2km wide (and in that case I don't know any physical principle it could use to capture the payload, aside from a thin-enough mesh); or the payload have to have its own thrusters for several orbit corrections to hit the bull's eye. And even with such corrections, to fly into a 12m whole on a 4m wide ship at, say 300-500 m/s would be a feat of precision and luck...