Dunbaratu

They also desperately need to SHOW YOU the part they're talking about in the part test contracts. Don't just say "oh, you need to test the ABC123XYZ engine at this altitude and this speed", but show the icon of the part, and its info panel - the same icon and info you see in the VAB editor - so people know what you meant. Many people play the game visually and don't have the part title's memorized. After a while, which engine is which, and which decoupler is which, gets a bit blurred. And it's important information to know. There's a big difference between accepting a contract that says "test this 1 ton engine in orbit" versus one that says "test this 4 ton engine in orbit". And it's a difference you need to be aware of before you commit to it.

As of kOS 0.15, you can now write a script that reads what the player's stick-and-rudder controls are *attempting* to do, and decide how you want your script code to react to that. (In principle this means it should be possible to do something like the Airbus style of controls - where the pilot's controls are mere suggestions for the autopilot to take under advisement, rather than having any guarantee that they'll actually be obeyed.)

Both user keyboard input and an "exit" are not there yet. Part of the reason why is that both, while they'd be simple on their own, are tied up with more complex changes we want to do that affect how they get implemented. Key input is tied to making the terminal better and more dynamic, changeable, and remoteable. The 'exit' is tied to making proper functions (because of the need to decide if we want exit codes from RUN commands, or return objects from functions, or both). Sometimes when I've needed an emergency "exit" in a script, I cheated and deliberately caused a runtime error to force the program to quit. (for example, trying to divide by zero).

Thanks for the quick update. As I usually do I'll be playing plain stock for a few days after an update to get a good feel of what the update did before I start re-adding mods back in again. Yours is one of the first few I'll be putting back on.

Well it looks like 0.90 broke kOS (as expected). erendrake has started looking into it. For my part I plan to play a bit of stock 0.90 KSP for a day or two first to understand the new features from a player's viewpoint before I look at how those changes affect the kOS mod.

Well you can work around it by having two docking ports on the second mission - the one you'll use to dock and an pointless dummy one just to saisfy he contract. The contract requires a clamp-o-tron docking port to merely exist on the ship, and it requires a docking with the Agena, but it doesn't check if THAT is the port you used to dock or not.

Here's another problem, but it's a problem in the configuration of the missions, not the code. When you try the historical missions, the Agena launch mission says you need to launch the Agena with "any" docking port on it. But when you go to the next mission, the Agena Target Vehicle mission, to dock with it, it says it requires not just "any" docking port, but specifically the average-sized one ("Clamp-o-tron docking port"). So if you obeyed the "any" docking port requirement of the Agena by making a Sr or Jr docking port, then the follow-up to dock with it requires the wrong kind of port to dock with it.

Actual Problem Found. Oh god this whole thing was one massive red herring. The actual Problem: The slash ('/') is a valid Base64 character. It represents the bit pattern 111111 (dec 63). It's therefore possible if you have a lot of bits of '1' in a row, to get two contiguous slashes in the base64 string. Two contiguous slashes forms a comment ('//') in the persistence file and thus causes the value to be truncated at that point. It always got truncated when the content had '=' in it and was not truncated when it did, purely because of the sheer coincidence that in my test cases when the content had '=' in it, it also happened to have double-slashes ('//') in it. There's no causal relationship between those two conditions - it was just a random fluke of the data I was testing with.

yeah definitely it's NOT a problem with what the low level persistence file is doing. I was able to make a dumb test to do this: node.AddValue("testaa","aaaaa=="); node.AddValue("testbb","bbbbb__"); node.AddValue("testcc","ccccc,,"); And then later, this: UnityEngine.Debug.Log("reading back in: testaa="+configNode.GetValue("testaa")); UnityEngine.Debug.Log("reading back in: testbb="+configNode.GetValue("testbb")); UnityEngine.Debug.Log("reading back in: testcc="+configNode.GetValue("testcc")); And that proved that the file is perfectly capable of storing values with "__", "==", or ",," at the end of them without stripping them off. So whatever is happening in the code that's causing them to be stripped off, it's happening elsewhere, which is utterly confusing to me. Oh well, I'll have to keep looking.

I'm aware of the '==' at the end of base64 already. I already tried replacing the '==' at the end with '__' or ',,' and it *still* strips them off at some point during the save. Now I'm suspecting that I'll have to dig through the code to find somewhere *else* that the saving is also occurring. That's the problem with picking up mods someone else wrote and continuing with them. Things often occur in places in the code that make no sense and so you don't catch them. If this problem isn't universal then that has to mean the code is trying to manipulate the same data in the save file from *more* than one location in the code, because I verified that it works right in the one place I edited it. There must be some other location where it's repeating the same work, in a very not-object-oriented way.

This is the sequence of events I'm getting: 1: I leave the scene of the ship, and go back to the space center. Knowing this will write persistent.sfs, I pause the game and view the persitence file in a text editor, and confirm that my value is in it, and ends with "__". 2: I quit the editor (not saving anything) and then in the game, exit the game nicely. 3: I look at the persistence file again, now the value is missing the trailing "__". The *FIRST* time it writes it out, it writes it correctly. Then after a complete quit of the game it's gone again.

What bothered me is that your response implied that you were ready to call FlightGlobals.ActiveVessel buggy if it didn't behave as you expected. It does exactly what it's meant to do. If you assumed it worked as a boolean check to see if the crash event is on the active vessel, then then the bug is in your having made that assumption. No shame in that, as the KSP API is horribly documented and most of the documentation of it is coming from the user community's own guesswork. There's no shame in guessing what it does incorrectly, as it's all any of us are doing is guessing. I wish SQUAD would document their API if they claim they like having modders around so much. Mine as well. It's actually abnormal to build a rocket in which the first stage hits the ground before you reach an altitude of 2.5km. But that 2.5km value can be changed by other mods. Being reliant on the short unload distance for it to work right is a fragile assumption.

I'm having a heck of a hard time diagnosing a problem with Base64 encoded content stored inside a ConfigNode of the persistent.sfs file getting mangled. It would help if I could find actual hard facts about the syntax of the persistent.sfs file and what is and isn't allowed in it. For example, when the file has a line like so: name = someValue When what is the regular expression that defines what is legal and illegal for someValue? I'm getting the characters '='. '_', and ',' being stripped off of someValue if they happen to occur at the end of the string, but not if they occur in the middle of the string.

Since when does it do that?. (Besides, what do you mean by "current vessel" if it doesn't just mean "player vessel"? Do you mean "the vessel that's experiencing the OnCrash Event?") What you're describing would have to require that FlightGlobals.activevessel be aware of where it was called from. It would have to know it was called from inside an event hook, and which one, to be able to tell you whether or not the active vessel is the vessel associated with the event. Every time I've ever used it, FlightGlobals meant only "returns the vessel the player is controlling right now" and that's *all* it meant.

I disagree very strongly with applying the label "hardcore" to "having to avoid triggering a bug". The description of the contract does NOT claim that separated stages also have to survive undamaged in addition to the main ship. That is NOT intuitive at all from the contract description. Either the bug is in the code doing the wrong check, or the bug is that the mod describes the contract conditions to the player incorrectly. Either way around, its still a bug.

These two sentences contradict each other. I'm confused.

Are you using ModuleManager to add kOS to all the command cores? The problem might be related to having the computer pilot and the pilot made of meat in the same part.

Sadly I don't think what I'd need to know would be in it because it would only log things it *knows* are problems. And this is a case of it not realizing how wrong it is being. For a full debug I'd have to change the mod's code to do a verbose dump of the *entire* context of each CPU's state of mind and what it's thinking as it steers, and work backward from the steering code to which piece of data is wrong and where it came from. The steering code is really more @erendrake's area so I'm not sure I should jump into it. What might help is providing a savegame file of the exact moment of time just before the undocking happens. Although, that would also mean having to make sure the exact same list of other mods you have is installed on the test platform just to be sure we can load the savegame.

Unfortunately that's inconclusive, as I didn't realize you'd have multiple vessels with the exact same parts list on them. I was assuming each broken apart vessel would be unique enough not to be the same mass. Knowing that they both say 1.2t doesn't help if both really indeed *are* 1.2t in mass. I was hoping for a situation in which it would be *incorrect* for them to give the same mass because they are different. In that situation, them giving the same mass would be proof of the bug. But in this case, them giving the same mass might be correct. Try it with the SHIP:NAME field instead. Rename one of the two vessels, and then see if the two terminals give different names or the same name. If they give the same name despite the fact that the two vessels are named differently, then that would be proof of the bug.

True, but it doesn't look like it's bothering to check whether or not the vessel being destroyed is in fact the one being currently flown, and since spent stages count as vessels, a spent stage falling to the ground is triggering false positives on the crash checker. I had a cursory glance at the code on github and this part looks suspicious to me, in VesselMustSurvive.cs: public void vesselDestroyed(EventReport er) { if (FlightGlobals.ActiveVessel) { VesselAlive = false; Debug.LogError("Vessel Recorded as destroyed in contract vessleAlive = " + VesselAlive); } } Was this: if (FlightGlobals.ActiveVessel) meant to be something more like this instead: if (er.origin!= null && er.origin.vessel == FlightGlobals.ActiveVessel) (i.e. not just responding to *every* vessel crash, but limiting to only respond to the ones in which the part being destroyed is part of the active vessel.) I didn't take the time to examine your entire logic structure of the program - that would be a big project. So I admit I could be easily misinterpreting the intent of if (FlightGLobals.ActiveVessel). But on the surface of it, if the intent was "don't respond to the event unless it's for the current vessel", then that code doesn't do that at all. Just saying if (FlightGlobals.ActiveVessel) by itself is doing nothing more than just ensuring that globally an active vessel exists *somewhere* in the loaded universe. It's not doing a thing to check whether or not the currently crashing part is in any way related to that active vessel. What happened in my game is that my active vessel did NOT crash in the slightest. My spent stage did, as it *should*. I was being a good space citizen and avoiding Kessler Syndrome. My landing was smooth as silk and nice. But it was the crash of the spent stage that falsely triggered the mission failure, and I think this is why - any crash that occurs in the loaded 2.5km universe anywhere, regardless of which vessel it is for (and spent stages count as separate vessels) is triggering the failure. I suspect it would happen as well if you had say a heavy craft with small starting boosters that separated and fell back to Kerbin very early in the flight and fell to ground before you were 2.5km high. The OnCrash events those boosters would undergo because they didn't unload before impact would be falsely interpreted as crashes that occurred to the main vessel.

I can confirm that I had this problem when I was testing the docking use-case with some new Direction features I was implementing. In testing that case I often found that joining and separating craft triggered this. A workaround is to leave the scene and come back to it, forcing KSP to destroy and recreate the kOS parts into memory. In my case, subassemblies were not involved at all. It's the act of separating craft in flight that did it, and it was intermittent. Sometimes it happend and sometimes it didn't. I think it depends on which part of the vessel is considered the "root" part, which keeps changing when you dock and undock. (You've all seen the effect where you dock a vessel to a station and the game decides to rename the station to the name of your vessel you docked to it - when you see that it means the game decided your new vessel was to become the new root part of the joined together ship, rather than the station's previous core part.) I have no clue what criteria the game uses for this, but the point is that I think which part of the vessel contains the root part when you split the vessel apart affects which half of the vessel experiences the bug and which half doesn't. Whenever you split a vessel into two halves, either through staging or undocking, it seems that it breaks off at the splitting point such that the next part further out from the split point becomes the root of a new parts tree for a new vessel, that follows the same branching structure from there. Meanwhile the original vessel is still there, but with one of its branches truncated at the split point. The bug seems to only affect which of the two vessels is the newly invoked one. The vessel that consists of the original old one with a truncated branch still operates correctly. The vessel that was newly built starting with its new root at the branch point is the one that gets the bug. I strongly *suspected*, but haven't gone through the effort to actually prove, that the bug is because the new vessels' kOS CPU still has a variable in memory that tells it "I am part of vessel A", when it is actually part of vessel B now. This would lead to a whole host of confusion in the steering algorithm as it tries to read rotation, position, and velocity of the vessel and is getting back answers referring to the OTHER ship rather than its own ship. The reason it is intermittent is that it's hard to predict which half of the split is going to become the "new" vessel, and it's almost as if KSP is picking that at random. It just occurred to me how you could prove once and for all that this is the problem. When you experience this problem next, and one of the two parts is unable to lock steering properly, then do this while the problem is still in effect: In terminal 1, PRINT SHIP:MASS. In terminal 2, PRINT SHIP:MASS. If they're on two different vessels that have different parts, they should return two different numbers. If they both return the SAME number despite being on different vessels, that's proof that both CPU's still think they're part of the same ship as each other.

This mission bugged up big time. It incorrectly believed that when the vessel landed it had been destroyed when it hadn't. it was just fine and dandy. A nice soft landing at 3 m/s at the point of touchdown. Nothing broke off. Everything was fine. But the contract incorrectly thought it blew up and thus gave me the failure penalty of 2 million Funds (thus effectively ending that career game as I only had 500000 at the time.) Here's the screenshot of the false claim of vessel destruction by the mod - where you can see the vessel is just fine and nicely landed. Is there somewhere in the save game that the alleged failure can be undone? I suspect the error may be this: Just prior to landing, I still had the uppermost stage of my ascent rocket attached because it still had fuel in it. Rather than discard it with fuel remaining, I decided to use it during the initial part of my descent. I figured it would run out when I was still a few km above the ground, and then I'd decouple it and switch to the lander's engines. This is exactly what I did. BUT this meant that my spent stage was falling just underneath me as I came in to land, and it exploded into the ground (as I'd expected) while I was only about 1km up on my descent. This meant that it exploded into the ground WHILE it was within the 2.5 loading range. I wonder if that explosion confused the mod into thinking it was a relevant part of my main vessel that had experienced a catastrophe when in fact it was just the crash of a spent stage, which is normal and intentional.

The expense of the query can be greatly reduced by just giving you a way to utterly skip the "find thread where" part of it. A query in which the intended result is "find posts where..." rather than "find threads where..." would give me exactly what I want, and I think a lot of other people too. Don't bother doing any of the joins between posts and threads tables. Just search the posts themselves, and don't bother culling out the multiple posts mentioning a word in the same thread, and it would let you see a list of the POSTS containing the search term and when you click on them you get taken to the link to that post within its thread.

I looked back about 2 weeks worth of the thread and never saw the word "Volume" mentioned in any previous post. Can you elaborate as to what you're talking about? Presumably you're seeing this message when you think you shouldn't?

You type a search term "word". You get lots of threads as hits, ordered from newest to oldest. Except it's not the age of the mention of "word" that's being sorted on. It's the age of whatever post happens to be the newest one in the thread regardless of whether that post has a thing to do with your search term. In other words the search is sorted this way: For each post that has a hit for "word". Get the thread containing the post. Get the timestamp of the newest post in that thread. Sort by that timestamp. When what would actually make sense is this: For each post that has a hit for "word", grouping distinctly by thread picking just the most recent post that has "word" within each thread. Get the timestamp of that one post containing "word" in that thread. Sort by that timestamp. That should be doable in SQL language in a database query. The point is that the person searching wants a "newer" hit to mean a newer hit of THAT word, not a thread with a very old hit for the word that happened months ago but people have been adding to the thread after that about other subjects.