Jump to content

Snark

Moderator
  • Posts

    9,522
  • Joined

Everything posted by Snark

  1. Hello, sorry for the late response! So, about the countdown dots, like this: ...The current version of BetterBurnTime only shows those dots for the closest-approach tracker. It doesn't show them for maneuver nodes or the surface-impact tracker. Reason why it doesn't show them for maneuver nodes: Actually, it used to. However, KSP 1.5 added a much improved burn-indicator for maneuver nodes, so BetterBurnTime now defers to this, since BBT version 1.7. Reason why it doesn't show them for surface impact: It's never shown them for that, mainly because the code in the mod is not currently smart enough to be able to accurately calculate exactly when the burn would start. (Reason for that is that it requires split-second accuracy, and being accurate about that is a Great Big Fat Hairy Difficult Problemâ„¢, so I've never had the gumption to tackle it. It would be a very big job.) You should be getting the dots for the closest-approach tracker, though, so if you're not getting them for that, then that would be a bug I'd like to know about.
  2. Well, in general, the way BetterCrewAssignment works is: If you've previously manually assigned a specific kerbal (e.g. "Val") to a slot for that ship, try to put that kerbal in the slot, if they're available. And if they're not available, try to assign a kerbal of the same profession as the one you assigned. "Val's out on a mission, so you get Jeb, since he's a pilot too." Or, "The tourist you previously assigned isn't here, so you get this other tourist." If you've never manually assigned a specific kerbal to that slot in this ship, then it uses part-based rules (from the ModuleManager config) to decide who gets priority. I believe it would be possible, for example, to put ModuleManager config in place for a particular part (say, crew cabins) if you were so inclined, so that the game would try to fill that part with tourists when available. However... regarding this comment, ...that's kinda problematic. Because BetterCrewAssignment has no idea what your intended purpose for a given ship might be. Suppose you've got some tourists that you intend to send on one mission for contract A, and you have some other tourists that you intend to send on a different mission for contract B. And then you build a ship in the VAB, which has a part on it that (let's say) you've used ModuleManager config to prioritize tourists for. Well... BetterCrewAssignment has no way of inferring which contract you intend to satisfy with that ship. Are you planning to send that ship on a mission for contract A, or contract B? It doesn't know-- so it therefore has no way of knowing which of the tourist kerbals it should assign there. Now, that said: let's say that you intend it for contract A, so you specifically manually assign the contract-A tourists to it, and save the ship after doing that assignment, and then you launch. And let's say you accidentally mess up the launch and then revert to VAB and launch the same ship again. Well, in that case, your saved preferences should stick with the craft file, and it should remember that you wanted this tourist Dinkledorf in that Hitchhiker seat, so it should put Dinkledorf there again when you launch. Beyond that, though... I'm not really sure I see what more it could do?
  3. Interesting! Thanks for the suggestion, I'll consider it next time I update SimpleFuelSwitch. Thanks for the concrete code examples. Out of curiosity, though: why the specific concern about "craft being saved into a file"? i.e. what's the reason for thinking it's okay in a craft file, but not anywhere else? Also, even granting that concern, why is it needed to check that ShipConstruct.SaveShip() is in the stack trace? For example, if you're checking that HighLogic.LoadedSceneIsEditor, why is that not sufficient to cover that condition?
  4. That occurred to me, too. However, if you run the numbers based on Kerbin's radius and rotation speed, centripetal acceleration turns out to be only about 5 cm/s2 at the equator, or 0.5% of gravity. So that seems way too negligible to produce as dramatic a variation as OP was observing. (Plus, if that were the case, he'd notice a big difference at the equator depending on whether he's flying east or west, and he didn't mention anything about that.)
  5. In a vacuum, yes. In atmosphere it's extended a lot, to something on the order of 25 km.
  6. Various content has been redacted and/or removed due to violations of the forum rules, specifically: making personal remarks (rule 2.2.d) disclosure of private conversations without consent (2.2.f) off-topic (rule 2.2.o) attempting to enforce rules (rule 3.2; please don't do this, you're not a moderator and it never ends well) Folks,please don't engage in personal drama, which includes personally criticizing other people's behavior or trying to tell anyone what to do or not to do. It accomplishes nothing but driving the thread off the rails, fanning flames, and everyone loses. If you observe someone behaving in a way that you believe violates forum rules, then please feel free to report the post, and the moderators will have a look to see whether any action is indicated. Beyond that, though, please don't respond to inappropriate content, or try to enforce anything yourself. Thank you for your understanding.
  7. Some content has been removed due to personal remarks, which are not allowed per forum rule 2.2.d. Folks, please address the post, not the poster. Any comments speculating on another user's character, behavior, motives, or the like are solidly out of bounds. If you don't like what someone else has to say, then you are welcome to address what they said, provided you can do so civilly. Or you could simply ignore them if you don't feel it's worth engaging. Thank you for your understanding.
  8. Yes, this was done deliberately. That's why, if you look at Add_LFO_to_LF_tanks.cfg, I call out specific parts by name, rather than using a wildcard to just "add it to everything" as I did with LFO. Rationale: There are a lot of LF parts which, to me, make no sense to add LFO to. There are a bunch of them that are directly and clearly tied to atmospheric air-breathing flight, for example. Basically, anything that has an air intake on it, seemed to me to belong to the category of "this part is overwhelmingly used in contexts where only LF is needed", so I figured it's better not to add the switch on there, because, 1. adding any UI to anything is clutter, and 2. I loathe clutter, and 3. therefore I only add clutter if the benefit of the feature is worth the added clutter in the UI. Since these seemed like parts that would rarely need to be switched (I certainly never switch them in my own gameplay), I figured it was better to leave it off. This one was not skipped, and I deliberately added a switch for it. It's in there. I added this because it's a high-temperature part that isn't necessarily used for atmospheric flight, and would be a handy place to stash LFO for a spaceplane. The strake is missing-- I didn't notice that it contains fuel, and would have added it if I had. This was an oversight, thanks to @VTOL Frog for pointing it out. I'll add this. Main reason I didn't add LFO to this one is that this part's temperature tolerance is so incredibly low that I've found it very hard to use for anything that needs to go fast enough to escape atmosphere. In other words, my experience has been that any craft that needs LFO engines is going to be going so fast that it would burn off the FAT-455 wing anyway. Therefore, there didn't seem to me to be much need of a switch for this one-- i.e. in my opinion, the value the switch adds would be less than the "clutter cost", so it didn't meet the bar. That said, of course I realize that other people have play styles of their own who might prefer these deliberately-omitted parts to have the switch available. My rationale for omitting them still applies, as far as I'm concerned, so I'd be somewhat loath to go ahead and add it to the default install. One thing that occurs to me I could do, however, would be to create an "optional config" file (similar to what I've done with DefaultActionGroups, for example) that would be available for installing for anyone who wants it, thus saving people the need to cobble together config on their own. Let me mull this over. (And if anyone has ideas for other optional config that would be good to have, I'm open to suggestions, though I make no promises.)
  9. Thank you! I missed this, will add it in to the next update of the mod.
  10. No, that's not normal. No mod should ever be throwing NullReferenceException. That generally indicates that the mod is assuming something about the state of the world (i.e. taking some condition for granted), when in fact what it needs to be checking whether that assumption is correct. So, the fact that ModuleSimpleFuelSwitch is throwing that error means that there's a place where I missed a spot. I've looked into the code, and I suspect that I've identified where the problem is: This mod works by adding modules (via config) to certain parts, to enable the functionality. To enable SimpleFuelSwitch on a part, what one needs to add is, a single ModuleSimpleFuelSwitch two or more ModuleSwitchableResource (these are the options to switch among) Normally, it would never be the case that one has a ModuleSimpleFuelSwitch but no ModuleSwitchableResource on a part. (Because it's not going to work without ModuleSwitchableResource. If one isn't going to add ModuleSwitchableResource, why add a ModuleSimpleFuelSwitch in the first place?) However, it's possible that someone could add config that puts a ModuleSimpleFuelSwitch on a part, and forgets to add ModuleSwitchableResource. So the mod should handle that case without blowing up, even though it's a case of mistaken config. My code doesn't handle this case. It blows up. So, that's a miss on my part. I'll update the ModuleSimpleFuelSwitch code so that when such an abnormal situation happens, it will simply log a warning message and go inert for that part, rather than blowing up. Thank you for bringing this to my attention! That said... it would be interesting to know just how you (presumably) got into a situation where you've got a mis-configured SimpleFuelSwitch. Some possibilities that spring to mind: you added some config yourself? there's some other mod you have installed, that interacts poorly with SimpleFuelSwitch in some way? perhaps it's mis-configured? some part that I put config on, and screwed up, and the only reason I haven't noticed is because it's not a part I usually use while playing (this would be the most embarrassing) Once I fix the bug so that SimpleFuelSwitch doesn't go kablooie when the config is wrong, this sort of situation will be easy to diagnose because you'll have a log message that will identify what part is causing the problem. However, until that happens, the only way to figure it out would be some digging on your part. Some questions for you: Do you have any other mods (beside SimpleFuelSwitch itself) that add SimpleFuelSwitch config to anything? Have you added any SimpleFuelSwitch to anything, yourself? Can you narrow it down which part is causing the problem? e.g. try making a very simple ship with just one fuel tank on it, does that reproduce the problem? which part needs to be on there for this to happen?
  11. Moving to "Tools and Applications", since this isn't really a tutorial per se. Very cool work, @Krafpy!
  12. No idea here; can't reproduce it, works fine for me. Do you see the issue if you have BetterBurnTime, but nothing else installed?
  13. Hi @SelfAwareMatter, and welcome to the forums! This looks awesome, and I expect lots of folks may find it helpful! However... this is basically a mod, so it needs to be treated as such in the forums. Please see the add-on posting rules. The main thing you need to do (that you haven't already) is to pick a license, state what it is in the OP above, and make sure that your downloadable package has a license file in it with the full text of whatever you've picked. We've taken the liberty of moving this to Add-on Development, since de facto it's essentially a mod. (Would have put it into Add-on Releases, but wasn't sure if you were calling it "released" yet, plus there's the license issue to take care of.) If at any point you'd like us to move it to Add-on Releases, please let us know and we're happy to do so. In the meantime, we've removed your download link, since the license requirement's a pretty firm one for anyone offering their work to download. Please feel free to restore the link once you've taken care of the license issue as described above. Thank you for your work!
  14. Some content has been removed and/or redacted, due to: accusations personal remarks ...neither of which is allowed by the forum rules, specifically 2.2.d. Please try to stay civil, folks. Also, please remember that it's never any user's place to tell any other user what to do or not to do. And if you see someone behaving in a way that you believe to be inappropriate, please just report the post and let the moderator team have a look at the matter; don't try to respond to it yourself, as that never ends well. Thank you for your understanding.
  15. Locking thread pending resolution of licensing issues. @--Sentinel--, please contact us if you need guidance about the posting rules, license, etc. Thank you for your understanding.
  16. Hi @Frameshift, It looks like there was a problem with the image link you tried to post, such that the picture was, 1. not visible to anyone but yourself, and 2. causing issues with the forum formatting; so we've taken the liberty of snipping it. It looks as though you may have been trying to link to an image that's hosted in your personal space somewhere, and which therefore nobody but you can see. To post images in KSP forum posts, they need to be posted somewhere that is publicly accessible-- imgur.com is the most popular site that most people use, but there are plenty of others if you'd prefer those. Moving your post to Add-on Discussions, since this is about an issue with a mod.
  17. Hello @--Sentinel--, and welcome to the forums! Moving to Add-on Releases, which is where mods and modpacks live. Sounds pretty cool! However... we've had to snip your download link from your post, because unfortunately there are still a few more hoops to jump through. Please see the add-on posting rules, here: ...specifically sections 1 and 2 regarding licensing. Executive summary is that to post something downloadable, you need to specify your license. Also, if you're including anyone else's licensed work (e.g. anything from any other mods that are posted here), there are requirements around that as well. We look forward to seeing your modpack, but please try to sort out the licensing requirements before re-posting the link. We know this stuff can be complicated and confusing, so please feel free to reach out to us privately if you need assistance working out what needs to be done. We apologize for the inconvenience. Thank you for your understanding, and again, welcome to the forums!
  18. Moving to Add-on Discussion.
  19. I believe the auto-deletion altitude is defined as 1% of Kerbin sea level pressure. On Kerbin that happens at around 23 km. On Eve it would be a lot higher, and on Duna considerably lower. Correct. As the others have observed, this is just how the game works. Craft that you're not piloting and which are outside the "physics bubble" are running "on rails"-- there's no physical simulation at all, they're just following a perfect conic-section orbit according to the laws of mathematics. The game does that because doing an active physics simulation on a craft is computationally expensive. Basically, they can only afford to simulate the current ship, and any nearby ones. Since there are potentially hundreds of ships in the game, all in various orbits and situations, there's just no way the game could simulate them all; it would bring the computer to its knees. Aerodynamic drag is particularly computationally intense-- for every single part on the vessel, the program has to do a bunch of computations based on its speed (which is changing moment by moment), its orientation (also changing), the atmospheric pressure (also changing), etc. By putting the craft "on rails" they reduce the computational burden to near zero, thus making it possible to have lots of ships in the game without bogging down the computer. The fact that it works as well as it does without the player ever noticing (most of the time, anyway) is a testament to the effectiveness of the technique. It does, however, have its limits, and lack of orbital decay is one of those. The computational shortcut becomes more apparent in situations like the one you're describing.
  20. Perhaps so, but the original poster's question is long since answered, and further discussion in this thread is probably moot at this point. Accordingly, locking the thread to prevent further confusion. Anyone with more questions or comments on autostruts (or any other topic) is welcome to spin up a new thread for the purpose.
  21. Some content has been redacted and/or removed, due to flaring tempers and people making it personal rather than having a civil debate on the merits of the arguments. Please do not tell other people what to do or what not to do. Please do not make personal remarks. Address the post, not the poster. Thank you for your understanding.
  22. A lengthy but interesting side discussion ensued from this point, regarding the nature of human perception, how frame rates affect that, how high a frame rate can we "see", etc. It's a worthwhile discussion, but at this point it became utterly unrelated to the original topic of this thread (it was about human perception and frame rates in general, nothing to do with KSP 2, or with PC resources consumption). So we've split it off into a separate topic of its own, which anyone who's interested can follow and discuss here: We now return you to your original thread, already in progress. Please try to stay on topic, thanks!
×
×
  • Create New...