druidjaidan

I wouldn't necessarily go that far. The great thing about open source and in particular when combined with github is it's pretty easy for someone to pick it up and run with it: https://github.com/Jaidan/RemoteTech2 That has the the burn time fixes provided by both marce (I even de-uglified it) and the hotfix from madadam. Now the artwork isn't under an open license so actually providing a packaged mod isn't really allowed without permission from the creators of the artwork. I think there are enough people interested to keep it alive. The real issue is that Cliph has hinted at an existing rewrite(which could be a good thing I don't know what/why his motivation for the rewrite was), which has made people super hesitant to do anything other than hack hotfixes into place. I mean the hotfix from madadam doesn't actually try to fix the issue, it just comments out a performance enhancement and replaces it with recalculating the same value potentially multiple times. I wouldn't expect anyone to bother with a 0.23.5 release. If any major issues or fixes come up I'm sure the community can come up with patched dll's. I'll likely merge any fixes that look completely baked just so I can keep a stable copy myself. If Cliph hasn't come forward with the rewrite by 0.24 I would expect someone to really try and take point, but what is out there now works.

here is the PR that represents the community hotfix https://github.com/madadam/RemoteTech2/tree/quick-and-dirty-fix

https://github.com/Cilph/RemoteTech2/issues/241 Cliph isn't providing it so far. I've been considering forking the project myself I'd like to work on it a bit, but if he really has this massive rewrite that the other devs want to work on there is little point in getting started on the current one. It's kinda frustrating, I want to help get this project moving along myself, but without the "current" source it kinda ties everyone's hands. I'm not sure I see any huge issues in the existing source that we could just fork from what is on github and run with it, but as I don't think that Cliph will even be processing pull requests I don't see a reason to try to commit time to it until things have been worked out.

You are [word we don't say on the forum] awesome. This is the bug I tried reporting a few pages back. I looked at the source as well and it all looked in order. I didn't think about HotRockets causing the module to change. Also...the source is available on Github: https://github.com/Cilph/RemoteTech2

I'm having some major huge issues with the flight computer being basically completely unusable and I'm curious if there is something I'm missing. The major issues I'm seeing: When selecting a attitude hold mode (NODE for example), this ship will wildly rotate toward the node vector, but will massively overshoot it. Appears to be failing to account for maximum torque vs current angular momentum or something. I can tell from the code that it attempts to prevent this issue, but it is failing miserably as far as I can tell. I overshoot the maneuver node by 60-70 degrees and begin oscillating around the node After settling on the node (using time warp to freeze rotation). Sometimes when either new command is added or coming out of warp the computer will decide I'm no longer aligned and (particularly common with the GRD+/- vectors) my orientation will be slightly off and the ship will rotate aggressively....in the opposite direction of the vector. Maneuver node execution fails to account for delay when calculating burn time and so executes late Canceling a maneuver node causes the gui to crash when opening the flight computer queue. Log shows a spew of: [Exception]: OverflowException: Outside range [MinValue,MaxValue] Maneuver node execution lacks ability to control accuracy. Worse when combined with the above attitude hold causes oscillation issue, maneuver node execution ends up completely broken. When the craft gets down to the last few m/s and the node begins to drift the ship thrashes about wildly as it tries to follow the node.

Other than the community likely would contribute more to a Mono based project (simply because of knowledge), I'm not sure what benefit would be seen by doing this in Mono over Java (or really any other cross platform framework).