FlowerChild

Where I think you're wrong here is that I don't think there were any boys in the game previously either. As far as we knew, they were all hermaphrodites, with this I think that Squad has basically just added gender to the game when it wasn't previously there. I would argue they've already made a mistake through naming her "Valentina", as described in my previous post, which I think is a name better suited to an adult dancer than an attempt to bring any form of gender equality to a game.

This part is strange to me, as I don't think I saw any arguments in the other thread made against the female Kerbals that weren't related to development time. I know for certain that's all my comments were related to in viewing the addition of female kerbals as something that was completely unnecessary and which adds the danger that Squad will be forced to spend more time addressing complaints in the future as a result, no matter how careful they were about avoiding gender stereotypes. Take for example the overblown name "Valentina" itself. I think it could be quite reasonably argued that name for the first Kerbal female encourages the objectification of women by making a strong associated between them and a holiday themed towards romance. It's subtly saying "the primary purpose of women is love". Put another way, it sounds like a name for an adult dancer. I am not personally making that argument mind you. What I am saying is that there was previously no gender issue in KSP. Now there's potentially big ones and if that's the case, it's inevitably going to consume additional development time over what was previously a non issue.

Remains to be seen. This has the potential to be rather weird, and open up a whole can of worms with regards to gender bias that didn't previously exist, having Squad making additional changes ad nauseum to address one complaint or another. What roles do the female Kerbals play within the space program? Do they visually reinforces gender stereotypes? Are they equally represented in both management and astronaut positions? Previously, as far as I'm concerned, there was no gender issue in KSP. Now there potentially is one which can turn this into an ongoing issue. Hehe...no, it's amusing but I wouldn't actually do it

Lol...it'll be tempting This is definitely the biggest face-palm I've pulled with KSP since the starting manned thing

So what? Are any of us so short on imagination that we can't fathom an alien culture having a naming convention that violates our narrow sense of gender boundaries? Heck, if it's an issue, you can just throw "Sue" into the table of random names and be done with it. IMO, the lack of "female" Kerbals didn't speak of there being anything wrong with the game, it was the complaints about it that spoke more to our obsession with gender and gender roles as a culture.

<face palm> Never thought that Squad would cave to the ridiculous public pressure to have "females" of an alien species that could have been hermaphrodites for all we know. Cheers to the community for pressuring Squad to waste their time on a non issue. Personally, I was hoping for the Van Allen radiation belt to be implemented in some way, but I guess we get "Valentina" instead

Yeah, I agree, and I am a programmer Squad has access to the source code, which we modders do not. That means they can address things at a far more fundamental (and much easier) level than modders can. I think the key word in that is "look". I don't think it's in any way implied that they intend the new aero itself to be more in-depth than FAR.

Thanks for the verification. I think I'll assume that's what they meant anyways and that it was just a bit of imprecise language as it makes much more sense. The first time I read the summary I didn't understand what the heck he was talking about until I realized he may have meant "intuitive" Yup, I realize. It's more than things that are intuitive are generally predictable, but things that are predictable aren't always intuitive. Just got confused based on that, and also likely because I'm used to "predictable" being used to describe game systems that are deterministic rather than intuitive and couldn't really figure out how the new system would be any more deterministic than the old. Regardless, I'm pretty sure "intuitive" is what was meant there and I'm just over thinking the whole thing

Yup, as I mentioned above: As far as I know, the new operator only hides the base class function if you're calling an instance of the child class directly. If you're calling it through a reference to the base class (which in this case, that's precisely what the GameVariables.Instance is), the original base class function will be called. Basically, the new keyword doesn't respect polymorphism, and I checked multiple online sources to see if there was a way around that (I'm primarily a C++ programmer so I'm often times unaware of the subtleties of C# syntax), and from the many discussions I found about that particular issue, there doesn't appear to be.

Big thanks for the summary. Very helpful. One question though: are you sure they said "predictable" with regards to the aero system, as opposed to "intuitive"? Maybe it's a language barrier thing, but the former doesn't make much sense given the current system is 100% predictable, but the latter definitely would given the way it behaves is not what you would initially expect, particularly as a new player.

Just wanted to express my thanks for this very handy mod. It really should be stock functionality. Liked it so much, I made it a recommended mod to go along side my own

I thought the above idea had some merit, so I decided to give it a try, but unfortunately given that none of the methods are virtual, the base functions are still called. For reference, here is the code I attempted this with: using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using UnityEngine; using BTSM; class BTSMGameVariables : GameVariables { public BTSMGameVariables( GameVariables originalVariables ) : base() { contractDestinationWeight = originalVariables.contractDestinationWeight; contractFundsAdvanceFactor = originalVariables.contractFundsAdvanceFactor; contractFundsCompletionFactor = originalVariables.contractFundsCompletionFactor; contractFundsFailureFactor = originalVariables.contractFundsFailureFactor; contractPrestigeExceptional = originalVariables.contractPrestigeExceptional; contractPrestigeSignificant = originalVariables.contractPrestigeSignificant; contractPrestigeTrivial = originalVariables.contractPrestigeTrivial; contractReputationCompletionFactor = originalVariables.contractReputationCompletionFactor; contractReputationFailureFactor = originalVariables.contractReputationFailureFactor; contractScienceCompletionFactor = originalVariables.contractScienceCompletionFactor; mentalityDeadlineExceptional = originalVariables.mentalityDeadlineExceptional; mentalityDeadlineSignificant = originalVariables.mentalityDeadlineSignificant; mentalityDeadlineTrivial = originalVariables.mentalityDeadlineTrivial; mentalityExpiryExceptional = originalVariables.mentalityExpiryExceptional; mentalityExpirySignificant = originalVariables.mentalityExpirySignificant; mentalityExpiryTrivial = originalVariables.mentalityExpiryTrivial; mentalityFundsExceptional = originalVariables.mentalityFundsExceptional; mentalityFundsSignificant = originalVariables.mentalityFundsSignificant; mentalityFundsTrivial = originalVariables.mentalityFundsTrivial; mentalityReputationExceptional = originalVariables.mentalityReputationExceptional; mentalityReputationSignificant = originalVariables.mentalityReputationSignificant; mentalityReputationTrivial = originalVariables.mentalityReputationTrivial; mentalityScienceExceptional = originalVariables.mentalityScienceExceptional; mentalityScienceSignificant = originalVariables.mentalityScienceSignificant; mentalityScienceTrivial = originalVariables.mentalityScienceTrivial; partRecoveryValueFactor = originalVariables.partRecoveryValueFactor; reputationAddition = originalVariables.reputationAddition; reputationKerbalDeath = originalVariables.reputationKerbalDeath; reputationKerbalRecovery = originalVariables.reputationKerbalRecovery; reputationSubtraction = originalVariables.reputationSubtraction; resourceRecoveryValueFactor = originalVariables.resourceRecoveryValueFactor; } static public void OverrideStockGameVariablesIfNecessary() { if ( GameVariables.Instance != null ) { if ( !( GameVariables.Instance is BTSMGameVariables ) ) { // FCTEST Debug.Log( "BTSMGameVariables: Replacing stock GameVariables" ); GameVariables.Instance = new BTSMGameVariables( GameVariables.Instance ); } } } public float GetCraftMassLimit( float editorNormLevel ) { float fMassLimit = BTSMUtils.GetLaunchCapacityBasedOnResearchUnlocks(); // FCTEST Debug.Log( "BTSMGameVariables GetCraftMassLimit() returning: " + fMassLimit ); return fMassLimit; } } I'm instantiating through OverrideStockGameVariablesIfNecessary() from a separate monobehavior which is called whenever the space center is loaded to check if my class needs to override the stock one, and while it is properly instantiated and set, the debug output within GetCraftMassLimit() is never hit, and mass limits remain at stock levels (I already had mass limiting functionality in my mod pre-0.9, so BTSMUtils.GetLaunchCapacityBasedOnResearchUnlocks() is just a pre-existing function I already had written). I've also tried declaring GetCraftMassLimit() as override, virtual and new on different occasions, to no avail. Unless someone knows a trick to force overrides on non-virtual functions like this in C#, it doesn't look like this will work.

Yup, that's of course true. However, what I was trying to point out is that polls of this kind are not so much asking "how many players use this particular configuration?" as much as "how many people actively following the thread are using this configuration?" and that can vary rather wildly based on who follows the thread and when. For example, if people are having problems using DR in combination with FAR, I think it reasonable to expect that you'd have a higher number of FAR users actively following the thread at that particular time, as they'd be looking for potential solutions. Same if that were the case with stock aero, or if for example there was an incompatibility between DR and RemoteTech or something, you'd expect a higher number of RemoteTech users to be active here. Maybe I'm just pointing out the obvious that all stats are affected by the context in which they are collected, with the potential of invalidating the results. Can't be entirely certain there of course, but I'd say it's probably true for 90%+ of them. FAR/NEAR really does not go well with BTSM as the progression is essentially broken with it installed, including having to take rather extraordinary measures just to stop all your rockets burning up on ascent in the first couple of tech levels due to the thinner atmosphere (and beyond that point much of the challenge of progressing in the mod is nullified by the lower deltaV requirements).

The poll results might be a bit biased though. One thing to keep in mind, is that all BTSM players are using DR with stock aero, and I suspect the more mods people use (or the more issues they are currently experiencing with their particular configuration), the more likely they are to check mod threads and see things like polls as well So, I think what you might be getting through the poll is more "how many people with this particular configuration are actively following the thread right now?"

You can just drop it in anywhere in the Gamedata/DeadlyReentry directory saved as "whatever.cfg" It actually overrides all the different difficulty options to be the same given BTSM is balanced around a single set of options, so no need to worry about that part. Keep in mind, that's balanced around a totally stock install though, both in terms of stock sized Kerbin, and stock aero. Not sure how well it would work with FAR or what have you. There are also a few BTSM specific changes in there like ablative shielding isn't a tweakable resource and the parachutes are reset back to having stock deployment altitudes and pressure that you may or may not want in your game. They should be pretty obvious in the config though and can be disabled just by deleting the relevant sections.

That's actually what I was talking about above For convenience, here's the settings I use in BTSM: // config file to rebalance Deadly Reentry parts and stock parts with DR heat shields for stock game feel. @REENTRY_EFFECTS[*]:Final { @shockwaveMultiplier = 1.0 @shockwaveExponent = 1.09 @heatMultiplier = 25 @temperatureExponent = 1.03 @densityExponent = 0.85 @startThermal = 750 // formerly set at 250. No longer needed due to DR changes. @fullThermal = 1150 @afxDensityExponent = 0.8 @gToleranceMult = 2.5 @parachuteTempMult = 0.5 @crewGClamp = 30 @crewGPower = 4 @crewGMin = 5 @crewGWarn = 300000 @crewGLimit = 600000 @crewGKillChance = 0.75 @ridiculousMaxTemp = 2500 @maxTempScale = 0.5 @dissipationCap = True // the following turns off per planet atmospheric density variation @legacyAero = True @useAlternateDensity = False } @RESOURCE_DEFINITION[AblativeShielding]:Final { @isTweakable = false } // Command Pod MK1 @PART[mk1pod]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key,1 = 800 480 } } } // 1.25m Heatshield @PART[1.25_Heatshield]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key,1 = 800 480 } } } // Heat Shield for Mk 1-2 Pod @PART[2.5_Heatshield]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key,1 = 800 240 } } } @PART[0625_Heatshield]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key,1 = 800 640 } } } @PART[3.75_Heatshield]:Final { @MODULE[ModuleHeatShield] { @dissipation { @key,1 = 800 60 } } } // probe cores // Stayputnik Mk1 @PART[probeCoreSphere]:Final { !MODULE[ModuleHeatShield] { } } // nose cones // Aerodynamic Nose Cone @PART[noseCone]:Final { !MODULE[ModuleHeatShield] { } } // Protective Rocket Nose Mk7 (large one) @PART[rocketNoseCone]:Final { !MODULE[ModuleHeatShield] { } } // wings // AV-R8 Winglet @PART[R8winglet]:Final { !MODULE[ModuleHeatShield] { } } // Swept Wings @PART[sweptWing]:Final { !MODULE[ModuleHeatShield] { } } // Delta-Deluxe Winglet @PART[winglet3]:Final { !MODULE[ModuleHeatShield] { } } // AV-T1 Winglet @PART[winglet]:Final { !MODULE[ModuleHeatShield] { } } // parachutes // Mk16 Parachute @PART[parachuteSingle]:Final { !MODULE[ModuleHeatShield] { } !MODULE[ModuleAnimation2Value] { } // overriding DR's changes to default deployment altitude and pressure @MODULE[ModuleParachute] { @minAirPressureToOpen = 0.01 @deployAltitude = 500 } } // Mk16-XL Parachute @PART[parachuteLarge]:Final { !MODULE[ModuleHeatShield] { } !MODULE[ModuleAnimation2Value] { } // overriding DR's changes to default deployment altitude and pressure @MODULE[ModuleParachute] { @minAirPressureToOpen = 0.01 @deployAltitude = 500 } } // Mk25 Parachute @PART[parachuteDrogue]:Final { !MODULE[ModuleHeatShield] { } !MODULE[ModuleAnimation2Value] { } // overriding DR's changes to default deployment altitude and pressure @MODULE[ModuleParachute] { @minAirPressureToOpen = 0.007 @deployAltitude = 2500 } } // Mk2-R Radial-Mount Parachute @PART[parachuteRadial]:Final { // overriding DR's changes to default deployment altitude and pressure @MODULE[ModuleParachute] { @minAirPressureToOpen = 0.01 @deployAltitude = 500 } } // other @PART[trussAdapter]:Final { @maxTemp = 1250 // 5000 stock, reduced to 2500 by DR, but still too high } // modular girder segment @PART[trussPiece1x]:Final { @maxTemp = 1250 // 5000 stock, reduced to 2500 by DR, but still too high } // Modular Girder Segment XL @PART[trussPiece3x]:Final { @maxTemp = 1250 // 5000 stock, reduced to 2500 by DR, but still too high }

If you'd like a more recent version of those changes, they can actually be found within my BTSM mod. Just grab the "DRPartBalance.cfg" file out of it and you should be good to go. The changes I previously posted here that you were talking about were just an earlier version I was developing for BTSM.

Ah! Cool. Thanks man

Does anyone know what "Research Science Limit" for the R&D building does? I assumed it was some kind of cap on how much science you can accumulate at any one time, but after exceeding it, that doesn't appear to be the case.

Hehe...just wanted to chime in to say that's an awesome attitude man Fine Print integration is probably the one thing I am most anticipating in 0.9.

If I may chime in on the above, I've edited the part test contracts so you won't get access to parts that give you additional abilities before actually unlocking them. So while yes, you get testing contracts for RCS tanks at that stage of the tree, you won't get any for RCS Thrusters no matter how long you wait

Honestly I don't think that there are enough systems in the game to justify the above. If for example, there was a system for Kerbals to maintain or repair vessels while in flight (which itself would necessitate some kind of damage system), then I could see XP affecting the rate or quality of repair making sense, as that's not something the player can reasonably control short of quick-time events (which suck mightily). It then becomes a situation similar to what I mentioned about unjamming a gun in a WWI flight sim. In a case like that the role of the player and the role of the Kerbal are clearly defined. I think where the current ideas I've seen mentioned fall flat is that they're crossing the line between what is the players responsibility, and what is the Kerbal's. XP systems are ultimately abstractions used to fill the gap where the player doing something themselves is either impractical due to UI limitations, or would be so dull as to not qualify as fun. They're not really things that should be aspired towards for their own sake IMO. I think a big problem with all this is that *Kerbals just don't do much* and thus trying to jam a system in place to make them more significant is destined to get funky. If people want them to have a more significant role in the game, then I suspect more significant activities must be added to the game for them first instead of trying to jury rig existing activities the player has full control over to give Kerbals significance.

I posted this in another portion of the forums, but wanted to quote it here in the hopes that Squad might be more likely to read it: In short, I don't think the issue with the XP system is the particular variables you have it affecting (engine performance, etc.), I think that it's more an issue that the game is ill-suited for such a system in the first place, and it may be entirely reasonable to consider scrapping it entirely. And this is coming from a guy that is ONLY interested in playing career mode, so career/sandbox bias isn't a factor here.

If you check the in game part description it lists the actual temperature the part can handle after DR applies its changes.

That sounds a lot like he's using BTSM, where the integrated heat shield is a separate tech tree unlock.