Jump to content

undercoveryankee

Members
 View Profile  See their activity

  • Posts

    1,050

  • Joined

  • Last visited

 Content Type 

Everything posted by undercoveryankee

  1. undercoveryankee
    Yes, 0.25 broke TreeLoader. There's a community ModuleManager patch a few pages back that moves the remaining parts and upgrades into the remaining nodes, or you can delete TreeLoader and install the new TechManager plugin to bring the custom tree back.
  2. undercoveryankee
    The thrust is nonzero. Meaning that with nearly infinite patience and perhaps Principia for multiple-gravity-source low-energy transfers, you could eventually get anywhere with basic fission reactors and MPD thrusters. In real life, the Dawn probe currently traveling from Vesta to Ceres is doing roughly that: achieving about 10 km/s delta-v using an ion engine, solar power, and a lot of patience. In practice, electric thrusters don't become fun until you have a higher watts-to-weight ratio (beamed power, fusion reactors, or solar panels very close to the sun).
  3. undercoveryankee
    Sounds like @Fatchicken has ships using a release of ZodiusInfuser's parts that ran with IR 0.16. Will the current version of ZodiusInfuser's parts (or any version compatible with current IR) be compatible with those saved ships?
  4. undercoveryankee
    The "ratio" parameter gives the amount of that resource used in proportion to the other resources used. So in the config you quoted, where you have a mode with EC 14.5, MP 0.1, that would mean 14.5 units of EC for each 0.1 unit of monoprop. To convert that to EC/s at full throttle, you would first calculate the total flow of all propellants in kg/sec from the engine's thrust and Isp, then use the resources' densities to figure out how many "units" of 14.5 EC and 0.1 MP per second it would take to equal that mass flow rate.
  5. undercoveryankee
    If you have ships in your save that were built with older versions of PF (when each base size was a separate part instead of one part with tweakable size), the "deprecated" folder contains hidden versions of those old parts to allow those ships to load. If all of your ships were built with the tweakable-size parts, you don't need it.
  6. undercoveryankee
    The stock "Explore <body>" contract has a milestone for getting science from the body's SoI that can be completed on a flyby, and doing that unlocks the stock "Science from <body> orbit" contract which I remember could also be done on a flyby. Offering a separate flyby contract before the stock contracts would make the overall progression look less polished. It would be nice to have the flyby be its own contract that appeared when you were likely to be able to do it instead of waiting for the body to come up in the stock progression, but it would also weaken stock's bias in favor of manned exploration. (And with RemoteTech, you're about ready to start sending manned missions before you unlock the long-range antennas.)
  7. undercoveryankee
    It is. http://forum.kerbalspaceprogram.com/threads/98293-0-25-TechManager-Version-1-1?p=1506287&viewfull=1#post1506287
  8. undercoveryankee
    Part assignments for Interstellar are something I could do if Fractal doesn't. Keep the playground growing, and if Interstellar has to be dragged kicking and screaming into the Century of the Fruitbat, that's what the community will do.
  9. undercoveryankee
    I only posted to the obsolete thread because having replies on both of them was enough to confuse me. I'll see about getting the old one closed.
  10. undercoveryankee
    Just posted a minor update at https://www.dropbox.com/s/sz69k94ik6...41026.zip?dl=0 . Tested on 0.25 with Interstellar 0.13 and community fixes from the Interstellar thread, SCANsat 8, and today's USI experimentals. Changes from the last update: Added :HAS[!MODULE[sCANsat]] to the SCANsat config for the MKS planetary survey camera, so you won't have duplicate SCANsat modules on versions of MKS that already include the change. Added a fuel mode for thermal rockets to use NearFuture/CRP LiquidHydrogen now that FTT also includes tanks and engines for it.
  11. undercoveryankee
    Just posted a minor update at https://www.dropbox.com/s/sz69k94ik6y4c07/KSPI_CRP_20141026.zip?dl=0 . Tested on 0.25 with Interstellar 0.13 and community fixes from the Interstellar thread, SCANsat 8, and today's USI experimentals. Changes from the last update: Added :HAS[!MODULE[sCANsat]] to the SCANsat config for the MKS planetary survey camera, so you won't have duplicate SCANsat modules on versions of MKS that already include the change. Added a fuel mode for thermal rockets to use NearFuture/CRP LiquidHydrogen now that FTT also includes tanks and engines for it. This thread is obsolete; anything further will be at http://forum.kerbalspaceprogram.com/threads/94876-0-24-2-0-25-Community-Resource-Pack-integration-for-KSPI-0-12-%28ORSX-version%29.
  12. undercoveryankee
    SCANsat 7rc5 or 8 will scan any resource that has a scanner part defined and an ORSX map. SCANsat stopped trying to interact with ORS when ORSX was added, but SCANsat doesn't care if you also have ORS data for one of the ORSX resources it's looking at. I add ORSX definitions for the resources that Interstellar provides through ORS and configure the Interstellar gamma-ray spectrometer as a SCANsat sensor for them. That functionality works on either 0.24.2/SCANsat 7rc5 or 0.25/SCANsat 8 with the corresponding versions of Interstellar.
  13. undercoveryankee
    I think all the code to do that is already in the plugin. Just need to give the upgraded AM reactor an operating mode that produces charged particles.
  14. undercoveryankee
    For an idea to be copyrightable, it has to have some minimum level of originality. My theory, more specifically, is that if the relevant code is short enough that it's impossible for one working implementation to substantially differ from another, then that code alone would not have enough originality to be protectable. It's not that generic "practical considerations" can override a copyright. It's that the specific nature of the information we would need – (probably) a short sequence of function calls whose content is dictated by the interfaces being called – allows for a clear distinction between using that information and using anything original to the modder.
  15. undercoveryankee
    Also, since PART is a node, you need a set of curly braces afterward even on a delete command. So "!PART[selectors] { }".
  16. undercoveryankee
    The question on everybody's mind is whether someone can write their own code to add tree nodes using the same technique that TreeLoader used, given that the TreeLoader source is published "for reference only" all other rights reserved. In other words, is the basic information on how to add tree nodes subject to copyright protection? I personally believe that a modder cannot hold copyright over information about how Squad's code works, because the modder didn't create that information; Squad did by writing the code in the way it did. If you were trying to get creation of new nodes working in ATC and you compared your code to TreeLoader to figure out what about Squad's code was causing your code to fail, you could revise your code based on what you learned about Squad's work without violating the TreeLoader copyright because you wouldn't be using any information that the author of TreeLoader actually created. As long as any similarities in the final code were necessarily dictated by the interfaces that Squad provided, you would be legal.
  17. undercoveryankee
    That looks as expected. The fix doesn't create the nodes that TreeLoader would have created in the previous versions (there is no currently working way to do that); it just moves the parts and upgrades into the nodes that are available. Make sure that you have completely uninstalled TreeLoader, in case TreeLoader is still trying to move parts into the nodes that it failed to create, and you should have all of the parts even though you have fewer tech nodes.
  18. undercoveryankee
    Do you have B9 installed? It's reported that B9 applies an even sharper nerf to the turbojet's top speed than FAR does. I think 3.4 or 3.5 was about where B9's turbojet curve tops out.
  19. undercoveryankee
    Radiators upgrade in Experimental Electrics, which is a stock node, so I didn't change them when I wrote the first version of the tree fix. Since I moved some reactors into the 550-science tier that you wouldn't get until after Experimental Electrics otherwise, it wouldn't be a bad idea to move that upgrade earlier. The code to put the radiator upgrade in MetaMaterials would be something like @PART[*]:HAS[@MODULE[FNRadiator]] { @MODULE[FNRadiator] { @upgradeTechReq = metaMaterials } }
  20. undercoveryankee
    Fractal set most parts' TechRequired to nodes that are in the stock tree and then wrote his tree.cfg so TreeLoader would move them to the proper places in the extended tree. Because that much compatibility was baked into the design, the no-TreeLoader ModuleManager patch is only a few dozen lines. Wave shipped a tree.cfg that creates the extra nodes but doesn't move any parts around and listed the TreeLoader nodes directly in parts' TechRequired entries. I was in favor of Wave's approach at the time because it's cleaner and preserves the possibility of changing parts' TechRequired with ModuleManager, but the conversion to the stock tree is going to be a longer patch.
  21. undercoveryankee
    Current version works with SCANsat 8, because there haven't really been any changes to SCANsat since 7rc5. I haven't seen any breaking changes with Interstellar, either. I've been dragging my feet on claiming to be compatible in the OP because I'm still relying on testing done by other people, but I'd encourage you to try the current release on 0.25 and let me know if anything doesn't work for you.
  22. undercoveryankee
    WaveFunctionP packaged the folding Alcubierre with KSPI Lite, so if you thought of KSPI Lite as the "previous version" you might have gotten used to having it pre-packaged. There's a package linked from the Alcubierre page on the Interstellar github wiki. Not quite a drop-in, but close (change name and TechRequired to suit in each part config, and fix the scale factors if they're affected by the changes in 0.25).
  23. undercoveryankee
    No. The resources don't exist on planets that don't have an ORS map defined. If the planet author hasn't provided ORS maps, they're not that hard to set up. Look at the configs for the stock planets and use SCANsat if you need a height map.
  24. undercoveryankee
    It's one of the changes made in my Community Resource Pack integration pack. If you don't have CRP and want to change just Water, you'll delete the parts of the pack you're not using and change any :NEEDS clauses on the water-related patches. I thought I had posted an example of a water-only config somewhere, but I'm having some trouble finding it again.
  25. undercoveryankee
    Currently, white suits and orange suits both follow the same setting for permadeath. The idea of having permadeath for the white suits but having the orange suits come back is pretty common though; common enough that it may be based on the behavior of a past version. Whatever version adds female kerbals should have some recruited by default for the benefit of players who don't recruit white suits until they need more than three active kerbals, and giving both the old and new starting kerbals the orange suits is probably the easiest and least controversial approach. Maybe add a few more male orange suits named after well-known astronauts and cosmonauts while they're at it.
×
×
  • Create New...