Entropius

So… does anybody know exactly how much RAM the new B9 will consume relative to the old one? I ask because I've since realized my recent crashing on scene-changes is due to a memory error, and I was curious if B9 is going to be an option for me in the future.

When I go to launch at the launchpad or runway, there's a significantly high chance (≈25%) that KSP will freeze on the black loading screen. When I check player.log I see many mentions of ScanSat. I'm curious if this means ScanSat is the cause of it freezing, and if not, could somebody help me figure out what is? A couple Player.log files are available here.

Although I think some touching-up via photoshop was involved. I seem to recall such an admission in the Reddit thread where I saw that originally posted.

Regarding the previously discussed issue of the HUD monitor drawing the HUD to have the same color as the background on MacOS / OpenGL, I confirmed this is not caused by any-mod interaction. It occurs if RPM is the only mod (besides Module Manager, which is a dependency).

Other mods seem to have png textures without any issue. Environmental visual enhancements for one. Besides, other RPM displays have PNGs with alpha (like the RPM navball). Frankly, if OpenGL couldn't handle PNG's with alpha, a whole lot more would appear to be broken. So I doubt this is the explanation.

I'm on a Mac, so consequently my only rendering option is OpenGL. So this makes sense. I assume Linux also uses OpenGL. So effectively that HUD display would be a Windows-only feature (?)

I think I found another camera bug, but this time it regards the AeroCam and AeroCam180. It seems that RPM's external camera screen can use those 2 cameras….until you use HullCam VDS's camera view (like using an action group that invokes "Next Camera"). Once HullCam VDS's camera view gets used, RPM can no longer see anything but a gray screen. It should be noted this gray screen is affected by external lighting, as moving the ship changes the shade of gray. RPM's zoom also slightly changes the gray. It's almost like RPM gets forced to look at an extremely close gray wall. Once this problem occurs, revert to launch/assembly will NOT restore RPM's ability to view AeroCams. Only restarting KSP seems to fix it. The KerbPro and Science Cam are apparently unaffected by this bug. Any ideas on what's causing this? EDIT: Okay so restarting KSP isn't necessary, there's a workaround. The problem only occurs if you leave your external view on a HCV camera when you go into IVA. But if you first change your external view from HCV to just a plain old external view (chase/free/orbital) view, then RPM can use the aerocams again.

Yay, I found the correct value for the KerbPro camera. The line: rotateCamera = -90,0,90 should instead be: rotateCamera = -90,0,180 Assumably this change should be added to RPM in its next update (or is there a reason for the former value?).

I'm probably going to have to try to fix the camera via cfg-editing actually, simply rotating the part in the build-editor is problematic because then if I try to look through the camera itself (rather than use RPM), then that view will be wrong by 90-degrees. It would be ideal to get both methods of using the camera correct at the same time. Thanks.

I forget what command module I was in at the time, but it doesn't really matter since it appears to affect them all: stock, B9, Taurus HCV, etc. Maybe if I have time to waste later on I'll try narrowing down my list of mods to identify a culprit, but I'm really not looking forward to such a project. I also noticed the KerbPro camera from the Hull Cam mod gets it's camera view in RPM rotated by 90 degrees from what it should be.

It looks like I installed it correctly… I think. http://i.imgur.com/oAL1fJf.png Also, upon closer inspection I noticed if I move the craft around, one of the prograde markers will move, and as it moves, it appears that some invisible shapes partially obscure the prograde-marker. If I move them around enough I can see the shapes match those HUD elements in your screenshot. So it's like they're being rendered… but they have the same color as the background.

I'm new to RPM, and I toyed around with it but I'm having some issues. 1. I understood (possibly misunderstood?) that there's a way to configure an external camera view through a docking port, as in, it gives cameras to docking ports… is that the case? If so, how do I view it? 2. What is this monitor supposed to be showing me? Why are there 2 prograde symbols? http://i.imgur.com/ovRL4Uk.png edit: nevermind about #1, I figured out the docking cam. Apparently setting the part to control from must be done inside of RPM, not externally. Still curious about #2 though.

Thanks Master Tao. I know enough to delete configs, but not make my own, specifically I never learned the syntax for the first 2 lines. I should note though that the code you gave actually nerfs my engines further (quarter thrust) but I fixed that by tweaking the thrust multiplier from 0.5 to 2.0: @PART[B9_Engine_V?1]:AFTER[FerramAerospaceResearch]:NEEDS[!AJE]{ @MODULE[ModuleEngines*] { @maxThrust *= 2.0 } }

I think it all comes down to what assumptions you make regarding hidden internal components. Do the VTOL vectoring engines (1) all connect to a single internal engine or (2) connect to their own individual internal engine. If it's the latter, than the thrust scaling up with the addition of each engine part is justifiable. At a certain point you run into absurd situations where internal components should leave no room for fuel (but then again the same is true of stock engines). It was actually an 18 ton aircraft, but who's to stay I can't assume I've got 2 hidden Pegasus engines in the fuselage? Yeah, I get all that. And it makes sense with most forward-thrusting jet engines, as they continue to fly, just differently. The thrust-nerf is justified in 90% of cases. I'm just pointing that the negative consequences for VTOLs were significantly greater. In the end it may not be worth bending over backwards to avoid breaking VTOLs, but I didn't see any mention of this issue, so I thought it merited at least a mention. It's a tough call to balance this, I dunno. One recommendation I might make is if you keep the nerf, maybe put it in it's own separate config file (with an obvious name like thrustnerf.cfg). Then if people don't like it, they can just delete that entire file safely, rather than looking for specific lines within FerramAerospaceResearch.cfg (and possibly breaking something). I know Interstellar puts its nerfs to engines in separate configs like that (b9aero.cfg and rapier.cfg).

By this logic the stock jet engines shouldn't be even as powerful as the nerf allows them to be because their engine sizes are unrealistically short. Most real jet engines are several times longer inside the fuselage than the section you can see that's externally visible. I think in KSP there's an implicit assumption that there's more engine hidden away in whatever fuselage or pylon they're attached to. We could assume the same of the B9 VTOLs, that the bulk of the engine is internal somewhere and the visible part is just vectoring the thrust. So if we go with the assumption there's internally hidden engine components (as we do with stock engines), it becomes easier to justify the numbers. The real life Pegasus 11 Mk 107 offers 110 kN of thrust. Also, there's something to be said for being "too realistic". I think this is one of those cases where too much realism just gets in the way of the game being enjoyable, like a RSS-sized Kerbin would be.

I know FAR nerfed the thrust of engines to accommodate other drag changes, but is there a way to omit the nerf to the B9 VTOL Jet engine? That thing really does need it's original thrust, even at sea level, otherwise it's entire purpose is defeated, you know, taking off vertically.

edit: Never mind, managed to fix the problem myself.

@LuciferWolfgang: I'm guessing you installed it as: /Kerbal Space Program/GameData/TacFuelBalancer/ You want to install it as: /Kerbal Space Program/GameData/ThunderAerospace/TacFuelBalancer/

Yeah, but the thing was that the "-" button wasn't doing anything to begin with, so getting to the Edit button was impossible. It really was broken. But it's moot now because whatever you did in your latest update seems to have fixed it. So that's good news. The other issue about window resizing is still there though. Like Master Tao, I too am on Mac OS 10.9.4, so this may be a platform specific bug. Again, single clicks do succeed in resizing the window by 1 pixel. So if you want to resize it 5 pixels to the right, click 5 times on the right side of the resize-indicator. Here's my Player.log.

I had this problem too. Additionally, it also caused another issue: When I hit the ESC key, the window that usually appears pops up appears normally except it didn't pause the game the way it usually does.

The new 1.0 version is nice. Glad to see it can be partless (or not) as an option now.

How do you edit fuel on the launch pad? I've pressed every button in the GUI I could find, and can't figure it out. EDIT: Also, it seems there's a resize-thingy in the bottom-right of the window, but it doesn't resize via dragging. Dragging only makes it move the window. A single click (no drag) does seem to resize it by one-pixal's distance though. EDIT 2: Also getting a lot of errors. http://i.imgur.com/oudaDjo.jpg

Is there any chance that you'd ever increase the impact tolerance of these trusses to be on-par with the stock girders?

Isn't preventing them from exploding sort of what they already supposed to do? (or did an update break that or something?) Anyway, I was personally never a fan of the KSPI engine-overheating "feature" that manufactured the need for precoolers. In fact, I made a point of editing that out of my installs. The precoolers only work with a directly attached intake, which didn't mesh well with my B9 radial intake placement.

While I technically could do that, it's even more inconvenient than what I'm currently doing (letting KAC halt the warp, and manually resuming it till my kOS script halts it). I swap back and forth a bunch between manual control and my kOS auto-node script. I was a bit much to expect, but I thought it was worth asking anyway. On an unrelated note, does anybody know the proper units for engine fuel flow? The documentation doesn't seem to know, and speculates it's liters/second, but I'm not sure that would be useful. But on the other hand if it were in mass/second (metric tons/sec?), you could actually use it in the Tsiolkovsky rocket equation.