Streetwind

Members
  • Content Count

    5,696
  • Joined

  • Last visited

Community Reputation

4,647 Excellent

About Streetwind

  • Rank
    Talks To Boosters

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @fragtzack Antenna range is always the square root of the product of the sender antenna power and the receiver antenna power. In short: SQRT(senderPower x receiverPower). The result is in meters. For two identical antennas talking to one another, the multiplication and the root cancel out and the result is simply that antenna type's power. For two different antennas talking to one another, simply do the math as written. For cases where one or both ends have multiple antennas, especially a mix of different ones, you first have to calculate each endpoint's antenna power correctly, which is a wee bit more complicated. Also note that this is the maximum possible range, not the range at which you get 100% signal strength. That takes yet another different calculation. More info here: https://wiki.kerbalspaceprogram.com/wiki/CommNet
  2. There is a FAQ entry for this question in the opening post, which explains the reason for there being no updates. Should Nertea get bitten by motivation one day, we'll likely learn about it by having a screenshot gallery dropped on us out of the blue, as he is wont to do with new projects. Until then, however, consider the mod indefinitely on hold, and the answer to be always "no such plans".
  3. @jimmymcgoochie Done! Will ship with a future version of NF Propulsion. Until such a time, you can manually copy the following block of code into the patch file on your computer: @PART[rcsblock-*]:AFTER[NearFuturePropulsion] { @MODULE[ModuleRCSFX],* { @thrusterPower *= #$@NearFutureCustomSettings/nearFutureThrustMultiplier$ @PROPELLANT[ElectricCharge] { @ratio *= #$@NearFutureCustomSettings/nearFuturePowerMultiplier$ @ratio /= #$@NearFutureCustomSettings/nearFutureThrustMultiplier$ @ratio *= #$@NearFutureCustomSettings/nearFutureIspMultiplier$ } @atmosphereCurve { @key,*[1, ] *= #$@NearFutureCustomSettings/nearFutureIspMultiplier$ } } } I just tested this on my end and it worked, but I'd appreciate feedback whether it works for you, too. And whether or not it causes unwanted interference with other RCS parts. Murphy's Law is never far...
  4. The RCS parts were introduced after the patch was written, and they were just never included because... quite frankly, I forgot to do so Since you might very well be the first person who has ever written any form of feedback about that patch out of their own accord in all those years, I'll try to get it fixed for you today.
  5. @Incarnation of Chaos I wasn't saying that 800s Isp is unrealistic for a nuclear-thermal rocket. We have indeed achieved this IRL, in a multi-minute burn. I meant that it was unrealistic for a hydrazine monopropellant thruster, which is what the LV-N engine in KSP works like (especially when using the instant throttle up and throttle down keys). I could mason up a wall of text about the differences in detail, but it's kinda off topic here. <_<;; As for what stats the LV-N, or a hypothetical nuclear thermal RCS, would need to have to be "realistic"... the answer is "doesn't matter". It's not about performance, it's about the mode of operation that is not represented in KSP (and probably for good reasons). For gameplay purposes, the stats as they are now are okay, and that's what matters. But it's one thing to take a proven RL concept and simplify it for the sake of playability, and another to invent a device that could never, ever work IRL (like a nuclear thermal RCS system).
  6. Nuclear rockets operate by heating propellant running through it to crazy-high temperatures, created through radioactive decay. This brings with it certain quirks and problems, like how to properly turn it on and off - after all, the propellant flow is the only thing keeping the engine from melting itself to slag while the control rods are out... The LV-N as it is ingame actually behaves nothing like a nuclear rocket at all. It behaves like a hydrazine monopropellant thruster with extremely unrealistic Isp and mass. Meaning, what you are asking of Nertea to implement is a RCS thruster running on liquid fuel with entirely handwaved, inexplicable performance characteristics. Now, this might be something that Squad is okay with doing for the sake of ease of gameplay... but, I've known Nertea for a long time now. And he's definitely not okay with this sort of thing. At least not without some compromise (see: Kerbal Atomics/NF Electrical integration). This is a science game, we can do better than handwaving! If you desire non-monoprop RCS, use the stock Vernor. If you desire high-Isp RCS, grab NF Propulsion for its electric variants. If you desire LF-only RCS... yeah, sorry, I got nothin'. But you can probably Module Manager yourself a cloned stock RCS part with its fuel type swapped out in under five minutes. JNSQ is probably not shipping adjusted physics constants, or if so, adjusts them only slightly. The thing is, stock KSP artificially inflates reentry stresses - otherwise you wouldn't get any heat and effects at all at the comparatively low orbital speeds you have around the stock-size planets. But if you increase the planet size, you're increasing orbital speeds, and therefore get more reentry heating. You can decide to adjust the physics constants to get a more stockalike heat experience, or you can decide to leave them as is due to considering higher heating factors more believable and/or an interesting gameplay challenge. Regardless of JNSQ's design approach, though, you can always use the reentry heat slider in the game difficulty settings to adjust for higher orbital speeds and/or your personal desire for challenge. It doesn't do everything you can do by tweaking the underlying physics constants, but it does help with reentry survivability when playing with resized planets.
  7. @Virtualgenius In what kind of scenario is the stock OX-Stat too large? o_O
  8. You'll have to supply a little more information than that. For example, I'm pretty sure this doesn't happen with just ReStock alone, since I've played with it in a near-stock instance a lot. So you have a cross-mod incompatibility. Without telling us which other mods you have, we cannot help you figure out which one of them causes a problem. If you read back on the previous page of this thread, you'll see that WorldStabilizer has been causing problems before. If you have that, try removing it first.
  9. One question I always look to answer when browsing planet packs and system replacers is which scale they use, in comparison to stock KSP. Admittedly it's not so easily determined when the stock planets are not there anymore, but even a rough guideline like "feaures stockalike-sized planets and distances" or "everything is half-again as large as you would expect to find in stock" is very helpful. Related would be compatibility info in regards rescaling mods. With how much hand-crafting has gone into your planets and general experience, you might want to advise people not to rescale them, or perhaps confidently state that they can be rescaled without breaking anything as long as it stays within certain bounds, or the like.
  10. Is that using the new 1.8 surface shaders, or are those still classical textures?
  11. Keep liking the doing of the math. If there hadn't been people who liked doing the math, we'd still be living in mud huts, wearing furs!
  12. I must admit that I've never paid attention to methalox stuff, so can't help you there, I'm afraid. However, you could look at the ModularFuels patch that the mod ships. It lists all the design-intended internal tank volumes. Means you don't have to calculate or guesstimate them by yourself. One thing to keep in mind is that, while liquid methane is definitely a lot less dense than kerosene, it also requires comparatively more oxidizer to fully burn. Meaning, methalox engines run a more oxidizer-heavy fuel mixture, which in turn means that the tank split is shifted in favor of more liquid oxygen and less liquid methane. Since liquid oxygen is actually denser than kerosene, favoring the oxidizer counterbalances the lower methane density, and the total required methalox tank volume increase over kerolox end up smaller than you think it would be. At least, it works that way IRL. KSP LiquidFuel/Oxidizer isn't really kerolox, it acts more like a hypergolic fuel when considering its density, Isp, and engine behavior. So I'm not sure how Nertea's methalox numbers compare.
  13. The nozzle is the bearable part of the Cheetah. The really bad stuff is everything above it. Especially that awful striped tankbutt/mount that doesn't properly match any tank. I mean, most stock parts look crude next to ReStock, but the Cheetah manages to look crude next to stock parts. It's one of my most used engines in any playthrough because of its well rounded stats and sizing, but ugh, whyyyyyy that mount.
  14. Each Near Future pack is a stand-alone download that requires no other mods to be downloaded by you. Any dependencies are included in the pack itself. NF Spacecraft in particular comes pre-bundled with Module Manager, B9PartSwitch, and a bundle of custom IVA props. It needs those three, but no others. (Unless you meant that you "need" Restock in order to have the art styles match between parts. Which I would also say isn't true, but beauty is in the eye of the beholder, and if you feel that way then who am I to tell you otherwise...)
  15. At face value, the ratio is exactly what you're looking for. Take any old liquid fuel engine: it has a PROPELLANT node for LiquidFuel at a ratio of 0.9, and one for Oxidizer at a ratio of 1.1. You just add them together. For any 0.9 + 1.1= 2.0 units of mass that the engine consumes, 0.9 units will be LiquidFuel, and 1.1 units will be Oxidizer. It's important here to read carefully: I said "any two units of mass". Because the ratio is not about the unspecific "units" of a resource in a tank*. It's about a mass flow rate. Specifically, the mass flow rate that you calculate out of the relationship between thrust produced and specific impulse. That will tell you that the engine must have a throughput of XYZ kg/s of mass per second. The ratio then simply determines what percentage of each resource makes up that mass flow. It would work just the same way with a tripropellant engine. And then you look at an electric engine, and things get weird. Remember what I said about the ratio being about a mass flow rate? Well... it just so happens that ElectricCharge doesn't have mass. This is why you cannot make a pure electric engine like an EMdrive in KSP simply by copying the Dawn engine and removing its XenonGas propellant, leaving EC as the only remaining input. Such an engine would produce no thrust, because it would have no mass flow. Instead, electric engines like the Dawn define a ratio between a massless propellant and one that has mass. But how can that possibly work out in math? Look at ArgonGas in the config snippet you quoted. It has a ratio of 1.0. Can you guess what that means? The answer: no, you can't. Because in this configuration, the ratio assigned to ArgonGas does not matter. It has no meaning. It can be literally any number you want it to be. The result is always the same: since EC has no mass, the engine will field its entire mass flow rate with ArgonGas alone. Whatever the calculation of thrust and Isp says the engine must consume, that's how much ArgonGas it eats. The ratio number doesn't matter. Changing it doesn't change the ArgonGas consumption in any way, shape or form. Nertea simply decided to set it as 1.0 because that is as good a number as any other... or, perhaps, a better number than any other if you intend to do multiplication and division with it. Because now we get to EC. It also has a ratio specified. But since the entire mass flow of the engine is already fielded by ArgonGas, it should be meaningless...? Except it isn't. Because the amount of EC the engine demands supplied is calculated off of the ArgonGas flow rate - pay attention now - measured in resource units, not mass units. Everywhere else, KSP works with mass flows; but in the case of massless resources alone, it works with resource units. As an example, let's take the stock Dawn engine, because I just so happen to have all the relevant numbers I need for it on the KSP wiki: 4,200 seconds of specific impulse in vacuum. We convert this weight-based unit into a mass-based unit by multiplying in standard gravity: 4,200 s * 9.80665 m/s² = 41,187.951 m/s ("effective exhaust velocity"). This is dimensionally equivalent to thrust divided by the mass flow rate, and the engine develops 2,000 N of thrust in vacuum, so: 2,000 N / x = 41,187.951 m/s ---> 2,000 N = 41,187.951 m/s * x ---> 2,000 N / 41,187.951 m/s = x ---> x = ~0.04856 kg/s mass flow rate. One resource unit of XenonGas is 0.1 kg, ergo: 0.04856 kg/s / 0.1 kg = 0.4856/s XenonGas consumption measured in resource units. The Dawn engine has an ElectricCharge ratio of 1.8, so: 0.4856/s * 1.8 EC = 0.87408 EC/s . But wait! Squad decided to define the XenonGas ratio of the Dawn engine as 0.1. So we have to additionally divide by this ratio to get our final number. See now why Nertea chose 1.0 instead, even if the number is meaningless for the propellant flow rate? 0.87408 EC/s / 0.1 = 8.7408 EC/s. And if you look it up in an unmodded game, that's exactly what the Dawn engine says it needs. *) However, coincidentally LiquidFuel and Oxidizer have the same mass per resource unit, so it just happens to work out to the same in resource units anyway. In this case.