Jump to content

GP_LeChuck

Members
  • Posts

    24
  • Joined

  • Last visited

Posts posted by GP_LeChuck

  1. Solved! It appears that the scienceMultiplier value needs to be a whole integer. I tried it at 1, 1.5, and 2, and 1 and 2 worked fine while 1.5 reverted to the 5x amount. Would have done additional testing, but given that my KSP takes about 5 minutes to boot up after every file change, I decided to call it a day early! I wonder if there's something coded in to ensure only whole numbers of science get created. In any case, the problem seems to be solved for me for the time being. Thanks!

  2. Hi everyone,

    A couple years back, I posted this thread asking how to reduce the data to science conversion in the mobile processing lab. I got a great reply by @4x4cheesecake which worked perfectly on whatever version I was running at the time (~1.6?). Several years later, I've reinstalled KSP and attempted to carry out the same fix but can't seem to modify the conversion rate to anything other than 1 data > 5 science. 

    Here's the relevant part of my current LargeCrewedLab.cfg (relevant line in bold)

    Spoiler

    MODULE
        {
            name = ModuleScienceConverter
            dataProcessingMultiplier = 0.5 // Multiplier to data processing rate and therefore science rate
            scientistBonus = 0.25    //Bonus per scientist star - need at least one! So 0.25x - 2.5x 
            researchTime = 7        //Larger = slower.  Exponential!
            scienceMultiplier = 1.5    //How much science does data turn into?
            scienceCap = 500        //How much science can we store before having to transmit?        
            powerRequirement = 5    //EC/Sec to research
            ConverterName = #autoLOC_502055 //#autoLOC_502055 = Research
            StartActionName = #autoLOC_502056 //#autoLOC_502056 = Start Research
            StopActionName = #autoLOC_502057 //#autoLOC_502057 = Stop Research
        }

    I suspect I'm probably just doing something really boneheaded like accidentally editing the file to a different modded install or similar, but after at least an hour of troubleshooting I haven't had any luck. Thought I'd ask on here to make sure there  wasn't some change between versions that make this step no longer work!

    Thanks!

  3. I've been creating 9m parts by copying the 5m file (GameData/SquadExpansion/MakingHistory/Parts) and setting "rescaleFactor" to 1.8 (5 x 1.8 = 9). This has worked relatively simply for fuel tanks, engine plates, etc. and so far I haven't managed to anger the kraken, but it looks like fairings are a bit more complicated. Changing rescaleFactor makes for the right base width, but the fairing shell sections themselves don't increase in size, leaving large gaps. I can post a picture if necessary.

    Does anyone know what values I would have to change (working from the fairingSize4 file) in order to make the shell sections line up? I assume it's likely something under  the ModuleProceduralFairing section, but since trial and error would result in a lot more time looking at my KSP load screen than ideal, I wanted to see if anyone on here could offer some pointers. I also assume there's some sort of modder's tutorial out there with the answer that I've overlooked, so pointing me in that direction would be great as well.

    Thanks!

  4. I'm working on replicating Starship in RSS (using SMURFF rather than RO, so essentially just stock + expansion parts) and I'm having trouble getting much precision out of the control surfaces on descent. So far I've been using delta wings and wing connectors in conjunction with hinges to form the fins, and what I would really like is the fins to automatically adjust in conjunction with SAS to keep the orientation of the craft. I tried assigning the appropriate pairs of hinges to pitch/roll/yaw, but since axis groups don't work with SAS, I'm stuck making manual adjustments with WASD/QE. Maybe I need to just work on my piloting skills (virtually 0% of my play hours have been devoted to flying planes) and/or adjust some settings in the axis groups (where I can't say I have a super thorough understanding of all of the options, e.g. incremental vs. absolute control), but it seems like this manual input leads to a lot of overcorrection and the whole thing spiraling out of control. I've had more success with assigning each hinge to different action groups and just toggling the fins forward and back--i.e. if I notice the nose starting to pitch forward, I tuck the bottom two fins away and leave the top two out. This works pretty well for the majority of descent through the atmosphere, but once it gets thick enough (let's say around 50-60km when deorbiting), things start to get a little out of control. Toggling any one of the fins at that point tends to just make things worse, so I just say Jeb take the wheel and pray the tumbling flaming carrot of doom doesn't explode into a million pieces.

    Again, the ideal solution for me would be to have the hinges make automatic, minute adjustments in the manner of RCS/SAS, but I'm not sure how to make that happen. What sort of suggestions do people have to make for a pretty, stable belly-flop rather than a whirling mess? Should I make my fins out of control surfaces like elevons instead of BG robotics? Do I need to be looking at aerodynamic design/COM issues? Should I just load down the ship with reaction wheels and pretend my fins are doing the work? Is there a chance my angle of attack is wrong (I've been holding Radial Out; maybe I need to shoot for like halfway between there and Prograde?). I've seen a couple Starship recreations on YouTube and their descents more or less seem to work properly, but I'm not entirely sure how they're controlling the fins--if there are any tutorials out there, I'm more than happy to just plagiarize their ideas!

  5. 10 hours ago, AHHans said:

    Not a full solution. You can mitigate this by locking the robotic parts and having autostruts that bind parts on both sides together, but it doesn't go completely away. Sometimes it is also possible to "reset" the parts by unlocking and locking while there is no load on the parts. (E.g. when flying or in orbit.)

    Thanks for the advice, I'll give that a shot. Are there any other exacerbating factors that I should look to avoid in order to mitigate the effects? @Scoopapa mentioned gravity in the OP, although I have to say my latest experience with it is on Phobos in RSS, which is about as low of gravity as you can get. I'm a little bummed at this bug, and I might just swear off robotic parts entirely for anything that's going to touch the surface.

  6. Edit: The solution was as easy as tinkering with spring/damper settings :/ Mods can feel free to delete this thread!

    I am playing RSS, and with the help of Global Construction I've built a 6.6 ton, 10-wheel rover on the lunar surface. Unfortunately, once the rover is deployed, it
     begins to slide around. I can use the wheels to control it and reduce the speed for the most part with brakes, but I cannot bring the vehicle to a complete stop (about 0.3 m/s minimum), and when driving, the direction of orientation seems to make no difference: essentially, I Tokyo Drift around, regardless of which direction my wheels are pointed.

    I've driven smaller rovers on the moon without difficulty, and by replicating the problem at KSC by hacking gravity down to .16, I've determined it must be a gravity issue rather than anything specific to the moon itself. I also don't think it is related to Global Construction, as I cheated a fresh, VAB-built rover down to the lunar surface and had the same issue. I also have done some brief experimentation with applying some downward thrust near the center of mass while braking to bring the rover into better contact with the ground, and although I haven't gone all out and experimented with huge engines, reasonably-sized ones haven't seemed to have helped; the rover still refuses to come to a complete stop. Ultimately, I assume it's a question of distributing too little mass over too many wheels or something similar, but I wanted to see if this is a known problem with any solutions. I can provide a list of installed mods, craft file, etc., if this would help.

    Thanks!

  7.  

    On 11/22/2019 at 12:11 PM, GP_LeChuck said:

    Question for a 1.7.3 install: I used a kit to assemble a rover on the moon (using RSS), and upon deployment, the rover begins to slide around. I can use the wheels to control it and reduce the speed for the most part with brakes, but I cannot bring the vehicle to a complete stop (about 0.3 m/s minimum), and when driving, the direction of orientation seems to make no difference: essentially, I Tokyo Drift around, regardless of which direction my wheels are pointed. Any recommendations?

     

    On 11/22/2019 at 3:20 PM, allista said:

    I've experienced something similar with Hangar, when a rover is spawned. Haven't been able to pin the cause, except that it's linked with physics and wheel collides; but what helped me is switching to another vessel out of physics range (via the map), or a round trip to KSC and back. Time warp may also help, but I'm not sure.

    In any case, I'd like to see the logs; maybe it's just some uncaught exceptions mess up part modules...

    Update: After playing around with hacked gravity at KSC, it appears this may be a gravity/wheels issue and not have anything to do with kit spawning/Global Construction. When spawning the rover in question from the VAB, it drives perfectly fine under Earth gravity, but hacking it down to lunar levels at .16 replicates the sliding issue. This does seem strange, as I've successfully driven rovers on the moon before, although this one is larger (6.6 tons) and has more wheels (10), so there's likely some non mod-related issue that I'll have to figure out. In any case, obviously if anyone has suggestions, I'd love to hear them, but I don't want to waste @allista's time/clog this thread with non-GC issues, so consider it resolved!

  8. 17 hours ago, allista said:

    I've experienced something similar with Hangar, when a rover is spawned. Haven't been able to pin the cause, except that it's linked with physics and wheel collides; but what helped me is switching to another vessel out of physics range (via the map), or a round trip to KSC and back. Time warp may also help, but I'm not sure.

    In any case, I'd like to see the logs; maybe it's just some uncaught exceptions mess up part modules...

    Thanks for the feedback. Neither time-warping nor heading in and out of the tracking station seem to help, unfortunately. Here's a copy of the output log--I actually haven't used these before and don't know how to read them so hopefully I got the right thing: I loaded a save just before launching the completed rover from the kit, launched it and let it roll around a bit, then paused and used NathanKell's stickied guide to grab output_log.txt (I didn't shut down KSP first or anything in case that's needed to update the file).
     

  9. Question for a 1.7.3 install: I used a kit to assemble a rover on the moon (using RSS), and upon deployment, the rover begins to slide around. I can use the wheels to control it and reduce the speed for the most part with brakes, but I cannot bring the vehicle to a complete stop (about 0.3 m/s minimum), and when driving, the direction of orientation seems to make no difference: essentially, I Tokyo Drift around, regardless of which direction my wheels are pointed. Any recommendations?

  10. 17 hours ago, Scorpu said:

    @GP_LeChuck Are you playing with stock physics or with Principia? With stock physics, because of the way Real Solar System simulates Earth's axial tilt (by tilting the entire Solar System by 23.5 degrees), axial tilt of every other body including the Moon, is completely wrong. This causes the Moon to have polar days and nights just like on real Earth. So it's not actually possible to have 'peaks of eternal light' on the Moon when using RSS with stock physics. You'll get about half year of light and half year of darkness when you land in the right spot near one of the poles. Prinicipia adds n-body physics and though I'm not sure exactly how, the creators of this mod managed to implement proper axial tilts for every planet and moon.

    @Scorpu Thanks for the reply, that must be it! I'm ashamed to admit it, but after several successful moon landings with Principia I found myself missing the clean interface of the stock maneuver node and switched back. I had no idea Principia did anything with planetary bodies themselves--I figured that was all covered under Kopernicus/RSS. I may have to consider re-installing Principia now...

  11. Has anyone managed to find a spot on the Moon's south pole which receives substantially more sunlight than along the equator? I'm looking for a place to establish a base with near-continuous access to sunlight as has been proposed for the Shackleton Crater. I'm playing with the 2048 textures and have found that the sun dips pretty far below the horizon for a significant period of time in all the locations I've explored, making me think I'm better off just building at the equator due to the ease of landing there. 

  12. I managed to solve my earlier problem with the DIY Kit, but I am now struggling to figure out how to store Material Kits. Is there any component included with this mod which stores them? I'd like to keep things as lightweight as possible, so if there's any way to build directly from ore that'd be ideal, but if I need to download some sort of material kit storage container, where do I do that? Is Configurable Containers the best solution?

  13. 1 hour ago, DareDrop said:

    You need the Ground Kit Container not the Dockable Kit Container. The Dockable Kit Container
    is just for use in space to build a kit. The Ground Kit Container is used in the VAB.

    Right click on it and, select the menu option, select vessel, load it, and you are good 
    to go. Now you have to move it to an assembly area to build it. 

    Dockable Kit Container is build the kit and then assemble it in space.

    It confusing, i know and so is the UI.

    Sorry, I wasn't clear--the issue I'm having is actually with the Ground Kit Container itself. Choosing a ship from the "Select Vessel" dialogue seems to cause the game to hang up by not letting me click on anything else, meaning I have to Alt-F4 to get out of KSP. Selecting subassemblies or parts doesn't cause this same error, although these don't seem to work properly either--rather than the kit updating according to its contents, the selected part/subassembly just spawns nearby as if it were another part on the ship. I'm assuming it's some sort of mod compatibility error, although I'm also running 1.7.3 with Breaking Ground if either of those have been known to cause any problems.

  14. I just installed this mod am excited to get it working, but am having some trouble. Specifically, when I try to pack something into the DIY Kit in the VAB by clicking Select Vessel, after choosing the ship, nothing happens and almost everything in the VAB becomes unclickable and I have to shut down KSP. I can still right-click on the DIY kit and see that dialogue, as well as a couple random buttons around the VAB (e.g. I can click "Switch Editor" but can't move between the Build/Crew tabs). I'm hoping this has a simple answer and is just a case of me being dumb and overlooking something obvious, but I also wonder if it is a mod compatibility issue. I currently have installed:

    Simplex Tech Tree
    Bon Voyage
    KAS
    RSS and dependencies including Kopernicus (<- from a post a couple pages back, I wonder if this is the issue)
    SMURFF
    Snacks!
    World Stabilizer

    I was looking forward to some way to ship things into orbit at a lower weight and then construct them off planet and will be bummed if this mod doesn't work with my other ones. In any case, if anyone has any suggestions that would be terrific!

  15. Are there any modifications to ore percentages in RSS? I scanned the Moon and found a measly ore concentration of 1.1%, and the resource overlay from the survey scanner doesn't show any concentrations of ore whatsoever. I thought maybe this was a display bug and tried landing a mini-drill at the south pole (where I think most real life plans for ISRU production are) but got a message along the lines of "No resources to be harvested." Is this intentional? If not, is there any place I can go in the code files to either find out what parts of the moon actually have that 1.1% (since the colored overlay doesn't show me anything), or to increase the percentages? Thanks!

  16. On 8/5/2019 at 8:02 PM, Starwaster said:

    It's a matter of creating a set of ROC_DEFINITION configs with appropriate Frequency values so that they spawn in appropriate numbers that won't tank your CPU or FPS. There is an issue which aggravates performance issues when on oceanless bodies that Kopernicus will address in a later update.  (note actually related to the ROC issue but the issues compound each other)

    Also, RSS would require a set of terrain quality settings appropriate for each planet; I think there was talk about that happening.

    Finally, there's a value in each player's settings.cfg which would probably have to be modified to an appropriate value to further inhibit unwanted ROC spawning but it's not patchable by ModuleManager so would have to be set by the player or possibly by plugin... I've thought of proposing such a change for Kopernicus but haven't had a chance to put together the request. (I'd want to be able to suggest a precise course of action)

    So, TL;DR it's totally doable and a player could probably even do it on their own but in the absence of an official solution (which is doable) would have to deal with performance issues on their own as well.

    Hmm that does sound a bit outside my ability range (although if anyone is familiar with any tutorials, I'd love to hear it!). I assume that this is the reason Kerbnet scans don't work either?

  17. On 7/22/2019 at 5:50 PM, Starwaster said:

    You know, I broached that very subject in the RO Discord channel  and the response was lukewarm at best.

    That aside, Kopernicus has some issues that can in certain circumstances result in tremendous loss of performance  by enabling surface features (their proper term so as not to confuse them with terrain scatter) under circumstances in which they should not spawn and in quantities greater than they should spawn. So far the only viable workaround is custom terrain quality settings that can reduce the range at which they are created and by reducing the number of them created. That unfortunately tends to spread them over a wider area which makes the rarer ones harder to find. 

    I take it from this that there's no way to get Breaking Ground surface features (i.e. those used with scanning arms) on RSS planets? I just want to confirm this is an RSS limitation and not something resulting from some strange combination of mods I have installed. 

  18. Hi everyone,

    Is there any way to reduce the science output from data in the mobile processing lab? As far as I understand it, every 1 unit of data generates 5 science, and I would like to reduce this to 1:1 or at most 1:2. I'm fine with the time needed to process the data, and I even like the modifiers applied to data generation which mean that you could generate more data when processing it in a lab than bringing it home, but I'd like to cap the increase so it's a moderate improvement over shipping the data home rather than something that makes me swim in science. Is there a mod to do this, or an easy way to edit the game files?

    Thanks!

×
×
  • Create New...