• Content count

  • Joined

  • Last visited

Community Reputation

434 Excellent

About Terwin

  • Rank
    Spacecraft Engineer
  1. KSP version? MKS version? Any other mods installed? Can you reproduce the issue with just USI mods installed? Can you provide a save game with the problem with only USI mods installed? (the standard set of questions to help diagnose a problem)
  2. I never add RCS thrusters, but I often forget to empty the command pod tanks. I do most of my docking with the Klaw or KAS, so the extra lateral precision is not worth the bother of using a second control scheme that I rarely use. (admittedly I use Sr ports for my DIY Kit delivery rockets with one on each side of the kit so that I can re-attach the nose(with a sky-hook for placing the kit and re-docking), but I still find it easier to re-connect by having SAS set on 'up' and tweaking direction with quick taps on the keyboard while the engines are throttled to a TWR close to 1.0; fuel at this point is not a concern as this is a drone placing either a base or a base expansion, and so happy to wait for the base to refuel it)
  3. As far as the Assembly yard, I thought that was a reference to the vessel with the assembly module, but the idea of an inflatable scaffolding that is removed to expose the completed DIY Kit is appealing. Personally, I would use a DIYKit deployment node on any assembly yard module that is capable of producing kits, sort of like the EL does. Due to the ability to combine workshops, you could even make a 'deployment module' that has the deployment node and perhaps a place for the science kerbal that is required for making the kits, then use the already existing Engineering workshop modules to provide the engineer-time inputs. Having a deployment node approach means that users can plan to have this elevated with a path underneath it to allow for a flat-bed truck equivalent(possibly with a klaw mounted in the bed) to catch the kit when it detaches and carry it to it's destination(in addition to all the other options). The possibilities of uneven terrain, and the potential complexities of things like survey stakes, make me cautious about the prospect of just spawning a kit that is not attached to anything(this would also make it harder to use in orbit). In orbit, my understanding was that there would need to be a 'hangar' type module where the kit could be expanded and assembled, and if you allow detaching an un-deployed kit for delivery elsewhere, I see no reason that you would not just populate any new kits(possibly starting with a scaffolding again) inside a Hangar module.
  4. MKS is compatible with the community tech tree, and if RO has a different tech tree, and there is not yet a config to support it, then RoverDude accepts Pull Requests if you would like to add it yourself.
  5. As far as using stock ISRU modules to produce material kits, I think the rate of production makes this option little more than an after-thought in any scenario where you can already produce material kits unless your MKS production line is severely resource constrained. But it can also be very helpful when trying to kick-start a colony. While aerodynamics are a non-trivial problem to address for bases, GC also either allows you to break apart your base delivery vessel into multiple parts(DIY Kit and one or more MK cargo vessels), or produce part of the mass on-site(if using locally produced Material Kits). And launching multiple smaller payloads is much easier than launching fewer larger ones, especially when you need a large dV budget such as interplanetary transfers. @allista I would probably transfer the kit either by attaching a Klaw to a sky-hook type apparatus, or by using KAS to put it in place on the transit vehicle(may require construction vehicles to have enough mass capacity to move it, possibly even a crane on the transit vehicle).
  6. There is a whole thread just for discussing GTA Moding concerns and how that may or may not affect KSP: Spoiler: no one knows anything definitive unless you are willing to take Squad at their word.
  7. A month ago, I had at least 23, and I know I also currently have a 1.3 install, so: no less than 2 dozen, going back to 0.90
  8. If you want a fast turn-around(as in hours), landing back on the pad can save a lot of time and remove opportunities for damage to the landed vehicle(especially with how big this booster is expected to be). Refueling and mounting the tanker second stage will need to be done no matter what else you do, but if you are able to remove every other step beyond a quick visual/telemetry inspection, then you can get turn-arounds where the pumping speed of your fuel pipes becomes a major contributor to your ground-time. There was also a tweet earlier in this thread where musk mentions the accuracy of the landing improving with every return. There is also the option of adding heavy-duty shock-absorbers to the launch-clamps to allow a few extra m/s variance in the landing without damage to the booster.(not feasible when they need to be carried with the rocket, but only needing a flame-resistant cover if it stays on the launch-pad) Admittedly, I would not have considered it even plausible a few years ago, but we are currently living in a world where it is no longer remarkable to have the first stage of an orbital rocket to land within a few meters of it's target, be that a pad near the original launch-pad or a barge floating out at sea.
  9. Adding the change to MKS may be a hard sell as neither LH2 nor O2 are used or useful in MKS. The sky-hooks use LFO and I do not immediately recall any other parts that use fuel at all.
  10. I believe he is pointing out that any time you change the number of crew members actually on the ship while in the VAB, the results of the 'hab time at max crew' changes. You would expect the 'hab time with current crew' to change, but not the 'hab time with max crew' when you change the number of crew actually in the ship. As the only way to get an accurate measure of the hab time with the max crew involved actually adding that many kerbals to the vessel, having the 'max crew' line does not provide any useful information. I reported this previously as issue #224, and it was supposed to be fixed, so I'll go check real quick... Looks like it was fixed for supplies but not hab-time.
  11. If you do not have MKS installed, I believe that habitation and home-sickness are set to have no effect, as MKS has most/all of the habitation modules. (this is of course configurable, but I would not be keen to play with habitation and no MKS in my games) I believe that the small stock ISRU can produce fertilizer from Ore at a very slow rate as part of USI-LS
  12. GTA V sales top 80 million units as of May. When GTA IV topped 20M units sold, it was announced that the franchise had sold over 100M units(before the release of GTA V). As such, things that are worth while to do for GTA V or GTA in general are not necessarily worth the time and effort for KSP. As the comparisons made in this thread are to GTA or GTA V specifically, one must remember that GTA has sold roughly 90 copies per copy of KSP sold, and GTA V has sold roughly 40 copies per copy of KSP sold, with GTA also selling for a much higher price than KSP. (and this is not even counting the GTA online micro-transactions) I love KSP and I think it is a great product, but it just does not have the bottom-line impact of the product that it is being compared to in this thread. And as GTA V is sold on four different console systems, with more than 45M units shipped several months before the windows release was even available, I would hazard that it also has a smaller percentage of mod-users than KSP(as far as I know consoles do not generally support mods). In fact, looking at the sales numbers and the release dates, one might come to the conclusion that non-console users of GTA are mostly an after-thought(both GTA IV and V were released much later on Windows, with no support for other PC operating systems listed), making the maximum size of the GTA mod-using community an inconsequential fraction of the GTA community as a whole. After reading the rest of this thread and then looking at these sale numbers, I sort of get the impression of someone looking at the regulatory hurdles of building a 100 story sky-scraper in Manhattan and bemoaning the impossibility of building a 3000 sqft ranch-home in rural New Mexico.
  13. I believe the mechanic is 1 + year of hab for pilots or if on a body with 500% colonization, or 50+ years of hab in any scenario will give indefinite hab/home time. None of my planets are above 300% yet, but I have bases on the Mun, Duna and Moho with indefinite hab time because I have 50+ years of hab for the number of kerbals on-station.
  14. Many people seem concerned that T2 is all about profit and this will be the end of KSP. Remember, T2 did not just buy KSP, they bought the IP(as in they own Kerbals and can now release kerbal-branded everything). Also, it is not just profit, it is high profits with minimal investment. Adding DRM to a released product is hard. Anything tacked-on will be trivial to circumvent, and anything integrated will require a massive re-write. (considering how much of the core functionality is over-written by things like FAR(Aerodynamics), Kerbalism(background processing), and RO(lots of stuff, I am sure), there may not be a lot of code left where they can add DRM that is not *already* circumvented by existing mods, and I do not think any lawyer wants to be in a position to try and argue that even though A existed for years before B and has not substantially changed since B, A is specifically and maliciously intended to circumvent B) It is far cheaper for T2 to produce a re-skinned mario-kart clone, and two dozen other low-barrier-to-entry games using Kerbals than to go back into the existing KSP code(which is still being re-factored and cleaned up) and try to add DRM that is more effective than a post-it note saying 'please do not steal this.' Actually, if they made it racing rocket-ships with magnetic turns that could be pretty cool(obviously the default setting would not have 'realistic' physics on the turns, but it would provide a good reason why you need to choose between more steel(easier turns, but slower acceleration) or more carbon-fiber(more acceleration, but harder to turn), with magnets as power-ups and ...) I would expect most of the required development effort for those would just be appropriately funny cut-scenes and skins(that may or may not make Kerbals look a lot like the 3 stooges which may or may not be accurate depending on your views...). Easy to port to all consoles, etc. For monetizing KSP, DLC is the obvious choice, even if the core product will need occasional updates to make sure everything needed for the DLC is supported. Anything beyond that is probably too-much effort for the expected profit.(it is possible even DLC for KSP is too much effort for the profit, but they are using 'Making History' as a trial balloon to see if it is worth pursuing further) KSP is a niche product and I strongly suspect T2 is more interested in the Kerbals themselves than in KSP. I am expecting a large number of children's games featuring large-headed green people of Kerbin(which are already established and clearly not a derivative work, even if they share the same easy-to-draw characteristics of some well known characters, they even have the start of a non-violent but curious culture that would mesh well with children's games)
  15. While I can see why you would want them on the bottom for the purpose of creating images, don't most water planes have wings much higher up? That lets them do things like turn at low altitudes without having a wing ripped off by the water...