NathanKell

While I can certainly point to various older releases of my own mods (and I know ferram keeps his old releases available) it's less certain for other mods. Further, now that IR is updated for .23.5, I am unaware of any mod that works in .23 but fails in .23.5 (RT2 was *also* unsupported for .23, basically, but we still used it; and we can still use it now. The title of the thread is just saying don't bug *Cilph* with bug reports, he's busy). I agree that right now there's a lot of misc patches floating around; Medieval Nerd and I are trying to centralize a bit more. However, I am not (and cannot) create a giant single mod[pack] that does it all; that's why this thread and tool exists, because licenses (and good sense) prevent us from doing that. (And I am not going to rewrite giant plugins and recreate parts just so that the download can be one big piece instead of via this tool or manually). I'm currently (with MN, who's just released an update to RPL) going over the mods required. We'll get this sorted out somewhat better at least!

Jas1126: very true about, say, RSS. I never really understand why people claim [equatorial] launches from it are harder. Now, non-equatorial launches are harder. Your complaint is less true about something like DRE or FAR. In FAR, you can't stick a "make me aerodynamic" part on your rocket; if it's designed badly and you fly it badly, it *will* tumble and break apart. DRE? No matter your heatshield, you have to watch your interplanetary aerobrakes or you'll jelly your crew. By contrast your example makes little sense to me; implicit, IMO, in calling for "hard mode" is calling for a hard mode that is skill-dependent; if half your rockets just randomly exploded, with nothing you could do about it, that wouldn't be "hard mode", that'd be "restart half the time mode". Now, if it's a system where better-designed rockets fail less, and you can do various things to recover from failures (like, say, using a low-dV transfer rather than a fast Hohmann transfer, or making multiple gravity assists rather than a straight burn)--that would be hard mode. Vim Razz, almagnus1, re MCE. The costing mechanism in MCE (and note that MCE autocalcs all costs; it has nothing to do with what the partmaker set the part cost as, because we know that's usually broken if the modder even cares to set it) is pretty much entirely user-configurable. I've periodically posted begging for some crowdsourcing improvements of it, but got no bites by the time I last contributed to MCE (kinda a while ago, sorry malkuth!) Anyway, it's open and ready to be worked on by anyone who cares to add a few lines to a text file and do some testing.

It's locked up in one of the Assets files. You would probably have to use a dummy model, then write a plugin that would replace the part's model ingame.

Now *that* would be really useful. It'd open up a lot of options for making RCS parts with MODEL nodes.

Hey, Laz, guess what ialdabaoth just released? A non-broken RCS module. So you don't have to do the workaround anymore.

Yes, it uses Y axis. That's why you can't go between RCS and engine easily.

Benoit: Yes, because I'm using EVE 7.3 and it's all fine. (Given what the GameData folder looks like, I would be willing to bet it's an install error.) SpacedInvader: that sounds reasonable for Mercury. Regarding Venus, while I see them on the color map, I'm not seeing them on the heightmap...don't doubt they're there, though. As to PS what I'd suggest normally would be clone stamp work, but you'd have to base it very closely on the heightmap...

Ratzap: weird. I'll test throttle limiting. There's only one file; the post's instructions seem wrong. >.> I do agree with you about inclusion, but last brooklyn666 mentioned this, s/he wanted the fix kept separate. Regarding launch clamps. The issue is that the launch clamp fuel pump in RF will only fill *the tank it's attached to*, which is kinda dumb. I'm rewriting.

Benoît: this happens when textures are too large for your OS / video card. Open EarthColor.png and scale it down to 4096x2048. I can do it for you if needed. OxalysResourceConsortium: ah, yeah, I keep meaning to try that!

Ratzap: verify that thrust actually changes when you play with the limiter in flight? Thrust limiter works by lerping between min and max thrust, and since they're the same in RO, it shouldn't make a difference. (Note that MJ will report, in the VAB, limited thrust, but it won't work in flight.) Unless Squad changed how it works in .23.5 and I haven't noticed. Yeah, I'll get with MN about changing the instructions. But if your ranges are all off by 10 you don't have brooklyn666's antenna patches. Grab them in post 2 of RO thread.

SpacedInvader: yup, sounds like MeshWrapper is failing for the Moon then. Since that's supposedly what RSS is doing too but it's obviously failing. jebandhisfriends: Sounds like a bad install. Please use the Mod Bundler instead. manuelasa1999: Install gone wrong. You have a GameData folder inside your GameData folder, and I'm guessing that other mods also had (more subtle) installation errors. Try wiping your mods and install again, one by one, *exactly* following each readme's install instructions. If that fails, try the mod bundler linked above.

Starwaster: see above. Unless node parsing was totally rewritten, when you delete a node KSP needs to parse it as a node, not a value. I'm talking about !NODE{} vs !NODE {} btw. Not !NODE[blah] {} vs !NODE[blah ] {} (there, the whitespace in the nodename is bad, yes.)

Dude. Telling a mod maker who's making a mod primarily for their own desires that they should instead make it for someone else's is just...weird.

1. Is your KJR absolutely up to date? 2. Are you using mod parts, where the modders didn't set the correct node size? What was once only an annoyance and a disruption to FAR's drag model is now, thanks to Squad's joint fixes in .23.5, a reason for parts to fall apart. Bug your part makers to set correct node sizes!

Probus: yes. ThorBeorn: even if it does, you could copy a new tech.cfg over your old one. Ratzap, Visari: tweakable throttling shouldn't actually work, since it's no different from regular throttling. If it does for you, that's strange, since I've never seen it work. (It works for SRBs, of course). Visari: yes, that would be the case, although you can do things with varying turbopump rate and lowering chamber pressure (bad for atmosphere, nearly meaningless in vacuum). Ratzap: since you should be using brooklyn666's RT2 antenna ranges, you should have range mult set to 1.0 and consumption set to 1.0 in RT2 Settings. You should also have MultipleAntenna set to 1.0 and range model to Root.

If you're rescaling the tanks to use in SLS, give them the volume of fuel that SLS should have (work backwards from mass, mixture ratio, and density if they don't specify liters). That should be flexible enough, since the mass ratio will be reasonably close to what RF would assign. As to how much volume a tank part "should" have, that's complicated because "tank parts" (we'll call them stages) in KSP aren't actually tanks themselves, they have multiple pressure vessels within them, and how much of the stage is used for propellants varies. For example, a balloon-tank stage like Atlas or Centaur uses basically the entire volume of the stage for tankage, whereas N1 (with its spherical pressure vessels inside conic stages) uses comparatively little. That sounds like a fine plan for the two NK-33s. (And it wouldn't be N-1; that'd be NK-15s...)

No spaces are for things inside brackets. The spaces (and braces) there are to tell KSP that you're declaring a node rather than a value; if you remove the spaces, KSP might even think it's a value...

Three things affect scale. First, does the part use MODEL nodes? Skip to part B. A (MODEL node not used; instead "mesh = blah" used) 1. "scale = foo" determines how the first three numbers for each attach node line (the X, Y, Z coords of the node) are scaled. It does *not* affect anything else. Default = 1.0 if not present 2. "rescaleFactor = bar" scales both the model (and its transforms) *and* the attach nodes. Default = 1.25 if not present. B (MODEL node(s) used) 1. Inside the MODEL node, "scale = blahX, blahY, blahZ" determines the scaling of the model and its transforms. Default is 1.0, 1.0, 1.0. It does not affect node positions. 2. Outside the MODEL node, "scale = foo" works as above. 3. Outside the MODEL node, rescaleFactor works as above. HOWEVER, there is a bug in scaling. For parts with MODEL nodes, rescaleFactor is applied twice to the mu, *unless* (a) the part is the root part of the vessel and ( you've reverted to launch (or perhaps switched in flight? Don't recall). All other times, it is applied twice. What this means is that if you have scale = 1.0, 1.0, 1.0 in the MODEL node (or no scale at all), and rescaleFactor = 1.25, then your mesh will actually be 1.5625 as big, but your nodes will be scaled outwards 1.25. For this reason, when scaling parts using MODEL nodes, it is suggested to leave scale (outside the MODEL node) and rescaleFactor both at 1.0, and instead both change the scale = x, y, z inside the MODEL node and manually scale the positions of the attach nodes.

Never use PS's own png plugin. Use SuperPNG instead. It gives you far more control.

Yes. PP reads ST texture definitions and vice versa.

Nope, KSP uses vectors for vectors. It does, however, use quaternions for *orienations*, and quaternions are *not* simply 4-unit vectors (like you'd use in a 4x4 rotation matrix). If you see a 4-tuple, it's either a vec4 or a quaternion; vec4s are used for, e.g., colors (r, g, b, a), and quaternions for orientations. You might want to read up a bit on using quaternions for orientation, because dealing with them can be *quite* complex (they're a way of representing imaginary numbers, for pete's sake).

They won't; they'll be uncompressed ingame (!) Unless you have ATM, obviously, and even then it'll only compress stuff you tell it about, these days.

Yes, this is a massive issue. It's actually in some ways worse, because even if MM doesn't change the order of *existing* modules, saves/craft will be broken depending on when new modules are inserted (or if they are). (This is why, for example, CrossFeedEnabler doesn't default to being applied to stretchies/PP: because it will break .craft / saves.)

Right, I know you embedded an album; the issue it it pops up with scrollbars and other issues. If you use the forum's native way of embedding an album rather than linking to it, it comes out much neater: You're thinking of displacement maps, I think. Bump maps only ever do the same thing normal maps do. Try upping your deformities to quite large values (1000000 deformity, say) and launch KSP. The ScaledSpace mesh should be spiky. You can look at Gilly or Bop for an example of this. Sorry, for some reason I thought CrazyBump was free. Maybe SSBump? http://ssbump-generator.yolasite.com/download.php The 90d shift in lighting is due to channels not being swapped and inverted. You need to do those changes (on the wiki) or you will get the lighting weirdness. If you want an example of what the normal map should look like, check out the one for the moon I added to github a week or two back, based on my grabbing AndreyATGB's and doing those documented changes to it.

[preface note: you can embed the album by doing ['imgur]L5A9K[/imgur] (use the short album ID you get from the album's address).] That's *weird*. I'll check out the shader. I doubt they're using both a bump map and a normal map, since all a bump map is, is a stripped-down normal map (a bump shader computes a pixel's effective normal by computing a new normal based on original normal and bumpmap value; a normal map just allows you direct, rather than mediated, control over the final normal). Scaled space meshes' deformation is determined by the PQS; if the PQS is not very hilly, then the scaled space mesh will be flat (due to RSS warping ss meshes to the PQS). The derformation of the scaled space mesh has nothing to do with the color or normal map you supply. Regarding generating normal maps: I would suggest CrazyBump, first of all; nVidia's PS plugin is notoriously poor for this. You need SuperPNG (free). It's a much better PNG import-export plugin. PS handles PNGs *very* strangely (and poorly) natively.