Jump to content

MiniMatt

Members
  • Posts

    410
  • Joined

  • Last visited

Posts posted by MiniMatt

  1. I know this sounds *really* pedantic for a config file but it occurs to me that posting it *could* be interpreted (if you really squinted funny) as distributing proprietary code without permission so the safest answer I can give right now would be to get the stock files back from wherever you bought KSP - if Steam, then nuke (or, safer, move someplace else) your existing config file and in the Steam listing for KSP right click, properties, local files tab, "verify integrity".

  2. That gets to be a really wide question with a dozen different answers, all of them and none of them right.

    In short you can put your landing engines under your base module and try to keep them low enough profile, or you can put them to the sides of your base module to be jettisoned after landing, or you could put them above (and to the side) of your base modules as a detachable "sky crane". Each approach has it's merits. Duna will also allow for the use of some parachute assistance to further complicate or ease matters.

    As for docking them up once landed, you've options ranging from wheeled bases and carefully aligned docking ports, to mod solutions like KAS/KIS and the new USI Konstruction.

     

    Perhaps some pictures of your intended modules, and their intended final configuration would help? The Gameplay Questions & Tutorials section may also be able to provide more advice.

    edit: some shameless plugging - for smaller bases it may not even be necessary to break into smaller modules, you may just be able to launch the whole thing in one go - shameless plug link to the last Minmus mining base I launched as an all in one, aerodynamics be damned:

    Spoiler

     

     

  3. Ahh, my apologies, you're correct

    Just double checking in game, the Nom 5000 in agroponics mode is expected to eat 0.43 mulch/hour and produce 0.48 supplies/hour.

    Meanwhile a kerbal eats 10.8 supplies/(6 hour) day, or 1.8/hour.

    This means I've either misunderstood something badly (very, VERY likely - I get most things wrong on first glance) or I'm going to need to re-plan.

     

    edit: Ahh, the recycler efficiency of the MPL has changed quite a bit - from ~70% in 1.1 to 50% (up to 4 crew) in 1.2.
    So 2 kerbals with an MPL recycler would be eating 10.8 supplies per day total under 1.2. In 1.1 I'm pretty sure this could be covered by one Nom 5000 greenhouse, but clearly not under 1.2 - the changes Dstaal mentions are clearly worth noting here.

    The changes do kinda make sense of course, I could definitely not grow enough food to keep me alive on a daily basis in a space smaller than my car.

    edit 2: So it looks like the Nom 25k producing 2.38 supplies/hour (14.28/six-hour day) will do the trick for your 2-kerbal MPL recycled station - this coming at a cost of 1.148t and 1.32/s electricities; or four Nom 5ks, at a cost of half a ton, and 1.04ec/s will produce 11.52 supplies/six hour day.

     

  4. 37 minutes ago, Norcalplanner said:

    Has anyone else noticed the Nom-o-Matic 5000 running a lot slower than it used to? I had a mid-career station around the Mun with two of them, both configured for agroponics, and they couldnt keep up with the mulch generated by only two kerbals. Plenty of fertilizer and EC.  I'm away from the computer atm, so no logs - just wondering if anyone else has seen this.

    Is it possible you've got some recycling going on too, and it's not a case of the Noms being unable to keep up with mulch processing but rather them shutting down & not processing the mulch because your supplies are full? I'm 99% certain that recycling will reduce your supplies consumption but won't reduce the quantity of ....err... kerbal droppings / mulch stacking up. Ie, the recyclers don't turn ~70% of kerbal droppings into supplies, they just reduce your supply consumption by ~70% and leave the droppings to pile up in a corner.

    Remember also that the supply consumption rates have been significantly tweaked for 1.2.

    That said, I haven't started my 1.2 LS/MKS/Konstruction/Karibou career in earnest yet, just messing around in sandbox testing and theorycrafting.

  5. Fresh KSP 1.2.0.1586 Win x64
    GameData folder nuked (save the Squad stock folder)
    USI-LS 0.5.3.0 installed

    Create new sandbox save, default settings (no flights in progress - thought, haven't tested with a fresh save)
    Open SPH
    Select MK-1 inline cockpit
    Open LifeSupport status button
    Launch
    When loaded on runway, open LifeSupport status button
    Revert flight to SPH

    Autosaved ship loads up, with a blanked LifeSupport window - it seems whilst this blanked window is displayed, the log file fills up with null ref exceptions. Closing/reopening the LifeSupport window doesn't help, starting a new craft works fine (ie the LifeSupport window displays data as expected).

    Full log file at: https://drive.google.com/open?id=0BzCQMKilmnyaUXRyN1pCWkVyWVU

    Holler if there's anything else you need, but clearly just drop it if it begins to look like something unique to my setup.

  6. 4 minutes ago, Nori said:

    ...It's the Toolbar mod interacting negatively with USI LS...

    Curious, I'm getting it on a bleached fresh install with naught else installed. Clearly it's something specific to my setup then, I'll try digging further.

  7. 6 minutes ago, RoverDude said:

    FYI new release is up

    Yay! Can confirm max-crew increment fixed!

    Am still getting null ref exceptions in the logs - I *think* it's only happening now upon scene change from flight to editor after a revert, when the life support window was open in both:

    Spoiler

    [LOG 18:47:58.270] *****Adding icon for LifeSupport
    [LOG 18:47:58.281] Untitled Space Craft loaded!
    [WRN 18:47:58.334] HighlightingSystem : Framebuffer depth data is not available and can't be used to occlude highlighting. Highlighting occluders enabled.
    [EXC 18:47:58.351] NullReferenceException: Object reference not set to an instance of an object
        LifeSupport.LifeSupportMonitor_Editor.GenerateWindow ()
        LifeSupport.LifeSupportMonitor_Editor.OnWindow (Int32 windowId)
        UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
        UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
    [ERR 18:47:58.352] GUI Error: You are pushing more GUIClips than you are popping. Make sure they are balanced)

     

    (for testing - nuked game data folder fresh USI-LS 0.5.3.0, naught else but that installed)

  8. The interim release does indeed work pretty well, Wolf.

    Manually adding fuel pipes as if it were a 1.1 craft, getting the DV info, then nuking the redundant pipes to make use of the (awesome) new fuel routing works pretty well. The extra mass saved from the nuked fuel pipes becomes a free safety margin :)

    The HUDs are indeed one of the best things about KER and work just fine - the DV readout is clearly going to be a little flakey dependent upon craft design, but orbital parameters, current TWR, surface radar altitude etc all seem fine.

  9. 9 hours ago, Nori said:

    So I updated to 0.5.2 and I'm getting a GUI error upon opening the life support screen.

    Log is here: https://www.dropbox.com/s/fayg46gc9dm2ssy/KSP.zip?dl=0

    Oooh, I do hate to do this, but yep, me too - guessed relevant log lines in spoiler below:

    Spoiler

    [EXC 11:36:20.622] NullReferenceException: Object reference not set to an instance of an object
        LifeSupport.LifeSupportMonitor_Editor.GenerateWindow ()
        LifeSupport.LifeSupportMonitor_Editor.OnWindow (Int32 windowId)
        UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
        UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
    [ERR 11:36:20.623] GUI Error: You are pushing more GUIClips than you are popping. Make sure they are balanced)

    (repeated with ... terrifying fervor)

    Tested with all other mods nuked such that just USI-LS 0.5.2.0 remained.

    Also seeing an incremental addition to max crew capacity every time any part is clicked - repeatedly add and remove an (eg.) antenna (works with any part) from a single crew pod and max hab goes up by one on each click. Likely related, reverting a flight leaves a blank life support window in the vab, which appears to only reset upon re-loading the craft.

    EDIT: Forgot to say - my little kerbin-system taxi shuttle thanks you from the bottom of it's solar sails to the tips of it's cute little stubby wings* for the recycler module fix - it really is a great little module, providing just the nudge to life support efficiency needed for in-system shuttles.

    * may all who sail upon her enjoy delicious recycled nutrient paste

  10. Hi folks (hopefully this can be answered in community) - quick balance question re the RT-500 recycling module vs the Nom-O-Matic 5000 in recycling mode:

    • The RT-500 provides 60% recycling for one crew member at a cost of 0.5ec/s and 0.6t mass.
    • The Nom-O-Matic 5000 with it's new recycling mode provides 71% recycling for one crew member at a cost of 0.63ec/s and 0.125t mass, plus it has flexibility of other configurations

    Now I grant that the difference between 0.5ec & 0.63ec is not insignificant, and the radial mount of the RT-500 makes placement a little easier, but still - a ~half ton mass saving, an 11% boost in recycling efficiency, and the flexibility of other configurations seems too big a boost for the penalty of stack mounting and 0.13ec/s.

    Have I missed something? I swear I'm missing more stuff lately, I worry all those "beer kills brain cells" leaflets were right and the cumulative effect over many years is beginning to show....

     

    If I haven't missed anything then (a) yay! beer doesn't kill brain cells - cheers! and (b) I'd hate to make the RT-500 redundant as it's such a neat model and even if it's a little on the heavy side I did end up using it on my 1.1.3 Duna mission to "fill in the gaps" of the recycling setup (https://www.youtube.com/watch?v=-oRo3a9A9t4&list=PLMfeAycVYV0wcxr-5EyHWBe6asCm-YF5q)

    (edit: ksp 1.2.0.1586, USI-LS 0.5.0.0)

  11. Oh. Hell. Yes!

    This looks awesome and will definitely be in my 1.2 save from the start. My 1.1.x save (shameless plug below) frequently saw me launch fully built bases & stations direct from Kerbin, aerodynamics be damned, because there wasn't a satisfactory way to assemble in space (KIS/KAS and IR have come close, and remain excellent, but never quite seemed there - either offering too much or being insufficiently streamlined).

    This plus the MKS/USI-LS updates makes me feel my 1.2 save will be the first time KSP is, well, all I wanted it to be.

    So happy right now, so ignoring all other KSP drama right now, so thankful to all the wonderful modders & staff & staff/modders past and present right now.

     

  12. As good a place as any to thank, wholeheartedly, those who have worked on KSP past and present, those who have left and those who remain, for making my most played & enjoyed game in many years.

    All who have had a hand in this wonderful game deserve every success in their future endeavours and I can't wait to see what you do next.

  13. 40 minutes ago, richfiles said:

    Does Science mode really unlock all the skills/SAS modes? That seems odd. I'd think with a Science play through, you'd still want to unlock different technical capabilities from different probes, and maybe have some true skill differentiation.

    I'd say that Science and Sandbox mode (and I suppose, by extension, Career mode, for those who have expressed dislike for the features) might be well served by extra difficulty buttons. Basically, have a button to select whether Kerbals are equally cross trained, or if they have job specific training. Have another button to select between Probe cores with tiered SAS capabilities, and cores with universal SAS.

    I guess it also bothers me that science operations in Sandbox are completely kaputski... I gave up on sandbox, because it was, quite frankly, boring to have no goals... It's like a No Man's Sky preview! :sticktongue: Being able to deploy and use Science Labs in sandbox would at least let you rack up a clear and definable "score" in the recovered science value, even if it's not consumed for anything. Similar arguments could be said about Mission Control. Again, Sandbox has no goals, per say. It'd be nice if you could still receive missions (maybe swap out the word contract for missions, when in Sandbox or Science mode, to conceal the no money factor). Missions could be limited to science payouts.

    Yep, in Sandbox & Science modes right now the following seems to be in effect:

    • Every kerbal, regardless of specialisation, can pilot craft with full range of SAS modes
    • Every probe core has SAS capability and the full range of SAS modes
    • Every kerbal, regardless of specialisation, can repair wheels/legs/repack chutes
    • Only engineers provide bonuses to mining drill extraction rates
    • Only scientists can clean goo/material bay experiments & staff mobile labs (only relevant in Science mode)
    • And (personally, hence the question) hypothesised for v1.2 - only pilots can remotely pilot probes/ships through a comm link.

    It's a messy mish-mash which (personal opinion) originated from the initial introduction of career modes (initially career mode was what we now call science mode) and the desire not to brick pre 0.22 saves which may have had Bob on solo deep space Eeloo missions and Stayputnik probes going beep....beep.....beep.... around Moho.

    Roughly speaking, it seems abilities which were universal prior to the invention of Career mode (as we call it now) remain universal in sandbox/science modes to this day, but abilities which were tied to specific careers and added after that date are tied to those careers in all three current game modes.

    As v1.2 will see KSP further refine the roles and abilities of probes and pilots, I figure now is as good a time as any to clarify the position.

  14. On 8/25/2016 at 7:43 PM, SQUAD said:
    ...Bob (RoverDude) wrapped up his work on partial control, which can happen when a probe or crewed pod without a pilot has no connectivity to a control point.

    Probes will be limited to no throttle or full throttle, actions and events, SAS/RCS toggles, and the  autopilot settings that are allowed by their SAS level.  This means that maneuvering is still possible, but somewhat limited. Both probe cores and non-pilot crews without a connection to a control point will also lose the ability to add/edit/delete maneuver nodes.  The pre-plotted will remain, but without connectivity to a control point (or a pilot on board), it will not be possible to place new ones on the fly. We expect this provides appropriate incentives to maintain control without ‘bricking’ your existing probes, and also provides an incentive to use your pilots, even after probe cores are unlocked.  Bob was kind enough to share a shot of the updated user interface! http://i.imgur.com/l7sEIP3.png

    Q: Will the pilot stipulation be in place for Sandbox/Science gameplay modes as well as Career, or will a Scientist/Engineer be able to remotely control a probe?

    Right now under Sandbox/Science modes the ability to pilot a vessel with full range of SAS modes is universal, scientists & engineers can do it just as well as a pilot. Further, all probe cores are currently functionally identical under Sandbox/Science - with the full range of SAS modes available to all (even the Stayputnik)

    Question arises from a Gameplay Questions forum post which guesses a design intent of "everything unlocked in sandbox" which has evolved into "everything unlocked except...(mining/lab operation)" as new features are added - before we potentially add another "except" I figure it's worth clarifying.

    Personally I'm for limiting the ability to directly pilot vessels in Sandbox to pilots just as in Career, otherwise we'll have the sandbox mode giving unique mining bonuses to engineers and unique (if redundant) lab operation skills to scientists, unique remote probe piloting arrays to pilots, but the ability to directly pilot a craft being universal. It's a messy mish-mash of exceptions which made sense a few years back with a (presumed) desire not to brick v0.21 and earlier saves, but has evolved into something a bit too unwieldy as we add more career specific mechanics.

  15. 43 minutes ago, Reactordrone said:

    Scientists still have their unique attributes in sandbox as well as engineers, it's just that science serves no purpose in sandbox. I suppose universal piloting ability is desirable in sandbox so you can just throw anyone into the pilot's seat for test flights.

    Yeah, wanted to test scientists under a clean Science mode test (ie. their performance in labs) but that means levelling up a fresh save.

    Have to say I'm hovering over the submit button on the bug tracker right now, as some old v.0.90 threads suggest universal piloting skills were in place back then - 

    Wondering if this has come about as far back as v0.22ish when career mode was first toyed with (and became the science mode we have today) - perhaps the desire not to brick 0.21 saves meant everyone has unique pilot abilities but features release subsequent to that (eg. mining, science labs) can safely be tied to specialities under sandbox/science modes.

     

    edit: yeah, this is definitely an old design decision - just double checked, even the stayputnik probe has full SAS abilities under 1.1.3 sandbox mode. Think I'm going to log under feedback rather than bug on the bug tracker - I think we can safely brick v0.21 saves, but appreciate others may think differently.

    edit 2: logged feedback http://bugs.kerbalspaceprogram.com/issues/10845 - think this is an issue that's grown from a design decision that made sense three years ago that has increasingly become problematic as new features are added. Right now under Sandbox mode every single probe core is functionally identical - the only differentiator is in built torque wheel strength.

    edit 3: looking forward, with v1.2 introducing unique pilot skills under the communication array re-work, I suspect what initially started as a clear design decision of "everything is unlocked under sandbox" is only going to become more convoluted over time - we'll have "everything is unlocked under sandbox - everyone can pilot a ship and repair wheels but remote piloting can only be done by pilots, and mining can only be boosted by engineers, and all probes are functionally identical, and only scientists provide lab bonuses, not that they're relevant in sandbox".

  16. 14 hours ago, Red Iron Crown said:

    Jeb, Bill, Bob and Valentina are special in sandbox mode in that they can perform all the specialties' tasks at maximum experience. Any further kerbals hired will have just one specialty.

    Interesting, thanks. In that case we definitely have a bug as silver suited new hire scientists & engineers under 1.1.3 Win x64 definitely have full SAS pilot abilities in Sandbox and Science gameplay modes.

    I just tested mining, and what I think confirms it as a bug, is that in sandbox mode engineers on board definitely give a mining rate bonus:

    Silver scientist alone: 0.005255/s at lauchpad
    Orange Pilot (Jeb) alone: 0.005255/s at launchpad
    Silver scientist + silver engineer: 0.131371/s at launchpad (25x the rate, as expected for 5-star engineer)

    I can't see it being a design decision that engineers provide unique bonuses in sandbox/science, but that pilot skills are universal. I'll get it logged on the bug tracker.

  17. I genuinely can't remember if this is expected behaviour or a bug, so asking first before submitting to bug tracker.

    I get that under science & sandbox gameplay modes all kerbonauts start with 5 stars in their fields and thus their abilities are not graduated by experience, but could have sworn individual specialisations were still supposed to be in effect? Is it expected behaviour that Bill & Bob can fly a Mk1 Command Pod just as well as Jeb?

    Corollary - do mining rigs in sandbox/science modes function just as well with only Jeb on board as if engineer Bill also tagged along?

     

    Sorry, been so long since career was introduced and since it was my sandbox saves are usually just used for testing.

  18. Snagged a pretty shot after a couple of the taxis docked (most of the flash parts either USI Kolonization/Life Support or Near Future Solar):

    0Dj1juR.jpg

    As daft as it is I think I'm most proud of those little taxi shuttles, always seems the smallest craft require the most thought and refining, they're doing sterling work now ferrying tourists & crew between the Kerbin system stations.

    Anyway, the whole kaboodle was launched in one shot (who needs streamlining when you have boosters?) in the video below (I think the series also has those little system shuttles & other bits of Kerbin system infrastructure)

     

  19. The nuke engine masses 2.5t more. So the nuke becomes more efficient once you're hauling an extra 2.5t of fuel for your more fuel hungry terrier craft for a given delta-v requirement.

    So low total mass craft, or low delta-v requirements, will often see the terrier/poodle/etc a better choice.

  20. Gosh you're all a dark bunch with your vacuum gulags :)

    The purpose of prison is not merely security, or deterrent, but rehabilitation. Given that I refuse to believe Kerbals could ever do anything beastly to one another (they're far too cute), and therefore Kerbal "crimes" are things like noise nuisance caused by flying supersonic through a residential neighbourhood at night - the primary emphasis in Kerbal prisons would be rehabilitation.

    So drop them some place out of the way where they won't disturb Kerbling's sleep, supply them with all the tools, snacks, entertainment they need, drop a bunch of parts, KIS/KAS/Extraplanetary Launchpads, and tell them they can come home once they've built a <100db supersonic jet, or something equally ingenious.

×
×
  • Create New...