NathanKell

Brian--Griffin: welcome to the forum! That's because in stock KSP drag is proportional to mass! (Weird, right?) Every part has a drag coefficient, a part's drag force is equal to its drag coefficient times its mass, and the way stock parachutes work is that when deployed they just increase the drag coefficient to the specified value from the default (usually 0.2).

Ok--good luck with RL!

This would be because the only time the original part.cfg is passed to OnLoad is when the part prefab is created. Every other time a part is instantiated (and OnLoad for its modules is called), it's reading data from persistence to modify the part from the prefab's settings (i.e. loading a craft, or loading a vessel in flight from sfs--they are the same format because they're doing the same thing, storing the only bits of data that change from the part.cfg). If you really, really, really need to see that data again in OnLoad, flag it as persistent=true. That will make OnSave save it to .craft/.sfs, which means it will be there for OnLoad. To go back a bit: when you load a craft (in VAB/SPH, in flight, whatever) the part objects (and their modules) aren't created de novo. Instead, only one "prefab" of each object is created at KSP start: one prefab part per PART, with prefab modules per MODULE. Then, when the game actually wants to put a part "into action" (loading a vessel into flight [off rails], loading a vessel in the editor) it's cloned from the prefab, and any "persistent" settings are loaded to override the prefab setting. Conversely, whenever a part is saved to ConfigNode (vessel goes on rails, game is saved, craft is saved in editor, etc) then only persistent settings are written to ConfigNode; any members of your module (or any other module) that are not persistent=true KSPFields will not get saved, and will therefore return to their prefab values the next time the object is cloned. What makes this harder, of course, is that KSP isn't very good about cloning data from the prefab into the instantiated partmodule. So sometimes you need to use workarounds.

jrandom: that works for RO, but as the anti-FARites will tell you, gameplay before realism. That's why I'm asking what price people suggest--I honestly have no idea how things ought to be balanced for (mostly) stock KSP. lanceo90: just a recompile, basically. Despite my fears, .24 didn't change anything regarding kerbals to break DRE's killing of them (AFAIK).

RF is not yet updated for .24. There's some issues with auto-fill and not being able to remove resources.

Yes! I am happy to take suggestions for reasonable part costs.

Yeah, supporting this sort of thing is a ton of work! (In part that's why we created the official thread, because it's work the modders, who actually know the internals of the mods in question, are used to). I appreciate your starting this thread, but if you want me to close it and redirect people to the official thread, that's fine, no problem. As "modder-ator" I already volunteered myself to do this sort of thing. :]

Error downloading log. Thanks for the report, will test.

Ok, specific comments then. 1. Include a link to the official thread in the OP. 2. Rename "Confirmed Working" to "Has been tested, Seems to work - no issue reports yet" Create a new Confirmed Working category and use the same criterion as the official thread (no errors in output log (NOT KSP.log!) from the mod, after at least a day's playing with the mod. If you don't know how to check this, I will write up a guide for you.). 3. If the mod does not include, or rely on, any plugins (e.g. RLA Stockalikes, KW Rocketry), that also can go in Confirmed Working. If you're in doubt whether a mod has or requires a plugin, and you do not have confirmation in the form of (2), then it should not go in Confirmed. 4. Always include a version number with a report, and include a version number in the OP. Do *not* accept "It's working!" posts from people unless the above has been followed. Do not accept "It's broken!" from people unless Majiir's rules (from the official thread) are followed.

This thread *continues* to report mods as "confirmed working" that are known to have problem. Again, just because a mod author hasn't implemented a compatibility check (i.e. there is no warning on KSP start) does not mean that a mod is compatible, even if you see no obvious signs of problems during gameplay. Please fix this. You are spreading misinformation.

This is dependent on KAE, and even with taniwha's fixes to KAE and both that and this compiled for .24 there are still sporadic issues. It needs to be fixed, it's not just a case of "recompile for the new release." Patience, please.

You would think so. But in FAR. where the dialogs defaulted to off, people still complained that the mere fact they were there was confusing. Many, many people. So, removed.

That's stock KSP. When there is no root part, camera controls don't work. Add a part again (click on any part) and camera controls will work again.

https://github.com/NathanKell/DeadlyReentry/releases I never remove releases.

Those sliders are made with KAE, so it's not surprising they're not working...

1. Yes. You can set maxTechLevel. 2. As I said, check out Realism Overhaul. That's where the Modular Engines configs for RCS are.

nebuchadnezzar: it will have them as soon as reports start flowing in. I will add the ones I know. Helix935, now that there is an official thread, I have taken the liberty of removing "semi-official" from the title. Hope that's ok!

So, apologies. While I have a working version of the code for .24 x64, I've decided to hold off on uploading because I want to fully integrate the amazing new planet maps that dimonnomid has prepared, and to do that requires (a) tweaking the code a bit more, ( rearranging the planets (so this will require either a new save or some SFS editing if you have craft in orbit around the affected planets), and © another round of testing. If you are desperate to get RSS working in .24 I can PM you preview code, but I encourage you to wait; the rest of the realism suite needs updating too.

I know crew objects got changed a fair bit, but I'll let TaranisElsu (who knows about that) chime in. I do know, though I forget who discovered this, that MonoBehaviour defaults to having its bool enabled member be false. You need to set it = true in Start() or various methods (including OnGUI!) won't be called.

Ok, fair enough. ( But you don't have to deal with the support requests )

But there have been enough changes with the exact things that PF (in particular) uses that I really wouldn't suggest that. Also there's the fact that it's still got issues, which you can verify by checking your output log after using it for a while. So...I really wouldn't recommend it.

And you might have broken PF, since as I said in that very post giving the link that download is for developers only. Do not go changing a plugin's KAE; it's compiled against that, and any change to KAE will probably break it in invisible ways.

jpkermin: Sounds like this in the Dev forum might well be the mod you're looking for.

Glad to oblige! I haven't done *that* much testing, so let me know if you hit any bugs. But it does seem to work fine.

For the love of the kraken, please don't assume that just because you don't get a "This mod is incompatible" message, that the mod is compatible. Quite the reverse: it means there's no compatibility information in the mod, and therefore you should assume it is not compatible. Part packs are exempt if they don't rely on plugins. If the plugin works perfectly under testing, and throws no errors in the output log, only *then* should you rate it as compatible.