helaeon

With the way MKS/OKS/Karbonite/K+ work currently, it's possible if you do it right you may be funding your space program with it (as in sending goodies back to Kerbin for profit). Basically it may be another way to make funds outside of contracts. Which it should! For example efficiently selecting (probing) and mining an asteroid efficiently would be hugely profitable! Should be no different for Kerbals if they can over-come the challenges But, making a profit takes planning, skill, and often multiple launches to be in a place that you can do that.

I'd be unlikely to do much better than my post that RoverDude linked as to the hypothesized physics for an Alcubierre Drive. So for those interested read that. I was looking to explain the reasoning behind the alternate mode, if you entertain the possibility even if not convinced that's mission accomplished for me. Because... "hypothesis", nobody knows because frankly the whole idea could be pure fantasy. If it works it is beyond known physics and may behave in a way we would not predict or know until we turn one on. For all we know your orbital velocity upon turning off a warp drive would be zero because your velocity inside your warp bubble is zero. Or the drive would be impossible to turn off, so the whole thing would be moot because now you're some sort of tachyon forever. Until someone makes exotic matter or NASAs experiments into space warping show us something or aliens visit using one and share the knowledge we really don't know and they are all equally as correct. I think the thing you're missing from how this drive is supposed to work regardless of energy conversion is that your ship is staying still and space is effectively moving through itself using its shape to propel that flat spot. Whether that flat spot is disconnected from space time is part of the debate. Either way you're being pushed by space itself and that is providing the propulsion up, down, and around the gravity well. It would be like if the cement around your car liquefied and a wave of liquid cement pushed your island of regular cement to a new location. This analogy doesn't quite work, but it gives a good idea of the propulsion idea. Energy conservation could be obeyed in two ways (and hypothesis again) your raw speed has to change as you move in the gravity well otherwise you receive or lose potential energy; or your raw linear momentum stays constant and you do gain orbital energy & angular momentum based on your position in the gravity well. Total energy conservation here isn't possible, so it could be either because based on normal physics both are wrong. If you are not disconnected from space-time, your trajectory is altered by gravity as it would be for light. You effectively hit escape velocity for that gravity well, if you want to, as soon as you activate the drive. The trajectory shown in the map screen, regardless of conservation, is what your ship is going to do when you turn off the drive. You are propagating yourself through space itself just as light does. The way krakensbane works kind of turns every ship into an Alcubierre drive, and when using the function to move the ship, you're using krakensbane truly as an Alcubierre drive. I agree fully that linear momentum being conserved might be reality. Both RoverDude's original and KSPI's drive works about right if that's the case. The whole reason I proposed angular momentum conserving version was that everyone was using the linear momentum version and I wanted to try the other one. Linear momentum conservation is far simpler to code, I understand fully there. I wanted to see what the other way was like and thought others might want to as well. Then one could make their own choice of which side they fall on based on the reasoning they are most convinced by and which one seems more correct to them after using it. For me it all started when warping out to Jool from Kerbin and thinking "how... does my ship have this much energy suddenly?", then I looked into it and saw lots of disagreement. There are even more ideas of what might happen beyond these two thoughts. These are space toys for us to play with, the switch gives the player the choice to play with the toys as they want - you know the very reason we mod KSP in the first place and many of us alter the cfgs to suit our tastes. I knew this would be controversial with folks falling in both camps... so did both. I thought about putting the toggle in the cfg, but thought it was better from the player's perspective to choose in-game for those that aren't comfortable editing those files.

There are lots of good reasons, even outside of game-play why you'd want to not be warping in atmosphere for example: If you're using the upcoming momentum preserving option, that's the one that *might* cause a build up of gamma rays on the front of the bubble. Those would be interacting with the molecules in the atmosphere for extra bad times. Even without the gamma radiation the effects of warping space time like that in a dense collection of atoms and molecules is completely unknown. You'd hope that you wouldn't cause fusion, but the Sun is also a powerful warping of space time, as are black holes and neutron stars. The classic velocity version, you pop out of space time so you take all of that atmospheric material with you. Which would upon reaching space expand on PV=nRT rules. That may also not be fun. Yeah so warping in atmo is a bad plan. That min-altitude value is the multiple of the planetary radius. Personally I am using .5 so I have to be 1/2 planetary radius away, so kerbin is 300km, .25 would be 150km, .125 would be 75km. It looks like atmospheres start at about that .125 value. So, that would probably be a safer one to use if you want to run the drive as long as you're in space. This is just advice for your own personal config (which you can do whatever you want with). I wouldn't expect the behavior to change much for the main line mod. Pro-tip: Generally I like to avoid using zero as a value in configs unless it's known that's an okay value to use when I'm modifying them without knowledge of the underlying code to prevent division by zero errors. Or, I know that if I use zero, that it may introduce weirdness and crashes.

My suspects would be KJR and Tweakscale. I've been avoiding Tweakscale for all of .90 myself. Its a great mod, and I wish I could have it back but there has been funkiness with it. I gave it a spin in .90 and I do periodically and it's... unpredictable. Even when you don't use it on a given ship. KJR just in the nature of how it works (again great mod, I was using it myself up until a little while ago) can cause some funkiness. It really isn't super necessary unless you are running RSS or one of the other mods that makes your solar system and bodies much larger.

Form follows function. Function follows form. It looks as it needs to look and if I did a good job designing it will be elegant. This is what we learn from biology & biochemistry.

http://ocw.mit.edu/index.htm You know if you want the notes, power-points, and often times lecture videos from MIT's courses on the subjects. Though that XKCD comic is absolutely true. I've taken high end college level physics courses, my degree is in biochemistry, I've been interested in space flight all my life... and I've learned way more playing KSP than I ever did in school. Though I do think my background has helped me quite a bit.

Yes, or dock and undock. It seems the "parent" ship is not affected only the child. In the case of my little Duna flier it was affected and the base was not. But that's also the ship that stopped exhibiting the error for the reason I couldn't figure out. My space station around Minmus that I haven't used in a very long time was exhibiting the error, I did use the KAS fuel pipe on it once a very long time ago. My remote drills were also exhibiting the behavior and those were never connected via KAS just docking ports when I landed the stack of them. Though I did stick a RTG to them via KAS. Thanks for looking into it.

I think I may have found something broken. It looks like it is in all mechjeb dev versions going back to the addition of the arrows. I get this error spammed in my log on a craft that has ever been part of a docking-undocking. But not the ones that never have been. Decoupled doesn't do it. Disconnecting fuel pipes via KAS does. All of the arrows are disabled in my Attitude Adjustment window. I toggled them on and off just to make sure. I completely unloaded mechjeb and reset everything to defaults re-loaded and re-saved with no mechjeb and error is still there. It does not seem to happen if the craft is re-united. [Error]: MechJeb module MechJebModuleDebugArrows threw an exception in OnUpdate: System.NullReferenceException: Object reference not set to an instance of an object at MuMech.MechJebModuleDebugArrows.OnUpdate () [0x00000] in <filename unknown>:0 at MuMech.MechJebCore.Update () [0x00000] in <filename unknown>:0 That's spammed pretty heavily. Quicksaving and reloading after undocking doesn't cause it to stop. Weird thing in testing this on varioius vessels in order to narrow down precisely what I saw in common the first vessel I noticed it with stopped exhibiting the behavior and I don't know why. Here is a fat output_log for you where I was switching between the various vessels trying to see which ones would throw the exception https://www.dropbox.com/s/ncyjz07iz03oxyl/output_log.txt?dl=0

I've been playing with the efficiency by altering the ISP value. atmosphereCurve { key = 0 12500 key = 1 10 } Change that key = 0 to whatever you like. There's your space ISP. Myself, I don't want it as inefficient as before the 15c change, but I think it's way too efficient right now. Pre higher speed it took nearly all the ExoticMatter to get to Jool. I haven't had much time to test it though, my little test flight to the Mun seemed like it used a lot. If you come up with some good and fair numbers share please

Game pad so don't fly with keyboard. Whether I roll or turn right depends on the design of the rocket. I've found it is actually easier if you rotate the rocket in the VAB or right upon liftoff to have less inclination off of zero if you're pitching up-down like an aircraft rather than left-right. I nearly always do a near suicide burn to land, and I come in really shallow, so my suicide burn is always a little off of full retrograde so I can land where I want. No "mode" for controls. My docking controls are programmed into my gamepad (D-pad for up, down, left, right, stick click for forward and back).

You can repair them by editing the save file, so you kinda have to role-play it. Search for the name of your vessel, then "BROKEN" for the solar panels and change the broken to "RETRACTED" If you make a quicksave and edit that, then reload from quicksave then you don't have to unload & re-load kerbal. When you fix wheels and landing legs the game is effectively doing the same thing in-engine. But it seems like solar panels should need some kind of materials. The new evolution of KAS (KIS, which looks like it will be out shortly) might add that function, or they might want to by letting you take up a solar panel repair kit and repair with that.

I've been hoping that the secret project was stock clouds with Rbray89... I was hoping that was the cause for his disappearance. Hope he's doing okay.

I have quite a few mods, but recognize it's up to me to see what's going on help out where I can and figure out what's broken and why. So... I have very few problems as I stomp them as they arrive and they don't remain for long. DX9 is terrible though, I've been running in openGL for 3 versions now. I can usually play for several hours before the memory leak creeps in as a problem (yes there is a play-time limiting memory leak). ATM for me seems to make things worse and I'm better off in openGL using DDS4Win carefully and DDS loader.

DX9 for me behaves fairly poorly. in my steam launcher options I use -force-opengl -popupwindow That way it goes into borderless window mode and no problems. Looks different than DX9 but uses way way less memory. Shadow problems are with DX11.

It's the 3,483,184kb being used by KSP and the log you posted showing zero memory available (though that can happen other ways). So, one of those mods might have a memory leak because you're right there aren't a lot of part mods there. Though the DX9 mode seems to be pretty memory inefficient. Maybe try -force-opengl? Scansat 9 not 10? That might be causing problems if you're on the current Karbonite. http://forum.kerbalspaceprogram.com/threads/80369-0-90-SCANsat-v10-0-Real-Scanning-Real-Science-at-Warp-Speed!-Jan-29

I had the same issue as Van Disaster. I flat turned the reflections off using the in-game gui. I like the reflections but not so in love with them that I wanted to track down exactly which CFG (or many) were doing it.

You're at memory cap. You can only address about 3.5 GB for KSP, the other 12.5 GB can be used by windows and other programs, but not KSP. You have too many mods installed. Karbonite is probably the mod that pushed you over the top. You probably need to use -force-openGL (how to do this is all over the forums), Active Texture Management, DDS4Win & DDSLoader, and/or TextureReplacer (which also has some memory management fixes). One of these might do it, or you might need to use all 3. Personally I'm using -force-openGL and TextureReplacer. Textures are the main thing that eats up memory fast. RoverDude's mods are pretty extensive but really efficient for all you get out of them. Some modders use textures that are way too large. You can reduce their size by half and have no visual hit (this is part of what ATM does, and you can have DDS4WIN do) Mods like ScienceAlert don't use much memory because they are mostly doing calculations and telling the engine to do things (unless there is a memory leak, I use that one myself and there isn't one there I can tell). Parts mods are usually the memory eaters.

I think that may be somewhat likely considering the recent changes to Karbonite & Regolith. Though, they didn't come along without some backlash so who knows.

Only reason not in the top tier is I've been working on the alternate mode of RoverDude's Warp Drive rather than plotting an Eve landing and return mission. It's my last major thing to do in KSP. I'm kinda waiting for 1.0 aero. I'm running with FAR but with the new engine behavior and such, I think I'll wait. I think I should be able to have that last .4 for contributing to a mod

Considering the OP's picture they should be on base 8... which actually has some interesting physics implications. I remember when I was in physical chemistry that sometimes the best way to solve certain equations was to do everything in base 8 rather than base 10. What those things were I do not remember. A lot of things we did in physical chemistry we did to show we could rather than it being incredibly important, or to prove the real truth of something over the convenient simple lies we were told in earlier classes. This would have some computing implications as well, as Oct is a good alternative to Hex. The computing implications are all based on powers of two and some physics necessities for organizing memory and storage efficiently. Base 8 math naturally comes out of it. A base 8 system would serve kerbals very, very well.

It's necessary to return to Kerbin to refuel the Xenon. The way my warpship is set up the Xenon gas is the only limit on my total warp distance. Ec doesn't reduce at all during warp drive, Exotic Matter limits my single trip distance and the power limits how quickly I can warp again, but Xenon limits the distance until I need to either visit a base or Kerbin to get more. LH2 most of us use for our primary fuel anyway so we're packing a lot of it. Though if I were to author a Module Manager module for you guys I'd have it use A LOT of LH2 to stay with RoverDude's wishes so it would greatly limit your overall non-warp Delta-V. Since the 15c and krakensbane translation changes it might actually be necessary to increase the consumption of exotic matter and xenon, because our fuel efficiency went way way up.

TL;DR for Vanamode's awesome post: Orbit is not really getting up high though that is often part of it to get outside of an atmosphere so no drag (aerobraking) or to avoid hitting terrain (lithobraking). The key is going sideways fast, I suggest east so the rotation of the planet helps you. For Kerbin, you need to reach about 2300 m/s at 70 km or higher. https://www.youtube.com/watch?v=DPlbDEI63B4 (Newton's Cannon)

Changes on Alcubierre you already had as I was implementing those in the experimental version as they came out. There have been changes to Regolith and MKS/OKS. Not a ton on anything else. RoverDude supports KSP-AVC so if you install that it will tell you where you're at as far as updates go.

Done. Kinda made a mess as I copy and pasted the whole file out of Xamarin to make sure I didn't miss anything, I did have all of the previous changes imported. Still getting an error on drive activation with destroy nearby vessels. I ran an actual mission with this build with no other problems so should be good to go. Make sure you give a shout out to Serino in the credits. His help was absolutely invaluable.

How about creating a field that changes the way the matter making up the ship interacts with the Higgs field? Mass is essentially how viscous the Higgs field is in relation to a given particle. So... what if you made it less so. Make the particles that make up your ship blind to the Higgs field (really the other way around so Higgs field doesn't recognize the particles on the ship). Kind of like a photon which doesn't interact with the Higgs field (or if it does so only incredibly weakly).