[1.4] StageRecovery - Recover Funds+ from Dropped Stages - v1.8.0 (March 11, 2018)

[magico13]

Yeah, doesn't sound unreasonable. I test that code with really small ships and use less fuel than that. A mostly empty stage won't require too much, especially because its terminal velocity (assuming that calculation is working even remotely correctly) shouldn't be too high. Like, less than 200 m/s of dV probably was required. Powered landings are remarkably cheap in requirements.

[strudo76]

Coolies then, I'll consider it working as intended.

[Gordon Dry]

I never had this issue before.

A new career, sounding rocket:

Exception handling event onVesselWillDestroy in class StageRecovery:System.NullReferenceException: Object reference not set to an instance of an object
  at StageRecovery.RecoveryItem.SetRecoveryPercentages () [0x00000] in <filename unknown>:0 
  at StageRecovery.RecoveryItem.Process () [0x00000] in <filename unknown>:0 
  at StageRecovery.StageRecovery.VesselDestroyEvent (.Vessel v) [0x00000] in <filename unknown>:0 
  at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

NullReferenceException: Object reference not set to an instance of an object
  at StageRecovery.RecoveryItem.SetRecoveryPercentages () [0x00000] in <filename unknown>:0 
  at StageRecovery.RecoveryItem.Process () [0x00000] in <filename unknown>:0 
  at StageRecovery.StageRecovery.VesselDestroyEvent (.Vessel v) [0x00000] in <filename unknown>:0 
  at EventData`1[Vessel].Fire (.Vessel data) [0x00000] in <filename unknown>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
EventData`1:Fire(Vessel)
Vessel:Die()
Vessel:CheckKill()
VesselPrecalculate:MainPhysics(Boolean)
ModularFI.ModularVesselPrecalculate:MainPhysics(Boolean)
VesselPrecalculate:FixedUpdate()
ModularFI.ModularVesselPrecalculate:TimedFixedUpdate()
TimingPre:FixedUpdate()
 
(Filename:  Line: -1)

[Vessel GD Sounding Rocket A New Section 1 Debris]: Vessel was destroyed.

No info written to the SR windows, no vanilla message about destroyed parts neither.

Log:
https://www.dropbox.com/s/ve3l1h7gmio6ao8/2017-07-05-4 KSP.log.zip?dl=1

 

Edit:

Hmm. Removed mods, started new career, still the same.
Destroyed parts (jettisoned stages without chutes) neither shown in stock messages nor in SR UI at all.

All the time I used SR I never had this issue before.

Edit:

 

Edited July 7, 2017 by Gordon Dry

[Mukita12]

does it work with 1.3?????

[Gordon Dry]

@Mukita12: Yes, usually.

 

btw my issue is gone, but I have to find out if it's because

• switching back from Kopernicus RLS 4 (or .SMH build) to RLS 2
• using updated Trajectories
• using only Boulder Co and no additional visual packs

Next test will be using Kopernicus RLS 4.

[magico13]

@Gordon Dry it had been mentioned to me in the past that Kopernicus might have an incompatibility. I'm guessing that was it. I've had a lot going on IRL lately so I haven't gotten a chance to look at anything yet.

[Jimbodiah]

Is there any way to increase the range from KSC for the recovery % in a RSS install?

[Gordon Dry]

The issue was triggered by the Kopernicus.SMH build, RLS 4 is working.

[strudo76]

Does Stage Recovery take advantage of drogue chutes if they are fitted?

Also does it take into account the different chute materials offered by RealChute, or is just having the chutes enough?

Thanks.

[magico13]

1 hour ago, strudo76 said:

Does Stage Recovery take advantage of drogue chutes if they are fitted?

Also does it take into account the different chute materials offered by RealChute, or is just having the chutes enough?

It is supposed to account for drogue chutes in the total terminal velocity calculation. Different materials should be handled as expected, so if one material leads to a lower terminal velocity than another, StageRecovery should reflect that. You can test that in the editor with the editor tool.

[Loren Pechtel]

1 hour ago, strudo76 said:

Does Stage Recovery take advantage of drogue chutes if they are fitted?

Also does it take into account the different chute materials offered by RealChute, or is just having the chutes enough?

Thanks.

Drogues cost more per unit of drag and there's no need for them with Stage Recovery unless you're landing something that's within physics range.  Also, what you're landing with Stage Recovery is normally light and draggy.  I use only mains, set to open at 1000m and I've had zero problems except with stages dropped too fast.  (A stage that comes off above 2000 m/s risks burning up.)

[terminalmonky]

Hello sorry for the newb question here.  I have dug into this in several threads and can not find a good answer.

The main question here is does a craft have to be "on rails" for StageRecovery to recover it?

I have a mutistage rocket with SRBs in one stage and a lifter stage that I am taking straight up to test.  Once the lifter stage burns out the vessel is sub orbital.  I separate the capsule from the lifter stage and they both glide to AP and then return.  Everything has parachutes.  I have Stage Recovery, FRMS, RecoveryControl, and Real Chutes installed.  (I know its probably a weird mod interaction but I am trying to understand the behavior.  And yes this is a heavily modded install.)

I have RecoveryControl set to auto everywhere.  FRMS is set to give StageRecovery control of parachute only vessels.  And I even have FRMS inactive.  

The SRBs are recovered fine.  But if I do not put separatrons on the lifter stage to push it out of the physics boundary then it crashes into the ground with no recovery what so ever.  StageRecovery does not even register it as destroyed.  

Here is an example of the lifter stage just crashing.  

[LOG 14:50:47.335] 7/21/2017 2:50:47 PM,DeepFreeze,DeepFreezeEvents onVesselWillDestroy 43759180-46ef-4006-8284-d8d9519fadfc
[LOG 14:50:47.404] ControllingMod  failed
[LOG 14:50:47.405] [SR] Controlling mod is null
[LOG 14:50:47.479] [SR] FMRS is not active.
[LOG 14:50:47.485] [Dynamic Battery Storage]: Summary: 
 vessel RC.stack (loaded state True)
- 0 stock power producers 
- 0 stock power consumers
[LOG 14:50:47.495] [Dynamic Battery Storage]: Summary: 
 vessel RC.stack (loaded state True)
- 0 stock power producers 
- 0 stock power consumers
[LOG 14:50:47.497] [Dynamic Battery Storage]: Summary: 
 vessel mk1pod (loaded state True)
- 0 stock power producers 
- 0 stock power consumers
[LOG 14:50:47.498] RemoteTech: SatelliteManager: OnVesselDestroy(43759180-46ef-4006-8284-d8d9519fadfc, Upgoer Mk1 Debris)
[LOG 14:50:47.500] RemoteTech: SatelliteManager: UnregisterProto(43759180-46ef-4006-8284-d8d9519fadfc)
[LOG 14:50:47.502] IR: [ServoController] OnVesselUnloaded, v=Upgoer Mk1 Debris
[LOG 14:50:47.556] 1 explosions created.
[WRN 14:50:48.733] [F: 88320]: Vessel Upgoer Mk1 Debris crashed through terrain on Kerbin.
[LOG 14:50:48.736] [KSP Interstellar] Handling Impactor
[LOG 14:50:48.738] [KSP Interstellar] Handling Impactor
[LOG 14:50:48.740] [IM:7/21/2017 2:50:48 PM]: crash data -CRASH-Ker

And here is an example of the lifter stage being recovered properly because it was on rails at the time of the crash.

[LOG 15:14:50.704] [F: 157235]: Vessel Upgoer Mk1 Debris was on-rails at 1.0 kPa pressure and was destroyed.
[LOG 15:14:50.706] 7/21/2017 3:14:50 PM,DeepFreeze,DeepFreezeEvents onVesselWillDestroy 3c666a75-9f1c-404a-ba16-5ea62979d957
[LOG 15:14:50.766] ControllingMod  failed
[LOG 15:14:50.768] [SR] Controlling mod is null
[LOG 15:14:50.834] [SR] FMRS is not active.
[LOG 15:14:50.836] KK: OnVesselRecoveryRequested
[LOG 15:14:50.837] KK: OnVesselRecoveryRequested is career
[LOG 15:14:50.838] KK: Distance to KSC is 39079.4446377483
[LOG 15:14:50.840] KK: SpaceCenter set to: SpaceCenterMarker
[LOG 15:14:50.841] [SR] Searching in RecoveryQueue (0) for 3c666a75-9f1c-404a-ba16-5ea62979d957
[LOG 15:14:50.851] [SR] Vt: 4.66989548508274
[LOG 15:14:50.852] [SR] Adding funds: 4998.43896484375, New total: 39378.167816189
[LOG 15:14:50.854] [SR] Stage was recovered. Distance: 39.08km, Altitude: 24939m
[LOG 15:14:50.856] [SR] D%: 0.944, S%: 1, Total: 0.944. Funds: 4998.44
[LOG 15:14:50.858] [StageRecovery] Attempting to add parts to ScrapYard inventory

 

Is this intended behavior and I just need to plan on using FRMS through recovery control when a disguarded stage will be landing closely enough to the my controlled stage that it is still in physics range?

If it is not then can you tell from these log snippets what the funky mod interaction is?

 

Thanks for the incredible work you guys do.  It is very much appreciated.

 

 

[magico13]

10 minutes ago, terminalmonky said:

Is this intended behavior and I just need to plan on using FRMS through recovery control when a disguarded stage will be landing closely enough to the my controlled stage that it is still in physics range?

Yes, StageRecovery is (almost) purely reactive and only kicks in when KSP deletes a vessel for being "On Rails" and in atmosphere. That means it only kicks in for vessels that are more than about 22km away from the active vessel AND under 25km altitude around Kerbin. If both those situations aren't met then StageRecovery can't do anything with it. You'd ether have to make the lifter unload by moving out of range, set the parachutes on it to deploy at 0.4 or 0.5 pressure and stage them when you decouple it (with RealChutes I'd set them to deploy at 1km altitude or so instead of by pressure, but they might be going too fast if you're just going straight up and straight down), or use FMRS to recover that stage manually. If you don't want to make it leave physics range (or make your capsule move away) then I'd try setting the parachutes to deploy automatically, since you'd have to do that to recover them with FMRS anyway.

[Wragie]

I have been running a no part mod'd 1.3 KSP and of course SR. Today I ran across a interesting thing. Not sure if it is a glitch or what.

I tend to get an annoying amount contracts for tourists so I design various Bus, some orbit and some are landers. With SR I can put a good chunk of expensive parts (27x vector engines etc) into the boost stages and recover the funds. On the stage that circularizes the orbit I generally will put a ring of smaller SRB's that fire on separation to de-orbit that stage at the same time. So they are kinda obvious when those stages separate lol. Today I ran two bus landers to the moon one right after the other. The initial LKO was 85km. Thats my usual orbit for this setup as it is just about or is out of fuel right after the circulation burn. So today I did the mission came back and noticed the one stage was still in a circular orbit instead of showing up as recovered. After the second mission same result, yet both had definitely fired the sep/de-orbit burn. I have used this configuration for dozens of missions and this was the first time something amiss occurred  and not once but twice! lol. Now the interesting bit...

So I thought might be good excuse to design a recovery vessel to get rid of desirable and not so desirable orbital debris (instead of pressing click in the tracking station). So equipped with the claw, a butt load of fuel, thrust and mono-propellant as well as parachutes I launched to rendezvous. On approach to the first booster stage as soon as I got within 350 meters the ring of retro srb's fired. If was pointing straight down and the srbs fired and burned out and put it into  a deorbit trajectory. It wasn't worth burning up so I switched target to the other booster and rendezvoused with it. Again at or around 350 meters the srbs fired. This time it was facing radial in so the srbs pushed it out into a higher orbit. It did get about 30km away before I started to close up again. this time when I got close it didn't fire the srb's. I did manage to connect and de-orbit the booster. I separated after the de-orbit burn and landed. The booster was then recovered by SR as it normally does.

So to be clear I was not using unlimited fuel or other cheats. The srbs fired TWICE. Once in the normal sequence and the second upon rendezvous approach at around 350m distance. Just curious if anyone has seen this behavior before?

[magico13]

27 minutes ago, Wragie said:

Today I ran across a interesting thing. Not sure if it is a glitch or what.

Definitely not anything caused by SR. Could be that they were firing, then the vessel unloaded before they finished, and then when you went back to them they fired again? I'd try switching to them in the tracking station if it happens again, since that would probably also make them fire again.

[Wragie]

I am using RT10's instead of those wimpy sepatrons lol. And these would be the first two blips after using this setup for say 30 plus launches. Was so nice just march the toristas up the ramp hand them the complimentary snack and beverage and light it off. Flawless other than the odd massive inflight disassembly on the first few flights. 

On one of them I was watching this burn and it was out before it was out of physics range. Both burned full length on the approach to recover them. I had such a great name for the recovery ship too! Kessler's Revenge! Lol.

Must be something that changed or updated then as the root cause.

 

[pwhk]

Sorry if I don't go thru all 53pages of posts. Does this mod work's with Ven's Stock revamp? With Ven's the descend speed is ~12m/s for a typical Mk1 + Mk16 Chute setup (i.e. sole Mk1 pod with Mk16 on top), despite SR saying it will descend at ~5m/s at VAB.

Looks like Ven's changed the parachute sizes.

[magico13]

3 hours ago, pwhk said:

Does this mod work's with Ven's Stock revamp?

Assuming Ven's doesn't introduce an entirely different parachute module then it should work correctly. Stock chutes are still fairly heavily approximated in what the terminal velocities will be, which is why I typically recommend using RealChutes as well since it usually comes up with much closer results.

[pwhk]

21 hours ago, magico13 said:

Assuming Ven's doesn't introduce an entirely different parachute module then it should work correctly. Stock chutes are still fairly heavily approximated in what the terminal velocities will be, which is why I typically recommend using RealChutes as well since it usually comes up with much closer results.

Yea Ven's does not introduce different module and parts with those chutes still recover correctly, just the VAB calculation

[Nachocuban]

Would having the 'Tidy up debris cluttering KSC' setting in the main game being on or off have any effect on recovery of funds/parts?

[Rodhern]

23 minutes ago, Nachocuban said:

Would having the 'Tidy up debris cluttering KSC' setting in the main game being on or off have any effect on recovery of funds/parts?

When I played with StageRecovery in an older KSP version, the 'tidy up' would trigger the refunds. I wouldn't get the message, but I would get the funds.

[Syczek]

I tested science recovery but it seems not work because probe safetly lands on Kerbin and yet no science gain

[Bornholio]

4 minutes ago, Syczek said:

I tested science recovery but it seems not work because probe safetly lands on Kerbin and yet no science gain

I did a couple booster sample recoveries today that worked fine.  Are you sure the science was not recovered  or transmitted before hand.  If science is recovered in a stage the icon will be blue and the science recovery text inside the information box will be blue.

[Syczek]

Just now, Bornholio said:

I did a couple booster sample recoveries today that worked fine.  Are you sure the science was not recovered  or transmitted before hand.  If science is recovered in a stage the icon will be blue and the science recovery text inside the information box will be blue.

 

I did get recovery report of probe safely recovered but no science gain and my science did not change i will check again to confirm this,it will take time because even with my 32 gb ram and 8 gb vram on gpu and opengl mode game loves to access violation

[Bornholio]

Just now, Syczek said:

 

I did get recovery report of probe safely recovered but no science gain and my science did not change i will check again to confirm this,it will take time because even with my 32 gb ram and 8 gb vram on gpu and opengl mode game loves to access violation

Sounds like you have a problem with your install, post an output_log.txt online and I'll take a look.  I play on a much weaker computer without crashes.