[WIP] Coatl Aerospace ProbesPlus Dev Thread [Beta] 10/19/2020 (1.8-1.10)

[Marcelo Silveira]

@akron, I made a pull request in github
I will make something similar for the Surveyor's soil sampler.

[Pappystein]

19 hours ago, Marcelo Silveira said:

Well, I made a patch to add compatibility with CommunityResourcePack and ScanSat for the scanners available in this mod. 

 

Wait does this mean If I have all the various scanners that cover all the Biomes of a planet I don't need to do a Scansat Survey?  Because these individual parts = a ScanSAT survey?

 

[akron]

3 hours ago, Pappystein said:

Wait does this mean If I have all the various scanners that cover all the Biomes of a planet I don't need to do a Scansat Survey?  Because these individual parts = a ScanSAT survey?

 

As far as I know this allows some of the science instruments to map CRP resources as well a map those same resources as a SCANsat map. You would still need a SCANsat survey to find resources not covered by these instruments

[Pappystein]

4 hours ago, akron said:

As far as I know this allows some of the science instruments to map CRP resources as well a map those same resources as a SCANsat map. You would still need a SCANsat survey to find resources not covered by these instruments

Thanks for the info!

[Friznit]

I'm sure like many people, I use the rather excellent Probes+ together with ScanSat (and various other mods that include scanners such as Dmagic's parts for Universal Storage).  I must admit I find it quite challenging to figure out which parts cover the relevant ScanSat capabilities - Fuzzy Resource Scan, Low Res Altimetry (Radar), Hi Res Altimetry (SAR),  Biome/Aonomoly (Multispec) - and how the specific resource scanners fit in.

There are plenty of multispec options and they are usually easy to spot in the parts list.   As far as I can tell there is only the one stock fuzzy resource scanner (and it's an awkward shape too).  Probes+ has a couple of different laser altimeters which count as Low Res Radar, and one SAR scanner for Hi Res Alt.  I don't think there is any equivalent to the stock Narrow Band scanner so presumably this is where all the various individual resource scanners fit in for the final step of identifying the best resource spots (and where Marcelo's patch comes in useful if you're using CRP).

Thankfully it's relatively simple to write a Module Manager patch to add the Fuzzy Resource Scan to a part of your choice (I've opted for the DMagic Universal Storage Water Scanner, mainly because it looks cool and folds away neatly) and judicious use of tweakscale means you can get full ScanSat capability into a single Probe without it looking like a warty elephant (let's face it, looks are important: you never know when your deep space probe might bump into an alien and first impressions really do count).

If anyone has a better idea how this all fits together please do chime in!

[akron]

14 minutes ago, Friznit said:

If anyone has a better idea how this all fits together please do chime in!

Well, to be perfectly honest I am not a big fan of the stock "hocus pocus" resource scanner. There is no universal resource detector equivalent in real life. You need multiple instruments to verify multiple emissions as well as double check the results of others. This is why we're still sending probes to the moon today to study its water reservoirs.

So, I have not found a single part that would make sense as a replacement for that horrible stock monstrosity . The closest thing might be some sort of mass or particle spectrometer but even then it might be multiple instruments in one. I'll take suggestions for an equivalent though if you have some and it makes sense.

I think it's more interesting to have multiple scanners for multiple resources. Plus, that way you have multiple part designs instead of just one. The other thing is that I personally do not send probes with every science experiment onboard so I never have to worry about fitting every scanner.

[Friznit]

It's always revealing to read a modder's own vision for how their mod should best be used!  I was labouring under the illusion that the Fuzzy Resource scan is a requirement for ScanSat resource hunting to even begin (albeit with Stock scanning disabled, so at least it's not a one click reveal all).  If the same outcome can be achieved with the individual resource scanners, then I think that's absolutely fair and adds an interesting challenge to missions if you can't get a magic handwavium read out of every resource in one pass.  It also gives me ample excuse to build more probes and lob them into orbit!

Edited March 22, 2019 by Friznit

[akron]

28 minutes ago, Friznit said:

It's always revealing to read a modder's own vision for how their mod should best be used!  I was labouring under the illusion that the Fuzzy Resource scan is a requirement for ScanSat resource hunting to even begin (albeit with Stock scanning disabled, so at least it's not a one click reveal all).  If the same outcome can be achieved with the individual resource scanners, then I think that's absolutely fair and adds an interesting challenge to missions if you can't get a magic handwavium read out of every resource in one pass.  It also gives me ample excuse to build more probes and lob them into orbit!

Yes, as far as I know using detailed science scanners such as from my mod has the same result as the narrow band scanner. The only difference is that you'll need specific scanners for specific resources such as the GRS for water

[Pappystein]

On 3/22/2019 at 7:08 AM, akron said:

So, I have not found a single part that would make sense as a replacement for that horrible stock monstrosity .

Wait!  you are not knocking the Solid, Flat plane AN/SPS-49 model are you?!!!  GASP!  

seriously though, if that model was mesh instead of a folding solid plate, and had some actual curves both top to bottom and span-wise to it and we mounted it on a spinney plate on-top of a mast, it would be a good SPS-49 replacement.     I can see where it's inspiration came from

All Joking aside.   I wanted to thank you @akron your last few posts have cleared up the reason why I have issues with ISRU in game with the stock functionality suppressed.  I need MOAR Probes!

 

PS if they wanted to make a flat and ugly scanner... I don't understand why they didn't just use the SPS-48 or the SPS-52... Would have been easier to model... Would have looked JUST as bad and would have done a yeoman work for a stock "flip the switch and exchange handwavium" to get results.

Edited March 23, 2019 by Pappystein
PS

[akron]

56 minutes ago, Pappystein said:

Wait!  you are not knocking the Solid, Flat plane AN/SPS-49 model are you?!!!  GASP!  

seriously though, if that model was mesh instead of a folding solid plate, and had some actual curves both top to bottom and span-wise to it and we mounted it on a spinney plate on-top of a mast, it would be a good SPS-49 replacement.     I can see where it's inspiration came from

All Joking aside.   I wanted to thank you @akron your last few posts have cleared up the reason why I have issues with ISRU in game with the stock functionality suppressed.  I need MOAR Probes!

 

PS if they wanted to make a flat and ugly scanner... I don't understand why they didn't just use the SPS-48 or the SPS-52... Would have been easier to model... Would have looked JUST as bad and would have done a yeoman work for a stock "flip the switch and exchange handwavium" to get results.

Hehe. Even then, technology for naval use might not be the right fit for orbital use in this case.

I don't think that it is the fact that the stock scanner doesn't look like a radar, I think it's that a radar alone won't be sufficient to map mineral (Ore) and other deposits (metals or water) or materials on the surface. I mean, you could infer the presence of material either currently or in the past by their effect on the topography (think Mars river and lake beds) but you cannot confirm it without chemistry or spectrography. 

My point is more that a radar alone won't be enough to map mineral deposits like the stock scanners do.

[golkaidakhaana]

@akron How's about a quick progress update?

[Pointblank66]

I seem to have found a problem with Real Fuels and Probes Plus.
About half of the engine parts are showing their plume effects when it shouldn't be active at all.

Down below is a screenshot of the problem and the mods installed. And also a link with the KSP Log in it

https://imgur.com/a/VHG3tnR

https://imgur.com/a/Sp2hDqm

https://drive.google.com/open?id=1e8BEMENKAaeDLO0ZQC-tONLHiDFNsV6q

[akron]

7 hours ago, sslaptnhablhat said:

@akron How's about a quick progress update?

Sure, Let me get a more proper update tomorrow evening as I've been out all day.

I still really need to get back to weekly dev streams or career gameplay because it keeps me better engaged and committed. I also need to go ahead and re-configure KSP to the new 1.7 version to test compatibility. Some of my dependencies or compatible mods have also been updated, and I need to upgrade. I did have to deal with a Windows 10 upgrade recently when I got the new video card as the GTX 1660 Ti drivers did not work with my Windows build. SMH

@Pointblank66 Thank you for letting me know. We had this issue before and I cannot remember how I fixed it or what the conflict was. I don't think it was Real Fuel, maybe RealPlumes? I'll look into it. Do engines also have the problem? Your screenshot only seems to show RCS thrusters.

[Pointblank66]

8 hours ago, akron said:

Sure, Let me get a more proper update tomorrow evening as I've been out all day.

I still really need to get back to weekly dev streams or career gameplay because it keeps me better engaged and committed. I also need to go ahead and re-configure KSP to the new 1.7 version to test compatibility. Some of my dependencies or compatible mods have also been updated, and I need to upgrade. I did have to deal with a Windows 10 upgrade recently when I got the new video card as the GTX 1660 Ti drivers did not work with my Windows build. SMH

@Pointblank66 Thank you for letting me know. We had this issue before and I cannot remember how I fixed it or what the conflict was. I don't think it was Real Fuel, maybe RealPlumes? I'll look into it. Do engines also have the problem? Your screenshot only seems to show RCS thrusters.

@akron Well only one engine has this problem too, which is the Linkor Service module. But only the RCS ports on it have the problem. The engine bell itself does not show the plume. All the other engines are fine too.
I have traced it back to Real fuels since I have not installed real plume seen in the second imgur link. Maybe RF has something of RP related installed with it but what it is, I have no idea.

I also posted the problem over on the RF forum post but so far no reaction

Edited April 21, 2019 by Pointblank66

[akron]

16 hours ago, Pointblank66 said:

@akron Well only one engine has this problem too, which is the Linkor Service module. But only the RCS ports on it have the problem. The engine bell itself does not show the plume. All the other engines are fine too.
I have traced it back to Real fuels since I have not installed real plume seen in the second imgur link. Maybe RF has something of RP related installed with it but what it is, I have no idea.

I also posted the problem over on the RF forum post but so far no reaction

As long as no actual engines have the issue, I am pretty sure the problem is the RCS fx plume. Now on that log you posted, you do show these two folders:

RealPlume-RFStockalike
RealPlume-Stock

ModuleManager is definitely detecting plume configs. There are hundreds of RealPlume entries all throughout your log. I am going to need another KSP install to test because I realized that you're running 1.6 and I've already updated to 1.7 but I'll keep working on figuring this one out.

Update

Along with that Windows re-install I had to deal with recently, I also had to upgrade to a new version of Maya. unfortunately, the NSUV plugin I used for UV editing now no longer works. While Autodesk has thankfully overhauled their UV editor and it's quite good now, I still had to relearn and get used to where tools are located now. I think I've got it figured out but not without slow progress and frustration so I've moved on from working on finishing UVs on Mariner 9's engine and back to modeling.

Viking has some pretty weird dimensions and offsets that have been tough to nail down. I first worked out the outer dimensions of the Aeroshell using a lot of math, but I think its fairly accurate. I needed to use it to help me model the lander within its size constraints. Viking is packed tight in there since the aeroshell has its own propulsion system along with the parachute and some other structure bits. 

The bus is the right size and the landing gear and engines are mostly done (Minus textures). The hydrazine tanks are roughly in the right location but the RTG wind covers are just a block-in. RTG dimensions are iffy to get since even old schematics are in the wrong measurement system so I don't know how accurate they are.

I could not find accurate dimensions for the MR-80 engine so those were eyeballed. 

All in all, there's been a lot of reading and looking over hundreds of Viking images and figuring out how much detail I wanna put on there since I do have to texture them later. On texturing and potential future art changes, I've been looking at incorporating a change in the color palette to better match along with the Re-Stock mod and Porkjet's style in general. Some older parts will thus need a remake eventually. I'm debating if I should go ahead and sacrifice craft realism in favor of a more stock aesthetic, especially with Viking. Feedback on that regard is appreciated.

Thank you all!

Edited April 22, 2019 by akron

[Drakenex]

looking so good! I say go stock, it will make anything you do easier to integrate with BDB and Tantares launchers and more pleasant to eye in overall 

[Pointblank66]

6 hours ago, akron said:

As long as no actual engines have the issue, I am pretty sure the problem is the RCS fx plume. Now on that log you posted, you do show these two folders:

RealPlume-RFStockalike
RealPlume-Stock

ModuleManager is definitely detecting plume configs. There are hundreds of RealPlume entries all throughout your log. I am going to need another KSP install to test because I realized that you're running 1.6 and I've already updated to 1.7 but I'll keep working on figuring this one out.

Those 2 folder come with the RF installment somehow. I removed them manually but the plume effect is still there.

[akron]

13 minutes ago, Pointblank66 said:

Those 2 folder come with the RF installment somehow. I removed them manually but the plume effect is still there.

If they come included with RF, those might be dependencies for that mod. I don't use that mod but I wouldn't delete folders unless you are sure it's not going to affect anything.

Now, for my mod, try deleting the RealPlume configs found here:

GameData/Coatl Aerospace/ProbesPlus/Compatibility/RealPlume.cfg

[Pointblank66]

7 minutes ago, akron said:

If they come included with RF, those might be dependencies for that mod. I don't use that mod but I wouldn't delete folders unless you are sure it's not going to affect anything.

Now, for my mod, try deleting the RealPlume configs found here:

GameData/Coatl Aerospace/ProbesPlus/Compatibility/RealPlume.cfg

I only deleted them on a test bench installment just to check.
Okay I will try, I'll let you know if that works,

EDIT
@akron 
Okay so I tried removing the RP config. that did not work.
What did work tho was the Stockalike RF config. So something in that config file is creating those plumes

Edited April 22, 2019 by Pointblank66

[Pointblank66]

I have found the problem.

@akron The problem seems to be with a module that is being added to the RF stockalike config for Probes Plus.
 

Spoiler

@MODULE[ModuleRCS*]
    {
        @name = ModuleRCS
        @thrusterPower = 0.1
        @heatProduction = 18
        @atmosphereCurve
        {
            @key,0 = 0 428
            @key,1 = 1 415
        }
        !PROPELLANT[LiquidFuel] {}
        !PROPELLANT[Oxidizer] {}
        !PROPELLANT[MonoPropellant] {}
        PROPELLANT
        {
            name = Hydrazine
            ratio = 100.000000
            DrawGauge = True
            %resourceFlowMode = STAGE_PRIORITY_FLOW
        }
    }

So as I suspected, it is definitely RF that is the culprit. Removing the above mentioned module fixes the problem.

[akron]

3 minutes ago, Pointblank66 said:

I have found the problem.

@akron The problem seems to be with a module that is being added to the RF stockalike config for Probes Plus.

So as I suspected, it is definitely RF that is the culprit. Removing the above mentioned module fixes the problem.

Yeah that's a generic "catch-all" config but I can't see why it would cause erroneous plume fx since it doesn't look like it references anything effect-related. I mean, unless the plumes are specific to the stockRCS effect (which I use) and since it gets removed, there's no module to control it.

I am glad you figured it out, Unfortunately removing that config means that a lot of parts, especially mine now will not use the RF "Hydrazine" fuel. Just keep that in mind.

[Pointblank66]

6 minutes ago, akron said:

I am glad you figured it out, Unfortunately removing that config means that a lot of parts, especially mine now will not use the RF "Hydrazine" fuel. Just keep that in mind.

That is the thing, I can keep the RF Stock config for Probes Plus and still use the RF fuels, ASLONG as I remove the "@MODULE[ModuleRCS*]" Modules.

I think the reason why it conflicts is bc it already has a RCS module installed in the config as seen below

Spoiler

MODULE
    {
        name = ModuleEngineConfigs
        type = ModuleRCS
        techLevel = 4
        origTechLevel = 4
        engineType = L
        configuration = Hydrazine
        modded = false

Idk how it conflicts tho, cause in the past both modules worked fine together with no major problem

Edited April 22, 2019 by Pointblank66

[akron]

@Pointblank66 It seems one RF config removes the stock modules while another adds it's own. I don't know the danger of using a part with two simultaneous RCS modules where one uses a deprecated fuel type, but if it works, it works!

@Drakenex Yeah, I want to close the gap between part styles. I am hesitant to oversimplify the look of iconic historical parts though, because then they lose their identity when painting them with a coat of stock paint. I really keep going back and forth on this and I can't pin something down. I just absolutely do not want every probe core I make to look like it was made by "Probodobodyne" though, because they're not.

Hopefully using the new color palette will help along with borrowed design elements. The foil surfaces will be cut back a lot and I can re-do a craft or two to be "naked" instead without foil texture switching. Xihe may be a good candidate to try it out, actually.

For Viking, I may do two texture versions. A typical white version with more "realistic" accents, and a grey version based on the FC3 model but with a stock grey color and style instead:

 

[Cavscout74]

Has anyone encountered an issue with Probes Plus tracking solar panels in 1.7?   Whenever I first launch a vessel & deploy solar panels, they deploy fine but don't track the sun at all.  When if I switch to another vessel or the space center & come back, they seem to track just fine.  I haven't noticed this behavior from stock panels.  Specifically, I've tried the Surveyor HGA Antenna/solar panel & the ET-120 solar panel.   I don't remember if I've tried any of the other tracking panels since the update.

[akron]

4 hours ago, Cavscout74 said:

Has anyone encountered an issue with Probes Plus tracking solar panels in 1.7?   Whenever I first launch a vessel & deploy solar panels, they deploy fine but don't track the sun at all.  When if I switch to another vessel or the space center & come back, they seem to track just fine.  I haven't noticed this behavior from stock panels.  Specifically, I've tried the Surveyor HGA Antenna/solar panel & the ET-120 solar panel.   I don't remember if I've tried any of the other tracking panels since the update.

I will test this. Can you post a log in the meantime?