Dunbaratu

This: until ship:altitude > 79000 lock steering to heading (90,10). is overriding everything else you're doing. It's continually setting the steering to heading(90,10) regardless of all the work the whens are doing. Also, don't do that. Every time you re-lock steering you make the in-build PID controller start over, making it forget the accumulated integral term. This is better: lock steering to heading(90,p). until ship:altitude > 79000 { set p to (put something here to decide what pitch you want). wait 0.001. }

Just started using this on a new career. I think the description of the first CCCP contract (Soviets launching a captured V2) is confusing: "Launch the R-V1 rocket and return samples back home." "Unmanned". I thought. "How on earth am I supposed to do a sample return mission without crew? Sample return requires crew in stock." I had to go read the contract's config file to realize "return samples" didn't mean it was a "sample return" mission, and you just have to get some surviving piece of the rocket after landing.

The temperature model changed in the stock game and kOS hasn't caught up. It doesn't report an "interior" and "exterior" heat for a part. This is partly because we were hoping it would be possible to get the info thematically by having you have to place a thermometer and read the thermometer, thus being unable to get the heat reading of every part - just the ones you stuck a sensor onto. The change of the stock game to have a separate interior temperature sort of mucked that plan up because you can't read that from a thermometer. Chances are we'll fix this eventually but it's been super low priority compared to other things to work on. As for drag, that's much harder to get magically from a sensor, and doesn't feel realistic to add to the autopilot's API directly. What you can do, though, is calculate how much you *would have* changed velocity had you been in a vacuum, and then compare that to how much you actually *did*, and assume the difference is due to drag.

Thus why it's a good thing that's a massive exaggeration on your part. Hard mode in no way requires that many uses of the test parts contracts. Not even close. You can do just fine only sprinkling in an occasional test part contract here and there among the other contracts, usually piggybacked onto them as an "also ran" thing to do on the side.

Choosing to label a slower pace of adding new parts with the disdainful word "bull%@#$" completely ignores the entire reason you're suggesting that a new user use science mode in the first place, when slowdown of part acquisition is the *goal* of suggesting science mode instead of sandbox mode. So it's just a matter of degree how much to slow it down. The very thing that itself was the goal of that suggestion doesn't suddenly become "bull%@#$" when there's a bit more of it. It's just a matter of degree of how much to slow it down. In a sense normal mode may actually be easier than easy mode here, because it slows down the rate at which you learn about new parts even more. Hard mode might be taking it a bit too far, but not so far as to suddenly turn the previously desirable effect into "bull%@#$".

I never played science mode after proper career mode existed. I didn't realize the game bothered with having an easy, normal, and hard when playing science mode. So I thought it was 5 modes, in increasing order of difficulty: Sandbox, Science, Career/easy, Career/normal, Career/hard. That the mere act of stating "easy mode" automatically implies career mode. Sorry then I misunderstood how the settings I never use work. So yeah if that's how it works, then yeah having the tech tree limiting the baffling array of parts to read though, but without the money worries would be the easiest way for a new player to learn

I agree. Its' just that "no reverts" is part of what it means to say you're playing on hard difficulty, so the claim that easy, medium, and hard are no more difficult than each other and it's just a matter of how much grinding you tolerate just isn't true. If you set it to hard mode, but then click the checkbox to re-enable reverts, then what you have gets called "custom" difficulty at that point, and is no longer correct to call that the hard difficulty setting. I didn't want a new player to make the mistake of believing what you said, and therefore thinking there's not much reason to bother avoiding hard setting.

That's perfect. Yes, that's what would be most useful for new players. No amount of knowledge of how real world space flight works is going to teach you what the game's controls are and how the game's UI works. You might be a total science nerd who knows how to calculate a Hohmann transfer, and how constant altitude burn landings work, and none of that is going to teach you that to change from orbital to surface-relative velocity readout you can click the navball's display label that totally just looks like just a passive display label and not a control button at all.

That's not true. The reason they are not the same difficulty is that with the smaller rewards for successes that the harder difficulties give out, your space program can't tolerate as many failures per success before you run out of money and have to abandon the career. In easy mode you can tolerate far more failed attempts per success before you run out of cash. Now an argument could be made that Easy and Normal are the same if you use the revert flight option thus bypassing this issue altogether, but you also extended that claim to Hard mode too, where it is definitely false because one of the options Hard mode turns on is the no-reverting-flights option.

The parts I needed the most help on and where the learning curve was the hardest were not the 'rocket science' stuff like "you have to turn to the side when taking off, not go straight up" and "you want to enter the atmosphere at a shallow angle, not come straight down" and so on. Those you can know at least in a non-mathy intuitive way just by being a fan of space stuff and watching enough videos of the real thing. The really hard part was the game's user interface not *telling* you how it works. The tutorial helped a little but it doesn't tell you everything about where you click to do what. Knowing real-world orbital stuff doesn't help you know, for example, that while you *can't* click the navball's 'RCS' indicator to turn on RCS because it's done by keyboard instead, that same logic does NOT apply to changing the mode from orbital to surface to target. For that you *DO* click the navball to do it. It's lots of UI "secrets" like that that make it impossible to learn everything in-game. Heck, until I saw a video on it, I never knew there *was* a target-relative mode option on the navball, which made docking super hard as I was doing it by eyeball not knowing that option existed. Other examples of this include: Not knowing that you can rcs translate with IJKLHN instead of using the 'docking mode' option. Not knowing there's a secret hidden menu underneath the altimeter for recovery and abort. (I thought you had to do it from the tracking center after landing.) Not knowing you can lock the camera to a ship-relatve view (which makes docking and landing a lot easier). What the game really could use is one of those old-school keyboard template cheat-sheets like flight simulators used to come with - print it out and leave it by the side of your computer in view when playing. The keybindings screen on the settings panel isn't good enough because you can only see it when NOT playing.

Most important issue: I'm seeing posts that are clearly out of order in a thread, where a reply quotes a post that appears later in the thread. And no it's not just 'stack order' - it's an intermingled mess. What does the forum use for its sorting critiera when showing a thread. Whatever they are there seems to be a bug in the thinking. Less important issues: - Please fix the CSS choices for rendering extra blank space between lines. You may think it looks nicer but you're wrong because it blurs the difference between adjacent lines and an *actual* blank line. Also as to the claim that it's better for mobile...wouldn't screen real estate be even MORE precious on a mobile device? Why waste more of it? - I hate the lack of a markup format because you can't compose offline and paste it in. For the changelogs we posted for the kOS mod, this was important. Now it HAS to be done with manual human effort because you cannot script the marking up of bold/italic/unordered-list, etc. - Pretty much every mod out there has links on its description pages in Curse, KerbalStuff, and CKAN that point to the mods "main thread" in the forums. You just broke ALL those links by not supporting links to the old URLs. Those are some important links that are going to give those mods a bad first impression when people try using them for the first time and can't follow the links.

[quote name='Bosun']So to claim that Mechjeb simulates a simpler solution of shelf-buying misses the argument everyone else is making: Mechjeb introduces controls and mechanics that would have been purpose-built for each craft, in a format that allows it to be in the game in the first place. It's no more store-bought than any other part you use in the VAB.[/QUOTE] Your argument seems predicated on the notion that the only two choices are Mechjeb or no autopilot at all. If you were just arguing that Mechjeb is more realistic than flying manually, I'd agree with you. But you also keep implying that it's closer to the game's attitude with assembling craft in the VAB than the [i]other autopilots[/i] I mentioned, and that's where we don't agree. There's nothing wrong with stating that you don't find the notion of roleplaying the autopilot programming part of a space agency fun at all and don't want to bother, and want to abstract all that away and just install a working one out of the box. There's plenty of good reasons to make that argument, all revolving around it not being fun, not being worth the time investment for just a game, etc. The majority of people are definitely going to fall into this category of not finding it fun or worth the time to do it. But the argument that doing so is roleplaying the software side of the space agency to the same detail as the way you play at being a rocket engineer in the VAB, that's just false. Mechjeb is definitely a much broader abstraction of autopilot design than the VAB is of rocket building, for the following very important reason: Hardware rocket design in the VAB: You can make mistakes both when building it, and later when using it. Autopilot design with kOS or kRPC: You can make mistakes both when building it, and later when using it. Autopilot design with Mechjeb: You cannot make mistakes when building it ( * ) , only when using it. ( * ) - Unless you're one of the programmers of the mod itself. There's no player agency in the making of Mechjeb's autopilot. Thus you're not roleplaying the making of it like you are the making of the rocket. It's not the same thing at all. Sure, the VAB abstracts away an enormous amount of detail, but it still lets you make the final assembly and lets you play at being a pretend engineer, and that ability to fail at it is vital to that experience. If you can't get it wrong, then there's no sense of accomplishment when you get it right. If you want to roleplay at that part of the space program that makes the mission software, in the same exact way that the game lets you roleplay at being that part of the space program that designs the mission hardware, you don't get that from Mechjeb. Stock KSP lets you roleplay at being both the spaceship pilot and the spaceship maker. But Mechjeb only lets you roleplay being the autopilot user, not the autopilot maker.

[quote name='selfish_meme']At the time, all software was custom, but the game has nuclear engines and advanced computerised technology.[/QUOTE] It's still custom *today*. It's not like the Philae lander had the latest "Microsoft Comet intercept software v1.2" downloaded off the net and installed on it.

[quote name='Bosun']I'll just mention, in case anyone didn't in the last....29 pages....All spacecraft launched after Apollo began had ascent profiles and programs loaded into them for the pilots to 'Execute' at the right times. This is exactly what Mechjeb is actually simulating.[/QUOTE] That's what kOS, and kRPC simulate. What Mechjeb simulates is what it would have been like if that software didn't have to be specially made custom for the space program and could be just bought off the shelf. Programming the AGC for Apollo was just as much of a major effort as making the rockets was.

[quote name='Ricardo.b']I searched log.txt on ksp folder and it returned only changelogs from mods, where can I find this? I'm using ubuntu linux[/QUOTE] For some idiotic reason, Unity decided to make the log output filenames differ per platform even though there's NO TECHNICAL OS-BASED REASON they have to do that, and the entire goal of Unity was to be a cross-platform engine, thus the name "unity". On Linux, they put the log file here: "/home/user/.config/unity3d/Squad/Kerbal Space Program/Player.log" (Change /home/user to whatever your home dir is). Disclaimer: I don't have the game on Linux so I can't verify this - this is from posts I've seen from others.

[quote name='Ricardo.b']hi guys. I'm having problem with some ir structure, whenever I type: print addons:ir:groups[0]:speed. at the terminal it returns: "cannot cast from source type to destination type." or when i try to set the speed it returns: "failed to convert parameters" and I dont know what these messages means, am I doing something wrong?[/QUOTE] Can you give a dump of the output_log.txt ? It should have a much more verbose description of the error.

For the 20 minute limit, is that round-trip time including taxiiing at the island runway to ready for a new takeoff, or is that a one-way measure? (And I assume it's 20 minutes in game-clock time not realtime (i.e. no fair using 4x physics warp to effectively make it more like a 60 minute limit.))

The default CPU speed is deliberately throttled back severely for two reasons: 1 - We don't want to take up more than our fair share of the simulation time, so we want to make sure kOS only uses a very small fraction of the total time, leaving lots of CPU (real CPU) time available for other computationally-hungry things like the stock patch solver, the FAR calculations, etc. (And we are simulating old era slow computing here anyway). 2 - The simulated virtual computer considers all "instructions" to have the same weight even though in reality they don't and some take a lot longer than others to execute. In order to prevent you from trying to run, say SET FOO TO SHIP:PARTS, which requires a full tree walk of the parts tree, tens of thousands of times per second, it also ends up preventing you from running a much less expensive operation like SET X TO X + 1 tens of thousands of times per second. In other words it's severely throttled back because it's treating every instruction like the worst case scenario instruction, and we picked a setting pretty much guaranteed to have a rather small runtime impact even on a slow gaming rig running inefficient scripts. If you think the default choice is too slow, and you want to experiment with how it behaves with it set higher, try this: set CONFIG:IPU to nnnn. Where nnnn is some number in the range of 50 to 5000. The default we ship with is 200, but many people have reported that they can increase it to 10 or 20 times that much on their rig and still get acceptable performance and frame rate. This setting, once changed, is global and stays the same for the entire mod (across all saved games). I'd like some day to experiment with implementing differently speeded CPUS on the tech tree - slow ones early, fast ones later, but right now it's just a dumb single global setting. You can try to change this setting on the fly in your script, if you're being adventurous. (For example, turning it up just before you enter a section where you know the script will be doing nothing but math in its head, and then turning it back down when you exit that section - just remember it keeps using the previous value until the end of the current physics tick, so you might want to force a WAIT 0.0001 just after any such change to ensure it really takes effect right away.)

This jamming up the list of 10 contracts with mostly ones you don't want is in fact *inevitable* when you think about it. Imagine you see 10 contracts, 7 of which you don't want. So you end up leaving those 7 in the list, and only removing one of the other 3 to perform it. Then it spawns a replacement for it, then you do the replacement, then it spawns another replacement and darn it it's a junky contract too, so now you have 8 out of 10 you won't do. So you do one of the other 2, and it gets replaced, and by chance eventually it *also* ends up being one of the kinds you won't do so now you have 9 you won't do.... The point is that the fact that you don't like that kind of contract *causes* the list to become more full of the kind you don't like specifically because you aren't removing them from the list as fast as the ones you actually are doing. This system inevitably ends up filling your list mostly with what you don't want to do. The solution to that is not to punish the player for the poor contract design that keeps feeding them junky contracts they find boring, and allowing the presence of those contracts prevent the ones they like from spawning. The solution is to stop allowing the junky contracts they've been "soft rejecting" by just not choosing them to stuff the queue and prevent the ones they do from appearing. One solution could be a limiter to prevent more than a certain number of contracts of exactly the same type from being present at the same time in the list. i.e. Configure part test contracts with a "max slots = 3" or something like that so it won't spawn any more if 3 slots are already in use by the same kind of contract, and do that for all kinds of contract. Another solution would be to use the history of previously expired contracts to remember what sorts of contracts the player tends to ignore more often and use that to weigh the probability of what kind gets spawned in the future. Think of it as a mini reputation system. You've gotten a reputation as a space agency that refuses to do space tourism, so eventually people stop coming to you with offers to do it.

Do you have an account on github, or would you be willing to make one? We make heavy use of it for organizing code coming from multiple contributors, and this sort of thing is best handled there.

I don't understand what you're trying to do. If you're trying to make self-modifying code of a sort, then yes there is a problem because kOS assumes during the life of a program that subsequent RUNs of the same file don't need recompiles of that file. That's because if you run a file in a loop like so : until false { run foo. } It shouldn't have to recompile foo over and over and over, which would be very slow. Instead it knows that during the current run, foo got compiled once already so it re-uses the already compiled one in memory. It's only when you're all the way back to the interactive terminal again that it turns that behavior off and actually recompiles everything from scratch again.

Are you aware of the difference between local volume and archive volume? Only the archive will end up on disk. The local is stored inside the part itself and only lives as long as the vessel is still present.

One of the next features on deck is inter-cpu communication, where a kos CPU has a message queue of prmitive objects (strings, numbers, etc) that other kos CPU's can insert into, so as long as you invent your own protocol for what you want those strings and numbers to actually mean, you can have one talk to another and feed it information. It occurs to me it might be possible to also add a few external C# hooks into the system so mods can use it to send/receive data from a kOS CPU script, provided the script was written to expect what it's being given. Not a promise - just brainstorming here.

I tested your craft and script on 0.17.3 (with minor edits to comment out the 0.18 - specific code and change 'groundspeed'/'surfacespeed') and I also tested it on 0.18.1. The claim that it doesn't work well in 0.18.x is an extreme exaggeration. It's a little bit more fiddly (your plane has extremely weak pitch and roll and yaw authority, by the way, and was quite hard to even fly manually), but it does work. The thing you didn't mention, which was super important, is that your script is built on very very tight hardcoded assumptions with no tolerance for deviation of any kind. Even on the successful 0.17.3 launch, it ended the launch like so: Pe = 70,143 Ap = 70,222 Remaining liquidfuel for ascent engine: 19.68 / 1125 (not counting the much larger tank, which because it's feed was disabled I'm assuming was intended as a passive payload). You never mentioned that you were operating on such razer-thin margins, and that the real problem was that the new steering just made the launch "ever so slightly" less efficient, and your setup could tolerate no deviations from that at all. That's sort of important to the complaint that you're making.

Probably never going to happen. That would be a spaghetti code nightmare to maintain as they are two entirely different systems with different code flow. The only problem I've seen is that the default tuning parameters make it steer too weakly for the case of a large rocket that is slow to turn and needs the controls pushed to the max. I just think that the default settings need to be a bit rebalanced, rather than scrapping everything and making the system a spaghetti code mess by trying to support both the old and new systems. Opening up the chance of tuning the built-in steering without having to make your own entire steering system from scratch isn't a step backward at all. In the old way you had to replace the entire steering system with your own work from scratch in order to get even the slightest change to the behavior. The only options you had were "use hardcoded behavior" or "do the whole thing yourself". There were no in-between options. Now there are.