Youen

Here is the new version. It seems to work fine with stock aerodynamics when I tested with the stock Kerbal X craft, and also with FAR. However, I get NullReferenceExceptions related to DragCubeList.AddSurfaceDragDirection when I test with the Dynawing stock craft (and stock aero model). Probably an issue related to one of the parts in that craft. I'll release on Kerbal Stuff once this bug is fixed (to avoiding notifying too many people with a not-completely-stable version).

Thanks to atomicfury and BigFluffyTRex who pointed where the problem is. I'll test the fix and update ASAP.

Errr, so, does it work or not? If it works, I'd like to update the compatibility info, but I'm not playing KSP right now, so I'd be glad if someone could test that for me. @Kaleaze: should I assume you mean it doesn't work for the stock aerodynamic model? That could explain kendoka15 reports it works (with FAR)?

Maybe there is a bug, I haven't used that functionality a lot. Can you see the green cross correctly placed after entering the coordinates ? Or only if you use "set current impact". There is still the bug where the green cross is hidden under the ground so I hope you can see it in your case.

Yes, it's a known bug, I haven't got time to tackle it yet. And it is indeed really misleading (I failed an aerobrake because of it too, before I understood what was going on). Hopefully I'll be able to fix it in the next release. But I can't tell when that'll be. Somehow, it escaped being noted on github until now. - - - Updated - - - This has already been suggested, and looks like a good idea, but I'm not sure I'll have time to implement it. Anyone with a bit of programming skill is welcome to take a look and send me a pull request.

Makes sense, but how do you provide a global value that can be changed with MM? Is there another way than creating a KSPField on a PartModule (though that wouldn't be a too bad idea as I already have a PartModule that stores per-vessel trajectories settings)?

Indeed. As a workaround, you can use maneuver nodes to place the red cross where you want, and then set the target to the current impact. Or you can find out the longitude/latitude of the new space center, and enter them in the corresponding fields. And if you tell me what the location is, I should be able to hard-code it in future versions, to replace KSC location when RSS is detected.

That's definitely possible, but someone needs to take the time to implement it. Also, it would be best to account for all mods that have implemented airbrakes, and the stock ones, so that players don't get bad surprises once they think it just works (at this time, it just doesn't work ; unless FAR includes it as regular drag in its calculations, but I don't think it does). By the way, it's already in the wishlist of the OP. - - - Updated - - - Thanks for reporting the issue, I'll take a look when I find some time. EDIT: I've reproduced the issue with the latest version of FAR (don't know if it happened with the previous one). It's not a big issue since everything continues to work fine, but still bad for performances to trigger exceptions every frame, so I'll see what I can do. EDIT: bug fixed (in next release)

I think that, from a technical point of view, they can (and also format their computer or whatever, I don't think there are restrictions on what C# code can do, is it?). But an IP is not a reliable way to identify someone.

Actually it's as simple as adding ModuleManager.dll in whitelist.txt. I've just added a bug report on github so that jrodriguez can hopefully be notified of the issue if he is not following this thread.

... or it'll just get "unfixed". Looks like a stupid war to me. As the author does not seem active just right know, I'll take a look at his tool to see if I can white list Module Manager, but then I'll need him to update the OP anyway.

So if you don't know how to build a car, you should not be allowed to drive one, because some people don't respect traffic laws? Don't get me wrong, I think I understand what you mean, that some of those users who incorrectly report bugs also don't understand why they would or would not need to play with a 64 bits version. But still, if fear of ignorant users prevented people to release software that could be used incorrectly, there would be about no software at all ever released.

OK, so I suppose it's just a matter of adding it to the whitelist jrodriguez mentionned. This makes me think that adding indications in the log is a much better idea than blocking a mod completely, there would be no unfixer if all mods did this (so also no log removed by mistake). And a warning popup at startup (with a checkbox to disable it) would help make sure every user reads the bug report instructions. Again, maybe it already exists and I just don't know about it.

My personal opinion is that jrodriguez is doing nothing wrong (except removing the log thing, but that wasn't on purpose obviously). He wants to use mods, that are open source, on a different version of KSP, that's his right. It's also his right to distribute the thing so that others can do the same. Wether win 64 is worth playing or not is a matter of taste. Now, I also understand some modders are tired to get bug reports that have nothing to do with their work. Probably like Microsoft employees are probably tired to get bug reports of other Windows applications that have nothing to do with Windows bugs, web developers are tired to get internet explorer bug reports, and so on. The problem is that some users are not able to read, understand, and apply simple instructions (not necessarily there fault either, computer science is complicated, most people don't know what "64 bits" even means, and think they'll get better performance or other silly ideas). It's written everywhere, where win 64 related stuff is distributed, that "mod bugs" must be reproduced on 32 bits before posting. So if someone should be angry, in my opinion, it should be solely against these users that report bugs on the wrong forum thread. And even then, that's a whole part of software development to sort out which bug reports have to be discarded or not. There it was, just stating my opinion, please no-one take anything personnaly, because it isn't. Makes me a bit sad to see a clash here, because I only see dedicated and generous people in the KSP modding community :-) Also, I would kindly suggest to jrodriguez to add a clear (and very visible) statement on the OP to not report "mod bugs" found on unfixed versions of KSP (unless that's already the case when using the tool, I haven't tested it). And maybe make what's necessary to restore the sarbian log stuff?

I see no reason why it wouldn't work, but I haven't tested. Let me know if you have issues.

@Skalou: thanks for the link, I didn't read that yet. But it seems to work correctly since 1.4.2, a vessel made of a probe core covered with tens of RCS blocks is correctly predicted @Shattermage: the bug is fixed in version 1.4.3 that I just released

Does your ship contain struts or fuel ducts? I just made a test where I get errors with those (and only if FAR is not installed). Seems to be because they don't use a drag cube like other parts, but the spherical model. I'll fix that in the next release. Also, they were probably completely ignored in previous versions, which explains why you only have the bug now.

I've also fixed the following bugs: air density was not completely accurate (due to temperature changing for different latitudes), and mass of "physicsless" parts was not taken in account (they do not have drag, but still have a mass). I'm now quite confident that results will be accurate for the stock model (keep in mind that some situations are intrinsincly inaccurate, such as very long aerobrake trajectories, unstable crafts that can't keep the desired orientation, etc.). Version 1.4.2 is released on github and kerbal stuff.

I haven't investigated further yet, but I can confirm there is a huge difference between the predicted trajectory and the actual one with your ship. You're doing nothing wrong, it's a bug. I'll keep you posted if I find the cause (it's probably related to one or more of the parts you have on this vessel that are not correctly predicted). - - - Updated - - - OK, it's the FL-A10 and FL-A5 adapters (especially the FL-A5 is predicted to have drag much lower than what actually happens). I don't know yet why these parts don't work as expected. - - - Updated - - - I've fixed the bug and will published a release soon. These parts have the flag "PhysicsSignificance" set to 1 in the config file. I don't know exactly what that means, but it seems the effect is that they don't have an associated rigid body in the game, and the mod was ignoring drag on parts which don't have a rigid body. So the drag produced by these parts was simply ignored by the prediction, which cause the observed behavior. EDIT: it's actually more subtle than that. Parts have two members referencing a rigid body: Part.rb and Part.Rigidbody. One could think they are the same, but apparently sometimes Part.rb is null while Part.Rigidbody isn't. The correct one to test in this case seems to be Part.Rigidbody.

Just to make sure, did you use the latest version (1.4)? If not, try clicking the "update now" button just before reentry (this step should not be needed with 1.4) Also, can you post your .craft file so that I can check if I can reproduce the issue (with only stock parts would make my life easier)? Thanks.

Just to be sure : on the other thread you indicate "Windows 7 32bit", but here we're talking about the 64bit version, so on which version did you get the crash?

Have things evolved since then? It works almost flawlessly for me... Though I do occasionally wonder, when minor issues occur (so far: tweakscale parts not correctly scaled, and RCSFX sometimes not responding properly to inputs, and of course mouse click issues as reported by other players), if it is due to the 64bit version or not. Or am I just lucky?

D'oh. So an almost exactly identical tool as the one I made already existed. We're even using the same library to patch DLLs (Mono.Cecil).

I suppose you've already seen the existing "body fixed mode" in the Trajectories UI window? When enabled, it plots the trajectory relatively to the body, but it is displayed in space (in 3D). If I understand you correctly, what you want is the same thing, but projected on the planet surface instead? To check if the trajectory gets exactly above a point on the ground, you could align the camera with the center of the body (it is displayed if you zoom out a bit), and the point you want. Then you'll see if the 3D trajectory is above it or not. I'm not sure if projecting the trajectory on the ground would really help or just clutter the interface a bit more. - - - Updated - - - Oups I'll fix that asap.

I've released a new version here. If I get positive feedbacks (and no regression), I'll upload it to Kerbal Stuff as well. This version should fix the staging bug (where drag was not updated after detaching a part of the vessel), and also improve accuracy for prograde entries (related to the cache resolution that missed a point for AoA of 0°) Let me know if you still have prediction errors with stock aerodynamics (a .craft file would help, because everything I've tested on this version seems to be pretty accurate)