Jump to content

[1.12.x] Alcubierre Warp Drive (Stand-alone)


RoverDude

Recommended Posts

I'm still working on the angular momentum / orbital energy conservation version of the drive with Serino (it has a toggle so you can change it to the classic velocity conservation drive in the VAB).

We're seeing some weirdness and are trying to decide how to proceed or if the weirdness is something one has to deal with messing with warp (has to do with not returning to start states and oddities on SOI switches).

I could build and throw up a Dropbox link to an alternate build that includes our best working version of the different physics if folks want to give us some feedback.

Link to comment
Share on other sites

Is possible make the drive work only outside planets sol ?

When you have understand orbit mechanics is easy place a ship in stable orbit, and is easy too use the drive for do transfers planet to planet in the same sol without waste Dv.

Yes... but not going to.

The angular momentum conservation version of the drive you can't do a lot of the tricky stuff that you can do with the velocity conversion version of the drive. You really probably "could" in reality but that gets into n-body physics and I have no way of making that sort of thing happen that I can tell as all I can do is work with the numbers produced by ballistic trajectories.

For example: If you warp from Kerbin to another planet on the other side of Kerbol. You'll be heading in the wrong direction (a lot like the velocity conservation version of the drive), but with far less energy as you only have Kerbin's orbital momentum and a small fraction from your orbital momentum around Kerbin. You can still use Kerbol to change your velocity vector direction which would help a lot but... you can't simply change your orbital momentum the same way you can your velocity. You'll need to use your thrusters. When you keep warping back at the planet you'll see your velocity returns to exactly where it was. You can use the gravity of the planet to change the direction of your velocity vector, but all the while your angular momentum remains the same.

Basically the trick of warp from Kerbin out to Jool, keep warping at Jool until you bleed off the excess velocity... that doesn't work with this take on warp drive. Departure windows still make your life a lot easier (though they are different than normal, you want the planets aligned on the same side of the star).

Short version of what to expect is, if you did a regular hohmann transfer, you need to "pay for" all the deltaV needed at your destination if you warp straight there. That's not 100% true you can do things more efficiently than a hohmann transfer, but usually not. What you get with the orbital momentum conservation version is not needing to wait months to get to your destination. I think it's a really neat effect and interesting to use the other take on how a warp drive might behave. Personally I like it better than the velocity conservation version as the numbers don't seem to get as silly.

Link to comment
Share on other sites

WarpDrive Test.zip here : https://www.dropbox.com/s/k0q5tg08dzwck5y/WarpDrive%20-%20Test.zip?dl=0

Here is the source to the new DLL : https://www.dropbox.com/s/fcye1h5mft0mrhl/USI_ModuleWarpEngine%20CThree.cs?dl=0

The zip is the whole directory. Description change in the .cfgs and of course the DLL. DLL is really all you need.

This includes the latest commits so if there is weirdness with the bubble guide that's good to know too.

Note you can change the "mode" of the drive in the VAB/SPH, but not in flight. It will tell you the mode of that drive while in flight. Default mode is Angular Momentum / Orbital Energy conservation. If you have any ships currently in flight with the warp drive they will become angular momentum conserving drives! (I did this for my own test save purposes. Will change to classic velocity conservation drive being default when I do commit to github.)

Wierd/bad things happen at very high warp sometimes on sphere of influence changes. If that happens, I think I may know the problem but unfortunately the answer is... slow down on those transitions. Which you should anyway, navigating at 15c is hard! I find I fly most places at about half throttle unless I'm trying to cover large distances.

I have a bit of a beast of a computer, so feedback on performance hit or crashes while active is appreciated too. Runs nice on my rig using a 275 part spaceplane + lander.

There are also concerns with G loading as the velocity is changed during warp flight. DRE users want to chime in on if it causes a problem? I'm not sure if there is a solution to it though. I don't use DRE myself, so I don't know.

Final issue is the math isn't perfect. Partly due to floating point errors, partly due to how KSP calculates trajectories and changes its frames of reference. If you warp to Eve and return to Kerbin taking up the exact orbit you had when you left is impossible/nearly impossible. You will have a different velocity, especially on multiple SOI changes. Now... at this point considering all the formulas and equations and things that have been looked at trying to get this to behave "just" right, this might have to be accepted as an unexpected effect of using warp and that gravity and trajectories while warping do affect your ship in sometimes unexpected ways.

Link to comment
Share on other sites

Because you have to have some mass for the engine part module to work, and ExoticMatter has no mass as it's shared with KSPI

Why not have the engine auto-generate a small quantity of mass with an arbitrary name? That way, you can be reliant on ExoticMatter, and run off the other material as the 'mass' for your mod.

For example:

EFFECTS

{

powerflame

{

MODEL_MULTI_PARTICLE

{

name = flameion1

modelName = MP_Nazari/FX/flameion

transformName = thrustTransform

emission = 0.0 0.0

emission = 0.10 0.00

emission = 0.15 0.45

emission = 1.0 0.75

speed = 0.0 0.75

speed = 1.0 0.97

}

}

}

MODULE

{

name = ModuleEnginesFX

//engineID = rocketengine

//runningEffectName = powersmoke

directThrottleEffectName = powerflame

thrustVectorTransformName = thrustTransform

exhaustDamage = False

ignitionThreshold = 0.1

minThrust = 0

maxThrust = 80

heatProduction = 0

PROPELLANT

{

name = ElectricCharge

ratio = 12.0

}

PROPELLANT

{

name = GravioliSlurry

ratio = 0.1

}

atmosphereCurve

{

key = 0 420000

}

}

MODULE

{

name = FXModuleAnimateThrottle

animationName = colorAnimation

dependOnEngineState = True

responseSpeed = 0.5

}

MODULE

{

name = ModuleGenerator

isAlwaysActive = true

OUTPUT_RESOURCE

{

name = GravioliSlurry

rate = 20

}

}

RESOURCE

{

name = GravioliSlurry

amount = 20

maxAmount = 20

}

The above component is an engine that works off incoming electricity only. It's simple, and game-breaking, but it works, and therefore is a decent example.

Edited by Mekan1k
Link to comment
Share on other sites

I'll take a peek - I assume if all looks good you have no aversion to this being rolled in?

Go right ahead, I can do a pull request too just let me know.

Serino and I are still investigating better ways to do the math so it's more stable. But this one seems to work pretty well with a few predictable issues.

Link to comment
Share on other sites

RoverDude you might want to hold up on integrating the angular momentum stuff if you were going to. I just came up with a kinda cool version involving a different take on the math.

If anyone wants to try that one instead of the one I posted before. Rename it to WarpEngine.dll and replace. https://www.dropbox.com/s/u0upuz84v6c38dx/WarpEngine%20p.dll?dl=0

This one deals with hyperbolic trajectories very differently and lets you do things like, match orbits with a celestial body by continually warping at the planet, or better the periapsis of the orbit you eventually want to take. More feedback than what I and Serino can do testing ourselves would be great and will let me know which of these two avenues to continue to pursue as I think they both have their virtues.

https://www.dropbox.com/s/lzxxr0cwq0r4ny5/USI_ModuleWarpEngine%20semilatusconstant.cs?dl=0 new source too for those that may want to take a peek at it.

Link to comment
Share on other sites

I think it's nearly ready to go. I fixed one of the big problems I was having, the new math seems to work really smoothly. I'll keep trying to break it and unless Serino or one of the folks testing it finds a big problem I'll push it along this weekend.

https://www.dropbox.com/s/u0upuz84v6c38dx/WarpEngine%20p.dll?dl=0

(rename it to WarpDrive.dll and do a direct replacement of the existing warp drive.dll) for those that want to test it.

Also, this whole time I've been getting a spamming of errors in the log about the Destroy Nearby Ships module failing "[Log]: [WARP] ERROR IN DestroyNearbyShips". When I activate the drive. I have no idea why. I've had it disabled during my test DLLs but want to make sure there isn't a conflict when I push the alternate physics mode.

Link to comment
Share on other sites

I think it's nearly ready to go. I fixed one of the big problems I was having, the new math seems to work really smoothly. I'll keep trying to break it and unless Serino or one of the folks testing it finds a big problem I'll push it along this weekend.

https://www.dropbox.com/s/u0upuz84v6c38dx/WarpEngine%20p.dll?dl=0

(rename it to WarpDrive.dll and do a direct replacement of the existing warp drive.dll) for those that want to test it.

Also, this whole time I've been getting a spamming of errors in the log about the Destroy Nearby Ships module failing "[Log]: [WARP] ERROR IN DestroyNearbyShips". When I activate the drive. I have no idea why. I've had it disabled during my test DLLs but want to make sure there isn't a conflict when I push the alternate physics mode.

can you or someone explain what this changes? (short version)

Link to comment
Share on other sites

The "classic" version where your velocity is preserved remains intact. If you select "Velocity Conservation" in the VAB and it works as it does now. Behavior is effectively that the warp bubble pops you out of space time, and you continue on upon bubble collapse just as you were when you entered. You get free potential energy by warping away from the center of gravitation.

If you select "Angular Momentum Conservation" in the VAB you get the new behavior. It keeps constant the magnitude of the orbit.h vector (specific angular momentum) and direction of the velocity vector. Basically as you warp away from the planet/star your orbital velocity will reduce, as you warp towards it, it will increase. Some odd stuff happens with hyperbolic trajectories which requires special math in order to conserve angular momentum. Your angular momentum and semi-latus rectum remain constant, and your velocity changes based on your current position's SMA and radius. In a way it functions kind of like the opposite of the current behavior. You get no free energy with this one. You stay put space moves you. If you warp out to Jool you usually have too little velocity like a Hohmann transfer rather than too much. This means you can adjust your orbit in interesting ways, when I push this along I'll write a tips & what you can do guide for those curious in this alternate hypothesis on the behavior of an Alcubierre drive. I think after getting used to it that its far easier to use.

Edited by helaeon
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...