Dunbaratu

If there is I didn't see it. If you know of one I'd love to find out about it.,

Well, that's a workaround. I still think it would be handy to just be able to say that smileys are just always unwanted by default.

First, change them so they can be put in-line like so: this is proportional [ code ] this is fixed [ / code ] this is proportional. and be rendered without breaking out into a giant box. Until that's done, this isn't really a workable solution. The code tags are for BLOCKS of code, not for mentioning one quick thing within a line of otherwise non-code things.

Do you mean you want it to stay pointed that way all the time even when it goes on rails or you go focus on another ship? As awesome as kOS is, it can't escape from the fact that KSP does not allow anything, human or mod, to adjust the ship's movement when it's on rails. When the ship is on rails, kOS is helpless to do anything with it. Worse yet, when the ship is not within the 2.5 km (or whatever you changed it to) loading limit, kOS can't even run on that ship at all because the kOS part on the ship doesn't even exist, period. It's unloaded from memory until the ship is brought back into view and has all its parts "rebuilt" into the universe. That makes kOS scripts who's purpose is to keep a ship on a particular orientation "at all times" even when not in view sort of impossible. It's unfortunate because I think it would make perfect sense to use kOS for a "station-keeping" script like this, but sadly doing so would require more than just a mere mod. It would require changing how squad's own code works.

As one of the contributors for the kOS mod, I'm often posting things that have punctuation marks in them that the forum software mistakes for smileys. I get tired of having to go back after seeing the post rendered and think "oh yeah that's right", and go edit it, click "go advanced" and check the disable smiley box. First off, it doesn't feel particularly "advanced" to get the forum software to do *less* work, but that's a side issue. It would be nice if there was an option in my user profile somewhere I could turn on that would make disabled smileys the default assumption, and then I'd have to "go advanced" to turn it on, rather than "go advanced" to turn it off. Smileys off is what I want 99.9% of the time.

I wonder how this will need to be joined with the new SHIP:PARTSINGROUP() method. It should be doable. I'm just trying to think of how it would be done.

@cairan IMO, all the LIST operations should be made the same, to return a LIST() of items rather than just dump things to the screen. But a few of them don't quite do it yet. If Volumes isn't doing it, then yes that's a bug.

It ran into a snag because we insist with kOS that we don't hardcode *anything* to operate on ActiveVessel only. The variable called "SHIP" means whichever vessel happens to contain the cpu part that's executing the code, which *usually* is the same thing as ActiveVessel, but isn't always. During docking operations there's more than one ship in range that could be running kOS code, and they can't both be the ActiveVessel. The problem we hit is that Action Groups Extended only works on the current ActiveVessel. I don't know if this problem ever got addressed.

At the moment it's messy. LIST PARTS IN PLIST. FOR P IN PLIST { IF P:NAME = "something" { Do_stuff_with_P_here. }. }. In 0.15 there will be a SHIP:PARTSNAMED("something") to make this better.

@GabeTeuton : Try changing this: set ag9 to "set l to l+i". set ag10 to "set l to l-i". To this instead: on ag9 { set l to l+i. Preserve. }. on ag10 { set l to l-i. Preserve. }. wait until false. // press CTRL-C in the terminal to end program or it will sit on this line forever. You need to add a line similar to that "wait" at the bottom or else the program will just finish at the bottom and release all controls when it quits. When a kOS program quits, it releases all its controls. You have to do something to keep it running for it to continue doing anything.

Uhhh.. yes it does. SHIP:CONTROL:PITCH does not mean the pitch of the ship. It means the pitch of the CONTROLS OF the ship. i.e. if it says -1.0 or +1.0 it means you've got the virtual control stick (from box [4] of my diagram) pushed all the way back or all the way forward. The actual orientation of the ship is called SHIP:FACING. If you want to work out the angle between the ship's nose and the horizon - if that's what you meant by "pitch", then you can use vector math to do that: SET U_VEC TO SHIP:UP:VECTOR gives you a unit vector pointing directly to the center of the sky at the ship's current position. SET F_VEC TO SHIP:FACING:VECTOR gives a unit vector pointing toward the nose of the ship. If your nose is aimed at the horizon, then U_VEC and F_VEC should be perpendicular. If it's aimed straight up, then U_VEC and F_VEC are parallel. You can work out the angle with dot product, or kOS provides a function that already does this called VANG. VANG(U_VEC,F_VEC) will return an angle in degrees from 0.000 to 180.000. If it's 90 you are pointed at the horizon. If it's, say, 80, then you're pointed 10 degrees up from the horizon, and so on.

The way that kOS works on the controls is as follows: +---- Kerbal Space Prg ---+ +--- kOS -----------------+ | | | | | [1]--------------+ | | | | | Rest of the KSP| | | | | | Game | | | | | +----/|\---------+ | | | | | | | | | | | | | | [2]--------------+ | | [4]-----------------+ | | | Input Override | | | | One set of control| | | | Stack picks one|<-------------| settings | | | | set over the | | | +----/|\------------+ | | | over | | | | | | | +----/|\---------+ | | | | | | | | | | | | | | | | | | | | [3]------------------+ | | [5]----------\|/-----+ | | | One set of control | | | | kOS Script code | | | | Settings | | | | reading/writing | | | +-/|\--------/|\-----+ | | | control variables | | | | | | | +--------------------+ | +-----|----------|--------+ +-------------------------+ | | | | User User Keyboard Joystick The problem is that to do what you'd like, it would have to read box [3] from box [5], when what box [5] actually reads is box [4]. When you read SHIP:CONTROL:PITCH, you're reading what kOS's settings have set it to, not what the main game has set it do.

I think trim might give some people what they're asking for - an ability to make an autopilot that helps the manual controls without overriding them - Let the autopilot control the trim while the player manually controls the main stick. The autopilot can maintain heading, pitch, and whatever with trim-only controls while the human can quickly override them temporarily by moving the main stick.

Which is exactly why leaving "destructable buildings" turned off isn't a workaround. The danger of broken runways caused by what you did wrong is a fun challenge. The danger of broken runways caused by what the developers did wrong is NOT. What does work is turning it off very temporarily, just long enough to spawn the plane, then turning it back on once the plane is resting on its wheels ready to takeoff.

The problem is simply that LOCK STEERING doesn't have a proper PID controller inside it, and just guesses how strong it should steer based on the average craft's rotational ability. That guess isn't correct for rockets that have a large amount of rotation capacity. We've been debating back and forth on whether or not to fix it, given that the whole point of kOS is writing your own autopilot and making a proper PID controller is part of that. Just handing users one that works out of the box might be a bit too ... mechjeb if you get my meaning. What I was thinking might be a good idea would be to allow users to adjust a setting that affects the strength of LOCK STEERING's deflections. If it's set to a smaller number, it makes LOCK STEERING use less than it's full amount of possible deflection force. That should dampen away a lot of these feedback oscillations without necessarily giving people a fully working out-of-the-box PID controller. Your own script would still be responsible for deciding whether or not to tell kOS to steer more mildly.

There have been plenty of replies in this very thread that tried to put the blame on poor vessel design by the player as opposed to it being a buggy artifact of the simulation in need of fixing. I'm glad to find out that SQUAD doesn't agree with those replies and does correctly consider it a bug.

Yes. I can't tell if the fix exists and I just don't know how to activate it. If it doesn't exist, then this becomes a bug report. I wouldn't call it a mere suggestion, because that implies it's not a bug fix and is instead an enhancement. Given how broken it looks now, I don't consider fixing it to be an enhancment. I consider it a bug that needs fixing.

It should be able to. You can address individual part modules on individual parts (or you will in 0.15, I mean). The difficulty is in identifiying which one is which when you have a very symmetrical design like this. But the even bigger problem with using laserdist for what you're doing is that I hit a wall trying to diagnose the behavior of unity's raycast when it comes to detecting hits on parts of the same vessel. It seems to have some very nasty buggy timing issues where depending on what order Unity chooses to update different parts of the KSP system in, it sometimes performs the raycast when not all the parts are in the expected location. (They don't all move to the new position in one lock step. One part at a time, it moves each part to its new location for the next frame. Depending on the order it did that in, the laser ends up being out of sync with the other parts of the vessel *some* of the time and thus missing them. It's a real mess and the advice from the user community runs directly contrary to the documentation from Unity itself, so I'm having to do lots of experiments to work out what's the right answer.) The effect of all of this is that I may have to release a lesser version of laserdist that only works on terrain and not ship parts as a first go of it. It's also exacerbated by the fact that the problem seems to depend on your computer's speed. It's a timing issue which means if I ever to get it working I don't feel confident that I *really* fixed it for everybody. So for the time being I put laserdist on hold for a week or two while I work on kOS more. I want to release laserdist simultaneously with the 0.15 release of kOS, and the problems in kOS are, frankly, easier to deal with because they don't involve performing experiments to learn what a hidden undocumented black box of highly timing-sensitive code is doing.

If your computer is one of the ones that doesn't deal with SM3 shaders very well, it can bog your framerate a lot to use them. So you unclick the checkbox in settings to use the fallback of SM2 shaders, which provides a tremendous boost to frame rate... BUT.. it comes at a cost - and NOT just the cost that it inevitibly must come at , which is that it makes the graphics a bit less pretty. It also makes them very DIM so it has to be high noon in order to see the terrain well and even then it's still quite dark. At morning and afternoon when the sun is at an angle, the terrain is extremely dark and barely visible on screen at all. It can't be *that* hard to just add a fixed brightness boost to the terrain polygon colors when SM2 rather than SM3 shaders are being used, to compensate for this.

But the existence of a mod to workaround the bug should in no way be taken as a reason *not* to call it a bug and complain about it in the support forum like this. It still is a bug and still needs fixing. It's nice that there's a mod that lets you adjust the angle that precisely, but it's a bug that it's even necessary to do so in the first place. Real planes don't magically teleport into existence above the runway and then drop down onto it, therefore any problems that occur as an effect of that should be properly viewed as an undesirable artifact of the simulation, rather than a thing players should have to compensate for in their gameplay. One simple fix would be to design a bit of taxiway just off the edge of the foot of the runway that, unlike the rest of the runway, is indestructable, and have the spawning happen there. Make the indestrucable part just one patch big enough to handle whatever the SPH lets you make and no more. That way people still have to deal with landing planes on the destructable runway and the consequences of doing so poorly, because one patch of indestructable surface isn't enough to land on - just enough to spawn on.

I'd say the real source of the bug is just the way the game spawns planes above the runway and just drops them. It's very reasonable that a large airplane just dropped from a couple meters up onto its landing gear would would damage the runway (and the plane. The rate of vertical descent during a good landing is less than you'd get from a few meters of dropping). What's not reasonable is why is KSP dropping planes from 2 meters up as the means of spawning them? If there's some issue with needing to account for variation and the game doesn't know exactly where the surface of the runway is, then it should "drop" the plane under lower gravity first, then after it's down, turn the gravity up to normal. It's not fair to expect people to account for the dropping in their design as that's an artifact of the game, not a real-world problem.

Reputation appears to only approach 1000 asymptotically rather than linearly as far as I can tell. Although, that calls into question why we're being told that a mission "awards NNN reputation" then when it's not a fixed number like that and depends on how much you already have.

To help diagnose it I'd have to see what the craft is like. The exact arrangement of the staging list and the separators and yellow fuel hoses (if any) is important to calculating fuel in a stage. Can you make a screenshot of the craft that shows these things, or post the .craft file itself?

I think you mean lack of syntax *highlighting*. It has syntax, or it wouldn't work at all. If you're interested, one of the future ideas is to try to find a way to emit syntax highlighting data from the C# code directly into a form that people can easily read through in their own software and convert into the syntax config format of their editor of choice. I've got a syntax file for VIM but it's getting out of date as it's a mess to keep it updated manually every time kOS changes. From the grammar file directly it's possible to do *some* automatic highlighter generation, but it can only tell you things like "that looks like a variable" rather than "that particular variable is one of the special predefined system variables as opposed to a user-defined one". It's trying to spit out that information that I'd like to be able to do some day from the kOS code itself. It's not bold. It's just the raw Commodore 64 font, which didn't have separate normal and bold modes. The thick letters you see there *are* the normal mode. But it was designed under the assumption you'll be using it with lower contrast colors like the original Commodore 64 default of light blue on dark blue. It's putting it into bright green on black that made it look so "bold". I find the thick font very handy when making youtube videos, because such videos often don't have *exactly* the same pixel resolution as the original gameplay did, and if the font's lines are only one pixel wide, then they can get smudged away during both the pixel averaging by local encoder software and the pixel averaging done by youtube's own processing on the server. That being said, more options is always better. I wonder if it would be easy to have a clickbutton to pick font for the terminal window. It would just be a matter of having a handle on both images loaded into memory, and swapping which one is being used at runtime.