MedievalNerd

This is simply the best thing ever, maintained by one of the greatest! Seriously, so many fuel tanks can go on the way side with this mod! And since I'm one of those people with mod fever, this helps reduce memory footprint by allowing me to remove at least a good 50 superfluous tanks! Save memory, go stretchy!

So good news! The custom experiment module is coming along nicely. What does it do? #1 - Allows you to assign specific bodies to experiments! This is something I really wanted, since experiments are by default applicable to all bodies, it was rather difficult to play with new experiments without having a butterfly effect of new science to be available down the road. #2 - Allows you to set an amount of "Data" required to be able to execute an experiment. #3 - Added a custom resource method that restricts the generation of this data to the same situation mask as the experiment. (Data is created at the cost of ElectricCharge) This is basically some added difficulty. Extra power, and also adds the requirement of staying in the situation mask for more than a fraction of a second. Also, I could easily make either 'ore' or 'ketane' be a requirement as well. So you could have 'Moon Kethane Science Mission" or "Duna Ore Science Mission" or whatever! Hopefully it'll be modular enough to anyone's liking. Once this functionality is working 'ok'. I'm going to consider having a MFT style interface in the VAB, where you could assign specific 'mission packages' to your probes, as opposed to having it be on a probe model progression. Cheers,

I haven't got to test the biome specific stuff yet, since I've been hassling over the instantaneous aspect of science, and that science instruments don't take energy. Little tidbit of the history of this project, before Science was implemented and I was working on a series of missions for MCE that would require the user to gain 'data' at key locations (set altitude, area, wtvr). This data collection process would expend energy and convert it into Data. (using the Kethane Plugin). Now trying to bring that idea into this new concept. I was thinking of doing the following: #1 - Include the Kethane plugin to probes, so that they can expend energy to convert it to Data. #2 - Have this customized plugin also inherit from the ScienceModule so that it can be assigned situation masks. (Can only collect data while orbiting X body in y situation) #3 - Add an additional check to experiments to see if you have enough of "Data" on the craft before the experiment can be triggered. #4 - Not sure if I can pull this one off, but have the probe expend the data once the experiment is performed. #5 - All these custom experiments will be implemented inside stock probes and tiered into the tech tree as to unlock "new missions". I've also been working on balancing the costs for the tech tree. What I'm doing is writing experiments a bit like missions in a way. Quick list of first experiments: (Sub Orbitals) #1 - Kerbin - High Atmosphere - Sensor Readings (100% transmit) + 5 Units of Data #2 - Kerbin - High Atmosphere - Sample Collection (0% transmit) + 10 Units of Data #3 - Kerbin - Low Space - Sensor Readings (100% transmit) + 5 Units of Data #4 - Kerbin - Low Space - Sensor Readings (0% transmit) + 10 Units of Data (Orbital) #1 - Kerbin - High Space - Sensor Readings - (100% transmit) #2 - Kerbin - High Space - Sample Collection - (0% transmit) Then I'd have some flybys: #1 - Mun(Moon) - High Space - Sensor Readings - (100% transmit) #2 - Eve(Venus) - High Space - Sensor Readings (100% transmit) #3 - Duna(Mars) - High Space - Sensor Readings (100% transmit) I only wrote the Data for the first tier, since I'm not sure how to balance that just yet. Also, thanks to Nathan (yet again) he's done some sweet math over the solar panels, and found a nice article that talked about their weight/performance. And I've created a tiered tweak to solar probes. So essentially they were heavy enough for the power they generated, but 'too heavy for their size' so ultimately over powered in the sense of the amount of physical space they took. So I scaled it down using the static panel, which creates ~20 Watts and but only weighs 135 Grams. Panel4 is essential as efficient as the static, but has 6 cells with matching weight to power ratio. Panel3 has a ~15% improvement over it's predecessor with no weight gain. Panels 2 & 1 are a bit heavier, but do get a weight to power ratio improvement. TLDR; power is getting there. Cheers,

I think it is. Also, are you using TreeEdit or TreeLoader? That seems to supersede some of the changes MM does since TL will apply changes to TechRequired post MM loading.

Still, that won't help his issue.

From what I understand Video Memory is also in the mix, so the program itself can't have the full 4GB. (Depending on how much video memory is in use.) I may be wrong. But in the end, the issue that Tommygun is having can't be fix by a program or changing the frame rate. It's about limiting how many assets are loaded.

First of all, any program that puts your computer into "Turbo mode" get rid of that. It's like with mobile phones, they make these 'app killer' apps which end up causing more strain than help, due to how they work. Plus you don't want to try to troubleshoot an isssue with something like that running. Frame rate has nothing to do with it. This issue is simply because A) 32bit program which can only use ~3.5GB of ram. The game must load 'all assets' upon launch and this, when using stuff like new planets, can cause a heavy memory footprint. As Krag herself said, this mod will require 'heavy amounts' of RAM. So at some point when you jump into the mod pool, and the mods that are memory heavy, you'll have to make a choice of which ones you want/don't want. Again, the only thing really affecting your system memory usage is the number of assests loaded on launch. Another way to tweak would be to get MFT & Stretchy Tanks & SRBS. Then delete all superfluous fuel tanks that come with all the mods. Also, go through the part lists of the mods you use. Are you using all their winglets and what not? If not, delete it. Each part you'll delete is one step closer to more memory. And please, get rid of anything that is a 'performance enhancer' software. Considering how hardware is usually waiting on software these days, don't bother with those things.

Ahh, so maybe I found out how to check for the biome, but I haven't tested it yet: public bool checkBody() { if (vessel.mainBody.BiomeMap.Map.name == "biomeName" && vessel.mainBody.name == "Duna") return true; ScreenMessages.PostScreenMessage("This experiment can only be performed at biomeName on Duna!", 3, ScreenMessageStyle.UPPER_CENTER); return false; } I'll try it out a bit later tonight. So I could make a MunEastCrater Module, so the experiment would check if you were near Mun & over said biome. (with stock checks for situation)

Yeah, if you would want to have science function on a time base, and generate science based on location and everything. That would require a custom plugin. The closest thing I can think of is Fractal_UK's science lab part in his Interstellar Mod. I'm not skilled enough to start messing with that level of detail for now. Things I'm doing to eliminate "grindiness": #1 - Experiments do not have partial return. The base & cap values match. #2 - Experiments are either transmittable or not. (Data vs sample) This avoids diminishing return situations. #3 - Less experiments, higher payout. #4 - No biome sensitive experiments. (Unless I figure out an easy way to adding this to the plugin) In an ideal world, I would prefer that experiments get unlocked/researched, which can then act as "modules" which can be dynamically attached to probes. But that's way harder than it sounds. Nathan, Fractal_UK & Ethernet provided me with some great references/code samples, but I'm too much of a noob to take it to the level where it needs to be to do this. Perhaps I'll go for round two down the line, but right now code 1, Nerd 0. So for now I'm adding specific experiments to probes, and will try to scale them to into the tech tree. (Kerbin > Mun > Minmus > Duna/Eve, etc. Cheers,

@Jay2Jay - As Visari said, the almighty NathanKell indeed. I've been nausing the hell out of him, so he's being extremely helpful. And the template of the plugin was actually written by ethernet, when I asked about body limitations on the science thread. So kudos to him too! OK, So without having the super cool, 'select your planet/experiment' VAB UI, I'm going to try and use planet specific experiments to give some flavor to probes. I might duplicate the probes once over, to have a both "sensor & physical" version of each experiment. We'll see how it goes. I was able to test a Kerbin only experiments. I setup a high atmosphere experiment for Kerbin. First one would be just to get into atmosphere and you can transmit back Data, and the other would be to gather samples and land safely back. With a combination of body/condition you can basically create misison profiles for probes. (IE, Mun probe for orbital tests(Low/High space), Surface scans(Surface), or Sample collection (Surface + 0.0 Xmit). Playing with Earth-Kerbin totally changes the scope of things obviously, when sending ~200kg into orbit requires quite a bit of planning! I'll go through a quick list of 'missions' to get an idea of balancing and then I'll put out a first version of the Tech Tree, along with all my tweak .cfgs and the Body Exclusive plugin which I'm finishing up. By using the tweaked module (KerbinExperiment, MunExperiment) you can create your own experiments and contain them to specific bodies. It's making some form of progress, just taking longer than anticipated. Cheers,

Very nice, redefines what is 'far'.

I wasn't around when this happened. But I'm really baffled as to how this could ever be ill received. This is pure genius this and earth rescale are some of sky rocketing to the top of my list.

I see that the Kerbnet minions have been made aware of my last public address. What I can see to this 'excited' Kerbal is that his tin foil hat won't save him when the Kerbal economy goes down because we wasted all our money sending rockets to nowhere! Kerbals need to know the truth! - Concerned Hard Working Kerbal

There more things I hear about this, the more I believe that this is a ploy by secret Kerbal Officials. As interest has been waning in the Space Program, they are simply trying to find a way to entice the Kerbal population to endorse this ludicrous enterprise of finding more planets or muns. Heck, pull out your latest copy of Encyclopedia Kerbica, and show me where it says that there might be other planets out there. Nothing. You won't find anything about this, because there is nothing. You heard it from here first folks! The Kerbal government is messing with your minds with promises of distant yet to be seen lands. I say someone failed to clean the telescope and thought it was a planet, when it was a piece of dried piece mozzarella. Yes, it was moldy, hence the change in colors and everything. There is a logical explanation to all of this, and to believe in all this fantasy, that there is more to space than what is currently known, is a pipe dream built by tin foil hat wearing Kerbals, who've taken advantage of the Kerbnet to spread their madness. So before you fill out your next tax form, better think about where your Krones are going! Stop the lies! - Concerned Hard Working Kerbal

Yikes, I vainly tried to figure out how to create a way to dynamically change internal probe experiments, as opposed to having a list list of duplicate probe parts (IE, reuse the same mesh a few times and assign those specific planet experiments to them), and I have to say, hat's off to people who write plugins, I have no idea what I'm doing. I'm going to drop the idea of planet specific experiments, I lack the skills to make that possible without having either way too long list of actions on a probe, or long list of probe parts. Which would be annoying considering how already full the VAB is, or gets over time. Sorry!

Much success with ethernet's gracious code. We can have planet specific experiments! Woo! Just tested the compile .dll and it worked! Going to add all planets, and then when I create an experiment I can refer to this new module when including it to science parts! This could lead to a interesting diversity of probe cores. With giving them specific bodies they are 'meant' to explore for experiments. Either that, or make 'theoretical' nodes, which unlock new experiments to existing parts. Maybe this is a little too hardcore, but I think I'm interested in the idea of redoing all experiments, and making them planet specific. The advantage of this is it allows for finer tweaking of the impacts of experiments and their costs. Right now we have fixed multipliers for celestial bodies. IE, 10 science point experiment is worth 40 points on Mun (x4) and 70 on Jool (7x). So any tweaking of science experiments values or new ones, has quite the butterfly effect when it goes through all the celestial bodies. This is even pushed further depending on how many situations the experiment is applicable to (land, low/high atmosphere, low/high space). Now to see if I can find a way to make these modules check a tech level before showing up in the part itself.

Do not be sorry! It works and it's amazing! Now I can work in some unique planet specific experiments! You rock good sir!

Yeah, that could be an option. But considering that you'd then have to check half-life/degredation values and meh. That seems like a bit of hassle. I'd rather look at their overal lifetime and use an average. Also, considering for 'how long' some of them last, perhaps a it would be trivial to have a resource to begin with. (Will you ever do a 20+ year mission in ksp?... Well, maybe with earth-sized kerbin ) As for firespitter, as I mentioned I'm not factoring it into the tree. So on top of tweaking the electrical values, the parts won't appear in areas where you would expect them to be. I tried to keep stock nodes in logical locations, but considering on how many splits my tree has, it wasn't really possible. Should be noted that the primary focus of the tree will be early rocketry on up. I'm not going to have people start with only planes. You start with 0.625 engines only, and you pick your progression. (better fuel engines, better SRBs, etc.). (Preferably with KATO engines from Nathan using Modular Fuel Tanks) I've had illusions of grandeur and create customized experiments based on celestial bodies, but it's proving to be not something you can really do 'stock'. A kind soul wrote me a quick plugin, but I'm running into issues when trying to build the code. (Super noob at KSP plugin creation) The work continues.

You can't make anything fool proof. And since we aren't talking about rocket science here; making sure you have the right version of module manager in your gamedata directory. I don't see how significant amount of people would be having issues with this? What I see the most is people not sure which version they are dealing with, then confusion about how dates are kept with their OS. (IE, resets date to when you downloaded). So having a version number in module manager solves all that. Plus trouble shooting would be extremely easy. "Do have more than one MM .dll in your game data folder? Oh you have V13 and v14. You can only have the latest version." Done. As Nathan points out in a later post, trouble shooting would be increasingly complicated with each additional mod. If we are talking about a average user, I don't see how checking .dll files in all folders will make things easier for them. That combined with potentially outdated versions of MM running all the cfgs in the KSP directories, that alone would probably would lead to some very obscure issues when described in laymen terms. And then trouble shooting will become more of a hassle. Also, there is a limit as to how low of a bar you want to set for the usability of something. I disagree that something needs to be set at the level of a nigh-clueless PC user, because they need to step up their game, not make things easier for them. I mean, we are talking about version control on the mods they download... not editing files or creating parts here! If somebody can't keep track of their files, as I stated previously, there is a bigger problem in the mix that has nothing to do with KSP or MM. And no amount of 'oversimplifying' will solve it. As others mentioned, I have yet to see a mod that uses a custom MM version. And I doubt that would be attractive to people who area already using mods that use "regular" MM. Version numbers will make everything easier, I promise.

Thanks again for this. But I think i'm missing a reference somewhere, it does not want to use the Duna string. And there it's stating a missing parameter: Error 1 Operator '==' cannot be applied to operands of type 'CelestialBody' and 'string' e:\migrate documents\visual studio 2010\Projects\Project1\Project1\Class1.cs 6 6 Project1 Error 2 No overload for method 'DeployExperiment' takes 1 arguments e:\migrate documents\visual studio 2010\Projects\Project1\Project1\Class1.cs 19 5 Project1

Darn, Seems that it probably needs to be linked to biomes. Because I have an experiment that isn't biome sensitive. And when I do experiments which aren't defined the game makes a generic reponse, even though none is listed. (I removed it) Do planets who do not have biome diversity, have '1' biome applied for the entire planet? So I might actually need to give your module a go ethernet!

@BananaDealer, I read the OP, please let's not get into semantics. I'm pretty sure you understood what I meant about 'altitude' since we were already talking about the masks, moving on. Also, I'm specifically talking about making unique planet experiments. Not restricting where it can be executed, I've already done that with an experiment I created for probes. Now that part about what you said about not having default response, that sounds like a winner. @ethernet, Thanks for understanding my madness. It was planet specific, not surface only. Perhaps BananaDealer is on to something with not having a 'default response'. Cheers,

Those masks deals with biomes & altitude. I'm talking about celestial body.

Is there a way right now to limit which planet is applicable to an experiment? Trying to think of ideas to make unique probes/sensors. If this would possible it might be interesting.

@Visari #2 - I wasn't inferring that science parts would consume power, but that would be interesting. Would you mean that they consume power per use, or that they have a general power consumption? #3 - Yeah, having both a partial base value with a partial Xmit value can do some fun grinding. So perhaps matching base/cap values, with a lower Xmit factor but, with single use instruments that are balanced by Krone cost. (MCE) #4 & 5 - Yeah, perhaps a yes/no solution would be best. Some experiments can be transmitted others not. Right now I'm toying with 150wats per packet. (should be noted that it's a bit arbitrary for me to say this since it's in conjunction with my probe/electricity tweaks and my tech tree) @Jay2Jay Howdy Jay2Jay, I have very little experience myself. It if wasn't for Nathan there would be quite a few things that would have taken me 'wayyy' longer to do/find, etc. I'm not touching anything plugin related for now, I try to make use of what's available already. In mods and the likes. (You need permission of said creator if you would release something that uses their plugin obviously) Right now i'm still in process of balancing. Yes, it's never ending. Plus I'm tweaking science costs, and also starting to look at part prices so that I can figure out how much it costs to send what where. And figure out mission payouts. But I'm starting to think it would be way easier if people play the tree and give me feedback about whether they hit snags in progression or if something is too difficult. One caveat though, it's that you would absolutely need to use the mods I use, and even more importantly the custom .cfg files I'm making. The reason being that things like, not playing with KIDS, or using stock energy will greatly put off balance the 'flow' I'm envisioning. So in order for the feedback to be relevant it'd be important to play it in the same conditions I am. I'll play it again tonight and try to get maybe 2-3 tiers balanced, and ask r4m0n to put it public. Then you can try to help balance this beast with me. I say beast, but the real beast is the 'first' intended tech tree I originally posted about. R4m0n pulled a rabbit out of his hat and now newNodes can be linked to other newly created ones without any funky connection issues. But that's going to wait a bit, I'd like to get a sense of balance with this more simple tree. That way once I get that close to a decent stage, i'll be able to apply what we've learned to the realism tech tree. I'm also a bit concerned in releasing it too early, unbalanced then people will just get a bad experience and not come back. There are so many facets to balancing, and I'm no expert statistician, so it'll take a bit of time. We'll get there.