Search the Community

Showing results for tags 'resources'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • The Daily Kerbal
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website
  • KSP Pre-release
    • 1.2.9 Pre-release Branch
    • 1.2.9 Pre-release Modding Discussions
    • 1.2.9 Pre-release Bug Tracker


  • Developer Articles

Found 18 results

  1. This is the development thread of KSP Interstellar Extended where new development can be discussed or request can be made. For any question on existing functionality, ask and discus them in the new Release Thread of KSP Interstellar Extended For KSP 1.2.2 Download latest release 1.13.8 from Here source: Github If you appreciate what I create, please consider donating me a beer you can make a donation by PayPal or support me by Patreon To Do Improve realism magnetic nozzle, increasing maximum Isp and making it depend more on reaction charged product speed, which should significantly increase Isp for Beam core antimatter Future Note that do not consider myself the person that have to determine the future of KSPI, it's just that nobody else seems to want to do it. I would be more than happy to share that responsibility. Anyone that actively want to develop KSPI is free to do it. It would appreciate it as it would allow me to focus more on advanced features I have ideas about. The simply truth is, KSPI is too big for a single developer. I don't have the time nor the skills to implement everything that it deserves. I'm especially frustrated about the lack of artist support. Many of KSPI models and effects look dated and ugly compared to more resent mods. There have been some artist and programmers offering their help but they often go AWOL after a short time. I'm not sure If I can keep it up myself indefinably. I would prefer to create a team of developers that works on KSPI together. I guess that's the only way to ensure KSPI Future
  2. The Community Resource Pack is a clearinghouse for common resource configurations as well as resource distribution configs for the stock resource system. It gives modders a toolkit of commonly used resources to play with, and helps us all work together in the same resource playground. The CRP has two goals: Goal 1: Establish a common set of planetary resources. To make this happen, CRP will include a consolidated list of distinct resource configurations designed to be used with the stock resource system. Examples include Water, Substrate, Uraninite, and others. Goal 2: Avoid surprising our users by stomping over resources. When mods both define the same resource, bad things can happen for the player. So the CRP pincludes a bunch of resources that modders have agreed to consolidate on. Including ones from Karbonite and MKS/OKS (of course), Universal Storage, KSPI-E, RealFuels, Near Future Technologies, and others. Additional mods are supported where we've decided not to break their stuff, even though they are not (yet) active participants in CRP (kinda like santa claus handing out gifts). Examples include EL (for RocketParts), and TAC-LS (for life support stuff). If this goal is achieved, even for the few dozen resources we already have listed, I'm be thrilled, since being nice is a lot more beneficial than randomly stomping on things. So if you're sold, head on down to the bottom of this post for links and goodness. If you are not sold, read on. "I am sad! you're trying to control my stuff!" Not really. I just don't want to break your stuff, and I hope you don't want to break mine. All of this is totally optional, if you don't wish to participate, then peace out and rock on. "There's no way this will ever work, people can't agree!" I dunno, I have enough already agreeing that I am pretty darn happy. Given the current level of adoption and cooperation, I think we've landed in an excellent place. "But I don't want you mixing space cows in my ultra-realistic electrolysis sim!" Then don't use space cows. But maybe someone wants to have a nuclear-powered space cow RTG or something. In which case, you probably don't want them breaking your electrolysis sim. "But... you can't mix space cows and Plutonium-239!" Sure you can. Maybe you don't want to in your mod, or in the mods you select for your own save game, but people are going to do all kinds of crazy stuff. And I expect you'd prefer it if your Plutonium-239 to not suddenly triple in mass mid-flight because SuPaKerBaL9000 modified the AAA_SpaceCows mod you downloaded for your kid's save to triple the mass of Plutonium-239. "What about disparities in resource density and atmospheric pressure, or gas compression?!" Here's reality. Most of us just want to play a game. Hence, CRP has no opinion on units, compression, cost, densities, etc. - that's up to the mod creators. And if something is good enough to be adopted by a couple of mods, then it's good enough to join the club. In the end, this is curated. But the only considerations on the table are ensuring stuff plays well in our space lego game together, not in nitpicking physics or chemistry, and most certainly not in dictating how stuff should be measured. "But what if I want my own resources?!" Go for it. CRP does not dictate what resources your mod has or how you use them, just that you don't create ones that conflict with ones already there in CRP. "But this is more work for me! I am sad!" Actually less. Just include a dependency like you would Firespitter or any other similar mod. Shop for resources. Done. But hey, if you'd rather have SuPaKerBal9000 wreck your mod, rock on. "I'm still sad! I won't use this!" Ok that's fine too - peace out "Ok I'm sold.. how do I use this thing in my mod?" Since CRP is based on the stock resource system, it's super lightweight! Include the CommunityResourcePack folder with your mod, and you're done. And please don't modify any of the configs you download either, as that kinda defeats the entire purpose, and is downright mean Lastly, don't supersede CRP resources with your own definitions for any of the included resources - that's almost as bad as modifying them. The whole point of the club is that we all play nice. If you want in the club, awesome! But please don't join the club just to trash the clubhouse Mods that bundle CRP MKS/OKS Near Future Technologies Karbonite Asteroid Recycling Technologies Freight Transportation Technologies NearFuels RealFuels KSPI-E DangIt! Mods that are CRP Compliant (Mods that are known to play well in the sandbox together) Universal Storage TAC Life Support Download Links Use any of the links below to download this mod, or pick it up via CKAN. Source Code and Change Log Donation Info! If you like what you see, and want to help out (or just buy me a beer!), please consider donating, either via PayPal or Patreon. License Information Umbra Space Industries, USI, CRP, and Community Resource Pack are (tm), and may not be used without permission. License for all configuration files is CC 4.0 BY SA NC NOTICE: This mod includes version checking using MiniAVC. If you opt-in, it will use the internet to check whether there is a new version available. Data is only read from the internet and no personal information is sent. For a more comprehensive version checking experience, please download the KSP-AVC Plugin.
  3. Configurable Containers Requirements ModuleManager AT_Utils (already included) Download from SpaceDock For Players This mod converts fuel tanks and resource containers so that you can change the resource(s) they hold in Editor and in Flight. Supported Mods Configurable Containers support many part packs and mods: TweakScale ProceduralParts Parts with stock resources converted: Stock KW Rocketry Mk2 Expansion Mk3 Expansion SpaceY-Lifters SpaceY-Expanded Fuel Tanks Plus Modular Rocket Systems Standard Propulsion Systems Near Future Propulsion Spherical and Toroidal Tank Pack OPT Spaceplane Parts (made by octarine-noise) …more will come. Supported resources: Stock TAC Life Support Extrapalentary Launchapads Near Future Propulsion All USI All KSPIE …more will come. Types of the Containers Tank Type is a set of resources that, gamewise, have something in common. For example gases, or liquid chemicals, or metals. There are also two kinds of configurable containers. Simple containers belong to a single Tank Type (which can be changed in Editor) and can hold only a single resource. In flight this resource may be changed only if the container is empty, and only within its Tank Type. Compound containers are in fact collections of simple containers inside of a single part. In Editor you can partition the inside space of such part, creating as many simple containers as you need. The only restriction imposed by KSP is that a part cannot have two identical resources stored. So if you have two containers for liquid chemicals in a part, only one of them can hold Liquid Fuel. Compound containers have a dedicated user interface so as not to clutter part menu: For Modders Source Code CC is a part of the AT_Utils framework. It provides the SwitchableTank module that allows for creation of container parts for predefined sets of resources switchable in-flight. Sets are configured in a separate .cfg file and are intended to contain similar things like gases (one set), liquid chemicals (another) and so on. Another module Configurable Containers provide is the TankManager which enables in-editor partitioning of a container, effectively converting it into a set of independent SwitchableTanks. The third, utility module named SimpleTextureSwitcher allows you to cycle through a predefined set of textures for the model or a part of the model, so a container may be easily identified. It is now part of the main AT_Utils.dll, not the CC itself. Acknowledgments My patrons on Patreon. Thank you for your support! eL.Dude Bart Blommaerts Layne Benofsky Issarlk SCESW Kevin Casey Bob Palmer Ryan Rasmussen Matthew Zaleski Patrice Hédé Steve Victory
  4. Hey all. As of late I've been playing around a bit with module manager and just editing .cfg files, mostly as a way of familiarizing myself more with KSP's back-end, and partly because I do have some interest in maybe developing some kind of mods in the future, even if only for practice/personal use. Anyways, I spent the better part of my afternoon and evening today playing around with resource definitions and modules, and as a practice exercise I've been trying to make a simple set of .cfg files for a resource pack (Stuff like water ice, carbon, uranium ore, and processing these materials into other things with ISRU units). I get the gist of what I'm doing but there are a few things that I've yet to find answers to, and I'm looking for advice. Forgive me if my questions have been asked before. I did some googling, and found next to nothing, so I suspect this isn't a problem, but if so, please feel free to point me to the exisiting posts. 1) in the ResourcesGeneric.cfg file (GameData/Squad/Resources), what is hsp, and is it worth modifying for a new resource? 2) in the Ore.cfg file, I understand that I'm looking at the resource distribution parameters, but I don't know what Variance or Dispersal correspond to, also 3) is the PressenceChance parameter per planet? Per Biome? Per savefile? 4) still in Ore.cfg, what is ResourceType? I've yet to see an example of anything not equal to zero for that parameter... 5) It occurs to me that a few resource parts are configured by default to only work with the standard "Ore" resource, such as the Narrow Band Scanner, and the Drill Parts. Is there a simple way to make either of these function for all available resources, or must I add new modules to the .cfg for every mineable resource? 6) how do these changes apply to asteroids? do I have to use a MM patch to add mineral resource to a roid? Or are all of the other resource definition and distribution cfgs enough? I'm sure that I'm yet to encounter more questions on the topic of Resources, ISRUs, Drills, and scanners, so If you can think of anything else helpful for working on this kind of stuff, please, don't hesitate to fire your pointers my way! Happy Launching, happy Modding!
  5. Download via the USI Catalog Page LOTS OF STUFF CHANGED WITH 1.0 - DELETE YOUR OLD STUFF FIRST! Introducing Karbonite Plus (K+) - New resources and parts for Karbonite K+ adds new resource and gameplay elements as well as supporting parts to Karbonite. K+ requires Karbonite (not included) to use. Enhancements and Changes included in K+ New resource: Karborundum. Valuable and incredibly fuel efficient, but also very hard to get. It can be harvested on the surfaces of Eeloo and Eve, or by a solar collector within approximately 2000 meters of the sun's surface. Hats off to nli2work for his awesome rover-sized models, and for TMarkos for being awesome and collaborative! New parts: Tiny radial Karbonite/Karborundum drill. 0.625m form factor, can be node or surface attached. Also KAS-portable! Deployable Karborundum scanner (NOTE: Karborundum is only detectable on the surface, or at altitudes lower than approximately 500m over the terrain - so bring your Rovers and nape of the earth (NOE) flyers). New fuel tank - the Karry Kan - great for small quantities of Karbonite or LFO. Comes in two sizes - a surface-mountable single Kan, and a double-Kan (great for the Packrat Rover). Rover-sized generator, for powering your Karborundum operations on the fly. KASable, surface and stack attachable. New radial tanks to store Karborundum in three sizes - a Jumbo radial tank, an inline tank cluster, as well as a 0.625m mini tank. The mini tank is KAS-enabled. A Karborundum sample tank. Luxuriantly expensive, but saves you the trip to eeloo. Made for testing purposes. Warning: Will self-decouple and explode when empty! Hilarity may ensue. A new particle collector with slightly better range (at the cost of efficiency and energy use), allowing it to skim the sun's surface picking up stray Karborundum particles. The Karborundum Fusion Drive (in two sizes - 1.25m and 2.5m) Expensive, incredibly efficient, but require significant EC to operate, and runs on Karborundum. A small but adorable 0.625m Karbonite engine. This one has the added benefit of taking some of the vented exhaust and converting it into monopropellant for later use. Dev Note: The Karborundum engines are absolutely OP compared to stock engines (we're in KSPI territory with these), This is to balance the absurd difficulty in getting fuel for them. Tech tree wise, Karborundum-specific parts will be under Nuclear Propulsion. Karbonite bits will be under Fuel Systems. Demo of the Fusion Drive Configuration files and code are licensed under the GPL v3 license. Assets, including Models (*.mu) and Textures *.png/*.dds) are All Rights Reserved. If you wish to use any of these assets in your project, just ask nicely Download on GitHub: Change Log: 0.3.0 - 2014.12.16 [LIST] [*]KSP 0.90 Compatability [*]Moved 0.625m Karbonite engine and Karbonite SRBs to the core Karbonite mod. [*]Moved the Karry Kans, mini drill and mini-generator to the core Karbonite mod. [*]Added MM config to add Karborundum back to mini drill for K+ [*]Swapped all generators and converters to Regolith [*]Removed the Liquid Hydrogen requirement from the torch drive, increased ISP, reduced thrust (so they are more... you know... torch drive like). [*]Added in CTT support. [*]All K+ harvesting parts are under Resource Exploitation. [*]Fusion drives are under Fusion Rockets. [*]Torch Drives are under Exotic Reactions. [/LIST] 0.2.3 - 2014.11.01 [LIST] [*]Moved K+ DLL and version file to better support package management [*]Replaced all PNGs with TGAs [*]Adjusted KAS containers to better manage state [*]Fixed name and attachment issues with RAT boosters [*]Fixed missing model part from inline Karborundum tank [*]Added two new torch drives in 3.75 and 5m form factors. Because Hohmann transfers are for sissies. [/LIST] 0.2.2 - 2014.10.07 [LIST] [*]KSP 0.25 Support [*]Added ability to shut off Karbonite SRBs [*]Corrected issue with node spacing for fusion drives [*]Updated ORSX/USI DLLs [/LIST] 0.2.1 - 2014.09.28 [LIST] [*]Updated USI Tools [*]Fixed bug where Karborundum could be seen from orbit (boo!) [*]Karborundum tank description now includes max capacity [*]Added four Karbonite based SRBs in 0.625 and 1.25m form factors. NOTE: While these are very powerful, they also become unstable as speed increases - beware! [*]Fixed issue with the radial drill not extracting [*]DRE Support [*]MFT support for Karborundum [*]Tweaks to the 0.625m engine [*]Switched from ORS -> ORSX [*]Fixed animation on fusion drive [/LIST] 0.1.2 - 2014.09.12 [LIST] [*]Maintenance release - version file, new DLLs with version checking, and a dummy DLL for folks to use with MM to determine if K+ is present (KarbPlus.dll) [*]Updated to latest USI components [/LIST] 0.1.1 - 2014.09.07 [LIST] [*]Added bottom nodes and fairings to all engines [*]Fixed cost issue with Karborundum tanks [/LIST]
  6. Idiot Lights r0.0.1 Released 6/30/16 Downloads to date: Donations will be credited toward the Maritime Pack, my other mod. Donations to Date: List of Donors. THANK YOU! Ok, let's think about this for just a moment. Kerbals have exactly two stats: courage and stupidity. Now, when your crew's performance is based on their level of ignorance and lack of self-preservation, can you really afford to overload them with information? Introducing the first piece of Gednuk from Fengist's Shipyard and Gedunk Shoppe: Idiot Lights. We've made this so simple that even the most incapable Kerbal can't get it wrong. Simply stick this little gem anywhere on your vessel and watch the pretty lights flicker. Green = good. Yellow = ummmm mebbe good Red = we're gonna crash. Now, for the human translation: Idiot Lights are the solution to keeping track of your fuel status without having to watch a bunch of numbers. Let's face it, flying a rocket isn't easy. And sometimes, you can get just too much information. One quick look at Idiot Lights and you know your fuel status. Green = You have more than 50% of a resource. Yellow = You have between 25% and 50% of a resource Red = You have less than 25% of a resource. Resources monitored: Battery Liquid Fuel Oxidizer Monopropellant Features: Lights only go on when a resource is present! That's some serious technology! Surface mounts to just about anything. It is scalable but you'll need to do that in the .cfg for now till I get it tested with Tweakscale. It's original size is 10 time larger than what you see. In the .cfg the line:[ rescaleFactor = 0.1 ] sets that size. Change that until you have the size you want. The reason for this resizing was to get the text beside the lights to look decent. Known Issues Ok, so I got the surface connection pointed the wrong way... but you can turn it around till I get that fixed.
  7. In my mod GTI MultiMode Intakes, I am allowing switching between different intake modes. When doing this, I'm also changing the resources associated with the intake, like intakeair or intakeatm. However, so far, I've relied on "part.Resources.Clear();". This removes all resources in the part, and then I can add the new resource I want back in. However, this have one mayor drawback, it removes all resources, and not just the ones I want it to, namely the ones I target. So in my latest try, I used the below methods to target only relevant resources. However, I cannot seem to get them to work. public bool Remove(PartResource res); public bool Remove(string resName); public bool Remove(int resID); I tried as follows (i merged the three overload methods directly into the example below, I do NOT run them at the same time, I comment out when testing). Debug messages says that I do indeed run the "Remove()" method where expected and on the expected resource. The remove methods return true!!! But my engine continues to consume IntakeAir even when switched away, so that the resource should have been removed. When I use "Clear()" the engine flameout immediately as it should. And listing all resources in the part after all show that the resource was not removed. bool preserveResource; PartResource partResourceDef; //Evaluated all resources in part for (int i = 0; i < currentPart.Resources.Count; i++) { preserveResource = true; GTIDebug.Log("Check for resource removal: " + currentPart.Resources[i].resourceName, iDebugLevel.DebugInfo); //compare all resources to the target resources for (int j = 0; j < modes.Count; j++) { //If it is a target resource, mark it for replacement if (modes[j].resourceName == currentPart.Resources[i].resourceName) { //Remove resources managed by this mod preserveResource = false; break; } } //Remove resource if it is marked for replacement if (!preserveResource) { GTIDebug.Log("Removing Resource: " + currentPart.Resources[i].resourceName, iDebugLevel.DebugInfo); //try 1 currentPart.Resources.Remove(currentPart.Resources[i].resourceName) //try 2 currentPart.Resources.Remove(PartResourceLibrary.Instance.GetDefinition(currentPart.Resources[i].resourceName).id) //try 3 partResourceDef = currentPart.Resources.Get(currentPart.Resources[i].resourceName); currentPart.Resources.Remove(partResourceDef) } } So my questions are, does Remove() work at all? if yes, then can anybody point me toward what could be wrong in my code?
  8. Current Version v0.5.4 Solaris Hypernautics is proud to bring you the very latest in virtual particle tech! This a parts pack that takes the all parts of the venerable Ion Hybrid Electric Pack,!!!-See-Development-Monitor, and reimagines them in the next generation propulsion devices that use virtual particles! Now we've expanded our line of technology and engines to include adaptations of Nazari1382's Aurora Atomic Thruster part, nil2work's Retro Future Planes parts, dtobi's Asteroid Cities parts, and various of Zzz's parts. This shows all the parts the mod used to only have, it currently has a full set of comprehensive components. Long ranged designed for high speed aerocaptures, the Fafner Descent Vessel. CRAFT FILE DOWNLOAD LINK: Massive IPV meant to transport small vessels and modules within its cargo bays to any destination. Can even function as a mobile operations station and refueler, the Armetis IPV. CRAFT FILE DOWNLOAD LINK: So what do these tiny particles have to offer when I already have nuclear engines and warp drives? Well, for one these babies don't require the power budget of a small country, though plenty of power is still advised. These drives don't use exhaust so you'll never have to worry about accidently blasting away those fragile solar panels! Electricity is the only thing you need to keep the whole system running, so no more running out of fuel or need for mining! How do I use this crazy new technology?! Easy as one-two-three! One: Generate them via a Virtugenic (and a lot of power). Two: Store it in a Stasis Tank. Three: Propel your ship with it! Told you it's as easy as one-two-three! I heard that you've expanded beyond virtual particles, what else is there?! Glady you asked! We now also have a wide range of parts that utilize the exotic reaches of magnetic fields and dust, yes dust! Our scientists and witch doctors have devised ways to make dust useful like getting xenon out of it or compressing it into ore, which is actually useful. For our line of magnetic fields research, mostly from our bored co-workers playing with the fridge magnets in the break room, we've figured out how harness their power as an ablative to keep systems cool! How cool is that?! Thanks to some serious work with an unmentioned scientist, we've devised even more ways to get power from various resources, nuclear power here we come! I'm sold, so what parts does this pack actually have? Passive Intakes for collecting compressed atmosphere. Huge Docking Port for connecting really big ships. Nuclear Fuel Tanks for holding blutonium. Industrial Nuclear Facilities for refining ore into blutonium. Advanced Grabbers for more options to attach to asteroids. Stasis Tanks for storing virtual particles. Virtugenics for generating virtual particles using lots of power. Kannae Drives for moving vessels and probes using only virtual particles and some serious power. Side Adaptor for attaching things on the side. Virtual Ore Reactors for powering things from ore and virtual particles, the bigger one even has a backup reactor that uses xenon instead of ore. Catalytic Engines for higher thrust rocket propulsion and the ability to draw dust from any atmosphere. Magnetic Drag Array for atmospheric entry with huge vessels, uses its magnetic charge as an ablative, has a built-in SAS system and cooling system. Nuclear Jet Engines for travel through an atmosphere without having to worry about needing oxygen. Retro-Propulsive Unit for a heat shield and an engine all in one part, uses it magnetic charge as an ablative. Nuclear Plasma Engine for when need the absolute biggest space borne propulsion using liquid fuel and electricity. Ionic Plasma Thruster for when don't need a monster engine, but a modest propulsion using liquid fuel and electricity. Magnetic Cooling Unit for dropping the temperature at the cost of power, perfect for fighting overheating. Virtual Dust Containment Tanks for storing dust and virtual particles, though the compression requires constant power or it'll leak virtual particles. Spherical Dust Tanks for storing dust and only dust. Dust Accumulator for gathering dust in any environment over time, but requires constant power to keep the magnetic trapping field up. Dust Processing Unit for extracting xenon from dust or compressing dust into ore, both using a lot of power at the risk of slight overheating. Nuclear Reactors for using ore and a bit of electricity to produce a ton of power, but it tends to overheat so make sure to use the built-in cooling system that also takes power. Nuclear Forge for producing power like a reactor but can also transynthesize virtual particles directly into dust, also has a cooling system built-in. Thermal RCS for maneuvering massive ships without then need for an army of normal RCS thrusters. Spectrometer for getting an area's composition to get some juicy science. Virtugenic Refinery for processing dust into more ore and converting dust into virtual particles. Dust Ring for higher speed drawing in of dust. Solar Wind Panel for truely passive dust collection from the Sun. Micropulsed Magnetic Drive for high efficiency burst of acceleration at the cost of endurance. Zurbin Nuclear Drive for massive propulsion on par with the Indominus in and out of the atmosphere. Gallery of Parts and Usage Details PRIMARY DOWNLOAD: CURSE DOWNLOAD: CKAN AVAILABLE: YES Development Thread Licensing The contents of this pack are licensed as GPLv3. Zzz parts are licensed as Public Domain. Recommended Mods Module Manager 2.6.2 or more Integratable Mods Engineering Tech Tree by Probus Community Tech Tree by Nertea THE ION-HYBRID PACK FOR CURRENT KSP IS OUT NOW GO CHECK IT OUT:
  9. The Resources in a Can or RIAC for short is a mobile, small and compact mining IRSU for small purposes. Able to be stored in very small cargo bays and land on small distant moons (Engines released pending completion.) Even tho it is of small size and stature it will be well suited to supplying roving probes with required fuel for much less then a full mining rig. It will have center core, that is just a simple attachment point or maybe include a probe core. Then there will be many stack parts, such as on top, a four way small connector for 4 independent solar panels, a stack 4 way solar panel that is static, probe core, small rcs and LF/OX tanks, Sas, reactor, a mini docking port/ decoupler, and a parachute (Probably multiple depending where you plan to go). For the bottom it would be landing legs, and assorted engines each with their own strength to be used for different gravitates. The main goal of the mod is to have a small stow-able miner that could be pushed by just a ion drive to the planet and then use its own thruster, and be used as a back up and since it will be quite low rate of production. Or as a far off miner to land and start a mining colony well you setup the bigger stuff or to refuel future missions so they can save weight on return feul. Each part is contained in a quarter shell with doors that open allowing for safe travel and re-entry through atmo, but I plan to have the doors also act like radiators for the refiner and drill. The refinery will have a bit of storage for fuel in it but the pop up will have a lot more fuel available in it (To be determined at a later date).
  10. I've encountered what seems an odd phenomenon, that has helped strand a Kerbal in Munar orbit, without a ship. Here's a craft file: Selene 1 Mod 2 I launch this ship with RCS turned off, using main engine gimballing for control until staging. Once I stage away the booster, fairing, and nose cone (above 70 km only due to a spectacular demonstration of the drag still present at 40+ km and 1000+ m/s), I turn on RCS so I can maneuver before igniting the second stage engine to circularize (the second stage also performs transMunar insertion and Munar orbit capture before being deorbited on the Mun). This is where the odd thing happens. It takes a lot of RCS authority to turn the remaining stack at this stage (initially, with full tanks in all modules), and the center of mass is far enough forward that the Lf/O thrusters on the second stage tank get a lot of help from the four sets of RCS quads on the lander and pusher stages. However, the RCS on the lander and pusher stages don't consume fuel evenly from the command pods and RCS tanks, despite crossfeed being enabled on every decoupler and stack separator. Rather, the lander's RCS fuel is depleted first, with the command pod being emptied before the stack RCS tank is used, and both of those being burned dry before any fuel is drawn from the pusher (top module at launch). This doesn't seem to be a case of the game drawing propellant from the lowest tank first, which would make some sense for the usual staging order; rather, the command pod fuel is being depleted first. The only solution I see is to remember to manually disable the command pod and stack tank feeds before launch, and then manually re-enable them before I'm ready to decouple the pusher and turn it around to dock with the lander (a la Apollo, which is the configuration I adopt before Munar orbit insertion so the pusher is ready to maneuver itself and the lander as soon as the second stage is jettisoned). Am I missing something relative to propellant consumption order? I think this is the first time it's really matter which tank empties first -- but this time, it led to a Kerbal launching from Mun without enough RCS propellant left to assist when the main engine's tanks ran dry before establishing orbit. The pusher pilot, meanwhile, was sitting in a safe orbit, with a nearly full RCS tank, and no way to help...
  11. Currently several lifesupport mods exist which is great. The user can choose by himself/herself whatever lifesupport mod most coïncides with his/her wishes. What is not so great is that every LS mod uses it's own resources. Take Food. In another mod it's called KolonySupplies, in a third N.O.M.S. My request to all LFS developers is to standardise resource names so parts of different mods can become interchangable.
  12. I have begun very basic work on a series of engines that combine mass driver, plasma creation, and the ultimate in recycling. Engines will have two grades, O.R.C. and E.L.F. Otherwise Really Cool Engines will heat its "fuel" mass to high gaseous state, ionize and expel for force. High cost of energy to the matter's density and boiling point, a bit more for ionization andd magnetic expulsion. So far a 1.25 I call Pele and a 2.5 I call Vulcan. Only fuel at this moment is the junkiest, but would be universal otherwise in being Rock. Performance curves in atmo like LN-V. So no mining rock on kerbal to get to orbit, well not reasonably. I am not making a cheat, but basing this on real scientific principles. I said basing, accuracy will of course deviate and that can be debated, but will not be this threads sole purpose. Stage two is in concept only ATM, everything is the same but more so, to get Electrodeless Lorentz Forces from a plasma you make from whatever. Thinking once I get how to flow and channel the thermal models in KSPI-E, I will use that as a power core. Next steps is an enigine module that will use a fuel data dictionary for settings about boiling points and specific heats, as well as density. Then the fuel determines the engines force, as all else will be as a level zone. This will make an interesting alternative for Depleted Fuel and similar things. It will be high density, so you would get 2-3 times the effect from rock in an ELF, but boiling points are much higher I believe, so an ORC maybe only 1.5 to 2, with higherr electric charge per second. These engines will take nearly impractical amounts of power. Nearly because the nuclear option is literally on the table, and will tend to pay off, or at least get close. I am looking to Coordinate with USI and KSPI-E, at least. ~Rough Draft~
  13. I am making some science parts and I want to make them use resources to operate. For example: Rodent Research, uses five rodents. How can I do that?
  14. DOH!!! I'm a dummy! I forgot I had switched to my development computer and hadn't updated Module Manager. So my mod Thermal Nuclear Turbines relies on the resource IntakeATM. I was just testing my engines for 1.1.2 when I discovered the intakes won't generate the resource anymore. The MM patch for intakes. Oh well... Here is a pic of some cute confused Kerbals... Sorry guys. They think something got jammed into the intake... poor Kerbals.
  15. I have a question and maybe a mod idea. What is the point of stock narrow band scanner (the hexagonal thing) if it does not work on a planet without prior sweep by the big M700 scanner? 1) What sense does it make mechanics-wise? It's a scanner or it isn't? 2) What's the point of bringing one at all, if you already have the data from M700, and can see ore-rich areas? If you oh so wish to win few hours over few days of mining by moving to especially rich vein - there's surface detector for that. Won't it be a better idea to have two scanners different in mass and size, with different capabilities? Trading smaller size for data limited to area directly below your ship, compared to instant whole-planet scan by the big bulky polar scanner?
  16. So I have been working on this mod for a little bit but I kind of stopped for a bit. currently it has a converter and small tank. I am currently curious on what would be required to allow it to function with ore but have the ability to recognize that MKS has been installed and switch to that as the processed resource instead of ore? The current module attached to it in the Cfg is: MODULE { name = ModuleResourceConverter ConverterName = Xenonfuel StartActionName = Start Xenonfuel StopActionName = Stop Xenonfuel INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 100 } INPUT_RESOURCE { ResourceName = Karbonite Ratio = 0.0225 } OUTPUT_RESOURCE { ResourceName = XenonGas Ratio = 0.001 DumpExcess = false } } Any help would be appreciated.
  17. Greetings, So I am working on resource implentation for all the BIOMES, Planets, Moons, in KSP, OPM, maybe one or 2 extra planets/moons for OPM. We are using STOCK resource generation now, and only basic resource implementation is provided. This game is going places, but players such as myself and modders especially make it go further. A premise or 2 for resources in this game is to add realism or extra challenges; survival, building things in space, like more spacecraft ! So I was thinking..."ORE??" Scan and drill for ore and convert it to rocketparts; there are mods that get into this, some of which are either pretty basic and others which involve a level of logistical thinking that boggles the mind ! Well since we are going down this wabbit hole, why 'ORE' now? Let us drop ORE and define the basic metals needed to build spaceships and provide survival needs (the survival needs are provided by chemicals to grow hydroponically for example and are pretty straight forward; however even here...); in drilling for basic metals, we also get rock which contains limited amounts of various chemicals; carbon for one. We could even have silicon. In some of my processes I use 'chemicals' as a broad term for needed extras to complete water purification for example. There may be some chemicals, like liquid chlorine, I use to clean water; we could get this and remove the chemicals if we wanted; we could be more specific in our processes. ORE is not very specific. There are many kinds of ORE (and some drillable materials that are not ORE): iron, bauxite, gold, etc. Rocketparts would then be replaced by iron, aluminum, gold...yes there is a rabbit hole here; why not start diggin ! There probly isnt much ore out there to build spaceships with; maybe some planets/moons have alot of a specific material though. We could use iron altho it is very heavy; we can make steel or alloys in processes to make the materials less dense. I am going to drop ORE completely from the resources list !! Where ever it is used I am going to simply replace the process with an alloy ! I havnt a clue what the best space ship material is; so I am going for an alloy; I note that a material called karborundum is out there; I dont like how it is probly implemented; it sounds like one of the hardest materials out there (and less dense too I think) called carborundum; this could be an endgame material. Metals could have a shelf life; after a certain amount of time it succombs to raditiation leakage; the parts have to be salvaged. The only problem is the resources dont deplete as far as I know. I opt for dropping ORE as a resource material for building anything, but maybe leaving it for the primary source game resource. The new resource system now shows percentages of any resource so why have ORE (from a 'vet game player's' point of view). An easy option would be to drill for ORE and have processes extract the materials based on the presence of the resource on the planet/moon (!); well I just had this thought now! Say we scan for ORE and other materials; say bauxite is at 5%; this would mean we have a 5% extraction rate of Bauxite from ORE; or we drill specifically from Bauxite present on the planet/moon. Do we keep the ORE and extract material presence in it (more processes code), or do we mine for specific materials? Looks like mining for specific materials is better as it drops out one process. So I am dropping ORE as a drilled resource...what do you think !? Commander Zeta
  18. My first contribution to this fine Community -- and I can assure you it won't be my last. Hopefully this points anyone who needs the information in the right direction. I've been monkeying (Chaka!) around with adding CO2 Scrubbers and whatnot to Pods and Station Modules. Following the brilliant examples in TACLifeSupport by TaranisElsu, I attempted to add the relevant modules from that pack into Pods and Station Modules that I was directly using, but it didn't quite work out the way I wanted. I was calling the parts instead of the functions; that's where I was going wrong. Turns out we can simply add these things directly into each .cfg file, and not have them be static (because one Pod for two Kerbals should not have the same Scrubber as a Pod meant for six!). We can tweak how "efficient" these parts are, as well as how "converty" they are, according to the Pod or Module. All credit for the code you're about to see below goes to TaranisElsu and TacLifeSupport. I'm just a bit of a hack who tweaked the numbers for simplification, and I'm sure TaranisElsu will yell at me for it. In each part file you want a Convertor/Scrubber/Recycler in, you can add this to the config, and you may have more than one convertor! Simply make a new MODULE {} entry for it. // Watch this ... don't need separate config files, do it right here in the .cfg file! Needs TacLifeSupport. MODULE { name = TacGenericConverter converterName = CO2 Scrubber // A scaling factor by which the resource amounts are multiplied -- change the last number for however many Kerbals the part is rated for (this one is for 4 Kerbals) conversionRate = 0.04 // A comma separated list of resources to use as inputs. // For each resource, list the resource name and the amount (which // is multiplied by the conversionRate) inputResources = CarbonDioxide, 0.1, ElectricCharge, 0.4 // A comma separated list of resources to output. Same as above // but also specify whether it should keep converting if the // resource is full (generating excess that will be thrown away). outputResources = Oxygen, 0.025, false, Waste, 0.075, true } As you can see in the code, the above unit is rated for 4 Kerbals, and has an efficiency rating of ~25%. Every 0.1 units of CO2, plus 0.4 ElectricCharge will output 0.025 units of Oxygen and the remaining 0.075 units (in this setup) is Waste. The inputResources and outputResources can be anything we need; but it's good to keep things realistic. No reason to have this thing generating MonoPropellant, ElectricCharge and LiquidFuel/Oxidizer, although it could. And remember that anything outputResource generated is stored automatically if that resource storage is specified on-board. For example, if we're storing Waste on board, the excess ("Waste") will go into the Waste resource pool, because that resource was specified as being on board. "Waste" literally can mean anything. Anything. Treat WasteWater the same way. Outputs are likely CarbonDioxide and Methane (you'll need tanks to store both separately), then use the CO2 Scrubber to get Oxygen from it. If we really wanted to get creative, we can use a Sabatier Process to turn Carbon and Methane into nearly anything. Hope this is helpful. Again, all credits go to TaranisElsu and TacLifeSupport for the code.