Streetwind

Members
  • Content Count

    5,512
  • Joined

  • Last visited

Community Reputation

4,414 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. Make sure they are researched. If you have added the mod to an existing career or science mode save, the parts will not be unlocked by default. Even if you have all the nodes in the tech tree already. In such a case, if you go into the R&D building, you'll see that some of the nodes show up marked with little numbers, denoting locked parts within them. Click these nodes and "research" them again (at no cost), and you will have your parts. If that is not your issue, though, you'll have to supply more information. "It doesn't work" isn't exactly the most precise description of a problem...
  2. @MaximumThrust Thanks for the info, I'll keep it in mind in case we get more TAC-LS related questions.
  3. @Xurkitree - Not a bug. That's how KSP works. When you shift focus away from a vessel, it no longer does anything. It doesn't produce thrust, it doesn't generate power, it doesn't consume power, it doesn't process anything, the heat simulation is offline, collisions do not happen, and so on. For all intents and purposes, it stops existing entirely. There are way around this, although they are sort of awkward. For example, if you have a stock ISRU module onboard, you can run it while the vehicle isn't focused. How? Well, the moment you switch back to that vehicle, the simulation plays catch-up. It remembers how long ago you left it alone, so it will do all the processing for the missing time at once when you come back to it. The heat simulation does that same. The reason this is awkward is because it isn't precise - how does the catchup routine know how the illumination of your solar panels changed while you were away? How does it know that the fuel cell you were using would not have had enough fuel to keep going that long? It just doesn't. Also, when the heat simulation catches up, you sometimes get huge temperature spikes that can actually damage parts on your spacecraft. Another way around this is doing real background processing for all existing vessels. There used to be a mod that did this, but it was only really compatible with stock and a very small selection of modded parts. Every single part that wanted to use it had to be individually patched to be compatible. TAC-LS for its part is doing its life support calculations independently from the vessels. It just remembers that vessel X has this amount of resources and uses them at that particular rate, so it determines that it needs to send you a warning in so many days. The vessel itself still doesn't actually consume or calculate anything; instead it will play catch-up when you load it again. Now, I haven't touched TAC-LS in a long time, so I don't know how sophisticated its tracking of vessel resources has become. Maybe it is able to recognize if a vessel has positive EC generation and can factor that in. But in that case, the reactor should work. Or it doesn't have this capability, in which case no source of power (not stock solar panels, not fuel cells, not RTGs) would work, and you would get the same warning no matter what. Or, it is selective about which power sources it accepts - for example fuel cells might not be accepted because they can run out of fuel without TAC-LS noticing. In that case, you'll have to talk to the TAC-LS people and ask them to make NFE reactors a trustworthy power source.
  4. @Dafni This is the thread. The pods are part of Near Future Spacecraft's 1.5.x release.
  5. I have no idea. Never used Tweakscale myself. But you can probably find an answer to this question in the Tweakscale mod thread. Note that it's not as easy as increasing data storage and calling it a day. A mobile lab scales its operating speed with amount of data stored... the absolute value, not a percentage of capacity. So by increasing the data storage, you increase the speed at which the lab runs. That's definitely a balance consideration.
  6. There are no official patches supplied. You can, however, make your own. Please note that some of the features may not be fully Tweakscale compatible. The plugin isn't written with resizing in mind. When it works - great. When it doesn't work - well, then it doesn't. You can look this up in the config yourself, by checking the velCurve node inside the airbreathing ModuleEnginesFX node. There are a number of keys inside that node, each of which has between two and four numbers assigned to it. The first number is the mach number, the second number is a thrust multiplier, and the third and fourth numbers are irrelevant to you (they smooth out the curve). That way you can get a rough idea at which speeds the thrust multiplier starts growing noticeably. If you want more detail, you'll have to find a way to draw the curve from its keys, so you can see the slope.
  7. The optional patch is just that, optional. You can add or remove it at any time without breaking your game... unless you already have spacecraft with hall thrusters in flight. Then you will obviously render those vessels incapable of firing their thrusters. I don't know the contents of your GameData folder, so I don't know where you put the patch. You'll have to find it and remove it. You can see what it looks like by opening the Near Future Propulsion download archive and looking into the Extras folder.
  8. Because there is room in the tech tree at that point. The tree is merely a selection of options for the player to pursue. Whether to unlock the engines or the tanks first - or indeed, whether to even progress along either of those branches at all - is left to each individual player to decide. And from a perspective of believability, constructing a pressure vessel is far easier than constructing a device capable of producing a jet of ionized matter without destroying itself in the process. The tanks are placed in locations where they are within conceptual reach of the engines in terms of overall gameplay progression, but they are not contingent on researching the engines first. We're leaving the eternal chicken-and-egg question of what came first up to the player. Also, note that there is a big difference in part distribution between using the stock tech tree and using CTT. I don't know which one you have, but, using the stock tree is not recommended. There are not enough high-end nodes to fit all the parts, so they end up crammed together in suboptimal places. Because you installed the optional extra patch that switches hall thrusters to xenon use
  9. Anywhere inside GameData is fine. This patch is simply a Module Manager config which activates the functionality that's included in the NF Electrical plugin. As such, KSP will find it regardless of the exact path. Personally, I tend to just drop the folder in as-is.
  10. Thank you for the sentiment, but it's not my mod. Nertea made it! I just answer questions in the thread.
  11. The latest versions are compiled for 1.5.x and ship dependencies compiled for 1.5.x. However, you can still download the previous 1.4.x versions on SpaceDock and Curse just fine.
  12. No intentional changes IIRC, though without you mentioning what version you came from and what version you use now it's impossible to say for sure. In what situations is your craft overheating? Time warp? Loading an unfocused craft? Normal flight? Which radiators are you using for which reactor? In case of fixed panels, are they all turned on? Can you replicate the cooling issue if you use the same reactor and cooling configuration in a barebones instance with only NF Electrical and its dependencies? I have no idea what you mean. Kerbal Engineer has always worked fine for me. Since I am slow, explain with pictures, please?
  13. Well, xenon is a stock resource, and Squad chose to be that specific in naming it. Besides, there's no harm in some variety. While it's easy to make all NFP engines run off of xenon and keep their stats as they are, having a small selection of different fuels is conducive to immersion and depth. It's a perfect excuse/explanation for having different plume colors, for having certain stat distributions, for having different tank models, for having different ISRU methods, and so on and so forth. However, with each additional fuel you add, that benefit greatly decreases. At some point, anything you can add invariably will become too similar to what you already have. And producing assets takes a lot of time and effort. If there are already three different tank designs, is it really worth adding a fourth? Stuff like that. Realism Overhaul goes all in on the fuel variety, but a.) it does so in a different manner, or example the look of tanks doesn't change based on what's in it; and b.) It does this because it is Realism Overhaul. That's literally its purpose. It's required to correctly replicate historic launch vehicles. Meanwhile, a mod like NF Propulsion is gamified, and meant to be close to stock. The design decisions behind it follow game design theory instead of a desire for realism.
  14. I highly recommend that when hunting for bugs, you should do so with the help of a dedicated instance that only includes the mod that you are investigating and its dependencies. First, you devise a way to reproduce the issue reliably in your gameplay instance where you first noticed it; then, you follow those exact reproduction steps in your minimal testing instance. If you can reproduce it there in the same way, great! Submit a bug report. If you cannot - well, there's a cross-mod conflict somewhere. Your next step would be backing up your gameplay instance and then pulling out mods (usually via the "take half, leave half" method) until you find the group of culprits. What you are looking for is the so-called Mangalyaan Maneuver. In a nutshell, this maneuver is a special variant of periapsis kicking, where you start in a low parking orbit and, through repeated short burns at every periapsis pass, lift your apoapsis higher and higher over time, until you reach escape velocity. The special part comes in when, based on where your apoapsis has to be during the transfer window, you calculate where your apoapsis must be weeks or months prior to departure. That way you can periapsis kick over long periods of time with spacecraft that need many, many passes due to their very low TWR, but still end up hitting your ejection angle exactly on the final escape burn. There used to be a great guide here, which really made it easy to grasp and pull of ingame with KSP's limited toolset. Unfortunately, the helpful pictures are broken, and the author hasn't been on the forums for over half a year. Still, the text makes it reasonably clear (at least to me) what you have to do. Give it a try with a probe - after you pull it off once, you'll never struggle with it again. (I recommend setting yourself a dV budget for every periapsis pass, such as 100 m/s per burn. How much you choose depends on your TWR - it should be possible to complete in no more 4-5 a few minutes at most.)
  15. When designing a typical rocket, you pay attention to your mass ratio (wet mass to dry mass) and your thrust-weight ratio. With electric engines, there's a third thing you should consider: specific power. In other words, how many Ec/s you can generate for a given investment in dry mass. This is important because electric engines give you this tradeoff in that they allow exceptional dV at the cost of having very bad TWR. But what if, in order to run them, you have to pack on a huge amount of dry mass just to produce power? Then you lose some of the dV advantage, while your TWR falls even lower. You want to avoid this. Therefore, you should examine your mission profile and decide on what kind of power solution you want to go with. On small expendable probes this is usually not such a big factor, but it definitely becomes one on larger ships that you want to be able to return home. Here's a very rough rule of thumb guideline; the exact numbers and details may vary ingame (especially if you have other mods installed): Solution Specific Power Advantages Disadvantages Thermoelectric 10 to 20 Ec/s/ton Simply just works everywhere, no ifs or buts Worst performance Somewhat pricey and late in tech tree Might decay over time (with optional patch) Fuel Cell Array up to 75 Ec/s/ton Works everywhere Affordable Fuel is limited and very heavy (reduces specific power) Array is too large for small probes Small single fuel cell performs massively worse than large array Solar 65 to 120 Ec/s/ton No fuel usage Specific power increases closer to the sun Spacecraft must be able to align panels to sun during burns Specific power decreases away from the sun Might require a lot of area for high-end engines Nuclear 100 to 250 Ec/s/ton Compact and powerful Works everywhere Extremely low fuel use Extremely expensive and late in tech tree Needs dedicated radiators Fuel is limited and very expensive Might break if mishandled Trickle charged capacitor buffer many hundreds of Ec/s/ton Best performance Relatively cheap and accessible Manual discharge control required during burns Burn duration limited by size of buffer Wait time between burns Needs a different power source to go with it Generally, the more you rely on storage - especially if that storage is capacitors - the higher your specific power becomes, but the lower your maximum full power burn time becomes. Since electric engines need long burn times, this needs to be carefully considered during spacecraft design. However, if your storage solution becomes so large that it equals a large power production solution in mass, you might as well just go straight for that instead.