Jump to content

Motokid600

Members
  • Posts

    3,858
  • Joined

  • Last visited

Posts posted by Motokid600

  1. Forgive me if this is a FAQ, but ive not been able to find info on it. Using the rugged wheels Im getting stuck in the terrain. Collision works. But its as if Im running into a run-away truck ramp as soon as I leave the runway. Craft quickly comes to a halt and gets stuck. Steering doesn't work. Ill work on a log asap if need be encase its not a frequent question.

  2. Same issue here. All stock. Game is hemorrhaging NRE's. Was hoping landing would fix it... nope. This is a SIX YEAR OLD BUG. >.< I remember dealing with this six years ago and there are even threads going back that long asking about it. 1.11 is the first time ive played stock in years and its good to know 90% of the bugs ive been tackling in my modded installs were all stock issues. One of the buggiest KSP experiences ive ever had so far. Zero mods. XD.

  3. 10 hours ago, Gameslinx said:

    It'll be fixed in the next BH update, but if you want to do it yourself:

    For every planet (except Kerbin), change the template to Eve if it has an atmosphere. If it does not, change the template to Minmus.

    The planet configs can be found in BeyondHome/Configs, and the template section is near the top

    Ill have to wait for that update, thank you. I did try that fix awhile back and it really messed up the lighting and terrain textures for some planets. Mostly the lighting. It was as if everything was in a perpetual eclipse.

  4. I found this in the change log.

    * Implement new Max Time Warp logic to allow faster warp rates when on rails. This is managed by gamesettings (ORBIT_WARP_MAXRATE_MODE = PeAltitude).
    * Implement Limit modifier for altitude based Max Time Warp logic so players can tune when the mode is set to (ORBIT_WARP_MAXRATE_MODE = VesselAltitude).

    How can I use this to revert to the old time warp logic? I prefer the slower pace at lower altitudes and it's causing overshoot issues with mechjeb burns.

  5. This mod really throws me some curve balls it seems. I have an odd issue. Two planets with identical comm setups. A main talking to home then using omni for local comms. Two identical scan sats for each planet using omni antenna to talk to the main relay. Same builds. All is in range. Only one works... How? Only one receives signal. The scan sat at the other planet works. The kicker is everything says connected. On the one that works I can see the connection line to home from the scan sat. On the one that does not work the connection line is not there unless the relay is the active sat.

    Edit: Okay... it seems to be intermittent. The home signal will return periodically when its not an active vessel. However when its active the connection is constant.

    Edit: Intermittnet turned into not at all. Power is good. I have the master satellite back at home set to active vessel. Can one antenna only support one craft at at time or something?

  6. 3 hours ago, hemeac said:

    Sorry if I haven't followed all of your previous posts, but when you rescaled, did that also rescale any existing light intensity curves?  JNSQ which is 2.7x stock scale seems to have that issue and there doesn't seem to be a current solution:

     

    I used Sigma DImentions for the rescale. I only edited base settings.

    	// Advanced Settings
    	
    	landscape = 1
    	geeASLmultiplier = 1
    	
    	resizeScatter = 1
    	resizeBuildings = 0
    	groundTiling = 1
    	
    	CustomSoISize = 0
    	CustomRingSize = 0
    	
    	atmoASL = 1
    	tempASL = 1
    	atmoTopLayer = 1
    	atmoVisualEffect = 1
    	
    	lightRange = 1
    	
    	scanAltitude = 1

    The advanced settings are unchanged, but there are some interesting ones now that I look at them. "groundTiling = 1" Related to the checkerd pattern im seeing on the surface? And "lightRange = 1" which maybe is related to what you mentioned there? Also to which issue are you referring? There's two, but only if a fix for the first is applied. The big one is the checkered pattern on the surface of every moon. However when attempting to fix that via the template name change that causes the lighting issue.

  7. Ill have to bump this as well. Experiencing the SAME exact checkered pattern on bodies in Beyond Home. I was wondering if the 2.5x resale was the culprit. Maybe not. I tried this fix mentioned by Hohmannson. " Temporary and unsupported fix is to go through all planet configs and change template = Laythe to template = Eve and template = Tylo to template = Minmus." That did solve the checkering issue, but it broke the surfaces where they didnt receive sunlight. Will try what R-T-B mentioned next change I get.

  8. On 8/2/2020 at 7:40 PM, Hohmannson said:

    It changes the Kopernicus template of planets. For Beyond Home it means nothing, because all the planets in pack are stripped off all their properties and are created from scratch. But. Tylo and Laythe templates used for most BH bodies are currently bugged because of Squad`s unfinished revamp, causing the checkers to appear. So replace them(Laythe to Eve, Tylo to Minmus), clean the Cache folder in BH directory and you`ll be fine. Well, worked for me at least.

    So weeks after doing this I noticed an issue with lighting. Upon making this template name change it seems certain bodies no longer receive sunlight. As if they're stuck in a permanent eclipse. Any ideas? And again is this the 2.5x rescale that's causing the checkering issue? Ill consider removing it and going stock scale if so.

  9. Im wondering if I can use this to better analyze SpaceX style launches. As of now flight trajectory and MECO timing is my best guess based on payload mass. But then my booster lands with 300+ Dv :P. Id like to assemble a data set to make better judgment when it comes to said trajectory and timings. A way for me to go back and look at altitude, speed and I suppose acceleration for MECO times.

×
×
  • Create New...