The Pink Ranger

Exact same problem here. Running Winblows 8.1.

Yah. If he isn't behind this upcoming aero update then there's something wrong with their hiring process

+1 for CKAN

Having a similar problem. If I write this: @PART [*]:Final { @RESOURCE [*] { @amount *= 5 @maxAmount *= 5 } } It only seems to affect the first resource in each part. However if I punch in each resource individually like this: @PART [*]:Final { @RESOURCE[LiquidFuel] { @amount *= 5 @maxAmount *= 5 } @RESOURCE[Oxidizer] { @amount *= 5 @maxAmount *= 5 } @RESOURCE[SolidFuel] { @amount *= 5 @maxAmount *= 5 } ... etc ... etc ... etc ... } Then it works fine.

LOL! Wow! I wish module manager had a way to check syntax hahahaha! Hopefully that works Anyway I'm not familiar with dimonnomid's work but I think it might be fairly simple to write a short patch that allows almost any parts mod to work with RSS/10x Kerbol. What I'm thinking is as follows: 1.) As per your calculations simply divide the mass of all parts containing engine and engineFX modules by about 6 2.) Also as per your calculations divide the masses of all parts not containing said engine modules by about 4 3.) As per TChapman500's calculations divide all stock resource densities by about 5 in order to bring them acceptably close to real equivalents (if other mods balance their resources around stock values then I'm thinking this blanket patch will bring them in line with the scale of RSS with minimal issues.) 4.) Not sure if this last one is necessary but no harm in testing it out: Multiply all stock tank volumes by about 5 ------------ The other thing I'm currently trying is this: Stock KSP balances around smaller scale planets by increasing everything's density. I'd like to see what happens when I tone the density of all parts down to realistic values and then balance them for the smaller scale planets by reducing thrust instead of increasing mass. I have a feeling that a lot of the strange behavior in KSP can be chalked up to everything having insane amounts of inertia. So basically all I'm doing is implementing all of the pseudo realistic changes above and then dividing thrust for all engines by the same factor I divided their mass by. Then I'll further tweak by relating the TWR of a certain size of rocket to its dV. So far I've got all of this done except the resource multiplier.

Okay so if I just adjust the resource densities to real world figures (as I've already done) then that should be enough to bring the stored energy somewhat in line with real world figures? The only reason the *5 multiplier is necessary for converting stock tanks to real fuels is because real fuels pretty much just changes the units right? Density part of the patch: // Squad Resource Definition Densities @RESOURCE_DEFINITION[LiquidFuel] // assume kerosene { @density = 0.000915 } @RESOURCE_DEFINITION[Oxidizer] // assume liquid oxygen { @density = 0.001141 } @RESOURCE_DEFINITION[SolidFuel] { @density = 0.00175 } @RESOURCE_DEFINITION[MonoPropellant] // assume hydrazine { @density = 0.001021 } //@RESOURCE_DEFINITION[XenonGas] //{ //@density = ??? //} Anyway even if my original intent doesn't make sense conceptually what can I do to get the resource changes to work (for future reference)? I tried splitting them up as follows and despite that module manager reports no errors on load it still doesn't work. @PART [*]:HAS[@RESOURCE[LiquidFuel]]:Final { @RESOURCE[LiquidFuel] { @amount *= 5 @maxAmount *= 5 } } @PART [*]:HAS[@RESOURCE[Oxidizer]]:Final { @RESOURCE[Oxidizer] { @amount *= 5 @maxAmount *= 5 } } ...... and so on and so forth for the others

Hey fellas. I'm trying to make a universal patch to make everything compatible with RSS without using MFT or Real Fuels. Trying to multiply LiquidFuel and Oxidizer amounts and maxamounts by 5 and this is what I have copy and pasted from my cfg file: @PART [*]:HAS[@RESOURCE[LiquidFuel|Oxidizer|SolidFuel|Monopropellant|XenonGas]] { @RESOURCE[LiquidFuel] { @amount *= 5 @maxAmount *= 5 } @RESOURCE[Oxidizer] { @amount *= 5 @maxAmount *= 5 } // What multipliers to use for the following? @RESOURCE[SolidFuel] { @amount *= 1 @maxAmount *= 1 } @RESOURCE[MonoPropellant] { @amount *= 1 @maxAmount *= 1 } @RESOURCE[XenonGas] { @amount *= 1 @maxAmount *= 1 } } Doesn't work. Can anyone tell me what I'm doing wrong here? Thanks. Edit: Caught the missing bracket. Still doesn't work.

Any chance you'll put this on CKAN?

Seems to be working alright. I installed manually and didn't extract the relevant files to KSP's root folder. Thanks for the help.

Alrighty here you go: output_log.txt Thanks!

Anyone else having issues seeing the main config screen? When I click the controller icon all i get is this:

Hey can someone tell me what data mechjeb uses to launch into the plane of a target? I'm trying to make a custom window so that I can do it manually but I'm not sure what data I should be looking at. Should be the target's longitude of the ascending node right? I'm looking at this diagram and I'm guessing that the "Target LAN" field uses the direction from the center of the body you're on to your position over that body as the reference direction? I'm guessing I need to launch when "Target LAN" says either 0 or 180. Am I on the right track or do I have this totally wrong? edit: I know that AN and DN work for bodies within the same SOI but they don't work when you're trying to launch into the plane of another planet. The autopilot seems to handle it just fine though so I'm wondering what data it's going off of. edit 2: Okay well I'm still not sure what the reference direction is but after messing around for a bit it seems that my craft always crosses the target's plane when LAN = targetLAN +/- 90deg. Not sure but it looks like the reference direction for a planetary SOI is the parent planet's prograde direction on its orbit?

Okay thanks guys. I'd like to learn C# eventually but I'm really just trying to sharpen up my C++ skills while doing something fun in the process. Too bad because modding KSP looks like a lot of fun. Anyway thanks for being helpful, wasn't expecting it haha.

Hey fellas the only experience I have with programming is a single semester of basic C++. Anyway I'm basically trying to find ways to merge work and play and was wondering if it's at all possible to write a plugin for KSP in C++. Thanks.

Pretty cool man. Any plans for a cargo bay?

The "pitchGimbalRange" value represents how far off of the default thrust axis the engines can vector in either direction right? Say if the big bang engine defaults to about 30 degrees off the center line of the spacecraft and I set "pitchGimbalRange" to 30 the engines should have enough range to thrust directly through the center line of the craft right? I'm trying to make a massive Energia style rocket with the payload strapped to the side but the engines don't seem to be able to vector far enough to work properly. It basically does somersaults off the pad every time. Edit: Ooookaaaay didn't work. Any way to get the engines to straighten out more?

Any takers?

Hey Fractal I'm sure you've already been keeping up with Dr. White's talks but in case you haven't I found a pretty interesting bit of info on how warp drive might work. According to Dr. White the warp bubble has no sense of direction so you need to use conventional propulsion to give your spacecraft an initial velocity in the direction you want to warp. Then when you activate the warp bubble space starts "piling up" in the appropriate orientation. So in terms of KSP the warp effect should happen in the direction of your prograde vector regardless of how your ship is oriented. Might add a little more challenge to the endgame since you'd still need to get your inclination right before warping, and also mid course corrections would consume lots of fuel. He talks about this at 50:25

Hey just wondering how tweakscale works. If I use module manager to change a part's mass will tweakscale scale off of that modified mass or is everything pre-set?

Yea I'm tired of politicians with no spine. All they care about is trading favors so they can retire with their fat lobbyist paycheck. It's pretty disgusting really. Feels bad man.

Hey so if I'm using FAR and facing prograde as I approach a planet for aerobraking will the program assume that I'll be facing prograde the whole way around the predicted trajectory?

You mean it's only more stable because it's running within 32 bit constraints? As in there's no benefit so may as well go back to 32 bit?

Has anyone watched this yet? According to Dr. White (in regards to warp drive) the warp bubble has no sense of direction so you need to use more conventional propulsion to give your spacecraft an initial velocity in the direction you want to warp. Then when you activate the warp bubble space starts "piling up" in the appropriate orientation. So basically in terms of KSP the warp effect should happen in the direction of your prograde vector regardless of how your ship is oriented. He talks about this at 50:25

The last time I tried it (not recently) I didn't get any crashes in x64 when I forced opengl on it.

So THIS is where my performance issues were coming from. Thanks for the update!