All Activity

This stream auto-updates     

  1. Past hour
  2. It does seem to work with FAR still. Like any other mod?
  3. Please consider adding proper Kerbalism configs - or pushing them to Kerbalism itself as patch.
  4. My fault, I should have done an epoch when I did that change. Thank you for fixing it
  5. To date, all successful mission aborts have been the result of a solid rocket motor successful usage. As well, all successful seat ejections were. It is not enough, not for abort and certainly not for landing. We can do that in KSP, because all solid motors have identical firing characteristics and can be perfectly aligned, but clustering solids in real life is not a good idea. A 200 t heavy ICBM gets pushed from a silo with iirc three sequential powder cans burn. I guess, it's enough good for a 10 t capsule pushing as well. No rocket packs or separatrons. A ring pipe of the chamber, nozzles attached to it where they're needed, powder cans. The same but bigger as the abort/deorbit propulsor. ~3 m wide, < 1 m thick cylinder under the capsule. Who said "no chutes"? You can read: "drogue chutes", 20 m/s landing speed = 72 km/h or 40..50 (?) mph. A speed of a car if the landing engine fails, but with legs and seat pistons providing 1 m of braking distance, so 20 g of acceleration on hard landing. Safer than a car crash if the engine fails. Also, about 500 astronauts have climbed aboard a cabin with no chutes, abort motors, or ejection seats at all. I.e. in the rear half of the ship, all of them. If make a bicapsule ship, they will be placed there as well, but in a reusable unmanned rear capsule. When I say that Dragon is overmassed due to its enormous octopack motors and fuel tank inside the heat-proof capsule, they say that Falcon anyway can lift more. So, that's this more but on purpose.
  6. I just checked the files again and there is a B9PartSwitch config for fuel tank and texture switching and the combined FireSpitter/IFS patch as well. B9PartSwitch is not mentioned in the OP as a new dependency, only this info does: https://github.com/linuxgurugamer/NSS/commit/7c078f21b612bf03a8565cf044e1ad4a80f2ba83 Some of the part configs already got a check for fuel switching MODULE:NEEDS[!B9PartSwitch] { name:NEEDS[Firespitter,!InterstellarFuelSwitch] = FSfuelSwitch name:NEEDS[InterstellarFuelSwitch] = InterstellarFuelSwitch ... so I suggest that the first line in GameData\NSS\TextureSwitch\NSS_MM_FSTextureSwitch2.cfg needs to be changed to @PART[OctoSat_*]:NEEDS[InterstellarFuelSwitch|Firespitter,!B9PartSwitch] Please test this and report back.
  7. This is so cool! I haven't checked up in a while.
  8. I haven't thought of the aero drag during separation yet. Interesting. I've only noticed it when I oversteered my MK3 spaceliner (spaceshuttle clone) and the whole thing tumbles because the wings and/or the huge fuselage is catching aero forces... But as I said, one sepatron on the nosecone of the booster pointing at the vessel is mostly enough to create an outward momentum. I usually separate when the boosters are empty (separation and next stage ignition in one go)...
  9. I want to use the mod for the first time. I ask to prompt in two questions. 1. I want to use the mod "Kerbal Construction Time". I understand that these mods will not be connected in any way. I want to be sure that there is no conflict. 2. if use the mod "Kerbal Construction Time", the ship will be built on Kerbin longer than on orbit in the "Orbital Assembly Line". How to reduce the build speed for balance? For example, reduce in 2-3 times. Please suggest an example of a patch. I hope that this is possible and engineers will still influence the speed of construction.
  10. Yes, it does. A fuel tank behind the drone core creates up to 100 kN of drag while others create up to 10. I took a drag cube for Mk2 battery from parts database and copied it to the drone core cfg and it works. All fuel tanks create equal drag, the drag of drone core didn't change. Dragcube for Mk2 battery also works for Mk2 SAS module but I'm not sure it's a good idea because it's twice shorter.
  11. That beast has carried some interesting cargoes in its day...
  12. You have 1.6 selected as compatible KSP version too, right? The version ordering was wrong in the metadata, because during the transition to @linuxgurugamer as maintainer, the 'v' prefix has been lost. So CKAN thought v1.19 was the newest compatible version, despite it isn't. I fixed the version ordering, if you refresh once again now, it should display the right links.
  13. I packed up the crane that I need to construct my Munbase inside the fairing of a 5m class rocket. As you can see, it's a weird contraption that uses robotic parts to fold up. Once at its destination, it will unfold and since the robotics will no longer need to move they will be locked and autostrutted. It's pretty light, so it doesn't really need the dV that the 5m rocket provides to reach the Mun. I only chose that size of rocket because it wouldn't fit in anything smaller The launch is scheduled for tomorrow, if time permits.
  14. No, I'm on 1.7.3 and I enabled 1.8 in compatible versions.
  15. I know very little about what it would take from a development standpoint, but from a player's perspective I can imagine this: - trusses can be docked together like normal in station construction using parts from some mod that is deemed "what this is designed to be used with" - the S1 truss would be either launched with, or attached later, a part that is the rail system and base that the arm structures would attach to (basically a gantry) and it would by default be only as wide as the S1 truss. - using a mod structure similar to B9 part switch, the user can then select how long the gantry will be in flight, similar to how a player can change fuel tanks to labs using orbital wet workshop parts - the user can select how long the gantry should be on either side (1, 2, or 3 truss segments or maybe in meters IDK) and the model grows accordingly, allowing further gantry movement down the new track Now I have no idea what it would take to accomplish this, but this is how I imagine it would work if someone told me it existed and I had to guess how to use it.
  16. Neither here nor there, he's also an ophthalmology practitioner of some stripe (it's not clear to me whether he's got a full MD yet, or going for nurse, or residency, or whatever).
  17. Sometimes solids are more reliable. To date, the only engine-related human fatalities have been the result of a solid rocket motor failure. Small nitpick here, but the distinction you're drawing (complex, pump-fed, non-hypergol vs simple, pressure-fed hypergol) is inaccurate. You can have pressure-fed cryo engines (Kestrel, Xodiac, Tronador T10, Aerospike Annular J-2, RS-17, RM-1500) and you can have pump-fed hypergol engines (RD-253, LR-87-11, YF-20, RD-215, Gamma-8, and many others). We often see pressure-fed cycles combined with hypergolic propellants because hypergols need no ignition system, which makes them more reliable. Pressure-fed cycles are favored when either high reliability or low propellant volume is involved. It is not enough, not for abort and certainly not for landing. We can do that in KSP, because all solid motors have identical firing characteristics and can be perfectly aligned, but clustering solids in real life is not a good idea. Rockets with solid boosters strapped to the first stage (Atlas V, Vulcan, Delta IV Medium) use nozzle deflection, where the nozzles are canted away from the rocket body to fire through the center of mass: This is used regardless of whether even or odd numbers of boosters are installed. As I said before, the STS used the largest TVC system ever built to solve this problem of inconsistent thrust on the Shuttle SRBs. The only time I know of when a great number of solid motors have been clustered in parallel (like Sepratrons) was in the second stage of the Jupiter-C: This rocket used eleven scaled-down Sergeant missile motors which fired simultaneously for six seconds, after which the core popped out and fired its own internal motor. These motors did not have canted nozzles, but instead used an electric gyrostabilizer inside the payload spinning between 450 and 750 rpm to accommodate for thrust variations. If land without chutes and start ignite at 2 km altitude. No astronaut in her right mind would ever climb aboard a capsule with a solid landing motor and no chutes. A hyrid motor, maybe. But never, ever a solid. Using a solid motor for landing really puts the "suicide" in suicide burn. Nothing wrong with using solids to brake at chuted-landing touchdown. That's how Soyuz does it and that's how New Shepard does it. Starliner uses airbags to perform the same function. Service module. Two heat shields? No, no, definitely no. And the trunk is not "heavier" by any stretch. It is very lightweight, and it allows both Dragon vehicles to co-manifest unpressurized cargo.
  18. Today
  19. That would be what the Kontinuum is for Currently the way to share HoloKrons (Geo-Caches, BD Armory challenges, Racing challenges ect.. .... these are all HoloKrons) is to upload your file to a file sharing service (dropbox for example) and then provide a link to the file for people to download. Once downloaded, the user places the HoloKron file (the .orx file) into the GameData/OrX/Import directory in their KSP game and then when OrX Kontinuum is next opened (you can drop the HoloKron files into the import directory while the game is running) the HoloKron file will be processed and all of the HoloKrons contained in the file will be set up and made available to the user (yes, you will be able to chain HoloKrons together with each HoloKron being unlocked and made available after the one before it has been opened and completed) The Kontinuum however will bypass the need for this step ... I have already started on a file sharing deal that will allow for automatic updating of .orx files while logged into someones Kontinuum ... Let me explain So this mod came out of an idea I started working on about 2 years ago and has been in the works in some shape, form or fashion for over 4 years .. actually since I had the idea to create a zombie mode for KSP (which I did mind you ... See spoiler below ) Anyways, back to the Kontinuum ...... The Kontinuum is the multiverse of KSP installs which, through some file sharing and network connectivity, another person will be able to connect to. This is not a multiplayer deal per se, but more of the ability to phase into another players universe by using the HoloKron system coupled with a whole ton of other network logic I have been working on that shares files between KSP installs that are connected to the same Kontinuum ... A player will be able to create their own Kontinuum connection that other players can log into if they have the password as well as the connection details Use Case #1 - you can create BD Armory HoloKron and send it to the other players universe and have the AI defend the position you created the HoloKron at in the other players KSP install (the ability to send orders to your phased HoloKrons will likely be a part of this) ... You will not have direct control over any of the craft contained in the HoloKron, they are controlled by the AI in BDAc Use Case #2 - A space race type of deal Use Case #3 - A cooperative space exploration deal I think you get the picture I created OrX Kontinuum to make it so that I do not have to hard code every level in OrX - The Loot Box Controversy (that was a major factor in how long it took me to create the few levels I did) ... Now OrX Kontinuum does it all for me
  20. Thanks, this is on 1.7.3, I still havent moved (and wont until Kopernicus/JNSQ and some other stuff). That said the visual set up I'm using is linked in my sig including the custom KS3P config. This is all in game processing I really liked the old CryoTanks but the new ones with the reflective textures are another leap ahead!
  21. Great screens! My 1.8.1 game doesn't look nearly that good. /envy
  1. Load more activity