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

[helaeon]

Did quite a bit of work today. I have a proof of concept finished for the gravity brake, did a bit of an overhaul on how warp speed and max speed is calculated and applied. One can cram in a desired number into the config for WarpFactor and it'll be the true maximum warp (so multiple solar system people can put in silly numbers like 3000 or bigger), I also have a config based braking factor that when it's all finished should let those same people put in huge numbers so they start to brake harder, sooner. I took out the slowly decelerate and accelerate, the throttle itself does that now (makes huge warp factors useable). Also fixed Kerbals experiencing G-Forces in angular momentum mode.

It all works but I have some tweaking to do with how everything works together and to make it behave as I want, but I ran out of weekend... It's 90% done though.

[FreeThinker]

I wonder if someone could figure out a way to combine Roverdudes Alcubiere drive with KSPIE Alcubiere drive. I wish I could figure out myself but unfortunately I don't have the time.

Edited October 31, 2017 by FreeThinker

[RoverDude]

And the whole point of this mod is to have a stand-alone drive without the weight of KSPIE.

[FreeThinker]

4 hours ago, RoverDude said:

And the whole point of this mod is to have a stand-alone drive without the weight of KSPIE.

I'm not debating that, my  suggestion was to incorporate some of KSPIE alubierie warp methods (time warped FTL) into this mod.

[helaeon]

Physics warp FTL might be possible now that the translation calculations are tied to the fixeddeltatime. (In my test version!) I just haven't tried it yet. (Just did, it works, so you can have up to 4x time warp)

There's a decision here that I'd welcome some feedback on, but the window on that feedback is somewhat small as I'd like to have this project wrapped up by the end of the week.

I have a working frame-work for the new goodies and gravity braking. But, I have two choices:

1) I can have the warp drive "catch" you more easily when you approach planetary bodies, but it requires significantly limiting maximum warp speed (especially in the 1:10 Kerbol system) by being very aggressive with the brakes. I may even need to tie top warp speed to the player's physics increment time. I'm finding that on each physics tick, the distance you travel can be far beyond the sphere of influence of anything if warp is high enough (I'm getting this happening even at warp 6). There's nothing I know of I can do to fix that other than bring warp speeds down or completely re-think  how I'm calculating the braking so it always takes into account every body in the system (I'd imagine very CPU intensive especially in something like OPM and I doubt it would work well with multiple star systems). Of course on a 1:1 scale system higher warps would work because you have more physics ticks occurring between point  A and B.

Other option is it doesn't catch you nicely, but it does help slow you if you use your throttle appropriately and don't approach Jool at like 8c. It is still fairly fiddly but much, much better than it used to be.

Edited October 31, 2017 by helaeon

[RoverDude]

@helaeon - what kind of limitation on speed are you thinking?  i.e. is it something drastically slower than what we have in the configs today, or is it more that it puts a theoretic cap that's above the current config value?

If the former (i.e. we'd need to lower the speed in the baseline 1:1 Kerbol system), then I would vote for sacrificing nice breaking for speed.  

[helaeon]

@RoverDude I'm still playing with some math so I might find a really good solution, but I don't think there is any way around that if you move 270,000 km in a single physics tick (I'm using .06) at 15c, there's no way to slow one down in time. Kerbin's sphere of influence is 84,159 km. So there are 0 physics frames that I can use to slow the ship from 15c and that includes if it is headed right at the planet, but you almost never are so it's really hard to "grab" the ship. Only needs to be going 60,000 km/s to blow past the entire planetary cutoff warping through the planet which is about 5c. I was thinking for Kerbol max warp being around 5c-6c near Jool and and hopefully 3c at Kerbin's orbit (with the braking system doing its thing). For a 1:1 system one could up the warp factor in the cfg. That would hopefully at least give a couple of frames to grab the ship and start slowing it. I'm thinking at this moment to require the player to have throttle control but try to make it a bit forgiving.

I had a solution that for the stock system, due to the small radii involved it naturally limited to about 6c even though the config had 15 as the top warp factor. If I kept warping away from Kerbol my warp factor continued to climb. It would eventually hit 15 but it was going to take a long while. I abandoned that one thinking about multiple solar systems and 1:1 system as the warp factor wasn't climbing fast enough as I went away from Kerbol.

Right now I've got a braking solution where WarpFactor in the cfg is the absolute top speed and the gravity brake slows from that. I'm wondering if maybe a turbo button or function might be a better solution for going between systems (such as brakes come off once some distance away from a central body and speed increases to a turbo warp factor value)

[RoverDude]

@helaeon - I like the idea of a brake - possibly based on planetary radius, etc. where your max speed ramps up (or more correctly, your speed throttle is eased) as you get further away, so we can get some really fast interstellar speeds for the larger planet packs.  So even at max speed, you can't zip around the Kerbin system, but once a certain distance away (i.e. enough that you can actually slow down), the speed increases.  Same for other encounters (can we check the SOI for this?  i.e. are there any cases where we can blow through an SOI in a single tick?)

 

[capi3101]

I might suggest using twice the distance of a star's SOI as a "braking zone" for want of a better term. Within a star system, limit the max throttle to 10-15C (like it is now). Within the braking zone, maybe 100C or so (just to throw a number out there; that's probably still too fast), and then really be able to crank it when you're well into interstellar space. Could even scale that down within interlunar space inside the system.

Is there anything in the code that would increase the rate of depletion of consumables as speed increases?

[helaeon]

At work right now so throwing down some ideas for feedback as it does help with the thinking, so when I get home tonight I can try some stuff between trick or treaters. Apologize for the novel.

@RoverDude Right now the brake is based on planetary radius, its gravity, and how far away you are on an inverse square. The idea is that as your distance from a body becomes very large, your brake becomes very small. Your speed ramps up and down exponentially as you move through the sphere of influence. It works quite nicely, but I'm trying to figure out how to best apply them to the speed and put in a braking factor to fine tune things from the cfg (and what that number should be) to fit the most use cases possible so it naturally works well because the math does it on its own.

What I have it doing now is figuring out the brake factor for the object of your current SOI, then add the brake factor from the parent body, and then that's parent body, and so on. This causes your braking factor to stack quite nicely and there are no abrupt jumps in speed when crossing a sphere of influence. This and the other changes I've made have things running very nicely. I have a green mission timer the entire time I'm in warp and can use physics warp. As it is an exponential the idea is that you should hit your maximum warp speed (whatever it may be) but when near a planetary body it clamps down on it and ideally very hard as you get closer.

I've blown through the SOI of the Mun quite a few times (as in teleported through the body itself even). Even small warp factors can do that, and it may be something we won't be able to get around because the problem is more pronounced the smaller the body. Interestingly I think this would be a less severe problem with the 1:1 systems even at higher warps because everything is bigger and further apart.

The other idea I had, and I'm not sure how to actually implement and I worry about performance issues : Have the game tell me what bodies are inside the current SOI. So if orbiting Jool - Jool, Laythe, Tylo, Val, Bop, Pol. And the parent of that where applicable Kerbol. I'll need to get the distance and gravityparameter to each, also need the radius of the body currently being orbited (I'm making warp approach zero at cut-off altitude). Use these distances to get a braking factor for each - the only ones that will really matter a lot is your current SOI and the body you're closest to. Then blowing through SOI transitions wouldn't be as much of an issue because the braking could start well before the SOI transition. If I don't get something I like working on my current algorithm tonight, I'll upload my current best effort to my git fork and maybe start on this idea.

@capi3101 I think to do that I'd have to do the completely different thing mentioned above I'm not sure how to do. Also, I'm playing with stock system. I'm not going to test for mods I don't use, though once I get a workable version up if folks are willing to test and give feedback and if it's something I know how to change to make it work better I'll do it.

I'm also now thinking that SOI is supposed to be planetary body of highest gravitational influence... maybe I don't really want the braking factor working outside an SOI... player needs to control their speed - just like in Elite. The answer is probably to set maximum warp based on the scale of the system one is playing in. Then add some other features like when braking gets small enough it starts adding to rather than taking away (also exponentially) - I'll do that after I get the overall brake working well.

[capi3101]

2 hours ago, helaeon said:

The other idea I had, and I'm not sure how to actually implement and I worry about performance issues : Have the game tell me what bodies are inside the current SOI. So if orbiting Jool - Jool, Laythe, Tylo, Val, Bop, Pol. And the parent of that where applicable Kerbol. I'll need to get the distance and gravityparameter to each, also need the radius of the body currently being orbited (I'm making warp approach zero at cut-off altitude). Use these distances to get a braking factor for each - the only ones that will really matter a lot is your current SOI and the body you're closest to. Then blowing through SOI transitions wouldn't be as much of an issue because the braking could start well before the SOI transition. If I don't get something I like working on my current algorithm tonight, I'll upload my current best effort to my git fork and maybe start on this idea.

@capi3101 I think to do that I'd have to do the completely different thing mentioned above I'm not sure how to do. Also, I'm playing with stock system. I'm not going to test for mods I don't use, though once I get a workable version up if folks are willing to test and give feedback and if it's something I know how to change to make it work better I'll do it.

Hmm...okay, so if I understand correctly, this method would have you calculating your distance and bearing to every body in the system you're in with each tick, correct? That sounds kinda like what the Protractor Extended mod does, though in this case the bearings and ranges could be changing significantly with each tick. The 1.3 source code for that mod might give you a place to start if it turns out you need to go that way.

I use that mod; I should fire it up while warping and see if it behaves...

[helaeon]

@capi3101 I don't think big changes are a problem as I'm freshly calculating each tick both raw distance to travel and braking to apply to that distance. I want a fairly quick and simple-ish way to get the distance from ship to body, and then the gravparameter of that body. Which if I know what the relevant bodies are I think I can call both directly. I just took a look at what Protractor Extended does and it will certainly provide a start if I need to go down that route. Thank you.

[capi3101]

2 hours ago, helaeon said:

@capi3101 I don't think big changes are a problem as I'm freshly calculating each tick both raw distance to travel and braking to apply to that distance. I want a fairly quick and simple-ish way to get the distance from ship to body, and then the gravparameter of that body. Which if I know what the relevant bodies are I think I can call both directly. I just took a look at what Protractor Extended does and it will certainly provide a start if I need to go down that route. Thank you.

Glad to have been of some assistance.

[helaeon]

I have something that works awesome. Tweaking initial values for stock system now. Someone will have to let me know how it does 1:1 (and recommended values) or with higher warp factors. I have 3 values exposed in the cfg that one can use to set the drive up to their liking for their particular solar system or multiple solar systems. I did not need to do the Protractor thing but thanks again for the avenue if I needed it. Overshoots are still a thing if your aim is bad and you don't control your throttle, but I'm not really teleporting through bodies anymore. You don't have to be off by much to blast past Dres or Eeloo, but the braking works nicely even there.
No turbo factor at this point where after a certain point it starts increasing warp factor on top of the set one in cfg, but that is still do-able.

What you need to try it should be in the FOR_RELEASE folder (updated dll and cfgs are all I did). I have the current source up too. https://github.com/helaeon/WarpDrive
Usual disclaimer about dev version and use at your own risk.

[RoverDude]

Thank you @helaeon for continuing to be awesome

[helaeon]

While I fiddle with things the next few days I might bring ZZZ's folding warp parts back. I still have the pieces from when I made them work last time. Is there a desire for those still? I have a .625, 1.25, and 2.5 scaling. Also keep in mind I only have the part files, I don't have access to the original models so I don't think I can change anything.

@RoverDudeshould I add those to the pull request if I do them again. Seems I am making that pack every once in a while just updating the cfgs.
 

Any suggestions for values for other systems, especially if tested in those systems are welcome (even stock. I'd like other opinions as I just came up with a set of numbers I thought played nicely). If I get some maybe a  MM patch is in order so if you're using a mod that changes the system it will automatically change the drive parameters to fit that system.  Nice thing about having those parameters in the cfg :). I'm motivated to work on this at the moment so, now is the time if anyone wants changes or additions (within my power and ability).

[Enot02]

Could you make a bubbleless drive for me to use?

[RoverDude]

5 hours ago, helaeon said:

While I fiddle with things the next few days I might bring ZZZ's folding warp parts back. I still have the pieces from when I made them work last time. Is there a desire for those still? I have a .625, 1.25, and 2.5 scaling. Also keep in mind I only have the part files, I don't have access to the original models so I don't think I can change anything.

@RoverDudeshould I add those to the pull request if I do them again. Seems I am making that pack every once in a while just updating the cfgs.
 

Any suggestions for values for other systems, especially if tested in those systems are welcome (even stock. I'd like other opinions as I just came up with a set of numbers I thought played nicely). If I get some maybe a  MM patch is in order so if you're using a mod that changes the system it will automatically change the drive parameters to fit that system.  Nice thing about having those parameters in the cfg :). I'm motivated to work on this at the moment so, now is the time if anyone wants changes or additions (within my power and ability).

Awesome - and yeah, let's add in the ZZZ drive models to the core mod, the license is pretty darn permissive and folks seem to like that model

[helaeon]

12 hours ago, Enot02 said:

Could you make a bubbleless drive for me to use?

The bubble is pretty important to gameplay balancing, especially with the three new ones being added next version (same model, but 3 sizes). The 3.75m version has a bubble about the size of the VAB.

[Clonos]

@RoverDudeAwesome, i dont use part mod except this one.

but i have a question, does more drives mean double the speed?

[JadeOfMaar]

1 minute ago, GenesisPlayz said:

@RoverDudeAwesome, i dont use part mod except this one.

but i have a question, does more drives mean double the speed?

No... Warp drives don't work that way. The only option is to use the bigger or biggest warp drive and have a power source that can keep up when it needs charging.

[Clonos]

5 minutes ago, JadeOfMaar said:

No... Warp drives don't work that way. The only option is to use the bigger or biggest warp drive and have a power source that can keep up when it needs charging.

Hmmm, i've tested this with 4 drives and im not sre if it went faster than before

i guess youre right, but ill test this tomorrow

[capi3101]

49 minutes ago, GenesisPlayz said:

Hmmm, i've tested this with 4 drives and im not sre if it went faster than before

i guess youre right, but ill test this tomorrow

@JadeOfMaar is correct - attempting to "chain" multiple warp units together tends to lead to RUD at relativistic velocities. The 2.5 meter drive has a usable warp bubble radius of about 16 meters out the fore and aft ends, which in my experience is big enough to haul a lot of things all at once if you're careful about it. The speed limit is solely dependent on throttle (and by extension, the throttle limiter); with the version @helaeon has under development, it will soon also be dependent on where exactly you are in the system.

[helaeon]

@GenesisPlayzChaining multiple parts together is not supported and expected to cause problems. The way warp happens more parts won't do anything but muck up calculations. It doesn't add thrust like a normal engine in KSP. The distance you move per physics tick is determined entirely in the code based on the values in the part's cfg. However the chaining multiple parts comes up enough I'm noodling over if there is a way to deactivate all but one automagically in the coding (for aesthetic purposes)... or maybe just maybe let multiple drives overlap their warp bubbles... It won't make you go faster just allow a bigger ship and probably require power and fuel for each part. Don't expect this to happen though and it would be way down the line if I have steam left after finishing up what I'm doing now and adding in some sort of turbo mode. Pull requests are welcome though if someone wants to figure out the problem themselves.

If you want to go faster, make WarpFactor larger in the part's CFG. If you want a larger warp bubble: Change the Model scale for the warp bubble, then in USI_ModuleWarpEngine multiply BubbleSize by the same factor you did the model. If you did 2,2,2 for the model, do 40 for the BubbleSize. Or pretty sure that should work anyway.

Also my dev version it matters a lot where you are . Like max speed 1200km above kerbin is about 0.0001c, by the edge of SOI however you're at about 3c. Which happens amazingly quickly, I'm at about 2 minutes from engaging warp drive at Kerbin to full braking at Jool.

[DStaal]

Honestly, what I'd expect to happen if you have two drives on the same ship - and activate them both - is for the drives to interfere with each other and for the ship to explode...  (If you left one of the drives inactive of course you could carry it along.)