WuphonsReach

Has the calculation for maximum acceleration changed? (link to the full contract) PARAMETER { name = ReachState type = ReachState title = Must not be under acceleration maxAcceleration = 0.5 } The behavior that I'm seeing in KSP 1.4.4 is that if I time-warp, the parameter ticks over and the time remaining starts counting down. But if I'm running at 1x speed, the parameter is no longer valid and the timer resets. So I'm having to time-warp, set a KAC alarm, then go back to the space center (while at 5x/10x/etc.) to keep the timer running.

Pods are not per-biome (the hammer may be, but [X] Science would tell me for sure). I usually launch out 3-6 on descent in various directions, with a variety of powers. So one to the N at 100%, one to the S at 100%, one to the E at 50%, one to the W at 50%, one to the NE at 75%, one to the SW at 60%.

I recommend looking at Celestial Body Science Editor: https://spacedock.info/mod/136/Celestial Body Science Editor I also play with CTT with a moderate game difficulty and will turn down the science returns on Minmus/Mun/Kerbin. (The other thing I do is play with KCT with really slow settings, a custom config I made, where it takes 10-15 years to get past the 90-point nodes.) Have the hammer on the probe/ship. As you descend to the surface, fire off the pods sideways but upwards at 500-1500m AGL in different directions. Expect about half to two-thirds of the pods not to survive. Once you land and the distant mods no longer move, use the hammer portion like a normal science experiment. (I did some experiments with the pods a while ago in this thread. KSP physics kraken ate pods no matter what I tried.) You get more points the further that the pods are from the hammer.

I do some orbit randomization in the CC contracts for my mod. This file that I'm linking creates a polar orbit with a low Pe and a really high Ap (so you spend 95% of your orbit above or below Kerbin's poles).

Thanks. What I'm probably going to do for my 1.4.4 release: Refactor how much antenna power is needed for a tier 1 and tier 2 contracts. Introduce a tier 0 level of contracts in LKO with random orbits (under 800km altitude, various inclinations), suitable for antennas in the 1-3 Mm power range. Right now, you can complete them 10x to get a little ball of relays going. Hew more closely to 1.4.4 antenna strengths in vanilla, except where vanilla values don't make sense. Lower requirements on a lot of contracts for battery power, or deadline pressure. Lower permanent drain generator values on antennas, anything below about 5G of power has no permanent power draw. Transmitting science with relays is possible, but the EC/Mit values will be in the 40-80 EC/Mit range (most vanilla antennas are 6 EC/Mit). Add tier 1 (1Gm or more power) contracts that require Tundra / Kolniya orbits. Add tier 1 contracts that are random (out to about 6-8 Gm around Kerbin). Currently playing through in career mode and I've only unlocked the tier 0 and tier 1 contracts so far. I also need to run my parser again against my latest changes to see if there are any antenna values that need tweaks. I have one or two PRs out to various mod authors with balance tweaks for antennas that were way off compared to others. I don't feel the need to do the Kolniya/Tundra contracts for tier 2/3/4 antennas.

Even with careful use of auto-struts (mostly auto-strut to root on the 1st/2nd stage main tanks)? I haven't had to use KJR since KSP 1.3 launched.

Why does the Spacedock page say (at the very bottom) "Mod requiers: Kerbal Joint Reinforcement"? Also, in "ORION_COMMAND_MODULE_new5", the antenna module is missing a definition for packet interval (packetInterval).

Finished up parsing the config file (I used the ModuleManager cache file), see the ParsedData tab. https://docs.google.com/spreadsheets/d/1yj08CJX458ZbHOsLgVckEtqvHUj5KkP1En-R1kLIYyw/edit?usp=sharing I have 197 parts with antennas in my current GameData/ folder. This is the raw data prior to installing my mod.

I'll be taking a look at 1.4.4 this month. Been busy with other projects (and work). Busy writing a KSP config file parser in C# using .NET core as I need to update the spreadsheet with more parts pack values and trying to gather the data with awk/grep wasn't working out for me. Then I want to see how the current system is working before I work on this mod again.

@eightiesboi Yes, I would have liked to only have the generators turn on when the antenna was deployed, but have failed to figure out a way to do that yet (without writing C# code). It's real fun on the big OSIS antenna from DMagic. That consumes 90 EC/s (but is a 6.0Tm antenna) in the unreleased version. On my boosters, I tend to attach fuel cells which are attached to the stage event to turn them on when I launch. I've also used Module Manager to create clone copies of the SpaceY launch clamps so they provide 15-20 EC/s. That at least lasts me until I get almost into orbit. I also have access to large batteries through Near Future Electrical, plus some welded parts that I've created (12k, 32k and 60k). Plus the various solar panels from NFE and reactors from NFE/USI, so I may not be feeling the pinch as much. P.S. I have done a bit of balance work on the master branch in the github repo this month (boosting some signal strength, reducing some EC/sec, re-balancing of contracts), but have not yet pushed it out. It's probably close to a release state, but I'm still play testing. --- Links (only for the brave, there's no guarantee of balance or support or even future compatibility): Launch clamps: https://github.com/WuphonsReach/KSP-ScrapyardBob/tree/master/SpaceY-Lifters Batteries: https://github.com/WuphonsReach/KSP-ScrapyardBobsWeldings/tree/master/Parts/Batteries Master branch with latest changes: https://github.com/WuphonsReach/KSP-StockAntennaBalance

Each "research a celestial body" contract will only raise a single planet's value by 10%. The TB-75M in orbit is mostly useful for discovering bodies. Put one in high orbit around Kerbin, then right-click on the telescope to pull up the Research Bodies contract. Pointing at a celestial body (use Haystack or Distant Object Enhancement) and spamming the button will unlock the planet/moon. After that I just use the Shift-F12 debug menu and sit in the Mission Control, accepting and completing the "Research a Celestial Body" contract 10x for each planet/moon that I want to get to 100%. I never use the "research using a telescope" contract or bother going into the observatory UI. Unfortunately, the "RBResearchBodyBehaviourRB" does not allow a value to be passed in and is hard-coded to only give you 10% completion per contract completion. Otherwise, I'd submit a PR to have a more balanced contract system where you'd only need 1-4 contracts completed per celestial body (maybe with longer durations).

UbioZur Welding still exists -- with the caveat that it only really saves on part count, not FPS these days. For my MKS (well, mostly USI-LS) needs and other needs, I will frequently take one of the stock Kerbodyne tanks and create a MM patch that clones the part to remove some of the LF/Ox and replace it with storage capacity for this or that (supplies, reaction wheels, batteries, mono-prop tanks, fertilizer/mulch storage, AR202 module, etc.). The MM patch advantage is that it's modular and actually reduces the number of textures / polygons / etc. being drawn on the screen and simulated in physics. Or I'll weld 2-3 stock parts together, then swap out the innards completely to give me what I need.

I've seen this behavior as well, but have not been able to track it down. In my career games (because I've played for so many years), I'll start with 5000 or 8000 science and a bunch of funds (10-25 million). Which means I unlock a lot of research nodes in R&D on day 1 (or during the first play session). I'll also do some upgrade point purchases in the KCT Upgrades UI window. Then, sometimes when I come back into the game (next play session), I'll have a negative of -10 to -25. I usually fix it by gifting myself more science or funds and using the KCT Upgrades UI window, or I'll just wait to unlock more R&D nodes. I always figured it was because I'm using CTT (Community Tech Tree).

I'd expect that they would drain all resources in the current stage at a minimum? (without looking at the code, that is) (I only use the valves just before touchdown back on Kerbin to reduce the mass and lower the speed of descent under the parachutes.)

Yeah, I've been running the dev version for weeks and weeks without issue. There's even a new developer version of the Scrapyard add-on with some performance fixes which is very nice.

You probably want Crew Light add-on (see link by @canisin) Unless you're talking about "when the habitat generator is running, turn on the lights", which I don't have a ready answer for.

You can do something like this with the Contract Configurator add-on where you define your own contracts. There is a way for synchronous orbit satellites to have a "be above a particular point" criteria, but I didn't use it. (I use CC in my add-on to generate orbital contracts.)

MechJeb + DPAI First off, use the RCS Build Aid add-on to make sure that your ship is balanced when using the RCS thrusters to translate along the X/Y/Z axis. So if you have four RCS at the nose and four at the tail, right-click one of the set that is fartherest away from the center of mass (CoM) and adjust the thrust limit downward until the big orange circular arrow and the smaller orange arrows go away. Second, you need enough RCS power for MechJeb docking to be efficient. Too much or not enough will cause it to have trouble during the final docking. Third, pack along lots and lots of mono-propellant. Fourth, getting close to your target requires: Matching the plane of your target, doing a Hohmann transfer at the right time, and then zeroing out velocity relative to your target at the closest approach. MechJeb has the Rendezvous Auto-Pilot module which will do this for you. Fifth, you need to get lined up with your docking port. Start by right-clicking on your vessel's docking port and use "control from here". Then right-click on your target docking port and use "set as target" (if the target vessel has multiple docking ports, use the left/right buttons in DPAI). At this point, you can try turning on MechJeb's auto-pilot. Alternately, use MechJeb's Smart A.S.S. and pick "TGT" then "PAR-". That will orient your craft to be lined up with the docking port. Now you can just use I/J/K/L and H/N keys. The flow for docking is to get on the right side of the target vessel (green bars, not red bars), have a CVEL (closing velocity) close to zero at a CDEST of around 30-50m. (H/N keys push you towards/away from the docking plane.) Then use I/J/K/L to line up with the axis of the docking port. Once lined up, use H/N to start moving towards the docking port (or turn on MechJeb A/P at this point).

More kerbal head color variations would always be welcome. Bright pink hair? Stripes?

A thought about the hab/home timer. The current "instantly get maximum home time" feels a bit silly. It's the "instant" bit that bothers me. Put huge station in orbit around Kerbin, have kerbals pass within 150m on their way to Eeloo. I think homesickness should increase slowly instead of instantly from the current value to the maximum possible (in the current situation). My thinking is the maximum increase per 6h period should be 100d of home time. So if you dock a freshly launched keerbal with a 30 year station, it would take about 128 days to build up a full 30y home timer.

A timestamp is the instant in time (historical record) of when a kerbal left Kerbin. You then compare that timestamp with the current instant and do some math to get elapsed days. How did you transfer Bill to/from the station? Vanilla transfer method? EVA? Ship Manifest add-on? (That may help narrow down why the timestamp gets rewritten.)

I suspect what is happening with the mission time is that a space station, launched years before has a much higher MET than the kerbal. That seems to be the pattern I'm seeing when I get a huge mission time ribbon. (One possible fix would be to timestamp each kerbal as they launch from the home world, then use that to figure out MET on return.) There's a setting in Final Frontier that lets you revoke ribbons that were awarded incorrectly using the in-game UI. (Or maybe you just want to demote Jeb because he broke something again.)

I've had to remove Scrapyard 0.9.6.70. After maybe 100-150 vessel launches and recovery with StageRecovery, the VAB/SPH get laggy due to the recalculations. I'm not seeing any NREs or other exceptions, just slowness as I add/remove parts from the vessel design. The lag is a pause every few seconds, and clicking on things takes a second or two to register (including modes 2 and 3 where I'm moving/rotating an already attached part). I suspect something creating/destroying lots and lots of objects which may be triggering excessive garbage collection. The brute-force approach might be to only update inventory cost / build estimate every 10-60 seconds instead of on every change to the vessel.

https://github.com/ChrisAdderley/NearFutureElectrical/blob/master/Source/NearFutureElectrical/FissionReactor.cs#L703-L719 Feels like that value in the condition "(rate < 0.0000001)" is too large. For the small USI reactors, running at fractional rates (10-17%), it means you can't get a good estimate of core life remaining given the current fuel load for smaller reactors. The 0.625m USI reactors have a rate of 0.000000126785 at 100% with a fuel amount of 2.00 (730.3 days). Running at 10% would be 7 zeros before any non-zeros and a lifespan of 7300 days (about 17 years). Given that a C# double has 15-16 significant digits, changing that line to add one or two more zeros should not cause issues. This logic will give an answer if you have between 0d and 25y of fuel left based on current consumption. Below a certain rate of consumption, it assumes a minimum to avoid a possible divide by zero. const double veryLong = 3600 * 6 * 426 * 25; const double minimumCalculationRate = 0.000000001; rate = (rate < minimumCalculationRate) ? minimumCalculationRate : rate; var remaining = amount / rate; if (remaining > veryLong) return Localizer.Format("#LOC_NFElectrical_ModuleFissionReactor_Field_FuelStatus_VeryLong"); else if (remaining > 0) return Utils.FormatTimeString(remaining); else return Localizer.Format("#LOC_NFElectrical_ModuleFissionReactor_Field_FuelStatus_Exhausted");

Wonder if I use MKS PDUs to send power using the microwave link to the vessels with drill heads -- would that get around the meltdown issue?