[1.12.x] BetterCrewAssignment v1.4.1: Smarter by default. Remembers your choices. No UI.

[NewtSoup]

Hi Snark, I can't get this to work.  Been working out the kinks in a tanker I was building and hitting save every time I launch.  Every time I revert and hit launch again it forgets my crew assignment and the crew compartment is empty once again.  Not even Jeb has managed to sneak in. Which I guess is a small bonus.

It's just made a liar of me.  Tested again and it works.. yet for several hours I've been wondering why it wasn't working.

Edited October 8, 2018 by NewtSoup

[Snark]

Hmmm.  It may be time for another pass through the BetterCrewAssignment code.  It's pretty old, and it's not ideal the way it's set up currently-- for example, the way it handles different Kerbal professions is kind of out of date, since KSP changed its "profession" model several versions ago and I'm still working with the old model, which is kinda clunky.

Apologies for any inconvenience you experienced.  Overhauling the code here is definitely on my "to do" list, it's just that it'll be a pretty big job (it's a significant architectural change, not just a simple cosmetic tune-up), so it needs to wait until I have the bandwidth to address it properly, and I'm fairly busy IRL these days so it keeps getting procrastinated.

[cakepie]

Hey @Snark, I've been doing a bit of digging into engineer repair skill requirements and learned some things that indicate that your config needs some fixing.

 

Specifically this part:

@PART[*]:HAS[@MODULE[ModuleWheelBase]:HAS[#wheelType[LEG]]] {
	MODULE {
		name = ModuleCrewRequirement
		profession = Engineer
		minimumLevel = 2
		importance = 0
	}
}
@PART[*]:HAS[@MODULE[ModuleWheelBase]:HAS[#wheelType[MOTORIZED]]] {
	MODULE {
		name = ModuleCrewRequirement
		profession = Engineer
		minimumLevel = 3
		importance = 0
	}
}

I suppose this is based on info in the wiki re: skill level required to repair legs and wheels. However, that information appears to be super outdated -- it applies to long long ago when there used to be ModuleWheel, ModuleLandingLeg, ModuleLandingGear. They were all changed to use the new wheel system in I think it was KSP 1.1, and ever since then it looks like both legs and wheels damage and repair functionality are in ModuleWheelDamage and requires engineer level 3.

It seems quite hard to "organically" cause leg damage so I wrote a small piece of code to let me trigger it manually for testing purposes

//------------------
// Plugin
//------------------

using ModuleWheels;

namespace BreakALeg
{
    public class BreakALeg : PartModule
    {
        [KSPEvent(guiActive = true, guiName = "Break Leg/Wheel")]
        public void BreakLeg()
        {
            ModuleWheelDamage mwd = part.Modules.GetModule<ModuleWheelDamage>();
            if (mwd == null) return;
            mwd.DamageWheel();
        }
    }
}

//------------------
// Module Manager
//------------------

@PART[*]:HAS[@MODULE[ModuleWheelDamage]]{
MODULE{
name = BreakALeg
}
}

And KSP complains if engineer is not at least Level 3 when trying to repair a broken leg.

 

The BetterCrewAssignment MM patch should be changed to

@PART[*]:HAS[@MODULE[ModuleWheelDamage]] {
	MODULE {
		name = ModuleCrewRequirement
		profession = Engineer
		minimumLevel = 3
		importance = 0
	}
}

This will take care of both wheels and legs -- and only gets added when their configs are setup so they can actually be damaged/repaired.
If you want to be extra specific with the targeting you can add a test for cases where ModuleWheelDamage has explicit field isRepairable = false and exclude those parts. (it defaults to true if omitted)

hth

Edited May 11, 2019 by cakepie
add info re: isRepairable

[Snark]

5 hours ago, cakepie said:

I suppose this is based on info in the wiki re: skill level required to repair legs and wheels. However, that information appears to be super outdated -- it applies to long long ago when there used to be ModuleWheel, ModuleLandingLeg, ModuleLandingGear. They were all changed to use the new wheel system in I think it was KSP 1.1, and ever since then it looks like both legs and wheels damage and repair functionality are in ModuleWheelDamage and requires engineer level 3.

Ah, thanks for the heads up! 

There's also the larger issue that BetterCrewAssignment still uses the old-fashioned "class-based" way of dealing with professions, rather than the newer "skill-based" one, which I should also address... just that fixing that would involve a much deeper re-factor.  This, on the other hand, is a pretty minor config tweak, so should be a lot easier to update.

[Snark]

Hi gang,

Just a note that I've released BetterCrewAssignment v1.4.  No new features, just a compatibility update for KSP 1.8.

[gnorc]

Hi, i'm sorry, I'm not sure how this mod works. I extracted the entire base BetterCewAssignments-1.4 into gamedata, which itself has a gamedata folder, and I got a different load screen so I figured I installed it correctly. But after saving a craft with Bob as the crew, I exit the hangar and go to the runway and it's crewed by Jeb. If I replace it with Bob and return, it's still Jeb. As far as I can tell the mod isn't working at all. Any tips for getting it running? The lack of a default crew option seems like a huge oversight for this game, which among other things make me believe the devs don't actually play their game that much.

[Geonovast]

@gnorc Welcome to the forum!

You're running into a very common issue.  You don't want to put the mod's GameData folder into yours.  You want to put the contents of the extracted GameData folder into yours.  This will put the BetterCrewAssignment folder, and the ModuleManager dll file alongside your Squad folder inside your GameData folder.

[4x4cheesecake]

The mod throws an exception, every time I load a vessel in the editor which uses a different command pod then the previously loaded vessel or even when I exchange the pod in the editor.

Doesn't seem to affect the functionality though, I want to report it anyway

KSP 1.8.1 (tested on a fresh install with only MM and BetterCrewAssignment installed)

Steps to replicate:

1) Place any command pod in the VAB
2) Delete the pod
3) Place any different command pod

Thrown exception:

[BetterCrewAssignment] (Exception) Mismatch at index 0: mk1-3pod versus mk1pod.v2:   at BetterCrewAssignment.Crewable.List (ShipConstruct construct) [0x00147] in <fcaadc6adbe94684b181672bfcd58aa1>:0 
  at BetterCrewAssignment.CrewableList..ctor (ShipConstruct construct) [0x00006] in <fcaadc6adbe94684b181672bfcd58aa1>:0 
  at BetterCrewAssignment.AssignmentLogic.AssignKerbals (ShipConstruct construct) [0x00000] in <fcaadc6adbe94684b181672bfcd58aa1>:0 
  at BetterCrewAssignment.EditorBehaviour.OnShipModified (ShipConstruct construct) [0x00027] in <fcaadc6adbe94684b181672bfcd58aa1>:0 

full log: https://www.dropbox.com/s/9ztlrx5h4nmseic/Player(BCA_exception).log?dl=0

[Snark]

On 3/28/2020 at 6:29 PM, 4x4cheesecake said:

The mod throws an exception, every time I load a vessel in the editor which uses a different command pod then the previously loaded vessel or even when I exchange the pod in the editor.

Doesn't seem to affect the functionality though, I want to report it anyway

Thanks!

I've gotten that myself, from time to time.  It's an annoyance to me (even if it doesn't seem to hurt anything, it offends the OCD perfectionist in me)... but it's never quite risen to the threshold of getting me to plow into it.

BetterCrewAssignment is probably the most "snarly" codebase of my mods-- it has quite a lot of code in it, and it was one of the earlier mods I wrote before I really "hit my stride" with how to arrange things elegantly in KSP, so the code is creakier than I'd like and debugging/maintaining it is a chore.  (Its internal logic and design are quite complicated.)

Another thing that's been dis-incentivizing me from going in is the knowledge that it's actually doing it wrong from a fundamental design standpoint-- KSP "professions" (like engineer, pilot, scientist) used to work differently than they do now.  Many KSP versions ago they significantly reorganized how these work, in a much more elegant "traits-based" way, but BetterCrewAssignment was written using the old assumptions and isn't currently well-suited to the KSP design.  It still works, but there's an impedance mismatch with the actual design intent of modern KSP.  I know this, and I'm basically a poster child for "letting the perfect be the enemy of the good"-- I find myself reluctant to touch the code without fixing that problem, but fixing that problem would be a seriously labor-intensive overhaul of the code base, and the chore is so intimidatingly big that I just don't even get started.

Anyway, yes, I'm aware.  Fixing BCA up is one of those things on my mental to-do list that I keep putting off.  I hope I'll get to it sometime, but not sure when that might be, since it's a pretty big job.

[BlackjackTonka]

Thank you! Just friggin awesome!

[PocketBrotector]

@Snark , I'm getting some exceptions from BCA in KSP 1.11, accompanied by heavy UI lag in the VAB whenever a crewable part is added.

• KSP.log
• Video of issue

My crew assignment configuration:

//Default all crewable parts to empty by overwriting BetterCrewAssignment’s configurations
@PART[*]:HAS[@MODULE[ModuleCrewAssignment]]:FINAL {
	@MODULE[ModuleCrewAssignment] {
		@defaultAssignment = Empty
	}
}

Mod list:

Spoiler

000_ClickThroughBlocker
000_FilterExtensions
000_FilterExtensions_Configs
000_Toolbar
001_ToolbarControl
B9_Aerospace_ProceduralWings
B9PartSwitch
BetterCrewAssignment
BonVoyage
CommNetAntennasInfo
CommunityCategoryKit
CommunityResourcePack
CommunityTechTree
CryoEngines
CryoEnginesNFAero
CryoEnginesRestock
CryoTanks
CustomBarnKit
CustomPreLaunchChecks
DatedQuickSaves
DeployableEngines
DistantObject
DynamicBatteryStorage
EnvironmentalVisualEnhancements
GEP
GEP_JNSQ
HeatControl
HideEmptyTechTreeNodes
JNSQ
KAS
KEI
KerbalAtomics
KerbalAtomicsLH2NTRModSupport
KerbalEngineer
KerbalHealth
KerbalJointReinforcement
KerbalKonstructs
KerbalRenamer
KerbalReusabilityExpansion
KerboKatz
KIS
Kopernicus
kOS
KSP-AVC
KSPRescuePodFix
LB_KSP_Configs
MagiCore
MarkIVSystem
MechJeb2
ModularFlightIntegrator
ModuleManager
NavyFish
NearFutureAeronautics
NearFutureConstruction
NearFutureElectrical
NearFutureExploration
NearFutureLaunchVehicles
NearFutureProps
NearFuturePropulsion
NearFutureSolar
NearFutureSpacecraft
OSSNTR
PartOverhaulIntegration
PlanetShine
QuickMods
RationalResources
RationalResourcesParts
REPOSoftTech
Restock
RestockPlus
SCANsat
Scatterer
SituationModuleInfo
SnacksSupport
SoundtrackEditorForked
SpaceDust
SpaceDustBunnies
SpaceTuxLibrary
StageRecovery
StationPartsExpansionMetal
StationPartsExpansionRedux
Trajectories
TriggerTech
TriggerTech
Waterfall
WaterfallRestock
WildBlueIndustries
ZeroMiniAVC
 

Please let me know if there's anything else useful that I can add to my report. Thanks!

[Snark]

9 hours ago, PocketBrotector said:

I'm getting some exceptions from BCA in KSP 1.11, accompanied by heavy UI lag in the VAB whenever a crewable part is added.

Thank you for posting the report!    Very well and coherently done, especially the inclusion of the video and the log file.  Those are invaluable.

So, based on some cursory examination, I think this behavior is at least partly BCA (I've observed somewhat similar behavior myself), but I wouldn't be surprised if other mods are getting farbled as well.  In particular, you may want to look at whatever is spamming "[SystemHeat][SystemHeatOverlay]" into the log files in the same areas where BCA is having issues.

Here's what I believe is going on:

• BCA works by trapping "ship changed" events in the editor, such that every time the ship "changes" -- for example, if you've added or removed a part-- then it does various calculations to decide what to do.  And also writes stuff to the log.
• I think KSP 1.11 changed something about the way that the game fires "ship changed" events, such that it fires a lot more of those events than it used to.  For example, if you drag a slider up and down in a part's right-click menu, that spams tons of "ship changed" events.
• Since BCA does fairly heavy-duty processing on every "ship changed" event... the fact that those events are now getting heavily spammed is causing BCA to gum up the works.
• There's a pretty simple fix that I can do to BCA that should filter out all that event spam.
• However, any other mod that also triggers on "ship changed" events in the editor, is likely to have similar problems to what BCA is hitting.

Thank you for posting your log file-- that's very helpful. Holy mackerel you've got a lot of mods.  There's a lot of stuff in that log. 

One thing I noticed was that in the area where BCA is spamming-- i.e. the place I need to fix-- it looks like some other mod is spamming even more.  I see tons of stuff like this:

[LOG 23:48:39.699] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay
[LOG 23:48:39.716] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay
[LOG 23:48:39.732] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay
[LOG 23:48:39.749] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay
[LOG 23:48:39.766] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay
[LOG 23:48:39.785] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay
[LOG 23:48:39.802] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay
[LOG 23:48:39.817] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay
[LOG 23:48:39.834] [SystemHeat][SystemHeatOverlay]: No loops, destroying overlay

I don't know anything about whatever is logging all those "SystemHeat" messages... but it's extremely spammy, looks even spammier than BCA.  It may be that it's being bitten by the same thing that's biting BCA, perhaps even worse.

So, TL;DR:  yes, this is a BCA problem, and I already have a fix in hand, I just need the time to release a fix.  The fix clears up problems for me just fine-- but I don't have that "SystemHeat" thing going on.

But even with that fix, I wouldn't be surprised if you end up still having a problem due to the SystemHeat thing, so you might need to check whether whatever-it-is that's logging that has some sort of KSP 1.11 compatibility fix to deal with the event spam.

[PocketBrotector]

5 minutes ago, Snark said:

But even with that fix, I wouldn't be surprised if you end up still having a problem due to the SystemHeat thing, so you might need to check whether whatever-it-is that's logging that has some sort of KSP 1.11 compatibility fix to deal with the event spam.

Yessir. The author of System Heat actually just pushed an update a few hours ago to address all that log spam. It certainly made it challenging to track anything when those lines were being logged dozens of times per second.

8 minutes ago, Snark said:

Holy mackerel you've got a lot of mods.  There's a lot of stuff in that log. 

It's the result of gradual accumulation... I actually try to be pretty discriminating in what I install, believe it or not. Nearly all of my part mods, for example, are from the same author. But everything has dependencies, and it does add up when all taken together.

[Snark]

Hi gang,

I'm pleased to announce the release of BetterCrewAssignment 1.4.1, with an important bugfix for KSP 1.11 compatibility.  Thanks to @PocketBrotector for an excellent bug report with plenty of useful context!  (see above posts)

This also updates to the latest version of ModuleManager, 4.1.4.

Other than that, no new features, just the KSP 1.11 compatibility fix.

[Krazy1]

Hi @Snark I got an error for BCA 1.4.1 on KSP1.11. It happened the first time I opened the crew tab in the VAB. The log has this (first occurrence):

[LOG 09:57:17.341] [BetterCrewAssignment] Entering crew screen, persisting kerbal assignments.
[ERR 09:57:17.342] [BetterCrewAssignment] (Exception) Mismatched lists: 4 crewable parts (out of 71 total), 0 part manifests:   at BetterCrewAssignment.Crewable.List (ShipConstruct construct) [0x000c7] in <2246ef1671564b339ac4bca8276f97ce>:0 
  at BetterCrewAssignment.CrewableList..ctor (ShipConstruct construct) [0x00006] in <2246ef1671564b339ac4bca8276f97ce>:0 
  at BetterCrewAssignment.AssignmentLogic.PersistKerbalAssignments (ShipConstruct construct) [0x00000] in <2246ef1671564b339ac4bca8276f97ce>:0 
  at BetterCrewAssignment.EditorBehaviour.OnEnterCrewPanel (ShipConstruct construct) [0x00010] in <2246ef1671564b339ac4bca8276f97ce>:0 

The 4 "crewable parts" were all MK1 crew cabins.

KSP log

 

[Snark]

37 minutes ago, Krazy1 said:

I got an error for BCA 1.4.1 on KSP1.11. It happened the first time I opened the crew tab in the VAB.

Thanks for the report!

Yes, I've seen that on occasion.  AFAICT, it's been an intermittent error that's been around for a long time.  I've never been able to get it to reproduce consistently enough to nail down exactly what causes it.  I haven't noticed it causing significant problems.

If you have a specific, 100% reproducible sequence of actions that could cause that to happen every time, then that would be useful in tracking down what's going on.  Otherwise I'll just have to let it lie, pending more data.

[Dominiquini]

The screen (part editor window) is flickering when I switch to crew selection mode!

https://imgur.com/a/aJDEBiw

https://gifyu.com/image/1SMk 

https://gifyu.com/image/1SMv

Log file: https://pastebin.com/U6nu3Zg9

Edited June 17, 2021 by Dominiquini

[Dominiquini]

On 6/17/2021 at 12:37 AM, Dominiquini said:

The screen (part editor window) is flickering when I switch to crew selection mode!

https://imgur.com/a/aJDEBiw

https://gifyu.com/image/1SMk 

https://gifyu.com/image/1SMv

Log file: https://pastebin.com/U6nu3Zg9

I see that the mod was updated to KSP 1.12 on CKAN and I tested it again (on KSP 1.12.1), but the problem remains!

Thanks.

[Neebel]

On 7/3/2021 at 11:01 PM, Dominiquini said:

I see that the mod was updated to KSP 1.12 on CKAN and I tested it again (on KSP 1.12.1), but the problem remains!

Thanks.

Just here to confirm I have the same issue, and it stops flickering when I change the crew assignment. 

[Snark]

On 6/16/2021 at 11:37 PM, Dominiquini said:

The screen (part editor window) is flickering when I switch to crew selection mode!

Yes, I'm aware of the issue-- I can reproduce it, too.  It's on my "to do" list to address when I have time-- it's just that I've been pretty busy lately, and there have been other things higher in the priority queue. 

[The-Grim-Sleeper]

I'm using this mod with Contract pack: Tourism Plus in KSP 1.12.2, but I am experiencing some crew-ing issues: assigned tourists keep getting bumped in favor of Lvl1 engineers and random tourists. (Yeah my 1-use $8k and seven bottlecaps craft lands with parachutes)

I take it that this is something that can be resolved with the module manager file, line 107, importance of engineers for parachute modules. But I am a not sure how this field works. Does a higher value for importance mean that it gets a higher priority? Are negative values allowed?

Is there a way to set the 'profession = tourist' importance to make sure planned tourism flights get their assigned passenger load-out, even at the cost of 'vital personnel'?

[Snark]

37 minutes ago, The-Grim-Sleeper said:

Is there a way to set the 'profession = tourist' importance to make sure planned tourism flights get their assigned passenger load-out, even at the cost of 'vital personnel'?

Well, in general, the way BetterCrewAssignment works is:

• If you've previously manually assigned a specific kerbal (e.g. "Val") to a slot for that ship, try to put that kerbal in the slot, if they're available.
  • And if  they're not available, try to assign a kerbal of the same profession as the one you assigned.  "Val's out on a mission, so you get Jeb, since he's a pilot too."  Or, "The tourist you previously assigned isn't here, so you get this other tourist."
• If you've never manually assigned a specific kerbal to that slot in this ship, then it uses part-based rules (from the ModuleManager config) to decide who gets priority.

I believe it would be possible, for example, to put ModuleManager config in place for a particular part (say, crew cabins) if you were so inclined, so that the game would try to fill that part with tourists when available.

However... regarding this comment,

37 minutes ago, The-Grim-Sleeper said:

random tourists

...that's kinda problematic.  Because BetterCrewAssignment has no idea what your intended purpose for a given ship might be.  Suppose you've got some tourists that you intend to send on one mission for contract A, and you have some other tourists that you intend to send on a different mission for contract B.

And then you build a ship in the VAB, which has a part on it that (let's say) you've used ModuleManager config to prioritize tourists for.

Well... BetterCrewAssignment has no way of inferring which contract you intend to satisfy with that ship.  Are you planning to send that ship on a mission for contract A, or contract B?  It doesn't know-- so it therefore has no way of knowing which of the tourist kerbals it should assign there.

Now, that said:  let's say that you intend it for contract A, so you specifically manually assign the contract-A tourists to it, and save the ship after doing that assignment, and then you launch.  And let's say you accidentally mess up the launch and then revert to VAB and launch the same ship again.  Well, in that case, your saved preferences should stick with the craft file, and it should remember that you wanted this tourist Dinkledorf in that Hitchhiker seat, so it should put Dinkledorf there again when you launch.

Beyond that, though... I'm not really sure I see what more it could do?

[The-Grim-Sleeper]

34 minutes ago, Snark said:

Now, that said:  let's say that you intend it for contract A, so you specifically manually assign the contract-A tourists to it, and save the ship after doing that assignment, and then you launch.  And let's say you accidentally mess up the launch and then revert to VAB and launch the same ship again.  Well, in that case, your saved preferences should stick with the craft file, and it should remember that you wanted this tourist Dinkledorf in that Hitchhiker seat, so it should put Dinkledorf there again when you launch.

I am having a malfunction with This specific scenario. For reference, I've turned off engineers for parachutes requirements (I'd like to leave that on if possible, but this is for troubleshooting)

I have a craft with 3 seats (Mk1 command pod, Mk1 Crew Cabin). Assigned crew: Valentina (pilot), Clauke (tourist) and Melnard (tourist). And saved this status
Going to launch with these settings works fine.
But any change to the craft (adding or removing any part), loading the same craft, or reverting to VAB causes the crew assignment to be scrambled: Valentina (pilot), Corrim (tourist) and Dunbus (tourist). These 2 are simply the first 2 tourists in the available crew list; the names of the tourists are not properly saved with the craft.

Log file: KSP(BetterCrewAssignmentScramble).log

Edited September 15, 2021 by The-Grim-Sleeper
clarification

[Tuupertunut]

This mod does great job at remembering the crew in ships I save. Even the cargo I put into the inventory of the crew is remembered as long as I stay inside the VAB.

However, when I exit the VAB and come back, the inventory of all crew members gets reset. Could this bug be fixed?

[UnanimousCoward]

9 hours ago, Tuupertunut said:

This mod does great job at remembering the crew in ships I save. Even the cargo I put into the inventory of the crew is remembered as long as I stay inside the VAB.

However, when I exit the VAB and come back, the inventory of all crew members gets reset. Could this bug be fixed?

I believe that may be a stock issue. Somewhere in the KSP game settings is a setting called something like "Persist inventory loadout". Enable that, and the inventory might work the way you want it.