Fraz86

I wouldn't be fundamentally opposed to boil-off for cryogenic tanks, however, it would need to be implemented in a manner that prioritizes fun & transparent gameplay mechanics. If people want maximum realism, they can use mods like RealFuels and RO. For "stockalike" gameplay, I don't think we should concern ourselves too much with realistic numbers for boil-off temperature and rate. Nertea's new HeatManagement mod (and the new version of NFE) will include radiators and heat pipes with active cooling capabilities. However, this active cooling has a floor of 273K. Therefore, the boil-off threshold would need to be above 273K. Something like 400K would probably be reasonable. Thematically, we could assume that cryogenic tanks have built-in internal refrigeration that prevents boil-off, as long as the temperature of the tank itself remains < 400K. It would also be important to include a means of alerting the player when boil-off is occurring; e.g., RCS effects coming off of the tank would be ideal.

After further testing, I think it is most likely a bug within IFS. It appears that if you use a list of variables to define tankMass, it just copies forward the value of the first variable in the list and ignores the rest. Using fixed numbers (instead of variables) works fine, which is why the Octo-Girders function as intended, but that obviously won't help for the LF/OX config.

It looks like fuel switching for LF/O/MP tanks was left out of the download. I don't see it in-game or in the config files. Edit: Also, in the config for LF/OX tanks, the line "tankMass = #$../mass$;#$../mixLH2mass$;#$../mass$;#$../mass$;#$../onlyLH2mass$" does not appear to be working as intended. In game, as you cycle through the fuel options, the "dry mass" remains constant at the part's stock mass. Contrast this with the Modular Octo-Girder, whose dry mass changes as intended. Unfortunately, I have not yet been able to identify the problem.

I am 100% on board; this looks great! Can't wait to test it out!

Toadicus, Just my 2 cents, but I am leery of calibrating KSC2 + DTS to be "in-range of Duna during ideal transfer window." I much prefer the simplicity of "KSC2 + DTS is always in range of Duna." The latter is significantly more straightforward, and more friendly to the "average Joe" player. Moreover, I do not see how the former contributes to fun gameplay. It would be distinctly un-fun to lose a probe due to a transfer that turns out to be suboptimal. On an unrelated note, I made an excel file that automatically provides practical descriptions of each antenna combination's range (see below). Pink cells are input, blue cells are output. Download here if you'd like to play around with it: https://www.dropbox.com/s/s1qsd03wysddycj/AntennaRange.xlsx?dl=0 EDIT: Here is an example of some numbers that feel "right" to me: You can download the excel file here: https://www.dropbox.com/s/8e0j41xhd2djztj/AntennaRange2.xlsx?dl=0

Looks great! Will this be on CKAN?

Telos Tech Tree Basic principles - Every node should offer meaningful progression and enticing new gameplay possibilities - As a corollary to the above, when multiple parts are functionally similar with no important advantages over one another (e.g., merely different sizes or appearances), those parts should be grouped together into a single node, so as not to pointlessly deprive the player of creative/cosmetic options - Parts that offer little practical utility in advancing the player's career should be grouped together with other such parts, so that collectively they will be more enticing, whereas an important part may have its own node - Progress should be slower than stock (stock tree can be unlocked without leaving the Kerbin SOI) - A reasonable degree of differentiation/specialization should be feasible as the player advances through the tech tree, but at the same time requiring progress to occur in a sensible stepwise fashion - The necessity and incentivization of science "grinding" should be minimized - The tree itself should not be huge, confusing, or difficult to navigate Starting out Where to begin - airplane parts or rockets; manned pods or probes? In this tree, the player begins with none of the above, but with the ability to quickly pursue any of these options. Starting parts include the external command seat (functions as a command module via dependency on TakeCommand), wheels, structural parts, batteries, antenna, thermometer, barometer, and seismometer (and the transmissibility of these 3 science parts has been increased to 100%). The external command seat strikes me as a particularly "Kerbal" way to begin, but also handily limits the players progression, as it presumably won't be safe for re-entry once heating is fixed, thus encouraging the player to pursue either probes or manned pods. Starting out with multiple science parts, batteries, and antenna may seem like an odd decision, but it has several benefits: - It allows the player to conduct a quick science-gathering rover tour around the KSC, providing enough science to unlock several nodes that will define the player's early emphasis (aviation vs rocketry, manned vs unmanned) - It reduces grind by making it easy to collect a significant chunk of the cheesy KSC science in one fell swoop (100% transmissibility also makes this easier), rather than re-touring the KSC repeatedly as new science parts are unlocked - When choosing nodes to unlock, the incentive to make a beeline for science parts is reduced when you already have several; thus encouraging the player to make decisions on the basis of design ambitions rather than science-gathering necessity Science changes Grind is reduced in the early game as described above, and further mitigated by setting the max science of all experiments equal to the base amount, thus removing the incentive to repeat experiments. This also slightly reduces the total obtainable science, which - in combination with the significantly increased science needed to unlock the entire tree (27,000 vs 16,918 for stock) - means that science will remain relevant farther into one's career. Experiment data scales and science part costs were also rebalanced. Mods - TakeCommand is a dependency, as explained above - All of Nertea's mods (NFT, SSP, Cryo Engines) are recommended (there will be some empty nodes without Nertea's mods, but they are not strictly required) - Porkjet's Atomic Age is supported - Optional config for KeepFit, which assigns "exercising" status to Nertea's habitation modules and slightly increases their masses to balance this advantage - Optional config for MechJeb, which currently adds the MJ module to all command parts and links functional progression to the unmanned techs - Communication tech progression is designed with AntennaRange in mind, but could be adapted to support RemoteTech easily enough; stock is also fine but there won't be much reason to unlock the dishes - Requires ModuleManager - Parts from unsupported mods are automatically assigned to the starting node for now, but adding support is relatively easy Downloads Telos Tech Tree Optional config for KeepFit + Nertea's Habitation Modules Optional config for MechJeb Further development No particular plans, but I'm open to feedback, and if there's significant community interest, I would be happy to help provide support for other mods. License is WTFPL

"%MODULE" does not specify which module to overwrite, and it therefore overwrites the first module it finds. Take a look at AddToRadialTanks.cfg, which specifies the module name as follows: %MODULE[ModuleCrossFeed] { %name = ModuleCrossFeed } Actually, I believe the "%name = ModuleCrossFeed" inside the brackets is entirely redundant, as the first line creates a module named "ModuleCrossFeed" (if no such module already existed), and then "%name = ModuleCrossFeed" changes the name to "ModuleCrossFeed", which was already its name. Thus, the following should be perfectly sufficient: @PART[airlinerMainWing]:FOR[CrossFeedEnabler] { %MODULE[ModuleCrossFeed] {} } @PART[adapterMk3-Size2Slant]:FOR[CrossFeedEnabler] { %MODULE[ModuleCrossFeed] {} } @PART[adapterSize2-Size1Slant]:FOR[CrossFeedEnabler] { %MODULE[ModuleCrossFeed] {} }

Toadicus, I've been considering the pros and cons of additive ranges. One advantage is that additive range ensures reciprocal connectivity. That is, it guarantees that if Antenna A can reach Antenna B, Antenna B can reach Antenna A. Given that the connections are being used both to send scientific data back to Kerbin, and to control probes from Kerbin (if the option is enabled), a reciprocal connection is intuitive. On the other hand, I'm concerned that the range differences between antenna types would become relatively insignificant as you progress to higher tiers. Consider the following chart, which takes the maximum ranges from your post above (Comm 16 = 51696, DTS = 37152180, Comm 88-88 = 224770770), and applies the equation, Range = [Antenna A]/2 + [Antenna B]/2: [table=width: 500] [tr] [td][/td] [td]Comm 16[/td] [td]DTS[/td] [td]Comm 88-88[/td] [/tr] [tr] [td]Comm 16[/td] [td]5.17E+04[/td] [td][/td] [td][/td] [/tr] [tr] [td]DTS[/td] [td]1.86E+07[/td] [td]3.72E+07[/td] [td][/td] [/tr] [tr] [td]Comm 88-88[/td] [td]1.12E+08[/td] [td]1.31E+08[/td] [td]2.25E+08[/td] [/tr] [/table] This problem could be mitigated using a non-linear equation. For example, Range = Sqrt([Antenna A]2 + [Antenna B]2), gives the following chart: [table=width: 500] [tr] [td][/td] [td]Comm 16[/td] [td]DTS[/td] [td]Comm 88-88[/td] [/tr] [tr] [td]Comm 16[/td] [td]5.17E+04[/td] [td][/td] [td][/td] [/tr] [tr] [td]DTS[/td] [td]1.39E+06[/td] [td]3.72E+07[/td] [td][/td] [/tr] [tr] [td]Comm 88-88[/td] [td]3.41E+06[/td] [td]9.14E+07[/td] [td]2.25E+08[/td] [/tr] [/table] Edit: If you want something in-between the two above options, you could play around with X in the following equation: Range = (([Antenna A]^(1/X))/2 + ([Antenna B]^(1/X))/2)^X At X = 1, it is identical to the first equation above. As X approaches infinity, it becomes equivalent to the second equation. At X = 2.8, the range of Comm 16 + Comm 88-88 ≈ DTS + DTS, which strikes me as a nice balance.

I've never had any success using ModuleManager to edit "@PART[kerbalEVA]" in the past. If you're saying it can be easily done using a plugin, well, I'm afraid that's outside the scope of my knowledge. Basically, I just want ModuleManager-like ability to edit the properties of EVA Kerbals.

Well, if you do get the chance to implement that functionality, I would be forever grateful!

Toadicus, that looks perfect.

I suppose it's ultimately a question of what is the intended gameplay purpose of AntennaRange? Is it intended to promote the construction of an intricately interconnected network of communications satellites? Or merely to provide a basic sense of progression, requiring players to unlock and use larger dishes to communicate longer distances? If toadicus' intent is closer to the latter, then the "Kerbin SOI -> inner planets -> outer planets" progression seems ideal. Also, while I am aware of mods that add dishes of various sizes, it seems to be important to toadicus that the mod function well with only the 3 stock antennae, which I think is a good decision. As such, it seems that the progression should be tuned around the 3 stock parts.

Couldn't you accomplish the same progression of antenna ranges without additive behavior? You could just double the above ranges, as below: Communotron 16: Increase range to Kerbin's SOI Comms DTS: Increase range to Duna's SMA + Kerbin's SMA, allowing it to be used for all "inner system" missions Communotron 88-88: Change range to ~1.5x Eeloo's SMA Wouldn't this be functionally almost the same as the additive option, except that the non-additive approach wouldn't require a matching antenna in Kerbin orbit (which seems like a rather trivial difference)? The end result, in both cases, is a progression from Kerbin SOI -> inner planets -> outer planets, which feels intuitive and well balanced. And, as you said, the jump from medium dish to big dish would be less extreme. I can see the pros and cons of additive vs non-additive, and I don't have a strong opinion either way. However, the discussion of progression of antenna ranges seems like a mostly separate issue, is it not?

It looks like CKAN has CTT designated as a required dependency. Since CTT isn't actually required (and designating it as such forces the user to install it), please change it to suggested or recommended.

Where did you get that information? 1.03 was supposed to be released last week. There were several Steam DB changes Friday morning, which usually immediately precede a release. Later on Friday they reported a "work emergency," which apparently prevented them from getting 1.03 out the door, but it would seem reasonable to assume the patch should be ready early this week. Unless they've put out a statement to the contrary?

It looks like AddToRadialTanks.cfg needs an update to include the new fuel-containing wings. Until it's been officially updated, you can copy and paste the following entries into a ModuleManager file: @PART[airlinerMainWing]:FOR[CrossFeedEnabler] { %MODULE[ModuleCrossFeed] { %name = ModuleCrossFeed } } @PART[wingShuttleDelta]:FOR[CrossFeedEnabler] { %MODULE[ModuleCrossFeed] { %name = ModuleCrossFeed } } @PART[wingShuttleStrake]:FOR[CrossFeedEnabler] { %MODULE[ModuleCrossFeed] { %name = ModuleCrossFeed } } Secondly, I noticed the AddToRadialTanks.cfg includes radial RCS tanks. Given that monoprop uses STAGE_PRIORITY_FLOW, which seems to ignore crossfeed, I was wondering: what does adding CFE do?

Is EVAManager able to edit fields other than modules and resources? For example, could I change the maxTemp of EVA Kerbals?

Due to radiators' heat transfer behavior, it might be possible to overheat a radiator even though its parent part isn't hot. In this case, the temperature of the parent part is less important than its total heat content. That fuel tank has enormous thermal mass, which means lots of heat to be sucked out by the radiators even at normal temperatures. Ordinarily, the parent part's temperature would eventually drop to the point that heat transfer slows down, but perhaps in your case the thermal mass was so high that the radiator exploded before you reached that equilibrium. The situation was also obviously exacerbated by the heat pipes from the engine, as well as the low emissivity of the radiator while closed. I'm not sure if these factors fully account for the explosion, but it seems plausible. If so, turning off the radiator's heat transfer while closed should prevent similar mishaps in the future. Edit: Nevermind, I just saw your most recent post.

It's included in the NFE dev download. https://www.dropbox.com/s/9osrqe6c051v91t/NearFutureElectricalX_4_13.zip?dl=0

Ah, that seems reasonable. It would require a lot of heat pipes to exploit a 1.05 ratio, and at that point, a radiator would have lower mass. Though, perhaps an increase in heat pipes' cost is warranted, considering that radiators are quite expensive. Somewhere in the 500-1000 range feels about right.

Did you end up leaving the heat pipe ratio at 1.25? Even with doubled heat production, I would still recommend a ratio of 1.0, as I'm afraid serial heat pipes are fundamentally exploitable otherwise. I'll do some testing when I get home.

Given the requests ring-less engines, I thought perhaps it might be worthwhile for me to chime in as someone who doesn't want ring-less engines. The purpose of this mod is to provide LH2/LOX analogues to some of the stock LF/LOX engines, and it does so beautifully. Nertea's parts have always been very "stockalike", and his mods generally conform to stock conventions whenever possible. These are traits that many users of his mods value. There are no ring-less stack engines in vanilla KSP, and as such, this request seems out-of-scope for this mod.

I completely understand! Real life comes first. Take your time; it's already a fun and interesting mod! In the config I provided for Stockalike Station Parts, I failed to realize that airlocks can hold crew, so I missed a couple parts. Here they are: @PART[crewtube-airlock-125]:NEEDS[KeepFit]:AFTER[KeepFit] { MODULE { name = KeepFitPartModule strActivityLevel = CRAMPED } } @PART[crewtube-airlock-25]:NEEDS[KeepFit]:AFTER[KeepFit] { MODULE { name = KeepFitPartModule strActivityLevel = CRAMPED } }

In order to test the effects of doubling reactor heat production and radiator heat transfer, I applied the following patch: @PART[*]:HAS[@MODULE[FissionReactor]]:Final { @MODULE[FissionReactor] { @HeatGeneration *= 2 } } @PART[*]:HAS[@MODULE[ModuleGenericRadiator]]:Final { @MODULE[ModuleGenericRadiator] { @Radiation *= 2 @RadiationExtended *= 2 } } Then I built this spacecraft: All reactors stabilized below nominal temperatures. Details are as follows: [table=width: 500] [tr] [td][/td] [td]Reactor Temp[/td] [td]Radiator Temp[/td] [/tr] [tr] [td]M-EXP[/td] [td]273[/td] [td]1161[/td] [/tr] [tr] [td]MX-4[/td] [td]273[/td] [td]1395[/td] [/tr] [tr] [td]MX-1[/td] [td]352[/td] [td]1135[/td] [/tr] [tr] [td]MX-L[/td] [td]831[/td] [td]1123 (GR-1) & 1444 (XR-550)[/td] [/tr] [tr] [td]MX-2[/td] [td]273[/td] [td]1417[/td] [/tr] [/table] Edit: In order to test the effect of doubled reactor heat on a spacecraft that attempts to use structural heat dissipation in lieu of actual radiators, I used one the the NFT example craft, Deep Space 2, with each of its 4 GR-EXP radiators replaced by a Structural Wing Type D. This modification represents a 25% increase in "radiator" mass, with a 60% decrease in cost. In the original configuration, the reactor stabilizes at 273K. In the modified version (without radiators), the reactor stabilized at 864K. This is well below its critical temperature of 1300K, but above its nominal temperature of 650K. I would personally prefer that it was a bit more punishing, but it's certainly an improvement from before.