diomedea

m4v, can you please confirm if RCSBA v 0.6 should work with parts that use ModuleRCSFX? I have a few of those, and can't see them recognized currently. But believe interfacing with that module was going to be fixed, would like to know for sure if already done, before looking for other causes about those other parts not working.

I have studied what FlightTest modules expect in the config, and just began to table values about the stock engines to later be translated in a config file. However I'm just at the beginning and can't dedicate too much time in this at the moment. Will probably try to implement just a small subset at the start, starting with those parts available in the beginning in a career game, and progress from there.

Thanks Biotronic for all the efforts you did to let this great add-on available to the community. Pity time is never enough for all the things we love.

About landing planes, my approach is to follow a procedure as close as possible to what done in reality. I'm sure most of it will not sound foreign to you or others. Sure, need to have gear, or you're better with chuting above the runway. You have to know beforehand the lowest speed your plane can stay airborne and stable, of course at very low altitude. It pays to experiment to find out. During all approach and landing, you should never slow below the minimum speed. Also useful to know the Angle of Attack (AoA) to keep altitude at such slow speed. 1. Approach the runway from the sector you want to land (e.g. eastern to land on heading 270), reduce speed and descend. Call tower for landing authorization (ehm, not yet in KSP). 2. while still some Km out from the runway, you should aim to be aligned with it, or, to see the runway exactly at 270° bearing, and have the plane pointing that way. In reality your heading may differ to compensate for wind, not in stock KSP. The distance at you should be aligned depends from expertise, we don't follow mandatory approach procedures like in reality. 3. Also, you should aim for the correct slope. Let's say the correct slope is 2.5° (quite often used), that means to have altitude (above ground) of 440 m at 10 Km; 220m at 5 Km; and so on. Sum the altitude ASL (above sea level) of the runway (70 m for KSC runway), you get the altitude to read (510 m at 10 Km distance). 4. Fly the approach slowing to just a few m/s more than the minimum speed, always keeping aligned with the runway, and descending to follow the slope. If you have those, set your flaps. At a convenient distance (let's say, 5Km out) have your gear down and confirmed. 5. It is normal for a plane to require some AoA, or pitch up, to keep altitude at slow speeds. Let the plane assume the correct AoA while it slows down. Real pilots know the correct AoA for a given weight and speed, and the correct pitch is AoA - slope. The correct AoA also means the plane will touch down with the rear gear first. Don't slow too much, or the AoA will be too high and you may hit the runway with the tail. 6. If all the above went correctly, you should be slow just above the runway gate, aligned, ready for touch down. Different planes may require different ways to handle, I like when all required is just to cut the engine and let the plane descend those few meters while also slowing at the minimum speed. Touch down. Pitch down, apply brakes (apply reversed thrust if any), reset flaps. Let the plane roll until it almost stops and then drive it into the taxiway (not really required in KSP).

Much understandable. Really too many the engines to deal with (and then other parts too). But I'm happy to already see the add-on working, to get acquainted with it, and with the prospect of credible progress in the reliability of parts.

Thanks. Looking forward to that. Tried the P&W RL-10, Rocketdyne H-1, Rocketdyne LR-105. Possible other engines too, have not found any getting tracked by TestFlight yet. I'm not running the full list of RO recommended add-ons currently, just a minimum subset to check this. Got a pic of one test here, maybe useful. Nothing in the output_log to suggest a problem. EDIT: did a test with stock parts (not RO-modified) after having copied these config files from a dev version of TestFlight: "Squad_Engines.cfg" and "Squad_FuelTanks.cfg". Launched a rocket, and both tank and engine installed were recognised. Therefore confirmed TestFlight works, just a problem either with config or my install of RO to make parts not recognized.

Agathorn, many thanks for your detailed explanation. Of course it will take a bit of time to experiment, I can't be sure yet to have got it all right. But sure will come asking again in case. One thing I would know already about the repair mode (e.g. CanBeRepairedInFlight), those modes just mean a button wil appear to let the part be repaired upon clicking? I ask because would like to see the possibility that EVA is required to repair some parts. About the engines, I mean I'm not finding the stock engines configured, even if changed in RO. Not yet clear if that is because of a bad install. I did a couple tests building a vessel with one of those reconfigured engines, and in flight mode, TestFlight seems unable to find it (it gives a message on the MSD "TestFlight is not currently tracking any vessels", and I infer it is because no engine was recognized. Unclear if I should in some way make TestFlight look at the engine while in the Editor, I can't find an option for that.

Priceless! Thanks Padishar and cibutek .

Eh, happy to know that was the issue. I have myself always had doubts about the consequences (undocumented till now) of that change back in KSP 0.24, my math kept telling it couldn't be correct how it was depicted. And still I could not find a method to measure things so to let the exact rotation period be known.

Of course not everybody uses only the engines from RO. Even when I do use RO, I still have the stock engines (improved in realism because of all the add-ons dealing with them in RO), and still can use them. So, a bit surprised to not find any stock engine yet configured. Now, trying to figure how to build a config for those myself. The wiki is a nice way to show how, but at the moment I still can't find enough info to figure what to write (e.g., what the meaning of values with keys in TestFlightReliability module). Not a prob about the basic terms, I am pretty used to MTBF, Failure rates, MTTR, and all what makes the statistical aspects of reliability. Just the specifics of TestFlight modules so to start. Thanks.

wait, an add-on about test flying? Absolutely can't miss it. Test flying things in KSP is one of my major activities . Thanks a lot for it.

kitoban, you think could be possible and useful to change the appearance of the G scale on the right side of the Navball? I've always wondered why the scale goes down to -5G, as KSP only shows absolute (positive) G values (as could be the scalar value of the acceleration vector, independent of direction). IMHO, would be much more useful if the lower part could show an enlarged scale for low G values, and better if the whole G scale was logarithmic (so spacing would be greater for lower G values than for higher ones), so reading low Gs would become more accurate. Below a mock-up showing a log G scale close to the stock linear scale on the navball.

Just ask moderators in advance in case of doubt, as you see we are all keen to provide suggestions so that rules are respected.

With the latest RPM 0.19 dev build, my RPM-MJ integration works fine. Nicely done, and thanks again:).

On the subject of ways to remember maneuvering keys, even after hundreds manual dockings (with or without DPAI), I must take a moment to remember how to use the IK translation keys. All others are really second nature. It would take no time to reverse those in the KSP settings to K= translate down, and I= translate up, and have everything work as could be expected during a docking. My laziness to not have tried. But really, what was the logic for that choice as the KSP default? just to mimic the WASD keys? (where the S=pitch up, W=pitch down have sense because they act similar to plane controls?). Can't see one reason why IK shouldn't be KI instead, and allow easier dockings for new players or old farts with memory leaks. Now, please let me be the last to have gone out of subject. Why not go back to discuss the wonders of DPAI on this thread?

Many thanks for your help. Was using your update over a RPM 0.18.3, anyway installed the dev19 version you suggested. Unfortunately, same result, that autopilot page seems completely frozen on the first menu, only other page selection buttons work, and the exception in the log still shows. MechJeb seems correctly installed, and works on its own. RPM seems to be installed correctly (according to the folder structure) and all other add-ons interact with it flawlessly. Of course ModuleManager (v. 2.5.9) is installed. Even had a look in the MFD40x20.cfg, but nothing tells me an error exists in there (page 'D' has the Pagehandler set to MechJebRPM, that seems should do fine with the MechJebRPM.dll in the RPM install). Can't discount at this time that specific MJ version (2.4.2.0-399) has an issue, but before asking for help in the MJ camp I would like to be sure all is normal with RPM.

Believe RPM should allow integration of MechJeb. And indeed, with the 18.3 package, a MechJebRPM.dll is included, certainly for that purpose. I have RPM (updated to 18.3) and MechJeb (2.4.2.0-399) (plus some more add-ons that integrate in RPM: VesselView, SCANsat, DPAI 6, all working). But RPM only shows a menu about the autopilot, where no button/selection work, while this Exception is raised each time I try something with that page: Any idea what could be wrong?

Did the test according to the procedure by Arrowstar. Longitude from KER = 67° 59' 16" E; from KSPTOT MA (imported initial state from quicksave.sfs) = 67.9049 --> 67° 54' 18" E. Longitude difference = 0° 4' 58", quite probably entirely due to slack in pausing KSP while quicksaving. Had a quick look at your SFS file, apparently nothing out of order in there. However, the fact it has been in use for such a long time may provide a reason for the discrepancy. One possible cause may be related to the alleged change in time reference for Kerbin's solar day in KSP 0.24 (now exactly 6h, or 21600 sec long) while before 0.24 it was the sidereal day to be 21600 sec long. That change should bring a difference of 59 sec/day (exactly 59"/day in longitude), that can easily cumulate to many degrees over months of gametime. However, can't tell if this is your case. Alla SFS files save a time marker (UT = ... in the Flightstate section) and vessels' positions are valid for that time; therefore if the marker significance had changed because of the change, any vessel already in game would have the position coordinates referenced to a different time. That change in the sidereal day duration means that a specific point on Kerbin (e.g. KSC, but also the meridian at 0° longitude) is now pointing in the same sidereal direction every 21541 sec instead of 21600, so the reference for longitude rotates at a different speed; but because longitude (coordinate with all saved vessels in the SFS) is tied to their reference body, those vessels there were orbiting Kerbin would be in a different sidereal position after the update to KSP 0.24 than before. Unclear however how the change may affect vessels launched after the update, or vessels that never left Kerbin's SoI.

Testing DPAI 6 RC3. Have a number of DivideByZeroExceptions raised in the log, e.g. However, not found (yet) any missing or misbehaving functionality with DPAI. Doing dockings while in IVA (with RPM + DPAI) is very immersive .

Unlike all KSPTOT releases running on MCR 2013a (always requiring to be launched twice to run on my system), no prob starting KSPTOT 12.0 on MCR 2014b 64bit. Once loaded, KSPTOT 12.0 has some weird RAM allocation. RAM effectively used (private bytes) is ~ 650KB, but RAM allocated to the program (virtual size) is > 4,600KB. Seems like MCR is enjoying too much the RAM available on a 64bit system . Lines and coloured areas show much better on MCR 2014b (IMO). Could not see any issue with fonts, in any part of the UI, everything seems nice. Tried some basic functionalities (porkchop plotting, multiple flyby, 2-burn maneuvers), all seems to work well and even somewhat faster (e.g., a simple Kerbin-Duna transfer porkchop takes ~11 sec. to complete calculations with KSPTOT 11.x; ~ 8 sec. with KSPTOT 12.0). No issue with saving or loading mission files with MA. Of course had to give KSPTOT 12.0 rights to write and read files on my system, but then it worked like a charm.

Sure some good advice in that. You got what I mean, N finite maneuvers to provide a total DV as planned for a single impulsive burn. Though, time taken to execute those N maneuvers must be considered, or the resulting trajectory will miss the target. Of course I'd much prefer if an automated solution was possible, even if that required optimization in steps. While relatively simple, manual splitting burns requires some computation about the max DV achievable with each burn. That means going in that tedious repetitive process (determine time to travel the elliptical arc at periapsis; determine DV achieved during that finite time; update orbital params; repeat until total achievable DV >= required DV), unless KSPTOT MA optimization is enough to correct wild estimates a user may provide about the DV at each burn. I'll go with the first approach and a spreadsheet. However one optimization I see MA should be used for is about the total time required for the maneuver. I mean, if I strive for maximum distance at apoapsis, I'll just get the burn going for as long as possible within the acceptable arc, can't see a reason why MA shouldn't; but it shouldn't if the result is to bring the craft on a very eccentric orbit at the N-1 burn, and have a long time to travel that orbit just to perform a smaller final burn at the Nth burn: a better solution would be to optimize duration in reverse, applying the longer possible burns at the Nth step and going down, so to result in lower orbits before and a lower total time. Then, I think I may have a problem. You made a good example telling total DV for getting in the transfer orbit = 2000 m/s. However, after I burned 950 m/s my craft is already about to leave Kerbin's SoI, therefore no more periapsis passages. That means my craft will have to keep burning while on the outgoing leg from Kerbin to provide the remaining 1050 m/s. But what direction? For efficiency, I want it already aimed so to only need a prograde burn. And this is where really I need MA to optimize, it should choose the timing of the previous burns so that the ejection vector is aligned for that final burn to get the craft on the transfer route. Now, how better to give conditions to MA for this kind of optimization? The final direction solution reverberates back with all the previous burns until each one timing and vector are optimized, so I can't think optimizing a single stage at a time could be effective. Well, you told something's hard about this problem. Doesn't seem to me it belongs to the NP-complete class, however it may require more than the usual computational power to solve, possibly some extensive parallel computing. Doable within the limits of MA routines?

Hi immelman. Yes pretty much you are right, KSPTOT works with any star system but needs the bodies parameters, from a "bodies.ini" file it has in its root folder. The "bodies.ini" that comes with the standard KSPTOT distro is about the stock Kerbol system. For any other star system (including RSS) there is a nice utility from KSPTOT main menu/file/"Create New Bodies File From KSP". You must have KSPTOT Connect correctly installed within the KSP GameData folder, and have that KSP install running for that to work.

Indeed, I did not even formulate a question . But you're right, I'm looking for more info about a capability I would like to see with KSPTOT MA. Actually, what I described is the way I would manually plan a split-burn maneuver. Clearly that is only required for low-thrust continuous burns. It's a tedious process, though not terribly difficult, to do in KSP. However, the duration of the whole maneuver can be relatively long (from first to the last of the burns, because those are executed on subsequent enlarging orbits), and therefore this maneuver must be started such amount of time earlier, or the subsequent transfer after escape will bring the craft where the target was that time earlier - probably an error enough to completely miss the intercept. Or, the transfer should account for that delay, therefore aiming since the escape to a different point in space. Now, unless I missed something (very possible), I should be able to use MA to plan the single 9 (or more) burns required, tie them with the target intercept, optimize and have a solution ready to be used in KSP. But while MA would allow the precision I need, planning burns that way remains a tedious process. And I'm far from certain that I may be able to optimize the duration of each single burn that way. Therefore I'd like if, with the "finite-duration" burns now possible (allowing to use low-thrust engined crafts), KSPTOT MA would also allow to directly plan the split-burn maneuvers (that said crafts will have to use). Would be nice if the user could just make a single entry in the event list and let MA create the single split burns as needed to achieve the final DV required.

Sorry my bad. Next infraction will be issued to my sticking shift key .

SUre, we know when he awakes and get to fight him!