[1.8.x] DMagic Orbital Science: New Science Parts [v1.4.3] [11/2/2019]

[WuphonsReach]

I've seen the issue as well in my current save with the MAG/RPWS contracts, it seems to be minor as the contracts do actually complete.

• Have an existing MAG+RPWS sat around the target body, in a high inclination, high elliptical orbit (mine are usually 75-89 degrees of inclination, with eccentricity > 0.80, Pe at either the north or south pole)
• Get a MAG/RPWS contract
• Do the readings in high orbit, then in low orbit (transmitting both times)
• The lines for "parts", "inclination" and "eccentricity" will not update.

However, when I go away from the vessel and then look again, those three contract parameters *do* go green.  I'm not sure whether it's the act of switching away, or just a time delay, or something else.  I've not had one fail yet and I've done a dozen or so in the current career.

[WuphonsReach]

So I've been experimenting with sensor pods on the Mun.  The results are mixed.  Sensor pods are possibly not sturdy enough for being jettisoned at 100% decoupler power, at an angle of 5-15 degrees above the plane of descent at anything above 25m AGL.  Out of five landings, I'm usually only seeing 2-3 survive.

The biome seems to be strange too.  The stock Double-C Seismic sensor will report the biome correctly, but the Seismic Impact Hammer sometimes reports a different one.  When I land in of (one of) the Mun's Twin Craters it says I'm in the Midlands (landing site 17-36-06 S / 134-48-57 E).  

I think the biome bug has to do with staying with the craft all the way from orbit to landing.  If I switch away from the lander to another vessel and then come back, it reports Seismic Data from the correct biome.

[DMagic]

@ParkerArt The XRay is working fine for me, with more-or-less the same vessel. Do you have log files?

@WuphonsReach @SmashBrown Do other people only see the magnetic field contract problems when using existing vessels? That would make sense, it doesn't have a way of checking existing vessels, and one of the ways to force it to update is to switch to another vessel while in flight (but apparently switch to the magnetic field survey vessel doesn't work, because KSP is weird). It should be easy enough to force a check of all vessels whenever the contract is loaded and isn't already tracking any vessels.

When you have problems with biomes and the seismic hammer what is the exact procedure. Are you decoupling pods, but keeping focused on the main lander (with the impact hammer) all the way until landing, then seeing the wrong biome come up? Do you know if the biome corresponds to the landing site of any of the pods? It's possible that something is getting mixed up with all of that happening. And the pods probably need another increase to their impact tolerance.

Edited December 30, 2016 by DMagic

[WuphonsReach]

1 hour ago, DMagic said:

Are you decoupling pods, but keeping focused on the main lander (with the impact hammer) all the way until landing, then seeing the wrong biome come up?.

Yes, lander starts in orbit.  At 25m / 50m / 75m / 125m AGL on final descent (I've been experimenting with various heights), I fire an action group that ejects all five sensor pods (which then spread across the landscape).  My focus stays on the lander through the entire procedure from orbit to landing and then running of the hammer experiment.

Based on the biome maps (in-game SCANSat overlay), I'm well within the biome borders for all of the probes.  Will experiment more (there are 17 biomes on the Mun to unlock).

Sometimes the pods fall like dormant seeds, sometimes they immediately flower (a fiery flower, i.e. go boom).  So I'm experimenting with the max impact speed settings.

---

Tested again at the Mun's poles with the above procedure (stay focused on the lander all the way down).  It thinks that the lander is still in the Midlands, while the stock experiment correct says "Poles".  I'm well within the border.  Switch away to a vessel outside of physics range and come back, and the experiment has the right biome.

My guess is that something changed in KSP 1.2 with regards to events.  It smells like when I decoupled from the mothership, I was over the midlands, and the experiment never asked again for an updated biome.  These landers are not the root part on the mothership, they are child probes attached via stock decouplers (right-click, decouple, use '[' and ']' to switch to the child probe).

 

Edited December 30, 2016 by WuphonsReach

[Merkov]

1 hour ago, DMagic said:

@ParkerArt

@WuphonsReach @SmashBrown Do other people only see the magnetic field contract problems when using existing vessels? That would make sense, it doesn't have a way of checking existing vessels, and one of the ways to force it to update is to switch to another vessel while in flight (but apparently switch to the magnetic field survey vessel doesn't work, because KSP is weird). It should be easy enough to force a check of all vessels whenever the contract is loaded and isn't already tracking any vessels.

I'be had an issue or two with the magnetic field contracts, always with existing vessels. I used to just cheat them to force them to complete, but the last few times I have found that just playing the game long enough would get then to work. Based on what you're saying, I'm guessing they probably started working at the first vessel change but I wasn't looking closely enough to notice. 

Since adopting my more patient approach, I have never had a contract that I have been completely unable to get to work. 

[WuphonsReach]

Decoupled from mothership over Lowlands (30-35km above Mun), switched to lander with '[' / ']' keys.  Target is center of the Northern Basin.  MechJeb Surface Info and SCANSat maps both agree I'm over the Northern Basin on final approach.  Three of the five probes (impact tolerance of 300 m/s) survived a 75m ejection (distance of 860m and 1.6km on two, the near one is 130m).

Seismic hammer thinks it's in the Highlands.

Edited December 30, 2016 by WuphonsReach

[WuphonsReach]

Switching to the Sally lander with four experiments: 2HOT Thermometer, Magnetometer Boom, Dynamic Albedo of Neutrons, and the Surface Ablation Laser Light Imager.  Two landers per mothership in Mun orbit at 30km altitude.  Standard procedure of decouple, switch focus, then land the probe in the target biome.

All four experiments reported the correct biome (so I'm reasonably sure it's just the seismic hammer).

 

[DMagic]

@WuphonsReach Did you happen to notice if the biome being reported matched the biome of the ship still in orbit? There might be some problems with the vessel reference not updating when decoupling/undocking that would make the hammer think it is still in orbit.

[WuphonsReach]

7 hours ago, DMagic said:

@WuphonsReach Did you happen to notice if the biome being reported matched the biome of the ship still in orbit? There might be some problems with the vessel reference not updating when decoupling/undocking that would make the hammer think it is still in orbit.

I believe that is indeed what is happening.  The recent experiment in the Lowlands biome initially shows Midlands as the biome, then if I wait long enough, that switched to Polar Crater biome.  The mothership is in a highly inclined orbit and passes over the Polar Crater.

Crash tolerance of 1500 and 5/5 survived a 75m AGL deployment.

-

Starting to wish these sensor pods had a self-destruct after 30 days setting

And even at 1500 m/s of crash tolerance, I've had deployments at 75m AGL on the Mun where 4 of the 10 exploded.  Another had 3 of 10 explode.

Edited December 31, 2016 by WuphonsReach

[ParkerArt]

On 12/30/2016 at 11:03 AM, DMagic said:

@ParkerArt The XRay is working fine for me, with more-or-less the same vessel. Do you have log files?

I don't believe so...? I'm using Galileo's Planet pack, if that would break anything.

[DMagic]

Version 1.3.8 is out; get it on Space Dock.

It fixes some errors with the magnetic field and reconnaissance contracts when trying to use a vessel already in orbit. It also fixes some issues with the seismic impact experiments when decoupling or undocking from another vessel before setting up and running the experiment, along with a few other less common issues. It also fixes a problem with the seismic impact and x-ray experiments when using them with Kopernicus on a planet that replaces Kerbin, for instance Gael, in the Galileo's Conquest pack, or Earth in RSS.

[SmashBrown]

2 hours ago, DMagic said:

Version 1.3.8 is out; get it on Space Dock.

It fixes some errors with the magnetic field and reconnaissance contracts when trying to use a vessel already in orbit. It also fixes some issues with the seismic impact experiments when decoupling or undocking from another vessel before setting up and running the experiment, along with a few other less common issues. It also fixes a problem with the seismic impact and x-ray experiments when using them with Kopernicus on a planet that replaces Kerbin, for instance Gael, in the Galileo's Conquest pack, or Earth in RSS.

Thank you!

[WuphonsReach]

Issues with the Seismic Hammer not realizing it's in a new biome are now fixed.  It also does a good job of figuring out the "strength" of the experiment (the light bar on the side of the hammer device).  Before it would only read about 30-40% until I switched to a craft outside of physics range and came back (at which point it would read 100%).  Now it seems to pickup the pods right away.

Attempts with pods (deploying at 50m height, I count the number of booms I hear):

1. 6/7 survived
2. 3/7 survived

They must just land on the explodey bit sometimes.  I suggest always packing (8).

[MaxxQ]

3 hours ago, DMagic said:

Version 1.3.8 is out; get it on Space Dock.

It fixes some errors with the magnetic field and reconnaissance contracts when trying to use a vessel already in orbit. It also fixes some issues with the seismic impact experiments when decoupling or undocking from another vessel before setting up and running the experiment, along with a few other less common issues. It also fixes a problem with the seismic impact and x-ray experiments when using them with Kopernicus on a planet that replaces Kerbin, for instance Gael, in the Galileo's Conquest pack, or Earth in RSS.

Ah!  I was wondering about that.  No matter what height I was placing the hammer, nor where I was located, I always got the "hammer can't reach the ground" notice, even when it was lifing the ship while deploying.  Thought it was just me being stupid and not getting it in the right spot.  Well, time to check that out and make sure it's fixed.  I'm playing a GPP science game, BTW.

[Esquire42]

Hi @DMagic, I'm not seeing the relay upgrade for the antennas appear in sandbox mode. I do have the Part Upgrade in sandbox setting checked, but the SIGNET devices display as direct transmitters only.

[DMagic]

@WuphonsReach There are really several ways of going about it. One is to carry an abundance of pods, if you have five in the near vicinity you should get full points regardless of how they are arranged. Another is the somewhat dangerous (as you've found out) method of trying to launch pods while still above ground, on low gravity planets this can actually work really well, it's just a bit tricky, since if they travel more than 2.5 km away you'll have to focus on the pod until it stops. Another still is to use different landers to drop pods, you could setup a really minimal lander probe to drop a few pods. And another (my favorite) is to not care about getting 100% for all science and just get a decent enough result.

@MaxxQ It has to do with the way that the "home" planet is still internally named Kerbin in some places, so that was interfering with how I was detecting if the drill or hammer could reach the surface.

@Esquire42 Do part upgrades work in sandbox? I've never tested it, and it wouldn't surprise me if there was something finicky about it, the entire part upgrade system is very half-assedly implemented.

[WuphonsReach]

I think the best distance on the Mun that I've gotten is up around 1.8km, ejecting with 100% power at 50-100m AGL.  (2 of the pods have a very low eject force of 20-25%, so they don't go that far.)  I'll be experimenting on Minmus soon.

I currently pack 7-8 pods on the lander and fire them off at 50m AGL because it's cool .  They all fire off simultaneously for maximum effect.  And that gets me anywhere from 75-100% of the science value which, as you say and I agree, is good enough.

[Esquire42]

14 hours ago, DMagic said:

 

@Esquire42 Do part upgrades work in sandbox? I've never tested it, and it wouldn't surprise me if there was something finicky about it, the entire part upgrade system is very half-assedly implemented.

I've seen mixed responses to the question. Some places I've seen yes, and some no. There is an option in the persistent file for part upgrades in sandbox. Porkjet's revamped rocket parts show that upgrades are available but I don't use those parts enough in my sandbox save to look at the difference. I can do so sometime this weekend.

 

EDIT: Looks like it's all good. Might have been some Filter Extension weirdness.

Edited January 7, 2017 by Esquire42
we're good

[doktorstick]

Howdy. Let me preface this by saying I'm a fairly newbie Kerbal player; there may be a difference between how I think something should work and how it does work.

I launched a very small probe consisting of the Probodobodyne OKTO with the Double-C Seismic Accelerator, 2HOT thermometer, and PresMat barometer on one side (0.02t) and the DMagic Magnetometer Boom on the other side (0.02t). Once I get into space (>70,000m), I try to vector into orbit with a RE-A12 Pomeranian (a 0.625m LFO gimbaled engine from some mod; I don't know which).

The problem is that the craft immediately starts to spin pretty heavily. There's no trim (Alt-X to verify). Once I remove the DMagic Magnetometer Boom and relaunch into space, I power up the engines and continue on without spin. I've repeated both variants with repeatable results.

That's what doesn't make sense to me; there's no air resistance to cause that spin, CoT through CoM *and* the arguably unbalanced version flies straight. Is there something special with the boom that would cause this behavior? Thanks.

Edited January 7, 2017 by doktorstick

[Esquire42]

5 hours ago, doktorstick said:

Howdy. Let me preface this by saying I'm a fairly newbie Kerbal player; there may be a difference between how I think something should work and how it does work.

I launched a very small probe consisting of the Probodobodyne OKTO with the Double-C Seismic Accelerator, 2HOT thermometer, and PresMat barometer on one side (0.02t) and the DMagic Magnetometer Boom on the other side (0.02t). Once I get into space (>70,000m), I try to vector into orbit with a RE-A12 Pomeranian (a 0.625m LFO gimbaled engine from some mod; I don't know which).

The problem is that the craft immediately starts to spin pretty heavily. There's no trim (Alt-X to verify). Once I remove the DMagic Magnetometer Boom and relaunch into space, I power up the engines and continue on without spin. I've repeated both variants with repeatable results.

That's what doesn't make sense to me; there's no air resistance to cause that spin, CoT through CoM *and* the arguably unbalanced version flies straight. Is there something special with the boom that would cause this behavior? Thanks.

I've had issues with tiny probes being randomly hard to control before and changing my maneuver nodes vastly because of it. It might be a physics engine thing.

[danielboro]

thers a setting to add the mass of a part to the parent part

if the 2hot and barometer use it but the mag boom dos not the probe will be unbalanced, as on one side ther will be 0 mass (mass added to parent mass) and on the second side the mag boom will have mass

[WuphonsReach]

Add a reaction wheel (I don't think the OKTO has one), that should help.  Even my smallest probes are a few hundred kilograms and with the smallest reaction wheels have no problem with a mag-boom.

You could also try insetting the boom into the body of the probe more instead of making it a surface mount.  That will move its mass closer to the line of thrust.

[DMagic]

More than just offsetting the boom, I think the problem is that the boom is much heavier than the other parts. And once it's extended it's mass is distributed across it's entire length. 

For smaller vessels it always works better to mount it on the top rather than the side.

 

[WuphonsReach]

On 1/6/2017 at 9:04 AM, DMagic said:

@WuphonsReach There are really several ways of going about it. One is to carry an abundance of pods, if you have five in the near vicinity you should get full points regardless of how they are arranged. Another is the somewhat dangerous (as you've found out) method of trying to launch pods while still above ground, on low gravity planets this can actually work really well, it's just a bit tricky, since if they travel more than 2.5 km away you'll have to focus on the pod until it stops. Another still is to use different landers to drop pods, you could setup a really minimal lander probe to drop a few pods. And another (my favorite) is to not care about getting 100% for all science and just get a decent enough result.

Turns out you don't need to focus the sensor pods out past 2.5km.

First test on Minmus, ejecting at 25m AGL with 100% force resulted in 5/7 survival, I have pods at 4.2 and 5.0 kilometers away from the landing site.  Which is pretty crazy on Minmus given the size.  On Gilly, I'll possibly be putting pods into orbit with 100% force ejection.

Second test on Minmus on the Great Flats, but in a narrower portion, I expect the probes will bounce and roll on the hills around the flats.  Lost 3 of 7, two survivors have a distance >4km.

[WuphonsReach]

Gilly probably shouldn't be a target for MAG/RPWS contracts.  The low-orbit boundary of 6km is is within the 8km 1x reference frame, and I've had things vanish when under 6km Pe.