Dunbaratu

Correct. There's two things wrong with calling flags "flights in progress": 1 - They're not flights. 2 - They're not "in progress". I'd rather see this problem fixed by addressing #2 and #1 as two entirely separate problems. Why? Because flags aren't the only things with these problems and when solving them, the solutions should be applied in as properly generic a way as possible so the fix also fixes things that aren't flags too. Take for example, a rover that is functional, and drivable. The game also calls it a "flight in progress", just like with flags, but when you look at the two parts of that description, #1 being that the game is claiming "it's a flight" and #2 being that it's claiming "it's in progress", it's only wrong about #1, but it's right about #2. It IS a mission in progress, but it's not a flight. Contrast that with when it calls a flag a "flight" that is "in progress". There it's wrong on both counts, not just one. So for the problem that flags appear in the count of currently active thingies, that's problem #2. It should be solved separately from problem #1, which is things being called flights that aren't flights. Basically the rover *should* be part of the count of things currently active in the campaign save - it's just that the game needs to stop calling the active thingies "flights". So I propose two separate solutions to the two separate problems: Fix #1: Change the wording so the campaign's count of "flights in progress" becomes a more generic term, perhaps something like "active vessels" or "active craft". Then it can accurately apply to both flying and landed things - the relevant property being that its in some way a controllable thing rather than debris with no command core of any kind. This fixes problem #1, which is calling things "flights" which aren't actually flying. Fix #2: Remove flags from the list of thingies that are "in progress", regardless of what you call those thingies. This fixes the fact that flags are not "in progress". Here's my suspicion as to what causes the game (currently) to claim flags are "in progress": It's probably because the game implements a flag "part" as a command core that refuses all input, but still counts as a "command core" for the sake of meaning the flag isn't debris. Normally the very definition of "debris" that the game uses is this: Debris is any craft that has no command core, manned or unmanned, among its parts. The game NEEDS to ensure that flags, which are basically vessels containing one part - the flag part, don't get classified as Debris. (Because if they did get classified as debris, the game would delete your flags at some point.) Even if you set your active debris to a number higher than zero, the deletion of debris is on a timestamp queue basis, so eventually your flags would go away if they were debris. (i.e. if you have debris set to 50, then a planted flag would only last up until the next 49 bits of debris are created. Once one more chunk of debris exists after that 49th one, the planted flag falls off the back of the list and is deleted.) So the core of problem #2 is coming from the fact that the game divides all vessels into two categories: A - Active "in progress" craft. B - Debris. If it's not A, it's B. If it's not B, it's A. To keep flags from being deleted as debris, they had to be called A. Which means the flag part is probably some type of "command core", at least as far as the "is it debris" check is concerned. So fixing problem number 2 would require splitting that into three categories: A - Active craft. B - Inactive non-debris craft. C - Debris. So you could put flags into category B, a category that I suspect doesn't exist in the game at the moment.

One thing I've found this mod does is make me appreciate solid fuel boosters a lot more. They're so darn CHEAP, and that makes it worth it to put up with their annoyances. I've been launching my payloads in such a fashion that liquid fuel is only used for the uppermost stage (where you start to need the control and the ability to adjust throttle to fine tune things). Although, this is probably just a 'broken' thing about KSP's stock parts game balance. Once SQUAD issues the next update where money starts to matter in the stock game, I can imagine they will find a need to redress this imbalance.

Nobody seems to be addressing the problem that KSP makes station-keeping impossible and thus this doesn't work. Let's say you have a vessel where its velocity down to as close to zero relative to the lagrange point center as you can "see" on the instruments. The instruments round to the nearest tenth of a meter per second, so anything smaller than 0.05 m/s will show as zero as far as you can tell when piloting it. But even at 0.05 m/s that's still 1 meter every 20 seconds. Meaning that to travel 100,000 meters, as one suggested SOI for the L points was, takes 2,000,000 seconds. 2,000,000 seconds is about 23.14 days. Even if you are such an awesome pilot that you can get your speed down to the point where it *looks* like zero, you could still drift out of the L point in as little as 23.14 days. So how do you correct for that in KSP where ships that are not the current focus of attention cannot DO anything? Their on-rails movement relative to the L point will drift them out of the L point if you ever time warp more than 23.14 days ahead without switching focus back to your L point station again to do a bit of station-keeping thrusting with it. Even an automated mod like kOS in which you could write a station-keeping autopilot is useless because ships can't thrust or maneuver when they aren't the center of attention.

One potential problem I see with this is that the crew list that is saved in an active vessel is not just a list of 'which parts are populated' but also "whom are they populated by". It doesn't just say "this capsule has two Kerbals". It says "Seat 1 of this capsule has Kerbal ID #1 in it." (Which when you look it up is a Kerbal called "Jebadiah Kerman".) Then it says "Seat 2 of this capsule has Kerbal ID #2 in it." (Which when you look it up is a Kerbal called "Bill Kerman".) If you save that with the craft file, then you are saying "these are the people whom this craft is supposed to be flown by", which brings up the question of what should the game do if those named Kerbals aren't available when you launch. It may sound like a trivial problem because you can just say "well populate them with someone else then", but remember that one future plan the KSP devs announced is to keep track of astronaut experience. It could start to become quite relevant whom is flying the mission.

This can be really infuriating: I make a ship. Try it. It doesn't quite work. So back in the VAB I edit it slightly. But the game has chosen to completely alter everything about my staging list even stuff not related to what I edited. I don't notice it did this. I go out to the launchpad and have a disaster because, for example, the launch stabilizers didn't let go when the engines kicked in, or the second stage starts before the first stage. I know the game needs to auto-edit the staging list when parts are added and removed, but could it at least be possible for it to detect when a significant change exists from the previous staging list that's stored in the save file for the "current craft" versus the staging list it has now in the editor, and use that to detect when it has edited the staging list without you doing it yourself? In those cases a warning chime or popup just before leaving the VAB to let the player know ("I changed your staging list. Have a look before you go") would be really nice. The part about this that would be hard to implement would be for the game detecting the difference and thinking it can tell the difference between "the player wanted to change this" versus "I, the game, chose to change this myself". Basically, these things are "player choosing the change the list": - Manually dragging the staging list or clicking the +/- buttons, obviously. - Adding a new part from the sidebar "bin" that has staging list actions associated with it. - Removing a part from the craft into the sidebar "bin". And these things are not cases where the player wanted to change the staging list: - Player detaching a part of the craft in the VAB, then re-attaching it, without binning it. Anything that is part of the detached subsection should retain the same staging steps relative to each other when re-attached. when this does not occur, that's when to issue the warning. I steps are inserted into the staging list, and those steps are all associated with new parts being added from the bins, then that's "expected" edits to the list. It's when the old steps changed relative to each other that the player needs to be warned.

It would be very handy for setting up asparagus staging. Right now if you want, say, a ring of 6 asparagus staged sections, you actually have to make 3 separate pairs of 2 sections each, and manually eyeball it to get the symmetry right between the 3 sets, or else the symmetry is all wrong when placing the yellow fuel hoses and they end up being placed with 6-way symmetry. What this would open up is the chance to place the sections using 6-way symmetry, then break the group up into 6 separate parts for the purpose of placing the hoses individually. Another thing it would do is allow you to make x-wing symmetry. i.e. you place with 6-way symmetry, then remove a pair of two opposite parts, leaving 4 behind, so the 4 are placed at 'compass points' 60,120, 240, 300 rather than at 0,90,180,270. But I think the mess that it would create probably outweighs the benefits. Once you "split symmetry" like this you wouldn't be able to re-join it if you change your mind.

I think the post was asking for the ability to pick up just one part from a group of parts that were placed as part of a symmetrical set, leaving the other parts behind. So you put down one girder with 6-way symmetry turned on, then want to remove just one of the girders, leaving the other 5 behind, rather than removing all 6 when you pick one up. To active this, you'd have some sort of ability to hit a key or click a context menu that would "remove the symmetry" from a group of symmetrically placed parts. What this would mean is that the game would, instead of saying "this is a single part that was cloned 5 times.", it would now say "there are now 6 individual parts here that have nothing to do with each other. They just happen to be currently placed in a symmetrical pattern purely by 'coincidence'."

I'm having fun with this mod. But I do question one thing about the 'game balance' of the stock mission pack, and that's this: You are not allowed to perform the mission to land a kerbal on the Mun and come back home until after you've performed the mission to put sensors in a polar orbit (I think the first polar orbit mission is called Sputnik IV if I remember correctly, but I could be remembering that wrong). However, to perform the polar orbit sensor mission (which might be called Sputnik IV) you are required to put a Gravioli Detector on your craft. In Career Mode, the Gravioli detector is in a top-tier final "leaf node" of the tech tree. You can't put one on a craft until you've gotten very high up the sensors part of the tree. So I get "stuck" at that part of the stock game hand have to switch over to the 'random' missions game to make enough money to continue. I think the order of these two events in the stock progression need to be swapped for game balance: 1 - A mission requiring a Gravioli Detector. 2 - A manned mission to land on the moon and come back. A Gravioli Detector is a lot higher up the tech tree than the parts you would need for a successful Mun landing and return.

Thanks. It's unclear that this is what that meant by 'default values' - that it refers to starting over. I would still call it a bug that a new campaign gets values leftover from a previous one, but it's just a bug with an easy workaround if you know where it is (which I didn't). You are operating under the misconception that the word "misleading" must imply deliberate intent. It does not, and it was not my intention to make that implication. Something being accidentally misleading is still misleading. What was misleading was the claim that it's a mod "for sandbox mode". But you changed the wording, so good.

A bug: If you decide to start the campaign over and re-use the same name for the campaign, KSP itself opens a popup dialog asking to confirm that you want to clobber the old savegame folder and make a new one from scratch. If you say 'yes', it does so and your old savegame is gone... ... BUT the Mission Control mod stores the campaign data outside that folder in its own plugin folder, using the campaign name. The result is that when you try to start the campaign over as described above, Mission Control still has your old budget number and still uses it. So if the reason you started over is that you ran your money into the negatives while trying to learn how the mod worked, as in my case, then when you start over you're starting a new campaign in which you're already at negative money from day 1 instead of starting at 50,000.

I'm aware of this. But the description on spaceport and on this thread implies this mod is just for sandbox mode. That's misleading if the mod is made to work with career mode. Then the description needs to be edited.

I just started running with this and the first thing I noticed was that when you click on the research tab in the toolbar it says this: "Research not available in Sandbox Mode". So.. does the mod support career mode? The description in this thread's OP and in Spaceport seems to imply it's a mod only to be used with Sandbox Mode, but the existence of that research tab, and the message that it doesn't work in Sandbox Mode seems to imply that had I not used Sandbox mode it would have had something there... meaning it isn't a "mod for Sandbox Mode" anymore. Does it support Career mode? If not then what is that Research tab actually for?

So, for the future of this challenge…. what are the possible ways to deal with the fact that the official public release of kOS won't run on KSP 0.23 and we can't assume Kevin will be coming back any time soon to rectify that? I see two possible approaches (if you see another one let me know): 1 - Keep the use of stock kOS from the spaceport, but then also state that the challenge must be performed on an install of KSP that's on the old version (0.22) that kOS used to work for. If you don't have access to a 0.22 installation of KSP then too bad you can't participate. 2 - Allow people to start using 0.23 of kOS but then that means picking some sort of semi- official version of kOS that people have been compiling and putting up themselves on cloud hosted public shares as the baseline for the challenge. The problem with allowing privately compiled own-versions of kOS is that there can be lots of slightly different versions with lots of slightly different features and fixes - so you'd have to pick just one of them and keep it the official one for the challenge.

The real problem here isn't with flags. It's with KSP calling *everything* a flight that isn't debris. Note that flags aren't the only non-flying "flights" in KSP. A moon base landed on the Mun is not a "flight", but the game calls it one. The real problem shouldn't be "continue using the word 'flights' for everything it's used for now except for flags". It should be "stop using the term 'flight' as a generic term for everything.". Flags are just one particular symptom of the problem.

I'm not trying to belittle you. I'm trying to look for a solution that helps all future people and not just one person at a time. Even posting updates in this thread doesn't work because it's an enormous thread and nobody wants to have to read it through. Posting yet another explanation in the thread explaining it again seems to have been a good time to bring up that this practice is becoming less effective over time.

Most people would like to wait longer, but the upgrade to KSP 0.23 made it a problem. What would be nice would be if we had the ability to put a warning with a few edits in the first original post of this thread, directing people to a user-community made version and explaining why you need to use that instead of what's referred to in the post.

This is why someone really needs to fork kOS, make a new name for the new split-off version of it, and make a new github page for it and a new name and a new Spaceport page. As long as the official version is still 0.92, and that's what people will see when they look for "some sort of programming in KSP thingy", this question will continue to be asked again and again and again and again. One person compiling a new version of it and putting it on a cloud and pointing to it in a forum post is a nice stopgap but if Kevin is still out of communication then this just isn't a viable way to continue and I fear it will wither and die.

I picked the simplest example to illustrate the problem and assumed you'd extrapolate from that to understanding the more general case problem. It's still a problem if you read a much flatter slope than is really there even if it's not reading all the way down to zero. Reporting a slope of, say, 0.2 when it's really 0.8 is still a major problem. So the problem will happen a LOT more often than you're claiming. Slopes in KSP are rarely going to be zero. Only on a few worlds that have 'sea level' ground, like Minmus, will that happen. So the code will actually have to have a tolerance cutoff to be effective, say for example, "it's okay to land on a slope of 0.2 or less", rather than trying to find an absolutely zero slope. And that means, that the problem doesn't just occur when going only exactly perpendicular to the slope. It happens when going *close enough* to perpendicular to the slope to read falsely small enough numbers to fall below that tolerance window (which is NOT going to be zero) when the terrain isn't really that flat. How do I know? Because I've done it in kOS already. My lander has exactly this problem and it happens a lot more often than you imply. To make it work in kOS is going to require either arrays (to store a grid of different measurements as you drift in multiple directions, to make a small surface map), or directional ground radar that realistically aims in the direction the bottom of the ship is pointed rather than radar that aims straight vertical regardless of the craft's orientation (which is what KSP has now). With radar that aims with the craft, you could just rotate a bit in the crosswise direction to check the slope perpendicular to your travel.

One of the difficulties in trying to compare Apollo computers to modern ones and say "oh how did they do so much with so little?" is that there's a lot of apples and oranges comparison going on given that the Apollo computers were NOT general purpose do-anything processors accessing general-purpose do-anything RAM. When you make a generic "computer" that's not hardwired to specific tasks the burden is on the software to do all the heavy lifting. When you make a very specific one-purpose computer that DOES have a lot of things hardwired to specific tasks because it was designed in an era a little bit prior to the prevalence of 'general' do-anything sorts of computers, a large portion of that burden is moved from the software out to the "peripherals" so to speak.

Your algorithm describes how to find the slope of the terrain if you lived in a 2D world with dimensions X (horizontal) and Y (height) only. But when operating in a 3D world, you need to also know the slope in the crossways direction to your travel, which this algorithm doesn't find. Imagine a long trench gouging the ground from west to east. If your ship is traveling west to east and sampling the ground height along the slope on one side of this trench, it will think the ground has a flat slope when it has a very steep slope… but it's a slope perpendicular to the direction of travel so you can't "see" it on that one pass. For the idea to work will require storing multiple data points in memory and moving in multiple directions to scan the slope in two different directions and remember the ground height. And that's where the current limitations of kOS are a problem as storing such a thing is going to be a real mess without arrays implemented. When you have to hardcode the name of each data point as a separate variable it's too unwieldy to work with it.

I think the OP is asking how do you tell BEFORE you get there - when you plan your transfer maneuver - which way is the intercept. The trick to answer that is to see which way the encounter causes your trajectory to bend. Look at the new post-encounter trajectory that is being predicted. (the purple orbit on the map view) Does it fling you radial-in or radial-out from the Sun. You can tell because radial-in will rotate the orbit backward (The orbit ahead of you dips closer to the sun and the orbit behind you rises higher from the sun), while radial-out will rotate the orbit the other way (the orbit ahead of you rises higher from the sun and the orbit behind you dips closer to the sun). If your predicted orbit bends in the radial-out direction, you're passing inside the target planet and thus on route to a clockwise (retrograde) capture maneuver. If your predicted orbit bends in the radial-in direction, you're passing outside the target planet an thus on route to a counterclockwise (prograde) capture maneuver. But in any case, it doesn't take much delta-V to correct for this if you stop time warp the moment you enter your target's SOI. While still far from the target planet you can burn perpendicular to your path and bend it to pass on whichever side of the planet you like and it's not that big of a deflection.

I don't see anywhere in there where you hit the first stage. So it has the same effect as throttling up on the launchpad but never hitting spacebar to turn on the engines.

That shows an amazing ignorance of the rocketry equation. You'd get the same sort of disparity for comparing ANY two launch vehicles, one of which is capable of hauling far more tonnage into space than the other is. When a vessel has a smaller payload, it costs less per kilogram of that payload. When the shuttle was used to truck massive payloads, it was as efficient as any disposable rocket THAT tried doing the same job. The inefficiency and expense came from the fact that it was often used well below its capacity and used just to truck people and not use its large payload capacity. An 18-wheel truck rig is an efficient way to haul heavy cargo across town. But when someone tries using it to commute a few passengers to work and back, and leaves the cargo space in the back empty, it's not being used correctly and a different vehicle should be used for that sort of commute. Soyuz is designed for pure passenger missions. Light and small. It's like a compact car compared to the massive truck that is the Space Shuttle. Far better for commuting, but utterly incapable of hauling large cargo. What made the Shuttle inefficient was that it was the only thing NASA had so it used it for everything even things it was not made for. Had it had two types of vehicle, one large and one small, and only used the Shuttle for the large cargoes it was optimized for, it would have been fine.

Career mode should have a loss condition (and if you don't like that why are you playing career mode? Sandbox mode is what you want if you want the "pure toy" not the "game" style of KSP play.) But that being said, one absolutely crucial aspect of having a loss condition is that there MUST BE NO MORE DISASTER-CAUSING BUGS before such a thing is fair. I still get (even with no mods installed) the occasional case of a space station exploding the moment I switch to it from the tracking center. Because that still happens, I still have to constantly save off a copy of my persistence file just before I boot up the game each time, which is a cheat if you're trying to play it like a game, but is necessary when the game itself is cheating against you (which is an accurate way to describe what it feels like when the space Kraken eats your space station - that wasn't a "legit" case of me making an error that broke my space station. A bug that incorrectly deletes expensive hard work and thus sets back a 'game' mode of play or even sets up a loss of it is not the player's fault.) As long as such bugs continue existing, then players will still be well within their rights to copy the persistent file off and manipulate saves that way, and once they do that the "game" aspect of the play suffers. Permadeath is vital to making such a game meaningful, but permadeath is broken when game bugs cause the death instead of the player causing it. (To explain, "permadeath" is the word I use for what most people incorrectly call "rouge like". If there's no dungeon crawl, no fighting monsters and looting treasure, then it's nothing like rouge at all. Just sharing the one aspect that it has permadeath is insufficient for me to consider it being like rogue.)

Uhm. Doesn't this already exist?