Dunbaratu

To make it a similar situation manuever nodes would have to be a hard requirement to be allowed to perform any burns at all, and they're not. All the burns you perform with a manuever node could have been done without the help of the node. Manuever nodes don't cause your engine to become ignitable when it otherwise wouldn't have been. Manuever nodes help you *plan* the burn to reach a given orbit. They are not a requirement to make it possible *at all* to make the burn like the astronaut complex is for flag planting. Tonnage limits on the launchpad are also not as much of a hard boolean limit because how much they hinder you varies depending on tech tree upgrades for engine ISP, your rocket design, etc. If RP-0 prevented you from getting an orbit contract based on *it's heuristic guess* of how hard it would be for you to do that would be a problem because for some players that guess would be wrong and it would be doing them a disservice to use that heuristic guess to prevent giving them the contracts they actually *can* achieve but the game doesn't realize it. But this flag planting feature isn't such a heuristic guess. It's a hardcoded boolean guarantee that it's impossible to plant a flag without that AC upgrade. AC upgrades to make EVA's better makes sense (i.e. change how much TAC life support resources an EVA can store. Change how much EVA propellant you have on an excursion). But flag planting is such a low tech thing. Its a silly holdover from the stock game (which, by the way, never offers you a "plant flag on" contract until that astronaut complex upgrade). Another thing that makes sense for AC upgrades is G-force tolerance (again, the idea is the suits are getting better, which is always what I envisioned the AC being all about.) Another thing that makes sense for AC upgrades is limiting allowed Kerbal experience level. (i.e. to level up, you need better training programs.) Or the opposite, instead of limiting allowed level, use it to impart some XP points to new hires (again, it represents training) to make them closer to levelling up. A lot of possibilities exist that feel more sensible than "after we invented the self-contained space suit, we finally figured out the even harder problem of how to stick a rod through the top of a flag so it stays unfurled without air." The only indication of that additional requirement is a one-line thing buried in the bullet points. Adding a one-sentence description of that bullet point doesn't really change this much, I think. What would work better would be to change the title of the contract. In stock, all contracts that require a flag planting actually say they are flag planting contracts in the title itself. Which makes sense because if you ask someone, "Can you plant a flag on the moon yet?" they will know that implies also landing a person. But the reverse is not true. If you ask someone "Can you land a person on the moon yet?" they're not going to automatically assume that means also planting a flag. If the title says "plant flag on the moon" it implies both landing a person and flag planting at once in one compact statement. It might make a better title.

Nothing went missing, although I did have to revert a save because the person in the lander would have run out of food (which feels cheaty, but in this case it felt justified because it felt like the game cheated by creating an un-commanded move of resources without informing me). To be clear, there was a decoupler between the parts which had crossfeed disabled.

I noticed that when it offers the "First human landing on moon" contract, one of the requirements is to plant a flag. But that requires upgrading the Astronaut complex to level 2 first, and you get the contract offered without checking for the astronaut complex level. In other words, if you take the contract without noticing that, and it costs more money to upgrade the astronaut complex than you have.... then you get penalized for the lunar landing contract failure because you literally cannot do the contract yet and don't have the money to upgrade the building yet. Could that be changed to not offer that contract until you have flag planting ability? (or remove astronaut complex upgrades from the requirements for flag planting, because, let's face it, flag planting should be pretty low tech and happen automatically once you can EVA on the surface of the moon.)

Is this "normal" or a bug? It's a lunar mission with a command module and a lander, in which I don't have a docking port and instead will use EVA to move a crew member from the command module to the lander. The lander has room for 5.85 Food in it and the command module has 200 food in it. I notice the lander is nearly out of food, at 0.48 Food left. (Nobody had been in it yet, so it was sucking food out of the lander to feed people in the command module). So I do a resource transfer to move food into the lander, topping it off at 5.85 food for its one inhabitant it will have. Then I EVA someone from the command module to the lander. The instant that person enters the lander, *poof*, the lander is magically back to 0.48 food again, and something has moved that food back into the command module again. When I did the food transfer again the second time, after the person was EVA'd into it, *then* it stayed transferred. But the act of doing the EVA moved it, and *not* in the direction one would expect if it was just a case of the EVA kerbal "taking some food with them". It was in the opposite of that direction. It moved from the *destination* capsule the Kerbal *got into after the EVA* to the source capsule the Kerbal came from at the start of the EVA.

I did it again later and it worked correctly. The only difference, I think, is that the first time I had two active contracts (at the same time) - one for impact and one for landing, which I intended to solve with 2 separate missions. It looks like the landing event got "stolen" by the impact contract and counted as the impact event instead of the landing event, but I didn't notice because the impact contract didn't show up as "done" in the messages icon. But when I left the scene and went back to the space center and looked at my mission control, *then* I saw that the impact contract got marked had been moved over into the "finished" tab (I saw no notice message to this effect in the messages queue button). So it looks like the impact contract "took" the landing event for itself, and also didn't notify me of this with a contract finish message, leading to all sorts of confusion. At least I *think* that looks like what happened.

Does anyone know if there's a known problem with the "Lunar Landing (uncrewed)" contract? (This is RP0 v0.54.0.0) The problem is, as far as I can tell I did everything right... and it claims I'm not landed on the mun. I know for a fact that I am because I can print my status from kOS and it comes back as "LANDED" (which is taken directly from the KSP API for the vessel's status so I know it's true). But all the bullet points of the contract say they're done, except that one. The ship did tip over on landing, but none of its parts broke off, so it shouldn't count as destroyed in any way. (In the screenshot, note the uncompleted bullet point called "Land on [the Moon]". (I also noticed that although the API calls the moon "Moon", sometimes aspects of the game throw a "the" in front of it, calling it 'the Moon". I wonder if that is in some way related? Maybe the name being sometimes "Moon" and sometimes "the Moon" is confusing things? In the end I used the debug menu to force-succeed the contract because IMO I did it correctly.

Does that merely remove the UI button the partmodule adds to the menu, or does it entirely remove the PartModule itself from the part? If it removes the partmodule entirely from the part, then wouldn't that also get rid of the ability to trigger it from an action group? I'm not sure if it's possible to keep one but not the other if both are caused by the same partmodule.

Does anyone know which of the many mods under the RO umbrella is the one that adds the "Range Safety" button to the probe parts, and if so, how I can remove that button from the rightclick menu? IMO, because there's no "Blow it up? Are you sure" y/n" confirm on that click, and it just happens immediately upon misclicking on that button instead of a button adjacent to it, that button shouldn't be there. Activating range safety should be something that only is possible when you really meant it, not when you were just a few pixels off. Having it accessible through only the action groups (i.e. the abort button) would make more sense to me and I was wondering if there was a way I could set it up to work that way.

Okay.... that's not really a question though. Are you seeking advice on how to go about doing it?

I think the problem is that your program reaches bottom and ends before the WHEN.THEN has time to fire off. Once the program ends it clears out any WHEN,THEN triggers it had set up (can you imagine the nightmare of debugging if it didn't, and they could still take over and trigger after the program is over and you're in the middle of running something else instead? That's why we clear them out as soon as the program is over.) To make them trigger you'd have to keep the program from finishing until they go off.

Terminal velocity is not a simple number anymore ever since the atmosphere model changed. Now it properly has a different terminal velocity depending on your vessel's shape and orientation (which can change from one second to the next). The only way to find it now would be to determine it experimentally for a given design and orientation. (i.e. when falling, calculate where it would have been had there been no atmosphere, then compare that to where it actually ended up, and the difference is due to air drag). We did remove terminal velocity from the documentation back when this change happened ages ago, and did make note of it in the changelog at the time, but missed a few places it got mentioned in the docs, it seems.

It's not known to be broken. What is the comm system selected for kOS config, and what's in use in the game?

One difficulty of setting up a challenge in which you use the RT mod is that it will vary greatly from one savegame to the next. Can the player have a pre-existing satellite network set up or is that part of the challenge?

We tend to be more active on reddit in /r/kos. That's because here on the KSP forums we get only one thread for all of kOS, and that gets frustrating to deal with because separate conversations get interleaved together. On the subreddit it's easier to keep separate conversations separate. What was the question you wanted to ask?

Now I solved the saved file problem too. It took a while to find the problem. There was one spot buried deep within the code that writes to the persistent.sfs file that was using ASCII instead of UTF-8 mode when converting from a String to a byte array. Now I have a Pull Request for it on Github, but I have no idea when the next release will be that includes it.

I solved the input keyboard problem but the saved file problem is harder to find and I'm still working on it.

I don't know yet where the cause of the problem is, but here's a possible workaround for you to try until then: If you use the telnet feature, and your telnet terminal program is capable of using "UTF-8 Translation", then the Russian keyboard will work via telnet. I tested it just now as part of trying to narrow down the problem. (Knowing that the telnet terminal works fine eliminates large sections of the source code from being the cause. Whether the input comes from telnet or from the in-game terminal window, after a certain point it follows the same path through the source code either way. So the problem has to be happening before then, when the two techniques still differ.)

I made this into a Github issue, here: https://github.com/KSP-KOS/KOS/issues/2061 You can look there to track further progress as I look into this problem in the next few days.

Okay I installed the right options in Windows to get my keyboard to toggle between Russian and US mode with alt+shift. I think I am now able to see the problem in front of my own eyes. Can you confirm: is this the same exact problem you are seeing: In Notepad, I type the (US layout) "q" key, then shift modes to Russian with alt+shift, and type "q" again and get the Russian letter й instead. So, this is the expected behaviour. Then I try the same thing in the kOS terminal. I type "q" and get 'q' as expected in US mode. Then I shift it to Russian mode with alt+shift, and type "q" expecting to get "й", but instead get "9". If this is the same thing that's happening to you, then at least I know I've been able to reproduce the same problem, which is necessary before I can start fixing it. I can't read Russian, but I can at least see that "9" doesn't look like "й". I promise I want to fix this. Getting kOS to work in other languages was one of my main goals when making it able to use unicode fonts, and I'm frustrated to find out it didn't work like I expected. I'll get started on this on July 5th. (Tomorrow is a holiday here and I'm busy). So, as an example, "й" is unicode 0439hex, while "9" is unicode 0039hex. They have the same low byte (39hex). This seems to suggest very strongly that somewhere along the way the high byte (04hex) is being zeroed out. I thought I'd found every spot where that could happen and changed it, but I probably missed a spot somewhere.

All I did for my testing was try to print out some Unicode codes of a few Cyrllic letters, for example: print char(1103). // Unicode 0443hex, "Я" print char(1041). // Unicode 0411hex, "Б" etc... It's possible there is another standard used in Russian fonts that doesn't match Unicode conventions, but if so then I don't know much about it. I don't speak Russian. The first test is to ensure the font chosen actually has the Unicode characters in this range populated (Hex 0401 through Hex 04FF). Not all of them do. The second problem might be that the keyboard sends codes that uses a different standard than Unicode. Again, I've never used a Russian keyboard so I don't know how it works. The third possible problem could be a mistake in kOS where keyboard codes might be getting cut off if they are out of the expected range. I thought I got all the places that expected only 7-bit ascii and removed the limitation, but without an actual Russian keyboard to test with I don't know if I missed something. Can you describe the exact problem you are seeing? Is it this: "I try to type a Russian letter on my keyboard and nothing happens."? Or is it this: "I try to type a Russian letter on my keyboard and I get a letter on the screen, but it's a different letter than the one I typed."? Also, is it using the in-game terminal or is it using telnet? If it's using Telnet it might not be using the right encoding to send the characters down the line.

Okay I'll try that for now. So is the problem that they spawn with their feet under the ground and that makes them "collide" with the terrain?

If I edited the .cfg files for a contract pack, after I already had been playing a career and have a saved game for it, do the new settings take effect for newly spawned instances of the same kind of contract in that career, or is there some cached data that remains in the save game that prevents the new .cfg file settings I made from being used? (I'm not talking about the contracts I already accepted - I'd expect those to stay the same. I'm talking about newly offered copies of the same kind of contract that didn't appear until *after* having edited the .cfg file) I ask because the contracts are still behaving like they have hardcoded altitudes for SpawnKerbal even though I commented the "alt = ...." line out of the config. I'm wondering if I've actually accurately tested my change or whether I'm still seeing the effects of the old settings because something is cached.

Okay here's another useful data point: for the contract where passenger kerbals spawn next to the runway. They did spawn on the ground at first. Then I taxi'd toward them from the plane spawn point. They were clearly at ground level... ...until I approached within 300 meters of them. At the very point where their distance marker registered a number < 300 meters they suddenly teleported from the ground to a point a few hundred meters in the air above where thy had been and started falling from there. That number, 300, is suspicious to me. It happens to be the "unpack distance" for landed objects on Kerbin. (The distance when a vessel goes from merely being visual renderered to also having all the physics applied to it).

Okay that didn't seem to fix it (although with how much CC caches things in the game it's hard to tell if my edit actually took effect or if it's running off the old contract info stored somewhere in the save game. Anyway, I noticed something this time - I was able to go "fly" the "Vessel" for the landed kerbal the K2 rescue mission spawned even before you get there (which shouldn't be allowed, and it doesnt' work from the map view but it does from the flight view where you click on the icon for the kerbal in the distance). Anyway, when I did that I noticed the following: The kerbal *DOES* spawn right at the ground.... at FIRST, for a brief fraction of a second as the scene loads in I see myself right down on the ground in the mountain terrain, with trees around me and everything. Then, as it finsihes loading in the scene suddenly I'm teleported to up in the sky above the terrain, with the kerbal up at the problem altitude. Something about the process the game goes through as it loads in the kerbal makes it suddenly be up in the sky, when it definitely wasn't at first. I think something buggy is happening with the "when vessel state is 'landed', move vessel to be at terrain height upon loading" part of the scene loading algorithm. Perhaps it's spawning slightly below the ground and being "popped" up? I don't know.

I had a look inside the .cfg files for GivingAircraftAPurpose and I noticed it's hardcoding the kerbal spawn altitude with an 'alt = nnn.nn" type of line. It's not using ContractConfigurator's option to spawn at ground level by omitting the `alt = nnn.nnn` line. The altitude given for things like Charter-Flight-4 (which is supposed to spawn 4 kerbals at the SPH for you to taxi over to to pick up), is 133m. I'm pretty sure the terrrain altitude is nowhere near that high. I commented out the "alt = " line from all the contracts where kerbals are meant to spawn on the ground to see if CC's defaulting to ground is working and if that fixes it. I'll report more later when I get those contracts again and see if that fixes it. I know CC had some trouble in the past with spawning on the ground and I suspect that maybe the maintainer of GAP may have resorted to the hardcoded altitudes to work around it... then perhaps SQUAD changed the terrain so it's no longer at the same altitude?