Dunbaratu

That definitely sounds like a bug.

Sorry. Why I didn't think you were trying to answer that question, but instead were talking about what I described doing in my code, is because saying that putting the code in Update() is something that only "usually" works isn't really a good defense of what Unity did in their documentation. It's just that it puts me in the uncomfortable position that in order to believe that raycasts are meant to go into FixedUpdate, I have to believe that the user community who says this are *better* informed about how Unity works than the very person (presumably who works for the company) who wrote Unity's own documentation. I know Unity's docs are bad but I thought they were only bad in the sense that there's a lot of omitted details, rather than being bad in the sense of including details that are wrong, which is even worse than omitting them. I have zero doubt that there is no error in what I did there. Either the coordinate I hardcoded within the model space is in the right place or it's not. It's not going to be in the right place 70% of the time and the wrong place the other 30%. That being said, if it can be embedded into the model file then it's a better place to put it not because of the claim that it's a potential place for the error I'm getting, nor because I am "adding steps", which I'm not, but to make it easier to keep things consistent when there's future changes to the model. The decision as to the shape of the model and the decision as to where to start the ray within the model's local coordinates would then be in the same place so the two decisions are edited adjacent to each other within the Unity editor. The reason to make the change is to accommodate future edits, not for the current problem which has nothing to do with it. I'm not "adding steps" by doing the work of manually choosing a ray origin point outside the Unity editor instead of inside it. It's still a manual hardcoded decision either way. It's just better to make that decision in the same place as the place where the model is edited because then it's easier to notice that if one changes the other should be changed too. (on spherecast/cylindercast) (This isn't a disagreement with you, but with Unity for choosing terms that clash with each other.) Maybe I'm not making the clash clear. "Spherecast" is apparently being used by Unity to mean "extrude a shape along a line, and in this case the shape is a sphere. The resulting shape of the check ends up being a capsule". That makes it sound like the verb "to cast" means "extrude the named shape along a line to see what it hits". But that's utterly contradicted by the name "Raycast". If that was what "to cast" meant, then "Raycast" should have been called "pointcast" instead. It's a point, casted along a line, the result of which ends up being a ray in the end. If "cast" really meant "extrude along a line to see what it hits" then that would mean if you call something a "raycast" it would actually be half of a flat plane shape - a ray that's been extruded along a line. That's why I was saying "spherecast" is the wrong term. Because the word "Raycast" has already established that when you say "FOOcast", the FOO in the word is describing the final shape the check will have, not the shape you're going to extrude to get the final shape. Looking at it that way, a "spherecast" would mean a sphere-shaped check, not a capsule-shaped check. Thus why I said "cylinder" was a better term. Granted, "capsulecast" is a better term than both cylindercast and spherecast, for the reasons you gave. But I'd say that between "spherecast" and "cylindercast", that "spherecast" is the one that's more incorrect. *if* "raycast" is a name that is taken as sacrosanct and needs to be left alone. Alternatively the contradiction could be handled by going the other way and keeping the name "spherecast" but then changing "raycast" to "pointcast". The contradiction is in whether "casting FOO" means to extrude the named shape FOO along a line as you check for intersections, or whether FOO is the description of the final shape itself, and 'cast' just means to check for intersections with the shape that was named FOO, as-is. That contradiction is why I didn't get what "spherecast" meant. "Cast" in "spherecast" means something different to what "cast" in "Raycast" means, apparently. Then Unity's claim that it *reliably* runs FixedUpdates on a rigid schedule is a claim they really shouldn't be making. It is entirely at the mercy of all the MonoBehaviors in the whole game to make sure they run very fast short code. If Unity doesn't abort FixedUpdates that are taking too long, then it cannot claim to be certain about them being executed on a reliable timescale.

The code is just too full of spaghetti mess at the moment with lots of my false starts and patchy rework trying to figure out what's going on, so I just checked it in to github as it is and I'll branch it and try again starting over with smaller simpler code that doesn't do much but the minimum that recreates the problem. Either the problem won't recreate, or it will with a small enough amount of code that I can actually show the whole thing to people. I'll take out everything about the numeric pqs solver, and everything about trying to average multiple hits over several FixedUpdates, and just show the basic situation - a FixedUpdate that should find the hit, and doesn't. There's a lot of extraneous side issues in the thread cluttering up the actual problem.

A method I've used is to detect when I'm halfway between apoapsis and periapsis altitude. At the start of the circularization burn periapsis is far a way and I'm near apoapsis, meaning my altitude is closer to AP alt than to PE alt. When I reach the point where AP has spun to the other side and PE has spun to my side, that will mean my altitude is closer to PE than AE. So burn until (altitude - periapsis) < (apoapsis - altitude). The moment where that first happens will be the spot where PE and AP have spun round so I'm half way between them.

Wow if that's what it does then it's named very weirdly. Because what you're describing would be better called a cylinder cast - a raycast with a diameter to it. At any rate, I'll try adding a second linerenderer during FixedUpdate, and then when the raycast misses, I'll leave the linerenderer behind and start a new one next FixedUpdate rather than moving the old one - that should leave behind lines hanging in space on all occasions where there was a missed cast. The misses are so fast and short that just updating the same linerenderer would not actually be visible since I have a slow framerate (it might move it back to the right spot before rendering a frame). It's not just "a" rotation. It's *the* very rotation of the part itself, gotten from the same transform as the transform that got the point. Is there a way to tell the Unity editor to put a marker at a location inside my model and give it a name I can reference later, rather than the location of the model as a whole? I don't know the Unity editor well enough to know if there's a way to name a specific spot within the editor and reference it later in the C# code rather than the transform of the model as a whole. The problem is that naming a subset of the model with its own separate name is not a thing I've done before. I don't know where it is in Unity. It's not what you said the first time. You gave no qualifiers and just said it *IS* faster. BOTH assumptions are inconsistent. The assumption that Update() is slower is no less wrong than the assumption that it's faster. A proper solution would have to use neither of those two assumptions, which is what I'm trying to do. I'm using Update() over FixedUpdate() only because of the consequences of what would happen if I take longer than I should. If I take longer than I should in Update() the result is stuttering animation but still correct numbers. If I take longer than I should in FixedUpdate() the result is more catastrophic than that. As I understand it, Unity enforces the FixedUpdate rate by aborting code partway through if it's taking too long. That doesn't just make things stutter, it makes them incorrect.

As an aside I realized I put this thread in the wrong area on the forums. It should have been in "plugin development and support". I don't know how to move it.

But it would differ from the actual problem in a massively important way - I'd be the one creating the sphere that I'm aiming the ray at, and the problem is dependent on the timing of my raycast's positioning versus the parts' positioning. If I'm the one in control of setting both the ray and the sphere it's hitting then I'm not really exposing where the problem is happening because I'll be deciding when the sphere moves. The frustrating thing I'm having with most of the google-able advice is that it's written for people writing their own unity game from scratch and telling them how to interleave the movement of their objects with the raycasting to try hitting them. As I'm not in charge of when SQUAD choses to move the parts around and what the timings on that is (nor can I even discover what it is because it's not public source code), such advice doesn't work in my case. Or do I not understand what you're asking to do? I agree with the principle to do it as simply as possible to remove the unknown variables, but that does not look simpler than what I did. Not to my eyes. FindModelTransform is adding an unknown I'm not in control of. Getting the transform of the part directly from Unity like I did is less of an unknown. I should be clear that the linerenderer isn't just there for debugging purposes. It's intended to be visible to the end-user as the laserbeam. And I was told you do your animations in Update() because it's what runs every animation frame. As the linerenderer changes a bit each frame (making a pulsating effect where the line changes thickness and opacity each frame), it should be getting updated at animation frame rate, not physics frame rate. I could add a second linerenderer for debugging that's NOT the one the user will see in the end, and update it during fixedupdate(). The assumption that framerate is always faster than physics updates is false. On computers with high speed and good graphics cards it is. On less powerful machines it is not. The default physics rate is always 25 FixedUpdate()'s per second regardless of computer speed, while Update() rate depends on the quality of your machine and your video card and can be either faster or slower than 25 FPS depending on the computer. My computer is not a super awesome gaming machine. It's a macbook pro laptop that's been repurposed to run Windows instead of MacOS. I get about 20 FPS when part count is low. Worse when it's high. In my case, putting work in Update() makes it impact the system *less* than putting it in FixedUpdate. If you see back in the thread, I've been consistently describing a situation in which more than one FixedUpdate() happens between Update()'s. In a way I'm sort of glad my machine is not great. Otherwise I might not have experienced the problem and might have released a mod that's broken on slow machines and not realized it.

Also, one thing I'm suspicious of is that despite the fact that everyone in the Unity user community says to perform the raycasts in FixedUpdate(), Unity's OWN online documentation examples always show it being done in Update(). Granted Unity's documentation is horrible so it could be wrong, but it does make me suspicious. See this: http://docs.unity3d.com/ScriptReference/Physics.Raycast.html

yes. I was using Physics.RayCast() first and then changed to using Physics.RaycastAll() later to see if it would help. Both had the same problem. This isn't workable in this case because I don't hardcode which part I'm trying to aim at. Its "return the hit on whichever part you hit that's nearest". That's what this is: origin = this.part.transform.TransformPoint( relLaserOrigin ); pointing = this.part.transform.rotation * Vector3d.down; It's done during Update(), using a recalculation of origin and pointing (since the location of things can be different during Update()), but capping the distance of the line at whatever the distance result of the raycasts in FixedUpdate were. So FixedUpdate is picking the distance of the hit, then Update() is drawing using that distance. I don't think that will make much difference but I could move the drawing code to fixedupdate too. The problem isn't the drawing, but the calculation of the distance is missing the hit entirely.

Sadly, the problem is that you're half right but not 100% right. I get much better results by taking the best hit of all the FixedUpdate raycasts that happen between Update()s, but sadly not 100% perfect results. It still occasionally takes more FixedUpdate()'s to find the hit than are happening between Update()s. And it's not a fixed number of fixedUpdates. Sometimes 2 FixedUpdates is enough to guarantee finding a hit among them. Sometimes it occasionally takes 3 or 4 to get to one where there's a hit. When I say it fails about 1/3 of the time I don't mean that it's perfectly interleaved, as in success, success, failure, success, success, failure, success, success, failure. Sometimes it's more like this: success, success, success, success, success, failure, success, failure, success, success, success, failure, failure, failure, success, success, success, success. I..e an *average* of 2/3 success, but not nicely interleaved as 2 success, 1 fail, 2 success, 1 fail. During the bits where there's multiple failures in a row, I end up still returning a failure overall to the Update() because none of the FixedUpates() that occurred in that chunk found the hit.

Have you tried using the algorithm to just fire a bullet through just one thin part rather than through a ship made of multiple parts? It might be that as long as you hit one of the parts of the ship it's a success, whereas I need to hit the *correct* part of the ship to be a success. If I hit the fuel tank in the middle even though there was a panel part in front of it that I should have hit first, then that's a "fail" by my criteria. For firing a bullet to hit a ship, hitting the tank instead of the panel would still look like a good success for your needs. I don't know. It could also be a very ugly timing issue. It might be that it depends on how many Update()'s happen versus how many FixedUpate()'s happen, and computer speed changes whether or not a full suite of Update()s happen and finish on time before a FixedUpdate(). I read that thread before on my previous googling. Sadly, some of the advice is about what order I should be updating the position of "my" objects in, as if I was writing my own Unity game from scratch and had the privilege to do that. This isn't useful in the context of a KSP mod because I'm not in charge of deciding when to update and draw the ship parts, SQUAD is in their proprietary code that I don't know how it was written. And the rest of the advice is quite different because it talks about drawing a raycast from the camera, which I'm not doing. Sadly I'm suspecting that what's actually happening here is that SQUAD's own code is updating parts in such a way that it's not working right when trying to hit thin parts. It might explain also why it is that the main game itself has such a hard time with right-clicking on parts working to bring up the menu. That user interface is ALSO dependant on raycasting and it also seems to fail about half the time when I try to click on parts. I have to keep re-trying until I get lucky enough to get it to work.

I will if I include the fallback pqs technique in fixedupdate. If all I do is the raytracing it's fast enough in fixedupdate. If I run a recursive iterator that has to take about 500 loop iterations to get down to an answer within 2m of accurate because the only way to detect terrain hits at long distances is to test sample points along the ray, then it won't. I already know it's not even fast enough for plain ole Update(). I had to split the algorithm up across multiple updates, remembering state between them to get acceptable FPS. Note, that's even BEFORE I moved any of it to fixedupdate. The problem of finding the solution of the intercept of a ray with the pqs terrain is NOT a trivial calculation. It requires itrerative approximation. That's why I have to have half the logic (the stuff using Physics.RayCast) in fixedUPate and the other half (the fallback to pqsCOllider) in Update(). But that's not even related to my problem. Even when dealing with JUST nearby objects using JUST Physics.RayCast in JUST FixedUpdate, Unity is returning inconsistent results where in one FixedUpdate it will hit the part and in the next one it will pass through it to the part behind it *even when nothing moved*. I suspect that what's happening is that because I get FixedUpates more frequently than Updates, that not all the movement and recalculation of all the KSP parts is finished between fixedUpdates. There is no guarantee that Unity gets its way through ALL the parts' Update()s before the next FixedUpdate. So some have moved and others haven't yet. That's my guess. As to changing parts - again it's reliably inconsistent - any part has the effect that it tends to pass right through about 1/3 of the time in FixedUpdate. I've tried falling back on an ugly amount of work to compensate for it - I only need the information up to date once per Update, not once per FixedUpdate - so I'm trying to gather ALL the hits of ALL the fixed Updates that happened between Update()s, and then when the Update() runs, taking the nearest hit among ALL of them. that way as long as it hits the object on at least ONE of the FixedUpdates I don't care that it missed on others. It has to miss on all of them to be a real miss.

And the other messy thing is that to use action groups you have to let the keypress be handled by KSP and NOT by the terminal window so KSP will trigger the action group when you press '1' or '2' etc. That means that this technique, rather bizzarely, requires that you have the terminal window unclicked (partly transparent) at the time you press the key, which is really non-inituitive.

I would prefer for it to be something very common and universally used. I don't want to have to say "you must get THIS particular terminal emulator from THIS particular vendor..." to people trying to use putty or a bash command line to get to it. If it supported something like VT220 codes or ANSI codes then most terminal emulator systems would handle it out-of-the-box. I'd love for this to work some day: User is playing the game on Whatever OS - Let's say Windows. User clicks an option on one of the kOS SCS parts and enables "allow ssh on this part", and types a password for it. User on some other computer, say Linux or MacOS or even a crude terminal attached to a Raspberry Pi opens a native terminal window and gets the default bash prompt. User at the bash prompt enters command "ssh kosterm1@myOtherComputer.org", goes through password stuff, and now their native terminal window *BECOMES* the kOS terminal window.

Okay this is really getting quite infuriating. (Dealing with the API, not you guys. You've been very helpful but the game just isn't cooperating.) See the screenshots below. The laserbeam keeps toggling between giving a hit of 1.78 meters intersecting the structuralBeam3, versus giving a hit of 3.32 meters intersecting the landingLeg1-2 that's beyond it. Every few updates it flips between these two answers. The craft is sitting still on the ground. Not Moving. When the laser does miss the 1.78 hit and pass through to the 3.32 hit, I can see clearly the beam passing right through the middle of the closer object, incorrectly failing to detect the hit. This is the relevant code: /// <summary> /// Perform Unity's Physics.RayCast() check when the movement of all the objects is set in stone and they are not moving: /// Physics.RayCast() is unreliable when called from Update() because objects are moving their positions during their /// Update()'s and you don't know when during the order of all that your own Update() will be getting called. Therefore /// Physics.Raycast() has to be called during FixedUpdate. /// </summary> public void FixedUpdate() { // The location of origin is different in FixedUpdate than it is // in Update, so it has to be reset in both: origin = this.part.transform.TransformPoint( relLaserOrigin ); pointing = this.part.transform.rotation * Vector3d.down; mostRecentUnityRaycastSuccess = false; if( hasPower && Activated && origin != null && pointing != null) { RaycastHit[] hits = null; hits = Physics.RaycastAll( origin, pointing, MaxDistance, mask ); Debug.Log("num hits = " + hits.Length ); if( hits.Length > 0 ) { mostRecentUnityRaycastSuccess = true; float bestDist = Mathf.Infinity; foreach( RaycastHit hit in hits ) { Debug.Log("hit.distance = " + hit.distance + ", bestDist = " + bestDist); if( hit.distance < bestDist ) { Debug.Log("using new hit."); bestDist = hit.distance; mostRecentUnityRaycastResult = hit; } } } } } See the Debug.Log statements? This is what they're showing in the log: (I've removed all the verbose "(Filename: ....)" lines to make the log clearer to read.) num hits = 3 hit.distance = 6.966611, bestDist = Infinity using new hit. hit.distance = 3.787935, bestDist = 6.966611 using new hit. hit.distance = 3.323033, bestDist = 3.787935 using new hit. num hits = 4 hit.distance = 6.966611, bestDist = Infinity using new hit. hit.distance = 3.787934, bestDist = 6.966611 using new hit. hit.distance = 1.778339, bestDist = 3.787934 using new hit. hit.distance = 3.323035, bestDist = 1.778339 num hits = 4 hit.distance = 6.966611, bestDist = Infinity using new hit. hit.distance = 3.787933, bestDist = 6.966611 using new hit. hit.distance = 1.778339, bestDist = 3.787933 using new hit. hit.distance = 3.323039, bestDist = 1.778339 num hits = 3 hit.distance = 6.966611, bestDist = Infinity using new hit. hit.distance = 3.787933, bestDist = 6.966611 using new hit. hit.distance = 3.323033, bestDist = 3.787935 using new hit. It seems entirely outside my ability to control it - it just sometimes fails to include the structureBeam3 among the hits (returning a list of only 3 hits, not the correct 4 hits), even though I'm not doing anything different in that particular update. And it seems to randomly flip between finding it and not finding it based on who knows what. I'm tempted to punt and just tell people "sometimes it will fail to hit parts and there's nothing I can do about it."

Okay this is really getting quite infuriating. (Dealing with the API, not you guys. You've been very helpful but the game just isn't cooperating.) See the screenshots below. The laserbeam keeps toggling between giving a hit of 1.78 meters intersecting the structuralBeam3, versus giving a hit of 3.32 meters intersecting the landingLeg1-2 that's beyond it. Every few updates it flips between these two answers. The craft is sitting still on the ground. Not Moving. When the laser does miss the 1.78 hit and pass through to the 3.32 hit, I can see clearly the beam passing right through the middle of the closer object, incorrectly failing to detect the hit. This is the relevant code: /// <summary> /// Perform Unity's Physics.RayCast() check when the movement of all the objects is set in stone and they are not moving: /// Physics.RayCast() is unreliable when called from Update() because objects are moving their positions during their /// Update()'s and you don't know when during the order of all that your own Update() will be getting called. Therefore /// Physics.Raycast() has to be called during FixedUpdate. /// </summary> public void FixedUpdate() { // The location of origin is different in FixedUpdate than it is // in Update, so it has to be reset in both: origin = this.part.transform.TransformPoint( relLaserOrigin ); pointing = this.part.transform.rotation * Vector3d.down; mostRecentUnityRaycastSuccess = false; if( hasPower && Activated && origin != null && pointing != null) { RaycastHit[] hits = null; hits = Physics.RaycastAll( origin, pointing, MaxDistance, mask ); Debug.Log("num hits = " + hits.Length ); if( hits.Length > 0 ) { mostRecentUnityRaycastSuccess = true; float bestDist = Mathf.Infinity; foreach( RaycastHit hit in hits ) { Debug.Log("hit.distance = " + hit.distance + ", bestDist = " + bestDist); if( hit.distance < bestDist ) { Debug.Log("using new hit."); bestDist = hit.distance; mostRecentUnityRaycastResult = hit; } } } } } See the Debug.Log statements? This is what they're showing in the log: (I've removed all the verbose "(Filename: ....)" lines to make the log clearer to read.) num hits = 3 hit.distance = 6.966611, bestDist = Infinity using new hit. hit.distance = 3.787935, bestDist = 6.966611 using new hit. hit.distance = 3.323033, bestDist = 3.787935 using new hit. num hits = 4 hit.distance = 6.966611, bestDist = Infinity using new hit. hit.distance = 3.787934, bestDist = 6.966611 using new hit. hit.distance = 1.778339, bestDist = 3.787934 using new hit. hit.distance = 3.323035, bestDist = 1.778339 num hits = 4 hit.distance = 6.966611, bestDist = Infinity using new hit. hit.distance = 3.787933, bestDist = 6.966611 using new hit. hit.distance = 1.778339, bestDist = 3.787933 using new hit. hit.distance = 3.323039, bestDist = 1.778339 num hits = 3 hit.distance = 6.966611, bestDist = Infinity using new hit. hit.distance = 3.787933, bestDist = 6.966611 using new hit. It seems entirely outside my ability to control it - it just sometimes fails to include the structureBeam3 among the hits, even though I'm not doing anything different. And it seems to randomly flip between finding it and not finding it based on who knows what. I'm tempted to punt and just tell people "sometimes it will fail to hit parts and there's nothing I can do about it."

Does the drawing of the ray, if I'm showing it visually with a red lineRenderer, have to also be in FixedUpdate? I think the problem may be that. When I raycast in FixedUpdate and then draw the result, the drawing is really far off, appearing about 20 meters ahead of the craft as it orbits, making it very hard to debug what I'm looking at. But then again I'm tying to raycast in FixedUpdate and then Draw in Update. I think I can do it but the logic is messy because of the fallback to a slow numeric algorithm when the terrain is too far away for raycasts to work (the game unloads the polygon colliders when the terrain is more than about 10-20 km away or so). What I'm trying to do is basically this: MyRayCastWrapper( stuff ); DrawRay(); Where MyRayCastWrapper( stuff ) is doing the following: Step 1 - Try Physics.Raycast to hit ground or ship objects near enough to have loaded colliders. Step 2 - If Step 1 returned false, then fall back to my own homebrewed numeric algorithm to find terrain hits with the distant planet surface by querying the pqsController. The ugly part is that although Step 1 and the ray drawing may both be fast enough to put in FixedUpdate, there's that annoying Step 2 which really shouldn't be in FixedUpdate because it's computationally expensive, and yet it happens *between* Step 1 and the drawing of the ray. I could wait and draw the ray later but then it's being drawn in the wrong animation frame and thus in the wrong spot. I think it's doable but messy. I may have to disable the numeric solver, get the solution working for just raycast only, and then work out how to re-enable the numeric solver in the new way the code looks after that. That really looks like it's in the wrong order around. Are you sure I'm supposed to be checking how many alllHits there were and THEN for each one of them be calling Raycast on them? Doesn't the raycast come first and allhits isn't even populated until it's been called?

But how on earth do you know in software which of these situations you're in? I can tell visually by looking of course, but how does the code know whether or not it's the right situations to add the velocity offset or not? is there a cutoff speed where the effect becomes needed? I tried moving the logic into FixedUpdate and it was drawing the ray in the wrong spot, well offset from the position of the ship. When I have it in Update() it draws in the right spot, but passes through things. When I put it in FixedUpdate, it's not even drawn in the right spot.

This is an excellent idea, but I'd warn you of a couple of things. 1 - There is more than one screen. There is one PER SCS part. If you have 2 parts on the craft, there will be 2 screens because each SCS part has its own "shared" block of stuff. 2 - Be careful about the screen buffer method, because one far-flung future thing I want to do is stop it with this annoying direct-to-screenbuffer style of terminal interaction the mod has. People have wanted to make the terminal remotable with things like ssh and in my opinion the very first step of that has to be to first divorce the terminal entirely from the rest of kOS such that kOS is forced to talk to the terminal via a stream interface - translating key events into streams of chars, and doing all screen manipulations with a common well known set of character control codes like ANSII or VT100 (so that you can attach a terminal emulator program like Putty or a UNIX Bash shell in a terminal window to it). As this is a thing I'd like to do, relying on the screenbuffer technique may not be a good idea. (In fact for what you're doing, maybe getting the terminal divorced from kOS like that might be the first thing you have to do.)

Oh please yes. I took up the task of writing much of the docs but that styling was there before I started. I dislike it especially as when I link direct to the middle of a page with an HTML anchor tag, the annoying banner covers up the header line of the section I'm linking to.

Yeah the only way to run "simulations" in your hard mode game is to copy the game folder to a new name and play in there. I don't consider that "cheating" because it's like running the autopilot inside a simulator which a real space program would have a chance to do. It only becomes "cheating" if you then copy the effect of the test back into the main game, because then you're esentially just allowing yourself a "revert to VAB" option through the back door (and I assume that you're playing hard mode to avoid "revert to VAB"). I've always been annoyed that the main game doesn't have a "simulator" mode. It would be a lot LIKE having a revert to VAB but instead of choosing *after* you see the results whether or not you'd like to keep them, you decide *before* you lift off whether or not you'll be keeping the results. "Revert" lets you try and then decide to keep the result if it worked, or undo it if it failed. "Simulate" would require that you pick FIRST and commit to whether or not this flight will "really count" or not before you see how it goes. At some point after trying it a few times in simulate mode, you'd have to commit to the "real thing" and then that flight wouldn't be revertable. Actually, that sounds like an easy mod to make - it would just copy the savegame folder to a new save, let you jump into it, run a while, and then return back, with the caveat that it will not retain the new savegame folder and it will remove it the next time you go back to the KSC.

That actually sounds trivial for me to do. I already have the vector representing the ray of the laser, the coordinates of the start of the beam and the length of the beam to the hit point, so getting height diff is just a mater of taking the altitude above sea level of the start coord and the altitude above sea level of the end coord and taking the difference. (and once I have that, and I know the diagonal length already, then I've got 2 legs of a right triangle and I can get the horizontal difference from the simple Pythagorean formula.) This all seems do-able without much effort, but be aware that I will likely not have the available time to work on the mod until Thursday. If you like. you can show me a mock-up of what you'd like the display to look like for that little window. I may or may not follow it, but it will give me a basis to work from.

The current state of the raycasting to hit parts of the ship itself are not working well, due to some weird undocumented behavior of Unity's raycast function. (it keeps passing through the parts intermittently due to some picky rules about the timing of updates that I haven't fully nailed down yet). it works well for terrain, and it works on vessels that never move - but it's not working well for parts of vessels when the vessel is in motion.

It's not a bad idea. As my original goal was just kOS integration getting it on the RMB menu was enough, but you're right, making it appear on the screen in a small window box is a good idea. How about this interface: RMB panel shows up, has a button on it labeled "toggle display". you click it on and a small window appears just big enough to hold the display number and that's it. You can drag and move it about to where you like on screen, and when you click "toggle display" again it goes away.

Sigh. Moving it to FixedUpdate didn't break anything but it didn't make it work either. It behaves exactly the same now.