NathanKell

Dr. Jet: I think you misunderstand how plugins work. One doesn't compile plugins for x86 or x64. Use the released version (but, as TaranisElsu says, please don't expect or ask for support).

Starwaster: woo, release! I don't immediately have any reason for the bug FlowerChild mentions, alas. Also, can you edit the thread title (OP->edit->advanced) to change the date? It still says 7 Oct.

Ah, ok. I was going nuts trying to replicate :]

Cool! 10char

TweakScale and RealFuels engines are not compatible. This is why RF removes the TweakScale module from all engines that are RF-enabled. Did you add scaling back? I will deal with it at some point, but I have not yet had a chance to do so. In most cases, however, since the engines are either 100% real, or 100% realistic but from an alternate history, it doesn't make sense to make them scalable.

Number of engines shouldn't matter, since mass will be proportional to the number of engines and therefore can be assessed per engine (or are you saying it's very non-linear?). Gimballing will matter, but since engine gimbal doesn't differ within a single engine part, it makes sense to assess per engine. Bottom or top we can't account for, true, but have there been any [relevant, pace Goddard] LVs that *lift off* as top-pullers? I.e. where TWR is high? Thus I think assessing it per-engine is a pretty good approximation. The one thing you did not mention however is "mass above that stage" i.e. what's pushing down on the stage at the same time the engines are pushing up. But I think that can be ignored with some level of accuracy (i.e. even if we're off by 20% you can make it up elsewhere if you're making replicas, and that's close enough and better than 100% off if you're not). Finally, it's worth noting that this ties together with tank mass in RF (which is computed to try to lead to on-average-correct stage masses, *given engine masses in RO, and given stage masses in real life*).

Northstar: cool! I'd be happy to include them. Folks, slight additional delay and BIG ANNOUNCEMENT which some of you may already know, but others may not. RF v8 will be changing a *lot* of resource names; regex has gone through the entire list, added about double the resources there were up to now, and fixed them all for consistency in name and in stats. This means that some resources will have changed name (LiquidOxygen->LqdOxygen, LiquidH2->LqdHydrogen), some will have changed density a bit, and some (e.g. NitricAcid) are split (e.g. to three different resources, IWFNA, IRFNA-III, IRFNA-IV) rather than a generic that wasn't quite any of them. I am also taking this opportunity to once again balance tank masses against real life. Note that in many cases, this means structural coefficient will go up, which means you will have results closer to real life (rather than better than it). That, however, is taking a bit of time. What does this mean? It means that 8.0 is save breaking. regex has written a patch to update the resource names in old .sfs files and .craft files, but no promises that that will work, and due to tank masses changing you would do best to start a new game anyway since craft's tanks will either not update (bad) or update and throw off center of mass and delta v (also bad). I apologize, and I hope this is the last time for a long time (if ever) there's a save-breaking update, but I think it is very, very worth it; this is why I have held off making these changes until .25 came out, so the save breaking can coincide with when one is likely to start a new game anyway.

As for the masses, for liquid engines US engines often don't have the thrust structure included (classic example: The F-1 massed about 8.4 tons, but the S-IC had a 20-ton thrust structure, which meant in effect each engine massed 12.4 tons). That may be part of what's going on there. Russian engines do include the thrust structure in the cited mass, AFAIK.

Yes it would, because then it wouldn't change stock files (just fix bugs). You would then always have the option of uninstalling (rather than redownloading KSP!), it would be safe if KSP is upgraded and the issue not fixed, and it's just *always* a better idea not to *overwrite files* if you can avoid it.

D'awww KSP does that, actually. It's just that the heightmaps it uses are locked up in Assets. One of the things RSS does is let you either add a heightmap to bodies that don't have one, or replace the heightmap on bodies that do. Note that the PQS is made up of more than just the heightmap; really, the heightmap is just one of many "PQSMods" that create the final terrain. .If you're more on the technical side, here's what PQS is based on, Sean O'Neil's original procedural planet stuff (Part One on Gamasutra, search there for the other parts).

Nope, Kopernicus works enough you can play with it and make some planets, and with RSS to edit the PQSMods you can then make the planet into what you want.

As the game gets updated, more and more stock parts get added; this takes up more and more memory, leaving less and less available for addons (there is a hard limit of about 3.3GB in 32bit on PCs, and less on Macs). Your only option right now if you want more memory available for use is to run the Linux 64bit client of KSP (there's no 64bit client for Mac, and the Windows one is very unstable). You can also try using OpenGL mode (if you're on PC) as Athlonic suggests; obviously on Mac or Linux it'll already be using OpenGL.

RealChute doesn't disable itself on OSX. It only disables on version not 25, or version 25 and KSP Windows x64. What it does do is warn that it may not be compatible with a different version of Unity, which seems quite sensible since Chris isn't on a Mac to have that version of Unity, didn't compile for that version of Unity, and who knows what might break. This is only a problem because this time, Squad released KSP using a different version of Unity on the Mac than on other platforms; if we're lucky, no mods will break, but we don't know.

Nope, you just scale the image down. Do make sure the new resolution is also a power of two, i.e. 8192x8192->4096x4096 I would scale down everything but heightmaps first; if you scale down the color or normal map, things will look blurry; if you scale down the heightmap, terrain will change.

Could you name the mod? I have yet to hear of one. You will get *warnings* about that, but I have not heard of a mod that disables on OSX, just wrong KSP version number or KSP Winx64.

Would you be interesting in making a MM config to do this for ModuleRCSFX (since it supports EFFECTS nodes)?

That's due to a loader bug. Please read this as there's enough misinformation about KSP and textures floating around...

Pleas see this thread -- it clears some things up, and (Cerebrate et al) also has a way you can help.

Either write a :FINAL patch to remove them again, or check the HAS block in the TACLS patch and see if you can add something on :FIRST that would make the HAS block fail.

And, of course, gives up on any chance of support.

braininator: Adding to OP. I hope Win x64 will be usable when Unity 5 comes out, but Linux x64 is, and has been, stable. And RSS is, of course, not locked on it.

I have not tested it extensively, but I don't know of a reason why it would break in .25 and it's worked all the times I've used it. But do, please, blame me if it breaks.

Also, just a note in case it wasn't clear. The way DRE handles burning up a parachute is by cutting it. You will not see a heatmeter, and (because I forgot) you will not get a log message. It will just happen when the parachute is deployed in a shockwave where shockwave temperature * density > parachute part max temperature * multiplier.

I think the language used could use a bit of a tweak. There are two issues here: *Mods that genuinely are not compatible with KSP Windows x64 (I have yet to hear of a report of one of these that didn't turn out to be KSP Windows x64 being broken) *Mods that lock themselves on KSP Windows x64, due to KSP Windows x64 being broken and us not wanting to cause (or be thought to cause) issues, and us not wanting to release for a platform we literally cannot test on because it crashes too much. It is worth noting that no mods lock themselves on Linux x64, and to my knowledge none are incompatible with it either.

Please follow the guidelines in the READ FIRST sticky but in addition post pictures of your craft in the SPH with CoM and CoP (Squad calls it CoL...) enabled.