Dunbaratu

Apparently to make it work I have to actually be ON the tracking center map view screen, make the contracts button visible there (it normally isn't) and then bring up the asteroid mission contract window while on the tracking center screen. THEN it makes the asteroid name appear in the contract window. If I don't do that and instead select contracts the way I normally do, from inside the VAB, the target asteroid for the mission remains unassigned.

Given that there's no official right way to do it, there's no reason to presume that people who assume GAMEDATA is in the ZIP's paths are smarter than people who presume the opposite, or visa versa. Neither assumption is 'dumber' than the other, since all you're doing is just trying to read the mind of the person who made the archive. Even if you think you know for certain that one way is superior to the other for various technical reasons, that has nothing to do with being able to read minds and detect that the mod writer did it the "right" way. If there was a standard adapted, I'd argue that the ZIP should itself contain the GAMEDATA folder in its path (so you extract it into your KSP root folder), purely because of the consequences of getting it wrong: * If you thought the ZIP archive did NOT contain GAMEDATA in the paths, but it turns out it did, the effect is that you install into GameData/GameData/ instead of GameData/. Result: mod doesn't work, but you can easily correct it by moving the files up one directory. * If you got it wrong the other way around, and thought the ZIP archive DID contain the GameData in the paths, but it turns out it did NOT, then the effect is that you wrote files into your main KSP folder and might have overwritten something important. That isn't as easy to recover from.

Had people been merely claiming that it's a good idea to have it because its what everyone is used to, I'd have agreed. But they claimed it was more intuitive, and that's false. It's not more intuitive - it's just that the effort to learn the non-intuitive system has already occurred in the past for most people. It's more akin to things like the meaning of traffic light colors, or thinking of traffic as always driving on the right (or left in some countries). These are not intuitive. They are learned. Just like kph or mph are learned. They are just conventions, NOT intuited things, but the effort to twist one's brain into thinking of them as normal has already happened, thus fooling people into thinking of them as intuitive.

They were left there during a transitional period in which the game recognized BOTH locations for backward compatibility. i.e. the game would first find all the DLL's in mods under GameData/ and load them, then look for the DLLs in Plugins/ and load them in case there were any still being installed there. Also, a lot of mods store persistent data for the mod in the mod's own PluginData folder, and SQUAD was probably worried that if they deleted the old locations people might lose their saved mod data when the game updates, before they had the chance to move it. But now that it's been a while, and I don't think it's still doing that backward compatibility check, then there's no need for the directories to remain. They just make things more complicated to explain to new users who started playing after 0.20 and never used the old system. They open the possibility for user error and confusion over where they're supposed to put things.

Well that's another way KSP's asteroids differ from reality. They don't break up in atmosphere, no matter what. If you have deadly re-entry mod installed, then it turns out that an asteroid on a grabber arm makes the best heat shield ever, as long as you can keep it pointed in front of you.

Thanks for giving an example that helps my case. Now will you just let it rest for once and stop derailing the thread? What I'd like to see is some variance in solar system generation so it's not identical every time, to aid in replay value of the game. The best way to do it is to use procedural generation *that starts from a seed that can be selected from something outside the algorithm's control, like the system clock, thus making the result effectively as random as a computer is capable of and not pre-determined*. And furthermore I'd like people to stop trying to derail that suggestion by disingenuously *pretending* they don't know exactly what that means just so they can have a pointless argument over nothing. SQUAD's idea that it's a bad thing for different players to end up with different solar systems is simply not something I agree with. This is primarily a single-player game and having the exact same solar system every time means eventually you've explored everywhere and done everything already. And having an algorithm with the capacity for random seeds does not have to imply that it's mandatory for every player to play with such a random seed start. You can have the game default to using the same universal seeds for all players, and make picking a different seed from the default be an option. That leaves it up to the player whether they want to share the same experience as everyone else or not. Furthermore you don't need to randomize absolutely everything to get some variety. You can bias the algorithm to make it more likely to end up with gas giants farther out, small solid planets further in, and make it unlikely to get two planets at the same orbit, and so on.

The development roadmap link on the first page of this thread still points to erendrake's version instead of the new version merged with marianoapp's work.

As long as there's only one way to do it, I'd rather that the one way be global. Scoping makes sense only when there's ways to choose the scope (i.e. local when you want, global when you want). If scoping was forced to be local only, then it would create the opposite problem, where you can't delegate your steering operations to a subprogram and all steering would have to be in the top level program.

Do you consider this correct behavior or a bug? It didn't used to work that way pre-kRISC.

I've installed some mods in which the ZIP archive has filename paths that are 'rooted' at the KSP base folder, such that the files in the archive all begin with "GameData" as the first path component of the filename. I've installed other mods where "GameData" doesn't exist in the filename paths because you're expected to unzip them INTO the GameData directory. Which way is the standard? Which of these mods is doing it right and which is doing it wrong? Right now because there's no consistency I'm in the habit of unzipping to a temp dir first, looking at how it was archived, and then deciding to either unzip into KSP's base directory or into GameData, depending on what I saw it do in the temp directory.

It definitely did NOT tell me that. The asteroid name was not in the window like it is in the screenshot. I don't have a screenshot but if another such mission comes up I'll get a screenshot. Update: here's a screenshot: If you blow that up to full size with "view image" you can see that it just refers to "the asteroid" without naming which one.

If you've taught yourself that UNTIL 1 is the way you loop forever, then you've accidentally taught yourself to write code that is dependent on a bug remaining unfixed. "UNTIL 1" looping forever is a bug. "1" should be interpreted as 'true', so UNTIL 1 *should* mean the same thing as UNTIL TRUE. I don't think this is causing the problem you're having. I just wanted to warn you about it because I expect the fix for UNTIL 1 will be coming out soon and what you wrote is dependent on the bug continuing to exist.

@Xty, Your test script looks weird to me. What's the "UNTIL 1" for? Why make a loop that is designed to quit unconditionally before it even runs? Also, if you are trying to use UNTIL 1 or UNTIL 0 like you are, you should be aware of this bug with the UNTIL statement: https://github.com/KSP-KOS/KOS/issues/36 The fix is already implemented in a pull request but that hasn't made it into the v0.12.P3 release. I'm not sure if that's the problem here but it's something you should know if you're using that in your script.

Which asteroid is "the asteroid" When an ARM mission contract appears? I just got my first ARM contract to appear and in the description it refers to "the target asteroid" and how I'm supposed to get "the" asteroid and bring it back. I have 20 asteroids in the game. How do I figure out which one the mission is referring to, so I don't end up capturing the wrong one and wasting all the money?

I wasn't entirely serious because to a certain extent adding control characters like BEL might require adding the ability to make number-to-character converting (i.e. print chr(7)) and also require adding more sophistication to the terminal interpreter and so on. Might be a bit of a mess.

You can sort of accomplish that with LOCKs. A LOCK says "return whatever is in the expression" and "the expression" could just be another variable and nothing more. LOCK X TO Y has a very similar effect to making X a reference variable pointing at Y, with the exception that theres no iterator math you can do on it (add/subtract from X to "move" where it's pointing, which since the ordering of memory under the hood in kOSscript is not defined in any public standard, would be a Bad Thing to try to do.) Or in keeping with the theme of old-school tech: The ability to print a BEL character and make the terminal window beep.

THAT is what you didn't communicate. Up until now you kept saying that the people saying #2 is most efficient were incorrect. At no point did you (A) mention that they were correct but for the wrong reason, or ( mention that you were arguing with other people's explanations rather than mine. As the original proponent of that position in this thread was me, that's kind of a necessary distinction to make. And the reason I didn't mention that you push past circularization to get to a transfer orbit at the start is that I wasn't assuming people didn't already know this. It's obvious. I think you were being unnecessarily condescending of people because the explanation you're claiming you were arguing against is one I haven't seen anyone arguing for.

That is classically how the principle was derived, pre-Newton, but it doesn't convince me at all why it supposedly makes sense. Consider a different case - the case of blowing a wind on something. You glue two objects together, both are 1 kg, but one of them is a large piece of cardboard, and the other is a small lump of lead. You put them in a wind tunnel. Do they separate apart? No, They're held together and thus constrained to go the same speed. The differential effect on the two parts can cause the combined object to rotate but that's it. But if you separated them they would not be affected the same. The cardboard piece would be moved a lot more. That's an example where, unlike with gravity, the two objects *are* moved differently when separated and yet they can still be attached together into one object. The notion that "If two objects affected by some phenomenon went two different speeds when unattached to each other, then they'd have to be going two different speeds if attached to each other as one object, which is impossible, and that's why they have to go the same speed when not attached to each other" is a fallacious argument. Once you attach them together all that would mean is that there's tension pulling at the attachment point and if the attachment was strong enough to handle it, they would be forced to go the same speed even if they wouldn't when separated.

No. Galileo. Longer Answer: The mass cancels out. The more mass, the more force is pulling on it, but the more mass, the more force it needs pulling on it to achieve the same effect to its motion. Push on something twice as massive with twice as much force, and its movement is the same as pushing on something half as massive with half as much force.

You did. I just don't think you're correct. The atmospheric drag is small enough in the upper atmosphere that aiming to circularize at, say, 55000m instead of 70000m gives better results. Granted, you can't maintain that circular orbit at 55000m because even the thin atmosphere is enough to slowly degrade the orbit, but that's sort of my point. If you're doing a direct burn you don't have to maintain it circularized. You only have to if you're going to establish a stable parking orbit first. If you're doing a direct burn then you're only going to circularize temporarily. As you continue to push through circularization - periapsis swaps with apoapsis and you don't stop burning, you keep going to push the apopasis all the way up to the Mun. Thus you have a transfer ellipse drawn from 55000m to 12 million meters instead of one drawn from 70000m up to 12 million meters. What the lack of parking orbit buys you is the ability to circularize while still at a lower altitude because you don't need that circularized state to be stable. You'll push right past circularization and into transferring, which will pull you up out of the atmosphere very soon anyway. A parking orbit demands you be higher than that at the point you begin your transfer burn, and therefore you're doing it from a slower starting velocity.

Ah. I see there was an unstated assumption I forgot to put in my claim. That you're doing it without the assistance of a maneuver node. So you have to work out before you start your burn what will happen without the game engine showing it to you. The hard part there is that you're not just trying to make your periapsis hit the Mun, because that involves a lot of drifting up to higher orbit wasting the Oberth effect away, but instead trying to thrust enough to entirely leave Kerbin's SOI, but in such a way that as you do so on a fast pass overshooting the Mun, you get getting very near it as you do so. If you use a maneuver node to watch what you happen ahead of time then KSP is doing all that math for you.

That entire sentence is self contradictory. You claim it gives better results, followed by claiming the reason it's not done is because it takes so much more fuel… what?

Exactly. Like I alluded to before, the reason this happens is because it's a case where recognizing that there's no danger requires knowing how the KSP implementation differs from reality. Using real world information and intuiting that it's the same in KSP leads to the mistaken notion that you'd better track every asteroid you can find just in case. Until you fail to do so and let an asteroid land on Kerbin and just go "thunk" on the ground with no effect, you don't realize it's okay to just let it happen.

The difficulty is that trying to use the Mun as a slingshotter to leave Kerbin and go to another planet requires precise math that you cannot perform, even if you know how, without access to seeing the numbers "under the hood" in KSP, which you cannot do without a Mod. You need to know precise orbital parameters of Kerbin, the Mun, the target planet, and where they are in their current orbit at the moment of you're taking off, where Kerbin is within its daily rotation, and so on. Because to do it right and get a savings, you have to be able to do better than you'd do from the Oberth effect of just doing your interplanetary injection burn directly from low Kerbin orbit, and that means you have to be able to predict ahead of time how the Mun will bend your path later on after you stretched your ellipse out from low Kerbin orbit quite a bit. Otherwise what happens is that you watch the map view, and burn until you like the path you see the Mun encounter causes, then stop the engines and coast until you go through the Mun's SOI, and then later after that's done you look at how much more burning you have to do from free space and complete your injection from there. It's that "stop the engines and coast" part that makes it less efficient than an injection directly from a low kerbin orbit burn. To get the proper effect that real space agencies get, you need to know all the data ahead of time to make the mathematical prediction of when and were you start your burn before you begin. The usual KSP way of "watch the screen and stop when you like what you see" doesn't cut it for this.

It's true that the optimal way puts your periapsis in the upper atmosphere not the lower atmosphere, but that's got nothing to do with gravity losses. It's because of drag losses. Go somewhere without air and the most efficient takeoff is one that is as low as possible, just barely enough to clear the terrain. The most effecient trip to orbit from the Mun, for example, is to make an orbit of only 8km, skimming along the ground just above the highest mountain peak. The primary reason not to do that in game is purely the boredom problem that the game won't let you time warp very fast when you're low to the ground.