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

[biohazard15]

Not sure where this should go, so I'll post it in both topics.

There is an interesting visual glitch with Mag Boom and LoadOnDemand plugin:

It looks like that LoadOnDemand doesn't load alpha texture for boom (the rest looks OK). Launch clamps looks the same when its texture isn't loaded - but it loads correctly.

[DMagic]

It looks like that LoadOnDemand doesn't load alpha texture for boom (the rest looks OK). Launch clamps looks the same when its texture isn't loaded - but it loads correctly.

That's weird, maybe there is some better way to set up the alpha channel for my textures so that this won't happen. I'll look into it, but this is probably a problem with the texture loading mod.

Hmm, this kinda defeats the very purpose of procedurally-generated asteroids - catch only 5 of them, and you won't get any more science except stock sample.

I was also considering the scale of science return when I set it up this way. The stock asteroid sample seems to ignore the regular situation multiplier so it always gives 50 or so science, which makes this a really impractical way to build up too much science, but also prevents asteroids from further throwing off the career mode balance too much.

My parts don't do that though. A full set of science reports for a class E asteroid can return around 1000 science. Getting that much science for every class E asteroid you manage to rendezvous with would make the science points balloon even further out of control.

I do like the idea of setting up some kind of diminishing returns for each asteroid class, so maybe you could get results from four or five asteroids before you ran out (but keeping the same overall total amount of science for each class).

Even better would be assigning a spectral type for each asteroid and basing the diminishing returns and science reports off of that instead of just size. My current science reports sort-of do this, but really I just randomly assigned each asteroid class to a different type (Class E are M-type asteroids, Class A are S-type etc...) while writing the science reports.

I remember someone somewhere talking about removing the weird way asteroid science gets done in stock with different results for different orbits. Was that here? If not, what do you think about that? Any plans?

I'm not sure how to go about changing the Kerbal-specific stock science experiments. Those are all locked away either in the Kerbal code (crew reports and surface samples) or the asteroid module code (asteroid samples). It would be easy to set up a different method of collecting stock asteroid samples (with a robotic collector for example), but altering the stock EVA experiment would be more difficult. But yes, the stock method of getting multiple results from the asteroid based on your orbit is dumb and hopefully it gets changed.

Edited April 29, 2014 by DMagic

[biohazard15]

Is it possible to combine both ways?

- There is a cap for every asteroid class, let's say 500 points per experiment

- You can conduct experiment once per asteroid (if you try to conduct it again, you'll get 0 points)

- Experiments yield small amount of science (smaller than stock sample, around 20-30), this amount diminishes with every conducted experiment (i.e. 30-27-25-23-etc)

- When you hit the cap - you won't get more points from experiments

This will give a reason for asteroid interception, and won't destroy stock science balance.

[kiwiak]

Cool, update of my favourite science mod.

By the way - i will post here something i wrote in interestellar thread, maybe youw ill find that idea usefull dmagic:

I have suggestion for another type of impactor experiment.

Impact observation, smash something into mun and observe dust impact created to find about moon crust composition.

Something for early tech tree, before landing legs, we smashed things into moon before soft landings after all in real life.

To do experiment, observation craft woudl have to orbit moon/minmus (or something else?) and be in line of sight with impact site, science income woudl be vary depending on altitude, maybe time spent on watching impact results?

[biohazard15]

I second the impactor idea. Always wanted to crash something for science, but I don't want to install Interstellar.

[DMagic]

- There is a cap for every asteroid class, let's say 500 points per experiment

A per experiment science cap is an idea that I've been toying with for a long time. I think this would be a great way of getting around the explosion in science points caused by the addition of biomes.

The method I'm thinking of would be to have the standard cap and base values for each biome, but put a cap on each planet and have each successive experiment give diminishing returns. So it would basically work as it does now, just with an additional layer of diminishing returns: an experiment in biome 1 gives 100% of the standard return, biome 2 gives 80%, biome 3 gives 65%, etc... (maybe taking into account the total number of biomes per planet).

Something similar should be easily possible with asteroids. The asteroid class would be treated like an individual planet and the unique asteroid ID number would be treated like the biomes for each class. That would essentially work exactly as you described. Though I think it's reasonable for the first one or two experiments to give a relatively high science value (maybe 50% of the cap after three separate asteroids), so that people wouldn't be forced to farm asteroids for little science return.

I second the impactor idea. Always wanted to crash something for science, but I don't want to install Interstellar.

I think I'm resigned to the fact that I'll never actually be able to actually play KSP again.

This is something I've wanted to be able to do ever since I made my Deep Impact mission (even though I think that one turned out pretty well). I'll check out how KSPI does it, but I don't think there's anything too complicated going on and it should provide an opportunity to make an interesting part.

[kiwiak]

To add variety to ateroids, i suggest some composition variability (as i did before). Random chance that asteroid is made from iron/rock/ice (comet?)/gold

[kellven]

Would really really like a wedge mystery goohickey, the pill is just so incredibly awkward. I'd like a science jr wedgie also, but know someone will veto that.

I realize I could do it myself in 2 minutes with notepad, but I'm religious about not modding these days.

Great stuff with the rest of the parts I've tried so far.

[Tessai]

Love the Universal Storage parts, now if you could put all the science stuff in them .. hint hint

Seriously tho, good work.

[DMagic]

To add variety to ateroids, i suggest some composition variability (as i did before). Random chance that asteroid is made from iron/rock/ice (comet?)/gold

That multispectral scanner that I've been showing off (but not actually working on) would be perfect for identifying asteroid composition. That's how they are classified in real life, so it would be a great addition.

Would really really like a wedge mystery goohickey, the pill is just so incredibly awkward. I'd like a science jr wedgie also, but know someone will veto that.

I realize I could do it myself in 2 minutes with notepad, but I'm religious about not modding these days.

Great stuff with the rest of the parts I've tried so far.

Love the Universal Storage parts, now if you could put all the science stuff in them .. hint hint

Seriously tho, good work.

Thanks.

My plan for the next release is to fill out the US parts with the other three stock science parts (goo, mat bay, and atmospheric sensor) and hopefully to replace the wedge model. I should also be able to get the telescope finished, I just need to fix its animation.

The rover parts could also be put into the US wedges. But I really need to figure out a good way of getting them to actually point at the ground when you use them. I have some ideas in mind, but I just need to sit down and figure it out (and this would be good for the regular laser and drill parts too).

[phoenix_ca]

For those of us who do use KSPI, an MM config for the wedge with the Double-C in it that enables the KSPI experiment would be nifty. It might even be possible to just include that as default behaviour if KSPI is installed using a MM config file...though I haven't looked too much at how it parses things. I don't know if you can get the equivalent of an if-then with it. Maybe though.

[biohazard15]

The rover parts could also be put into the US wedges. But I really need to figure out a good way of getting them to actually point at the ground when you use them. I have some ideas in mind, but I just need to sit down and figure it out (and this would be good for the regular laser and drill parts too).

Hmmm, I've actually got a better idea. Rover parts could fit US wedges, sure - but why not make a rover body from US wedges? You'll need a flat base with nodes and such (modular in the same way as stock structural panels) and rectangular (1x1) wedges. Maybe even retractable wheels (that would be EPIC COOL - just imagine: you land a 3x4m box, push couple of buttons - and voila, you've got a fully functional rover!)

Something like this (sorry for terrible graphics, that was made in Word in 1 minute):

EDIT: And if that impactor idea ever materializes - please, make it compatible with other parts via MM. I've just got a crazy idea involving impactors, Lazor missiles and FASA nuclear warheads... Crash things for science? That's lame.

NUKE things for science - now we're talking!

Edited May 1, 2014 by biohazard15

[kiwiak]

small suggestion for anomaly scanner, included KAS grab module woudl be usefull, for taking it from lander to kerbin return ship.

[biohazard15]

small suggestion for anomaly scanner, included KAS grab module woudl be usefull, for taking it from lander to kerbin return ship.

There is a mod for that: http://forum.kerbalspaceprogram.com/threads/71683-A-Mechanic-Is-Jeb-or-KAS-For-Almost-Everything

[Daishi]

My plan for the next release is to fill out the US parts with the other three stock science parts (goo, mat bay, and atmospheric sensor) and hopefully to replace the wedge model.

If you can afford to wait a week or so, i'll be releasing the blank science bay part where you'll be able to mount your own parts inside. It will have a wider door hatch like your current wedges, so your pro science parts should fit in there just as snug!

You could also use that .cfg file referencing thing to embed our science bay into your current parts too, as long as its sourced from our original file directory, and credit is given. That way if we change the models it should seamlessly update onto your parts with no maintenance required on your behalf, and both of our models should act as a single part. Also saves you the effort of trying to model something identical, and you wont have attachment issues because the collision meshes will be identical to the rest of our wedges

[DMagic]

For those of us who do use KSPI, an MM config for the wedge with the Double-C in it that enables the KSPI experiment would be nifty. It might even be possible to just include that as default behaviour if KSPI is installed using a MM config file...though I haven't looked too much at how it parses things. I don't know if you can get the equivalent of an if-then with it. Maybe though.

I might look into a making a KSPI MM for all of my parts that could be used in both mods. For now I think that's just the magnetometer and Double-C.

There are some aspects of the parts that could be cleaned up a bit if they are being used in KSPI, I can turn off the magnetometer readout for example.

Hmmm, I've actually got a better idea. Rover parts could fit US wedges, sure - but why not make a rover body from US wedges?

Well, that would be awesome, but that's way beyond the scope of what I intend to make.

For the rover parts (and telescope too actually) what I plan to do is put the laser/drill segments on extendable arms with a rotating base on the end (and maybe a hinge with a limited range of motion). Then I can rotate that base so that it's pointing in the direction of the ground before activating. And I would eventually like to put in some kind of ground contact detection so that it actually has to touch the ground to return results.

If you can afford to wait a week or so, i'll be releasing the blank science bay part where you'll be able to mount your own parts inside. It will have a wider door hatch like your current wedges, so your pro science parts should fit in there just as snug!

You could also use that .cfg file referencing thing to embed our science bay into your current parts too, as long as its sourced from our original file directory, and credit is given. That way if we change the models it should seamlessly update onto your parts with no maintenance required on your behalf, and both of our models should act as a single part. Also saves you the effort of trying to model something identical, and you wont have attachment issues because the collision meshes will be identical to the rest of our wedges

That should work ok. I'll have to figure out how to work out animations from two different mesh files in the same part, but otherwise I don't think there will be any problems.

[FlowerChild]

Just a small observation: I've been thinking of different methods of evaluating asteroid class for use in BTSM, so I decided to take a peak at your weight based classification code and noticed one small thing that I wanted to point out in case it helps:

I've had a B-class weigh in at 44.1 tons, and a C class weigh in at 46.2, so I suspect the dividing line between the two rests closer to 45 tons than 50.

Currently I'm initializing my own class tracking variable when asteroid parts are first loaded so that they don't wind up being overwritten when the vessel docks, but that obviously has problems in that asteroids spawned without the mod installed will wind up being evaluated as C-class when it is.

I'm not sure how to go about changing the Kerbal-specific stock science experiments. Those are all locked away either in the Kerbal code (crew reports and surface samples) or the asteroid module code (asteroid samples). It would be easy to set up a different method of collecting stock asteroid samples (with a robotic collector for example), but altering the stock EVA experiment would be more difficult. But yes, the stock method of getting multiple results from the asteroid based on your orbit is dumb and hopefully it gets changed.

And just on this point as I glanced over the thread: I'm already modifying stock EVA experiments within BTSM, so feel free to check out the code there if you'd like to see one method of doing it.

Edited May 2, 2014 by FlowerChild

[acc]

Why does the sample drill only work on planets with atmosphere?

[phoenix_ca]

Why does the sample drill only work on planets with atmosphere?

Because reasons?

[DMagic]

Just a small observation: I've been thinking of different methods of evaluating asteroid class for use in BTSM, so I decided to take a peak at your weight based classification code and noticed one small thing that I wanted to point out in case it helps:

I've had a B-class weigh in at 44.1 tons, and a C class weigh in at 46.2, so I suspect the dividing line between the two rests closer to 45 tons than 50.

Currently I'm initializing my own class tracking variable when asteroid parts are first loaded so that they don't wind up being overwritten when the vessel docks, but that obviously has problems in that asteroids spawned without the mod installed will wind up being evaluated as C-class when it is.

And just on this point as I glanced over the thread: I'm already modifying stock EVA experiments within BTSM, so feel free to check out the code there if you'd like to see one method of doing it.

Thanks for that. I checked about 20 or so asteroids to get those mass ranges, but I figured they might be off by a little. My bigger fear is that it might be possible for the ranges to have some overlap. I ran into that same issue with using the Discovery Info size value and figured it wasn't worth the effort to work around it. As far as I know that's the only indicator of asteroid class (and you'll notice the class is never referred to again after you've approached within loading range of the asteroid), so maybe I'll have to see what you come up with.

I don't have any real plans to make do anything with EVA experiments, but if I do ever come up with something (asteroid samples would be most likely if I ever implement some kind of asteroid composition system) I'll check it out.

Why does the sample drill only work on planets with atmosphere?

Well, it's not really a sample drill, that would basically be the same thing as an EVA surface sample.

It's designed to search for trace levels of gasses associated with biological activity. You could probably come up with an experiment designed to search for biological activity (or maybe a more likely idea is an experiment designed to look for the remnants of biological life, not on-going activity) on non-atmospheric planets, but it would presumably look very different from one designed to look for some kind of microscopic lifeforms that share at least some similarity to known lifeforms.

I think I need to continue my series (or maybe that should be start my series) on the actual science behind all of these parts. I wrote up a post about the RPWS because that is the most esoteric and complicated of the parts I've made, but I always intended to write more in depth explanations about the other parts as well.

[FlowerChild]

Thanks for that. I checked about 20 or so asteroids to get those mass ranges, but I figured they might be off by a little. My bigger fear is that it might be possible for the ranges to have some overlap. I ran into that same issue with using the Discovery Info size value and figured it wasn't worth the effort to work around it. As far as I know that's the only indicator of asteroid class (and you'll notice the class is never referred to again after you've approached within loading range of the asteroid), so maybe I'll have to see what you come up with.

Yup, that's basically the same stuff I ran into while working on my code. For BTSM though, it's not a big a deal mind you as if I initialize my tracking variable based on discovery info when the asteroid is first loaded, then I am sure to have the right info from that point forward. Given BTSM is the kind of thing that you tend to play an entire save with, rather than something you install on a game already in progress, this was an effective solution for me, other than for the initial release where people updated and thus potentially already had asteroids loaded in their saves that didn't go through my initialization process and thus defaulted to class C based on discovery info.

Anyways, yeah, feel free to take a look at what I did for it. I decided to take a look at your system to get a better idea of the actual mass ranges, and have been keeping records of the mass of all asteroids I come across (I'm using those values to also generate resources consumed by other parts in my mod), so I'll let you know if I spot any other discrepancies as I move forward. The other asteroids I've encountered so far seem to fit into your ranges, but I'm still dealing with a small sample size. Was just a fluke that I seemed to get two that were so close to the max and min values of Class B and C.

[acc]

Ah, now I understand.

Thanks for explaintation

[DMagic]

Yup, that's basically the same stuff I ran into while working on my code. For BTSM though, it's not a big a deal mind you as if I initialize my tracking variable based on discovery info when the asteroid is first loaded, then I am sure to have the right info from that point forward. Given BTSM is the kind of thing that you tend to play an entire save with, rather than something you install on a game already in progress, this was an effective solution for me, other than for the initial release where people updated and thus potentially already had asteroids loaded in their saves that didn't go through my initialization process and thus defaulted to class C based on discovery info.

Sometimes I feel a bit dumb...

ModuleAsteroid.prefabBaseURL saves a string with the asteroid's class value in the persistent file: "prefabBaseURL = Procedural/PA_A" or B, C, etc... It isn't affected by the DiscoveryInfo size, so it doesn't matter if you've docked to it or not. The only problem is that you have to actually load the asteroid before ModuleAsteroid is applied.

So I guess if you just want the class value you can record the DiscoveryInfo size as soon as it loads like you're doing. But if you only need the info when you're within part-loading distance, or you want an accurate reading after the asteroid has been docked to you should be able to grab the prefabBaseURL and pull out the last character in the string. Either way it's much better than the mass based thing, though there are some cases where having more of a smooth sliding scale based on mass might be useful.

[FlowerChild]

ModuleAsteroid.prefabBaseURL saves a string with the asteroid's class value in the persistent file: "prefabBaseURL = Procedural/PA_A" or B, C, etc... It isn't affected by the DiscoveryInfo size, so it doesn't matter if you've docked to it or not. The only problem is that you have to actually load the asteroid before ModuleAsteroid is applied.

Oh wow. Thanks for sharing that man. I hadn't noticed it either and it's an extremely valuable piece of info

[Starstrider42]

Even better would be assigning a spectral type for each asteroid and basing the diminishing returns and science reports off of that instead of just size. My current science reports sort-of do this, but really I just randomly assigned each asteroid class to a different type (Class E are M-type asteroids, Class A are S-type etc...) while writing the science reports.

I will be setting up composition classes for Custom Asteroids. However, I'd like to see what interface Taniwha decides on for asteroid mining before I implement this, so it may be a while.