Dunbaratu

Then why do I remember over and over again seeing the engine nozzles tilting back and forth as kOS yanks the controls back and forth (in its overzealous way)? I know I've seen it do this a lot, but then again I don't play under RO. Is it a specific thing the RO mod does to change the API for gimbals? As far as I knew, kOS lock steering merely yanks the "joystick" WASDQE controls around, and lets the main KSP game engine do whatever it will with those inputs, without making any fancy exceptions. The main game gimbals when you use WASDQE, so why doesn't kOS when it does?

This is false. When I play stock and lock steering I see the engine exhaust is being aimed back and forth as it steers all the time.

You can paste it into the editor sub-window, though. I have no idea how you would go about reading the cut buffer from inside Unity, but Unity's own text editing widget knows how.

At the moment there is not. Two things I'd like to see are: 1 - A way to say "Return me a list of N things that are all copies of blarg": i.e. SET fiveAs TO LIST(5,"A"). // 5 things, each one is "A". 2 - A way to say "Make me a list of the things in this tuple": i.e. SET fiveAs TO { "A", "A", "A", "A", "A" }. None of these exist yet, but they probably could with some work.

"GMO" is too open-ended of a generic term to make a positive or negative judgement call. It's a bit like saying "is water dangerous" well, that would depend. Drinking it is healthy, but breathing it isn't. Rivers are necessary for life... but a temporary river running where one normally doesn't is called a flood, and that's not so good for life. There are some people who complain about GMO's for utterly ridiculous luddite reasons, akin to the stupidity of people using the word "chemical" as a generic scare word ("OMG this has chemicals in it!") forgetting that ANY molecular structure is a chemical, including water. They're wrong. But there are others who raise concerns over the legal issues surrounding trying to make self-replicating life organisms fall under intellectual property law, and some of those legal concerns are quite valid. One legal concern is how some weed killers work in conjunction with GMO crops. The hard thing about a weed killer is that you want it to kill everything that is NOT the crop plant, but leave the crop untouched. One solution is to make GMO crops that are resistant to the specific brand of weed killer, and then sell that weed killer and that crop seed together. The problem comes from the fact that the weed killer can spread to neighbors' farms, thus forcing them to also be customers of the same company, buying the same seed, to keep their own crops from getting killed. Being forced to use the same product that your neighbor is using is a monopoly problem. To summarize - there is no scientific problem with GMO food. There is, however, a lot of legal concerns. It centralizes control in the hands of a few.

I have found that often what can help with this problem is to check for *either* type of fuel running out. If you have a sliver of liquidfuel left but zero oxidizer, then the last liquidfuel won't burn because there's no oxidizer to go with it. So the check should really be that you use a boolean 'or' to check check for *either one of them* being zero, not just one. The exact amount of oxyidizer and liquidfuel is meant to be just the right amount to make them both hit zero at precisely the same instant, but I suspect that what causes the problem is a slight amount of floating point rounding error. It's a very small amount, but it accumulates over thousands upon thousands of calculations because KSP is running the calculation again and again 25 times per second. Say, you burn 0.5 units of liquid fuel per second, which means it pairs with burning 0.61111111 (repeat forever) units of oxidizer per second. Well, that's really being calculated in 1/25 of a second timesteps so it's really 0.02 units of liquidfuel and 0.024444 (repeat forever) units of oxidizer per 1/25th of a second. You can't *actually* represent 0.0244444 (repeat forever) as a finite binary floating point number. You can only get close with roundoff error. So over time, the amount of oxidizer being burnt isn't *exactly* right for the amount of liquidfuel being burnt. It's as close as floating point numbers will allow, but that's not 100% precise. Given enough time, that small error accumulates into something noticable, and you end up running out of one type of fuel before the other type.

stage:liquidfuel is always zero when you first start because the current stage is the pre-launch stage with no active engines yet - you haven't hit stage so you haven't enabled your first engine. Therefore your WHEN condition is already true immediately.

Technically, knowing binary isn't enough. You also have to specify which character coding. ASCII? EBCDIC? UNICODE?

In the telnet server's current implementation you can't quite use the scrollback buffer reliably that way. It only works if the things you printed to the screen were printed *slowly* to the screen. If you spew a lot of text to the screen all at once, such as with a PRINT SHIP:PARTS. or a LIST FILES, or something like that, then the rate at which it gets printed exceeds the rate at which the telnet server updates the client. So let's say that LIST FILES ends up spewing about 3 screenfulls of text all at once. Chances are very high that the telnet server will only send your telnet client the characters of the lastmost screenful of that. The telnet server's goal is to make your telnet window look like the in-game GUI Window, which it does by diff'ing what it believes your telnet client window actually looks like at the moment against what the window should look like at the moment, and sending the right characters to make the difference happen. It does this about 20 times a second. If the printout is faster than that, then the telnet server only tries to make your client look like it should NOW, not to send it the intervening text that has already scrolled by before it ever got sent to you. That being said, you can hit PageUp or PageDown to scrollback, but that's actually causing the server to send you new screenfulls, in our software, rather than it being your telnet client doing it (and it also works in the in-game GUI terminal to do that).

Some variant of this might work for you: // Assuming you have these three variables already: // __compass__, __pitch__, __roll__ // (the underscores are just there to help you see where they plug into the // code below) // // make pointVec the vector direction to point: lock pointVec to heading( __compass__, __pitch__):vector. // make topVec the vector pointing to the desired topward direction of your ship: lock topVec to angleaxis( __roll__, pointVec) * ship:up:vector. // make a lookdirup out of those two: lock STEERING to LOOKDIRUP( pointVec, topVec).

Generally it's unnecessary to raise the same question both here, in reddit, and on github. When you make a github issue, the devs definitely see it right away. We both have alerts set to notice when a new one is posted there. - - - Updated - - - There's a chance we may be able to eventually put the optional 3rd argument to HEADING back in place. The reason it was removed was that a change to the architecture made it impossible for a function to count how many arguments it was being passed. It had to hardcode a fixed number of args and stick with it. So optional Args didn't really work well anymore. But we may be on the way to being able to query how many args were passed, and make the built-in functions (like HEADING()) able to behave differently depending. But even if so, it would still be a long way off yet. But it *might* come back some day.

You could also maybe simulate the sorts of chips often used by small homebrew projects that contain an array of NAND gates inside them, so that each set of 3 pins maps to one of the internal gates, and you might get a dozen or so gates in one chip. And if you have switches you "turn on" with action groups or rightclick menus, then you automatically get kOS script support "for free" that way. (i.e you can design a system made of a hybrid mix of software and hardware to do tasks - by having a kOS script "trip" one of the switches built with this mod.) I like this. Good luck with it - I'd like to see it work.

Is it your goal to do this with a bunch of small surface-mounted parts you can hook together? (i.e. pick up a NAND gate from the parts bin, stick it to the side of the rocket, then pick up an OR Gate and stick it under that, and drag a line from the output of the NAND to the left input of the OR, then..... etc). That would be a neat teaching tool for basic electronics logic.

That was never in the language. what is (0-Pitch, Yaw, Roll) ? Is it an R(), a Q(), a V() ? You just typed a tuple without the preceding letter identifying what type of tuple, and that was never a thing in the language.

When I get functions into kOS I will be adding a RETURN statement to go with it. That should give you the ability to do early exits, provided you make the main body of your program be a function.

The fact that it's easy doesn't make it useful. Often you can reduce memory footprint *by* using a more complex algorithm. That results in a bigger DLL but a smaller memory footprint. Just listing the GameData contents only shows the disk footprint, which can be quite misleading and trick a person into blaming the wrong mod for the memory usage. Yes, just giving the titles of the mods for other people familiar with those mods to look at is useful, the the implication was that this wasn't the reason you asked to list the GameData folder, but rather it was because of those disk usage sizes you posted in your example.

No, actually, it wouldn't. That only gives you an idea of the size of the code complexity, NOT the size of the memory it uses once loaded. Take for example the following pseudocode program: L = some sort of list. for x goes from 1 to 1024 L.Add( allocate an array of 10485676 byes padded with zeros ) That's a PUNY tiny program... that eats 1 gig of memory.

Are you sure this is a question about Action Groups Extended?

Also, be aware that if you have the PresMat Barometer attached to your ship, kOS can get the readout from it, with SHIP:SENSORS:PRES. I used that in a launch script to work out stock KSP terminal velocity, like so: // The density of air in kilograms per cubic meter // at a pressure of 1 atmosphere: set atmToDens to 1.2230948554874 . // 'e', as in the natural log base: set e to constant():e. // The typical drag coefficient in SQUAD's formula for most parts except parachutes: // If you assume your ship is made of typical parts and you aren't trying to launch with // parachutes active, this will also be the average across your whole ship then: set drag to 0.2. // m/s^2 gravitational acceleration here (i.e. 9.802 for earth at sea level). lock heregrav to BODY:MU / ( (SHIP:BODY:RADIUS+SHIP:ALTITUDE)^2 ). // You can lock this to surface vel, or oribital vel. // Depending on how high up you are you might want to switch it: lock useVel to ship:velocity:surface. print "Current Pressure is" + SHIP:SENSORS:PRES. // air density here: lock dense to ship:sensors:pres * atmToDens. // Force of drag from air pressure here: lock fdrag to 0.5*( dense )*(usevel:mag)^2*drag*0.008*SHIP:MASS. // Terminal velocity here: set termv to ( (250*heregrav)/( dense * drag ) ) ^ 0.5 . // divZero? Obviously none of this will be right anymore once stock aero gets changed in 1.0.

Is there a reason the algorithm fails when using a simple cylindrical projection? (Does it end up distorting the path under a false notion of how far apart the points are when closer to the poles?) Maybe the algorithm could be altered to weight the cost of moving to a neighboring vertex based on what latitude it's at. On a cylindrical projection, the farther from the equator you are, the less it costs to move one hop east or west to the next vertex. If that weighting could be added in to the algorithm, you might not need a cubed sphere.

Is there some reason the algorithm depends on data being pre-stored before it starts? Is there a reason it can't calculate altitude at a given location on the fly when it examines it? I mean, the probability that the optimal path ends up going all the way around the other side of the world seems pretty remote to me, so why pay the expense of calculating the height map for all those locations the algorithm is unlikely to need to visit?

Can you show a screenshot with the part menu open? And scan the output log for the word "kOS" and see if there's any exception messages.

i won't be home for a while

what time?

That's the way the mod behaves. Time is sort of 'stuck' in the editor, which would make many of the things the mod does be very messy and screwed up (like reading your velocity when the clock isn't going). Rather than try to make exception cases around all of that, the mod is just disabled on parts that are still in the editor and not fully "real" yet.