NathanKell

While root and tip chord, span, and sweep angle at leading edge would be great, the current system works pretty well. Although that *would* solve the issue with tweakables where you can't select < 0.36 thickness and it jumps to .1; swamp_ig rewrote that for KAE.

Phredward: link updated.

krenshala: I apologize for coming down like a ton of bricks, and rather than belabor the point I will take Starwaster's advice and merely direct you to the official "Known Issues in .24x64" thread, which has a link to a mod Sarbian created to fix this stock bug. There is literally nothing in my code that affects decouplers, let alone decoupler force. So there is nothing for me to change. chaos_forge: you can change the rescaling of the 2m one to be 2.5m if you want. Godot: huh. That's been working fine for me. It is done by DRE, yes. That makes me wonder if you have an install issue and DRE isn't running right.

It already was applied to craft files, when it was enabled.

I'll get to this when I finish RF etc. The .23.5 version mostly works, so I don't think it'll need too much fixing.

I have. I just need to package it. Oh, and test it.

node.name is the name of the node (the thing that starts the node) like PART. node.GetValue("name") is the actual value of the key "name" that is inside the node, i.e. liquidEngine1-1

Yeah, I'm very sorry. There's only so much I can do in a day though. RSS v7 is about to be released. I can now focus on getting RF and this working.

the patched MM file toadicus posted appears to only work if you *do* have TweakableEverything.

NEAR needs the same level of cfg-making FAR does: all wings and control surfaces need the appropriate module with the appropriately-calculated stats added. The part classification is for stress damage of parts, which is disabled in NEAR anyway.

No, we can't really dig into KSP's guts and replace Squad's own code. The way the MM patch works is by telling KSP to run our code instead.

Oh, I do too. But if you have a git client, you probably have bash anyway. And even if not, cygwin's great.

Since the graph is there to show the relation of the coefficient, it makes sense that ref area isn't multiplied in. Renegade: you've convinced me it's time for someone to make SJE. I can't right now, but I will in a week or so if no one has by then. Meanwhile, 40kN base, ~70 at maximum velocity sounds fine to me; that will put it in J79 range, although it'll be underpowered at high speed at sea level, and overpowered at low speed at altitude.

Get all those files (and the ones in the folders). Click each file. Right-click "Raw" and choose to save the link as. Replace your existing copies. Ninja'd, except for the raw bit. You can't just right-click the links, you have to actually click each file and then click raw.

Kolago: yes. Use this. https://github.com/NathanKell/MechJebKMGimbalExt dtobi: you might want to consider including this--r4m0n hasn't had a chance to add it to MJ2 jenkins yet.

Each mesh is a render call. Render calls are expensive. Use as few meshes as possible (i.e. only when you need a different material). For that reason and also for reasons of not changing the texture state, it's best to use texture atlases rather than lots of small textures.

Rakird: it's hard enough supporting a mod this big for the version that *is* supported. Now you're asking modders to delay making RO supported in .24...by showing you how to hack around to get it to partially work in .24. If a modder hasn't mentioned whether their mod is .24 compatible, then it makes sense to ask about how to make it such. If they've explicitly told you it's not, you're not likely to get a helpful (or polite) response by asking them anyway...

It's not 64bit being unstable per se, it's that the way in which KSP handles decoupling right now fails on 64bit (but not 100% of the time). Check the Known .24x64 Issues thread for details, and a link to Sarbian's workaround mod. Re: the pack itself: amazing work (as always)! Looks absolutely stunning! Re: scaling. I thought Kyle said he fixed all the use of non-1.0 rescaleFactor? It's not that hard: just multiply the scale inside the MODEL node by rescaleFactor, multiply the first three digits of all node_ lines by rescaleFactor, and set rescaleFactor to 1.0. Heck, you could write a script to do it if you don't want to do it yourself. That would fix all those scaling bugs.

You can do it with a shell script. Also, you could just ignore the actual KSP libs, not *.dll. But seriously, it's easy enough for me to recompile; don't do it if it slows you down.

Works fine for any part ever: it will show that part's divergence from world XYZ.

I am now unlocking this thread and delivering a CHILL PILL ( © KSPforums). While it is acceptable to register one's disappointment with the fact that this mod includes ModStatistics, it is not acceptable to insult other members of this forum, nor do the latter in defense of another member. For this reason those posts have been excised, as have those posts that solely refer to them. Further, the issue of ModStatistics is a heated one right now. The actual thread, and two more threads, have been locked due to them becoming flamewars. That is not something we want to see, and we certainly don't want to see it spread to this thread. Majiir has been in contact with Squad and with the moderators here, and we will be speaking with him more. This issue will be resolved. I ask you to please exercise patience; if you don't want ModStatistics reporting information, create that config file. I guarantee to you it works right now, and I guarantee to you we will know if it stops working. If you don't want to have ModStatistics anywhere near your system, please read the OP of the mod you are about to download; the ModStatistics license requires that the OP notify you if it is included. Finally, a general advisory note: I find that this forum, along with many other endeavors, runs much better if we assume that others are well-intentioned, and if we begin by trying to persuade rather than by trying to excoriate. Please keep that in mind always, but especially when addressing so sensitive an issue as ModStatistics is right now. So, about those wings...

They're bit by the x64 decoupler bug. Known issue. Sarbian wrote some code to replace regular decouplers, but e-dog is using a custom-built one so he will need to switch his code to using Sarbian's.

I'm not asking you if removing DRE fixes the problem. I'm asking you to replicate the problem on stock KSP with only DRE installed.

Also there's the fact that .24 has serious issues regarding cost: there's no support for per-part costs (so procedural / techlevelable / engine-mode-configable / tweakscalable parts aren't supported) and resources don't add cost to parts, they subtract cost when the tanks aren't full. (???) The best answer here is "push Squad for a .24.1 that fixes these issues, and the other serious issues"

Since the file was last changed 2 months ago (when it was created for .23.5) I'd say it does. :]