dnbattley

IMO, this thread deserves a TOTM visibility boost... I only happened across it while posting my own thing and, while I haven't watched the whole movie yet, am enormously impressed by the thought and care that has gone into making it look so effortlessly stylish. @Dman979

I suspect the answers are decals, transparency, and/or a concealed k-drive, but feel free to ask!

... Now expanded into a short, but full, motion picture

A short video made using stock 1.10 for your midweek enjoyment...

Nice! I now have a submission too: behold the "fake space ship" Liberal use of custom flag decals with a concealed k-drive to power it... and I'm very happy with how it turned out!

Did you wait on the launchpad or launch immediately? After a few days on the launchpad it seems to update and give you a new target orbit, which presumably indicates the divergence onto the new mission path, and this may have caused the issue if you have not been recognised to have opted to do so. For the record I just completed it, at silver (despite landing within 20m of the target... it must have some very tight tolerances needed to get a gold score!). I also noticed some odd artifacts on the navball: markets looking the wrong colour and an "overlapping sprite" effect on the central marker.

I've found k-drives work quite effectively for that "star wars take off/hover", even if they might be seen as physics abuse otherwise. https://kerbalx.com/dnbattley/Falcon-IV

Initial view: the most interesting feature of flags for me is the low mass: we now have a 50g part on the smallest flag. Self interaction is possible but only through action groups and not via context menu (this is possibly an oversight on the Devs part and may be fixed later). Separately, the Klaw jr is very interesting part: lower mass than 2 jnr docking ports and a 50 m/s impact tolerance offers potential as a rather nice landing leg...

Beyond making a craft that resembles the picture and which can get to orbit, I'm unclear what the actual restrictions for this challenge are: any chance you could clarify please?

I'm rather hoping that flags can be used as even lighter landing legs...

With a slew of new parts incoming, this is a simple challenge: to push these parts beyond their intended purpose for entertainment and productive purpose. How far can you go? What does too far even look like? The magnetometer boom looks to have good potential, but flags and farings may introduce other exciting possibilities...

Lots of speculation here, with the only facts available being that parts will have a "cost" in terms of raw materials, which it is also possible to stockpile, but in certain circumstances or game modes, as shown in the picture, stock of raw material is not available or relevant. It seems likely to me that we were seeing a sandbox mode in the image, hence the "-" stock, but I accept the possibility (albeit one I see as less likely) that in all game modes stock is not relevant from the "home" location. More likely, I think, in non-sandbox mode is that missions will offer materials from which the player is free to make rockets, and efficiency is this rewarded with excess material to undertake "off-contract" missions. But we will see. Either way, I am happy to see the existence of a (non-cash, in this case) "cost" for building in circumstances it can be made available, and fully expect this to be able to be disabled for players who do not like this limitation.

Also... ISO-8601, amiright?

@RyanRising @AlamoVampire Please allow me to clarify that I neither object to, nor offer judgement on, players spending millions of credits building super-size rockets and missions. My point was that design efficiency and cost-related compromise is a fact of (real) life and, for me, the additional restrictions in career mode offer an additional dimension of play, not present in other modes, which I appreciate, and which has heightened my awareness of such inefficiencies. I personally believe starting in career has dramatically benefited my design building skills, which persist even when playing in sandbox, as I now more commonly do.

Wrong forum for this debate, friend.

There is a core resource that all players have in infinite supply: time. This is why I am in favour of a mechanic that drip feeds income over time, as it means that players who want to take cash seriously can measure their success (e.g. by achieving some milestones earlier than players who are less efficient), but players who want to launch million-credit monstrosities can do so simply by accelerating time sufficiently.

Thanks! hearing the concern what about this evolution: all missions simply generated revenue over time, provided that you launched a rocket within a month of the last payment, otherwise that payment ceases. Again, you could, if careful, build up a huge revenue from multiple overlapping mission payments, but if you decided to drop everything and focus on an interplanetary mission then by the time your mission returned your previous income would have fallen to zero, though that mission itself could now provide an ongoing income so long as you launched again within a month.

This is an excellent post, and adds a lot of value. Firstly I agree with the characterisation of sandbox players as building without consideration of money: I often watch Matt Lowne's (excellent) videos and giggle at their absurd cost: e.g. 200k to get to Duna?!? What??? I agree that a mode that forces design compromise adds depth to the game, though it was always an issue to me that the "normal" mode rapidly becomes too easy, while the hard mode starts off too tight for cash (I also realise you can set custom levels, which I do). One option for rewarding play/avoiding grind is for an "automatically repeat mission" option: once you have succeeded (once? twice? more?) in a specific mission with any given vessel, you should be rewarded with a function that allows that type of mission to be automatically "harvested" in future using the exact same craft, which can happen "off camera", and which reduces your cash by the cost of your vessel initially and then adds the recovered amount and reward back subsequently. This introduces a cashflow and timing consideration for your missions, and a further twist could be for an RNG "mission fail" event which adds no reward back, the % chance of which you can see before toggling the "farm this mission type" button. This turns an initial success into a revenue stream (with a chance of any event resulting in a cash burn only - hence needing the player to consider what their reasonable "buffer" should be - obviously not enough cash means the farming mission won't be launched), and over time could compound with other missions you choose to harvest in order to progressively increase your income (and make it a recurring form of income) that still limits your choices without leading to a bankruptcy scenario, and also rewards careful players with, potentially, faster progress. You could also dramatically increase the cost differential between small and large components under this scenario.

Thank you: I had just finished writing a mea culpa about that...

A healthy debate seems to be raging in the community regarding how KSP2 is coming along. I share some of the concerns, while at the same time being far more relaxed than others. I am sure the developers are seeing these debates too, and I hope there is some discussion around how best to update the community regarding their progress. However, there is one really important question that I am keen to know, and that is have the developers determined the UX question of multi-play vs time warp? If they have, then I'd love to know how, and if they have not then I'd have serious fears as to effectiveness of the design process, as this question gets to the heart of some pretty fundamental areas within the philosophy of KSP, and by extension will heavily influence the design parameters of the underlying physics engine. I'd like to explore these with this forum, and invite thoughts and comments to see if the collective brainpower of this forum can help in any way. So what is the problem? Well in a nutshell, we take it for granted that KSP uses "real" physics. That means that, absent the cheat menu (or equivalent mods), you cannot instantaneously move from point A to point B: to do so takes time, design (i.e. dV) and skill (manoeuvring). Time spent traversing the vast interplanetary void can be compressed into a human-enjoyable span through time acceleration. This puts the a god-like power of time compression into the hand of the player/observer and, for KSP1, just works. Well what happens when there are two observers? Well if one is strictly an observer, and one is a player, then we have the situation of watching a Brad Whistance or Matt Lowne YouTube video: one observer entirely devolves authority to time compress into the hands the player, who uses that power as they see fit for their enjoyment/control and for the benefit of their audience. Similar authority could be envisaged where players are cooperating on a single vessel/goal and one player is assigned a role of "captaincy", but the crucial point is that role has the responsibility, and would typically be trusted not to want to time warp their vessel into a planet at max speed - deliberately or otherwise. This would be possible as a multiplayer solution, but how roles would be shared and defined would significantly determine the viability and enjoyment of the players. What if other people don't want to hand over all time-compression authority to another player? If two people are simultaneously and actively playing on different vessels, then their flight characteristics, and hence time-compression wants, will be different. For two players a compromise should be straightforward: player 1 could highlight that they want to accelerate time, player 2 could either agree or disagree. Where they agree time can then accelerate to the lowest accelerated speed they both accept; where they disagree time remains in the lowest speed needed by either of them (which is probably, but not necessarily always, single speed). Given minute changes in dV can adjust the time it takes to intercept with a planet from seconds to weeks apart, this could cause some challenges on a multiplayer mission. This already causes some problems for both players, making the experience slower and potentially less enjoyable, but what happens when there are 3, 4, or more active players in a single game reference, each of whom are making active or passive choices to change game speeds. Very quickly the likelihood of all players finding unanimity drops to zero, and that's before you consider the possibility of AFK or "trolling" influencing the situation. In that situation, envisaging a "large scale" form of play, one spanning any significant distance, becomes difficult at anything other than "real time" speed. Ok: so each player chooses their own speed: problem solved? Not really: that solves the single player experience but makes the multiplayer interaction little more than the ability to see "ghosted images" of where players would have been or will be. Meaningful/physically accurate interaction between vessels in space becomes near impossible, and the multiplayer experience is reduced to short-term flights around one or more agreed "rendezvous" points. And even then, within those points the interaction can only be between players consenting to a single time reference, so you would not see, for example, a player screaming in from inter-planetary space to seamlessly join in with multiplayer action, unless that person was willing to accept some for of "time-slippage" where they move from control over their time reference, to not controlling it. These "bubbles of unreality" would partially solve a multiplayer requirement, but arguably run counter to the ethos of KSP, where reality is, broadly, a "firm" concept. So multiplayer in a "realistic game" is impossible? It's hard to answer that: certainly you cannot require that people give up their lives to "feed the tamagotchi" of a mission that happens to need to require all participants converge on a single point in real-time over missions that might last weeks or even years of in-game time if they do not have any control over that reference time, but equally you cannot easily compress time universally to the enjoyment of all players, without giving them individual control. Flight simulators have certainly found solutions whereby voluntary "bubbles" allow single-reference interaction if a player so chooses, but those are arguably quite specialised games and may not appeal to all of the KSP demographic, and (going back to the original point of this post) almost certainly needs to be coded in from deep within the game engine. A multiplayer mission to the Mun, for example, would be fundamentally different to a multiplayer experience of players flying planes around the KSC. And also incompatible with each other. Could a multiplayer approach accommodate both? Possibly, but you may need to decide which "version" you were playing prior to launch, and would easily become quite confusing for players. So what do you think? Am I over-stating this problem? Are there other solutions? This is where your comment below can help...

A follow up... on the moon!

New budget constraints have forced the administration to outsource all flights to 3rd parties in a unique public-private space partnership. In securing the lowest bid, the administration have agreed with the private providers that all payloads must be constrained to no greater size than a CRG-04 (the small Mk2 cargo bay), though multiple, separate, CRG-04 payloads may be launched in pursuit of a mission. Challenge #1 Launcher Bid You are the bidder, and your mission is to meet the particulars of the bid by designing and building a CRG-04 payload capable craft for the lowest ongoing cost. You must be able to take one or more target payloads from the KSC to an 80 x 80 orbit to deploy. Your mission cost will include recovery costs, so it is likely that SSTO designs will be efficient, but you should also confirm the largest dummy payload that you can carry, and which must be at least 2.5T (though payloads higher than 3.5T will net the executives a performance bonus, so they are applying some hints that you should do that if you can). While the bidding process calls for cheap payload-to-orbit submissions, Jeb is on the committee and doesn't want to be seen flying anything "uncool" (his words, not mine), so see what you can do. Challenge #2 Payload Bid You are the KSC, and are trying to persuade the administration to sign off your mission. Therefore, your goal is to put together a "simulated mission" (i.e. to fly it) for a design of your proposal, as constrained by the CRG-04 volume limitation. You may take any number of CRG-04 payloads (each of which must be assembled in orbit), and weight is not explicitly limited, but part offset is, as follows: you can offset but must not overlap any parts of significance (as defined by their mission-critical resource/functional usage - purely decorative parts may be offset freely) to any obvious degree (e.g. you could move a docking port *slightly" into its connecting part, but not so much that the visible section of the port itself became obscured). Being publicly funded cost is no object (!), and proposed missions will be presented by location, with the most prestigious (and/or inventive) mission plans rising to the top of the list. Full bids, combining challenge 1 and 2 are encouraged, but not required. Challenge 1 only participants may use ore canisters or other weight proxies and Challenge 2 only participants can, if they really wish, simply cheat their individual parts (in CRG-04 farings) into orbit, and assemble from there. Otherwise, normal rules apply; No cheating (beyond that specified above); Scouts honour; DLCs permitted but not required.

I don't see any problems in what you suggest: I'd love to get a source on the re-write point, as I hadn't heard that from the developers, and indeed if you look at the KSP 2 Develop story trailer it is quite explicit that we are seeing "pre-alpha footage" and "pre-alpha gameplay" complete with ringed planets and new engine types. That alone appeared to suggest they were significantly advanced on the (new) game engine - which was the starting point for the theory that we were simply seeing re-skinned KSP1 in the footage - and the fact that the original timeline (at that point) was far too ambitious to suggest the project was only just starting then. Now I agree that game development of a complex game will always take time, but the change of developers/hiring new staff and changing dates is far from "just game development being game development" - unless you have a far more chaotic (pun not intended) assessment of game development than I. Of course I might be wrong, and it *is* just a hypothesis, but absent the evidence of #1 then I see no new information that can confirm or disprove it.

I'll re-quote myself from early February (additional emphasis added): Since then, we've seen the developer change (ST staff brought in house to T2; new hires made - including for core physics engine coders) and now this acknowledgement of a significant delay: I see my hypothesis as still being supported by the evidence, but still remain confident that the end result will be worth it.

A nice day means it's time for a relaxing ride around the KSC... (Cross posted from the subreddit)