[KSP 1.8 - 1.12+] - Probes Before Crew [PBC] Version 2.93

[Poddster]

Now that @_Zee's back in the mod-mood, is  it possible to get this answered?

On 8/4/2019 at 11:52 AM, Poddster said:

So if I wanted to play a stock KSP + PbC, what other mods would you consider essential to get the best PbC experience? (Other than the required dependencies)

 

I.e. what mods was Zee using when playing and designing PbC?

 

Thanks!

 

[amoksepp]

On 9/6/2019 at 10:58 AM, amoksepp said:

This mod sounds great, i will start a new career play (didnt played career for ages) with RT  / ScanSat and maybe some Life support and first time without quicksave/revert.

Hey, is the science balanced to the Mobile Proccessing LAB or without it?

 

Does noone has a answer for my question?

[Jognt]

On 9/6/2019 at 11:06 AM, Poddster said:

Now that @_Zee's back in the mod-mood, is  it possible to get this answered?

Thanks!

Check the OP. Mods are a personal preference, but I would recommend at least getting DMagic’s Orbital Science, because getting science... lets just say this ain’t easy mode anymore  

(Especially when combined with upscaled planets like JNSQ)

4 hours ago, amoksepp said:

Does noone has a answer for my question?

Science is balanced to be easier to get on kerbin at the first few nodes, but Mun/minmus aren’t the 1000’s of science per visit they normally are. Overall it’s a quicker ramp-up, but you really have to work for it once you get past the 300 science nodes.

Lets just say that (with JNSQ, which is 2.7x scale) I haven’t gotten the science lab yet after quite a bit of playing (though I tinker more than I play). 

So by the time you even unlock the lab, you’ll know how much it’s worth for you   

[Wylker]

The Hitchhiker is no longer showing in the spaceExploration node - nor is it in my VAB yet. I can't seem to find any configs that move it in any mods - but this mod comes to mind. Has it been moved or removed?

[Jognt]

12 hours ago, Wylker said:

The Hitchhiker is no longer showing in the spaceExploration node - nor is it in my VAB yet. I can't seem to find any configs that move it in any mods - but this mod comes to mind. Has it been moved or removed?

Check your output.log file. It lists every modified part and every patch that modifies it. 

[hoover2701]

Yesterday I started a new career with the "Kerbin Size Real Solar System" Mod and "Probes Before Crew". I love both of them but what's bugging me is that the contracts used in the PBC-Mod refer to the planets in the stock system. So I get a Minmus mission although there is no Minmus or I get a Mun mission although it should be Moon.

Here's my question: If I change the "Zs_PBCContractsLayerx.cfgs" renaming all of the planets and moons to those corresponding with the KSRSS mod, should that work? Or do I only change the bodies' names in the mission descriptions, i.e. do I have to change the line "targetBody = Mun" to "targetBody = Moon" if that's the Kopernicus-settings name for the Mun in KSRSS?

Man, I hope someone's able to decipher my question. Sorry, no native speaker! 

[Jognt]

3 hours ago, hoover2701 said:

Yesterday I started a new career with the "Kerbin Size Real Solar System" Mod and "Probes Before Crew". I love both of them but what's bugging me is that the contracts used in the PBC-Mod refer to the planets in the stock system. So I get a Minmus mission although there is no Minmus or I get a Mun mission although it should be Moon.

Here's my question: If I change the "Zs_PBCContractsLayerx.cfgs" renaming all of the planets and moons to those corresponding with the KSRSS mod, should that work? Or do I only change the bodies' names in the mission descriptions, i.e. do I have to change the line "targetBody = Mun" to "targetBody = Moon" if that's the Kopernicus-settings name for the Mun in KSRSS?

Man, I hope someone's able to decipher my question. Sorry, no native speaker! 

Check the KSRSS files for where they rename stuff. Then copy that into a new cfg that runs in a pass after PBC loads its names. 

If KSRSS comes with its own contracts then you can also just delete the PBC contracts file, or rename it to .cfg.disabled so it won’t load. 

[hoover2701]

10 hours ago, Jognt said:

Check the KSRSS files for where they rename stuff. Then copy that into a new cfg that runs in a pass after PBC loads its names. 

If KSRSS comes with its own contracts then you can also just delete the PBC contracts file, or rename it to .cfg.disabled so it won’t load. 

Thanks. In the KSRSS-files "that rename stuff" there always is a reference to the template body, i.e. Moon = Mun, Earth=Kerbin etc. If I change the "targetBody=" parts in your configs to the changed names in KSRSS it dioesn't work (the contract doesn't show up), but if I set it to the stock name and only change the descriptive parts it seems to work, i.e. the contract shows up. I'll have to go to the Moon now though to find out if it works accordingly. Thanks again for your fast response! Probes Before Crew is a refreshing experience, keep up the good work!

Edited September 18, 2019 by hoover2701
Fail

[_Zee]

On 8/29/2019 at 7:03 AM, jamqdlaty said:

A little question/suggestion, cause something is not clear for me. There's that requirement for probe contracts: "Ensure that your vessel's name is tagged as a PROBE". Why? It already checks if the vessel crew capacity equals 0. I had to cheat completion of one mission cause I forgot to check the tag. I don't understand why is it important. Maybe this requirement can be just removed?

To answer this question, I would refer you to this post, this post, and the top half of this post. The bug being reported isn't the same as yours, but the cause and effect remain the same. It is that way because we have no choice. I put that note there as a kind reminder to users of the mod that are unaware of the limitations of contract configurator.

@amoksepp To be honest its really up to you. I recommend placing the Science slider at 70% on my OP, but that's just my personal preference. At that setting, I imagine using the lab would start to feel necessary at a certain point, depending on how many mods adding parts you have - and how deep down the tech tree I've placed those mods parts. You can make it play out however you like!

@Poddster I suppose I should post my mod list somewhere, huh? As with most of us on this site, it changes frequently, but I'll list my top go-to's: 
- DMagicOrbitalScience
- KAS/KIS
- MissingHistory
- 90% of the NearFuture Mods
- SCANsat
- RemoteTech (when I'm in the mood for it, stock actually does a decent job now)
- StationPartsExpacRedux
- Strategia
- TACLS
- UniversalStorage2
- And about 2 dozen other various utility mods/etc

This list grows as I get more and more recommendations to add to the support list. The voting system has actually done a really good job filtering all the top mods at the moment for me. 

@Wylker I don't remember whether or not I moved the hitchhiker, my gut is saying no.

@hoover2701 Planet Packs are not yet supported by PBC or PBC Contracts. That's actually one of the items on the voting list, go vote if you haven't yet. As for making your own quick patch, you could certainly redirect all the reference keys to the planet pack planets, but you'd need to spend a fair amount of time testing and/or mathing to get the contract rewards to match the difficulty and science payouts appropriately. In short, it wouldn't be balanced. 

My move is in about 2 weeks, super stoked! 

 

Edited September 25, 2019 by _Zee

[facmanpob]

Just wanted to say what a great mod this is.   It has really reordered my thinking about how to go about the early career. I also wanted to share a little album highlighting this, and a post I made in a KSP facebook group I'm part of...

Using Probes before Crew means that access to 3-Kerbal capsules comes a lot later than normal in a career. But for my first manned journey out to the Mun I wanted a Pilot for flying, an Engineer for fixing things that might break and a Scientist for resetting various experiments. So I had to get creative!

Spoiler

imgur 1st Munar landing with PBC album

[Wyzard]

Small bug report: PBC changes xmitDataScalar for some of the stock science experiment parts, but not for the equivalent Universal Storage parts.  Here's a section that should be added to ZsUS2Patch.cfg:

//// ***************** Science

@PART[USAccelGravWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[USSimpleScience]:HAS[#experimentID[gravityScan]]
	{
		// Same as stock sensorGravimeter
		@xmitDataScalar = 1
	}

	@MODULE[USSimpleScience]:HAS[#experimentID[seismicScan]]
	{
		// Same as stock sensorAccelerometer
		@xmitDataScalar = 1
	}
}

@PART[USFluidSpectroWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[ModuleScienceExperiment]
	{
		// Same as stock sensorAtmosphere
		@xmitDataScalar = 1
	}
}

@PART[USGooBayWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[USAdvancedScience]
	{
		// Same as stock GooExperiment
		@xmitDataScalar = 0.3
	}
}

@PART[USMatBayWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[USAdvancedScience]
	{
		// Same as stock science_module
		@xmitDataScalar = 0.3
	}
}

@PART[USThermoBaroWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[USSimpleScience]:HAS[#experimentID[temperatureScan]]
	{
		// Same as stock sensorThermometer
		@xmitDataScalar = 1
	}

	@MODULE[USSimpleScience]:HAS[#experimentID[barometerScan]]
	{
		// Same as stock sensorBarometer
		@xmitDataScalar = 1
	}
}

Edited October 20, 2019 by Wyzard
Fixed a typo in the thermometer patch (was patching barometer again instead)

[Jognt]

4 hours ago, Wyzard said:

Small bug report: PBC changes xmitDataScalar for some of the stock science experiment parts, but not for the equivalent Universal Storage parts.  Here's a section that should be added to ZsUS2Patch.cfg:

//// ***************** Science

@PART[USAccelGravWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[USSimpleScience]:HAS[#experimentID[gravityScan]]
	{
		// Same as stock sensorGravimeter
		@xmitDataScalar = 1
	}

	@MODULE[USSimpleScience]:HAS[#experimentID[seismicScan]]
	{
		// Same as stock sensorAccelerometer
		@xmitDataScalar = 1
	}
}

@PART[USFluidSpectroWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[ModuleScienceExperiment]
	{
		// Same as stock sensorAtmosphere
		@xmitDataScalar = 1
	}
}

@PART[USGooBayWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[USAdvancedScience]
	{
		// Same as stock GooExperiment
		@xmitDataScalar = 0.3
	}
}

@PART[USMatBayWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[USAdvancedScience]
	{
		// Same as stock science_module
		@xmitDataScalar = 0.3
	}
}

@PART[USThermoBaroWedge]:AFTER[UniversalStorage2]:NEEDS[CommunityTechTree]
{
	@MODULE[USSimpleScience]:HAS[#experimentID[barometerScan]]
	{
		// Same as stock sensorThermometer
		@xmitDataScalar = 1
	}

	@MODULE[USSimpleScience]:HAS[#experimentID[barometerScan]]
	{
		// Same as stock sensorBarometer
		@xmitDataScalar = 1
	}
}

It’s a better idea to blanket alter the xmit scalar. Less typing, less maintenance, more compatibility. 

This boils down to the same thing: 

@PART[*]:HAS[@MODULE:HAS[~experimentID[ROC*]&~experimentID[surfaceSample]&#xmitDataScalar[<1]&#rerunnable[True]]]{
  @MODULE:HAS[~experimentID[ROC*]&~experimentID[surfaceSample]&#xmitDataScalar[<1]&#rerunnable[True]]{
    @xmitDataScalar = 1.0
  }
}

 

[Wyzard]

On 10/17/2019 at 4:58 AM, Jognt said:

It’s a better idea to blanket alter the xmit scalar. Less typing, less maintenance, more compatibility.

Agreed, but that's less "bugfix patch" and more "refactoring the mod", so I stuck to the way it's done currently.

BTW, Zs_Science.cfg has a separate section for each experiment, updating the EXPERIMENT_DEFINITION (for baseValue and scienceCap) as well as the stock part which runs that experiment (for xmitDataScalar).  From a refactoring standpoint, I'd lean toward updating each of those sections to replace the single-part xmitDataScalar patch with one that patches all parts matching the specific experimentID.  (That way there's a clear, visible association between each experimentID and the xmitDataScalar it should have, since they're not all 1.0).

[Jognt]

1 hour ago, Wyzard said:

Agreed, but that's less "bugfix patch" and more "refactoring the mod", so I stuck to the way it's done currently.

BTW, Zs_Science.cfg has a separate section for each experiment, updating the EXPERIMENT_DEFINITION (for baseValue and scienceCap) as well as the stock part which runs that experiment (for xmitDataScalar).  From a refactoring standpoint, I'd lean toward updating each of those sections to replace the single-part xmitDataScalar patch with one that patches all parts matching the specific experimentID.  (That way there's a clear, visible association between each experimentID and the xmitDataScalar it should have, since they're not all 1.0).

Yeah my previous patch targeted specific experimentIDs, but because you can’t do OR in HAS blocks it was.. clunky. 
further investigation revealed that all those experimentIDs were unique in their rerunnable value too, so I targeted that. 
 

I’ve posted that old patch a while back in this thread but I’m quite sure Zee is otherwise occupied lately so I’m not expecting many tweaks in the near future. 

[dochockin]

I've just come back to KSP after a couple of years hiatus.  I'm wanting to play a Career game with Probes before Crews.  I fired it all up via Steam and the Probes/Crew mod was working, however, something else was messed up since the ground was lost under water once I got a bit of altitude.  I realized that I was using KSP 1.8 while many of the mods I had installed weren't updated yet, so I used Steam's Beta option to revert back to 1.7.3.

The water level bug went away but now Probes/Crew isn't working.  Any thoughts as to what's going on with this?

Thanks!

[severedsolo]

4 hours ago, dochockin said:

The water level bug went away but now Probes/Crew isn't working.  Any thoughts as to what's going on with this?

Can't say for definite, but:

I know it's a pain, but when you use that option to roll back ksp versions it's always a good idea to completely uninstall, delete the Kerbal Space Program folder completely and reinstall ksp from scratch with the beta enabled.

Steam won't delete files it didn't create, so it may be you have some old files that are causing issues.

 

[MysticDaedra]

I'm still on 1.7.3. I noticed that the PBC contract pack isn't showing up in Contract Configurator... Or in my mission control. 

[_Zee]

Hello Kerbonauts. Just wanted to pop in and let everyone know that I just finished working on updating my Civ6 mods yesterday, and now PBC is next! I'm going to work on getting everything updated for 1.8.1 first before working on adding new mod support, just to get a bug-free version of the mod out ASAP. I really appreciate everyone's patience, I know this update is sooooooo overdue but it's just a few days away now!

[_Zee]

So here's whats on the docket for this update, and some overdue replies to messages/questions in the thread.

@Wyzard and @SpaceMoose
I can understand the realism point of view on what you're talking about, but I think you might be over-thinking these "return" contracts.
Firstly, I wish it were possible to just re-tag debris because if we could I'd just tell you to do that. In the scenario that you are trying to just drop a science container with a parachute into the atmosphere, this is a case where I would say using Alt-F12 to manually complete the contract is completely acceptable. The spirit of the contract has been completed and it's just hardcoding that prevents us from automating this, so cheat the contract through with a clear conscience. (or just toss a tiny probe core in between the science container and parachute)
Secondly, returning from any planet to progress the contract unlocks is ONLY required for the Kerbin Moons. Look at the contract pack map in the OP and you'll see that for Duna and Eve, returning is OPTIONAL. As in, you can do it for the extra funds and rep if you want, but it's never required to unlock the other contracts. The same goes for all the "Class 4" contracts and their target bodies, it's just an option for the added challenge and reward. 

@CoriW
I saw you started working on building a patch for PBC and JNSQ, so sorry I couldn't reply sooner. If you're still around, I fully support the effort, let me know if I can assist somehow.

@ A Few Different People - I saw a few reports for antenna unlocks being placed just a tad too deep. I will review their placements and probably pull things in a little bit. Someone did mention earlier though, and I forget this all the time too, that antenna's CAN be stacked now. I know that only goes so far, but sometimes it's enough to make the mission work.

I also saw the US2 xmit issue brought up again, this will be patched in the coming release.

And finally, of course, support for all the new Breaking Ground 1.8/.1 parts.

I'll be hard at work all weekend. If there are any fresh issues or concerns you've run into, now is the time to bring them up!

[Jognt]

4 minutes ago, _Zee said:

I also saw the US2 xmit issue brought up again, this will be patched in the coming release.

Just in case you missed it, I've been using this patch for a while now. It targets the same experiments you do, but I dug into them to find out what properties make them uniquely targetable with a single patch.

@PART[*]:HAS[@MODULE:HAS[~experimentID[ROC*],~experimentID[surfaceSample],#rerunnable[?rue],#xmitDataScalar[<1]]]:FOR[JogntsTweaks]
{
	@MODULE:HAS[~experimentID[ROC*],~experimentID[surfaceSample],#rerunnable[True],#xmitDataScalar[<1]]
	{
	//	%xmitCheck = #$xmitDataScalar$ | $experimentID$ | $../name$
		@xmitDataScalar = 1
	}
}

Edit: While we're at it, I also added a change when using ReStock Plus: It moves the miniature RCS thrusters one node earlier so you've atleast got something to work with.

// Move the ReStock+ miniature RCS thrusters to Flight Control instead of Advanced Flight Control.
@PART[restock-rcs*mini*]:NEEDS[ReStockPlus]:FOR[JogntsTweaks]
{
	@TechRequired = flightControl
}

 

Edited November 8, 2019 by Jognt

[_Zee]

That's.... quite the conditional you have there Jognt...  A blanket statement to cover all parts that produce the vanilla experiments could be useful, but I'll need some help making sense of the code.

Firstly, whats the [ROC*] tag? Second, you have the surfaceSample listed here, but that experiment should continue transmitting at the vanilla default (0.35 if memory serves?) as I never intended to change it for that experiment. But, I also wonder how much this is really needed? Aside from the US2 parts I don't know of very many mods that reproduce the vanilla experiments. It may end up being quicker/easier to just set the xmit values for the US2 parts like I did for the stock parts. But I'm still curious to know how this conditional works, for science.

[Spectre112]

Hej guys.

I'm an avid fan of PBC, and just restarted my career playthrought now with 1.8.

But having started on making a few planes to tackle some of the contracts revolving around making certain experiments while flying under a certain altitude limit made me wonder:

Why are there not a mod which puts propellers before jet engines in the tech tree?

And seeing what PBC does, I figured this would be a good place to put up that suggestion.

Is that possibly a thing that could be added to this mod? or maybe a small mod that could go hand in hand with PBC.

With kind regards Spectre

[Jognt]

15 hours ago, _Zee said:

That's.... quite the conditional you have there Jognt...  A blanket statement to cover all parts that produce the vanilla experiments could be useful, but I'll need some help making sense of the code.

Firstly, whats the [ROC*] tag? Second, you have the surfaceSample listed here, but that experiment should continue transmitting at the vanilla default (0.35 if memory serves?) as I never intended to change it for that experiment. But, I also wonder how much this is really needed? Aside from the US2 parts I don't know of very many mods that reproduce the vanilla experiments. It may end up being quicker/easier to just set the xmit values for the US2 parts like I did for the stock parts. But I'm still curious to know how this conditional works, for science.

@PART[*]:HAS[@MODULE:HAS[~experimentID[ROC*],~experimentID[surfaceSample],#rerunnable[?rue],#xmitDataScalar[<1]]]:FOR[meOfcourse]

I'll assume the @PART and :HAS bit are self explanatory. Here's what each bit does:

~experimentID[ROC*]: This will exclude the new Breaking Ground experiments which are rerunnable, but should be returned for full science because of gameplay.
~experimentID[surfaceSample]: This will exclude surface samples, for the same reason as the above.
#rerunnable[?rue]: What do all the experiments you set xmit to 1 for have in common? Well, they were all rerunnable! The ? is to get both True and true values to work.
#xmitDataScalar[<1]: This one is just to be tidy, don't touch stuff that's already at the value we want.

Here's the old version I had:

// Old version
@PART[*]:HAS[@MODULE:HAS[#experimentID[*]&#xmitDataScalar[<1]]]:LAST[JogntsTweaks]
{
	@MODULE:HAS[#experimentID[temperatureScan]]
	{
		%xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$
		@xmitDataScalar = 1
	}
	@MODULE:HAS[#experimentID[barometerScan]]
	{
		%xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$
		@xmitDataScalar = 1
	}
	@MODULE:HAS[#experimentID[seismicScan]]
	{
		%xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$
		@xmitDataScalar = 1
	}
	@MODULE:HAS[#experimentID[gravityScan]]
	{
		%xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$
		@xmitDataScalar = 1
	}
	@MODULE:HAS[#experimentID[atmosphereAnalysis]]
	{
		%xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$
		@xmitDataScalar = 1
	}
	@MODULE:HAS[#experimentID[infraredTelescope]]
	{
		%xmitCheck2 = #$xmitDataScalar$ | $experimentID$ | $../name$ | $rerunnable$
		@xmitDataScalar = 1
	}
}

This worked perfectly fine, but it didn't feel very elegant to do it like this since I'm repeating the @xmitDataScalar bit a lot. So I decided to look for something that these all have in common that other experiments don't have. That something was rerunnable = true!

Thus, the conditional I posted earlier was born.

This way there is very little to no maintenance needed and it'll work with whatever science MODULE people can come up with that still use the existing experimentID key.

16 hours ago, _Zee said:

But, I also wonder how much this is really needed? Aside from the US2 parts I don't know of very many mods that reproduce the vanilla experiments. It may end up being quicker/easier to just set the xmit values for the US2 parts like I did for the stock parts. But I'm still curious to know how this conditional works, for science.

Is it really needed? Nah.

Does it do the same thing as manually setting the xmit value for US2 parts? Yeah.

Is manually setting it quicker/easier? Hell no!
Sure, figuring out how to do it cost me more time than manually setting it, but now that I've figured it out I don't have to manually set it anymore, ever.

If you're curious about the experiments it touches, I've left my debug bit in there, it's the commented xmitCheck thing. If you uncomment that and run KSP once then you can just do a search in Notepad++ (or your program of choice) for xmitCheck and it'll list the old xmit value, the experimentID for that that experiment, and whether it was rerunnable. (rerunnable was there to make sure I wrote the patch correctly back then)

Edited November 9, 2019 by Jognt

[_Zee]

Very nice, thank you for all of that Jognt. I had forgotten that "~" signifies exclusion and later figured out the ROC tag is for the new expansion after rummaging through the new files for a bit. Very well written line of code. Like I said before I'll probably just stick with the direct approach for these xmit values, but this could be very useful for heavy lifting in the future. Thanks for taking the time to explain it! 

@Spectre112
Welcome to the forums, glad you're enjoying the mod. To answer your question, PBC has not yet been updated for 1.8 or Breaking Ground, so the new propeller parts have not been sorted yet. They will be in the upcoming update.

[Jognt]

1 hour ago, _Zee said:

This could be very useful for heavy lifting in the future. Thanks for taking the time to explain it! 

You’re welcome. And yeah, this sort of patching is nice in that it keeps the value your modifying centralized. So if you were to want to tweak it you wouldn’t need to alter it in n^x locations. 

And it can be helpful in that the xmitCheck thing on its own can let you know whether you’ve missed a part somewhere if you run it after your usual stuff. The xmitCheck key won’t exist if everything’s in order.  

edit: Off of the top of my head I don’t know whether your patching took dmagic’s DMModuleScienceAnimateGeneric into account besides his DMScienceModuleAnimate (?), but since ReStock (afaict) adds nifty animation stuff when it’s present (replacing the stock module with it) it may be something to keep in mind when you’re getting into PBC stuff again.  

ps. Mad respect for the amount of manual labor that went into making your cfgs with all those manual @PARTs!

Edited November 10, 2019 by Jognt