Jump to content

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


RoverDude
 Share

Recommended Posts

Hey, erm. Why when I activate the engine does it just make a big green bubble for 2 seconds?

Shakes head...

The answer isn't even far back, its on the same page just above. It was answered directly when you asked in the Karbonite thread, and it is listed in the release notes. That should be more than enough tips for you to find the answer.

Link to comment
Share on other sites

I have noticed some shake when running some ships. Its similar to the flexing you get when you have a long space station and SAS is trying to stabilize it after a bump only with the Drive as the non moving center point of it. I can't find any rhyme or reason behind it, there seems to be no pattern behind when it will or will not do it. Longer ships seem to be more susceptible but even then it's not every warp and sometimes I even go warp after warp with nothing or have it just randomly start in the middle of the warp. It does seem to be more frequent when the SAS is "far" from the drive though.

Edited by Serino
Watching a toddler and typing causes errors.
Link to comment
Share on other sites

I have noticed some shake when running some ships. Its similar to the flexing you get when you have a long space station and SAS is trying to stabilize it after a bump only with the Drive as the non moving center point of it. I can't find any rhyme or reason behind it, there seems to be no pattern behind when it will or will not do it. Longer ships seem to be more susceptible but even then it's not every warp and sometimes I even go warp after warp with nothing or have it just randomly start in the middle of the warp. It does seem to be more frequent when the SAS is "far" from the drive though.

Wonder if this is why the ship I just built has parts inexplicably explode partway through the warp. I'll get up to speed then shortly into the warp stuff starts colliding for no reason and of course blowing up. Doesn't seem to happen when not going fast as far as I can tell (seems to start happening around .75c). It's also the same parts. I've tried attaching them differently and strutting them, to no avail still boom.

Have tried with SAS both on and off. Still booms. Maybe 30 seconds after hitting 1.6c, but sometimes it's pretty safe and I think things are good then BOOM! Though... I saw a ways back in the thread that the drive is supposed to be dangerous... not a fan of warp krackens though. But if part of the RoverDude plan I'll limit the throttle. :)

Link to comment
Share on other sites

I've been using gravity / aerobraking for deceleration (move past Ps, warp back, move again, etc) but it was slow and boring until I found this method.

But I'm having trouble with navigating (where to point my ship when warping) and found out that once I'm past the Sun periapsis it's very difficult to start moving actually away from the Sun. When I finally manage that I usually again have 8-9 km/s difference with my target. The best result so far is 2.5 km/s. (I do not consider 22 km/s Kerbin atmosphere re-entry a success... it was epic though).

Actually I currently find navigating with AD much harder than using more traditional ways.

Are there any visual guidelines I should follow when navigating with AD?

Link to comment
Share on other sites

I've been using gravity / aerobraking for deceleration (move past Ps, warp back, move again, etc) but it was slow and boring until I found this method.

But I'm having trouble with navigating (where to point my ship when warping) and found out that once I'm past the Sun periapsis it's very difficult to start moving actually away from the Sun. When I finally manage that I usually again have 8-9 km/s difference with my target. The best result so far is 2.5 km/s. (I do not consider 22 km/s Kerbin atmosphere re-entry a success... it was epic though).

Actually I currently find navigating with AD much harder than using more traditional ways.

Are there any visual guidelines I should follow when navigating with AD?

I've just started messing with the drive in the last couple of days. I've found that it's best as soon as you're in warp to consider you're really not in space. you can go anywhere you want any time you want. There is an exclusion sphere around each planetoid that must be avoided however, hitting one of those at the wrong time would be a day ruiner. Then only when you shut off your drive do you "pop in" and the rules then apply to you again. From there though I've been eyeballing it, both in regular flight view and map mode. Can use the nav ball to get an idea of where you're pointing. It's not a precision thing from what I can tell... but Jool in like 5 minutes!

Link to comment
Share on other sites

I've just started messing with the drive in the last couple of days. I've found that it's best as soon as you're in warp to consider you're really not in space. you can go anywhere you want any time you want. There is an exclusion sphere around each planetoid that must be avoided however, hitting one of those at the wrong time would be a day ruiner. Then only when you shut off your drive do you "pop in" and the rules then apply to you again. From there though I've been eyeballing it, both in regular flight view and map mode. Can use the nav ball to get an idea of where you're pointing. It's not a precision thing from what I can tell... but Jool in like 5 minutes!

I mean it's not a problem to get to Jool in 5 minutes with AD, the problem is to get to Jool with manageable velocity difference. There's got to be some math to help you getting anywhere in 3 easy steps - warp to point X, Y, wait for T days, warp to destination with zero dV to kill.

Link to comment
Share on other sites

Again, just from my flying by the seat of my pants fiddling around...

Big thing it seems is to drop in with your velocity vector facing the right way. You also will know the velocity of the planet that you are going to in relation to Kerbol (in the wiki) and you match velocity before going out there you should need very little dV to circularize, if any. If I understand how the coding works. So, if you're on the opposite side of the sun from your target you're going to have the maximum velocity difference. If the planets are aligned you'll have the minimum.

From what I know a real Alcubierre drive would preserve momentum not raw velocity, so going directly from Kerbin to Jool you'd drop in out at Jool and have too little momentum if its magnitude were correct, which actually isn't much different than our usual Hohmann transfers. Momentum is why you need to add velocity/energy to go to higher orbits, but your orbital velocity vs the planet lowers but your ship has more momentum (the "velocity" becomes potential energy stored in the height in the gravity well). and then more to circularize at that orbit or you aerobrake or sling shot (robbing momentum from the planet). I have no idea if it would be possible to figure out in KSP momentum rather than velocity in a way that was practical. At which point the drive would behave much more intuitively I think. I could be completely wrong here, as I may be missing something or there's something about the theory behind this drive I'm missing. Or I am poorly remembering my physics classes in college all those years ago. (RoverDude, BTW I love this drive. It's awesomeness is so extreme I have visions of Alcubierre drive shenanigans in my head and KSP is like new again. So thank you for your work on this. That momentum thing though... would be amazing, just don't know how to practically implement it in the game. Let you know if I figure it out. I think it would involve doing a calculation of current momentum, then solving for velocity upon arrival in relation to the current SOI then applying that velocity upon zero throttle, which might get rather complicated and is beyond the math I know. Won't be sad in the slightest if you nix that idea for whatever reason :) )

However, in this version of the drive we are conserving velocity. So, that means looking it up in the wiki and making it the same (magnitude and direction) if you want to arrive able to circularize without a silly amount of deltaV. The sun technique seems to be a good one for that.

Another technique I read about from KSPI is doing lots of quick little hops around the planetoid dropping in and out of warp and letting the tug of gravity against the ship circularize you that way, basically steering the ship where you want the orbit to be. That's on the list of things to test when I get home. ETA: It does work, but poorly. Looking up the correct orbital velocity and then using Kerbol to make that happen works awesome.

Edited by helaeon
Link to comment
Share on other sites

@Helaeon you are right the real one conserves momentum and even if its not explicitly stated also your momentum vector, if my knowledge of physics isn't failing me, and while that would be a very awesome way to implement this I don't even know if KSP has a momentum variable. It seems to me that it would just be easier to do some simple equations with velocity to determine orbits and such. It would be a nightmare to code in all the information for the warp drive but Roverdude could fake momentum conservation rather than velocity conservation. I wouldn't want him to work on that right now though I would prefer less kraken or more importantly larger drives, which if I remember right he is already working on.

Link to comment
Share on other sites

Again, just from my flying by the seat of my pants fiddling around...

Big thing it seems is to drop in with your velocity vector facing the right way. You also will know the velocity of the planet that you are going to in relation to Kerbol (in the wiki) and you match velocity before going out there you should need very little dV to circularize, if any. If I understand how the coding works. So, if you're on the opposite side of the sun from your target you're going to have the maximum velocity difference. If the planets are aligned you'll have the minimum.

From what I know a real Alcubierre drive would preserve momentum not raw velocity, so going directly from Kerbin to Jool you'd drop in out at Jool and have too little momentum if its magnitude were correct, which actually isn't much different than our usual Hohmann transfers. Momentum is why you need to add velocity/energy to go to higher orbits, but your orbital velocity vs the planet lowers but your ship has more momentum (the "velocity" becomes potential energy stored in the height in the gravity well). and then more to circularize at that orbit or you aerobrake or sling shot (robbing momentum from the planet). I have no idea if it would be possible to figure out in KSP momentum rather than velocity in a way that was practical. At which point the drive would behave much more intuitively I think. I could be completely wrong here, as I may be missing something or there's something about the theory behind this drive I'm missing. Or I am poorly remembering my physics classes in college all those years ago. (RoverDude, BTW I love this drive. It's awesomeness is so extreme I have visions of Alcubierre drive shenanigans in my head and KSP is like new again. So thank you for your work on this. That momentum thing though... would be amazing, just don't know how to practically implement it in the game. Let you know if I figure it out. I think it would involve doing a calculation of current momentum, then solving for velocity upon arrival in relation to the current SOI then applying that velocity upon zero throttle, which might get rather complicated and is beyond the math I know. Won't be sad in the slightest if you nix that idea for whatever reason :) )

However, in this version of the drive we are conserving velocity. So, that means looking it up in the wiki and making it the same (magnitude and direction) if you want to arrive able to circularize without a silly amount of deltaV. The sun technique seems to be a good one for that.

Another technique I read about from KSPI is doing lots of quick little hops around the planetoid dropping in and out of warp and letting the tug of gravity against the ship circularize you that way, basically steering the ship where you want the orbit to be. That's on the list of things to test when I get home. ETA: It does work, but poorly. Looking up the correct orbital velocity and then using Kerbol to make that happen works awesome.

>From what I know a real Alcubierre drive would preserve momentum not raw velocity

Momentum is velocity multiplied by mass. Unless your craft is changing mass, you don't need to worry...

Perhaps you mean it conserves energy? This isn't my field in physics, but I think that would make sense.

Link to comment
Share on other sites

It conserves angular momentum (I was being lazy with just "momentum"). So your velocity is slower at apoapsis than it is at periapsis (sometimes by a lot). As you go from apoapsis to periapsis, you trade potential energy for kinetic energy, then as you climb from periapsis to apoapsis you do the opposite, but you never change your momentum unless you turn your engines on. At all points in your orbit your angular momentum is the same.

With that in mind you would kick on your warp drive at any point in your orbit and have the same momentum. You could leave any planet at any time when in circular orbit around and have the same momentum at all times of year.

Right now if you leave at periapsis you have more "energy" than if you leave at apoapsis when really it should be the same (other than the direction of travel issue).

Check this out it may explain it better http://hyperphysics.phy-astr.gsu.edu/hbase/amom.html

(Math to implement it may actually be on that page!)

Consequence of this would be instead of transferring from Kerbin to Jool and be going way too fast on a solar escape, you'd have way too little momentum and be on a sun diver orbit when you dropped out of warp, so then you'd need to use Jool's gravity to rob angular momentum from it to match orbits.

If you were to transfer from Kerbin to Moho you'd be going way too fast, and need to do the opposite.

So the drive on transfers works opposite the way I think it's supposed to if I have my physics right... which I did have a lot of in college and it makes more sense that orbital momentum would be conserved not raw velocity.

But, all that said. How RoverDude wants his drive to work is up to him based on his vision and what makes the coding and gameplay work best in his opinion.

Edited by helaeon
Link to comment
Share on other sites

FYI I'm reading all of the stuff here - side note, it's mostly an easy way to simulate the effect from a coding standpoint. But if someone a lot more clever than me has a pull request to change the physics, I'm game :D

Righteous. I figured you were :) No idea where to even start with the code myself but I think I get how it *should* work so if that clever coder wants further explanation of what's going on a hand testing and bee kicking I'm all over it.

I have an idea of how one might do it, but I'm not sure what maths are allowed. I think one would need to do operations on vectors. You'd convert your orbit to an angular momentum vector on activating the drive, then on SOI switches you'd compare vectors and do operations on yours as appropriate for your new frame of reference. Such as upon leaving Kerbin SOI going to Duna you'd add (?) Kerbin's angular momentum vector when you went to Kerbol SOI. Then when you got to Duna SOI you'd subtract (?) Duna's. Kerbin to Mun I think it would work the same way, you'd subtract the Mun's from yours, and add it back when you left its SOI. If you could feed back that velocity data from the vector as your altitude changes I think it would keep the map and KER, VOID, MJ, etc working. But, further orbital parameters may need to be defined on the fly... don't have any idea how that system works or what the game needs. Good news is any body on rails will have a constant angular momentum so could be pre-calculated (or defined) and stored in a database. I'm about 10 years removed from doing this kind of math nearly daily so I only remember vaguely how one goes about it.

Edited by helaeon
I am apparently tired and can't write coherently
Link to comment
Share on other sites

@Bakase and @helaeon it depends on which version of the alcubierre drive is looked at one moves space time at a fixed speed in the direction you are pointing, there by conserving your angular momentum, or if you prefer your total energy (I don't think it really matters what we call it right now as long as we all understand), but there is another idea that was postulated in the paper written on the drive and metric in the you could use it as a "booster" where it would multiplying your velocity by a number while the drive is active but when it turns off you return to your original velocity, more of a warping space-time to create apparent velocity change without true velocity change. This would keep your velocity the same but move you around. Roverdude's drive works this way.

Also @helaeon It is a whole lot more complicated than it seems lol. I had to bust out one of my forgotten college textbooks to find an equation of angular momentum in elliptical orbits.

Rover the equations would require you to be able to pull the mass of whatever body the warp field is turned on and off in as well as write it a new SMA and eccentricity instead of letting it determine it for you. If you can do that without having to quickload it or something of that matter then let us know and I can give you the equations to do it. I would write the code and send that to you but I don't know what the mods are written in. I myself happen to be a C++ user with only a semi working knowledge of C, and a few other languages that wouldn't be useful in this situation.

Edited by Serino
Link to comment
Share on other sites

@Serino. That's awesome info there. Thank you. I was looking for a semi-easy way to simulate the effect as I very basically understood it, but if you've got a plan for the real deal. YES! :)

Looking at rule of cool, which is why the velocity version is great too. So I know I'd be stoked if we could get the effect of the conservation of angular momentum even if the math was an approximation that works well enough in most cases.

The masses of those bodies can be derived from our orbital parameters, and that's if the game doesn't expose the masses directly. May have to make a decision on about whether Kerbal G is the same as our G.

http://www.ajdesigner.com/phpgravity/keplers_law_equation_mass.php

From http://wiki.kerbalspaceprogram.com/wiki/Plugins. Looks like C# is the language.

And there is this http://forum.kerbalspaceprogram.com/threads/30401-Documentation-for-the-KSP-API

I have no answer about whether you can write a new SMA and eccentricity without causing the game to freak out. I wonder if Hyperedit can do that sort of thing and what the consequences are? If it works well there, see no reason you couldn't. Also wonder if you could feed the relevant information back into the game as you are in warp so we would have a preview in map mode or in our HUDs about what is going on?

Link to comment
Share on other sites

I have the equations to do it but currently hunting through all of my textbooks that I can find, and some that a friend of mine emailed me, to convert it over to using velocity so that we don't have to worry about changing orbital parameters.

Edit: nvm I figured it out once I realized that my equations already had everything needed to get the velocity when dropping out. Now to learn C# syntax and get a compiler so I can test my formula.

Edit 2: While I have the equations to do this I have come to realize that the further from your starting planet/moon you go the more inaccurate the value for your angular momentum would become. It gets even worse when you go to or from SOI inside of another SOI, ie moons. Coding in those values would work but only for stock planets which would unfortunately make this incompatible with any mods that add planets or moon or change where planets are or mass,

The point I am trying to make is that while Rover's isn't the turn on zip away turn off and angular momentum takes back over type of drive it is still pretty close to another form of the drive and getting the first type would be increasingly inaccurate with distance without locking this to stock worlds only.

Edited by Serino
Link to comment
Share on other sites

I don't think it needs to be perfect, and inaccurate would probably fit into "dangerous and a little scary" if you wanted to leave it open-ended using in-game values. I had that thought too that as your orbit becomes more and more a straight line with you sitting at apoapsis as you warp away from the planetoid that what momentum you do have grows increasingly inaccurate as your angular velocity increasingly approaches zero.... which is fine with me. I think we (the players), need to simply deal with that. As orbital velocity approaches zero it might as well be zero from a player's stand point, and you put in something to prevent it from actually reaching zero to prevent division by zero problems. However, that would mean that you could essentially get "free" momentum by warping away towards the edge of the sphere of influence and then back in... maybe. It depends on how inaccurate things would be and how many significant figures the game engine gives and will receive... I think. But, again, inaccuracy doesn't bother me. Even 10-20% off is probably okay.

Do what's easiest for you, makes the most sense gameplay wise, and makes you feel best about it. I for one greatly appreciate the effort you've already put into this.

A thought I had about the two versions of the drive too... if you get the alternate physics working maybe Rover could put a flag in the DLL so we'd have a velocity AD config and a momentum AD config that we could set it in the VAB (or maybe on the fly while in flight).

Edited by helaeon
Link to comment
Share on other sites

the problem isn't your angular momentum but the difference in the angular momentum between the planets/moons its the difference between coming in and having an orbit vs arriving and being on an escape trajectory. It has been a while since my last physics class but I am pretty sure that your true angular momentum is your angular momentum around the planet + your angular momentum around the star but we would only be able to calculate and use the angular momentum around the planet. That means we would be ignoring the almost double angular momentum that Jool's orbit around Kerbol has over Kerbin's orbit that's what I mean by inaccurate. In reality going from kerbin to jool with the alcubierre drive would still require you to add quite a bit of Dv to stay there rather than fall back towards the sun. If everyone is ok with that then I can start work on trying to figure out how to work that into Rover's code once my wife and daughter are no longer sick, or if someone wants to start work now I can give them the equations needed to do it.

Edited by Serino
It's late and sick family make incoherent thoughts.
Link to comment
Share on other sites

Sounds fine to me as it seems that's how it should work.

You should probably be on an escape trajectory unless you warp in at exactly the right place, and even then that place may not exist.

You're right about the momentum being your orbit around the star + orbit around planet. But I think it's close enough to assume that while in Kerbin SOI, that your ship and Kerbin have the same orbital momentum around Kerbol. So, you only worry about that when leaving Kerbin SOI. Intuition is that your dV for capture should probably be the about same as if you did the usual hohmann burn, but you need to supply it all at the end. It also didn't take you 2 years to get to Jool.

Now that I think about it your orbital equations if they account for inclination might be giving you a 3D vector, or something that can be expressed as one, and those can be added and subtracted like I originally thought. Looks like Vector3D might have the functions needed to do the operations for you. Would need to define the output of the orbital equations to their x,y,z components then Vector3d Add( should do the rest. Then could reverse that to feed the right information back into the game engine on updates.

When you leave a child body's SOI you add that child's momentum to your own. When you enter a child's SOI you subtract that body's momentum. This works no matter what body you're talking about I think and 3d vector math would take into account retrograde orbits and inclination differences as well. ETA: that body's mass would need to be substituted for your ship's mass when doing this calculation. I'm going with that the momentum imparted by that body is the same as if you were matched on its orbit exactly.

You take care of your family, we all can wait unless someone else wants to take a crack at it. If there's something I can do with game testing, math, or research wise that will help you with the coding let me know. I looked at USI_ModuleWarpEngine.cs on Git and I think I somewhat understand what is going on, but also realize I don't know anything about the language so no idea best practices and how to do even simple things like declare variables properly or pull or feed necessary info into KSP (but can look into that as well if it will help).

Edited by helaeon
upon thinking about it....
Link to comment
Share on other sites

FYI still watching this discussion with interest. Side note - any change would have to account for more than just the Kerbol system, i.e. it should work regardless of the orbiting body in question. If someone wants to take a serious crack at this and has the formulas and code down to the integration point, let me know and we can work it in.

Link to comment
Share on other sites

I have the formula for use with anything but by necessity it will have the inaccuracies I pointed out, they wont have anything to do with the calculation itself just realism accuracy. The formula isn't hard, I even have a formula to give the velocity at your altitude so that the game could theoretically set the SMA and eccentricity with it, but I just don't have time at this moment to try and code it since both my wife and daughter are sick. C# is also not something I have a lot of practice in, if this was C++ I would have already whipped up a class for it and submitted it but it's not, so if someone with more C# knowledge/practice than me wants to take a crack at it I would be more than willing to work with them by providing the formulas and continuing to search for a way to make it more realistic.

@helaeon Yea I was looking at the cs when my daughter puked on me which ruined that pretty quick. What you said is true about a child SOI but in the interest of keeping this available for all I currently have it only take into account your AM around planet/moon. Anything else requires some thought, though while laying down last night I thought of a way to do it, thought again with my limited knowledge of C# I am not entirely sure it could be done. Nifty thing is that your inclination from one place to the other will stay the same because reasons. In all seriousness though without us building one in reality there's no way to know how inclinations would be so i say they would stay the same for now.

Edited by Serino
Link to comment
Share on other sites

I think that gives you a lot of leeway to do something that seems to make sense being that one doesn't exist. You do what you think is best when your family is feeling better and I'll give it a go and see if it is behaving.

Again, anything I can do to help with the math or looking up functions or thinking up ideas of how to implement please let me know. If you want to send the math over I'll look up what functions we can use in C# and the KSP API to make it happen.

I think I know enough from what I was looking at in the KSP API right now to just about make a mess :P

Link to comment
Share on other sites

I'm having a problem with the .625 meter version exploding whenever i try to use it. I don't have any parts sticking out of the warp-bubble guide, but each time i throttle up more than enough to see the bubble start to form the entire thing explodes.

It is okay to have karbonium/karbonite in the bubble, right?

craft file: https://drive.google.com/file/d/0B171LYBBLzekdU1VUWN1WGI5cjg/view?usp=sharing

using Box sat, karbonite, K+, tweakscale, near future electricity,

pictures of craft in VAB

screenshot0.png

screenshot1.png

Edited by mkire
Link to comment
Share on other sites

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.

 Share

×
×
  • Create New...