Jump to content

Nertea

KSP2 Alumni
  • Posts

    4,859
  • Joined

  • Last visited

Everything posted by Nertea

  1. They're on CKAN because other people put them there. If you install via CKAN I don't give you installation support. The appropriate folder is your gamedata directory. Put the folder from extras (eg, NTRsUseLF or whatever) in gamedata. Done!
  2. Yes that is the plan currently, to move the engines, intakes, nacelles, etc to a "new" Near Future Aeronautics pack which is easy to maintain and update. The MkIV parts will stay here and enter a long term, no-longer-developed state.
  3. I am done, I will be restructuring the package in a bit to make it easier to support and for people to use but development is done for sure. Looking at the stats, there's not really enough usage of it to warrant the headache that working on aero stuff causes me.
  4. Inflatable parts do not have slots in the editor. I had to make some compromises to properly handle the IVAs and spawning from the VAB with crew inside conflicted, weirdly, with making the IVAs spin the right way (hard to explain).
  5. Thanks, it really helps to have these with my limited time if I have a workflow where I can fix something, test and recycle quickly! It sounds like some kind of problem with Dynamic Battery Storage but who knows really.
  6. Need more data. Specific reproduction steps with only NF mods installed please. Ugh, I fix this every KSP version. Looks like 1.4.4 broke my hack. I'll look into it... Can you define the why more closely? Is the module showing up ingame? How are you measuring the output? As with the other bug, please detail your reproduction steps. As an aside, I've been neglecting the forums, my apologies. I'll update things to 1.4.4 as soon as I'm sure squad won't be dropping a hotfix for it instantly.
  7. Probably not at all, that'd have to be on BD's end to affect the damage stat field.
  8. CryoTanks repository, readme.md Yes it should be doable. You would just need to add the appropriate module.
  9. Uh, you could try recompiling the dll for 1.2.2, but I think it uses some 1.3+ era features so success is not certain. Probably, but not supported. I have no plans to do 1.875m parts at the moment. I don't have MH and I don't intend to buy it. I'm assuming you mean like.. hide the windows, not toggle the lights? That's a large amount of work, probably won't happen.
  10. EVA an engineer for a dangerous mission. He'll need to be Level 5. You also cannot repair a reactor if it's below 10% core integrity, and you cannot repair it above 75%.
  11. Well, why make them use EC? They have no functionality at all without another mod beyond aesthetics, so I'd think it would be up to the LS mod patch to do the EC adding part. Yeah I'm trying to find time to test and release a small fix first.
  12. Where are you getting that from? A really old version of NFE? There's no reference to HC anywhere in the mod anymore, no dependencies at all.
  13. I don't think you got my rationale quite right. But like I said.... *points to ModuleManager*
  14. Perhaps the better question is something along the lines of "why add LqdOxygen"? If the only answer is realism then that's insufficient. Time for a long blurb. In my current gameplay paradigm (which has evolved over time, but is stabilizing), a new fuel type only brings value if has particular gameplay concepts that are different than other fuels'. A lot of my mods did not build on this, which is why it's a bit of a mess in NFP (fuels that shouldn't exist by this paradigm). The effective gameplay (in a non RO context) ways of differentiating fuels: Density: affects ship design significantly in terms of ship size ISRU factors: affects mission design if the production chain for the resource differs or if it is limited in presence Boiloff: affects mission deign and adds ship design-based mitigation strategies Transport factors: transferability and similar affect how the resource is actually used (eg solid fuel) Cost: a poor differentiator because a) KSP cost balance sucks and b) sandbox doesn't care Tank mass ratio: a poor differentiator as it is effectively a scalar on mass and Isp. Engine selection: a poor criteria but should be mentioned because it drives reasons to use the fuels. For example, Oxidizer is a bit more valid of a fuel because LiquidFuel can be used in some cases without Oxidizer. Typically IMO a new fuel type should not be added unless it provides a new challenge when used. Ideally it should hit at least 2 of these factors. My current fuel lineup looks like this, and you can see why I am only partly happy with it based on the above: LH2: Fairly good differentiation with 2 strong and 2 weak factors (boiloff, density, engine selection, mass ratio) Argon: moderate differentiation, probably shouldn't exist - 1 strong, 2 weak (ISRU, cost, engine selection) Lithium: Poorly differentiated, should never have added it (ISRU, engine selection) Uranium: Decent (ISRU, Transport, cost, mass ratio, engine selection) Now adding LqdOxygen and looking at it in these terms: Similar density to oxidizer so not great Presumably same ISRU properties as LH2/Oxidizer/LF. if different, would need more models/work Boiloff as LH2 - slightly different as presumably slower Same transport factors as any liquid fuel Cost not considerably different Mass ratio not significantly different to Oxidizer Engine selection limited to LH2 engines - already a gating factor to LH2 engines The only real reason that works is engine selection - and to effectively use this, you would need to use this resource in other engines that are non-LH2, because said engines are already gated by LH2. It is my considered opinion that using LH2 in these engines is basically only a naming change and doesn't really affect gameplay. Hope that answers your question :D. That being said, the boiloff code completely supports multiple types of fuels and is customizable to do whatever you like, as per one of the items in the FAQ specifically addressing LqdOxygen.
  15. Unfortunately I don't have time to do this, but I would accept community contributions with no problem. I'm glad the work I did optimizing pays off.
  16. FAR problem. Had a look a year ago, couldn't see anything wrong, asked FAR peeps to provide information on why it might happen, never got an answer. What, that secondary mod goal of education actually worked? :O
  17. I should migrate those pictures into the OP album for sure.
  18. DBS is a workaround for problems with stock's resource consumption management at high time warp. I'm pretty sure I worked with @Blackline on support for RB in DBS so it should be cool.
  19. Typically KSPI balance is of a different... style than most of the rest of KSP. They might be similar, they might be not in the case *shrug*.
  20. Most packs have been updated to 1.4.3. NFLV will follow in time. NF Propulsion 1.0.1 KSP 1.4.3 Updated B9PartSwitch to 2.3.0 Switched versioning to mix/max specification Additions/fixes to Russian translation NF Electrical 0.10.1 KSP 1.4.3 Updated B9PartSwitch to 2.3.0 Switched versioning to mix/max specification Fixed a bug with fuel transfer that caused it to basically never work NF Solar 0.8.11 KSP 1.4.3 Switched versioning to mix/max specification NF Construction 1.0.2 KSP 1.4.3 Updated B9PartSwtich to 2.3.0 Fixed lower stack node of S-MINI Adapter being too low Fixed lower stack node of Annular Truss Docking Connector being too low Revised exact positions of nodes on Spinal Truss pieces Fixed slight offset on Pressurized Octo-Truss Mini Fixed tiny misalignment on truss mesh of some Octo-truss variants Fixed lower node height on octo-truss octo-port Fixed tiny misalignment on hollow truss mesh of some Hex trusses Fixed old window texture emissive for pressurized parts being included instead of new one Fixed misalignment of meshes on angled octo-connector models Fixed misaligned mesh on replaced Rockomax Micronode Fixed localization error with Planar micro trusses NF Spacecraft 0.7.9 KSP 1.4.3 Updated B9Partswitch to 2.3.0 Updated NF Props to 0.3.3 Switched versioning to mix/max specification Disabled drag cube recalculation for B9PS-using engines to work around stock issue name = the EngineID of whatever engine you want to modify. In this case it's Argon but due to a bug in KSP, the localized version of the engine that shows up ingame is also the in-code version. It doesn't affect KSP, it does affect KER.
  21. Minor update deployed: KSP 1.4.3. Also versioned winder, so will be valid until 1.4.9 and Squad fixes their crap.
  22. New version, 3.3.2 KSP 1.4.3 Added Italian translation courtesy of Simog Modified the structure of the Aero branches to reduce arrow overlap If I got the KSP_VERSION_MIN and stuff right, this should stay valid until 1.4.9 from 1.4.2
  23. Right. Well, it appears that there is actually no EL patch yet, so you get to define whatever you like!
×
×
  • Create New...