Jump to content

[PART, 1.0.2] Anatid Robotics / MuMech - MechJeb - Autopilot - Historical thread


r4m0n

Recommended Posts

Hey Sarbian, theres a new FAR update, so I don't know if theres any changes that would affect the FAR extension for MechJeb? Basically just wondering if that needs to be updated, maybe it doesn't.

Link to comment
Share on other sites

Can't imagine not--the version of FAR changed, so this needs a recompile AIUI.

Well, it seems fine though. It's not throwing exceptions at any rate, at least none that show up on exception detector.

Link to comment
Share on other sites

Theres kind of a major problem going on with MechJeb (it's also killing the exception detector window, I figured that out by removing things that I updated recently, including MJ, but that's not even major), I noticed that it's showing the same deltaV numbers for both atmosphere and vacuum.

I thought maybe it was the updated FAR since I installed that recently and it was throwing exceptions about FARextension, but theres another one that it's throwing. Also, I checked with the previous version of FAR and it still does that there:


Non platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\MechJeb2\Plugins\MechJeb2.dll (this message is harmless)
Non platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\JSI\RasterPropMonitor\Plugins\RasterPropMonitor.dll (this message is harmless)
Non platform assembly: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\JSI\RasterPropMonitor\Plugins\MechJebRPM.dll (this message is harmless)
AssemblyLoader: Exception loading 'MechJebRPM': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.

at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)

at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0

at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0

Additional information about this exception:

System.TypeLoadException: Could not load type 'MechJebRPM.MechJebRPMVariables' from assembly 'MechJebRPM, Version=0.17.0.0, Culture=neutral, PublicKeyToken=null'.

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

and


MechJeb moduleRegistry creation threw an exception in LoadComputerModules loading MechJebRPM, Version=0.17.0.0, Culture=neutral, PublicKeyToken=null: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.

at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)

at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0

at MuMech.MechJebCore.LoadComputerModules () [0x00000] in <filename unknown>:0

Currently doing some investigation to narrow down a cause (besides Raster Prop Monitor) and see what dev version broke.

Edit: Without RPM, the exception detector window works now, but the deltaV is still borked. Also, it works fine in VAB/SPH (although it suddenly decided to have the sidebar button not work after I switched the deltaV window on and off to see if it was fine, but after making a new craft, it worked *shrug*), but when I go to flight mode, it breaks. The only MJ exception that I saw was one that it caught.

Edit2: Build 418 works, so, whatever broke, broke in 419 since 420 was still broken. It hasn't thrown an exception about the FARextension, yet.

Edit3: Oh, for some reason, when using 'land somewhere' (dev 418), the throttle indicator doesn't move when autopilot is using the engines, which is wierd. Seems to work normally though.

Edited by smjjames
Link to comment
Share on other sites

Since I am overshooting on small maneuvers with high thrust engines alot recently, I was wondering if there is a setting somewhere in MJ2 that makes it start burning maneuver nodes with low thrust and increases thrust up from there, instead of thrusting fully and decrease from full speed to low speed? Or have it see somehow "oh what a cute little maneuver, I´ll burn this with throttle at 1%" :D

On longer burns, if the maneuver node starts wandering off, it also helps alot to decrease thrust to avoid having to turn the ship several times and burn again. I have absolutely no idea if mechjeb could detect this and automatically decrease speed in such cases.

Right now I need to use the Util´s section "limit throttle to" function a lot and - not being that young anymore - I keep forgetting to remove that setting all the time :/

Link to comment
Share on other sites

Since I am overshooting on small maneuvers with high thrust engines alot recently, I was wondering if there is a setting somewhere in MJ2 that makes it start burning maneuver nodes with low thrust and increases thrust up from there, instead of thrusting fully and decrease from full speed to low speed? Or have it see somehow "oh what a cute little maneuver, I´ll burn this with throttle at 1%" :D

On longer burns, if the maneuver node starts wandering off, it also helps alot to decrease thrust to avoid having to turn the ship several times and burn again. I have absolutely no idea if mechjeb could detect this and automatically decrease speed in such cases.

Right now I need to use the Util´s section "limit throttle to" function a lot and - not being that young anymore - I keep forgetting to remove that setting all the time :/

Which engines are you using and how small a maneuver are you talking about?

Link to comment
Share on other sites

Since I am overshooting on small maneuvers with high thrust engines alot recently, I was wondering if there is a setting somewhere in MJ2 that makes it start burning maneuver nodes with low thrust and increases thrust up from there, instead of thrusting fully and decrease from full speed to low speed? Or have it see somehow "oh what a cute little maneuver, I´ll burn this with throttle at 1%" :D

What I find myself wanting is "oh, what a cute maneuver. Let's just use RCS translation and not bother turning first". Particularly for the plane change maneuvers done by the rendezvous autopilot; when it's only a 2m/s burn to fix the plane it seems like you burn more RCS deltaV rotating the ship 90 degrees to normal/antinormal and back again than you would from just doing an RCS translate burn.

Link to comment
Share on other sites

What I find myself wanting is "oh, what a cute maneuver. Let's just use RCS translation and not bother turning first". Particularly for the plane change maneuvers done by the rendezvous autopilot; when it's only a 2m/s burn to fix the plane it seems like you burn more RCS deltaV rotating the ship 90 degrees to normal/antinormal and back again than you would from just doing an RCS translate burn.

I thought about that too, but I realized that not every craft has RCS on them, some rely on their reaction wheels. I would like that too anyway if it got included!

Edited by DaniDE
Link to comment
Share on other sites

Some of the code for rcs burn is already here. What is missing is the burn backward stuff.

Right now I am focused on code performance and then I guess I ll be busy with the 1.0 change. If someone send me a patch that improve RCS burn I ll gladly merge it, if not you ll have to wait for me to find the time :)

Link to comment
Share on other sites

Houston, I've got a problem. A really weird one. I don't know if it's MechJeb's fault but it occurs when I use it. The problem 100% reproduces for me.

http://s000.tinyupload.com/index.php?file_id=00814646842525635034 This archive contains my game save file, KSP's and MJ's configuration files and KSP.log.

How to reproduce:

0. KSP 0.90 (32 bit), MJ #421 (#414 does this, too, I've upgraded it to the very last dev build but no luck), no other addons.

1. Load the game.

2. Via Tracking Station, go to "Laythe Lifter Ship", it's landed on Laythe.

3. In MJ's ascend autopilot, click "Launch to rendezvous" and "Engage autopilot".

4. The problem is: in about 30 seconds after liftoff, something triggers decouplers.

All the autostaging options are turned off (either this or I'm blind). The decoupled stage contains loads of fuel/oxidizer. The problem does not occur if the ship is launched not "to rendezvous" but just to some orbit. I'm confused as heck.

Link to comment
Share on other sites

Well documented bug are so easy to fix :)

The new dev build should fix your problem. All the timed launch assumed a bit too much that we had to do an initial staging to get some engines running. Now it only does it if there is no engines active.

Link to comment
Share on other sites

Thank you Mr. sarbian sir, with #422 unexpected staging doesn't occur anymore. Still can't rendezvous in one move, though. The autopilot just establishes some orbit not even in the target's plane. It probably just can't do it's work when launching from random location, or I'm doing something wrong. Never mind, Jeb Kerman is smart enough to do some things manually so it's not a problem. He's back home now, safe and sound, thank you again for your great creation, porkchop transfers rock :D

Link to comment
Share on other sites

Thank you Mr. sarbian sir, with #422 unexpected staging doesn't occur anymore. Still can't rendezvous in one move, though. The autopilot just establishes some orbit not even in the target's plane. It probably just can't do it's work when launching from random location, or I'm doing something wrong. Never mind, Jeb Kerman is smart enough to do some things manually so it's not a problem. He's back home now, safe and sound, thank you again for your great creation, porkchop transfers rock :D

The problem is that it has no reference to know how your craft performs an ascent from that planet. That's why you have to do a normal non-rendezvous ascent with it first from Kerbin for it to work there initially. I believe you can force it to learn by saving, "Mark"ing the launch and complete the ascent then reload that save and launching to rendezvous.

Link to comment
Share on other sites

The problem is that it has no reference to know how your craft performs an ascent from that planet. That's why you have to do a normal non-rendezvous ascent with it first from Kerbin for it to work there initially. I believe you can force it to learn by saving, "Mark"ing the launch and complete the ascent then reload that save and launching to rendezvous.

Well, in my particular case it seems more troublesome than useful, so I don't want and most probably won't do it. Thank you for your advice anyway, it's always good to know such things.

Link to comment
Share on other sites

I pushed a new Dev (#423) with all the performance change for the DeltaV simulations.

Before those last change the KER sim would use about 1MB (450KB for the PrepareSimulation and 600KB for the RunSimulation) per run for a KerbalX.

After the last code change it now uses about 7KB ( 0.9KN + 6 + some more) par run for the same KerbalX

I could have broken something but so far I did not see any difference in the numbers.

Here is some screenshot of my GCMonitor :

Before (#417)

MJMemBefore.png

After (#423)

MJMemAfter.png

Link to comment
Share on other sites

I pushed a new Dev (#423) with all the performance change for the DeltaV simulations.

Before those last change the KER sim would use about 1MB (450KB for the PrepareSimulation and 600KB for the RunSimulation) per run for a KerbalX.

After the last code change it now uses about 7KB ( 0.9KN + 6 + some more) par run for the same KerbalX

Nice work!

Link to comment
Share on other sites

I had to revert one of the codez change after I noticed an error. I m not suprised since this once the most complex one to change. I ll rework it an other day.

smjjames : yes, I found the origin. Not sure I will really fix the root.

Is there really a point to see the atmo stats when you are in flight ? Right now when in fligh you get the current stat for both mode (so atmo = vacum while in flight)

Link to comment
Share on other sites

Thank you Mr. sarbian sir, with #422 unexpected staging doesn't occur anymore. Still can't rendezvous in one move, though. The autopilot just establishes some orbit not even in the target's plane. It probably just can't do it's work when launching from random location, or I'm doing something wrong. Never mind, Jeb Kerman is smart enough to do some things manually so it's not a problem. He's back home now, safe and sound, thank you again for your great creation, porkchop transfers rock :D

Launching to rendezvous with a target in a non-equatorial orbit is going to be problematic any way you slice it. The launch must occur when the target orbit is almost directly overhead, which only happens twice a day (and days are looong on Laythe). The odds are very much against the target being in the right position for a direct rendezvous at one of those exact times. Best to just launch into the plane of the target and rendezvous after orbit is established.

Link to comment
Share on other sites

I had to revert one of the codez change after I noticed an error. I m not suprised since this once the most complex one to change. I ll rework it an other day.

smjjames : yes, I found the origin. Not sure I will really fix the root.

Is there really a point to see the atmo stats when you are in flight ? Right now when in fligh you get the current stat for both mode (so atmo = vacum while in flight)

On the deltaV thing, okay fine, but what about MJ throwing an error at RPM (and breaking exceptiondetector in the proccess)?

Edit: It's still doing that error and breaking RPM. Actually, now that I look at it, I'm not so sure that it's origionating from MJ, but could you look into it?

Edited by smjjames
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...