Dunbaratu

The problem isn't caused by the ground becoming lower detail. It's caused by the ground literally no longer being there *at all*, low res or high res. At farther distances, KSP replaces the ground with something that amounts to just a fake image that has no physical substance of any kind. The ground becomes just a hologram. Ironically, it actually can make the visual detail *higher* when it gets farther away and changes to a hologram instead of a mesh of physically collide-able polygons. (Thus why mountains look nicer from a distance than close up.) What the MCE mod did to deal with this problem is just put a hook on the moment a craft becomes unloaded (i.e. farther than 2.5km away if stock rules are used), and when a bit of debris goes away because it's too far from the camera, a check is performed to see if it has deployed and ready parachutes on it, and if the planet it's around is Kerbin. If so, then it treats it as if it had "landed" right then, giving you the same salvage money back that it would have had it landed. There's no reason the stock game couldn't do that too, but I can see an argument against it being a realistic idea to do it. The reason they don't bother recovering most first-stage rocket parts in real life isn't a matter of it being impossible to do so, but rather because the wear and tear of the launch and hard parachute landing would render it unsafe to reuse the part. They're designed to withstand the abuse of the launch long enough to last just the one launch. The shuttle's solid boosters were a rare exception, and it can be easily argued that it was proven to not be a good idea given how much it cost to refit them for a second use, and what famously happened to them on one occasion.

It would be nice for people writing mods to know ahead of time if they're working on something that the stock game will: - eventually have in a year or so, or - eventually have, but not for a long time yet, or - never have. Because if the thing your mod does becomes a stock thing, you have to either throw away your mod, or at least redesign it from the bottom up anyway because the API has been completely redone in that area. From the point of view of the mod writer, not knowing SQUADs future plans means having no idea whether or you should design your mod as a temporary stopgap or design it as a major longterm project with a deep underpinning and complex code engine under it, or just not bother with it at all. SQUAD changing their mind on a thing they previous said they'd never do can mean a mod writer out there wasted a lot of personal time and effort.

The LIST command should strip off the .txt from the display. Is the actual file in the archive called "hello.txt.txt"?

The docs don't say run won't work when switched to the archive but it seems to me that you would never want to run a program off the archive for various reasons (such as losing comms, or corrupting the file). Therefore I would assume the run command only works on files stored on the local volume. You should copy the file to your local volume and then run it What Avdacar described *should* work, actually, You can run files directly from the archive so long as you have radio range (a check which is currently disabled anyway because the future plan is to only enable that check if you have RT2 installed). Advacar, can you post the exact sequence of commands you run and the exact output you get? (A screenshot showing the terminal window would be great if you can frame it up so it all fits on one screenshot).

Was what you posted the entirety of your program or was there some missing context before and after the part you quoted? The reason I ask is that it looks like one straight fall-through if/else ladder without a loop around it (again, this is assuming you posted everything and not just a subset of the code). If that's true, then a big problem you'd run into is that an if/else ladder will only execute ONE of the conditions inside, never more than one. Consider this example code snippet: set x to 4. set y to 5. if x > 0 { print "x is positive.". } else if x < y { print "x is less than y.". } else { print "x is neither positive nor less than y.". }. Consider that code - BOTH the first conditions are true - X is both positive AND it's also less than Y. Therefore you might think it will execute both sections and print: x is positive. x is less than y. But it won't. It will only print the first one: x is positive. Why? Because it says "ELSE IF", meaning "only perform this check if the previous check failed." It will only ever check the second condition (x < y) if (x > 0) was false. Once the first check succeeds, it will skip ALL the remaining checks and drop all the way to the bottom of the entire if/else structure. So at first ALTR is < 80, so it executes the "DO TAKEOFF STUFF", and once it finishes that it skips past all the other checks, because it already knows the first check worked so all the other "ELSE" checks won't work because they say "ELSE" - meaning only try them if the previous conditions didn't succeed. (Now, if you wrap all this in a loop, that's different. Then on one pass through the loop it might do the first part, and on a second pass through the loop it might skip the first part and try the second part, and so on.)

To malkuth: I've had a lot of fun with this mod over the last several months, and I just wanted to give you a "thank you" for it. With 0.24 I will probably stop using MCE for a while, until you figure out how you're going to integrate it with the new features of stock (which I'm certain will require a massive re-write of this mod).

Above a certain altitude, the game switches modes from: - Planet stays fixed in space, and the universe rotates around it. to - Planet rotates in space, and the universe stays still. At low altitudes it keeps the planet stationary so that the terrain polygons don't have to be constantly repositioned as the planet rotates, which would lag animation to a standstill. So I suspect you might be seeing something happen at the transition between those two modes, but it's hard to tell for sure.

The problem was that layer 10, the map view layer, is being drawn all the time, even when not on map view. Therefore raycast is hitting the map view's version of the Kerbin planet even when not in map view. Masking off layer 10 from the raycast fixed it.

Contract: Burn name in Mun Agent: Chairface Kerbindale task 1: build excavation rover. task 2: land craft on Mun. task 3: excavate letters. Partial credit: ++Money per completed letter, but -reputation per completed letter.

C# strings default to unicode rather than ascii, so I doubt that's the problem. While they could put localization support in the code and let the fanbase do the translations, I doubt that Squad would want to farm out translation to the fanbase. You have to put an enormous level of trust in the person that you are letting rewrite everything your game tells the user. You might want the assurance that the translator has some degree of financial obligation to do it right (i.e. someone you contract out to do the task, rather than a random volunteer). If nobody on your own dev team knows the target language, you are giving the translator an opportunity to put whatever words they feel like into your company's mouth - insults, plugs for other games, libelous statements, etc. The extra trust you'd get from knowing you could sue them for a breach of contract if they do that might be important. The game does seriously need localization support in the code, but I doubt they'll want the fanbase to write the text.

[ addendum ] I also found out after all this work that despite the implications of the name, the RayIntersection function doesn't even calculate intersections with the terrain *anyway*. It just finds the intersection with the sea level sphere, which I could have easily done with my own math. (Making me wonder why on earth it's part of the PQScontroller when the information it needs to find the sea level sphere intersection is just position and radius of the body - surely it's got nothing to do with the PQS terrain and thus belongs just in CelestialBody....grumble.) That was a lot of work for nothing. It turns out I'll still have to write a homemade terrain intersect solver anyway. It will be a numerical approximation by slices, which can be computationally expensive. So I'll have to find a tricky way to allow it to store the state of the partially complete numerical algorithm between Unity updates so it can take, say, 2 or 3 updates to finish the algorithm - otherwise I'll be starving other mods of CPU time.

I just posted a "WIP" thread for a tiny mod that I'm planning to have work with kOS in the future. The idea is to make an instrument that reads distances by laser, let you place several of them on your vessel, and then read their values to have script code work out things like terrain slope in 3-D, or whether or not there's a mountain to the side of you. It's still very alpha at this point, as I still need to implement a proper use of KSP's distant terrain height mapper (called PQS), that right now is crude and gives inaccurate values, but for distances less than about 7000 meters or so, it seems to be correct.

LaserDist [WIP, Plugin, Parts] (2014-10-16) LaserDist 0.5 for KSP 0.9, Alpha Releases: * https://github.com/Dunbaratu/LaserDist/releases ZIP Download (See release page above): * https://github.com/Dunbaratu/LaserDist/releases/download/v0.4/LaserDist.zip Source Code Hosting site: * https://github.com/Dunbaratu/LaserDist License: * GPL v3 Copyright © 2014 Steven Mading (aka Dunbaratu on Github) madings@gmail.com This is a very small plugin. It makes a KSP Part that measures straight line distances by laser. The "Beamer 100x Disto-o-meter" Part aims a laser in a line and then measures the distance in meters to the first object the laser hits. The result is displayed in the right-click menu for the part. The laser can work over long distances - here it's measuring the distance from a Kerbin orbit vessel to the Mun: And even at those very long distances, the lasers can measure rather small differences in distace, within reason (it has an accuracy of 2 meters at this extreme range, to keep the game from bogging down too much). In the screenshot below, notice how the two lasers are returning different numbers for their distance to the terrain very far away: The direction of the laser is whichever way the laser gun is pointed when you mounted it on the craft, as demonstrated here: The electric draw for the laser is substantial. Each laser consumes 1 electric charge every 3 seconds that it's on. Why does this Mod exist? The intended purpose of this part is to be used in conjunction with scripted autopilots like [kOS](https://github.com/KSP-KOS/KOS/releases), to provide a way to for you to write scripted pilot software that can see the distance to the ground (or anything else like a ship) along the laser line. The reason this can be useful is so you can detect things like terrain slope and mountains in the way. The default radar altimiter in KSP only shows you the distance directly under the craft. In a nutshell, the purpose is to solve this problem shown in this picture: This mod can let you read the distance along the blue line in the diagram. Why isn't it inside kOS then? There is more than one KSP mod project for the purpose of letting users write scripted autopilots. Another such project currently under development is Jebnix My goal is to make this part script-engine-agnostic so it works with any such mod. I've been working in kOS mostly, but I didn't want this part to be kOS-specific because there's no particular reason it has to be. Information for other modders trying to use the part: As long as the scripting autopilot is designed to be able to query and/or set KSPFields on parts, it should be able to read the value of the distance, and turn the laser on and off, as follows: KSPField: 'Distance' is a float - the number of meters being shown in the display. It's -1 if there is currently no hit. KSPField: 'HitName' is a string - the name of the object being hit. KSPField: 'Activated' is a bool - true if the measuring device is on. KSPField: 'DrawLaser' is a bool (called "Visible" in the GUI) - true if the laser should be drawn when it's activated or false if it should be (realistically) invisible because, hey, it's coherent light and it's not supposed to be seen from the side. KSPField: 'CPUGreedyPercent' is a float (called "CPU hog" in the GUI) ranging from 0.0 to 20.0. It's how much of a single physics tick of time this mod will allow itself to consume during a single Update. If it hasn't gotten a good enough answer within that much time, it will wait until the next update to continue the calculation. KSPField: 'UpdateAge' is an integer - It's how many Unity Updates (animation frames, basically) it's been since the value you are seeing was calculated. Becuase of the logic of CPUGreedyPercent (see above) sometimes the value being displayed is stale by a few update ticks and shouldn't be trusted until the next time that UpdateAge becomes zero again. If you're in a situation where this mod needs to spend more than 1 update of time to get to a good answer for the distance, you'll see this value spinning a bit, quickly going 0,1,2,3,0,1,2,3,0,1,2,3...etc. When you see that, only when it hit the zeros was the distance value perfectly correct at THAT moment. Note: The higher that CPUGreedyPercent ("CPU hog") is, the less likely it is that UpdateAge will ever be nonzero, but the bigger hit your framerate might take. How to Mount it. . The Beamer 100x Dist-o-Meter is located in the "Electronics" tech node of the career tech tree. It's a 300-point node on the tree so you might not have it yet in a new fresh career game. The Laser can be mounted anywhere as a surface-mount item. Take care to note the orientation of the laser emiiter. (KSP lets you fine-tune the rotation of a part by using the SHIFT key while you hit the WASDQE keys.) The Laser will bounce back and give you a distance measurement when it encounters ANY object, including parts of your own craft. So take care to mount it somewhere where the laser beam will have a clear line of sight without obstruction. To ensure a good mounting point, you can use "tweakables" to enable the laser and make it show up in the VAB to look and see if you have it aimed well. Lightspeed Note that if you use it to measure the distance to a far away body (i.e. like aiming it at Duna from Kerbin), the mod does take into account lightspeed. You have to hold the laser on an object steady and unchanged for the entire duration of time it takes for lightspeed delay to bounce the signal back or you won't get a measurement, so using it at that great distance will be very hard. FUTURE EXPANSION PLANS (i.e. the reason this is a WIP) Max distance isn't enforced yet: It's part of a future plan to have different variants of the part that work better the higher up the tech tree you go. For now, despite what it says, the range is actually infinite. Other sorts of sensors?: Now that the numerical approximation behind making a "fake raycast" that finds intersections with the planet terrain from far away and from any angle is implemented, this opens up the chance that other sorts of long range beam sensors could be made. For example a "biome detector" that returns the name of the biome where the hit occurred is a possibility, as is a "density at a distance" measurement which might tell you the atmospheric pressure or density at the ground level where the hit occurred. (Maybe because of something that the laser detects about interference with the air? It's a bit hard to justify realistically how that would work, but it's definitely possible with the software. Just not sure if it's possible in the real world, or whether real-world sanity is really the intent of this mod or not. How do I use it from my script then? Very Soon Now the dev team of kOS (of which I'm part) plans to have a release that lets you read the fields of any part's KSPFields (The stuff you see in the rightclick popup user interface panels), and manipulate any part's widgets on the rightclick menus (the buttons, the sliders, etc). The plan from the beginning was to make LaserDist be a good test case of this feature that may actually be useful in its own right. But that's not released just yet. So at the moment this is only usable as a manual piloting aid where you leave the part menu open and look at it by eye as you fly. Part modeling help? I am aware that the artwork on the model isn't pretty. I'm a programmer, not a graphic artist, and I don't have experience with things like Maya and Blender. In fact I just made the model by slapping together some stretched Cube and Cylnder objects in Unity itself, without the aid of a modeling program. The model is good enough to work with, but I'd be happy to have someone better at art redesign the model. I included the model in the github directory if you want to have a look.

The message "Collection was modified, enumeration operation may not execute", does not come directly from kOS. It comes from C#. It happens because C# iterators are limited to only work when the collection is frozen during the iteration. It can't deal with altering a collection while iterating over it like some languages can. If you insert, remove, or modify an element inside the LIST while you are trying to iterate over it with an iterator, you will get that complaint. You didn't explain in your post how the code snippets you posted are included in the main program, but is it possible for this line: set recentLogList:remove to 0. Can get executed while inside of this loop: until not logItem:next { ? (i.e. is that SET command happening inside a WHEN trigger so it could happen during the loop?)

When I redid vessel velocity, I dropped it because the code had this comment above that suffix: //TODO: I created this one for debugging purposes only, at some point I'll make a function to transform vectors to headings in a more eloquent way I don't know who the "I" was in that comment, but I assumed it was never officially documented or published as working so nobody was using it. By the way that better way never seemed to get implemented. You can get a 3d direction from a vector but not a 2d compass heading without some vector math with a cross product with the north vector.

Are there any known bugs in the display of the cone in the map view? Because the display showed a cone wide enough to fir the whole orbit of the satellite in question.

That did not work when I tried it. Only aiming at the specific satellite worked.

I found the problem with a LOT of trial and error and frustration. With the function call: public bool RayIntersection(UnityEngine.Vector3 worldStart, UnityEngine.Vector3 worldDirection, out Vector3d intersection) The 'worldStart' parameter is correct, but the 'worldDirection' parameter is being read utterly wrong by the function. The problem is that it seems to be always rotating it off the wrong direction. To overcompensate for that I have to rotate it twice the correct way, to compensate for the fact that it rotates it once the wrong way, like so: Vector3d useWorldDir = pqs.transformRotation * ( pqs.transformRotation * worldDir ); And then pass in useWorldDir as the second argument to RayIntersection. I'm fairly sure this has got to be a bug. I now suspect the API call isn't being used anywhere by SQUAD themselves because there's no way they could be using it the way it is now without it being discovered to be wrong.

I have tried this a number of times and found that it just doesn't work at all. If I target the Mun from a kerbin-orbiting satellite with a dish, then none of the satellites around the Mun will make contact, even though they are well within the cone showing on the screen. What's wrong? On the other hand if I aim at the specific satellite then it works.

Use the unity primitive called LineRenderer to draw a line. GameObject lineObj = new GameObject("laser line"); bool isOnMap = MapView.MapIsEnabled; lineObj.layer = isOnMap ? 10 : 1; // 10 is the map layer, 1 is the transparent effect on flight cam layer. LineRenderer line = lineObj.AddComponent<LineRenderer>(); line.material = new Material(Shader.Find("Particles/Additive") ); // generic flat texture Color c1 = new Color( 1.0f,0.0f,0.0f,0.5f); // red, semi-transparent. Color c2 = new Color( 1.0f,1.0f,0.0f,0.2f); // yellow, even more transparent. line.SetColors( c1, c2 ); // color of start/end of line drawing - Unity will make a fade effect between the two colors line.SetVertexCount(2); // Despite the name, LineRenderer actually renders a path of lines, not a single line, so to just render one segment limit it to 2 vertices. line.SetWidth( 0.5f, 0.5f ); // width of start/end of line. might need it wider on map view. line.SetPosition( 0, __put_some_poistion_vector_here___) ; // start point line.SetPosition( 1, __put_some_poistion_vector_here___) ; // end point line.enabled = true; // line is invisible until you do this.

Since it's a matter of opinion how much calculation constitutes a"crapload", I can't answer that. Your post contains no information about how you're trying to read the pitch, so it's not possible to answer it. To find out if you're going up or down a slope, check if the upward facing vector is aimed closer to your velocity direction or more away from it. Do that with vector dot product. // Put this somewhere inside your main loop: set upvec to up:vector. // a unit vector pointing straight up. set velvec to ship:velocity:surface:normalized. // a unit vector pointing in your velocity direction. set dp to vdot(velvec,upvec). print "travel direction slope is " + ( 90 - arccos(dp) ) + " degrees". If your velocity is exactly perpendicular to "up", the dot product is zero. If the angle between velocity and up is less than 90, then dp is positive. If the angle between velocity and up is more than 90 degrees, then dp is negative. Since both upvec and velvet are unit vectors, the dot product between them is the cosine of the angle between them. (EDIT: There's also a vector function VANG that gets angle between vectors directly, but I'm used to using dot product for it, and I strongly suspect that VANG is implemented with dot product under the hood anyway.)

The fact that you can't do a 'wait' inside a THEN clause is still true regardless of whether it happens directly or via a call to a subprogram. The problem is that the WAIT statement waits until the next physics timeslice to perform the check, but the THEN clause all occurs within one physics timeslice.

Wait, does the code execute or does the console inform you that you never defined turnSpeed? Those seem to be mutually exclusive descriptions of the situation, since seeing that message would mean the program dies there and never gets to the part where it even tries to execute abs(target:bearing).

What happened is just that your target wasn't set when running the program, but it was set when running the interactive command. Unfortunately one thing I really don't agree with about how TARGET works is that when you have no target set, the keyword returns an object of type STRING instead of one that is a vessel or body. When you have no target set, then TARGET is the string "NONE", so you get the problem that you can't get the :bearing of a string. The reason I don't like this is that the kos script writer is helpless to protect the program against this problem given that there exists no tests for the type of an object. You can't say "if TARGET is a string do this, else do that". There's also no way to check if an object is NULL so you can't have TARGET return NULL when there's no target either.

The problem is that I already have proof that I have the world coordinates correctly because I'm drawing a line using Unity's LineRenderer using the same coordinates so I can see on screen that my idea of the ray described by the world coordinates is matching what I think it is. Also, I'm able to use those same numbers while low to the ground in a physics.raycast to find ground polygons and it works them. and Physics raycast is supposedly also using world coordinates too. That's the 'proof' that it's not using the same coordinates system as the one called "world coordinates". I also tried scaling the coordinates to map scale using scaledspace to see if the intersection presumes it must take place in mapview space, but that doesn't seem to make any difference. The problem is *still* that the aim is in the wrong direction and finds hits that aren't hits. I wish I had an example that actually worked to go from. You can use inductive reasoning to work out what a thing is doing only if you have both examples of it working and examples of it not working to derive from.