Jump to content

TMarkos

Members
  • Content Count

    113
  • Joined

  • Last visited

Community Reputation

53 Excellent

About TMarkos

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

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

  1. Nah, unless it's been changed it won't be possible with just the part files. You can edit the g limit in the part config but there's a secondary value that kicks in to prevent transmission within 1.25 planetary radii. That was intended to give Gilly and some of the smaller Joolian moons a meaningful exclusion zone. That value is applied in the source code, so it would require an edit and recompile. I'm uncertain since it's been a while, but I want to say that you'd also have issues transiting if either vessel is in a LANDED state, since there's a few bits in the code that reference t
  2. The Heisenkerb Compensator may be of particular interest.
  3. What page is that on? I can't find anything that seems to contradict your usage window stats. The wiki reads: Which is more-or-less true - unless you're playing with multiple stars you're not going to run into the upper limit on the IB-1 beating out the LB-100. Perhaps change "long-range" to "interplanetary", leaving "interstellar" as the province of the LB-100? Let me know. Also, did you change it so the IB-1 can't be used as a target anymore? I seem to remember seeing that somewhere. Let me know if that's the case and I'll correct that part too.
  4. Fun story, that was actually the original use case - I was getting a headache imagining how long multiple flights for base building and resupply for a USI Laythe base would take. Something about having to forward through that much time again and again always sets my teeth on edge, because then you have to run concurrent resupply flights for your other bases or just make sure they're all sustainable/unpopulated before you do the timeskip.
  5. Yeah, that's probably on me. Perhaps showing some of the visual aids from the wiki on the first post would help? I feel like the github wiki is actually relatively complete, just problematic in that nobody reads github wikis.
  6. The mechanic is that the higher mass increases the effectiveness of the GMU. If you build a class-e asteroid into your station you can run your LB100 in low Eve orbit. The EC cost offsets this advantage. 1500 tons is the target heavy mass I used when calibrating it.
  7. I am, but if you got it to spit out a valid bodies.ini file with that modset then I should be able to use that in lieu of generating my own. Do you happen to have it still?
  8. I don't see any obvious error messages but I'll include a full dump of the log it made during the attempt: [LOG 17:19:21.187] [KSPTOT Connect] accepted connection [0] from IP: 127.0.0.1:53429 [LOG 17:19:21.188] [KSPTOT Connect] new connection [LOG 17:19:21.259] [KSPTOT Connect] [CONNECTION][0][READING] received complete message head [LOG 17:19:21.259] [KSPTOT Connect] [CONNECTION][0][READING] data Size: 0 [LOG 17:19:21.260] [KSPTOT Connect] message from [0]: GetCelestialBodyData n 0 [LOG 17:19:21.261] [KSPTOT Connect] about to handle msg [LOG 17:19:21.265] [KSPTOT Connect] Start Body: Sun
  9. Sure, the sequence is: Install ModuleManager (bundled with most of the following mods). Install Kopernicus. Install Real Solar System Install Sigma Binary Install Real Solar System Expanded I was able to pull a successful bodies.ini with the first three (plus other likely inconsequential mods) installed, but after installing the latter two I was not able to make it work.
  10. I know this is sort of an edge case, but I thought I'd post it here even so. I'm running RSS, which posed no issue with the bodies.ini export until I also added the RSS Expanded pack. This pack adds a whole ton of new bodies and makes a few modifications to existing ones. With this pack, three systems are turned into binary objects - Pluto/Charon, Orcus/Vanth, and Ida/Dactyl. The KSPTOT export is failing, and I believe it is failing due to how these are implemented in the mod. The systems are modeled as being within the SoI of a barycentre, which is a dummy object. There are three baryce
  11. Since I'm in a configuring mood, I've also made some edits to the various flyby contracts: Fixed the displayed/required altitude to better suit the smaller SoI of various bodies. Contracts for flybys now have altitudes appropriate to historical flybys if one occurred (although some I had to alter since NASA gets really close on their maneuvers sometimes) Changed the contract completion prerequisite for Neptunian moon flyby contracts to be Neptune, not Jupiter. Changed the prerequisite for Makemake to be a Neptune flyby rather than Mars. Added the missing flybys fo
  12. Awesome mod, thanks very much for all your work in compiling this and thanks to Guswut for the unofficial patch. At the risk of descending deeper into unofficial patchception, I've further patched Guswut's files for the nine moons of Jupiter and Saturn which had SoI radii smaller than they were. I somewhat arbitrarily set the SoI radius to be 3x the planetary radius. https://www.dropbox.com/s/b5a1kiolr39h68t/RSSESOIPatch.zip?dl=0 Those go right into the GameData/RSSExpansion folder and overwrite the existing files.
  13. I think you'd be surprised - most of the farTargets calls are only referencing the vessel, so the beacon is just there for the ride. There are two instances where the beacon is fetched from the list directly, at lines 482 and 302-306. If you package that nested foreach function where you iterate through the parts and their constituent modules into a function all of its own for general use, not only should it make it easy to provide those beacons at all three access points (the third being the farTargets population function) it probably will work better for the scenario where multiple beacons
  14. Gravity well shouldn't make a difference, the list should be a full inventory of active non-self beacons and would then show blocked transfers as such. I suspect that the problem stems from a change to the target generation code that DBooots made to resolve a key duplication error - he predicted the possibility in a comment. The comment is line 173 in ESLDHailer.cs. This in turn seems to reflect a tendency by KSP to treat two distinct parts as identical in some cases. I have a sneaky suspicion that it has to do with some generalization it's making as part of performance optimization for unloa
×
×
  • Create New...