LorenLuke

Firstly- Every game that has multiplayers will have grief. But not every multiplayer game is mechanically built around preventing grief. And not every multiplayer has the same amount of grief, per capita of community. But those games do not tank because of lack of grief-countering mechanics; the players moderate, curate, and police themselves. I don't expect that to be any different here, and if you're worried about people griefing, the rules are simple- ensure everyone you play with is vetted and trustworthy, and (using the EVE axiom) do not fly anything you do not expect to lose at any point in time. Malicious behavior and accidental staging, especially in Ironman/no-reversion contexts suck, but we manage; next time (hopefully) we've fixed the mistake and rectified the conditions that caused that (which would include giving any mean-spirited sod the boot). Things like autosaving, and permissions (both in VAB and in flight), or vessel protections (making 'protected' vessels that cannot be interacted with by other players) can always be implemented, but can all be supplanted simply by being on guard against who you play with. Secondly- One of the things that I'm glad to see is people suggesting the notion of multi-crew (aka 'One player, one kerbal'). Given what was released in breaking ground (and what's possible in the Kerbal Attachment System and Kerbal Inventory System mods) EVAs would be much more involved (and possibly involve a good amount teamwork), plus what we know is possible as far as IVAs (thanks to things like to MOARdV's MAS and RasterPropMonitor), being able to delegate certain responsibilities in multicrew to certain seats. But one of the things that I've been wanting, and would love to see built-in capability to do would be a 'pilot and ground crew' multiplayer. Certainly not as exciting as the other multiplayer, but still would be fun as far as I'm concerned to have people monitor telemetry and look over flight data while we have the pilot stuck in the cockpit view (plus things like 'Oh, Scrap!' random failures or the like might mean that a competent ground crew would *actually* be considered a boon for the pilot) for a sort of cooperative, yet asymmetric, multiplayer. Plus the ground crew being the only other players, such wouldn't be so dramatically affected by any timewarpage.

You have the unfortunate implication of what a DLC (or an expansion pack, if you remember those days) is supposed to be- an addition of content without an addition of mechanics. For strategy games, a few new units and at least one new campaign; for base builders, new buildings, and so on. Some might tweak some mechanics (like how to achieve a cultural victory in Civ V DLC), but it's still fundamentally the same game. Adding a DLC that adds mechanics, from a game design perspective, causes problems because you're delivering (and having to maintain) two different experiences to two sets of players. Imagine if 'career mode' was DLC. That means that you have to develop the one without career into something more interesting... While also making career mode interesting enough. So when we consider that, what can really be added but 'more parts'? A logistics game is a changing of genre, and I can't imagine what else would be added otherwise.

As I've heard someone else mention somewhere on the forums, and I side solidly with them, MP should be no more than something like 4-6 people a server. Note that in my stance, I interpret this as 'vessels', ultimately leading to the statement that, I don't believe there should really be more than three, maybe four active vessels on a server at any given point, and just have many of the players be support staff or multi-crewing said vessels. Personally, some may find that a bit limiting, but it's the best solution I can conceive of to still preserve time-warp without worrying about having 1) desync, or 2) having absolutely no time warp.

I mentioned this in another thread, and I'll mention it here. I believe the best solution to be a DEFCON style timewarp, where it always goes as fast as the slowest time acceleration any one player has selected. My ideal case for multiplayer would be a server of no more than 6-8 players at a given time. Furthermore, if 'multiplayer' is 'one player per kerbal' and they're all on the same craft or you have one person on a craft and there remaining players are ground crew (mission control), again you find no issue with time warp because of the focus on the singular vessel. Multivessel multiplayer might have issue, but since it moves at the slowest speed (not always 1x) that any player has selected, it's a workable fix, if not most ideal. That said, nobody ever was jarred into a reactive/reflexive panic because things started going slower than they intended.

All 3 are multiplayer, strictly speaking, as the multiple Kerbals makes each Kerbal a player, and the ground crew would each be players where having certain readouts or even a ground track would make it more fascinating to do (I mean, imagine if your dude was just the equivalent of an EVA Kerbal in this scene- I still think one could achieve goodly amounts of gameplay from that). Iit'sjust that there exist no current mechanics to support a player in those latter roles. As for multiplayer mods, the suggestion was to roll in rudimentary functionality for such things (or even just make a generic MP for multiple Kerbals/ground crew players and have the mods do their own infrastructure around it).

Therefore a successful, established company should upend one of the practices that got them to this point in time. Think what you're asking, here.

As had I. I can't for the life of me determine how disproportionately little it comes up, so I try to advocate it in any such discussion, but it always seems to be 'Multiple crafts for multiple people', and never 'One craft, multiple Kerbals' or 'One Kerbal plus vanilla ground crew with telemetry', the latter of the two being far more interesting to me than the specific application of multiplayer that everyone seems to harp on. Given that everyone is, more or less, focused on the same craft, the DEFCON style timewarp ceases to be an issue. Coupling this with what provide mods makes it even more engaging for the single vessel group, having actual IVAs (something akin to Raster Prop Monitor, not just a draggable throttle), more EVA actions and personal inventories (KIS/KAS), software engineering to view functions of certain craft (kOS), and couple this with the ability to control the craft only from certain seats and to switch to and from those seats, you have a much more engaging team play experience with necessary division of attention and responsibilities for better play without even having to leave your own singular space program. EDIT: Also, a failure mod (Oh, Scrap!, or possibly just one's own mistakes in the realm of KSP) and/or life support (TAC-LS) makes trying to mitigate things from the crew and mission control point of view for those 'Houston, we've had a problem' moments provide potential for some of the more gripping cooperative multiplayer moments, which are just as, if not more, engaging than any multi-vessel multiplayer KSP could be, IMO.

Honestly, the best thing I can think of is to just do what DEFCON does- time moves as fast as the slowest player-selected timewarp setting, e.g. player 1 has 10x and player 2 has 1x? Moves at 1x speed. Player 2 bumps it up to 100x? It stops at 10x. Because nobody ever was as horrifically jarred by time moving slower than they wanted it to.

Is the fact I think that probes should come first for space exploration a fault of my thinking rather than that of the tech tree, because my ideas don't just happen to align inside this box of possibilities that can be done? Could not that be the fault of the tree for not allowing such a playstyle, instead of expanding the available, feasible styles of play? You do get quite the science glut at the start of the game if you choose to thoroughly explore Kerbin and the KSC (ironic since, not only do you live on a supposedly explored and colonised planet, apparently the Kerbals are learning things they didn't know about the very place they work at). But then you get this strange effect where the expenditure of effort to available science takes a nose dive. You can attempt to biome hop, hoping it doesn't foul your mission and your Kerbals' chances of getting back safely... But the cost requirement per science of a Mün lander seems to jump dramatically over LKO exploration. However, science does yet another odd thing as we branch out of Kerbin's SOI, it increases again, where a probe telling you that, predictably, the space around Dres is cold, has no pressure, and make liquid goo freeze is so much more groundbreaking a discovery than saying so about Minmus. The problem comes from the gameplay loop of exponential gains which supports exponential exploration. The whole of gameplay is 'spend points to get places, get points from getting to places'. There needs to be an alternative or more balanced, linear path to collecting science, rather than this sort of 'sideways hourglass' that bottlenecks us into cheesing the KSC on harder difficulties to get anywhere.

The problem of science is multi-faceted, and while there are parts you can dissect, it's worth noting that one may need to consider binning the entire thing in lieu of something else. I'm going to make to a few points to note and consider possible alternatives (which may require corresponding mechanics to interact with them). Point One- 1) Bar mobile labs, contracts, and asteroids, there is a finite amount of science obtainable in the Kerbol system. 2) There is a finite amount of science to spend. In MMOs there exists systems to generate and destroy in game currency (called taps/faucets and sinks, respectively). Effectively we have science taps, but no science sinks. If we had mechanics like scrapyard, where you have an inventory of parts that are built and can be used, as well as that of the Oh, Scrap! random failures mod, using science to research/increase part reliability for a type of part and a specific instance of part will provide that sink. Point Two- The tech tree and tech nodes. I can understand things like the Nerva costing what they do, or rockomax boosters coming after the lighter faire, but having to spend 65 to get any sort of probe core, and another 90 to be able to get a rechargable power source is right out in my opinion. Having more parts to where I can start with, or spend the 10 science to get, enough to build a very low level plane, probe, solid rocket, etc. Sort the tech tree into part classes and types with each low level available- solid propellants, fuel tech, structural reinforcements, probe cores, capsules, space planes, reentry tech, EVA tech, science processing, and power systems, so the result ends up being more nodes, but less restrictions on the paths you can take. Want to not do planes? Great. Want to focus probes? Great. It expands the play style options to suit player decisions rather than force them into a box. Point three- There's no universal way to convert straight resources from one to another either instantly over time. There's some strategies that enable conversion of science and prestige to cash, but not the other way. Personally I figure I should be able to pay my science monkeys to do more research with a bit of all my money, but they don't seem to want to take it (plus, the conversation can function as another sink). Add these three things and I believe, if nothing else, it still would be a better system than what we have.

I hope you'll still be on the development team.

@Andem, @KAL 9000 The primary useofs a microphone is used by mission controllers to communicate to each other during missions, the mission PAO to telecast the stream, and the Astronaut to speak to the CAPCOM. If you don't fit into these roles, the usage of vocal communication is completely optional. We use discord's built in chat client primarily during missions, but otherwise would use Skype for the majority of text communication. We use discord for all the mission controllers, with the CAPCOM and the Astronaut being on a separate VoIP utility. Given your statements of not using a microphone, we have several groups that don't necessarily overlap with the above, though due to our membership some of our members serve multiple roles. That said, we can always use more hardware (payload/launch vehicle) developers, software developers (using kOS), press corps (press report releasers), and mission planners (flight trajectory and geometry nerds). Feel free to contact @ZooNamedGames if you're interested in any capacity.

More people is always good!

The mission timeline falls largely to the LOD and the FAO. Mission planning is getting it there in the best way possible. Example: free return trajectory from a lunar flyby, any sort of required Delta-V calculations. Basically, you're putting the theoretical maneuver nodes in place before the vessel is even on the pad.

There's always room in flight planning, as well as for hardware (payload and booster) development.

Guys, Clifton started he's getting his wisdom teeth taken out on the 25th. Whose going to fill in to stream/PAO? Edit: assuming we're go for this weekend.

There's problems applicable to both. The primary thing is scale. Whether you want full scale or simple scale is up to you. Besides, it's not like there's a massive difference or difficulty in going from someone who doesn't have mods to someone that does.

24th, I can make arrangements. 17th, I can't.

If nobody has taken it yet, I'll snag Tracking.

Materials Bay observation is the experiment for the Science Jr. 9001. So it stores itself, but nothing else to my knowledge.

Ah, so you're just looking for flat experiment data storage in the probe core. I'd say that if you do so, it only stores the data (i.e. the transmittable stuff), for non-resettable experiments, as you cannot physically return the goo/materials as you could in a compartment on a crew capsule.

Would this part run and store its own experiment (maybe some analogue of a crew report) or aggregate the data into a singular storage space? Because if you're doing the latter, how are you going to physically move the data from the experiments?

Ah, already done on my end. So I guess you can add me to potential mission crew, also.

Which port number?