jefferyharrell

For what it's worth, fission reactors behave the same way. They produce xenon, which has nowhere to go unless you have an empty or partially empty xenon tank on your spacecraft. In order for the reactor to produce electricity you have to toggle it to dump xenon. I had to figure this out through a few minutes of not-especially-fun trial and error. I'm okay with that being the default behavior, but maybe there's some way to fit a message into the PAW saying the part is inactive because there's no place for its products to go?

There are dozens of us! Dozens! No but seriously, I am that player. JNSQ has revitalized an interest in playing with KSP that had lain dormant for years. Thank you so, so much.

Yeah, that's what I keep intending to do. The thing that's stopped me so far is that I know some mods are quite internally convoluted, with different parts sharing models or textures or whatever. Maybe BDB is very clean inside and you can just delete the stuff you don't intend to use; I haven't looked because I keep telling myself eh, a five- or six-minute load time isn't the worst thing in the world. Then I'm sitting there for five or six minutes and hating my life.

@Spike88 Man, I have such a love-hate relationship with Blue Dog. It's an amazing bit of work, let's be clear about that. But it's so damn heavy. It's probably responsible for half my 5-minute loading time. To answer your question, I haven't tried any of the historical kit-rockets. I mostly have the mod installed for the terrific antenna and SRB parts, plus some engines. The GEM-a-like strap-on SRBs in particular are just so very useful to get that extra .2 or .3 liftoff TWR. I keep telling myself I'll edit the mod down to just the parts I want to use, but I keep not investing the time.

I had a pseudo-career game going (meaning it was technically "career mode" but screw the grind so I used Career Manager), but I ended up with terrible crashing problems that I couldn't seem to understand. I've gone back to good old familiar sandbox play.

I'm not one of the developers but I've been playing with JNSQ since it came out. For my part, I've found that you don't need any different engines than what the stock game provides. JNSQ seems to be very well balanced against the stock game's tank sizes and mass ratios, engine TWRs and all that. Of course, I still want more engines, so I play with a bunch of part-oriented mods. All the Near Future mods, especially Near Future Launch Vehicles which has a 1000 kN, 300-ish s sea-level engine that's so good I'd almost go so far as to call cheating. I also use Cryo Engines and Blue Dog (despite Blue Dog being a monster of a mod that includes roughly 3 to 4 million parts I'll never use).

@N70 Excellent, thank you so much.

@Gordon Dry It looks like we're both kinda right. The source code download does appear to contain the compiled mod, but it's also got all the source code in it.

@N70 Amusingly, the 3.0 release on Github (https://github.com/Kerbalism/Kerbalism/releases) shows only the source code downloadables, not the actual objects. Since you just made your post like a minute ago I'm assuming this is something that'll sort itself out, but just in case I thought you'd like to know.

@Steven Mading Yup, makes perfect sense. Thanks for the quick response.

I have a wacky request: Would it be possible to add the ability to open a kOS window in, say, the Space Center or Tracking Station scenes? I'm asking because lately I've been having fun making kOS talk to Kerbal Alarm Clock. For instance, it's pretty trivial to write a script that takes a target orbit inclination and longitude of the ascending node and kicks out a KAC alarm for the launch window corresponding to that target orbit. The way kOS works makes this slightly awkward, though, since I have to roll a vehicle out to the launch pad, run the script, then recover the vessel. I could have my script time warp to the launch opportunity from the pad, but sometimes I want to just set up a series of alarms and go do other things while in-game time passes. I know the central conceit of kOS is that you're actually talking to a computer that's physically on the vehicle. But at the same time, there's this idea of the "archive" volume which notionally exists "on the mainframe" at the space center. It's not that much of a leap to imagine having a terminal connected directly to that mainframe. I know this is a big ask. I haven't looked at the source code but I'd guess that kOS is set up to run as a PartModule, which obviously only exists when there's a vessel loaded. It might not even be possible to make it work in anything other than the flight scene, but I thought I'd ask. I sincerely apologize if this has been asked before. There's 37 pages here, and I confess I didn't read every word of every page.

@Tyko As promised, here's my brighter-sun MM patch: @Kopernicus:AFTER[JNSQ] { @Body[Sun] { @ScaledVersion { @Light { !ScaledIntensityCurve {} ScaledIntensityCurve { key = 0 2 0 0 key = 1500000 2 0 -1.92E-07 key = 3000000 1.8 -9.62E-08 -9.62E-08 key = 6000000 1.6 -4.81E-08 -4.81E-08 key = 12000000 1.4 -2.40E-08 -2.40E-08 key = 24000000 1.2 -1.20E-08 -1.20E-08 key = 48000000 1 -6.01E-09 -6.01E-09 key = 96000000 0.8 -3.01E-09 -3.01E-09 key = 192000000 0.6 -1.50E-09 -1.50E-09 key = 384000000 0.4 -7.51E-10 -7.51E-10 key = 768000000 0.2 -3.76E-10 -3.76E-10 key = 1536000000 0 -1.88E-10 0 } !IntensityCurve {} IntensityCurve { key = 0 2 0 0 key = 9000000000 2 0 -3.21E-11 key = 18000000000 1.8 -1.60E-11 -1.60E-11 key = 36000000000 1.6 -8.01E-12 -8.01E-12 key = 72000000000 1.4 -4.01E-12 -4.01E-12 key = 144000000000 1.2 -2.00E-12 -2.00E-12 key = 288000000000 1 -1.00E-12 -1.00E-12 key = 576000000000 0.8 -5.01E-13 -5.01E-13 key = 1152000000000 0.6 -2.50E-13 -2.50E-13 key = 2304000000000 0.4 -1.25E-13 -1.25E-13 key = 4608000000000 0.2 -6.26E-14 -6.26E-14 key = 9216000000000 0 -3.13E-14 0 } !IVAIntensityCurve {} IVAIntensityCurve { key = 0 1.8 0 0 key = 9000000000 1.8 0 -2.89E-11 key = 18000000000 1.62 -1.44E-11 -1.44E-11 key = 36000000000 1.44 -7.21E-12 -7.21E-12 key = 72000000000 1.26 -3.61E-12 -3.61E-12 key = 144000000000 1.08 -1.80E-12 -1.80E-12 key = 288000000000 0.9 -9.02E-13 -9.02E-13 key = 576000000000 0.72 -4.51E-13 -4.51E-13 key = 1152000000000 0.54 -2.25E-13 -2.25E-13 key = 2304000000000 0.36 -1.13E-13 -1.13E-13 key = 4608000000000 0.18 -5.64E-14 -5.64E-14 key = 9216000000000 0 -2.82E-14 0 } } } } }

@Tyko I had to do some math, following Bob's instructions. If I can remember, I'll post the whole config file for you a bit later. It's quite short. Note that in those screen shots I'm also using KS3P with the ACES color grade preset. It's not everybody's cup of tea, but I'm a sucker for high contrast and color saturation.

Yesterday I asked about making a Module Manager patch that would increase the brightness of the sunlight. I was successful. Here are a couple of screenshots. Reasonable people can disagree about whether they like the "hotter" look, but I do. Thanks a million for helping me achieve it. EDIT: Just one more quick picture, this time of the launch of a vehicle that'll take a SCANsat satellite up into a polar orbit. I really like the lighting in this one. It's a bit later in the day.

I have two questions. First, I happened to look at my game log file and saw a great many errors that look like this: [LOG 09:58:20.881] [OD] ERROR: getting pixelFloatD with unloaded map Moho_heightmap (G) for Moho of path JNSQ/JNSQ_Textures/PluginData/Moho_heightmap.dds, autoload = True [LOG 09:58:21.034] [OD] ---> Map Moho_heightmap (G) for Moho enabling self. Path = JNSQ/JNSQ_Textures/PluginData/Moho_heightmap.dds [LOG 09:58:21.035] [OD] ERROR: getting pixelFloatD with unloaded map Moho_heightmap (G) for Moho of path JNSQ/JNSQ_Textures/PluginData/Moho_heightmap.dds, autoload = True [LOG 09:58:21.190] [OD] ---> Map Moho_heightmap (G) for Moho enabling self. Path = JNSQ/JNSQ_Textures/PluginData/Moho_heightmap.dds [LOG 09:58:21.201] [OD] ERROR: getting pixelFloatD with unloaded map Eve_heightmap (G) for Eve of path JNSQ/JNSQ_Textures/PluginData/Eve_heightmap.dds, autoload = True [LOG 09:58:21.361] [OD] ---> Map Eve_heightmap (G) for Eve enabling self. Path = JNSQ/JNSQ_Textures/PluginData/Eve_heightmap.dds [LOG 09:58:21.361] [OD] ERROR: getting pixelFloatD with unloaded map Eve_heightmap (G) for Eve of path JNSQ/JNSQ_Textures/PluginData/Eve_heightmap.dds, autoload = True [LOG 09:58:21.521] [OD] ---> Map Eve_heightmap (G) for Eve enabling self. Path = JNSQ/JNSQ_Textures/PluginData/Eve_heightmap.dds Are these nominal? My second question has to do with EVE. Unless the clouds are extremely subtle (which they might be, I have old eyes) they don't show up at the game's main menu. They work fine in play. I'm only asking about this because I want to make sure it's not a sign that my game isn't working correctly. Here's a link to my complete log file, if you want it. https://filebin.ca/4jZlSdPCPEEX/KSP.log

@OhioBob PERFECT! Exactly what I wanted to know! Thank you so much!

@OhioBob Thanks very much, but is there a better way? What I mean is, your config files have intensity curves that define brightness as a function of distance. Can I MM-patch those curves so that each point has a value that's 1.5 × the value in your config file? I don't want anything fancy; I can do the arithmetic myself, obviously. I just don't know which numbers in the config file's intensity curve section correspond to what. I should emphasize that this is strictly a cosmetic thing just for me. I play with KS3P, so all I'm going for here is something that'll look sexier on my screen, not some big global change that affects everybody.

I am in love with this mod. Absolutely in love with it. I've started a new game with Research Bodies installed and deliberately avoided looking at any screen shots or anything so I can discover the solar system blind. Thought I'd share something I'm working on. I've created a version of my kOS ascent program that's tuned for JNSQ. It's still very much a work in progress, but at the moment it can put an upper stage into a 95 × 90 km orbit via direct ascent for a hair over 5,000 m/s. (Direct ascent meaning no coast phases except during stage separation.) The first stage needs to have a sea-level Δv of about 3,500 m/s and a liftoff TWR of 1.5, and the upper stage needs an initial TWR of about 1.2 and a vacuum Δv of about 1,500 m/s for a little maneuvering margin. I'm still working on turning things. In the screenshot below, the circularization maneuver at apoapsis to make it a 95 × 95 orbit was 3.1 m/s. It's not the most efficient ascent program it's possible to imagine, but it has the virtue of being consistent. https://github.com/jefferyharrell/YAKAP-JNSQ Now for a question: Prior to JNSQ, I used to play stock with a little Kopernicus config that made the sunlight brighter. It looked like this: @Kopernicus:AFTER[Kopernicus] { @Body[Sun] { @ScaledVersion { Light { sunlightIntensity = 1.5 scaledSunlightIntensity = 1.5 IVASunIntensity = 1.5 } } } } This trick obviously doesn't work with KNSQ, but I was wondering if there's a trick that will? A cursory Google search didn't turn up any useful info on the intensity curve part of the Kopernicus config, so I don't know what the values are or which ones to change. Thanks for the fantastic, fantastic mod.

@woeller Glad I could help.

@woeller The reason your nitrogen supply looks like it'll run out soon is because your pressure control system is frantically using it to make new Atmosphere, a pseudo-resource that Kerbalism uses internally but that doesn't show up in the resource panel. (I'm pretty sure it doesn't anyway.) If you look at the Kerbalism GUI, under Habitat, you'll see an item labeled "pressure." In your screen shot that's at 60 kPa — kilopascals, a unit of pressure. Your vessel's pressure controller is using nitrogen to make more Atmosphere, and will continue to do so until your habitat pressure gets up to a little over 100 kPa, which is 1 atmosphere of pressure. When you disable habitat on a part of your vessel, that section's atmosphere gets vented into space, so when you re-open that habitat the total pressure of your vessel goes down (because you just increased the total volume) and the pressure controller has to make new air to bring the pressure back up. Your consumption rate of nitrogen will drop to something very low as soon as your vessel's pressure hits about 100 kPa.

More of an idea man, I guess.

A hundred years ago this year, a physicist named Emmy Noether did some groundbreaking work in the study of continuous symmetries. She was able to prove, mathematically, that wherever a continuous symmetry exists there also exists a conserved quantity and vice versa. The various observed conservation laws, in other words, were not empirical and arbitrary laws of nature, but rather unavoidable consequences of symmetries in various geometries that are present in the universe. The conservation of angular momentum, for example, is not a thing in and of itself, but rather a consequence of the fact that there is no directional bias to the universe. Because the universe looks the same from every direction  because it's rotationally symmetric  angular momentum must be conserved. Emmy Noether's theorem proves this conclusively. So I think this should be called Emmy's Mod.

No. "The bug fixing cycle" is a myth, as far as I can tell. Every release has been buggier than the one that preceded it; 0.90 is the buggiest, most unstable, least playable release of KSP I've ever seen, and I started playing version 0.13. How many bugs have been fixed during the beta? Spoiler alert: Zero. Exactly zero.

I don't think you understand what it's like to be a Squad customer. In December, you guys decided to call your alpha game "beta." Nobody thought this was a good idea. The game was too unfinished and unpolished to go into beta testing. But you guys called it "beta" so okay, we customers got ready to start seeing fixes for the literally hundreds of major gameplay-ruining bugs that we lived with all through the alpha period. Because that's what "beta" means: It means bug fixes, and lots of them. In the three months since, you guys have fixed exactly zero bugs. Not a single one. So we customers were already feeling kind of crapped on. It's a beta, huh? So where are the bug fixes? Three solid months without a single bug fix? That's not a beta. That's abandonware. And then you guys started in with the girl kerbal thing. Okay, whatever I guess. Literally every player who wanted girl kerbals has had them through Texture Replacer, so you were pimping a solution in search of a problem, but hey, it's your game, you do what you want. If you want to make a big stink about girl kerbals instead of fixing bugs during the beta period, I guess that's your business. Meanwhile we customers will just sit here and become increasingly frustrated with your game because it keeps crashing and our ships keep exploding for no reason and our kerbals keep getting jettisoned off ladders for no reason while you guys waste a ton of time doing non-gameplay-related renderings of a new character who will have exactly no impact on the actual game itself. And then it was oh, we're rewriting the entire aerodynamics system. Why didn't you just write Ferram a check and buy FAR? No idea, you decided to write your own. Instead of fixing bugs. During the beta. Three months after the beta started, in fact. And then it was oh, we're doing payload fairings. We've already GOT payload fairings, guys, and we love how they work. Yours aren't going to be as good as Procedural Fairings? Then why are you wasting your time? Instead of fixing bugs? Cause the Mac version still can't run with full-res textures, you know. Because your memory leaks crash the game. Constantly. And you haven't fixed any of them. Despite promising to when you called it "beta." AND THEN just a few days ago all of a sudden it was "Oh, geez, we bit off more than we can chew, and now we have to cut some of these AWESOME NEW FEATURES so we can spend a little time fixing a few bugs." Why are you spending any time on new features? The game is in beta. It's been in beta for three months. Why haven't you fixed all the bugs already? Why haven't you released 0.91, 0.92 and 0.93 already so your customers can beta test them for you? And then you guys were all "Gee, what do you think, customers? You have to choose between new features and having a game that you don't hate for all its bugs. Which would you prefer?" Talk about your all-time award-winning stupid questions. So when you posted your ha-ha-so-funny-little-joke, you know how we all reacted? With complete credulity. Because there was nothing in it, not a single thing in it, that sounded out of character for Squad. Every single word of it sounded exactly like something the Squad of the past three months would try to pull. It wasn't outlandish or ridiculous, man. It was just par for the course. This should chill you guys to the bone. You guys should have a sick feeling in the pit of your stomach right now. Because we believed it. Because it sounded exactly like something you guys would pull on us. Stop being like this, Squad. Please. You guys used to be pretty okay, as indie game developers went. Your quality control was terrible and you had a bad reputation for excessive employee turnover, but your customers in general were willing to give you the benefit of the doubt. That's over now. You guys have squandered your customers' good will. Earn it back. Please.

I play on the Mac, and I've never seen three gigabytes. If the game's going to crash from a failed attempt at memory allocation â€â€.and it is  it happens somewhere in the mid-two-gigabytes range. I only discovered that this mod works on the Mac a couple days ago so I don't have good, precise information yet; I've been so aggressive in my RAM-miserliness that I haven't had a crash since installing this. But I'll try to push it to its limits over the weekend and get some better data. I will offer this food for thought: My laptop (a Retina MacBook Pro which performs magnificently in every respect) has Iris Pro graphics, which as I understand it use RAM instead of having dedicated texture memory. Maybe (and I'm totally speculating) that RAM is coming out of KSP's addressable space and causing the lower RAM ceiling. It's certainly not a system-wide limitation; I've got sixteen gigs here, so I have plenty left over when KSP starves and dies. EDIT SOMETIME LATER: I just got a crash (or actually a hang; same thing in practice) due to a malloc failure when GCMonitor read 2,462 MB. It was brought on by the usual thing: launch, revert to VAB, launch, revert to VAB multiplied several times over. I didn't count how many trips around that loop I took, but it was quite a few. It was a true malloc failure, too: KSP(4169,0xa08361d4) malloc: *** mach_vm_map(size=33554432) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Receiving unhandled NULL exception …and then a big stack trace that just said "…in mono_traverse_objects" a bunch. So at least in this one case, the answer is 2,462 MB.