Jump to content

NathanKell

Members
  • Posts

    13,406
  • Joined

  • Last visited

Everything posted by NathanKell

  1. v0.9.19 is OUT! *Update to 0.25. *Implement procedural cost support (needs balancing) *Fix RO patch, add another RO patch (for techlimits) *Attempt to work around NaN bug for procedural decouplers (needs more testing) NOTE I don't play stock. This is well known. That means I need your help balancing costs of the various items. So...let me know!
  2. Also, if this is code oriented, I would like to move it to the Plugin forum; I am not doing so now, however, in case you (paul23) mean it more generally (i.e. to include making parts too).
  3. Not actually true, the Cargo bay shielder is there, just not in use by any parts.
  4. What I forgot temporarily is that while KSP has too-high Isps for most (but not all) its chemical engines, those engines *also* mass about 4x what they should, as do tanks. So it evens out. If you want realism-to-scale, use RealFuels. That will make both masses and Isps realistic.
  5. The problem wasn't in the post (which was clear), it was in the zip. Without source they were indistinguishable, except for decompiling, from the releases on rbray's repo. Apologies if that seems obtuse.
  6. Best bet right now is to do some C# tutorials to familiarize yourself with C#, then following the tutorial on the wiki to get your environment set up, then follow along TaranisElsu's Example Projects
  7. Realistic for the stock system would be way, way less delta V than is required even with FAR, since Kerbin shouldn't be that dense or, even if it is that dense, have that much atmosphere. :] If you want to stay with the Kerbol system as it is, then for realism (rather than difficulty, which is not the same thing) you should either keep Isps as they are, or maybe decrease them across the board slightly (since 370, let alone 390+, is way too high for [sane] storable propellant; try .85 multipliers for both). The "FAR to stock" thing is if you want engines to be bad, unrealistically, in atmosphere, in order to have to build larger rockets.
  8. .NET dlls are compiled to CLI, not anything deeper, so they can run on any architecture with a .NET interpreter (notionally). KSP includes its own mono interpreter, and pretty much all KSP's code is in CLI dlls, so our dlls target dlls that are themselves architecture-agnostic.
  9. For the record, that's what we tried, for .24, and it didn't work. And .25 is about 1/4 as stable. (we = modders; MFT did not have a giant warning, but TACLS sure did and that didn't help any)
  10. Whether or not sarbian claims credit, it would only make sense to mention (in the zip) that the release you've released wasn't released by rbray, and in fact includes code that isn't his. Attribution isn't only about giving credit.
  11. FAR reference area is for *all* wings, including horizontal and vertical tails. In real life, only main wings' wing area is used. So your wing loading is more like 400-450kg/m^2
  12. B9 v5.2+ should have its own built-in RF configs. I'll test and check in with Taverius if things aren't working right. You are using B9 v5, not v4, right?
  13. medsouz: those files are going to need some text (in them) saying they're by rbray89 and sarbian, as all posted addons must conform to the addon rules (and in particular follow the license of the work from which they're derived).
  14. Bonvi: welcome to the forums! Please make a thread in the correct Support forum (Support - modded installs) and I'm sure we can get you up and running. Athlonic, thanks for making my life easier.
  15. FlowerChild, that makes sense. Squad doesn't often explode parts, so it's understandable there's bugs with it re: struts and lines. Starwaster: thread title date fix splurg....
  16. FAR is perfectly compatible with 0.25, as the OP says. As the OP also says, it does *not* work on 0.25 KSP Windows x64, for well-stated reasons. Please read the *entirety* of the OP when you download a mod.
  17. The guidelines require: 1. Your complete KSP version 2. The correct logs 3. A list of all your mods with their version number 4. Replication steps. An example is even included, which you can check against. In this case I suggest trying to replicate the issue with a stock (unmodded) KSP install. If you can, it's a stock issue.
  18. If you change all the @PART[...] to @PART[...]:NEEDS[RemoteTech] then raidernick can include the file in the main download and it will only activate when RemoteTech is installed.
  19. Dragon01: that reminds me, once .25 calms down I need to make that plugin...
  20. It is best practice to make all changes in Module Manager patches, since then you are not redistributing the original (or original modified, aka derivative) cfg. Any addon you post is considered an addon and must follow the addon rules. If the changes you are making are significant (as in Realism Overhaul and FASA) it's best to get the original author's permission even if all you're distributing is a Module Manager patch.
  21. This is indeed the right place. If you want to get all engines for a vehicle, you'll want to search through all parts in the vessel's parts list, and check each one to see if it has an engine module (ModuleEngines, ModuleEnginesFX, or any other engine module). Category won't help (the LES is in Utility, for example), and won't catch any parts that had a module added dynamically.
×
×
  • Create New...