Dunbaratu

These new Triangular panels made me pretty excited at first, until I tried using them in the SPH and found the mirror symmetry feels all wonky and wrong for them, making it hard to design certain things with them. Look at these screen shots - the mirrored symmetry isn't making actual mirrored parts. It's behaving just like radial symmetry: The first two images are with Mirrored symmetry. The last image is with radial symmetry to compare. I don't see any difference.

I got it within 80 meters of the target, but I've done lots of manual flying of planes in the game before. The trick is to make your rocket a vertically launched glider plane, that uses the solid booster as its fuselage, and uses that size adapter (there's a reason you were given one) between stayputnik and solid booster, to reduce drag and increase glide distance (the fuel you have to remove because of the extra mass this causes is worth it - the extra glide distance is worth more than that bit of fuel.) You also have to be well versed in how to fly by using Pitch Trim instead of raw pitch, as raw pitch will violently wiggle the elevator too much and cause too much drag. This was a pretty advanced mission to give you as your first starting mission. (I also get frustrated with the missions' tendency to coyly hide the *real* mission objectives until after you're partway through flying the mission, guaranteeing your first craft design can't meet the criteria since you built it according to the lies you were told beforehand, rather than according to the real objectives.)

Why??? Why on earth make you wait (or time warp) 5 minutes to get the end score?? When nothing *tells* you to wait 5 minutes, of course the player is going to think something broke or the mission failed. The thing that seems universally wrong with *all* the Making History missions is that the text the player is shown is a complete pack of lies. It's as if the text was written first, then the mission was designed and didn't match the text, and the text never got re-written at the end to match the mission. That's a fatal problem that is causing many players to call the DLC missions broken and buggy. And I can't blame them - how are they supposed to know the mission is correct but the person who wrote the descriptions was lying to them?

The Acapello 15 mission is neither completed nor failed if you splashdown on Kerbin instead of land on ground. If you finish the mission in water, the "splashed down" node does not lead to a "mission complete" or mission fail node. Instead it leads (for some reason) to a 5 minute timer node. At this point the player has no idea what's going on. There's no message, and if you recover vessel, the KSC is all disabled and nothing works. Either splashing down should be a fail or a success but it shouldn't leave the mission stuck in limbo.

It's meant to mimic the first Soviet lunar probes. They had a similar problem of a launch pad at a latitude that forces a high inclination. Their solution was to not bother matching inclination but instead wait till the right time of day when the launchpad is at the right phase angle and then just launch into polar orbit. By waiting to the right time of day to launch, the polar orbit will be lined up right to make the transfer burn and you'll approach the moon from its North Pole.

The game fails to tell the player why the mission failed. This needs fixing immediately as it feels random and broken to any player unwilling to spend time debugging the situation. It makes the DLC look really bad and gives a poor impression. From trial and error I suspect there's a minimum score to succeed that the game never mentioned and not hitting it fails the mission. So when you crash into the moon the mission is over and it checks the score and if it's too low it gives the fail message with no explanation. I think you need at least a bronze, however many points that is (which it also doesn't tell you). There are also secret objectives it fails to mention and failing them can lower your score. Check the report and see the score calculation to look for anything that gave you multiplier less than 1.0. those are hurting your score and possibly preventing the mission from working. Also keep checking the map view for waypoints it never told you about and check the detail info dialog panel for objectives it didn't tell you about. I had a mission fail because it needed to land near a latitude/longitude that it never talked about and never made a waypoint for. I just saw the numbers in the info panel. I then had to look up where that was to find it was near the KSC.

While I found the stock missions in the Making History DLC fun at first, I am getting more and more frustrated with the poor way in which the objectives are communicated to the player, so you end up having to do several play-throughs just to learn what they really wanted you to do. I'm always having to read through the info panels on the right with a sharp eye to catch the places where the descriptions don't match the real objectives. Rather than go over all of them, here's one simple case where I got really confused for a while: The game doesn't explain why you failed a mission. It took me a long time to realize (and this is still just a guess on my part since the game doesn't say for sure) that failure isn't a matter of one specific bullet point you miss, but rather of not getting a high enough score. If you failed the mission because the general final score wasn't high enough, then failure dialog box needs to tell you this (and how far you fell short of the needed score) instead of making you hunt around guessing which specific bullet point you missed. It's only through trial and error that I'm starting to guess that there's probably this rule about a minimum score, since it never said anything about it. An example of a better way to communicate it to the player would be if the failure dialog box said this: In another instance, I kept failing the Agena launch for the rendezvous mission, because I "missed the launch window". At no point did the mission tell me that what this *really* means is that I need to complete everything within 20 minutes of game clock time. I had to pull the mission into the editor to figure this out because, again, the player isn't being told the real reason for the failure. You can't meet objectives that you don't even know what they are. I feel sad about this DLC because I know it needs to financially succeed for Kerbal to continue and for SQUAD to keep working on it, but things like this are a real hurdle to that happening, I think. Players shouldn't have to struggle to wrench information from the game about what the objectives even are.

I'm also discovering a tendency for the descriptions in the popup windows to be treacherously incorrect (such that following them as described makes you fail). For example, on the first probe to minmus mission you're told you have to decouple a probe that has mystery goo while in orbit below 100km, before going to minmus. The un-mentioned other objective is that your orbit has to have Pe > 95km. They don't tell you that in the popup and so if you don't open the little info panel on the side and see it you'll have no idea why nothing is continuing. But that's not the bigger problem - the bigger problem is that the popup claims you finish the objective by hitting the stage button and decoupling the probe. No, you don't. According to the *actual* objectives, you do it by performing the mystery goo experiment. Decoupling the probe won't make any difference and in fact is totally unnecessary. Realizing the *real* objectives let you keep that probe attached is how I was able to eventually finish the mission, because the probe has 200 units of battery on it, and the primary challenge of this mission is not running out of electricity. Realizing you never had to actually decouple the probe makes the rest of the mission actually doable by adding 200 desperately needed electric charge to your craft.

(This is about playing the missions the DLC comes with) First mission: "Launch your first rocket, get it to 5000 meters, splash it down near the abandoned runway". "Surprise, we actually meant on the runway, oh you didn't design your rocket for a land landing? Well too bad redesign and try again." Second mission: "Get to 48,000 meters, take a temperature reading and return home safely". "Surprise, we actually meant splash down in the water next to this waypoint we never told you about beforehand. Oh, what's that? You didn't design the rocket for steering because you thought we were telling the truth about the objectives? Well, too bad redesign and try again." Is there a way to learn those surprise objectives beforehand so you don't have to waste a launch just to learn the real objectives? Are they displayed somewhere?

It does not work for 1.4. Squad announced that 1.4.1 is coming when the DLC happens (scheduled for Tuesday this week, if they get it out when expected), and we're waiting for that. If 1.4.1 doesn't come out on time, then I may release the 1.4 version we have.

The reason is that there's an annoyingly long checklist we go through when we make a release and double- and triple- check things. There's also a suite of regression tests I run that can't entirely be automated because it involves actually playing the game. Doing so and then doing it again right away a few days later is a little frustrating.

We expect to delay any update to kOS until after KSP 1.4.1 comes, given that KSP 1.4.1 is expected next week and is likely to break things again. If we published an update today, it would be a version that only works for about 4 days before it breaks again and we have to make another update. We'd rather just wait and do it once.

And because of the tree structure of the vessel, missing that part data means not knowing how to draw the REST of that branch of the vessel because you are missing the part model that tells you the dimensions of the missing piece. Even if you want to join up the child of the missing part to its grandparent, skipping the missing part between, you'd still need to know if the child part of the missing part is supposed to begin 3 meters away from the grandparent part? or maybe 5 meters? 1 meter? The game has no clue because those dimensions were in the missing part. If it tries to construct the vessel on a guess about that, it ends up drawing the rest of that branch in the wrong spot and creating clipping and collisions where they shouldn't be, changes to center of mass, misaligned engines, etc. Asking the game engine to reconstruct a vessel while missing the dimensions and node attachment information about a missing part definition is just impossible. What might work, though, is a better signalling of the warning about the vessel before it deletes it. (i.e. "We have found 2 vessels we will have to delete if we continue loading this save. Here's a list of their vessel names and current locations and offending part(s): (i.e. My Probe 1, in orbit of Duna, 'FASA XL200 tank'' : Kerpollo 1, landed at Mun" 'CSX4192 kOS core') Are you sure you want to continue loading this save given that these vessels will go away?") The generic warning that some vessels might go away depending on mods isn't as clear as actually naming them after you discover it will definitely happen, and then giving an option to back out at that point.

I agree with not having them do this, just because it would mean "some mods are more equal" than other mods. "We'll do a bit more work to help the popular mods, but not the unpopular ones" doesn't seem like a reasonable dividing line because then they have to decide what counts as "popular *enough*" to do this.

For the optional DLC coming soon, will we modders need to release two simultaneous releases of mods, one for users with the DLC, and one for users without the DLC? (i.e. if non-DLC is version 1.4, and with-DLC is version 1.4.1.) I currently maintain a backward port of kOS to KSP 1.2.2 just because of Realism Overhaul always being a revision or two behind, but it's kind of a pain to keep a back-port active and I'd like to not have to start maintaining more of them because with-DLC and without-DLC users are on two different versions of KSP.

Sorry about that. I've been sick the last 3 weeks and haven't worked on kOS at all. I'm feeling better now and I opened up discussion with the other kOS devs about wanting to put out a release before the next KSP drops this month, specifically because of the Trajectories PR. I can't promise anything about whether we'll be able to do it on time or not. The timing is bad because one of the other devs is about to go on a vacation trip.

This is utterly false. Yes If you attach then assign the tag it doesn't clone the tag because that policy still lets you give unique names to the copies. But you can make clones of the tag by detaching the part after it's been given a tag and then reattaching it symmetrically. The tag is copied to the clones at the moment of attachment. The clones all have whatever the tag was at the moment the part got attached.

I don't know if this is the right place to ask this, but whenever I try to use the FASA lunar ascent module (installed indirectly, via Realism Overhaul's CKAN settings) I encounter this recurring problem: 1 - An EVA kerbal takes experiments on the surface (i.e. EVA report, Surface Sample). 2 - That Kerbal re-enters the Ascent module with the experiments. 3 - I fly the Ascent Module back up to orbit, and dock it with the Command Module. 4 - I have no idea now how to get my EVA report and Surface Sample out of the Ascent Module other than to transmit them via antenna (and take the hit on the Surface Sample because I didn't bring it home physically). The usual stock way of being able to right click the module with an EVA Kerbal and pick "take data" is missing from the context menu for the Ascent Module. I've tried and tried and it's just not there and I can't find any equivalent menu option. So I can't get the experiment home to get full credit for it. It's definitely in there, because I can see it when I use the "review" option to look at the experiments in the Ascent Module. But I don't know how to get it out. Have other people noticed this problem? Is it something that just happens on my install only or is this working as designed and I'm missing something. (Also usually the "open hatch" option doesn't work after I re-dock with the CM. I can't get the hatch open and have to transfer crew with EVA back to the CM. The menu option is there, but clicking it does nothing.)

Hmm. Whatever is wrong it must require your exact program to trigger it. When I perform this much simpler test, it works fine: set my_gui to GUI(100). my_gui:addtextfield(""). my_gui:show(). wait 20. // time to play with it a bit before it goes away. my_gui:dispose(). Does that simpler example work when you try it? If it does, then the problem probably requires that I run your *exact* script. I see that you are making custom style changes. It is possible there is something in the style code that is not set up right so when it tries to draw the GUI it hits this error. Can you perform a test where all the custom style changes you made aren't there and it just displays the stock appearance, but other than that it's the exact same GUI widgets? It might help narrow down the cause of it.

When you get NullReferenceException, that's not your fault. We're supposed to be preventing those in the C# code. That's on us. Do you have the output log from KSP itself? It should also mention this error when you get it, and it usually has more information about where in our code it happened.

(1) - The function call : VANG(ship:up:vector, ship:srfprograde:vector) will give you the angle between straight up and your surface-prograde vector. (I assume you want surface and not orbital here). So, for example, a pitch of 80 would mean there is 10 degrees angle between up and prograde. If you do 90 - VANG(ship:up:vector, ship:srfprograde:vector) then you should get the pitch number you are looking for. (2) - There is no such thing in kOS. Instead you can explicitly mention which you are interested in because prograde comes in two varieties - surface and orbital. You can say srfprograde for surface, or just prograde for orbital. You can say ship:velocity:surface or ship:velocity:orbit to get velocity vectors in the two frames. For target-relative there isn't a shortcut, but you can always subtract your target's velocity vector from your velocity vector to get the same thing the navball would have shown you in target mode. (3) - Not really. But if you want this kind of information, look at lib/navball in the community library. It's possible to get this information with a few lines of kOS script code and this example shows how. The documentation describing the functions is here: https://github.com/KSP-KOS/KSLib/blob/master/doc/lib_navball.md The actual functions themselves are here: https://github.com/KSP-KOS/KSLib/blob/master/library/lib_navball.ks

The only connections kOS uses with TCP are using Telnet. You can read a lot of old documents about the Telnet protocol in the old RFC format (just ascii text files) online. When I first made the telnet system in kOS, I tried to write down my thoughts about what it would take for someone to write a client that will talk to the telnet server in the game, here: http://ksp-kos.github.io/KOS_DOC/general/telnet.html#homemade-telnet-clients

It's not that simple. Under the hood, kOS is doing some fancy footwork to make TERRAINHEIGHT work because of the fact that the game doesn't load the actual physical (collider) polygons for the terrain until you are very close to it. Most of the terrain you are looking at on the screen is a "hologram" so to speak - it has visual appearance but no physics interactions. As you move across the terrain, the game populates the terrain colliders in front of you as you move, and despawns them as you leave them behind you. Anything more than about 6 or 7 km away from you isn't "really there". At least it isn't "really there" as far as the Unity's raycast call is concerned, and that's what matters here. When you query for TERRAINHEIGHT of nearby terrain that is fully loaded, kOS just asks Unity for a raycast that will get the precise length of that ray from body center up to that one terrain polygon it hit. It could query from Unity (but it doesn't) the normal of that polygon to get its slope. This is a pinpoint accurate answer but it only works with nearby terrain that has its colliders loaded. When the terrain is far away, kOS is using samples from the terrain generation formula KSP uses (and how that works is a mystery black box as far as kOS sees). kOS asks KSP, "If I was about to populate some terrain polygons in which one vertex of the terrain was at this exact latlng, what coordinate should I use for that vertex?" This idealized answer (which won't be 100% the same as what you will find when you get there and the game fills in its chunky polygon approximation of the ideal) is what it feeds back to your script if the terrain is too far away to "really exist". The terrain generation system doesn't tell us the slope - just the terrain height at the spot we asked for. To get slope we have to ask for the height at several nearby spots and compare them. In other words, kOS would just be doing the same exact thing your script is doing - sampling several nearby points and working out the slope from that. Besides, in a 3D world, slope isn't just a scalar. It's a vector pointing normal to the surface at that spot.

The underlying math libraries in C# have a square root but I'm not sure they have a cube root. I looked and didn't find one. sqrt() is indeed faster than ^(0.5) because there are some known shortcuts that algorithm can take, but I don't think the same effort has been done for cube root. Sqrt() gets its own function because of how common it is. But they can't do that for every power without it getting silly.

I just checked our code and it seems we only change the field by calling BaseField.SetValue(), rather than directly. So the opportunity to trigger the event does exist if the KSP code was written for it- given that we set the value through a method call rather than directly. If you're not seeing it happen then I don't know why, and trying to find out why would involve crossing a legal line into spying on KSP code so I can't go there. All I know from here is that we definitely use SetValue() to do it, and other mods I searched on GitHub also use SetValue() on BaseFields all the time without explicitly having to call the onFieldChanged callback afterward (in fact so does KSPWheelBase itself in one place). We are definitely doing pretty much the same thing the other mods are in regards to setting KSPFields.