Morphisor

Because you can't run it with those specs. They're barely enough for KSP itself unmodded.

That doesn't really answer my question, sorry.

In your case you're showing the Leftovers contract, which is the one contract that does not differentiate across situations. Is that what you'd suggest here then?

Why should it be excluded?

I assume this follows the name used on Spacedock; I didn't have it in the title there. I just edited that, hope it helps.

This doesn't replace it entirely nor is it meant to, but sure for most science you could!

You'll find that the surface contract used here excludes any experiment starting with the string "ROCScience", that oughta take care of the first issue already. Field research does the same for its surface scientist mission, though perhaps it pops up in other contracts there. That shouldn't happen here though. As for the station parts thing, that's a thing on their side in my opinion. I'd agree that it's not ideal, but I'd rather stay away from trying to fix other mods' issues to suit our needs. I'd recommend requesting the change on their end, patching locally or simply declining when a contract tries to involve something silly and you don't wanna go for it. Some players may actually appreciate the challenge.

Oh my, you're right. What a rookie error. Should be fixed now!

I'd like to dedicate a post here right away to further explain the rationale behind this contract pack. I've been playing career stuff for years, and I always use Field Research in those games; science after all is the core progress mechanic in this game and the stock game does a poor job of providing incentives for any of it. Even so, something about it all still never quite clicked for me. Recently I realized this is because while Field Research does an excellent job in showing the opportunities available, for me at least the resulting missions needed to complete the contracts just didn't feel like the way I'd want to go about it. This mostly comes down things like the biome studies mixing all situations for a single area and with different experiments for each situation too, which often means a whole set of launches needed to get it all done. Or the surface science requiring a rando scientist to be taken along, taking up a precious crew slot that could've been used to gain experience for your existing crew - or maybe even going in without crew at all! And that's where the idea for this pack was born: I wanted to do science, but using mission profiles that just make sense. I did my best to provide missions that provide flexibility of approach, but allow the player to use a more 'realistic' approach to mission planning. I tried to somewhat limit the diversity of experiments requested to avoid spacecraft being stuffed like ugly mules just because the contract asks for it, but still having a meaningful number of subjects to cover. The orbital and atmospheric contracts will often require the same experiment to be run in multiple situations, but there's some luck involved in the random draw. I also entertained the idea of separating contracts for transmission from contracts for recovery of experiments, but I couldn't figure out a way to make this work - both in gameplay terms (quite some overlap) as in technical terms - I do not know of a way to filter experiments with low to no transmission value, since this info is stored in the part definitions, which CC does not read in this regard, and not in the experiment definitions themselves. Different parts for the same experiment can have different transmission efficiencies, so I gave up on this. Should you know a way to work with this though, I'd be all ears. The reasoning behind the individual contracts is this: 2 types of orbital missions which most of the time should be doable with satellite probes. You could combine them with setting up a relay or a SCANsat mission. The orbital biome observation hopefully promotes alternative orbit profiles like molniya. For the surface study, I felt it important to do a good bunch of experiments once there. After all, going to the surface of another place is not something done lightly, so if we're going we better make it count. This contract should also draw splashed situations when seas are involved, though my testing showed that some planet packs (like the otherwise excellent JNSQ) have a tendency to ask for landed situation on sea biomes instead. Nothing I can do about though, CC just reads the definitions put out by the planet pack. Atmospheric investigation is the setup I had my most doubts about, after all how well does this balance out when this is requested for a far away planet. It may demand some significant mission planning and overkill builds - do please let me know how it works out for you! I'd also be very happy to consider alternatives or an additional atmospheric contract type if anyone has good suggestions. Finally, I felt the need for a leftovers contract as well. While Field Research has its own 'Scraps' contract, it's only one experiment at once, and who has time for that when there's hundreds! BTW, this pack does not include its own equivalents of 'hard science' or 'KSC science', Field Research already does an excellent job there. I'm very much open to suggestions on improving or expanding the contracts, do please leave a message!

INFO Research Advancement Division is a contract pack designed provide direction and reward players for doing science experiments. It is intended to be an alternative or complementary to Field Research. The difference with Field Research is that these contracts are designed with logical mission profiles in mind: each contract should be complete-able within a single flight, without unnecessary limitations. Included are currently 7 contracts: 1. Orbital study: a variety of experiments across all available biomes, low and high space only 2. Orbital biome observation: experiments focused on 2 specific biomes, low and high space only 3. Surface study: a big suite of experiments while landed (or splashed) in 1 specific biome 4. Surface analysis: smaller set of experiments than the surface study, but spread out over 2 biomes instead. 5. Atmospheric investigation: suite of experiments while flying high and/or low in the atmosphere of a planet, across several biomes. 6. Local Observation Flight: a big suite of experiments while flying high and/or low in 1 specific biome 7. Leftovers: several experiments that have already been done before, but still have >1 science value left to be recovered. All contracts are targeted at a single planet/moon at any time and only request science subjects that have not been done at all or at least have some value left (Leftovers contract only). Mods which add additional experiments are automatically supported! Feedback is welcome! IMPORTANT: To ensure the best functionality for the surface contracts, I recommend all users to navigate to the Contract Configurator main folder (located at Gamedata/ContractConfigurator) and delete the files named BiomeData.cfg and BiomeDataDefault.cfg. Once you load up the game of your choice the biomedata will be automatically regenerated, this time with the correct values. DOWNLOAD Github: https://github.com/Morphisor244/Research-Advancement-Division/releases SpaceDock: https://spacedock.info/mod/2929/Research Advancement Division DEPENDENCIES Contract Configurator by Nightingale is a hard dependency, without it this will not work! Get it here: CHANGELOG RECOMMENDED MODS CREDITS @nightingale - For providing Contract Configurator and Field Research @Friznit - Concept feedback LICENSE CC-BY-NC-SA-4.0

I concur with Jimmy, Scansat is your best bet. In this particular case however, WBI is an uncommonly tiny biome which is extremely frustrating to try and cover from high space. Best bet would be to launch a satellite on a molniya orbit such that the highest part of the orbit crosses the latitude of WBI location.

Don't even try.

You should be able to copy patches from Tetrix and apply the corresponding node names. Let me know if I can be of help.

Not a dumb question at all, in fact that is indeed possible. I chose to use tech tree nodes as unlock requirements instead to allow players to be creative with what parts they use for the contracts (the majority of experiments is available on multiple parts). Even if I set it to unlock at a specific part, players may end up not being able to do the contract as the parts of for instance OGO or Nimbus are spread out across multiple nodes, especially in tech tree mods like that. Also, requiring a part unlock may for some players 'hide' the contract since it wouldn't be available until the part is actually purchased for use (the first time 'development' unlock you do in career). The good news is that it's pretty easy to write a MM patch to change the requirements to match the tech tree. I highly recommend this to be done from the tech tree side, in fact I wrote exactly such a patch for Tetrix tech tree myself last weekend. Skyhawk should be able to copy it over and adjust accordingly.

I had another look to try and be more helpful. Most parts are fine by positioning actually, with one exception: the parts designated as Mariner-2 (Cosmic dust collector, radiometer and ion trap chamber) are in a higher node than the rest of the ranger parts. Whereas Mariner even predates some of the other ranger parts historically and they're essentially the same design. The problem with the BDB contracts consists of the contracts checking for a certain tech node to be researched to become available. Most probe contracts use the tier 1 nodes, since that's where the probe cores are placed within BDB itself pre-patching by any tech tree. To fix this, we should patch the contracts to only be available as the corresponding node is unlocked as well. It's probably best to do this from within Tetrix, should only take a few MM patches. I could write them up if you want.

@CessnaSkyhawk @theJesuit I was missing some parts from BDB in my tech tree while playing with this. Turns out there's a typo in the BDB patch file where it states "aerodynamicsSystems" instead of "aerodynamicSystems". Note the extra 's'. Since the actual node is named aerodynamicSystems, any parts configured with the typo end up missing in the game. It's an easy enough fix however.

I think what might work here - And others should correct me if this is not the great idea I think it is - But I would consider increasing the science needed for the first say 7 nodes, and reduce the requirements after that to get a bit flatter progression curve. The first node at 5 science is (almost) achieved by even just standing on the launch pad, personally I think it should require more effort. But I admit maybe that's not for everyone.

I always thought the first couple of nodes in any tech tree are way too easy to achieve, provided there's at least 2 experiments in the start node and then a whole lot more in the next one as is common. But at the same time, getting to the later nodes becomes a real chore, because how many players stick around in career long enough to land multiple missions on each body's biome to grind enough science to reach the future tech nodes?

I have a guess to this, after trying out some different type of parameters some time ago. My suspicion is that CC isn't accounting correctly for any 'amount' value associated with parts, if that makes any sense. What I tried to do myself is to apply the ResourceConsumption parameter to keep track of energy generation for example and require a certain amount for the objective to be completed. But CC simply never read the values out correctly, instantly completing the objective even when the value input was negative.

Without context nobody can help you with this. CC doesn't throw any errors like this by itself. Which contracts are involved, what are you doing when this error pops, etc. Sometimes it takes a while for technically available contracts to actually generate, the generation code has some oddities in it. Try waiting for several ingame days. Alternatively, I've found that simply browsing through the admin/science/astronaut/mission control buildings for a few minutes triggers generation of certain types of contracts too. If neither works, you're not matching the requirements or there's other things preventing the contract from generating.

When specifying requirements or objectives for a specific part from a different mod, always add a ":NEEDS[modname] to the node in question. Though beware, this also means the node won't be loaded at all if the needs isn't being met. You might need multiple nodes for all parts/functions you're trying to use this way.

@CessnaSkyhawk I am giving TETRIX a go, with BDB being my mainstay (among others, but this is the most relevant for my post). I notice that for quite a few of BDB's probe sets with multiple parts, such as OGO, OSO or Nimbus, these parts are spread out over various tech levels (by which I mean, in deeper levels of more expensive tech, not same-level but elsewhere). I would like to highly recommend keeping these parts together so players can actually build those craft in their original form once they start unlocking their parts, instead of grinding towards unlocking pieces of them. Another reason is that BDB comes with a number of contracts based on these parts, which cue from the parts' original placement as to when to become available. Now I have several contracts offered that I cannot reasonably complete until I unlock several more tech nodes further in.

Alternatively, it is possible to deactivate a requirement while in-game, through the CC debug menu. Just click on the green check icon next to the requirement after browsing to it. Be mindful however, I have found the contract can behave strangely when using this method (blinking in and out of existence), I only use it to check if it is loaded correctly, never to actually playtest. It's one of those features that's not quite functioning right.

16 GB of RAM really won't cut it if you're trying to load in the majority or all of this mod, plus others. I think my install with similar numbers and huge parts catalog will run my system to about 32GB active memory usage.

Wolffy wasn't so much asking for a new version to update functionality, rather just point out there's a number of issues that have been reported over past few years that are left unattended. That's no criticism of Nightingale either, everyone here is thankful this exists at all. It's just the state of the mod.