cakepie

Request for poll to be stripped from http://forum.kerbalspaceprogram.com/threads/92064 please Thanks in advance!

I'm not super keen about adding fuel, because: - additional game balance issues to consider - additional craft balance issues -- LF and OX are 5 kilos a pop, monoprop is 4 kilos -- so it'll entail adding nontrivial amount of mass; weren't you having already trouble with front-heavy craft a little while back? - personally from a flavour standpoint I'd prefer not to place fuel in a part of the passenger compartment. Battery makes more sense; but the stair itself doesn't consume any electric charge when operating, so this would primarily be for the rest of the craft. I'm not sure how much utility this has in vanilla KSP -- in my own vanilla play I've hardly ever faced a struggle to ensure sufficient electric charge on a manned aircraft or spacecraft. Space station or satellite, yes, but stairs inapplicable in those cases. There are some use case for bases and landers, I think, if you're doing a bunch of science transmissions or have a science lab attached. Rovers, yes, power for the wheels -- but that'd be a pretty big rover! If you are playing with other mods, though, the extra battery capacity could be quite handy, e.g. life support mods that require electric charge, or lots of KAS winching. The generator idea is pretty neat from a flavour POV, it'd basically be like an aircraft APU for when engines are not running. Utility might be a bit lower than battery, though -- for spacecraft I think most people would rather use RTGs or solar panels than cart around a load of fuel to burn for electricity -- the dV hit isn't worth it. So mainly Kerbin-bound aircraft, unless you're rolling with a mod that does resource mining and in-situ conversion into fuel. To be clear, I'm not out to shoot down your ideas, just want to discuss some pros and cons and see if it makes sense. I do really like your train of thought about adding more functionality, because the airstairs are primarily a cosmetic alternative to ladders -- which, remember, are massless in stock -- so once you take that out of the equation, you're basically left with a dumb piece of structural fuselage, i.e. dead weight. Making the part more useful = good. I am definitely going to give some thought on battery and APU. Plus, I've got a potentially good one: how about a module manager config to add KAS support, making a cargo/baggage compartment using KASModuleContainer? Pretty good fit, I think. I might even toss in replacement textures that add a cargo door at the bottom of the fuselage (although functionally KAS containers don't have a "door" per se). The one huge downside here is the dependency on another mod -- this feature would be pointless for people who don't use KAS. That is a real shabby way to treat paying passengers. The last time I saw passengers on the wing of an airplane, well, you know... A spaceplane version is part of the plan for the future, though I think I will wait for 0.25 and then design to work with the new spaceplane parts (which are, of course, based on SP+). For now the priority is to get the first version polished up and rolled out. There's also a bit of plugin work I'd like to do here, though I'm not ready to discuss that at the moment. Also, I expect it will take a bit more work to design for the different form factor. With this round fuselage version, it's basically working with the proportions right out of the Lockheed patent, and the stair height fortuitously lines up nicely for stock gears. With SP+ style fuselage the stair will likely need to fold up and stow away very differently than it does in this version -- that's going to take some figuring out. Sure it would be easy by either telescoping the stairs or magically scaling them, but I refuse to cop out like that -- I want the stair to fold, and I want its physical dimensions to remain fixed.

Finally done editing the longer version! While we're at it, the airstair part has been updated to v. 0.6.5. Check it out at: http://forum.kerbalspaceprogram.com/threads/92064

v0.6.5 has been released! This is an aesthetics update; it adds normal maps for the two existing textures (KAX- and Firespitter-like) so that parts of the texture appear raised (e.g. bolts and rivets) or recessed (grooves and holes). Feedback about how it compares to the previous look will be much appreciated. (New users: you can download v. 0.6 here to compare the two.) Changelog V 0.6.5 released 2014-09-15 Added normal maps to textures.

Yes, I did suggest for it to be an option -- I realize a big part of the new design is to be able to dispense with the control bar. Yes please. Backslash is dangerously close to backspace on a lot of keyboards.

By which you mean the control bar? Perhaps I didn't explain it well when I said "force control bar to be enabled" -- it's not to have it "always" open! What I meant is, in flight mode, the stock app launcher tool bar button serves as the 1-click master show/hide for all of Engineer. If Engineer is toggled off with app launcher, nothing (that includes the control bar) is displayed. However, when Engineer is toggled on with app launcher, the control bar will be show, along with whatever other windows are enabled, and the control bar serves as the place for toggling the sub windows (and docking them if not floated), in place of the Flight Engineer dropdown. There would be a really clean solution if only app launcher would just add the ability to distinguish between left and right click rather than straight up toggle and hover -- left click for 1-click toggle, and right click for the detailed dropdown.

Great stuff. Picked this up because Ship Manifest support for CLS seems spotty at the moment, and I don't really need resource or science transfers (have other mods for the first, and mostly sandbox so no use for the latter). I still keep Crew Manifest around for it's "Fill Vessel" functionality, though. Also, minor grammar nitpick, error message for "Part's aren't connected" should be just "Parts" without the apostrophe.

FYI, Connected Living Space no longer supports toolbar, should be removed from list in OP.

Any chance that v1+ will have an option like in v0.6 to use Blizzy's toolbar, or will v1+ only support stock toolbar moving forward? Blizzy's toolbar still confers advantages in being able to move, rearrange, and show/hide buttons. Also, imho stock toolbar doesn't scale well yet -- when more than a couple of mods' buttons toggle a show/hide on mouseover or mouseclick for a dropdown window directly below the toolbar, I find that the different windows jockeying to be on top can be rather finicky to use. And of course, for people playing with Flight Engineer in module mode, when flying a craft without the required engineer parts, the stock toolbar will still display the Engineer button (albeit disabled). Anyhow, if support for Blizzy's toolbar isn't going to be added to v1+, I would second micha's suggestion above, which can be accomplished by an option for "One-click UI toggling", i.e.: - disable "Flight Engineer" dropdown menu in upper right - force control bar to be enabled - bind the toolbar button to show/hide As micha said, this would provide one-click show/hide functionality, rather than having to click once for the dropdown, then again to show/hide the rest of the interface. It would also mean one less UI element competing with others for screen real estate in the upper right in flight mode.

You should probably update the README.txt as it still reads:

I really don't see any good way to structure the challenge around infiniglide. Judging whether infiniglide is/was a factor in an entry is murky water that I do not wish to tread into. So between accepting that infiniglide is possible, vs. barring stock aero attempts altogether, I choose the former option in order to enable wider participation from players who do not play with FAR/NEAR. If infiniglide bothers you, you can just ignore the stock aero leaderboard -- it's not like it does you any harm. And there's nothing stopping you, or anyone else from proving your chops with FAR enabled to prevent infinigliding.

Nicely done, added =)

I brought a payload too, should be good for Utilitarial Commendation, right?

Very nice! I have regular crew transfer working with Crew Transfer mod, so you've probably not set up your connected living spaces configs correctly.

Are you calling it fat? More seriously, though, thanks for trying it out and giving feedback. What would you suggest is more reasonable? For comparison, consider these similarly sized stock parts: an empty Rockomax X200-16 weighs in at 1 (kerbo)ton presumably, flavour text for this would be the outer shell, pressure vessels for LF and Ox, and some plumbing [*]the PPD-10 Hitchhiker weighs 2.5 tons flavour-wise, outer shell, pressurized cabin, life support and other equipment, supplies, crew. I pegged the airstairs at 1.5 since it should comprise the outer shell, pressurized cabin, stair and associated machinery, plus whatever else (in the real thing, I believe it's generally some baggage compartments and a couple WCs, and I think some A/C equipment in the hold area, IIRC) I guess I could reasonably take it down to 1.25, but I don't think it should be as low as an empty X200-16 tank. Can you please do me a favour, edit your part.cfg with a reduced mass of 1.25, give that a shot, and tell me what you think. Additionally I think it should be noted that the Firespitter bomber parts and the KAX medium cockpit & fuselage parts are not really balanced the same so there's definitely part compatibility issues arising from that Firespitter Bomber Cockpit: 1.2t Bomber Fuselage: 1.2t dry, 500 LF capacity Bomb Bay: 1.2t // because structural fuselage was deprecated in the most recent release KAX Horizon Cockpit: 2.75t Heavy Jet Fuel: 0.35t dry, 1200 LF capacity Heavy Structural Fuselage: 0.5t Stock Mk3 Cockpit: 3.5t (excluding monoprop) Rockomax X200-32: 2t dry, 1440 LF + 1760 Ox capacity There's some mismatch going on there, definitely -- KAX numbers are closer to stock, while FS is a bit on the light side. So mixing these parts will lead to more challenging aircraft balancing. One does not simply replace FS K-17 bomber cockpit with KAX cockpit and still fly! I've encountered similar difficulties as you've described (i.e. front-heavy) while building craft with a mix of FS and KAX even without the airstairs. In view of that, the other thing you could try is to counter-balance with a bit more weight to aft -- for an example of a reasonably-proportioned aircraft using KAX+airstairs, you can take a look at my video in this other thread -- there's a bit more footage of that including take off and in flight but I haven't got around to finishing editing it yet, though.

I usually play with FAR, but since I've been testing stuff and doing a few challenges in stock aero lately I figured I should get my K Prize while I was at it. The Kolibri: 6.5t, capacity: 1 kerb; One turbojet, two intakes; two Rockomax 78-7S. LF:381 Ox:283 plus the 7.5 monoprop built into the cockpit for docking manoeuvres. Today, we'll be flying with a small ion-powered science probe and ... a couple of chairs? you know what's coming, right? Launch preparations; Jeb with the preflight checks. Payload works out to 580kg. Horizontal takeoff, zoom climb, then level out to a more moderate climb in the mid- and upper-atmosphere. Rockets on at 21km, turbojets off crossing 31km or so. Coast to apoapsis. Circularization to approx 70.5km circular orbit. Payload deployment. The drone should be capable of taking care of itself from here on out. Here, have a couple of random pretty pictures Next stop, Unity Station. Disclaimer: This being a fresh stock save, I cheathaxed the station into orbit beforehand. Matching inclination, because the SSTO launch was just slightly off. Waiting to catch up to the station from below, then burning towards its altitude, aiming for approx 1km separation or so when we begin the final approach. Approaching the station. Note to self: pack an OX-STAT next time, reduce concerns about reaction wheel power consumption. Stationkeeping about 50m away. Docking port deployed in preparation. Docking manoeuvres. On hindsight, the arrangement of RCS blocks at the front only is a bit inconvenient... We're here. Why are we here? To pick up Bill and Bob, of course. All set for departure. Boy are Bill and Bob happy to be going home. Unity station slips ahead under us as we burn retrograde to slow down and drop behind it. Entering the atmosphere. The boys seem to be enjoying the ride... ... a little too much, perhaps. Lose a bunch of altitude and turn back toward KSC. Now you're complaining? I don't get you, Bob. Let's get this baby back on the ground. Some post flight fuel / craft stats... Obligatory photo op. tl;dr: to 70.5km orbit with small probe payload, docking with station at 80km, return to landing on runway 27.

PartCatalog is not actually bundled in the Firespitter download. That PartCatalog folder that you see just contains a couple of icons that you can use to represent Firespitter parts in the PartCatalog tabbed navigation. You can safely delete these if you don't use PartCatalog.

Glad that was of some use to you

Glad to hear that your PC isn't as damaged as it initially seemed, Monthar. Will be awaiting your attempt. As for stock aero quirks, infinigliding, etc -- my policy here I guess is, if you're patient enough to try it and pull it off (without breaking the rules), I'll give you the credit for doing so. Should be pretty obvious I usually play with FAR rather than stock aero, so I'm not as familiar about the various tricks you can pull there. Heck, I initially planned on a FAR-only challenge, but then decided to make it more inclusive. That sounds about right to me.

I made this short parody clip to showcase the mod airstair part I've been working on: (The rest of the craft is mostly stock and Kerbal Aircraft Expansion parts, and maybe a couple from Firespitter.) Here's some Lockheed L-188 Electra archival footage for comparison: It's my first attempt capturing and editing video from KSP, so please be gentle (Yes I know about the stupid cursor. Sorry!) If you'd like to check the airstair part out, it's over here.

Glad that takes care of it, mike9606

I guess I'm still thinking about it from the PoV of potentially large numbers of actions/activities that need to be separately tracked in order to prevent exploitative repetition. I don't know how many of those you have in mind. I'm also considering that you'd want this to be extensible by other mods. Besides mods that want to know the well-being of a kerbal, there may be mods that would like to add activities for kerbals too. So I figure you'd need to be prepared to handle arbitrary numbers of trackable activities, each of which would need its own "EVA-Happiness" variable. Hence my instinctive response is a dictionary approach. Ultimately, you're right there is a memory/storage vs time/complexity tradeoff and obviously you're in a better position to evaluate that, having put a lot of thought into this whereas I'm just working off gut responses (e.g. "whoah seems like there might be arbitrarily many tracking variables")

Using cooldown time sounds really promising. Repeating an action increases time left on the cooldown "timer" and diminishes the benefit proportionately; timer can be forgotten once it reaches zero. This way you'd only need to track the actions that are still on cooldown and forget the rest, rather than constantly maintaining a separate stat like EVA happiness for every possible activity [edit: in order to cap the benefit obtainable from any one action].

Ah, I see, so it's going to be some stat increase per activity, and decay over time. That may be exploitable, though -- for instance you'd be able to boost stat by repeatedly doing some token "exciting" activity such as taking a Kerbal on EVA just out the airlock and immediately go right back in -- flavor-wise that's not really doing anything meaningful (and might actually be mundane if that's the only thing you do repeatedly). Without some kind of history you wouldn't be able to tell the difference.

For how long a duration do you intend to track the "activity history" of what each kerbal has done in the past? Your ideas seem to suggest quite a fine granularity of tracking, including orbit/SOI, craft, EVA, part of craft that the kerbal is "living" in, etc, so my first reaction is that it might get costly to keep track of a long and detailed history.