Jump to content

TheBok

Members
  • Posts

    26
  • Joined

  • Last visited

Posts posted by TheBok

  1. 1 hour ago, TheBok said:

    Heyas, thanks for this epic mod :D

    I've just come back after some time away, am running 1.6.1 + RSS + 1.2.0.0 USI.

    I'm about to start putting up a huge space station, but can't see how to "start habitat" for any modules like back in 1.3.1, and the HAB timer is much lower than I thought it would be. Do I need to turn this functionality on now?

    PS: Also, none of my Space Station Expansion Redux (am using 1.1.0) parts seem to have recyclers, or any HAB time at all :(

    Alright so I played around a heap with different versions of Station Parts Expansion Redux and USI. Despite SPXR 1.2.0 being shown on CKAN as incompatible with 1.6.1 (I use 1.6.1 because RSS) it seems to work fine (with USI 1.2.0.0), so far anyway, and the problems above seem sorted now.

  2. Heyas, thanks for this epic mod :D

    I've just come back after some time away, am running 1.6.1 + RSS + 1.2.0.0 USI.

    I'm about to start putting up a huge space station, but can't see how to "start habitat" for any modules like back in 1.3.1, and the HAB timer is much lower than I thought it would be. Do I need to turn this functionality on now?

    PS: Also, none of my Space Station Expansion Redux (am using 1.1.0) parts seem to have recyclers, or any HAB time at all :(

  3. PLAD dude you should know that this mod is amazing, and you should feel good.

    I am wondering if you know of any practical solution to determining parking orbit LAN, or something, other than using the test vehicle in equatorial, setting maneuvre node, and launching by eye into that orbit? I don't use MechJeb so the addon isn't really an option for me. I actually somehow am finding the eyeballing launch into the maneuvre node method not too difficult, but it is a little time consuming and messy and just wondering if you've found any other practical solutions.

    Thanks again for your epic work on this mod.

  4. TLDR - Some moons seem messed up. I made github issue. Nevermind me.

     

    Apologies if my two posts earlier wasted anybody's time, my observations listed there concerning Saturn's moons were flawed and honestly it has taken me a good while to figure out what is actually happening.

    I have made the following observations on both my 1.3.1 and 1.6.1 installs.

    Enceladus: Surface is like, east/west reversed when compared with reality. Linear surface features can be observed to be pointing north west when in reality they point north east, etc. Compare images from wikipedia vs ingame to see what I mean - all the lines are backwards. Can't tell what's going on with the biome map here.

    Dione: As with Enceladus, surface features are east-west reversed. Biome map is way off but I can't figure out exactly how.

    Rhea: As above, features are east-west reversed. Biome map is... not correlating with the surface.

    Titan: Can't see jack. No useful observations.

    Iapetus: This one threw me at first. The surface features here are actually completely correct, but the Biome map seems rotated around the axis of rotation by 180 degrees - showing the Turgis crater on the biome map over the lighter side of the moon. This one is super, super weird. Detailed observations at bottom of post.

    Tethys + Mimas: surface features are correct relative to reality, but the biome map has been flipped around the equator; that is, longitude of surface features match the biome map, but latitudes of the biome map have been flipped from north to south.

     

    Apologies for the wall of text. Might anybody else be able to verify any of the above for me? I don't see any problems with any other moons on either install - Uranus/Jupiter's moons are all fine, they match their biomes and RL maps.

    EDIT: I take that last line back - Jupiter's moons do not seem fine on either install. Observations across both installs match and are listed below.

    Io: Has surface features east-west reversed as per Dione/Enceladus/Rhea above.

    Europa: Perfect. No problems here, matches reality and biome map.

    Ganymede: As Io, has east-west reversed. Surface features running east in game that should run west etc

    Callisto: Perfect, matches reality and biome map.

     

    Ok it's nap time. Will look at Uranus moons also but the first I looked at was fine in all respects.

     

    Another EDIT: Just installed a completely fresh 1.3.1 with only RSS and Kopernicus, all above observations repeated and confirmed.

     

    ANOTHER edit. BOTH of my observations on Iapetus were wrong, this one is HELLA WEIRD! What a mind... cluck this has been.

    Iapetus surface matches reality, but the only way the surface of Iapetus matches the biome map everywhere, is if you flip the biome map around the equator, like described with Mimas/Tethys. But the red biome (named Turgis) is the exception, it does not actually line up with the Turgis crater, it's been either misnamed or misplaced. Once the biome map is flipped 180 around the equator, everything looks great, except the existing red biome needs to be renamed to "Engelier" because that's the name of the crater it is then on top of, or it needs to be moved to the actual Turgis crater. which is over the other side and on the opposite hemisphere.

     

    omg do I get a cookie? I think I have low blood sugar

     

     

  5. Ok so I went back to a fairly old 1.3.1 install, and Saturn's moons are all upside down on there as well! Is the problem

    a) somebody laced my coffee

    b) I am a rookie who has messed up both of my installs

    c) RSS has had upside down saturn moons for some time without anybody (including me) noticing XD

     

    And before you say it, yes I do live in Australia, and no this does not explain the problem.

  6. Hi and epic work on this great mod.

     

    I am running 1.6.1 and have noticed that the biome locations for Saturn's moons don't seem to match up with the surface - easily noticeable by looking at Iapetus or Tethys and hitting "Biomes Visible from alt-f12 .It's apparent at Tethys where the major crater feature is visible on the northern hemisphere but the biome shows as being on the southern hemisphere. Iapetus' large impact crater is also visible in the opposite hemisphere to what's shown on the biome map.

    It seems that the moons themselves have had their surfaces flipped upside down, or something - as the north pole biomes are correctly at the north pole and vice versa, but the surface features themselves are flipped around the equator. This theory seems supported by the observation of Mimas' large equatorial crater being in almost exactly the correct position but other surface features also are flipped around the equator.

    Or maybe it's just me?

  7. 1 minute ago, IgorZ said:

    Grab the part, then click "R" until you get "surface node". This type of the nodes is not aligned to the target. Then use A/S/D/F to adjust the part rotation. All this stuff is mentioned in the hover menu when you're carrying a part (which some people trying to convince me to deprecate).

    If the part doesn't have a surface node (there are some), then you simply cannot do anything. That's a limitation of KIS.

    Thanks for yer prompt response - yar I've been using this mod for ages so was a bit stumped. I can of course see the popup window with all available commands, and went through all of them with both wrench and screw equipped - there is no "surface" option when cycling R that I can see. Am attaching to an octo-girder modular truss I guess it has no surface option?

     

    But that's no probs I can easily send up a new skycrane, thanks again for answering good sir! Excellent mod o7

  8. Is it at all possible to attach a part to very nearby, but not quite ontop of, a node?

     

    I'm trying to replace the HW-80 winch on a skycrane, but for the cable itself to be centered on the vehicles CoM, the winch needs to be offset slightly from the node on the grandparent part - if I use a wrench it refuses to attach anywhere, but if I use the electric screwdriver it will snap to the node and doesn't seem to allow offset. Is this just a limitation or am I missing something?

     

    I did attempt to search this thread and the forums for this but couldn't find anything, apologies if it's a super simple solution.

  9. On 2/8/2019 at 5:40 AM, lBoBl said:

    I have an issue where after some time with the game open and a few save/reloads, sometimes the trajectories GUI window refuses to open

    Has anyone experienced the same problem ?

    Yar I also have this problem, deleting the config file and restarting the game seems to fix but it tends to happen regularly.

    I get the feeling the popup window isn't de-activated, just hidden out of frame or something, as often it is inexplicably moved to halfway off my screen, it's a bit weird.

  10. Heya and many thanks for this epic mod.

     

    I'm running DeepFreeze with 1.6.1 and RSS + many others. When EC required to run tanks is enabled (though with temperature requirement disabled), I see a hugely fluctuating EC usage from the freeze tank as you can see here https://www.twitch.tv/videos/372516431?t=04h03m16s though please excuse my naughty words.

     

    Note the "Current EC Usage" on the freezer fluctuating along with the current usage at the top right.

     

    Just now I set DeepFreeze to extra debug logging, and setup a Freezer/Battery/Solar/Probe on the launchpad, froze me some kerbals and wanted to post the outpug log here but not sure how?

     

    Thanks in advance for any help o7

     

  11. 22 hours ago, Kerbas_ad_astra said:

    Procedural Parts and Interstellar Fuel Switch jump out at me as possible culprits (SMURFF has patches that interact with those mods, but it's been years since I used Procedural Parts and months since I've used IFS).  I'll do some tests this weekend, but you're welcome to do your own testing if you want results sooner.

    I removed IFS and the MRS tanks are now fine, all of them it seems, tho the two SpaceY fuelled nose cones remain vanilla.

  12. 1 minute ago, Kerbas_ad_astra said:

    Procedural Parts and Interstellar Fuel Switch jump out at me as possible culprits (SMURFF has patches that interact with those mods, but it's been years since I used Procedural Parts and months since I've used IFS).  I'll do some tests this weekend, but you're welcome to do your own testing if you want results sooner.

    Thanks for reply man, I'll try removing them one at a time and see if that changes anything, anything else useful I can provide?

  13. On 1/27/2019 at 1:30 AM, Kerbas_ad_astra said:

    That, or using the information box that pops up when you mouse over the part in the editor.  I don't have that problem when I just install SMURFF and SpaceY on my test install, so I need more information about what mods you have.

    Also I have just noticed that some SpaceY nose cones are fine, some aren't. The BFT 07C 7.5m and F05C 5m nose cones are still showing vanilla mass fractions for me in the VAB, tho the others seem fine.

    All of my MRS LF/O tanks remain on vanilla mass fractions also.

  14. 19 minutes ago, Marandil said:

    Have you checked the actual mass, or just the numbers in the parts menu? I had a problem where several tanks reported their original mass in the parts menu, but SMURFF'd one in "part info" (I think it is a KER extension, but dunno). 

    Long story short, just verify this first ;)

    I am checking these by placing one down in the VAB and then middle clicking to bring up the KER tooltip thingy, and looking at dry/wet mass. Is that the right way of going about it?

  15. Heya and huge thanks for your work on this.

     

    I've just made a new 1.6.1 install w/ RSS+SMURFF and about 70 mods total, and have just found that the MRS tanks seem to all be unaffected and remain at vanilla dry mass fraction. Also the SpaceY fuelled nose cones are exhibiting the same problem. No other tanks, including all other SpaceY tanks, have this issue and seem to have been successfully SMURFF'd.

    Should I provide a mod list or log? Apologies I am noob.

  16. 2 hours ago, jrbudda said:

    For anyone interested in this RCS thing:

    The RCS calculation is done via a mini-simulation. It's done twice per stage: before and after the stage simulation. It's kinda like a hypothetical 'what if I burned all my rcs fuel now?' thing. This is why, in the VAB screenshot, there's 2 values per stage for TWR and DeltaV, the first value is the start of the stage, the (second) is the end of the stage, after burning all the 'normal' fuel, but before staging.

    And since it's a simulation, it works with RCS modules no matter what propellant. I've only tested the stock ones with mono and vernor engines, but it should handle any mod part with any fuel type(s) so long as it's a ModuleRCS.

    The burn time is highly inaccurate since it's very hard to actually fire all the rcs engines at once at full blast.

    I may add RCS Torque to the calculations if I can make it meaningful. Open to other suggestions.

    Awesome man.

    Where you mention the burn time is inaccurate, would that apply to the RCS Thrust shown in the second picture too?

    Also if you were going to add a torque readout, I guess it'd have one for each axis so I guess adding thrust in all 3 directions too would be pretty amazing.

    In saying that I think having torque/thrust on-hand during flight isn't useful for too many situations I can think of, but I could be wrong and it would still be cool! :D

  17. 40 minutes ago, jrbudda said:

    KER does nothing with RCS as far as I can tell. Shouldn't be too hard to add, just have to be careful around vernor engines and mono-burning non-rcs engines.

    That would be amazing :D I believe that mono burning non RCS engines currently do show delta v in KER - at least it does with the few I tested. I was using such engines in the past to estimate my dv's in the VAB before I discovered the delta v function in RCS Build Aid. Not sure about vernor engines as I've barely used them.

×
×
  • Create New...