Steven Mading

Members
  • Content Count

    3,571
  • Joined

  • Last visited

Community Reputation

694 Excellent

1 Follower

About Steven Mading

  • Rank
    Capsule Communicator

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Steven Mading

    Universal Storage II

    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.
  2. Steven Mading

    [1.5.1, 1.4.5, 1.3.1] RemoteTech v1.9.0 [2018-10-29]

    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.
  3. Steven Mading

    KSP Loading... A closer look into Update 1.6

    I like the new engine bell shapes on the vacuum engines. Their shape always bugged me before since real world vacuum engine bells need a "taller shape" than atmo engine bells, and in KSP they were the other way around with the poodle and terrier having shorter fatter nozzle shapes than the skippers, mainsails, swivels, and reliants. I also get why the poodle was changed to two nozzles - because that's really the only way to make the nozzle have the right shape while still keeping the overall part height similar to what it was before - by making the nozzle smaller overall, which then means you need more than1 of them to make it look believably powerful enough.
  4. Steven Mading

    [1.4.1] kOS v1.1.5.2 : kOS Scriptable Autopilot System

    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.
  5. 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.
  6. Steven Mading

    [1.4.1] kOS v1.1.5.2 : kOS Scriptable Autopilot System

    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.
  7. Steven Mading

    [1.4.1] kOS v1.1.5.2 : kOS Scriptable Autopilot System

    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.)
  8. 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.
  9. 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).
  10. 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.
  11. 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.
  12. 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.)
  13. Steven Mading

    Flight Computers

    Okay, sounds neat... but... I fail to see any logical connection between your first sentence and your second sentence.
  14. 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.
  15. Steven Mading

    Is there an option to use something other than IMGUR?

    @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.