Phineas Freak

@DrLicor isn't that normal? I mean, you cannot expect a mod that it is compiled against KSP 1.2.1 to work in 1.1.3. That's the whole reason why plugin mods needs updating in the first place.

@Epox75 it is all Procedural Parts (from top to bottom). I gave it a "Thermal Blanket" texture (from FreedomTex) to simulate the MLI. Really nice work on that launcher! Always love to see proper application of interstages as engine fairings and proper tank/engine interfaces. The payload interface is also really good!

And it is still missing a lot. Proper avionics pods and conduits, along with a better paint job are only some of the things that require improvement. But i am trying to keep them "RO - stock" (i.e. no custom parts or textures) so it will suffice for now.

The Atlas launch vehicle family is one of my favorite. So let's spam this thread with some of the variants, starting with the Atlas LV-3C Centaur: Pre - launch Liftoff Roll program complete Pitch program BECO & engine separation Centaur insulation panels & fairing jettison Atlas core burnout & separation, Centaur ignition Orbital insertion (~1050 Kg of payload - 293 km x 260 km, 28.5o)

@Benji13: @heatProduction *= 2.5 Currently you are inserting a brand new "heatProduction" parameter (but without it having any previous value) and then you are trying to multiply by 2.5 essentially nothing. Edit: ninja'ed by @Padishar

@nickrulercreator from your detailed report and the provided logs your problem is <REDACTED> and can be fixed by <REDACTED>. Seriously, saying that you have an issue and not providing any means of debugging it is not going to help you. Post your KSP/Player.log and/or output.log so that we can see what the actual problem is.

Even better, replace the hard - coded "ModuleEnginesFX" with "ModuleEngines*" to cover both the old and the new engine modules.

@Gamax19 the problem is not the paths, the textures or the names but the model file itself.

Nothing really constructive to add but...there is so much win in this thread! @akron your work is absolutely amazing!

@crackerbal for the output_log: if you are using Windows then check if a log exists under the "%USERPROFILE%\AppData\LocalLow\Squad\Kerbal Space Program" path.

@Benji13 unfortunately i have no experience with modelling but the KSP version is not the problem (the .mu loader has not changed since ever).

Also, with Atlas V as the LV you can stuff Cygnus with more payload than Antares (7490 Kg vs 6170 Kg). That means you depend less on any followup resupply mission.

@Decus91 i am surprized that you can even launch the game with so many NullRef exceptions! Apart from having both the "BoulderCo" and "KSPRC" folders installed (remove the "BoulderCo" folder since it will confict with KSPRC) Steam has probably installed KSP 1.2.1 over your previous KSP version without cleaning up the leftover files. So: Unistall KSP completely (including deleting the "Kerbal Space Program" folder under "Steam/SteamApps/Common") Reinstall KSP Copy the "Kerbal Space Program" folder somewhere outside "Program Files (x86)" Reinstall your mods. Keep in mind that some of them are not yet updated for KSP 1.2.1.

@MissMolly RSS is not compatible with KSP 1.2.1 yet so that's normal. And no official patch/update has been released.

@NomenNescio can you remove Engine Lighting and try again?

Yep, you enter the name of the model file itself! Good to see someone actually taking their time and naming their models appropriately. Since you have changed the folder structure, be sure to double check the path to the model.

@COL.R.Neville because it is also "revision - locked". Changing the revision number and doing a recomplile is required.

The MODEL{} node requires also the correct path to the model. If this is wrong then KSP will never compile the part config correctly and the part will not appear. Assuming that the model resides under "StructuralDisks/Parts" and the model has the name "structuralDisk" then the MODEL node would be: MODEL { model = StructuralDisks/Parts/structuralDisk } If this fails then the problem stems from the model itself (it's structure might not be correct). Post a log so that we can check what the problem is.

and it will happen with every other addon texture pack. You will have to either edit your craft file to include the new texture definitions or rebuild your crafts. A way to circumvent this issue is to convert all texture definitions into Module Manager patches but this is upon to the modder that maintains each pack. The texture selection is a problem with Procedural Parts and not with the textures themselves. For some reason, PP will not refresh the texture list on a craft file if the texture definitions are simply added to the available pool (and not "edited - added" via Module Manager). It is a bit complicated. @Freedom has converted the texture definitions into Module Manager patches so they will probably be loaded correctly (but it may require to load the craft and save it again). No reason to cause any kind of performance loss (they are textures after all) and they are not outdated. Generally, PP textures are the most resilient mods.

Question: how difficult would be to implement a way to change the "node_attach" field? It is not an attachment node per se.

Please do not try to post the logs here! Upload them to a file sharing web service and post the link(s) instead.

No, it won't work with KSP 1.2.1.

Environmental Visual Enhancements. It exposes a small bug within KSP and that's the result.

@StevieC make sure that your Squad folder is properly updated (the issue was a texture name reference that was changed between KSP 1.1.3 and 1.2.1).

At least the G ASL (and probaly the gravitational constant) value have changed according to the KSP 1.2.1 release notes: * Fix CBs being in different places in 1.2 by adjusting GeeASL. So Kopernicus would be a bit broken if it worked in KSP 1.2.1 right now.