helaeon

When you hit the atmo button in MJ or KER it's saying at sea-level only (so your worst ISP). So it's assuming that you never leave the ground. Your true DV to orbit will be somewhere between the VAC and ATM numbers depending on the aerodynamics of your rocket and your flight profile. Usually closer to the VAC number as atmospheric pressure drops off pretty fast.

Can confirm I'm observing the same with KAS 1.0 and KIS 1.15. Also even with the electric screwdriver cannot get node attachments to happen. It part preview worked prior to KIS 1.15 (so may be a KIS not KAS problem). Node attachment has not worked since KSP 1.5 and KAS 1.0. Both parts that I tried to attach to the nodes were scraps generated by rescue kerbal & recover scrap missions. I'm happy to do further tests if necessary. I didn't see anything in my log but I can create the situation and make the attempt and get logs if desired.

@Angel-125 Totally. I got the part about removing the heat, why you did it, and agree (especially when time-warp is involved). But removing the generation of heat causes the drills to work at 10% the advertised rate because they are cold so ThermalEfficiency uses one of the first keys. Also not producing heat TemperatureModifier is also superfluous so can just go. ThermalEfficiency { key = 0 0.1 key = 250 .1 key = 500 1 key = 750 .1 key = 1000 0 } Drill is at something like 70K on the Mun so it uses the first key setting the drill rate to 10%. Drill part would need to be 500K to get advertised efficiency. The Buffalo and Pathfinder drills lack this block in ModuleResourceHarvester so work properly.

I think I may have found an issue. I was noticing my stock drills were digging up resources at about exactly 10% the advertised rate on the Mun. Realized that your resource harvester module does not accumulate or account for temperature. I think the drills patch should read. @PART[RadialDrill,MiniDrill] { !MODULE[ModuleOverheatDisplay]{} !MODULE[ModuleCoreHeat]{} @MODULE[ModuleResourceHarvester] { @name = WBIGoldStrikeDrill @GeneratesHeat = false !TemperatureModifier{} !ThermalEfficiency{} } @MODULE[ModuleAstroidDrill] { @Name = WBIGoldStrikeAsteroidDrill @GeneratesHeat = false !TemperatureModifier{} !ThermalEfficiency{} } MODULE { name = WBIEfficiencyMonitor efficiencyType = extractionModifier efficiencyGUIName = Extraction Rate } MODULE:NEEDS[BARIS] { name = ModuleQualityControl quality = 100 mtbf = 400 } } I made myself a temporary MM patch that does the !TemperatureModifier and !ThermalEfficiency and it seems to work as expected. Wonder if maybe that patch should also be more general to grab anything with ModuleResourceHarvester HarvesterType=0 and ModuleAsteroidDrill. That way it would also grab the surface drills from KPBS (and others).

I've been playing some No Man's Sky recently... I think what is missing is discovery. To me the best part about NMS is landing on a world and seeing what weirdness is going to come out. Maybe a little procedural generation would be a good thing. I'm into KSP something like 5k hours now, I've seen everything, I've been everywhere. I think the only way to deal with folks like me is have the game come up with subtle interesting things so each landing has that bit of the unknown. I'm not a fan of load up ship with every experiment you've unlocked and then hop biome to biome and run them all for the boat of science. Labs are better. Still kind of weird that you unlock technology with science points though, maybe game would make more sense if science -> money and you use cash to unlock parts (I saw that above). Or nodes unlock with cash and meeting some other condition. I think I saw that up above. Have science experiments chain into other ones. Discovered possible microbial life on Duna or Laythe? Better send a base to do on the spot science, find more samples, and maybe grow that stuff. I think the science itself maybe needs to be a game of its own and on top of that getting to new things drives the engineering of new vehicles. I think I'm kind of talking about combining the contracts and science system not unlike what some folks have done with contract configurator. This would also be a way to inject Making History type missions into Career mode.

You ran into the "Gravity Brakes" closer you are to a gravitational body (and the stronger that gravity) the slower you go. It is meant to make the warp drive more controllable and easier to use, less shooting past planets and having to feather the throttle. It's also meant to add a bit more danger to getting really close to Kerbol or Jool. Laythe + Jool is a pretty deep gravity well for the warp drive to work in so speeds are slow (and energy use high).

This is probably a side-effect of moving the entire physics bubble at once through space. This is what allowed the awesome warp speeds we currently have. The solution to this used to be that everything in the physics bubble except for the ship would explode. Then that function started causing null-refs and it didn't seem like it should have so... it was yanked out. Figure it's the warp drive warping space severely enough those other parts are dragged along with, surfing your wake, but only that which is inside the bubble is considered safe and predictable.

I had considered making exotic matter 0 on launch when I did my last overhaul. However, I realized there would be major support concerns with people not being able to get the warp drive activated - we have enough issues with the fail-safe altitude. So it is intended. To get the slider to appear one has to add some fields to the source code and recompile the plug-in, which I wasn't really into as there is really no advantage to setting the slider to zero. You can pretty easily make a module manager patch that would set the initial EM amount to zero and that would be my recommended course of action.

If you're making individual lander parts for lego like use... you're my hero. Your parts so far have been super high quality so I'm excited for these.

I think likely there are some major physics inaccuracies going on here. What is your physics tick time set at? You might be an edge case where you have an incredibly large/long vessel, with long burn times... does it wobble as you burn? Also are your engines burning directly ahead or are you angling your engines to get them to match your center of mass (including relying on gimbals to do it). You'll have delta-V correctional losses from that which could be adding up. 200m/s is a lot but you might have a bunch of little things and errors in the simulation adding up to a significant total sum.

https://github.com/helaeon/WarpDrive it's on my github, you'll need to use the green clone or download button, then use the For_Release folder in the zip it gives you similarly to any other mod zip you'd download (merge gamedata with gamedata). Though in this case I'd suggest deleting your existing USI Warpdrive folder first and dropping this one in new. I didn't move anything around but I did add some stuff and changed all the configs so good to start clean just in case.

I should have said something about this when I looked in the thread yesterday... Making it let you warp off the planet is a fairly trivial change to make... having it let you warp off the planet without mathematical weirdness... not going to happen. I made a lot of mathematical choices with the understanding I would never have to deal with certain altitudes (very low ones) in regards to the brakes. It's very very possible that even if you set the correct value to over-ride the fail safe that you wouldn't go anywhere... you might warp into the ground... or you might burn up in the atmosphere... but I do know I was dealing with the assumption that the failsafe was always there to prevent weirdness as orbit radius / planet radius approached 1, because as many powers and logs as I used... weird weird stuff should start happening.

I think the bubble guide being on by default in the vab and the effect in flight are both controlled in the plug-in. I think the warp effect and the color changing bubble is made using the plug-in. RD wrote all that before I was involved, just remembering what I thought I saw when scrolling through the code. Frankly I'm not totally sure what the bubble model in the part config references or creates in game (I think that might be the bubble guide for the VAB). I haven't broken it, see what doesn't work, then fixed it to know for sure.

How about putting your control parts inside a fairing so they really are inside the nose cone? If you really want to be cute about it you could eject the fairing when you get high enough and get some delta-v back due to reducing mass.

@TheKurgan All you need to do is balance the cfg to your liking. The USI 2.5m drive I believe has the values of all the default parameters in the dll. So if you don't specify one, the game will fallback to the one in the plug-in. Yes the TurboFactor is so if a speed of say 100c is too slow it can get cranked up to thousands of c so you're not sitting there for 45 minutes warping between stars (I was thinking about the 45 minute real time trek to Hutton Orbital at Alpha Centuri in Elite Dangerous). Turbo is also a way to deal with big systems but still have the speed be manageable. Neptune is a 90 minute trip at 1c in a real scale system. For scaled systems module manager multiplies the warpfactor and turbofactor by the scale of the system so that should be handled for you if you set your parameters up for a stock size system. Correct.

@TheKurgan In the soon to be released version (currently the dev version. latest of which is on my github https://github.com/helaeon/WarpDrive )... I made a few things configurable in the part.cfg for people wanting different behaviors from their Warp Drives. All of the maximum parameters of the warp drive would have to be based on the core part that uses USI_ModuleWarpEngine. However you could take @JadeOfMaar's advice and use converters and harvesters after altering the ISP of the engines so that you need the converters to not thrust limit. Though remember... if you run out of resources while warping bad things happen. This warp drive totally works more like the Frame Shift Drive in Elite Dangerous now - that's all for gameplay reasons rather than some theoretical thing about warping space that's already been warped by a gravitational body. Though that's what I'm saying for the physical reasoning it behaves this way. I have where the turbo kicks in and how much it multiplies WarpFactor user configurable in flight and the VAB. I did that because everyone plays a bit differently and I wanted flexibility. However, if mod authors that also use the USI Warp Module would like me to change that so it adds some differentiation between warp parts, I'm open to that. Code snippet below of USI_ModuleWarpEngine with some commenting MODULE { name = USI_ModuleWarpEngine WarpFactor = 6 // maximum warp - this sets your absolute top speed before turbo GravFactor = .95 // Gravity Strength (multiple of planetary radius where speed trends to zero.) Severity of Gravity Brake, this is the main factor that prevents blowing past/through planets between physics ticks. This and BrakeFalloff are the two levers that let you tune the behavior of the warp drive. BrakeFalloff = .85 // orbit radii to this power (smaller is stronger braking further away) Also helps stop from blowing past/through bodies between physics ticks. Note this has a big effect to limit maximum warp while in interplanetary space (go much slower near Eve's orbit than Jool's orbit) TurboMult = 1 // Increases overall turbo top speed, careful to not make it too large. (For re-scaled systems) minMaxSpeed = 0.001 //c no slower top speed than this (To prevent Laythe issues where reasonable gravity well, in a big gravity well. A Hot Jupiter would have the same problem.) deployAnimationName = Engage warpAnimationName = WarpField MinThrottle = 0.05 DisruptRange = 2000 BubbleSize = 20 MinAltitude = .5 // planetary radius * this. (Failsafe Altitude) //MaxAccelleration = 6 }

@gamerscircle To stick with the role playing thing... You'd have to set up some kind of warp relay in reality if you're wanting to do comms between star-systems. EM radiation is limited by speed of light concerns as well (so, you're looking at years between star systems. Even to Mars you're looking at a 20 minute delay, Neptune an hour and a half), so if you want comms you'll need FTL which means craft that sends a physical packet and that physical packet has its own warp drive or the beacons warp space between them (like the Mass Relays in Mass Effect). You'd have band width concerns between relays, then you'd use regular comms from beacon to ship. Other way would be with some kind of qbit entanglement thing but that would have even more limitations. You're looking at an all-new technology here regular comms aren't going to get it done. Warp ships between systems will have to be manned and they will be out of comms contact between systems, and systems likely not in contact with each other except when a warp thing shows up with data. We're talking like old-school mail delivery to bring the news.

@RoverDude I didn't make a scale up of the USI 2.5 to 3.75, but all the Z style scalings are in there including the 3.75.

@RoverDude Pull request sent. I didn't get to test this a whole whole lot. Did a few runs to Laythe, went to Tylo, back to Kerbin from Jool, and out to Eeloo. It seems pretty good. The change is pretty simple so I'm not concerned about it breaking anything. Of note for people who want to ModuleManager their .cfgs to make things to their liking. minMaxSpeed does allow you to disable the brakes; set it to a value just under where your turbo would kick in. Turbo will still kick in at the same point away from the primary gravitational body. I have a 3.75m in ZZZ's form-factor. The bubble is huge.

I think I'm okay with a minimum max speed being built in. It allows the brake falloff to be a bit more severe without making things too slow overall. I understand what you're saying. I think the main use cases would be getting too close to a star, jool, and laythe. Everywhere else the regular stuff works fine, so putting a floor on how much gravity defeats your ability to warp space should be okay. Plus it was easy to implement. That pop less so especially making it configurable for re-scaled systems.

Yep I was thinking of this https://www.xkcd.com/681/, but I have to exaggerate things a bit. Speed of light is fast. It would be fine if we didn't have to deal with physics ticks. Which in my case is every .06 seconds which at 1 c takes you 18,000 km. That's quite a long way in a system where an earth like planet is 2400 km across (this is blowing THROUGH objects not just past them. Game often doesn't even detect the collision and you can in no way react fast enough). Jool is 12000km across. you can go past it in one physics tick as well! I already made up a test DLL that has a minimum speed (configurable in the part config) seems to work alright. I kind of liked the fail-safe never really being reached because you just couldn't warp at that altitude, it was just too slow. But Laythe may make that impossible.

@Space KadetGood news... Gravity brakes are working as intended so nothing wrong with the plug-in... Bad news is I may have made them a bit too harsh for this one use case. More good news though is this is all fixable in the configs so if ya'll would help me with suggestions for values you think are good that would be greatly appreciated. I made the braking due to gravity wells additive so you didn't just blast past the other moons in the game. Plus thinking about it it's a gravity well sitting in a gravity well, it should be additive. Laythe is a special case where it has a fairly reasonable gravity well of its own and it's fairly deep in Jool's gravity well. You're still warping and you'll still be able to climb out of the well from failsafe, it'll just take a long time and a lot of exotic matter. I tested out at Tylo and thought it was fine... but didn't even think about Laythe. The two values we need to be concerned with are GravFactor and BrakeFalloff. I think the thing to do is mess with GravFactor as values of BrakeFalloff much different than what I have tends to have you blowing past planets because you don't start slowing down soon enough. Very small changes make a big deal in both of these values so don't increment by too much. It may also be an idea to reduce GravFactor but bring BrakeFalloff up a bit. I'm going to fiddle with these numbers a little bit and I'll give some new recommended values later. Once some new values are settled on I'll get them on Github and do a PR for the official repository. ETA: I just did a bunch of tests... GravFactor = .55 BrakeFalloff = .78, works nice for Laythe but isn't strong enough for anywhere else. I think I like the original values better for general use. I may make a modification to the plug-in so there is a minimum warp velocity. I'm thinking .0005c

@Space KadetI think you're getting bit by the gravity brake pretty severely, but it shouldn't be that bad at that altitude. It looks like you were running full-out long enough, but maybe not. Hard to say without your warp menu open. I know I need to run full out for a little while to escape a 350km orbit of Kerbin (I have my cutoff set to .25 in my personal game, so braking should be even less severe without that modification). You definitely have enough power and fuel. I'll give the current version a look again and try to replicate your situation when I'm on my KSP computer tonight assuming stock.

Both FFT and SSPXR have been all good for me so far. The auto-level landing cradles are pretty cool. I do kind of wish they had a bit of suspension for the initial landing - but understandably may not be possible. Or some kind of extendable stabilizer so they're a little less tip prone during said landing. I did a couple of 2 m/s landings on the Mun at 0-5 degree grades and it seemed super tippy, like surprisingly so. However I usually build landers with pretty wide bases so could be I wasn't used to one with a base the same size as the rest of the stack. Of course once you're down and you can turn on auto-level it works great. I added the USI ground tether function to them as well for my own game and that also works great.

If you're using FarFutureTechnologies, NearFutureElectrical, MKS, DSEV. It takes 25x stock electricity to warp, and 15x to make exotic matter. I wanted the warp drives to use more electricity than Nert's largest MPDT. You're going to need a large fission or a fusion reactor (which is the point). Battery powered warp drives should be fairly useless and dangerous unless you have millions of ec worth of storage. I'm not even sure if the capacitors from NFE can keep up (I don't use them personally so I don't know). I do use these mods myself and this is my intended electrical use... the stock values are for the purpose of making a truly stand-alone drive. The much higher values are the intended ones.