Dunbaratu

I'm fully in favor of letting someone else *add* a second langauge that kOS can use, provided I don't have to be the one to implement the second one. Making the system able to use a second language would take a bit of work because those other languages would have to be able to compile into our made-up machine language as their compile target. Not impossible, but not a trivial task, and there's other bigger problems to deal with. Most of the stuff that can be described as "a lot of the stuff that should work doesn't work" is not the fault of the kerboscript language. Not anymore. It used to be a horrible mess but it's been fixed up as far as I know. That is most of what I was working on since I joined the project was the parsing of kerboscript. The current problems are that once the script requests us to do a thing, the stuff that the C# code does WITH that request has bugs. You won't fix those sorts of bugs by swapping out the language. You will get other benefits, but fixing the current crop of bugs that still exist isn't one of them. But I'm fully *against* getting RID of kerboscript to add Lua. But be warned, that most of the limitations aren't in the language but in the virtual machine we're running itself. You'd have a hard time implementing a full OOP system on top of the "machine language" instructions we have so far. But that system is designed to be expanded. Unlike with a real hardware computer, we can just effectively "re-burn" the "chip"'s microcode, so to speak, with each new release.

What you want is to take the position vector that points from your ship to the other ship, and work out what is the angle between it and the horizon-plane. And the way you do that is to first work out what is the angle between that position vector and the NORMAL TO your local horizon plane is (your ship's current UP vector is normal to its current horizon plane), and then subtract it from 90 to get the "other half" of that angle. (i.e. a vector that is pitched up 30 degrees from horizon will be pitched DOWN 60 degrees from straight up: 90 - 60 = 30. A vector that is pitched DOWN 30 degrees from horizon will be pitched down 120 degrees from straight up: 90 - 120 = -30.) So that thinking gets you this final formula: SET PitchToOtherFromMe TO 90 - VANG( OTHERSHIP:POSITION, SHIP:UP:VECTOR ). Where "OTHERSHIP" is obviously the other vessel. As a side note, I dislike the fact that Kevin chose to use the same vocabulary term to mean both a 3-D direction ( HEADING(a, ) and also 2-D direction projected onto the ground (TARGET:HEADING). Those really shouldn't have been the same term.

Ohhh man I *really* *really* want to mention some tools that exist already in the update but aren't documented that do exactly this. The only reason I haven't mentioned them is that the docs are currently frozen because someone is writing a re-do in a better document system and I didn't want to publicly mention a thing that's not properly dealt with in the official docs.

Here's another question: If you're writing some changes to a mod to make it take into account the new space center building tech levels, and you need to test what happens to career games at different points of progression, is there a quick cheaty way to set the building tech levels where you want without having to actually play out the entire career to that point? I also have the same question for pilot skills. Basically, I'm contemplating making kOS obey the Tracking Center limits. For example, kOS allows scripts to access a nearest pass orbit solver (a function that lets you pass in two Orbit objects and it returns the next timestamp at which it guesses they'll have the closest rendezvous). I'm contemplating making it not work until after your Tracking Center can do it, under the thematic idea that your space agency isn't very good at that yet. (And to keep kOS from being a mechanism by which you can cheat your way past the limitations of career mode). But to test a thing like that, I'll need savegames in which the tracking center has different tech levels. Being able to quickly fake that for mod testing would be useful.

Given how PID controllers work, I suspect the magic minimum number is 3. 2 is enough to learn the diff between current value and previous value, derive a change rate from that, derive a future predicted position from that, and then you need one more iteration after that to actually see an effect happen from the input settings that it changed in iteration 2. Just on pure guesswork from the method signature that sounds like what we might need. I'll pass that on to erendake (although, if it's a Vector and not a Quaternion, then that means it has no roll information, which is going to annoy our users quite a bit. It's fine for rockets to ignore roll, but not for spaceplanes).

Can you use the API to lock the new SAS to any arbitrary direction you pick for it instead of just to the six cardinal ones? (i.e. "Please try to SAS your way toward the goal direction that I'm going to give you, oh and by the way I'll be slightly updating this goal direction each update because it's not fixed in space - its a dynamic direction (i.e. 5 degreees above the target, or in the same facing direction as my target is facing, etc - any sort of direction that will need to be moved a little bit each update.") Because I'm fearful that if there's an API method to give it just whatever direction you feel like, that constantly passing in a slightly moved direction each time will end up constantly resetting the PID controller making it not able to do its work properly. It seems like you have to leave the direction unchanged for a few ticks for the PID controller to do anything. (And this immediately begs the question why on earth it can lock the SAS to aim toward the target as it moves relative to its target - it clearly *is* able to deal with a seek direction that keeps getting re-updated again and again continually, but it seems as if it can't deal with such a seek direction if it's one you pass into it.

If you're looking for a thematic reason it would make sense story-wise, the launch facilities at Cape Canaveral, and the mission control facilities at Houston, and the network of tracking telescopes strung out around the earth, while they may be expensive, are *also* technological in nature. They're not just big dumb warehouses. The tracking center alone has to involve a massing computing facility. And obviously, the R&D center itself is a big science lab where you use science to learn how to learn more science. So just like you unlock a tech tree node before paying money for the part that's in it, thematically it would make perfect sense to say, for example, that you have to unlock tech tree nodes that allow for building upgrades first before paying for them. Making a technological complex containing labs, computer consoles, electronic networks, environmental training facilities, etc, involves a lot more than just paying a contractor to build a building. It's what the building is *filled* with that matters, and that's a lot of stuff built using science knowledge. So go ahead and make an argument that for gameplay you don't like spending science on building techs, but story-wise and theme-wise it fits. Maybe an argument can be made that it's not a good idea for the game, but not because of any realism issues with it. It's perfectly realistic to say you can't make a fancier mission control center if you don't have better electronics yet, and so on. As for the balance problem, I think it's really just caused by the fact that BOTH funds and science got new ways to obtain them, with more contracts that generate them, but only ONE of them now has more stuff to spend it on. You get a lot more funds for missions than you used to in 0.25, but this is more than offset by having to spend them on some very expensive new items. Whereas for science, you get more science for missions than you used to in 0.25, but this was NOT accompanied by a similar new place to sink those points into. The tech tree is still the same as 0.25. This gives rise to the problem of gaining science points that you're not allowed to spend because they come in faster than the Funds to upgrade the building does. This is the part that feels like a grind - because you're sitting on points you can't use, and you're just running the same missions over and over until you have enough money to unlock the use of those points, thereby finally opening up more interesting NEW missions to try instead of trying the same old ones again and again. Getting new missions is directly connected to getting new tech. If your tech is capped out, you're not getting new types of mission showing up either - just more of the same. So it's just as much a problem of "too much science now" as it is a problem of "not enough funds now". Add something to sink those science points into just like there's something new to sink the funds points into, and I think the two would be brought back into balance. Simply making the tech tree wider (not deeper, wider) would do it. Having to learn the tech for a building upgrade would be just one idea for how to do that.

Even the absolute best of those still barely pay for themselves, and that's asssuming you can hit the narrow window of parameters right on only one try. Actually because of the need to piggyback them onto other missions, the testing on the ground ones are the only ones I still bother doing, because they're the only ones that don't hinder the more primary mission the rocket is on at the time by forcing you to fly the rocket in a dumb way (too fast while low, or too slow while high, way out of whack from an ideal launch profile). But that's really a side topic anyway. The thread isn't about part testing - which hasn't really changed much with 0.90. Whatever problems it may have, are ones it already had before.

Which doesn't start happening until after level 2 of the R&D building, unless you're playing on an easier mode. In hard mode, you haven't built up the capability to do the 200k contracts yet at the stage of the game I'm referring to where the boring grinding part is. Mun surveys get you between 60k and 120k depending on how many parts they have. Minmus slightly more. The 200k contracts don't start happening until you go to other planets and land on them. At tier 1 tech your launchpad is too small, your VAB is too small, etc to be doing those 200k missions. And if you're trying to make the R&D building go to level 2 as fast as possible because you're already unlocking most of the tech nodes at cost 90 and less, spending money on those other building upgrades sets you back from that goal even further. It is possible to gain the funds in time to upgrade R&D before you've capped its level 1 ability, but only by playing in a very weird unbalanced way where you perversely ignore the missions that give you science and try going just for the ones that give money alone.

I think people would hate part testing a lot less if it had slightly better rewards. As it is, it always has to be a side thing you do along with a real mission rather than a primary point of a mission, otherwise you spend more on it than you get back. But, that's hardly a new problem with 0.90. It's been that way ever since part testing contracts existed. I just wish there was a way to tell the game to stop spamming my available contracts list with them crowding out the useful missions.

Specifically, the grind that occurs between level 1 and level 2 of the R&D center. That's the real big one. After that it's not so bad. But before that, you accumulate science above and beyond your ability to spend it, even when you're not trying particularly hard to gain science points. This is because the Funds you need to upgrade that R&D center come slower than the science comes and you can't help but accumulate science a lot faster than your funds will allow you to spend it. By the time you get the R&D center from level 1 to level 2, you'll be able to unlock about 5-6 tech nodes instantly, at the very least, from all the banked science points. They are balanced in Normal Mode, but Hard Mode made one a heck of a lot harder than it made the other, putting them way off balance compared to *each other*. As to the suggestion to fix it by picking fund-heavy strategies in the admin building, the design of the game was *supposed* to be that you use those to push things off balance from the default if your play style is different, but currently you have to use them to repair the unbalanced default gameplay back TO being balanced again, thereby taking all the fun out of that building too since you can now only use it to do one thing and one thing only - push back against the unbalance of funds. It's a bit like driving a car with steering that pulls to the right so badly and is so out of whack that you have to turn the steering wheel almost all the way to the left just to go straight. Sure you *can* drive straight that way, but it will severely hamper your ability to steer to the left when you need to, because you're spending most of your leftward steering power just to go straight. Having to use all of the admin building's power to try to re-establish the off balance of the Hard mode settings back to the center again is crippling its use for its intended purpose. It's frustrating because with a little bit of tweaking 0.90 would be great. The *system* is good, but the data its populated with is a bit off-centered, so to speak. And it's the off-center balance of Hard Mode, much more so than the general average overall difficulty of Hard Mode, that makes Hard mode feel like a grind during the early game. I hope when SQUAD addresses the balance like they say they intend to, they pay attention to the multitude of complaints about this, and not to the people who engage in the strawman fallacy of mischaracterizing the complaints as merely "oooh it's too hard" and that's it. That being said, once you get past the necessary grinding funds to get the R&D center up to level 2, the rest of the game opens up better from then on. It seems the main problem is just during that first part, where science comes in way faster than you're allowed to spend it.

Except that's not the purpose of those modes. The devs have said the the whole point of career mode being laid out with the tech tree a bit historically backward (i.e. learn rockets before you learn planes, or worse yet - before you've invented the wheel, apparently) is that it's meant as a teaching tool so that new players are introduced to parts of the game in a way that flows from basic to complex. So given that that's the purpose of career mode, there is a problem that it tends to scale the difficulty backward now in 0.90 (No, I don't meant the difference between easy, medium, and hard, but the difference between late game and early game. It feels like the early game is the hard part now and the late game is the easier part. That's fine for experienced players but it's a bit backward if career mode was meant to teach new players the game piece by piece.)

None of these sliders are capable of affecting the hardcoded fact that funds are used for a lot more things than the other stuff is. They can't alter that balance problem. Lack of funds prevents you from using science points, but lack of science doesn't prevent you from using funding points. The 3 things are not equally important, which then also means that the ability to change them around with the admin building doesn't really help either. It's functionally identical to changing the sliders before you start the campaign.

None of those sliders fix the root problem, which is that Funds are the only thing that matters in Hard mode, and the other 2 things aren't important at all. Those sliders can only alter how fast you accumulate the 3 types of "currency". They can't change the fact that all the building upgrades require purely just Funds and not any Science or Rep. THAT is what cause the Hard mode to be grindy. The game balance problem comes not from how fast you get the 3 types of "currency", but from the fact that one of them, Funds, is about five times more important than the other two, Science and Rep, such that there is exactly one and only one right strategy in the admin building - increase funds and decrease science and reputation. The other options are presented to you but are wrong to pick because you'll hit the funding problem long before you'll encounter any problems from the limitations of the other two. If you get science faster than funding, there's no point, because you can't spend the science as fast as you get it without an upgrade to the R&D building that you cannot afford for quite a while yet. If you get Rep faster than funding, there's no point, because you can't actually perform the nice missions you're getting as a result. That's what makes it feel grindy. Instead of balancing the 3 things, you really just deal with one of them and one of them only - the funding. And that means doing the *same* thing over and over and over, instead of doing new and interesting things. It's not impossible to fix it - it just needs some tweaking, and perhaps much more interesting contracts given out at low tech levels. If the Funding grind wasn't DULL it wouldn't be a problem. But it becomes dull only because you're limited to only about 2-3 kinds of mission for a long time, so you'll end up doing the same mission again and again to get the funds up to unlock the more interesting stuff. It would be better if there was more variety to the low-tech starting part of the game. And that would require balancing the parts tree a bit better. Don't wait for tier 4 to let you make planes. Instead unlock bad plane parts early and better ones later. Don't wait for teir 4 to let you have wheels. Give you the tiny wheels early and better ones later so you can start doing some rover missions early on around Kerbin. Increase the *variety* of gameplay at low tech levels and the initial grind for Funds won't feel annoying anymore. And for the hard of thinking : A complaint about the grind and a complaint about the difficulty are NOT the same complaint. Any post that makes the argument that people shouldn't complain about the difficulty if they set the slider to "Hard" is sort of ignoring the fact that most of the complaints about Hard mode have actually been more about the grind than the difficulty. Currently, setting the slider to Hard has TWO effects: 1 - it makes it harder. 2 - it adds a lot of dull grinding up front in the early game. The challenge is how could SQUAD tweak it so that you get #1 without #2. I've offered 2 suggestions up above: A - Make building upgrades require some use of the other 2 types of currency as well, not just exclusively funds alone. That way you're not just accumulating science points and banking them doing nothing with them for a long time like you have to do now B - Add a lot more variety to the early-game missions so that grinding for funds isn't as annoying anymore. What makes it annoying the the repetitive nature of them. "Survey this set of spots" are all pretty much the same mission, and "put a satellite in this particular strange orbit" are all pretty much the same mission, and "test part Foo at altitude Bar and speed Baz" are all pretty much the same mission. Give you earlier planes and rovers and then you can have early missions like "Land a rover here on Kerbin and drive it 2 km away from where it landed to test the rover system", or "Try to fly as flat and level as possible so you keep your altitude within a 200 meter window for a distance of 5km over this location", and so on. More *types* of low-tech missions would turn the dull grind into "fun grind" instead.

Nah, getting to a target orbit without maneuver nodes is easy. The hard part is getting a rendezvous mission without the closest-approach chevrons. It's the lack of those chevrons that's the problem. I don't think the game should be giving you the "rescue this guy from orbit" missions until after you have them available, because that's just going to punish new players who don't realize how hard it is to do when they pick the mission. You only have 2 active missions at a time, and you pick a rescue mission as one of them and you've effectively just locked out that mission slot for a long time because you didn't realize you needed a better tracking center first. For new players that's really punishing. Experienced players can pull it off without the tracking center help but it's quite hard. Hard enough that an easy-mode or normal-mode player shouldn't be presented with those missions deceptively early like they are.

It's only off by a little bit, and what we are returning is *exactly* what the KSP API says for Orbit.period. Given that we are just returning what the API directly says, I'd be more inclined to believe the wiki is wrong than that our number is wrong. Also note that there's multiple different kinds of measurements for period, depending on what you take as the "same" point the body comes back to, in a constantly moving reference frame with a parent body that isn't in the same place it was when your orbit cycle began. Sadly, the utter lack of documentation for the KSP API means we're not being told which kind of period it is giving. These slightly different versions of Period give slightly different, but close to each other, values. My guess is that it's referring to the period according to the local raw SOI space (which kOS hides from you by always making all positions get reported relative to the CoM of the CPU's vessel) - how long would it take to return to the same XYZ grid coords relative to the parent planet if those grid coords remained fixed and didn't switch reference (i.e. if you kept the same vessel focused for a whole orbit). In the real world, if you want to take a period measurement in an inertial reference frame where you don't take into account the rotation of the planet itself or its orbit around its primary body, then you have to do it against the starfield "backdrop" of the solar system (which itself is still changing too, of course, but it's changing slowly enough that you can use it like it was fixed in space). In KSP you get that same sort of meaning (the period in properly behaved linear inertial reference frame that's not rotating as the objects move) NOT by doing it against the starfield but by doing it against the local subspace coordinate grid to which the primary body's SOI is fixed. And that's a meaning of "period" that you're just not going to find in any real world astronomy manual because it's purely an artifact of the KSP simulation that doesn't actually map to a real world phenomenon. But this is pure guesswork because SQUAD never documents their API. What we're returning is "whatever SQUAD means when THEY say 'period' in the API."

Locking does not work with suffixes of any type. LOCK AAAAA:BBBBB TO CCCCCC. Will fail for *any* AAAAA, BBBBB, or CCCCC. The LOCK command only works on simple single values. This is a limitation of it that I'd like to fix some day, but working out the right thing to do is a bit messy if the chain of suffixes is itself changeable. For example, it you: LOCK SHIP:PARTSTAGGED("my engine")[0]:THRUSTLIMIT TO TWR*1.2. The problem is in having to work out which of these was meant: option 1: First, Up front: Get the parts tagged "my engine". get the zeroth such engine, and get a handle to its thrustlimit. Then, continually update each time: That thrustlimit's value to TWR*1.2, regardless of how PARTSTAGGED("My engine") might change. option 2: First, Up front: Do nothing. Then, continually update each time: Re-run PARTSTAGGED("my engine") to recalculate what the zeroth such part is at the MOMENT, just in case that changes, then set it's thrustlimit to TWR*1.2. Option 2 would correctly handle the case where the suffix changes what it means from one moment to the next, but it would be wastefully expensive for the majority of cases where it doesn't. I don't know the right answer for choosing between option 1 or option 2, which is why I haven't addressed this hole in the language yet. By deliberately not picking one or the other, I force the script writer to do it explicitly if they want lock-like behavior - they have to do it in their own trigger, where their own code would decide which way to do it. Option 1 can be implemented this way: SET FOO TO SHIP:PARTSTAGGED("my engine")[0]. // calculate this part just once. WHEN TRUE THEN { SET FOO:THRUSTLIMIT TO TWR*1.2. PRESERVE. }. // recalculate this part over and over. Option 2 can be implemented this way: WHEN TRUE THEN { SET SHIP:PARTSTAGGED("my engine")[0]:THRUSTLIMIT TO TWR*1.2. PRESERVE. }. // Recalculate the whole chain of suffixes over and over. Warning, Option 2 is very expensive because it does a walk of the whole parts tree every update, which is why I'm reluctant to implement LOCK this way even though it would be linguistically more correct with how the language probably is meant to work. Can you elaborate? It's intended to work like the other buttons up there where it's mutually exclusive with the other panels (i.e. you hover the mouse to bring the panel up temporarily, or click to leave it up and click again to make it go away, and it won't appear if one of the other panels is up instead (i.e. the resource panel).

Thankfully the devs have said that they know they need to work out the cost balances, but I really hope they pay attention to this problem when they do. 1: Newbies are given contracts that only veterans can pull off (nendezvous with the mun, but do it without a functioning encounter detector yet). Be smarter about the sorts of contracts you're handing out to people. You don't want new players being frightened away. 2: Veterans who want the challenge of Hard Mode are now forced to ONLY pay attention to Funds as the only one of the 3 resources that matters because Hard Mode nerfs Funds and makes everything more expensive, while NOT doing a similar thing to the same extent with the other 2 resources of science and rep. That unbalances the 3 relative to each other such that you'll earn plenty of rep and science without really trying, while being unable to use any of it because you still can't afford to upgrade the relevant buildings. You'll buy all the 90-cost and less techs just from the residual side-effect science you picked up while scrounging for funds long before you've earned the 2 million funds to update the science building.

Yes you can control IR from kOS now (although kOS is in a state of flux at the moment because KSP 0.90 broke some stuff about how autopiloting works. KSP's 0.90 changes are VERY much in the same areas that kOS has its fingers in, so don't expect kOS to be 0.90 compatible for a while yet. We kOS devs aren't part of the experimentals group so we only just got our first chance to be aware of the changes yesterday.) A simple dumb example of manipulating an IR part from a kOS script: // Assuming THEPART is a part that is an infernal robotics part, move that // part in the "+" direction for 1 second, then stop moving: SET robotModule TO THEPART:GETMODULE("MUMECHTOGGLE"). robotModule:DOACTION("MOVE +", true). WAIT 1. robotModule:DOACTION("MOVE +", false). More full descriptions can be found here (for now - the docs are about to move to a new location) : http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_parts_and_modules/index.html

In general most of these problems can be summarized by one simple statement: The game shouldn't be presenting the hardest challenges a the START of the career, as that discourages new players. And yet that's exactly what it's doing.

So they are meant to be used by autopilots that are supposed to allow pilot overrides, but not ones that aren't? That's what I'm getting from the description.

Can anyone describe how the new autopilot hooks work and how they differ from OnFlyByWire, conceptually? Specifically, how they interact with a human pilot also trying to control the same vessel at the same time - who "wins". With OnFlyByWire it was generally whomever added the lastmost hook.

Tutorials that have to be re-written since all the existing ones assume you have a functioning tracking center, when you won't yet at this point of the game.

It is using the following algorithm: 1 - Try calculating the terrain height using the ideal terrain function (PQS) which represents a smooth curve of terrain as seen from high up in space, not the actual polygons that approximate it once you get low down. 2 - Try doing a raycast to hit the terrain polygons. If the raycast worked, return that, else return the ideal PQS value. I suspect the raycast is intermittently failing, because it's notoriously unreliable unless you call it with precisely the right timing. It's a problem I've encountered in another mod I was writing and trying to diagnose why it randomly misses is a royal mess. The docs in Unity explaining how you're supposed to use it do NOT cover all the tricky timing issues that break it so trying to figure out what's wrong is pure random guesswork based on user community suggestions (that contradict each other). Fixing it is not a high priority because usually you use geocordinates to work with terrain at any arbitrary point that could be far away - so the polygon hits aren't really usable for that anyway. For local polygon hits right under you, the alt:radar is good.

Yes, a thousand times Yes. I just got done with such a mission without the aid of the tracking center (let's face it you're not going to be spending 200,000 funds on that when you get your first rescue contract immediately after your very first successful orbit - you won't have nearly enough money for a working tracking center yet). If I hadn't been a veteran player there's no WAY I'd be able to pull that mission off. Even if I was a rocket engineer at NASA I couldn't have done it if I was a newb to this game (because all the math knowledge in the world for how you perform a rendezvous is no use without being able to see the numbers that stock KSP won't show you. The only way to get it right without knowing the numbers is seat-of-the-pants guesswork by having seen it so many times.) For superhardcore hard mode for veterans, trying to pull off a rescue rendezvous without the aid of the inclination angle indicators, the ascending and descending node indicators, and (most importantly) without the closest-approach chevron indicators, is a LOT of fun. But to subject newbies to that? No Way is that going to give them a good happy impression of the game. It's just going to be frustrating and they won't discover just how hard it really is until after they accepted the contract and will have to pay the penalty for failure. Unless you're in hard mode, don't open up the rendezvous contracts until after the tracking center is able to provide the help. In general, this is a concern of mine - it feels like the entire design of 0.90 is putting the difficulty curve utterly backward. The game is *hardest* when you start a new career, and gets *easier* as you go.