Dunbaratu

That doesn't make much sense. Can you show a log of it?

Bug: Storage tank slider levels don't persist in craft file. To re-create: 1 - Attach a Radial Storage tank to the vessel in the VAB, on any resource type. The example pictured here uses Oxygen. 2 - Use the slider to reduce the storage to less than 100%. (See first image linked to below). 3 - Save vessel design. 4 - Launch Vessel. Notice the slider seems correct HERE - the reduced resource is rememebered (see second image linked to below). 5 - Recover Vessel. Go back to VAB. 6 - Click "new" vessel button. Click "Load" Vessel button. reload the same vessel design. 7 - The slider is back to 100% again. The .craft file seems to have no memory (or it does but it doesn't load properly) of the the slider's position, so it resets to default. The slider positions should probably persist in the craft file, just like the stock game does for reduced fuel levels. Screenshot In VAB originally: https://steamcommunity.com/sharedfiles/filedetails/?id=1593401713 Screenshot launched from VAB: https://steamcommunity.com/sharedfiles/filedetails/?id=1593401744 Screenshot back in VAB again, reloaded from craft file: https://steamcommunity.com/sharedfiles/filedetails/?id=1593401763

The real messy problem with the power starvation flag set wrong is with how RT works by making a sweeping denial of everything that would have worked in stock, and then selectively allows the things to work it decides to allow. So when RT gets a false notion that the power is starved when it's not, that doesn't just prevent the RT computer from working. It also prevents the Kerbal sitting in the cockpit from using their controls to, for example, take a temperature reading for science points. The check RT does where it says, "should I get out of the way and let the control work because this ship has a crew?" is also not working right when it has a false notion of power starvation. The pilot tries to take a temperature reading, and it doesn't work and a message appears claiming the ship is out of power. So getting the flag wrong does more than just prevent the RT computer from working. It prevents the pilot, made of meat, from working. What I'm getting here is that essentially these entirely different Boolean checks: "Does a signal exist?" "Can the RT computer widget be used?" are too tightly coupled together in RT to separate the them effectively. It's not just that the power starvation check blends the two things together - it's that the entire mod itself does, at a deep enough level that they cannot be pulled apart. It seems like the only solution that would really work is to have kOS add a ModuleCommand to all kOS parts (even if RT is not present so this feature of kOS mod behaves consistently regardless of RT's presence), and then add the ModuleSPU also iff RT is present So that it is possible to make a ship in which the kOS part *is* the probe core, rather than having to have a kOS part *and* a separate probe core part. While not originally how kOS was meant to work, this seems to be the only way to get around the problem without confusing RT.

Bug: Oxidizer runs out before LiguidFuel. (The 9-to-11 ratio is configured backward.) The "Universal Storage: Radial Tank" part seems to have the stock 9 to 11 ratio for LiquidFuel to Oxidizer backward. It should be 9 parts Liquidfuel per 11 parts Oxidizer, or so I thought. When I tried making a service module with lots of these little tanks in it, it ran out of Oxidizer when there was plenty of Liquidfuel left. I think the culprit is this config in GameData/UniversalStorage2/Parts/Radial/RadialTanks.cfg : name = USFuelSwitch SwitchID = 0 resourceNames = Oxygen;Hydrogen;MonoPropellant;LiquidFuel,Oxidizer resourceAmounts = 3600;3600;3.5;3.7,3 initialResourceAmounts = 3600;3600;3.5;3.7,3 Notice the way it is set up, it's assigning the "3.7" value to the LIquidFuel, and the "3.0" value to the Oxidizer. Notice that the ratio of "3.7" to "3.0" is almost exactly 11 to 9. So I think it *is* the right ratio, just swapped around so you have more liquid than oxidizer instead of the other way around like it should be for stock fuel. I haven't looked at any of the other part configs to see if they have the same problem. For all I know they might. I just happened to encounter the problem with this one.

To be clear, the summary of the problem is this: 1 - RT's API call HasConnectionToKSC() requires a ModuleSPU on the vessel to be able to return true. Even a vessel that definitely has a connection will still claim it does not, if that vessel has no probe core and instead only has manned capsules on it. Even if there's people in the capsule so it should work, RT still claims no connection exists when the vessel lacks a ModuleSPU, regardless of the antennas' config. 2 - So I tried to add ModuleSPU to the kOS units, with ModuleManager. I'd have considered this a fine solution to the problem, since I wouldn't expect RT to work on a vessel that lacks its PartModule. I'd have been happy with this solution ... if not for the fact that it invoked the next problem... 3 - RT wants to detect if the ship is out of electric power, and set a flag that it will use elsewhere in the code to disable some things. But the test it is using to detect power starvation is a really indirect strange side-effecty kind of test that creates a false positive if the part with the ModuleSPU has no ModuleCommand in it. (It tests to see if the ModuleCommand in the same part is powered up and available for use, and *assumes* that if it's not then this must be because the power is starved, so it sets that flag.) This check does not distinguish the difference between the case where the reason it's not available is because it's not even in the part at all from the case where the reason it's not available is because its power starved. (It's doing the typical short-circuit safety check where it protects itself from nulls and doesn't perform the test if the ModuleCommand doesn't exist in the part. But this makes it pretend that "ModuleCommand does not exist" is the same thing as "power is starved", and set the flag the same way in either case.) The effect of #3 is that if I add ModuleSPU to kOS units as described in step 2, then ModuleSPU's weird way of testing for power starvation will get a false positive on all vessels that have a kOS part on them, making RT deny the ability to use the vessel's controls, EVEN from a crew capsule with crew in it. The ship is frozen uncontrollable because RT is disabling the right to control it under the false impression the ship is out of power when it's not. At that point I gave up on trying to fix it with modulemanagger magic, and instead just said "If you use kOS with Remote Tech, then never build a ship that lacks a command core. Add a command core even to crewed vessels, because RT needs one present in order to find the connection to home." The reason that the original problem (#1 above) doesn't affect RT itself, and only matters with kOS installed, is because RT itself doesn't care if there's a connection to home or not when the capsule is crewed. So the fact that it returns the wrong answer when no ModuleSPU exists is fine. But kOS does care if there's a connection to home, because it normally asks stock CommNet for the answer to that question, which it should NOT do when RT is being used. When RT is being used, kOS defers to RT to decide if there's a connection. Unlike RT, kOS *does* care whether there's a connection or not even on a crewed vessel, because it uses the connection to decide if it's allowed to copy files from home to the vessel.

This is exactly the criterion I use for staging (when any engine is done, stage). function maybe_stage { local engs is 0. // just to make the variable local - this will be overwritten. list engines in engs. local reason is "no ignited engines right now". // default if none found ignited in the list below. for eng in engs { if eng:ignition { set reason to "none". // good that at least one engine is ignited. if eng:flameout { set reason to "flameout of " + eng:name. // but bad that it is flamed out. break. } } if reason <> "none" { print "Staging because of " + reason + ".". stage. wait 0. // not sure if it's needed, but it ensures KSP notices the new vessel config and updates everything. } } Then just keep calling maybe_stage() from inside your program's main loop so it keeps checking. As long as you keep calling it again and again, it will keep trying to stage again and again until the vessel is in a state where there is at least one engine is ignited, and none of the ignited engines are flamed out. Note the game enforces a cooldown timer on staging, so you may hear it going "click click click click" as it tries to stage a second time again and again till it works, but that's fine. Be aware that I typed this mostly from memory. It may have bugs, but this is the basic idea.

Has anyone encountered a problem where GPP disagrees with *itself* whether or not ore (stock ore) exists at a spot on a body? This was on Iota. I did the orbit scan to show the ore (stock ore, no resource mods). The map shows the purple patches for where ore is. I make a driller and land it in one of the patches. It drills just fine. Later I send another driller to another one of the purple patches, one that is JUST as densely purple, and the driller keeps claiming there's no resources there. The concentration is very high according to the purple color on the map, and I"m right smack dab in the middle of the brightest concentration of purple in the patch. Nothing there according to the drill. I have a bit of extra fuel so I try to re-launch and land in multiple different spots within the patch. The drill claims nothing is there each time. I have no idea how I'm supposed to react to this information. If it was a mild low-intensity patch I'd move to a better patch, but playing with the "% cutoff" levels in the display shows this to be one of the best patches on the body. There isn't a better patch to move it to. Everything the map display is telling me is claiming there is good ore here. The drill disagrees and says there is none. Has anyone ever seen this happen before? I know GPP used to not work with stock resources and you had to install Community Resource mod to make it work, but I thought that had been fixed in the later versions of GPP. Besides, when that was a problem, the effect would at least agree with *itself*, where the space scan would claim there's no ore. In this case the game is disagreeing with *itself*. The space scan *says* there's ore there. The map shows ore there. But the drill says there isn't.

A CPU is only allowed to change things about its own vessel. It can query things about other vessels, but not change them. You could make a CPU send a message to another CPU that the other CPU chooses to respond to, but a CPU is not allowed to directly force another CPU to run a command.

It's a little difficult for me to follow what you are describing here. Are you saying that you perform this command: kuniverse:forcesetactivevessel(VESSEL("fhCore3_full Probe")). And then this command: SET SHIP:NAME TO "fhBooster1". //looks like this not changes name wait 1. On the *same* kOS CPU? Because switching the active vessel doesn't cause the kOS CPU to change which vessel is "SHIP". "SHIP" is always supposed to be the vessel the kOS CPU that runs the command is attached to, whether that is the active vessel or not. (But I'm not sure I understand your description of what you are doing. There *is* a bug you might be running into here that I've seen before, but there might not. In order for me to tell I need to know which kOS CPU is running which of those commands.)

I have been burned before where that is not what happened. It was just wasted effort because the PR wasn't wanted. Thus why I was more in the habit of discussing first before doing. Especially if it's the *very first* time I'd be dealing with that particular project, so there's a learning curve to get over before I can make a PR. That's a bit of "up front" cost of effort that is just thrown away if it's something the team doesn't want.

I know kOS. I do NOT know RO or RP-0. The development model of "drop a PR on the team from out of the blue, with no discussion ahead of time about what it's trying to do or whether the team even thinks that's a problem worth solving" is not how I'm used to working. So the pattern I'm used to is "raise issue, team discusses and someone on the team says they like the idea, then make PR, submit PR, team merges it", which is why I was sitting a long time when the issue got no further replies. I took "lack of response" to mean "there's a good chance if I throw a PR at them un-invited, they won't want it so it won't happen." So I didn't think it was worth me spending the time to learn their mod well enough to do that. The time to spend learning a brand new mod's system isn't worth it if the response will be "thanks but no thanks". The response here in the forum has been very different from on the github issue (which was just silence), so NOW I do feel like it will be worth it to go ahead with that effort. Yes, thank you. That would be great. I may be out of contact for a few days though, because of the Thanksgiving holiday. I don't know what the consequences are of not bothering to change the electric charge scaling as a first pass to getting something done. How much of a problem would it be to ignore that part of things for now? We can discuss more in github comments here: https://github.com/KSP-RO/RP-0/issues/758 That way it will be on record with the issue rather than in the forum history that might not remain forever. That issue was something I wrote up originally in response to NathanKell's request for better information about what can go into the ModuleManager config, but it was just before he sort of fell off the face of the earth for a while (which I hadn't known had happened).

The parts also have a small battery, do varying power drain based on how much code is being run, and one of them has a tiny solar panel on it. I know RO has a totally different set of rules about what one "electric charge" unit means. I think that's part of why I didn't suggest that before. I've got no clue how to scale the power of the part. However, I guess if they're adding the kOS module to avionics cores with ModuleManager, they're getting that probably inappropriate level of power drain *already* right now. As to the "right" tech level, that's going to be a doozy. It's very hard to map kOS back to real world hardware because simplifying some of what real software engineers had to do was kind of the point of it (And if you say that's not realistic, keep in mind that you can slap a rocket engine to a tank in RO and never bother contemplating where the fuel lines are running through that tank, or deal with POGO issues, etc. The game, even in RO, has some simplifications like this to make everything more tolerable as a game. RO adds *some* extra realism issues to the game. It doesn't add *all* of them, nor should it, since if it did then one single human being couldn't simulate the work of tens of thousands of engineers that it really took to deal with those problems.) Real world hardware was more limited, but real world hardware wasn't running high level software either. It was running very primitive pre-compiled (or even hand-woven) machine language instructions early on. And at the start it was more like SmartParts, with separate individual systems each just doing one self-contained basic thing. Those were often analog circuitry instead of programs anyway. One idea that may be useful to RP is that we were going to limit IPU in kOS (that's Instructions Per Update, a really fuzzy way to emulate the idea of slower or faster CPUs) based on tech tree (right now it's just in the settings options menu and is global and the user has permission to change it when they feel like). As that isn't available yet, there's not much RP can do with it for now, but in future it could be another way to 'cripple' early-tech kOS and let it get better with time.

Neither. They're separate disks that can be accessed by drive number or name. Each kOS part is a different CPU which can run its own code and also has a local storage volume. Different kOS cores on the same ship can see each other's local volumes, but they don't merge together into one logical drive in a raid array or anything like that. They're just separate volumes with filenames like "1:/this_file" on drive 1, or "2:/that_file_over_there" on drive 2, etc. I made an issue over there that's over a year old that didn't seem to really go anywhere: https://github.com/KSP-RO/RP-0/issues/758 Part of why I posted here was to see if there is somewhere else that work had been done on things as RP-1 comes closer to happening. Based on that issue, I haven't seen any movement. I don't really want to tell people in RP how to scale things - that's kind of up to them to decide how they think it's best balanced. But to choose to *never* scale anything at *all* in any way whatsoever does sort of break kOS and it's always been a slight annoyance with me.

RP-0/1 removes the kOS parts (they are not "costed") and instead replaces them with a ModuleManager config that adds kOS to probe cores. But it does has always done it wrong and presents a limited crippled version of kOS to the player. kOS is supposed to have 4 different parts in the tech tree to represent 4 different levels of disk size, like so: kOSMachine0m part has: diskSpace = 5000 bytes kOSMachine1m part has: diskSpace = 10000 bytes kOSMachineRad part has: diskSpace = 60000 bytes kal900 part has: diskSpace = 255000 bytes But when playing with RO/RP-0, This is what kOS looks like to the player, because of the bad ModuleManager config: Is it the 1960's? Then you have 5000 bytes. Is it the 1970's? Then you still only have 5000 bytes. Is it the year 2020? Then you still only have 5000 bytes. It's always 5000 (which was only ever intended as the minimum). No matter the tech tree progression. All the time. Unconditionally. Granted, you can pick 2x or 4x multipliers in the VAB for a bit more weight and cost, but that still only lets your 5000byte unit become a max of 20000bytes, which is *still* far less than was intended, as you can see by the first list above. The problem is that the ModuleManger confg unconditionally says "diskSpace = 5000" no matter what, for ALL avionics cores, all the time. And since this *replaces* the mod's intended parts, it kind of wrecks how kOS was supposed to be. Is fixing this on the roadmap for "RP-1"? All it takes to fix it is to vary that "diskSpace = " value for different kinds of avionics cores as you go up the tech tree, rather than making them all the same. I get that in realism overhaul you might want to change this number and make it more limiting than in stock kOS, but it still shouldn't be the exact same fixed value at all tech levels like this. (Before anyone comments about how limited the memory on the Apollo Guidance Computer was - keep in mid that half its programming didn't count toward that number as it was hardcoded programming literally weaved into the system, and for that which was not, it was machine language, whereas kOS is counting the Unicode source text since it's using a script language. There's not really a proper 1:1 comparison between the meanings of those values.)

Okay, sounds neat... but... I fail to see any logical connection between your first sentence and your second sentence.

That post above showing how to get the parts of Making History without the conflicting bits thrown in (the alternate launch sites, mainly) should really be on prominent display in this thread - maybe even in the head post. I've been using it a while and it works perfectly.

@4x4cheesecake I was just editing my post and hitting submit as your thumbs-up arrived at the same moment. Just a friendly reminder that you might want to re-read it in case the thumbs-up referred to the previous content, not this content.

Just putting in a URL with no markup? Okay I'll try that next time. Thanks for the advice. As for the WYSIWYG "part of" the editor, what I wish I could do sometimes is just suppress it entirely, but I'm not sure how to do that. When I try to type some markup with square brackets, for example, even when I try to avoid the WYSIWYG stuff, it still keeps asserting itself, hijacking what I typed and altering it. That is exactly what I typed in my above post. The problem is the broken editor refused to keep what I typed literal and instead it edited it into what you see in my post. EVEN when typing into the code popup which is for the express purpose of letting me type something literal, it STILL asserted itself and altered what I typed. That was why I was getting so frustrated. I suspect part of the problem is that too much of the editor is now on the client side in Javascript, and they probably don't bother testing that across platforms. I get far more problems when using Firefox than Chrome, but I don't trust using a browser from a company that uses spying as its main revenue stream, so I still stick with Firefox and pay for it with donations.

But where is this? If this was still markdown, I'd be expecting an answer like "you type [img=url] I guess the way to phrase it with the WYSIWYG editor is "which button is it"? I looked over the whole row and none of them have hovertext that says something like "image" or "picture". edit: I give up. That is nothing even remotely like what I typed, but the editor keeps changing what I wrote even when in a CODE section, it STILL overwrites what I wrote.

In the forum's WYSIWYG editor, clicking the image icon opens a popup that says "IMGUR album" requiring an IMGUR album code, instead of a complete URL where you could go to another site entirely. That's what I meant.

If I want to post a screenshot in the forums, is there a means to do so that doesn't depend on using IMGUR to do it? Are there any other supported hosting sites? I'm really not a fan of IMGUR because of how invasive their ads are. I understand the need for ad revenue, but in IMGUR's case the ads they hosted were being allowed to run very questionable javascript inside their <div> sections that does things like pop-unders, and stealing keyboard-focus away from the textarea I was trying to type into when a new banner ad cycles into the page.) Yes I could ad-block because of fear of malware, but I figure I shouldn't have to be *fighting against* the site that's using my eyeballs for revenue. I just decided to delete my account from IMGUR entirely to avoid the temptation to go back. But that makes for a problem in these forums because now I lost a lot of the images from some of my posts, like the kOS screenshots and the LaserDist screenshots on the first post of those mod threads. Is there anything else, other than IMGUR, that this site supports?

I fully believe this is because of a big technical limitation of IRC that this practice becomes common on many IRC servers. IRC servers tend not to have a viewable scrollback history of what was said while your client wasn't logged in. The server's job is to merely distribute the posted lines out to all the currently logged in clients, then forget all about them as soon as it has done so. All the scrollback history lives in the clients not in the server. This technical limitation (you have to leave yourself logged in 24/7 if you want a scrollback history of the channel) leads to the problem of being unable to tell who's *actually* there and who isn't.

Just did this, and it's working. Thank you for the advice.

In case anyone from SQUAD is watching this and wants to help solve it (they might not since it's specific to mods), here's another further piece of information from my experience: In addition to having to have the DLC loaded in order to trigger the problem for me, I also had to have the current active vessel be within the area of the KSC but not necessarily on the actual runway or launchpad - just somewhere else on in the KSC area that the mod had moved the KSC to in its planet pack. It seems to be triggered by the KSC being in a different location (due to mods) than it is in stock, and the active vessel being at this relocated KSC.

I had this happen to me before, with the exception being in exactly the same place. The problem is that the first step of any attempt to switch scenes is to first save a checkpoint of the game, and saving the game is throwing this exception so that aborts the attempt to switch scenes. The stock method, Vessel.get_LandedInStockLaunchSite (), seems to throw this exception if you have the Making History DLC installed and have modded the default homeworld's launch sites in some way. I thought the mod was Kerbal Konstructs, but it might be Kopernicus. In any case, I couldn't play Galileo Planet Pack without removing Making History DLC because of this problem.