Fraz86
-
Posts
462 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Fraz86
-
-
17 hours ago, Captain Sierra said:
@Fraz86 I think I would prefer something in the middle. I think it should be possible to execute a Duna mission on lifter tanks alone (assuming insulated orbital tanks are higher up the tech tree). Boiloff should become a serious concern that has to be designed around, but not be prohibitive. 0.015% loss per hour results in a 27% loss to Duna.
Another thing that came to mind is will oxidizer boil off too? Its a stock resource so depending on how the module is configured, it may not have the effect. In that case, you also have to consider the oxidizer which is now dead mass. You're still lugging it even if you cant burn it. This means less boiloff rate can still inflict the same punishment to your mission margins.
Oxidizer shouldn't boil off; that would be a dramatic change to the stock game, which NFT avoids.
The left over oxidizer isn't dead weight - it actually makes boiloff less punishing for LH2/OX engines, not more. The player simply needs to haul extra LH2 (presumably in LH2-only tanks) for longer duration missions, to compensate for LH2 lost to boiloff. LH2/OX engines only use 0.14kg LH2 per kg OX, so you won't need much extra LH2 to make use of the surplus OX. These considerations argue in favor of higher boiloff if we want it to have a significant impact on gameplay.
On an unrelated note:
@Nertea After further consideration, I think boiloff rate should be modeled as % loss of remaining LH2, as opposed to % loss relative to LH2 capacity. Percent loss relative to LH2 capacity incentivizes tedious, silly behavior. For example, the player could minimize LH2 loss during a trip to Duna by storing their LH2 in 100 tiny LH2-only tanks. Once 1% of the LH2 has boiled off, the player empties 1 tank (transferring its contents to the other 99 tanks), thereby effectively reducing the boiloff rate by 1%. This process is repeated each time enough LH2 has boiled off to empty another tank, always maintaining the used LH2 capacity at the minimum necessary, minimizing boiloff. Encouraging this behavior is clearly undesirable. If the boiloff rate is instead modeled as % loss of remaining LH2, there is no incentive to move LH2 between tanks, and optimal gameplay is more straightforward. I would propose 0.025% loss per hour, which (with exponential decay) corresponds to ~36% loss to Duna.
-
19 hours ago, Nertea said:
Drag will probably not be changed to start. I will probably lower the maxTemps a bit just because I like doing that and it makes me feel powerful :P. Just boiloff vs mass ratio as a tradeoff... It turns out I will probably need to write a tiny module for this, but that will not be hard.
Excellent!
QuoteRates, what do we think about these. It will probably be volume-scaled exactly, for logic's sake. I mean in theory it should be dependent on the surface area to volume ratio of the tank, but that's too much work/silly/inconsistent. In an ideal world, loss should be minimal during launch and a few orbits (~45 min), but be severe enough that a trip to Duna will put a serious dent in your tanks.
If you want the trip to Duna to put a "serious dent" in the tanks, but not to completely deplete them, then I'd suggest something like 0.025% loss per hour. That translates to 45% LH2 loss after a trip to Duna, if we assume the trip takes 300 Kerbal days (1800 hours), and assuming we're talking about % loss relative to LH2 volume capacity (not relative to the remaining volume of LH2).
Edit: Alternatively, if you want the dent to be a bit less serious (potentially making it practical to bring atmospheric tanks to Duna), you could go with 0.01% loss per hour, which translates to 18% LH2 loss after a trip to Duna. Another way to look at loss rates is in terms of "time until depletion," which would be 4000 hours (667 Kerbal days) at 0.025% per hour, or 10000 hours (1667 Kerbal days) at 0.01% per hour.
-
It looks like Nertea decided against higher drag for consistency reasons, and the reality is that lower maxTemp and crashTolerance don't really matter in most situations.
Moreover, avoiding boiloff is extremely valuable. In fact, it's outright necessary if you plan to use the fuel more than a few days or weeks after launch (depending on what exactly the boiloff rate turns out to be). Thus, orbital tanks could have pretty much any list of downsides and they would still have clear use cases.
-
3 hours ago, Nertea said:
Same volume ratio, lifter tanks have better mass ratio though.
I think that's the right way to go. If orbital tanks had the better mass ratio, they would be too attractive for use on lifting stages, or at the very least it would present the player with a confusing tradeoff. It's much more transparent to make atmospheric tanks unambiguously better except for boiloff.
One other point of clarification: will boiloff occur "per-tank, encouraging fewer larger tanks over many small," as Captain Sierra suggested, or will it be "per LH2 capacity," in which large tanks have no particular advantage over small tanks? Personally, I would find the latter to be more straightforward.
-
9 hours ago, billkerbinsky said:
The space shuttle used a ratio of 2.7l of H2 per liter of lox; that would be a volumetric ratio of 0.27 liters of OX and 0.73 liters of H2 per liter of tank volume. (On the mass side, because of hydrogen's fluffiness, that inverts to 6kg of oxidizer per kg of hydrogen. 8:1 is the stoichiometric mass ratio, but it looks like the SSME runs fuel-rich). Hydrolox rockets should have a definite volume penalty - you just need much bigger tanks to contain the needed mass of propellant.
The mass ratio of LH2/OX tanks corresponds to the fuel usage of cryo engines, which burn 10 units LH2 per unit OX. This gives a mass ratio of 7.06kg OX per kg LH2, which is pretty close to your space shuttle example.
In terms of volumetric ratio, however, Nertea and testers concluded that using real-world density for LH2 results in tank volumes that are simply impractical and un-fun. Therefore, the density of LH2 in fuel tanks is "fudged" (currently at 150%) for gameplay reasons.
In Nertea's previous post, he proposed that perhaps this density-fudging should be increased, which of course would result in a decrease in the LH2:OX volumetric ratio. I was merely suggesting that - if we are further decreasing the LH2:OX volumetric ratio - perhaps we should just match it to the LF:OX volumetric ratio. This change would be from 0.55L:0.45L to 0.45L:0.55L, which isn't too dramatic.
Also, as further reassurance, even with LH2 density fudged to 222%, LF would still be 5.78x more dense than LH2, so you would still notice a difference in the tank volume required for hydrolox rockets.
QuoteI'd very much like to look into boiloff options myself, but this would likely require further plugin coding that, depending on implementation, is highly intertwined with the ever-changing stock heat system. Nertea probably doesnt want to have to do through the NFE hassle twice every update. While a fun thought experiment, its probably best to keep it that way no matter how cool it may be.
I understand that incorporating heat mechanics might be asking too much in terms of plugin coding and complexity for players. That's why my suggestion for boiloff in atmospheric tanks does not involve any heat mechanics, nor do the first 2 out of 3 of my options for orbital tanks.
Boiloff could be very simple, e.g.: atmospheric tanks continuously lose fuel at a slow rate (e.g., 0.1% LH2 capacity per minute), while orbital tanks never lose fuel but are otherwise inferior (e.g., higher cost, inferior dry mass ratio, lower maxTemp).
-
Another thought regarding buffing LH2 density:
The "mixOXProportion" of stock LF/OX tanks is 0.55 (i.e., 0.55L OX per liter of tank volume). If we're increasing the mixOXProportion for LH2/OX tanks (due to increasing LH2FudgeFactor), perhaps we might as well go to the point of matching the stock LF/OX proportion at 0.55. The corresponding LH2FudgeFactor would be 2.22. This would provide a nice symmetry when switching between LF/OX and LH2/OX configurations, in that OX would remain the same. I can't think of any reason why this is particularly important in terms of actual gameplay, but it might slightly improve players' ability to compare the different fuel configurations.
Here are a few thoughts regarding relatively simple implementation of boiloff:
'Atmospheric' tanks - Boiloff occurs at a fixed rate (e.g., 0.1% of the tank's total volume per minute) and nothing can be done to mitigate it. The rate is low enough that the impact on lifting stages is trivial. The part descriptions of these tanks would need to be addended to make it very clear that they are not intended for prolonged use.
'Orbital' tanks - Here we have a few options, in increasing order of complexity:
- No boiloff, but the tank otherwise has significant disadvantages (e.g., higher cost, inferior dry mass ratio, lower maxTemp, etc.).
- Constant EC requirement. As long as EC is available, no boiloff occurs. If the craft runs out of EC, boiloff occurs at the same rate as for atmospheric tanks.
- Requirement to maintain a low core temperature using radiators. As long as the core temp of the tank remains below the threshold, no boiloff occurs. If the core temp of the tank rises above the threshold, boiloff occurs at the same rate as for atmospheric tanks.
-
1 hour ago, Nertea said:
The way it looks to me is that the mass ratio of LH2 tanks just needs to be friendlier. This will likely need some small downward revisions in CryoEngines Isp values, I'm fine with that. I'd like to aim for something slightly lower than LiquidFuel dry mass.
Looking at this in terms of "massPerUnitLH2" (the variable in the fuel switching config), the current values of 0.000035 (for stock tanks) and 0.000025 (for cryo tanks) give dry mass ratios of 2.02 and 2.83, respectively. A value of 0.00001 would give a ratio of 7.09, just below LiquidFuel's ratio of 8 (the difference would be trivial in gameplay). If you want a slightly more meaningful difference, a massPerUnitLH2 of 0.000015 would give a ratio of 4.72.
QuoteThe only annoying thing that I see is that the dry masses (and total masses) of some of the smaller LH2 tanks will be ridiculously small. It might be good to fudge the amount of LH2 going into a tank a bit more than it already does.
The current "LH2FudgeFactor" is 1.5, meaning that a given volume of tank is allowed to hold 1.5x as much LH2 as it should. In LH2/OX tanks, this means that LH2 occupies ~55% of the tank's volume, whereas (without fudging) it ought to occupy ~65% of the tank. Increasing LH2FudgeFactor to 1.8 might be a reasonable bump, with a corresponding increase of mixOXProportion to 0.5 (meaning that, with 180% LH2 density, the volume of LH2/OX tanks would be evenly split between LH2 and OX).
QuoteThe other thing to solve is some sort of differentiating factor for the fancy LH2 'orbital' tanks without implementing boiloff, preferably. I'm thinking minor advantages and disadvantages, mostly to discourage atmospheric use and encourage orbital use. Options might include that drag increase (doable for sure), increasing the LH2 volume compared to the basic tanks (but preserving the same mass ratio)... fiddly things like that.
I like the possibility of increased drag, however, I hesitate due to concern for consistency. If LH2 'orbital' tanks are given higher drag, what about other skeletal parts that also look like they should have higher drag? For example, what about Xe, Li, and Ar tanks? What about Octo-Trusses? You could give them all higher drag, but then it becomes a rather far-reaching solution, which I suppose is fine if you're comfortable with it. It's also quite tedious to implement because it requires defining custom drag cubes for each part, unless you've found an easier way to do it. On the other hand, I worry that options other than increased drag will fail to provide the 'orbital vs atmospheric' differentiation that you're hoping for, so I don't know what to suggest as an alternative.
-
The new 1.25m Li tanks have a higher maxTemp (1200K) than the 2.5m Li tanks (800K).
-
4 hours ago, Nertea said:
Xe tanks normalized to a dry mass ratio of 1.28 (same as large stock tank)
I just wanted to point out that the PB-X750 (the large stock tank) actually has the worst dry mass ratio of the stock Xe tanks. The dry mass ratios of the PB-X50R and PB-X150 are 1.333 and 1.4, respectively.
-
Has anyone tested this in 1.05?
-
Quote
- VASIMR (Ar/LH2): ?
The VASIMR's challenge ought to be devising creative mission profiles to capitalize on its versatility. It should never be the optimum choice for any single application, and thus should only be worth using if you can find ways to take advantage of its ability to fill multiple roles.
QuoteLithium for MPDTs: The reason I suggeted this was that 1) I already have some models. 2) It removes one "issue", which is working an electric engine balance thing into a chemical fuel. 3) I planned to do this when I released the fusion pulse propulsion models I made a while ago. It's also the canonical fuel from the test articles that originally inspired the models.
I'm a bit leery of adding another ion fuel, due to concern for part clutter and lack of benefit to gameplay. It already feels like there isn't a big difference between Xe and Ar other than cost (which is kind of boring). Especially if all "electric" fuels are conformed to a single dry mass ratio, I worry it will be difficult to create meaningful and interesting differences between fuel types. That said, if you could outline what might set Li apart as an interesting fuel, I could certainly change my mind.
-
4 hours ago, Captain Sierra said:
Cryo Engines
If NFP hydrogen tanks cannot be properly balanced to encourage vacuum-only use (low impact tolerance, low heat resist, higher drag if possible), then the next best option in my opinion is to simply not enable fuel switching on those tanks. They're not meant to be used on launch vehicles, so why should they be able to be? Instead of trying to make the two mods collaborate gracefully, simply make them coexist indifferent to the other's presence.Higher drag is possible (though a bit tedious to implement), as I outlined in this post.
-
3 hours ago, Streetwind said:
- You will have to either drop the HydrogenNTRs patch entirely, *or* give all the NTRs super-inflated stats.
I prefer the latter. As you pointed out earlier in your post, chemical engines are significantly more effective in KSP than on Earth. It's only logical that other engines require advantages over their real-world counterparts in order to be balanced relative to chemical engines and to maintain a gameplay niche. For example, KSP ion engines have tremendously greater thrust than real ion engines. I see no reason why NTR ISP should be held sacred. However, NTRs running on kerosene just seems silly.
Quote- Engines should have very little stat adjustments to help balance tanks, because this is intransparent to the player.
I think I mostly agree, or I at least don't strongly object. However, we do need to have meaningful differences between fuel types (e.g., density, cost, maxTemp), because otherwise we might as well just have a single fuel type.
Quote- I would recommend not scaling dry mass with size. Instead, dry cost can scale with size, like stock does it. This still leaves a small incentive for using larger parts, while keeping balance relevant values tightly under control.
Strongly agree. I have never liked NFT's divergence from the stock paradigm on this issue.
Quote- Fuel/mass ratios on xenon and argon tanks, including stock tanks, are best adjusted upwards, instead of adjusting hydrogen down. Ironically this will make them more realistic...
Or perhaps, if xenon, argon and hydrogen could all meet around the 2:1 point, then NF can be fixed while simultaneously achieving parity with CryoEngines and fixing the current cross-mod exploit.
Hmm, I don't immediately have a strong opinion one way or the other. There is a certain elegance in the latter solution, I suppose.
Ultimately, I think agreement between NFT and CryoEngines should be regarded as a necessity. Fundamentally, there's no reason why the two mods shouldn't be able to co-exist in a balanced manner, without either one overwriting the configs of the other. Whether that ought to involve NFT conforming to CryoEngines, or CryoEngines conforming to NFT, I don't know. One additional point of consideration (and the principle thorn in my side when I wrote the current CryoEngines fuel-switching patch): LH2/OX configurations of stock tanks need to be included in the balancing process, and - logically - the LH2 portion of these tanks need to be consistent with pure LH2 tanks in terms of the density and dry mass ratios.
-
I just tested out the new version of CLS, and I'm confused by what I found. Customization appears to be on by default. All parts with CLS modules have tweakables for Passable, Surface Attachable, and Attachable Surface. This includes some parts that aren't even supposed to be passable at all, such as reaction wheels. I also could not find any option to disable customization mode. Clicking the CLS toolbar button only presents two options: "Allow Crew Unrestricted Transfers" and "Use Blizzy's Toolbar instead of Stock."
I tried deleting the entire CLS folder and cls_settings.dat, installing a fresh download of v1.2.0.0, and creating a new game file, but the same issues recurred. Any suggestions? -
Has anyone tested if this works in 1.05?
-
CKAN shows 0.2.10 as the latest version for me as well, and I know for a fact that CKAN's algorithm considers 0.2.10 higher than 0.2.9 (the problem occurs in the opposite situation, e.g., if a developer attempts to advance from 0.81 to 0.9). I suspect the problem is on Auriga_Nexus' end.
-
[quote name='Papa_Joe']Correct. all "customization" features added will be disabled by default. CLS will behave as before, until you enable customization. Only then will there appear the ability to alter the cls configuration of a part.[/QUOTE]
I see, glad to hear it! Thanks for the clarification. My confusion arose from the bolded section below:
[quote name='Papa_Joe']1. Customization is off by default. This emulates the existing behavior of CLS prior to the new version.
[B]1a. If a part is passable, you can change the passable and surface passable states via a tweakable on the part during assembly of your vessel (new Behavior). [/B]
1b. if a part is Non passable by default, no info is show in the Tool selector on RMB
1c. If a part is Non passable by default, the part does not contain any CLS module, unless the part had an existing CLS MM config (existing behavior).[/QUOTE] -
So, to make sure I understand: in the default mode, for parts that are passable but do not have surfaceAttachmentsPassable (i.e., most passable parts), there will NOT be a tooltip to turn on passable surface attachments?
-
[quote name='Papa_Joe']not EVERYONE is a realism or "purist" if you will[/QUOTE]
For the record, I absolutely do not consider myself a realism purist. My priority is good gameplay and immersiveness. I oppose the change not because it is unrealistic, but due to concern that it directly undermines the purpose of CLS.
[quote name='Papa_Joe']This is why i have the behavior turned off by default. You have original CLS behaior. No changes.[/QUOTE]
Perhaps I need some clarification. I understand that customization is OFF by default. However, your previous post indicates (in item "1a") that - even with customization OFF - the surface passability of a part will be tweakable in the VAB. I interpreted this to mean that any part could be "tweaked" to allow surface passability, even in the default mode. Maybe I misunderstood? Maybe it's only tweakable for parts that allow surface passability in the first place?
P.S. - Papa_Joe, I certainly don't mean you any offense. I know you're just doing what you can to make as many players happy as possible, and I'm sure the final product will be excellent, as always. -
[quote name='codepoet']I think this is a debate that has been had right from the first couple of pages of the first CLS WIP thread when it was being developed - balancing "realism" with playability and providing options for player choice.[/QUOTE]
Indeed, [URL="http://forum.kerbalspaceprogram.com/threads/68617-WIP-Connected-Living-Space-API-for-connected-habs-%28new-download-9-June-14%29?p=962248&viewfull=1#post962248"]I was part of the debate from the beginning[/URL].
I understand that there will always be differences of opinion regarding the balance between "realism" and player choice, such as which parts ought to have passableWhenSurfaceAttached or surfaceAttachmentsPassable. Fortunately, anyone who feels strongly about it can simply make their own ModuleManager config.
However, the proposed change in "1a" goes far beyond merely shifting the balance - it enables passableWhenSurfaceAttached and surfaceAttachmentsPassable for ALL parts (through a tweakable). With that change, we really ought to make all nodes passable as well (why would all surface attachments be passable but only some nodes?), and - frankly - we might as well just not have any restrictions on passability at all (as in stock behavior).
Furthermore, this change effectively removes the ability to create your own rules for surface passability using a custom ModuleManager config, because the tweakable will always be there in the VAB, which means it would not be possible for me to recreate the restrictions I prefer. -
I disagree on all counts I have wanted this update since I read about it. Modders may have a vision of what passibility they want, but this is a single player game and those who want what they want will get it regardless of what modders want. This just makes it easier than having to do it in configs. So big thanks to Papa for this update
You can have whatever passability you want simply by not installing CLS. The central function of CLS is to introduce restrictions on passability - I don't really understand the purpose of installing the mod if you also want the freedom to negate those restrictions ad lib.
But to each his own - I'm not opposed to Papa_Joe adding a "customization mode" config option for those who want it. I just want to keep "cheats" and superfluous user-interface elements out of the default mode. Basically, if Papa_Joe just removes the new behavior described in "1a" from the default (costumization OFF) behavior, I'll be perfectly happy. Players like you could still turn on customization mode and customize anything you want.
-
1. Customization is off by default. This emulates the existing behavior of CLS prior to the new version.
1a. If a part is passable, you can change the passable and surface passable states via a tweakable on the part during assembly of your vessel (new Behavior).
1b. if a part is Non passable by default, no info is show in the Tool selector on RMB
1c. If a part is Non passable by default, the part does not contain any CLS module, unless the part had an existing CLS MM config (existing behavior).
I am strongly opposed to the new behavior described in 1a. Allowing players to enable surface passability at will largely negates one of the primary features of CLS - the restriction of passability to specific nodes. Surface passability should be restricted to combinations of parts that were plausibly engineered to be attached in this manner (e.g., a BZ-52 Radial Attachment Point attached to a Structural Fuselage). Most parts should only ever be passable at the specific points where they were engineered to be passable (i.e., nodes where a hatch appears to be present on the part model).
I also dislike RMB clutter and unnecessary customizability/tweakables in general. I hope that CLS can remain a simple, low-profile mod that operates almost invisibly in the background.
On the positive side, I do really like the new (much more readable) format for CLS info in the VAB part selector.
-
Oh man, that is not good...i just forgot to remove the "v". Might it help when i remove the version v0.2.7b from the downloadable files?
Not sure. CKAN still shows v0.2.7b as the latest version. You could try messaging the CKAN people (or posting in the CKAN thread) for advice; I've always found them to be very helpful.
-
CKAN really seems to be a bit slow when it takes the updates from KerbalStuff
The CKAN problem is explained here. Basically, it looks like 0.2.7b was named "v0.2.7b", whereas your other versions do not have a "v", so v0.2.7b is still the "latest" version based on alphanumerical sorting ("v" comes after "0").
[WIP] Nert's Dev Thread - Current: such nuke, wow
in KSP1 Mod Development
Posted · Edited by Fraz86
Wider range of example values.
@Nertea Excellent. Now we just need to decide what loss rate would make such a mission suitably awkward. For the purpose of illustratuon, let's imagine a mission to Duna that will need 10t of LH2/OX (1.24t LH2, 8.76t OX) for its return trip, using cryo engines, 300 Kerbal days (1800 hours) after its initial launch. How much extra LH2 will be needed to compensate for bioloff, and what does this represent in terms of % increase of the original total fuel mass of the return vehicle?
It seems that 0.025% might be inadequate to make Duna round trips truly awkward; 7% extra fuel mass on the return vehicle isn't really a substantial penalty.
Also worth noting: the impact of boiloff will be much more significant for engines that run on LH2 only, such as nuclear engines. In these cases, a 0.025% loss rate would correspond to a 56% increase in required fuel mass (for use after 1800 hours).