jefferyharrell

It's y'all's mod and you guys should do whatever you want. That being said, I would personally vote no for city lights, or at least hope for an easy way to disable them. It's just weird to me that Kerbin, a planet with no surface structures but the launch sites, should have lights visible from space. Maybe I've just been playing the game too long, since back before there were other planets, but I'm quite fond of the idea that all of Kerbin is untouched wilderness except for these half-dozen buildings or whatever.

Just in case, did you for sure install the version of Kopernicus for 1.7.3? It just came out a little while ago, I believe. If you installed an older version it simply won't load at game startup. (It also blasts the screen with error messages, so you surely can't have missed this one, but I just thought I'd ask in case it helps you out.) The other thing is that I believe Kopernicus has a dependency in Modular Flight Integrator. I didn't see you mention it, so again, just thought I'd ask. I may also be wrong about the dependency. I'm just stabbing in the dark here.

Looks like a 1.7.3-compatible version of Kopernicus dropped this morning. The changelog is very minimal. Any reason to doubt that JNSQ will work against the new Kopernicus without modification? (I obviously don't expect anybody to answer right away. Just thought I'd get the question out there so when you guys have a chance to look at it, it'll have been asked.) Thanks!

Easier than adding "**" as an operator to kOS? Well yeah. But when you copy-and-paste a lot of equations with the "**" notation in them, even find-and-replace becomes shockingly tedious after a while.

I haven't had a chance to check this out yet, and unfortunately probably won't for a minute, but if this means what I think it means I think I love you.

I have another feature request! I hope it's more plausible than my last one, but I suspect it's probably not really a very good idea. It's this: FORTRAN syntax for exponentiation. In kOS, you raise a number to a power by doing x^y which makes perfect sense. It's the C-language exponentiation operator, and it's used in a ton of other languages. But FORTRAN uses x**y for exponentiation, and for what it's worth Python uses this operator too. I've been copy-and-pasting a LOT of code from a Python-based symbolic algebra system into kOS, and it's great but for having to change all the "**"s to "^"s. Would it be possible for kOS to support both the ^ operator and the ** operator? It would of course be terrible to switch from "^" to "**", but it'd be terrific if either one worked. I have absolutely no idea how language parsers work, so this could be anything from utterly trivial to completely impossible. But I thought I'd ask! While we're on the subject, a built-in EXP function wouldn't be the worst thing in the world. It's trivial to include your own by writing DECLARE GLOBAL FUNCTION EXP { DECLARE PARAMETER x RETURN CONSTANT:e^x } but it'd be nice not to have to. Thanks!

@Jognt All very good points. I just think it's a shame that unless you're very self-disciplined, the thrill of discovery is not part of playing KSP at all. Which is why I like JNSQ so much — more than any other single fact about it, it's new. It's different. I have no idea even yet what any of the planets look like because my game has been entirely in cislunar space so far. Part of that is because I haven't had as much time to play lately, but also I'm deliberately drawing it out so I don't see everything new all at once.

@Jognt You laugh, but I think one of the best improvements to KSP would be procedurally generated solar systems. Years ago the developers said they didn't want to try this because they wanted players to be able to have the same game experiences, but that's trivially achieved by having a seed number that players can share to generate the same solar systems. I imagine that procedurally generating gravitationally stable solar systems might be a challenge (I haven't done the math), but with everything on rails the boundary conditions aren't that constraining. In my dream KSP, every time you start a new game you get a new solar system (only the sun, the "earth" analogue and the "moon" analogue are constant), and all the planets look like this until you send fly-by probes or orbiters to them. Get a particularly good solar system from the procedural generator? Just share the seed with your friends. Then there's like a 900-page forum thread of awesome seeds people have found.

I agree. What I wanted out of the mod was to "blur out" the other bodies in the solar system until I photographed them, sent orbiters to them and so on. You know, so you can't zoom into them in the tracking station and see every last pixel. Unfortunately the mod does a bunch of other stuff that isn't really compatible with how I like to play the game. I would say that I think there's a market for the kind of mod I want, but honestly after that first game where you learn what the planets look like, it'd be kind of pointless.

@Dragon01 There was a how-to posted a page or two back about downloading 1.7.1 from the Squad web site. I think Bob's point (not that I'm speaking for him) is that they really don't want to have to deal with "I compiled my own Kopernicus and now your mod ate my dog" stuff. JNSQ is meant to work on the official build of Kopernicus for which it's been configured. Anything else is at-your-own-risk, don't-clutter-up-the-thread-asking-for-support stuff. That's just my own interpretation.

I thought it was a function of your terrain detail setting. Am I mistaken?

I have nothing to contribute to this effort, but I just wanted to say I support it wholeheartedly and I hope it gets the attention it deserves.

I have now. SHIP:BODY:DIRECTION:VECTOR:MAG returns exactly 1 every time I look at it.

@panarchist Any chance one of those mods you're running is Research Bodies? When JNSQ first came out I tried starting a game with that mod and eventually (I can't remember what I had to do in the game to trigger it) I started getting hard crashes whenever I went to the tracking station scene.

@Kartoffelkuchen Yeah, I did some work along those lines. Somebody sanity-check me here. When a spacecraft is in orbit above Kerbin's atmosphere and the engines are off (including RCS thrusters), the only force acting on the vehicle is gravity, right? (Not in real life, just in KSP.) So if we say v is the spacecraft's velocity in the orbital reference frame (a vector quantity), and the spacecraft is at altitude r (measured from V(0,0,0) to the center of the planet), then dv/dt should be equal to μ / r². I went round and round on this yesterday until I started to doubt my basic arithmetic skills. The following code snippet works... DECLARE LOCAL Δt IS TIME(0). DECLARE LOCAL tPrevious IS TIME(0). DECLARE LOCAL vPrevious IS SHIP:VELOCITY:ORBIT. UNTIL FALSE { SET Δt TO TIME() - tPrevious. SET tPrevious TO TIME(). DECLARE LOCAL dv IS (SHIP:VELOCITY:ORBIT - vPrevious) / Δt:SECONDS. DECLARE LOCAL grav IS SHIP:BODY:MU / SHIP:BODY:DISTANCE^2 * SHIP:BODY:DIRECTION:VECTOR. PRINT( (dv - grav):MAG ). SET vPrevious TO SHIP:VELOCITY:ORBIT. WAIT 0. } ...but only approximately, and only to a good accuracy above a certain critical orbital altitude. In a 100 × 100 km orbit above Kerbin, this program returns a small number, on the order 0.0002 m / s². But down at 86,750 m (the lowest altitude you can cheat-set-orbit your spacecraft into) the error is much bigger, of order 0.6612 m / s². Is an unaccounted-for acceleration of two feet per second per second going to screw up my programs? Doubtful. But I'm more concerned about why the math isn't coming out right. So far my leading hypotheses are (a) KSP is just being buggy yet again or (b) I've been staring at this for so long I've gone cross-eyed and I'm missing something obvious.

I've searched the forum and whatnot, but I haven't seen this addressed in a definitive way: How can one, through kOS, "measure" the proper acceleration on a spacecraft? In the real world, proper acceleration is the acceleration that would be measured by an accelerometer carried along with the spacecraft. That is to say, on the launchpad it would read something close to 9.80665 m/s/s and in orbit it would read 0 m/s/s. Reading SHIP:SENSORS:ACC doesn't do what I want because on the launchpad it reads a very small number (on the order 10^-5), while in orbit it reads 6.8 m/s/s, which I don't understand at all. If it were just equal to local g I could subtract that off, but it's not. In the atmosphere I can approximate proper acceleration with THROTTLE * SHIP:AVAILABLETHRUST / SHIP:MASS, but if there's a way to get the actual proper acceleration I'd much rather use it. Thanks!

@panarchist Terrain detail settings are stored in settings.cfg. These settings changed between JNSQ versions, so you need to delete settings.cfg and let the game create a new one, then apply all your settings. Don't just copy your old settings.cfg file back, because that defeats the whole purpose of deleting it in the first place.

Oh amen.

@vossiewulf I really think it'd be worth your time to start all over. Uninstall KSP with Steam, delete the KSP folder from the steamapps directory. (Back up anything you want to save first!) Make sure your Steam settings are set to lock to the 1.7.1 version; counterintuitively, this is done through the "betas" tab of game properties. Install KSP, with or without the expansions you own/want to play with. Then COPY the "Kerbal Space Program" folder out of your Steam games directory and off to someplace else. Rename it to something helpful; I use "KSP 1.7.1 JNSQ." Then in THAT game folder, install all your mods from scratch. CKAN works fine for me; you might prefer to download and install manually. I've done that too and that also works. You will HAVE to do that for the JNSQ mod itself, since it's not on CKAN. (Or wasn't last time I played, which was last week.) If you download the required versions of Kopernicus, EVE and Scatterer and install them correctly (again, CKAN works for me), then install JNSQ, I can think of no reason why your game wouldn't run pretty much perfectly. Mine does. Though do note that Scatterer can apparently sometimes cause crashes. This is normal and to be expected, unfortunately. You might choose not to install Scatterer, at least at first until you've got your game nice and stable. JNSQ's graphics still look quite good without it, though it does make them (in my opinion) dramatically better.

I think I've said this before, but just to put it out there: In my game I have Real Chute installed (but not FAR), and I haven't observed anything out of the ordinary. I didn't know TweakChutes was a thing before setting up my game, is why I have Real Chute. It's just been my habit to use that mod for years and years now so I installed it without thinking.

Yeah, I'll usually do that too, but in this case it's kind of a pain. I need to be able to test my program against a variety of vehicles, which means having a bunch of parts mods installed, plus which I'm tuning it specifically to JNSQ so that adds to the load time. I've reached that unfortunate stage in the process where I really need to have my whole game up and running. Hence sliding just Scatterer out of the way to try to minimize crashes. But hey, when I'm done I should have a pretty cool ascent guidance program.

It's a temporary thing. I'm working on my kOS guidance program, which involves a lot of reverting. I've found that with Scatterer on board, reverting has a chance of causing a game crash. Since my game takes like 5 minutes to start up each time, I've temporarily moved Scatterer out of the GameData folder to try to avoid, or at least reduce, the crashing. So far it's working well. I'm just not seeing what I think Galileo says I should be seeing with Scatterer not installed.

I'm not seeing that at all! With Scatterer removed from the GameData folder but everything else left alone, I see an ugly ocean texture that's visibly tiled, like a grid of blue-patterned squares. Is there an obvious place I should look to troubleshoot this? My game has Distant Object, EVE and PlanetShine in addition to Scatterer, all installed via CKAN. And the right version of Kopernicus, obviously. Let me be clear: It's not your job to do tech support. So if you have any off-the-top-of-your-head hints I'd love to hear them, but other than that don't sweat it. It's clearly a problem on my end. Oh, and re: the crashes, that's what I figured. Oh well, occasional crashes encourage me to take breaks from the game.

If I may be excused for asking, is anybody else finding Scatterer to be kind of crash-prone under JNSQ? I've been working on my guidance program so I've been doing a lot of revert-to-launches. Maybe as often as one time in ten, KSP will crash and the last entries in the log will be messages from Scatterer. It's possible that Scatterer is just plain buggy under these conditions and it has nothing to do with JNSQ, but I thought I'd ask. My workaround is obvious: Just move the Scatterer folder out of GameData when I'm gonna be doing a lot of reverting. It seems to alleviate the crashes, but man the ocean is ugly.

Nertea's Far Future? I had no idea that was even beyond the concept stage.