Jump to content

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

r4m0n

By r4m0n
in KSP1 Mod Releases

 Share

Recommended Posts

mwlue

mwlue

Posted
Posted
Do you get the same null ref errors using MJ dev build 192? That's what I'm currently using for RPM development, and I'm not getting the null ref errors. It looks like there was a change in MJ 193 that might could be a problem for RPM, but I'm at work right now, so I won't be able to dig into it until later.

I haven't tried 192, i update straight from 183 to 193, noticed the null reference then try 194.......

183 was working fine with all the stuffs i have.

Link to comment
Share on other sites
mwlue

mwlue

Posted
Posted

Just to confirm, MJ dev194 don't work on my end with RPM. I have another copy of KSP which is mostly clean ( Just have KJR, proc fairing for my own modding) , have MJ dev194 working fine.

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
Posted
Just to confirm, MJ dev194 don't work on my end with RPM. I have another copy of KSP which is mostly clean ( Just have KJR, proc fairing for my own modding) , have MJ dev194 working fine.

I am not getting any errors, so I am not sure what's going on. If you don't mind, take a look at this development build of RPM (this is just the DLLs packaged, no props or module manager configs, so *do* overwrite an existing RPM installation). This is what I'm using right now. If that still doesn't work, let's take this discussion to the RPM thread or to PMs, so we're not cluttering MechJeb with RPM support.

Link to comment
Share on other sites
BARCLONE

BARCLONE

Posted
Posted

I backdated to dev193, and started a new sandbox...

The logfile starts throwing exceptions with the Docking AP at time reference 12:18:28:256. The game goes unstable at this point, but visually continues without giving the appearance of anything wrong. I cannot get back to KSC.

I'll try dropping back to an earlier dev and see where or if it crashes...

Link to comment
Share on other sites
AntiMatter001

AntiMatter001

Posted
Posted
Use the Dev builds they have lots of stuff fixed in them and if you find a problem with one you can help by doing bug reports so MJ gets better and better its a WIN WIN situation

same thing with everyone else... RPM is the biggest conflict ever... as soon as i install it (rpm i mean) mechjeb flings off...

also the tab that's normally on the right isn't there... but if i take a fresh install then it works fine...

Link to comment
Share on other sites
MOARdV

MOARdV

Posted
Posted

Something is going on with RPM interfering with MechJeb. I have reproduced a problem where SCANsatRPM.dll causes MechJeb to stop working if SCANsat is not installed. As a temporary work-around, please remove the SCANsatRPM folder from GameData if you do not use SCANsat. I am still trying to understand why this has stopped working, and I will push a fix to RasterPropMonitor as soon as I can.

Link to comment
Share on other sites
BARCLONE

BARCLONE

Posted
Posted

And another possible incompatibility to report...

I backdated to dev192 to see if the crashing problem could be duplicated, and it was. However, I remembered something from a much earlier problem with NovaPunch components. As a test, I redesigned my lander -- I had been using the Thor decent module for the lander, which is an all-in-one tank and engine combination -- using a simple stretchy tank and a normal engine instead. The problem went away.

I had some problems earlier with the NovaPunch Odin command pod. It may be just graphics-related, but the result was a game instability. If you are having similar problems to what I've been describing the last few days, check to see if you are using any NP parts.

I'm going to re-install 194 to test this theory...

Link to comment
Share on other sites
BARCLONE

BARCLONE

Posted
Posted

Sarbian,

In testing the 194 dev again, my lander's MJ unit swung the ship immediately on decouple and broke off a solar panel. Could you introduce a concept of "master-slave" into the MJ units, so that one ship always has "absolute top-dog command" and the others have a subordinate position? Perhaps also have a radio button to tell all subordinates to "Free Drift upon separation", or "Kill rotation upon separation", so that they hold a steady attitude after a decoupling occurs...

Link to comment
Share on other sites
BARCLONE

BARCLONE

Posted
Posted

Dev194 -- again...

Game crashes internally such that my command ship jumps 700 km away from the lander in one instant of time. Same orbit, just 700 km away...

What I'm getting is "Null Reference Exception"... 27 MB worth in the logfile... No immediate indication of where the crash is happening; the logfile doesn't specify which module the crash is starting from.

Too tired tonight to go another round.

Link to comment
Share on other sites
mwlue

mwlue

Posted
Posted
Something is going on with RPM interfering with MechJeb. I have reproduced a problem where SCANsatRPM.dll causes MechJeb to stop working if SCANsat is not installed. As a temporary work-around, please remove the SCANsatRPM folder from GameData if you do not use SCANsat. I am still trying to understand why this has stopped working, and I will push a fix to RasterPropMonitor as soon as I can.

This do the trick, thank you for the head up.

Link to comment
Share on other sites
darkstrike

darkstrike

Posted
Posted

I was in the same boat K3|Chris, but I updated to the latest Dev build of MJ and it seems to work much better now: http://jenkins.mumech.com/job/MechJeb2/

Click on the 'zip' link under 'Last Successful Artifacts' - it will link you to the latest dev version. They can be buggy, but this one seems fine for me and the spinning / inaccurate pitch/yaw seems fixed. Hope that helps!

______________________________________________________________________________________________________

As for my own question - is there a way to select a docking port on a ship to use MJ for Autopilot docking, but still VIEW the docking (still controlled from that docking port) from an IVA view in a cockpit? From what I can see, the second I switch to IVA, it changes my control point to that cockpit rather than the docking port... :(

Link to comment
Share on other sites
BARCLONE

BARCLONE

Posted
Posted (edited)

OK, now this is really weird...

Using Dev194...

[EXC 15:05:31.335] NullReferenceException: Object reference not set to an instance of an object

[LOG 15:05:31.349] BAR.Lark-Ship.MkIII (Intrepid-Class Mun Ship) collided into collider - relative velocity: 402.2417 - no impact momentum (no RB)

[LOG 15:05:31.350] BAR.Lark-Ship.MkIII (Intrepid-Class Mun Ship) Exploded!! - blast awesomeness: 0.5

[LOG 15:05:31.384] [bAR.Lark-Ship.MkIII (Intrepid-Class Mun Ship)]: Deactivated

[LOG 15:05:31.387] [00:02:09]: Lark Crew Ship MkIII collided into 2m "Make-A-Wish"-Type Ablative Heatshield w/decoupler.

[LOG 15:05:31.498] 1 explosions created.

[LOG 15:05:31.499] Packing Intrepid-Class Mun Ship Lander for orbit

[LOG 15:05:31.500] Packing Intrepid-Class Mun Ship Debris for orbit

[LOG 15:05:31.500] Packing Intrepid-Class Mun Ship Debris for orbit

[LOG 15:05:31.500] Packing Intrepid-Class Mun Ship Debris for orbit

[LOG 15:05:31.500] Packing Intrepid-Class Mun Ship Debris for orbit

[LOG 15:05:31.500] Packing Intrepid-Class Mun Ship Debris for orbit

[LOG 15:05:31.559] ObT : 0.0528124990378274

M : Infinity

E : NaN

V : NaN

Radius: NaN

vel: [NaN, NaN, NaN]

AN: [1, 0, 0]

period: 0

[WRN 15:05:31.559] [OrbitDriver Warning!]: Intrepid-Class Mun Ship Debris had a NaN Orbit and was removed.

[LOG 15:05:31.559] Intrepid-Class Mun Ship Debris Unloaded

[ERR 15:05:31.560] Invalid parameter because it was infinity or nan.

[LOG 15:05:31.560] getObtAtUT result is NaN! UT: 65577.0219762775

[LOG 15:05:31.560] ObT : NaN

M : NaN

E : NaN

V : NaN

Radius: NaN

vel: [NaN, NaN, NaN]

AN: [1, 0, 0]

period: NaN

[WRN 15:05:31.560] [OrbitDriver Warning!]: Intrepid-Class Mun Ship Debris had a NaN Orbit and was removed.

[LOG 15:05:31.560] Intrepid-Class Mun Ship Debris Unloaded

[ERR 15:05:31.564] Invalid parameter because it was infinity or nan.

[WRN 15:05:31.564] Vessel Intrepid-Class Mun Ship Debris crashed through terrain on the Mun

[LOG 15:05:31.565] [00:02:09]: Intrepid-Class Mun Ship Debris crashed into the Mun.

[LOG 15:05:31.565] dockingPort2 Exploded!! - blast awesomeness: 0.5

[LOG 15:05:31.565] [dockingPort2]: Deactivated

[ERR 15:05:31.569] Invalid parameter because it was infinity or nan.

[ERR 15:05:31.569] Invalid parameter because it was infinity or nan.

[LOG 15:05:31.607] Intrepid-Class Mun Ship Debris Unloaded

[LOG 15:05:31.607] Intrepid-Class Mun Ship Debris Unloaded

[LOG 15:05:31.608] [KzProcFairingSide2 (Intrepid-Class Mun Ship Lander Debris)]: Activated (forced)

[LOG 15:05:31.608] [KzProcFairingSide2 (Intrepid-Class Mun Ship Lander Debris)]: Activated (forced)

[LOG 15:05:31.608] [KzProcFairingSide2 (Intrepid-Class Mun Ship Lander Debris)]: Activated (forced)

[LOG 15:05:31.609] [KzProcFairingSide2 (Intrepid-Class Mun Ship Lander Debris)]: Activated (forced)

[LOG 15:05:31.609] [KzInterstageAdapter]: Activated (forced)

[LOG 15:05:31.609] [KWFlatadapter3x2]: Activated (forced)

[LOG 15:05:31.609] [KW2mengineVestaVR9D]: Activated (forced)

[LOG 15:05:31.612] 1 explosions created.

Here's the interpretation:

I'm carrying my lander Apollo-style inside a ProcFar adapter shroud. The lander has its own decoupler attaching it to the PF adapter base. From launch through to crew ship docking, and even decoupling from the adapter, everything appears to be working without issue. Time comes to separate the lander from the crew ship, so far so good. As soon as the lander gets out of the crew ship's SOI, the crew ship explodes. I didn't see the explosion, but I heard it and knew something nasty occurred. Curiously, the lander then went down to the surface (Mun) without a hitch, landed perfectly on target, and I was able to get back to KSP (game pause). The game did not crash internally to the point of instability.

Thoughts?

Edited by BARCLONE
Link to comment
Share on other sites
BARCLONE

BARCLONE

Posted
Posted (edited)

Build 194...

Just pulled two completely successful flights out of the hat using the same hardware that had been giving me fits earlier. What was different?

Something completely overlooked and not considered, but apparently running around in my squirrel cage of a head. It has to do with the names of the ship and the lander. MechJeb doesn't like two ships having the same name, nor does it like having one ship have the same name as a piece of debris. It seems that MechJeb could not distinguish between my crew ship and my lander, or between my crew ship and one (or more) of the aeroshroud panels that get blown off to expose the lander.

What happens is this: When you build the ship that I'm using, it launches as one ship under one name. When you separate the pieces, there is enough similarity between the "lander", the "ship", and "debris" that MechJeb mistakes one for another. This is what seems to have happened with an earlier test, where the command pod "exploded" in the background. Looking at the log, what it was described as doing was hitting the surface of Mun. I was at the time focused on the lander, going through the landing sequence. MechJeb saw the names of both ships as being the same, and so the command ship plunged along with the lander.

The change I tried on both of these successful missions was to rename the command ship immediately upon separation from the carrier stage, then switch over to the lander and rename it something totally different. When the command ship docks with the lander, both ships are recognized by the command ship name, but now the lander has its own identity after it separates from the command ship to go down to the surface. MechJeb liked the difference. and didn't summarily clobber the command ship, leaving it positioned comfortably in orbit. Wild, ain't it?

Screenshots of my wundership:

ADDENDUM: Sarbian just posted dev195, so I'll play with it tomorrow.

Edited by BARCLONE
Link to comment
Share on other sites
tmbomber

tmbomber

Posted
Posted
Sarbian,

In testing the 194 dev again, my lander's MJ unit swung the ship immediately on decouple and broke off a solar panel...

Also seeing this one. I usually jump back and forth between vessels just before docking and turn MJ off on both, then dock. (or engage docking AP) On occasion I forget. When you have multiple things docked and each has a MJ you'll see most of them with a red light and one with a green. It seems the inactive MJs remember their last command, and when you separate and an inactive MJ turns on it re-executes it's last command. (bad news if your vessels CG is closer to the docking port than it's architectural center)

I have a couple stations made from multiple launches. One of them has over 10 MJs on it. I have no idea if any of those have phantom commands that'll crop up if I separate something. It also seems to me that the inactive MJs seem to fight the active one. I think this is a source of the wobble that I and several others have seen.

What would be really nice would be the ability to right click on an inactive MJ and set or clear it's programming.

Short of that, on docking, have all the inactive MJ's clear their commands.

I can not think of a single case where I'd want MJ to hold on to it's last command and re-execute it after separation.

I've had multiple cases where the re-execution of long forgotten commands has caused problems.

Link to comment
Share on other sites
sarbian

sarbian

Posted
Posted

I'll add a few more steps to the docking AP to avoid some of the reported problems.

I should have some time to code this week. Now I'll have to remember what I was suposed to do first :D

Link to comment
Share on other sites
Justin Kerbice

Justin Kerbice

Posted
Posted

It's looks like I get a little issue with "Align Planes" RDV planner when planes are almost 180° from each other:

Javascript is disabled. View full album

I just circularize (or ellipsorize in my case near 100 km Kerbin altitude), then directly do the Hohmann trasnfert which is a lot cheaper in such case, I think.

It miss some option to set "I want the same way" or "I don't mind going to the opposite way" (by way here I mean being clockwise or counterclockwise to the target body)

Anyway it's kind of an issue cause from plane point of view, 0 and 180 ° are the same.

Link to comment
Share on other sites
John FX

John FX

Posted
Posted
Also seeing this one. I usually jump back and forth between vessels just before docking and turn MJ off on both, then dock. (or engage docking AP) On occasion I forget. When you have multiple things docked and each has a MJ you'll see most of them with a red light and one with a green. It seems the inactive MJs remember their last command, and when you separate and an inactive MJ turns on it re-executes it's last command. (bad news if your vessels CG is closer to the docking port than it's architectural center)

I have a couple stations made from multiple launches. One of them has over 10 MJs on it. I have no idea if any of those have phantom commands that'll crop up if I separate something. It also seems to me that the inactive MJs seem to fight the active one. I think this is a source of the wobble that I and several others have seen.

What would be really nice would be the ability to right click on an inactive MJ and set or clear it's programming.

Short of that, on docking, have all the inactive MJ's clear their commands.

I can not think of a single case where I'd want MJ to hold on to it's last command and re-execute it after separation.

I've had multiple cases where the re-execution of long forgotten commands has caused problems.

Myself I would want a child craft that either undocked or staged to inherit the state of MJ from its parent. Whatever was on, off, active, inactive should remain that way when undocked for both craft.

No surprises at all that way. (I`m sure this was the way MJ used to work)

Also gives some fun functionality for example with escape pods from a doomed cruise liner all popping off together with autoland already activated.

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...