helaeon

@RoverDude Can do. I have Turbo Mode left to add and need to go over the part configs. Doing part configs pass today with stock in mind (both resources and system size) while I noodle over how best to do turbo. I'm thinking it'll be a couple of days at least. What I set out to do works nicely, but everything is in need of tuning and re-balance. A little thinking out loud here : On turbo... I'm still not really sure the best way to support 1:1 systems and multiple star systems. Anything faster than ~6c is way too fast for stock (even OPM), but that's about 20 minutes to Neptune in RSS. Physics warp works now though so it's only 4 min. Everything works exactly as I'd like for just stock. Maybe a turbo button (maybe "hyperdrive") on the drive menu that multiplies the top warp factor? Any requests on that multiplier 10, 100, 1000? 1:1 systems are still an issue though because fuel flow should probably be dropped by a factor of 10 when using one of those systems - though that could be handled with a MM patch that is re-named from .txt to .cfg if using a 1:1 system

@Hay I just looked on newegg. 512GB m.2 PCI-e is $200-$250. That's what my 240 GB SATA was 4 years ago. There are quite a few for less than that. 250 GB is $124. The SATA drives are right in there too. Cheapest 2.5" SATA drives on newegg in that capacity range is $140-150. Any new motherboard should have a m.2 slot on the pci-e pipe. My suggestion is get a reasonable sized SSD (250-500 gb) and a cavernous traditional drive (3TB or more). Install programs and system stuff on the SSD and keep pictures, videos, music, documents, etc on the traditional drive.

@RoverDude I think what I'll do because it should be reasonably easy (I think) is if the game detects more than one part active with the USI_WarpDrive module, it'll just straight blow up every part with that module. So you could have multiple warp drives installed on a ship, but you better not turn more than one on.

@GenesisPlayzDid you use my dev version from a few days ago or the current release? I changed the way translation is calculated and applied in the dev version. It's much smoother and changing your delta physics time in settings no longer alters your speed. My guess is if it is actually increasing your translation then it is additive. Game is applying frame shift for the first part, then applying it again for the second. Right now I have the speedometer (in the dev version) using the distance it's applying to calculate the speed. I wonder if I should have it do some trig to compare using the distance from the central body in the current physics tick and the previous one. But... I also kind of don't want this kind of addition to happen. Tuning the warp drive's parameters and limitations has been fiddly and I think with the new braking calculations things could get odder. I think I'd rather disable the shifting ability of all but one warp drive part on the ship and at most allow a bubble extension. I think I need to look into how to do this rather than consider it optional. I will do a pull request of what I have this weekend though. Right now there is no turbo mode and of course no bubble extension and disabling of shift stacking - as discussed above (unless @RoverDude wants it to stay as 1 bubble only, then I'll figure out how to only allow one part to work period). AM mode works again and the new braking function which is super awesome... and allows a new circularization technique when in AM mode (it always worked but your throttle was so sensitive you couldn't do it)

@FreeThinker you are right! I'll fix it in my dev version. Thank you. That part only applies to angular momentum mode which is currently quite jacked up in the release version.

@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.

The i7 8700 is just around the corner (they've been out since Oct 5 just unavailable), and it has a really nice single core clock speed and should do single threaded applications nicely (KSP!) I use a tooooooon of mods and like to do other stuff while I play KSP, so I'm running 32 GB. However, my paychecks come from being a large format designer & engineer... so my rig needs lots of RAM for work KSP just benefits. When I had 16GB in mine it was fine. However, I just looked at the performance graph the other day and I was utilizing 24 GB while playing KSP (including windows, browser, cache etc). On RAM the issue isn't speed... mostly... it's about putting everything in memory. If you run out your game crashes to desktop same as the old days when we had a hard 4 GB limit. Graphics card does matter if you're using visual mods. I have an nVidia 960 and it's more than enough. Something I didn't see mentioned in a skim, get an SSD attached to a good pipeline and install KSP on it. PCI-e or M.2, as SATA drives are limited at 6 GB/s.

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.

I have a Melty Kerman that I rescued from low orbit of Kerbol (like circular orbit well inside Moho's).

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).

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.

@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.

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.

@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)

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.

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.

@jd284 back when I made the alternate mode (3 years ago! wow), I wanted to do something similar to what you were saying. However there are some limitations on the kind of math you can do with vectors; or being a chemist rather than a physicist or mathmetician I am not well versed enough in vector math to know how to do it. So the thought was that orbital speed was a function of orbital energy and your position and travel direction. That you give yourself energy somewhere in your orbit and that allows you to climb higher in the gravity well on the opposite side, much like throwing a ball upward. So, rather than preserving velocity I'd preserve the total energy of the system. There wasn't a simple way to figure out which direction your travel vector should be so I just left it the same. Interestingly when it AM mode is working as intended you do need to "pay for" your jump with the usual delta-v but at the end, and with the added benefit you can use repeated sling-shot passes (can keep warping back just before periapsis) or use Oberth and always burn just on either side of periapsis then come back. Also it allowed on hyperbolic orbits to do repeated slingshots, which is something that should actually happen. I used those follow on effects as further evidence that even just from a gameplay standpoint the AM mode was a good take on how a warp drive might behave. @CaribouGone Looking back at the code and doing some tests last night there is certainly something going on with the SOI hand-off. I think it has to do with the changes to Krakensbane and the new FloatingOrigin. Krakensbane was always a major issue in changing the velocity of your craft outside of normal game mechanics, which actually led to using it to re-position the ship in game. I have a couple of ideas on how to feed the changes to velocity into the game and try and get around FloatingOrigin and Krakensbane. Also, wondering if anyone knows of a way to suspend or over-ride G-Forces as that too is a major issue now with kerbals being able to pass out. Any thoughts as to what might be going on are welcome. I'm thinking about while mucking around in the code again I might finally add that Elite Dangerous like limit on top speed based on your distance from a gravity center and the mass of that object. Is that still wanted? I think I'd have it apply to both energy conservation modes. ETA an hour later: I think I have it fixed such that it behaves. I'm still getting an error in one of the modules I'll try to knock down even though it doesn't seem to affect anything. I'm thinking I do want to add an Elite Dangerous type variable speed. Throttle is just too fiddly inside a 1:10 system, if you target Jool and warp from Kerbin at 5c you have about 3 frames between SOI hand-off and slamming into the planet. Current thought is calculation based on inverse square, and that your maximum warp will be very low as you near the fail-safe.

Just built a ship and there is definitely something wrong with the angular momentum mode. I'll see if I can figure out what. It seems to not be doing the calculations (as there is no change in orbital velocity), but it's trying and chugging along in the attempt especially in map mode.

@capi3101 Going from Kerbin to Dres you should end up going quite fast relative to Dres, but if you look at your orbit around Kerbol it should be a skinny ellipse. I think I remember needing 20 or so successive jumps to capture and did need to use thrusters. .33c though, that's excessive. I haven't ran a warp mission since early 1.2 though so it's possible that something snuck in and it's misbehaving. Here's generally what's being done: When you engage the warp drive your orbital velocity and direction is stored as a vector, as is the orbit.h vector (your orbital angular momentum). Lots of math is done to figure out at any given current position what your velocity must be in order to make orbit.h always remain the same, provided the direction of the velocity vector does not change. This includes hand-offs between SOIs. So if you do the usual maneuver where you drop near the star, change your orbital direction and fall a bit to gain more velocity then warp to your target... in angular momentum mode that only helps to get your velocity vector pointed as you want you gain no energy so it doesn't help you have a better relative velocity to your target planet. I do seem to remember there being some compounding floating point errors that can happen when getting very very close to Kerbol, or when your orbital ellipse becomes very very narrow. I did test it against OPM at the beginning and it worked very very well. I took quite a few trips out to Plock. What I've found is that you warp to your target and need to use nearly the same delta-V as if you did a regular transfer at that same launch time (with some exceptions). Other than slingshotting I imagine there are other clever things one might do with the Oberth effect to gain a lot of orbital energy without spending as much delta-v as if you warped straight to your target. I might build a warp ship this weekend and see if everything is still working as I expect.

If you have questions about how angular momentum mode works feel free to PM me or ask here (tag me though). I wrote that mode and came up with the math. I wrote it mostly for myself as linear gives you free energy and I thought some kind of orbital energy conservation was more plausible as to what a warp drive would do while moving around a gravity well. RoverDude was cool enough to let me include it in the official version. In many ways it operates opposite of the linear mode. As you climb the gravity well (get further from the planet) your orbital velocity goes down. It's designed that it is necessary to use your thrusters more, but also allows repeated slingshots to gain orbital energy. You'll notice in linear velocity mode that doesn't work. The thing that got me to write it was the energy you have at Kerbin shouldn't allow you to escape Kerbol when you go out to Jool, you should still be solidly captured by Kerbol. All that said, I have NO idea how it behaves with multiple star systems because all the calculations are relative to previous and current SOI, so between star systems... No idea what that reference point is.

You guys know that Nertea is working on new station parts that go really nicely with DSEV and would probably allow one to make a Nautilus-X like ship (and many many others). Especially will have tons of options if the DSEV & Far Future conflict on fusion reactors gets worked out. (Both have the function ModuleFusionReactor) and it doesn't play nice.

Its beautiful. Excellent job on the stock-alike look. Definitely looking forward to any other pods and parts you come up with.

Ideas for chargeable engine behavior: 1) Engine charges when you right click the part and use "charge engine" or stage, there should also be a "discharge engine" option (so you can shut it off). When engine is fully charged and not throttled at 100% the difference in energy must be dissipated somehow. Maybe as heat, maybe as continued full ec drain, combination of both? Engine automatically turns on when it reaches 100% charge regardless of the initial charge status. So if you stage it and are at full throttle, the engine will charge then activate as soon as 100% charge has been reached. If you stage or charge engine, but throttle is at zero, it will activate as soon as you throttle up but you'll have to do something about the energy that needs to be dissipated to maintain charge. In this way I would think they would work a lot like the reactors from NFE. 2) Engine charges as soon as throttled up there is no pre-charge engine option. Shuts off when throttled down - but dissipates charge over time (kind of like how parts cool off over time) so if you need to do successive burns you don't have to wait the full time for the engine to recharge. So, for the first part of your burn you have zero thrust which would encourage schemes where you charge the engine very quickly rather than trickle charge it. Or use the capacitors from NFT as a pre-charge location then dump all that charge into the engine immediately if you want less delay.

Idea not a request. Use or discard as you wish. What about making a structural frame for the probe core for the various bus shapes, something with the node in handy places? Possibly put the RCS on that piece, or handy mount locations. Then you could use that frame for other things or put different probe cores in there as you upgrade the tech tree. Might also give some interesting KIS/KAS options - parts with nodes are way easier to work with on EVA than surface mount. Maybe even hidden framework that only pops on if a node is utilized. if one doesn't want to use the probe core but wants to use the frame might be handy to use as a lander base, extra fuel, a framework for inside a service bay all sorts of things that you'd have less options if it was another differently shaped probe core. Lego like nature could be retained. For example I made an ultralight flying craft using your surveyor frame, a small nuclear reactor, and the USI propellers. The mount locations for the rocket motors were cool so I could make landing "brakes" with the rocket motors but was not boxed into using an integrated thrust package.

May have a conflict: ModuleFusionReactor is the name used by Angel-125's DSEV for its fusion reactors. It seems that it doesn't cause any major problems other than the right click menu looking odd. It seems that reactors configured for DSEV still work properly though the new buttons like Enable Charging and fuel type do not work (because not configured). MM patch to add FFT features to DSEV's reactors or conflict requiring module re-naming or neither?