Jump to content

Search the Community

Showing results for tags 'ksp2br-v0.1.1'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP2 Dev Updates
    • KSP2 Discussion
    • KSP2 Suggestions and Development Discussion
    • Challenges & Mission Ideas
    • The KSP2 Spacecraft Exchange
    • Mission Reports
    • KSP2 Prelaunch Archive
  • Kerbal Space Program 2 Gameplay & Technical Support
    • KSP2 Gameplay Questions and Tutorials
    • KSP2 Technical Support (PC, unmodded installs)
    • KSP2 Technical Support (PC, modded installs)
  • Kerbal Space Program 2 Mods
    • KSP2 Mod Discussions
    • KSP2 Mod Releases
    • KSP2 Mod Development
  • Kerbal Space Program 1
    • KSP1 The Daily Kerbal
    • KSP1 Discussion
    • KSP1 Suggestions & Development Discussion
    • KSP1 Challenges & Mission ideas
    • KSP1 The Spacecraft Exchange
    • KSP1 Mission Reports
    • KSP1 Gameplay and Technical Support
    • KSP1 Mods
    • KSP1 Expansions
  • Community
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
    • KSP Fan Works
  • International
    • International
  • KerbalEDU
    • KerbalEDU
    • KerbalEDU Website

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


About me


Location


Interests

  1. KSP Version: 0.1.1.0.21572 Operating System and version: Windows 11 CPU and GPU models, any other system information which could be relevant: RTX 3070, i9-12900k Description of the bug.: Sun goes dark when you zoom into Gilly, Duna, Laythe, etc. (I didn't try all planets, sun seems to be fine when viewing Kerbin, Eve, and Moho for example) Expected Behavior: Sun should continue shining (fingers crossed) Steps to Replicate: Go to Gilly/Duna/Laythe/etc in the tracking station and zoom in A list of ALL mods: None Other Notes / Screenshots / Log Files (if possible..): https://imgur.com/a/Nz3u3EK
  2. KSP2 Version: 0.1.1.0.21572 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None How to Replicate: Put the attached zipped campaign into C:\Users\>EnterUsernameHere<\AppData\LocalLow\Intercept Games\Kerbal Space Program 2\Saves\SinglePlayer\ Load the KSCClearSave save file. Follow the steps I took in the following video (21 seconds): https://youtu.be/5xPzwIhlZmI Link to Campaign Folder: https://www.dropbox.com/s/nsijo42xalbceq2/GirderNodeStrutTest.zip?dl=0 More Information: Happens in different locations. If I launch a rocket and have it orbit the Mun and then launch another rocket the new rocket will be missing the physical strut connection on the Launch pad. Speculation: In game scenes are using the same identifier for physical struts as they were in the VAB causing a conflict that has all crafts after the first one not be connected.
  3. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Linux Ubuntu 20.04.6 | CPU: AMD Ryzen 5 3400G | GPU: NVIDIA GeForce GTX 1080 Ti | RAM: 16GB System Specs: Frequency: High (seems to happen every time) Description: Should a craft's docking port attach to another docking port on the same craft such that a loop is created in the underlying craft's structure the game will freeze I have attached a craft file that demonstrates this. Launch the craft and activate the only stage to drop the horizontal section. First one docking port will attach, then after some flexing the second will attach and at that point the game will freeze. It does this every time for me. Included Attachments: double_docker.zip
  4. I am not sure what causes it but often when building planes the wing control surfaces will work backwards at least visually, though sometimes making the plane unable to fly correctly without inverting them. I think it is more likely when adding multiple sets of wings though it sometimes happens with only one set. I am not sure if this guess is correct, but I think it sometimes is the wings getting confused about their position on the craft and whether to change direction by creating drag or pushing the air another direction. I was having issues putting in a screenshot but when trying to make my craft fly up on non-inverted wings, the main wings angle the control surfaces downwards creating drag in the wrong direction with the wings not being in a position to push the air another direction. On atleast 1 plane the effect was so strong I had to invert the wings or else the SAS wouldn't work and I would have to press the opposite button I intended.
  5. While orbiting Mun around 15K my PE and AP constantly change as though I'm gently thrusting toward the ground. It stops at any level of time warp but reappears at normal time scale. Definitely no thrust or RCS active.
  6. KSP Version v0.1.1.0 Operating System and version (Windows 10, Windows 11) Windows 11 CPU and GPU models, any other system information which could be relevant i7 12700F with RTX 3060 Ti Description of the bug. Expected Behavior SAS should not lose control of the ship when engine is burning fuel in any view. Observed Behavior Changing to MAP view while using any SAS option and the engine is burning fuel causes ship to lose control Steps to Replicate 1- Set any option on the SAS control; 2- Start the engine of the craft at any amount above zero; 3- Change the view to Map Fixes / Workarounds (if known..) - Unknown A list of ALL mods. If the list is long, please consider using a spoiler window. - NO MODS Other Notes / Screenshots / Log Files (if possible..) You can see the ship losing control as soon I change to MAP view at 0:14 and 1:07 of the video.
  7. KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None It's a regression because 0.1.0.0 seems to be working as it should but 0.1.1.0 and 0.1.2.0 are not. (video down further for difference) 0.1.2.0 Regression: I hit my YouTube upload limit but it is basically identical to 0.1.1.0 0.1.1.0 Regression: https://youtu.be/iv_0ekZ7rBg (38 Seconds) Things of note here are: Sounds have a delay before they can be heard. If turned off and on quickly the sound gets more and more delayed before its heard (with a quiet rumble sound) Throttling to zero then going to Map View then throttling to 100% the engines make no noise Going back to Flight View the sound is still missing but turning off and on in Flight View the sound returns with the delay Quicker Way of Just Having the Engines Quiet on Staging the Engines in 0.1.1.0 + 0.1.2.0: Load 0100SoundTestLaunchPad Throttle to Zero MapView Throttle to Full Space Bar Save File From Videos: https://www.dropbox.com/s/sdkkisofbc8qbsx/0100SoundTestLaunchPad.zip?dl=0 0.1.0.0 How it was originally: https://youtu.be/6OUCXdMNblI (20 Seconds) Things of note here are: Sounds are relatively instant when turning off and on engines quickly Sounds do change their sound a little bit when turning off and on engines quickly Sounds work if the engines were off in Flight mode and turned on in Map View There's a quieter rumble in Map View that goes back to full sound in Flight View Additional Information: Any reference above to turning engines on and off is actually Z and X to throttle 0 to 100 to 0 etc. If actually launching the rocket properly sometimes it works sometimes it doesn't on its way up in regards to the sound completely turning off in Map View (a little more intermittent) It happens in space as well. It's not just a launch pad issue. Save File attached below for that as well. Save File for Orbital Rocket Testing: https://www.dropbox.com/s/ix0qts5kp584ate/0100SoundTestOrbit.zip?dl=0
  8. when you enable Hibernate in warp on a probe it will cause the craft to start hiberating even when you are not warping. Attached below is a screenshot of the issue. this is on version 0.1.1.0
  9. KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None Video Evidence: https://youtu.be/_Umxp6djskY (11 Seconds) Save File: https://www.dropbox.com/s/x7yytoau97nn8l0/0120TStationScrollIssueSave.zip?dl=0
  10. Scrolling through the parts manager, resource manager, or any other pop up window will zoom the camera. One should be in control at a time. Side note: Please bring back single part windows. They could work hand in hand, there doesn't need to be ONLY the parts manager.
  11. I sent this to the devs through the support email but I think this is now the preferred communication channel for bugs? So I'm reposting for better visibility. Especially since I saw Matt Lowne hitting this exact bug. I was getting all my kerbals out of my ship in orbit for a group photo, and when I was ready to get them all back inside the ship, none of their EVA jetpacks were working. It's like they stopped accepting input. The fuel gauge showed them all in the 80-90% full range so they weren’t empty. I switched back to the space center and then used the tracking center to take control of them again, only to find they had somehow re-glued themselves to the ladder. Now wondering if they thought they were still on the ladder in some way? It appears to be related to getting additional Kerbals out of the ship Steps to Reproduce: -Have a pod in space with at least two kerbals in it -Have one kerbal get out. -Observe jetpack works fine, even if you switch back and forth between the kerbal and the vessel -Now have the second kerbal get out and fly around -Switch to the first kerbal -Observe, the first kerbal will now no longer accept input, but the second one will work fine -Return to space center -Use tracking center to take control of the broken kerbal -Observe, kerbal loads on the ladder of the vessel that was exited Note that if you go directly to the tracking center rather than going to the space center first, the kerbal will remain broken. Going all the way back to the space center then using the tracking center to take control of the broken kerbal seems to be the way to "fix" this broken state.
  12. hard to show in a picture but when driving, and especially on turns the small, apollo buggy style mesh wheels will jump up and down and it really breaks immersion. so the devs know, it doesnt affect traction or where the hitbox of the wheels actually are. also, cars flip too easily. I know that the wheels clipping into the floor will be fixed, but you guys need to make it so when you turn in a rover, it rolls in the same direction, to avoid a rollover, or just make the parts heavier.
  13. KSP2 0.1.1.0.21572 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 531.18) Summary: Predicted trajectories leaving the SOI of most bodies are incorrect. This affects the manuever plan trajectory as well as the trajectory displayed after burn. The trajectory flips to the correct one after leaving the SOI. I noticed that the map view camera rotates by the same amount as the perceived wrong angle of the trajectory relative to the bodies affected when switching focus between the vessel and Kerbol (or the parent body for moons). The following are the approximate rotations relative to the parent body, these match my experiences for Kerbin, Mun, Minmus and Duna, as well as the screenshots of others I have seen in this thread: Original report: KSP2 0.1.0.0.20892 - Windows 10 Home 21H2 - Ryzen 9 3950X - RTX 2080 Ti (Driver 528.49) (Save file link removed, this affects all craft). History: This craft launched from Kerbin, landed on Duna, picked up a stranded Kerbal, and launched from Duna to the east. Now in 200km Duna Orbit. Problem: As can be seen in the video, a maneuver node set up to leave Duna retrograde leads to a planned trajectory of a Kerbol orbit with an AP further out than Duna and PE at Duna (this is wrong). This will also be the case for the displayed trajectory after the burn, right until the craft exits Duna SOI. At Duna SOI exit the trajectory flips to the correct one, with a Kerbol AP at Duna and PE further in (see images - images from a different run than video).
  14. A bug in the VAB where parts cannot be put into trash when a space craft or a single part of it is behind the trash icon, even when trying to delete a part when clicking on an empty space on part-picker and a vessel is behind it, it won't be trashed / get deleted. How to recreate bug: Load a vessel or place a part in the VAB Put the 'part-picker' over the trash icon (alternate explanation: "hide" the vessel or placed part behind the trash icon on the 'part-picker') Get a part and try to delete the part with the vessel/part behind the trash icon or an empty space in part-picker This bug does not happen when trying to get a part from the part-picker when a vessel or a part is behind the selection. It also doesn't happen when trying to replace a part with another part with the same procedure. https://imgur.com/a/MIbxQN6
  15. Build : 0.1.0.0.20892 Windows 11 Azerty keyboard config (qwerty notation used here), Bug : When trying to bind "e" to any double input keybinds (like yaw left/right for example), "e" doesn't register and it cancels the rebind. It does work for simple input keybinds (like activate next stage for example) Fix : First edit the binding of what you want to bind "e" to something random (else it won't show up in the config file), then go into your appdata folder, locallow, intercept games, ksp2, global, InputKeybinds, and here search for the input you want to rebind, then save and restart your game. Note : steering isn't linked to yaw inputs but stuck on "a/d" for some reason
  16. So I have been normally playing ksp 2 and I have noticed that the time it took for the game to save my progress was becoming progressively longer. When it took like 3 minutes to save my game I have decided to look into the folder where it saves the game and I have discovered something horrible. The last save had 1.63 GB, yeah GIGABYTES. I have managed to look inside these files and at the bottom (it did not manage to load as a whole so I did not manage to get to the real bottom) I found a lot of text that was repeating itself (I added the image below). I have no idea what causes this, I have no mods installed nor did I change anything with the game. I really need some help because this is making my game completely unplayable. You can see the images below (most of the text will be in Czech but it's useless anyways so just ignore it): Below is the image of the repeating text in the save file Below is the first image of the save file folder. Below is the second image of the save file folder.
  17. Don’t have an image but title explains. Was orbiting duna and tried to undock a lander. The docking ports undocked, but the struts stayed connected and didn’t let the lender separate. Later, I tried again but with the Mun. Same problem. I time warped a ton and the ships decided to disconnect. The struts glitched out and clipped apart. The lander and main ship separated, but remained as one vessel for controlling. The camera also decided to focus on the space in between them rather than one of the crafts.
  18. KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None The issue appears to relate to the following: Radial Decouplers position on a part. Inline Decouplers but I am not sure of position on craft. Note I haven't tested all the decouplers for these issues. I used the TT-38X because it gave the most extreme results. I didn't test all the decouplers but the bigger radial one does it too. Only tested one inline decoupler. I have 3 Tests for this bug report: Multi-position Radial Decouple test to show different directions decoupling is throwing parts. 8x Symmetry Booster in orbit decouple moving in a radial out direction. Inline Decouple in orbit moving in a radial out direction. Multi-position Radial Decouple Test: 8x Symmetry Booster in Orbit Decouple Moving in a Radial Out Direction: Inline Decouple in Orbit Moving in a Radial Out Direction: Additional Information: Is this caused by some sort connection like an autostrut connecting at angles? I did a quick test with a 0.1.0.0 craft file for 0.1.0.0 and 0.1.1.0 and the results indicates it started with the first version.
  19. KSP2 Version: 0.1.0.0.20892 KSP2 Version: 0.1.1.0.21572 KSP2 Version: 0.1.2.0.22258 Operating System: Windows 10 CPU+GPU+RAM: i9 9900K+3070ti+32GB Mods Used: None 2 Videos for this Bug Report: First video shows it happening in space Second video shows COM appears to be calculating between the two separated crafts soon after launch. First Video: Second Video: Work Around: Jettison the Engine Plate's fairing/shroud However SAS is not engaged anymore. Change root part to the top of the craft.
  20. So heres the thing, basically every inline mounted auxiliary part such as decouplers, batterys, reaction wheels and cargo bays have bugged drag calculations(including those rounded rear hatches but i didnt feel like making a custom plane just to add it to my testing). Any 1 of these parts will effectively double your drag. These bugs are not limited to only the parts ive tested, as far as i can tell, literally every size and shape of said parts is affected. Ive run a couple of tests as you can see below. Every plane configuration is exactly the same other then parts that are in question added to the plane (original plane parts are white and test parts are orange). First test with base line results: Nr1. Base line: ~360m/s with drag being ~55Kn. Base line v.max ~1000m/s with drag being ~110Kn. Nr2. Same plane configuration, but with added reaction wheel. Plane is unable to accelerate past 350m/s with its drag being ~160Kn. Nr3. Same plane configuration, but with added 1 inline battery. Plane is unable to accelerate past ~340m/s with its drag being ~160Kn. Nr4.Same plane configuration, but with added inline decoupler. Plane is unable to accelerate past ~330m/s with its drag being ~160Kn. Nr5.Same plane configuration, but with added inline cargo bay. Plane is unable to accelerate past ~355m/s with its drag being ~160Kn. Nr6. Ive sized up the plane to see if the amount of drag scales with the size of the craft, and it looks like it basically does: Nr6.1 Base line ~750m/s, drag is ~600Kn. Nr6.2 Base line v.max = ~1100m/s, drag is ~1100Kn. Nr6.3 Same plane with inline decoupler. Plane speed is ~750m/s with drag being ~1050Kn. Plane is unable to accelerate further. All of these drag errors are effectively making it impossible to make xeon ssto's, put any sort of cargo capacity on planes or just have auxilary power or reaction wheels, not to mention the numerous implications it has on rockets.... tho i guess there not affected as much, it just dumsters there efficiency, as every vertical stage is going to effectively double your rockets drag. Hopefully this gets noticed and is fixed relatively soon. :)
  21. These may be minor, but I thought you should know about them. It seems only letters (upper and lower case) are allowed in the Site Name, so no "Minmus Site 1", etc. And since the title is character limited, spelling out numbers is not a great option. I'd think limiting the flag title to only upper and lower case is a bug - though a minor one and really just a nuisance in terms of impact. Site Name is forced into Title Case. If you hold down shift to get multiple uppercase characters only every other one will be uppercase, unless you add a space. Also it's not possible to have an all lower case Site Name, if that matters. A kerbal seems to be able to only plan one flag. Is this a bug or a design choice? There is utility in placing more than one flag, so I hope this is a bug. Workaround: Reboard vessel, do another EVA, and you can plant one more flag. Using punctuation in the Plaque Text (or attempting to use it the Site Name) can cause timewarp! So if you put something clever like "I got here first..." then you'll be timewarping ahead at 4x speed. Similarly, using a comma will decrease timewarp and so may pause the game. If you pause the game due to a comma, then you may be waiting a long time for Jeb to plant that flag once you close the dialog box. To reproduce this bug take Jeb out for a walk and try planting more than one flag.
  22. I was in orbit around Eeloo. I undocked my lander to see it going about 5 m/s in a random direction away from the transfer stage without changing its orientation. I went to EVA bob from the transfer stage and he instantly teleported away from the craft in an orbit completely different from that of the transfer stage except for eccentricity. Intended result: Bob does not teleport hundreds of kilometers from the transfer stage when he EVAs Hardware spec: RTX 3060ti
  23. When creating a new craft, it's lights action group is defaulted to the RCS action group
×
×
  • Create New...