Dunbaratu

Your original post described many things. The ones I referred to with the phrase "major sweeping changes" wasn't this one. There are at least 3 different places where such information would be useful that I can think of: - Autogenerated documentation online. - Printing strings in the terminal as you describe. - Making information available to IDE and text editor highlighters. That requires a bit more sophistication than just this string, and could be done by one single system if it was carefully thought out. Basically, I'd like to see this inventing of hardcoded off-the-cuff suffixes in source code in an ad-hoc way to be replaced with having suffixed terms register their suffix names in some common registry of names, and then put the implementation of INFO there, globally. That's better than hardcoding it differently for each type, and helps to minimize the chance of new suffixes being added that fail to get documented. The only difficulty is how to deal with cases where the suffix names aren't actually known at compile time because they truly are dynamically created, like the resource names LIQUIDFUEL, SOLIDFUEL, ELECTRICCHARGE, and so on.

Technically, if you want to get degrees you should use inverse trig functions (arccos, arcsin) of the dot product rather than 90*the_dot_product. The dot product will vary from 0 to 1, and thus you will get a number that varies from 0 to 90 by doing what you're doing, but if you graph the curve of how it varies from 0 to 90, it shouldn't be a straight line like that. It should be a quadrant of a circle.

does not seem to work and i didn't want to take up that much space. is there a way of attaching text files to a post here?Is there some reason people seem to want to post their raw unformatted ascii text (like kos code) in spoiler blocks instead of in [ code ] [ /code ] blocks? I see that on a lot of forums and I just don't understand it. [ code ] (without the spaces) works.

LOCK STEERING is based on where you are pointing on the navball. There is no additional problem kOS is introducing that wasn't already there in the game in the first place. If you're trying to travel in a direction perpendicular to your navball facing you still get the exact same problem in manual piloting - the direction the game thinks you're pointed isn't the direction you're actually going. Why a special exception for engines? Wouldn't it be sufficient to get the orientation of any part, and not care if said part was an engine or some other sort of part? That is in the vague future plans.

I'm sure the fact that all variables are global is mentioned in several places. It's already a thing we've thought of. Development of basic low-laying infrastructure (like local variables, and self-documenting structures) has been very slow largely because not everyone has had time to be involved of late. Major sweeping changes like would be required to implement such things throughout the C# code require buy-in from everyone, and a lot of the devs have been stuck in real life issues and unable to wrangle the free time for that sort of thing. Marianoapp - the one almost solely responsible for the script compiler that makes "opcodes" and faster execution, has been off in end-of-grad-school crunch time for a while. It's very hard to make sweeping changes when key devs aren't around to get their OK on ripping their code apart and rebuilding it a different way. What's the use case for building a ship where not all the engines thrust the same direction? I don't understand what you're trying to do from your description.

The flat black is actually *harder* to read for me than the grey. When the contrast gets too high, the letters start to "buzz" harshly in my vision.

I wouldn't call them "constants", as they'll change the moment you do any thrust. LAN is probably the most useless one because to do anything with it you have to know what the arbitrary basis ray is that it's referring to. It always has to be defined in terms of something off outside the solar system that stays relatively still (nothing is totally still in the universe, but at least still enough to last for a few centuries before it has to be redefined). In the real world, it's referring to a ray drawn from Earth to a point in the constellation Ares. KSP does not have a constellation Ares, nor in fact does it have such a thing as "outside the solar system". There's nothing for the basis vector to be pointing AT. LAN is therefore an arbitrary number based on something invisible inside the KSP code that we don't have access to.

These two statements back to back seem somewhat contradictory and confusing: I'm pretty sure the second statement is true, but not the first. I've never had to swap them when dealing with the vessel's position or velocity *now* - only for the methods that perform predictions about its future (like the orbit path), and interactions with the PQS solver.

The file only stores the code prior to loading. Once its running, it's running in the same memory space as the program that called it. And yes, it's the same object passed by reference. It's following the same rules as Java and C# do. Primitives pass by value. Anything non-primitive passes by reference. I don't like this, as it's against the feel of how the rest of kOS works, being that kOS does not feel particularly object oriented on the surface of it. (I mean it doesn't even have local variables except for parameters).

Is there some reason you're offsetting the tail of the vector so it's not touching the 'far' vessel? (Why draw from the magnitude*10 to the magnitude*50 rather than from 0 to magnitude*50?) Oh, and thanks for pointing out the existence of the .xzy property. I didn't know that was a thing so I always had to mess around with swapping the axes manually (why in the heck dis squad swap the axes anyway in some cases that I'll never know). It might be a good idea to test in cases where the orbit is highly inclined just to make sure the axis swapping is correct and necessary. I don't recall having to swap axes for map view - only for dealing with the planet surface with things like your body-relative position.

The problem with your conspiracy theory is that it's very hard to imagine a scenario in which a BUG puts the throttle at exactly 50%. 0%, or 100% - maybe. But 50% is generally not the sort of behavior you'd get from bugs. Bugs tend to cause edge cases, not middle cases.

The devs are on record claiming it was deliberate and intentional because supposedly lots of newbies launch rockets, hit spacebar, and then don't know why nothing happens. I think it's ridiculous because in order to know that you hit spacebar to start the first stage you'd have to have looked at the keymapping or the tutorial first. The game doesn't say anywhere else to try that. So if you've looked at those, they also mention having to hold down LSHIFT to bring the throttle up.

There's been several references to a new gui system coming out with 0.25 when it eventually comes. I expect this to really break a lot of mods - many mods open windows using Unity's current gui tools. One problem with new releases is that mod writers can't start altering their mods to match until after the new code is released - they can't even prep for it. Could we get a preview of what is likely to be different about the gui? Not necessarily a full release, obviously, but just something along the lines of "if you use this or this or this or this API call, that's the stuff we'll be changing, so get ready to have to alter those parts of your mod."

It's entirely possible there's more than one thing wrong at the same time. But trying to both set a local transform to move you to mapFarPos while at the *same time* trying to tell the line to draw itself starting at mapFarPos is definitely a part of what's wrong. No successful solution will be doing both at once. Either you transform to mapFarPos and then start drawing at 0,0,0 - or you don't transform to mapFarPos and then start drawing at mapFarPos. You definitely don't try to do both.

No, but weirdly it does adhere to the common way things work in OOP where primitives are copied by value and complex structures are copied by reference. If you do this: set x to 1.0. set y to x. then x and y refer to two different instances of the number 1.0, that you can edit separately. But if you do this: set V1 to V(10,20,30). set V2 to V1. Then V1 and V2 refer to the SAME vector, and doing something like SET V1:X TO 20 ends up changing the value of V2:X as well because they are just references to the same vector. This is because of how it's built on top of C# and it's inheriting this behavior from C# itself. I'm not very happy with this, as it's not intuitive, and kOS does not expose the difference between value and reference anywhere else to the script programmer, so it introduces a confusion that you lack the tools to do anything to control.

One of the changes since 0.6 is that kOS now has much better vector support. What it sounds like you want is to get the error between the wanted vector and the current facing in two components - the yaw component relative to the ship, and the pitch component relative to the ship. Check this video and see the bit at the end where I give a brief overview of one way to do it with dot products, starting at position 2:50 in the video.

It looks to me, on a quick cursory glance, that you're trying to set the position of the line the same way twice, thus making it have the translation offset twice over rather than once over. See these two lines: There's two approaches to take: 1 - Give the line object a transformation matrix that describes a local frame of reference in which the origin point is zero'ed at what what the world coordinates would call mapFarPos. 2 - Use the coordinates raw without a local transform, and tell the line to draw from mapFarPos. It looks like you're trying to do both, which essentially offsets the origin point twice over.

(By the way, please quote your code using [ code ] blocks, not [ quote ] blocks, because the forum deletes all but the outermost nest level of [ quote ] blocks when replying (even with multiquote enabled, which is broken), making it a PITA to reply to the code because I have to manually cut and paste to do it.) You do not need to do this: lock steering to np. over and over and over each iteration. Why is it inside the loop? Just do it once before the loop starts. That may have something to do with why it has a hard time keeping the steering straight. You're constantly re-setting it and making it have to start over from scratch.

There is no need to do R(0,0,0)* anymore, because kOS can steer from raw vectors themselves. This is because we fixed rotation*vector so it returns a vector instead of returning a rotation, which was nonsensical ("I want to rotate this vector" makes sense, but what it did before was "I want to vector this rotation", which doesn't.) So when you do: lock np to r(0,0,0) * nd:deltav You get a vector out of it now, not a rotation. (and since the rotation was zero, you in fact get a copy of nd:deltav). Thus the complaint about PITCH. PITCH isn't a suffix because what you now have is a vector, not a rotation. If you really do want a rotation, then you can get it from any vector with the :DIRECTION suffix, like so: lock np to nd:deltav:direction. But then you do have the information loss that a vector doesn't have an "up" direction so the roll orientation will be something arbitrary. != This is <> instead of != now. Nivekk's old "!=" feature was undocumented, so when the system was rebuilt from the ground up, according to the spec, there was no 'not equal' operator implemented because we didn't know it was there, being undocumented. Then a new not-equal was implemented (again not knowing there was one already), and it was named '<>'.

There's a significant difference between using software outside your responsibility to help do tasks like this versus using software that *is* in your responsibility. That's the main reason I don't care for mechjeb, but don't mind if someone else wants to use it. If you install an autopilot onto an integrated circuit chip installed in your plane, that chip itself is *not* piloting your plane - in a sense a human being is still doing it - its just a human being who worked at typing in software in an office on a computer keyboard some time in the past. Computers don't make decisions. The people who wrote the software for them made the decisions. And I want those people to be part of my Kerbal's Space Program, not entities that exist outside of it. If I can't make errors then it doesn't feel like a sense of accomplishment when I get it right, at least not to me. With mechjeb, I can't make errors in the autopilot's algorithm. Only the dev team of mechjeb can do that.

Every time I try to connect to KerbalSpace.Spazer.net port 3416 (stock, sandbox), I get to the point where the status window says: Syncing Vessels 134/135 And it just stops there. KSP hangs and has to be killed from the task manager. I get lots of spammed messages in the output_log.txt about the DMP cache being full and it deciding to delete ships because of it. I checked my settings but the cache is at 100mb which is stated as being the max allowed value.

Has anyone else noticed this: On the title screen if you try to connect to a DMP server that's offline (so you get a long timeout wait before it tells you there's no response), and you get impatient and try to click "quit' from the main KSP menu during that timeout, it freezes all of KSP and it requires a CTRL-ALT-DEL Task Manager hard kill to get unstuck - you can't even alt-tab out of it.

Which is the same figure I described. The reason it has no units is that all the units cancel out in the calculation as it's essentially a ratio that can be inserted into formulas in a few different ways. The problem is over what KSP means by it, not what the real world means by it. Citing real world definitions won't alleviate that problem. In this case, I don't know which "propellant" they're counting - the sum of both? The sum of both only if it's NOT a jet, and just the liquidfuel if it is a jet? If you're using it to calculate how much dV you can achieve from it then you have to to answer that first. You have to know if it's exactly including the propellant *that is being carried on board* or if you have to fudge the numbers because it's also including propellant not carried on board (jets counting the oxygen) or failing to count propellant that is carried on board (rockets not counting the oxygen). It's not "I don't know how real rocket programs do it". It's "I don't know how SQUAD did it.". I could just utterly ignore the problem of not knowing what SQUAD includes in their ISP numbers and just hand you the number from the API as-is and let you deal with it - but then I cannot also calculate the dV. To get the dV I do need to know which propellant(s) they used in the ISP number. In general I think the solution is just to provide a way to LIST ENGINES THAT ARE ACTIVE INTO VAR. (not with that exact syntax of course). Then you can decide what you want to do with the ISP numbers that come out ( and if you only have 1 engine active at a time, then you don't need to work out how to average them together and how to weight that average.)

A general case solution, which is what kOS would have to be written to provide, not just a solution for your case, cannot use the word "the" here, as that makes it stop being general case and instead makes it only work if you design a rocket with one engine firing at a time. If there's more than one engine firing, then you either iterate over them yourself or you get one lump sum from kOS for all of them. If it has to be returned as one lump sum, should it be an average of their current ISP's? What counts as "in the current stage" is a very messy algorithm in general, because people can use fuel lines and/or crossfeed to blur the dividing line between stages. At the moment, the definition kOS uses (for things like stage:liquidfuel) for "in the current stage" is to walk the parts graph starting from each currently active engine, truncating the walk at any point where a connection between parts is not crossfeed capable, and throwing away all the duplications (engine 1 sucking fuel from tank 12345 and engine 2 also sucking fuel from tank 12345 - both find the tank in their walks, but the tank should only count once), and summing up all fuel found during that walk. Because that's the definition used, and it seems to match the definition KSP itself is using to calculate its little green bar graphs of fuel, the only sort of meaning "this stage" could have for ISP would be "all the engines that are currently active". Would this do? The Isp is the ratio of the velocity of the exhaust products to the acceleration due to gravity ASL on Earth. This avoids all the confusion about fuel and oxidizer, all you need to worry about is the mass leaving the ship thru the engine. Jet engines have an ISP number as well, but take their oxygen from the atmosphere, not from the fuel tanks. So the assumption inherent in that sort of calculation, that all the mass being thrown out the engine at that velocity is mass that came from the ship's fuel being carried, doesn't hold for jets. The ISP doesn't have units because it's actually measured lots of different ways to come to the same number. Another measurement is that it's a unit of time - the number of seconds that a given amount of fuel will last if being used to push steady at a particular constant force (how many seconds of thrust do you get from 1 kilogram of ship mass being thrown out the back (fuel being burned) at a throttle setting that pushes at only 1 Newton.) This is the calculation that's useful for calculating fuel consumption and how much DV can you achieve. But the problem is that I don't know what the game is using for this calculation in the case of jet engines where not all the output mass is coming from the ship's own input mass, and some of the output mass was sucked out of the atmosphere.

If there was an abstraction that gave the ISP for the whole ship, what would you want it to tell you? - the total highest ISP of any one engine, calculated among the ones that are active now, or calculated across the whole ship? - the total lowest ISP of any one engine, calculated among the ones that are active now, or calculated across the whole ship? - the weighted average ISP of all the engines, calculated among the ones that are active now, or calculated across the whole ship? - the weighted average ISP of all the engines, calculated among the ones that are active now, and taking into account the fact that all the engines might not shut off together at the same time (asparagus) so it's weighted also by how long each would burn for? And of course, if you're moving through the atmosphere, ISP changes as the air get thinner, so the ISP right now may not be the same as the ISP later on, making predictive calculations on it a bit messier. Incidentally, you can calculate the rate of fuel loss that's occurring at the moment by, in a loop, comparing the current fuel left on the ship to the previous fuel left on the ship on the previous iteration, and compare that to the throttle setting you had during that moment and how long that moment took, to dynamically calculate your own ISP for the previous moment. I don't know if this suits your needs. Now that I think of it, there's two types of fuel you're burning, liquid and oxidizer, and I don't even know which one the game's ISP numbers are calculating - the total sum of combined mass of both that's being burned? I guess if you're using it for DV calculations it would have to be that.