Jump to content

Search the Community

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

  • 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. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Intel i9-9750H | GPU: RTX3060 | RAM: 32GB I find that when moving the camera around a vessel on a surface, if you move the camera down too far, when it hits the ground collider it suddenly switches perspective and stops being centred on the vessel. If you move the camera back up then it jumps back to the original perspective - making viewing anything on the ground rather janky, especially if you're wanting to look up to the sky etc... Included Attachments: KerbalSpaceProgram22023-11-2510-51-25.mp4
  2. 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 Transition from Vall SOI to Jool SOI: Transition From Kerbin SOI to Minmus SOI: Transition from Kerbin SOI to Kerbol (Solar Orbit) SOI: Additional Information: Cant test Kerbin orbit to Jool. The capture mode camera had issues. Credit goes to Suppise on discord for discovering that the Jool Moons were missing when it was inside of one of the moons SOI. Happens in 0.1.0.0 and 0.1.1.0 as well
  3. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Ryzen 5 5600x | GPU: 3070 | RAM: 64gb Behavior The Bug Does: When applying an object with a port that isn't the root part using symmetry doesn't behave only doing the object you put on Behavior: Extra Info: Additional Notes: This Might Just Be This Craft Save Itself, Due ThisIs4Bugs.json, All Anchor Points Are Considered "Invalid" There Is Objects Below The "Ground Included Attachments:
  4. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: win 11 | CPU: I7 | GPU: rtx 3080 ti | RAM: 32 Parachutes didn't deploy staging them. Vessel did drop over 200m/s second to water and survived .ipsImage { width: 900px !important; }
  5. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Famille 10.0.22621 64 bits | CPU: AMD Ryzen 5 5600H with Radeon Graphics (12) | GPU: NVIDIA GeForce RTX 3060 Laptop GPU (6009MB) | RAM: 16236 Only a part of the rcs work on my craft although they are in the same position. This bug has not reappeared in another save with the same craft. Included Attachments: onlyapartofthercswork_logs.zip Anth Edit: Looks like its the shroud of the heat shield is partially blocking the RCS that are connected to the decoupler. Steps to Reproduce: Be in the VAB with nothing in it Grab a M1-3 Gumball Below attach a heat shield of the same diameter Below attach a decoupler of the same diameter Attach 4 RV-105 RCS ports to the decoupler down slightly from the middle of it Below attach a X200-8 tank to the bottom Launch Turn off SAS Turn on RCS Use Q or E to use roll Note: Only 2 of the RV-105 RCS ports are working. Video Evidence: 2023-10-31 00-03-23.mp4 .ipsImage { width: 900px !important; }
  6. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Ryzen 7 3700x | GPU: RTX 3080 Ti | RAM: DDR4 16GB 3200Mhz Current game behavior disables your ability to make maneuver nodes if it believes your ship to have no deltaV. This also can occur when you have plenty of fuel in the form of monopropellent, which the game doesn't actually calculate the deltaV for. It can also cause you issues if the deltaV calculation has an error and believes your ship has none, even though you can still burn fuel. This seems intentional on the surface, but is prone to causing lots of frustration. Even if it works exactly as intended, I could want to set up a node before refueling my ship to get an idea on the potential fuel cost. How to replicate: Launch any ship in a configuration where the game detects you have no deltaV, and attempt to create a maneuver node. It will pop up an error. Included Attachments:
  7. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows | CPU: 13th Gen Intel(R) Core(TM) i7-13700H | GPU: NVIDIA GeForce RTX 4060 Laptop GPU | RAM: 1 TB I was on a trajectory towards Duna and time warp didn't stop in time. The craft glitched through the surface and was set on a straight trajectory into interstellar space. I reloaded a quicksave and started recording in order to find the glitch again. It happened again in the recording, this time however the craft began to orbit INSIDE Duna. I believe the orbit being messed up was a result of the craft exiting time warp while inside of the planet. Included Attachments: 2023-11-0616-10-07.mp4
  8. Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: windows 10 | CPU: Intel i5 4690K | GPU: NVIDEA GTX 1070 | RAM: 16gb I crashed part of my lander against a building, so some parts exploded, but the capsule was still intact so I should have been able to fly on and save the craft. Instead, the game forces me to the 'Mission failed' screen with the flight report because it thinks that "Vessel destroyed" even though this is clearly not completely the case. This is super annoying because it renders me powerless to save the rest of the craft. Included Attachments: RovyStray.json Spicat Edit: You can reproduce it with another error than "structural failure": Build any craft Attach a docking port (that we'll call A) Attach a docking port (that we'll call B) on A Copy A (so B is copied with it) Attach the copied part Video evidence: 2023-11-18 01-16-52.mp4 Additional Information: This reproduction is linked to another bug report who has the same reproduction steps:
  9. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 7 5800X | GPU: AMD Radeon RX5700XT 8GB | RAM: 16GB 3200 MHz Severity: Medium (feature not working as expected) Frequency: Always Azerty keyboards are translated like qwerty keyboards. Some default keybinds (and also the hidden ones like Ctrl-A in the VAB) are therefore placed somewhere else and resetting it in the settings just print the qwerty key instead of the one pressed on the keyboard. Example: [M] is the default keybind for Map View. On azerty keyboards, [M] don't work and you have to press [,]. Example: While resetting Map View keybind in the settings, pressing [M] on the azerty keyboard register [;]. Same for pitch, pressing [Z S] register [W S] The screenshot given below shows Toggle Map View bind to [;], while I pressed [M] on the keyboard Suggestion: Disable [Phyiscal Keys] option in Unity's input manager, if enabled. Included Attachments:
  10. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz, 2904 Mhz, 6 Cores, 12 Logical Processor(s) | GPU: NVIDIA GeForce GTX 1650 SUPER | RAM: 12 GB Expected delta-v to show for a separated vehicle but it showed 0 delta v Steps to replicate (what that I did): 1. Create a vehicle on another vehicle which separates via a decouple (eg. a probe which separates from a larger craft. Note: construct probe on larger craft, not as its own craft and then attach) 2. Separate sub craft. Included Attachments:
  11. Reported Version: v0.1.5.0 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 Pro 64-bit (10.0, Build 22621) (22621.ni_release.220506-1250) | CPU: 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (16 CPUs), ~3.6GHz | GPU: NVIDIA GeForce RTX 3070 Ti | RAM: 32768MB RAM 3200MHz (4 Sticks Corsair Vengeance RGB Pro 8GB) When I press the Extend button for the inflatable heat shield in the parts manager so that it extends and then make a quicksave and load that, the button switches to the unextended position even though the shield is extended. When I try to press the button it just plays the sound and nothing happens. I attached a video which can explain this better than I can. Included Attachments: Desktop2023_10.17-11_59_48.02-Trim.mp4
  12. Reported Version: v0.1.5 (latest) | Mods: See previous bug reports | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 9 | GPU: GeForce RTX 2060 Super | RAM: 32 GB Still trying to get to Moho, this time by creating multiple smaller craft and assembling in orbit. Launched the first craft (transfer stage), putting it into LKO at ~100km and watched it spin out of control as soon as the circularization burn was done. Finally got it under control and launched Moho II-1 Lander into LKO with a Pe of ~90km. Set original craft as target and used RCS to get to the target marker on the navball (in spite of having reaction wheels which, for some reason, do not seem to work AT ALL). Switched to the original craft using ]; I do this on all rendezous maneuvers when I have docking ports on the front/top of the craft so I have a direct line from one vehicle to the next. The lander craft began to spin out of control as I was setting it as a target, so I switched back to get it under control and then the original craft spun out of control. Video shows this happening. Steps to Replicate: rendezvous 2 crafts in orbit. ensure they both have control. make the craft target eachother set SAS to target on one of the crafts switch to the other craft and do the same observe the non-active craft will start to spin Workaround: Disable SAS on one of the two craft after positioning it Included Attachments: Desktop2023_10.31-13_41_58_03.mp4
  13. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Home 10.0.22621 64-bit | CPU: AMD Ryzen 9 5900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24339MB) | RAM: 65458 I encountered the return of orbital decay after loading a save. As a work around, I managed to activate time warp, but this only solved it temporarily. I am not sure if it affects other celestial bodies in the solar system. These are the steps I took after loading: 1-Begin timewarp and then exit 2- Start my power descent(descent burn) 3- record results Included Attachments: OrbitalDecayAroundMunafterLoadingaSave_logs.zip SpacePeacockDebugger.json (craft file)
  14. Reported Version: v0.1.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel i9 9900K | GPU: Nvidia 3070ti | RAM: 32GB Smaller Rover to Show Severity: Larger Rover to show its at each 1000m interval: Additional information: Quicksave and Quickload and the 1000m glitch will reset the distance and will now happen from 1000m away from that new Load point. Physics Warp appears to resets the 1000m glitch point as well. Why the Large Rover didn't end up on its side or on its back is because it wasn't travelling fast enough. I tried it on Minmus and it did do it at 1000m but I couldn't get consistent results because the surface wasn't flat enough. The game is reporting the Kerbal 2000m (not 1000m) away as being on a crash trajectory each time the large rover glitches
  15. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Edition Windows 10 Home Version 22H2 Installed on ‎29/‎06/‎2022 OS build 19045.3570 Experience Windows Feature Experience Pack 1000.19052.1000.0 | CPU: CPU Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz Base speed: 3.40 GHz Sockets: 1 Cores: 4 Logical | GPU: GPU 0 NVIDIA GeForce RTX 3060 Ti Driver version: 31.0.15.4592 Driver date: 19/10/2023 DirectX | RAM: Memory 32.0 GB DDR3 Speed: 1600 MHz Slots used: 4 of 4 Form factor: DIMM Hardware reserved: 4 Severity: Low Frequency: High. Very easy to reproduce the bug. Description: I am not sure when this bug happened, but frequently the game will not activate a staging on the first click of the green button nor will it active a staging on the first pressing of the space bar. A second click/press will do, though. I believe this is not intended to be, as the tutorial itself believes that one staging input confirms separation of the craft, in tutorial "Missing the Ground 3/6". (Paige can be fooled!) Here is a video of it happening (I have to click a second time to successfully separate the stage):
  16. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 10 Pro 10.0.19045 64-bit | CPU: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz (8) | GPU: NVIDIA GeForce RTX 2060 SUPER (8019MB) | RAM: 32683 Severity: Low Frequency: Occasional While trying to save a craft in the VAB, typing the letter "M" (upper or lower case) into any of the text boxes causes the game to immediately enter Map View. This has also occurred once whilst renaming a craft in the Tracking Station. Its occurrence is very sporadic, quitting the game clears the problem. (not sure if this should be filled under Construction, Map & Tracking or UI; I bow to your wisdom oh mighty bug hunters) Included Attachments: TypingMinVABentersMapView_logs.zip .ipsImage { width: 900px !important; }
  17. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 5 5600 6-core Processor | GPU: NVIDEA GeForce RTX 3060 | RAM: 15.91GB This ugly green outline was persistently present, even when not hovering the craft with the mouse. Dibz claims he also had it on a fuel tank going to map and back didn't fix quicksave and quickload did fix. Included Attachments: Dunaticon.json .ipsImage { width: 900px !important; }
  18. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel Core i7 4790 | GPU: Nvidia GeForce RTX 2070 Super | RAM: 16 GB Fairing causes parachute arming and deployment not to happen even after fairing is deployed. Could not reproduce in other crafts using fairings besides remaking of affected craft. Affected craft attached. Video: Included Attachments: DunaTransfer.json
  19. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Famille 10.0.22621 64 bits | CPU: AMD Ryzen 5 5600H with Radeon Graphics (12) | GPU: NVIDIA GeForce RTX 3060 Laptop GPU (6009MB) | RAM: 16236 action in action group didn't happen at the same time, i need to prees again the button. This bug reappeared in another save with the same craft. Included Attachments: actioninactiongroupdidnthappenatthesametime_logs.zip Spicat edit: probably related:
  20. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Win11 | CPU: AMD Ryzen 9 5950X | GPU: AMD Radeon RX6700 10GB | RAM: 32GB Corsair Vengeance RGB DDR4 3200mhz As the title states, I'm unable to bind E on any keybinds. I would like to set it to yaw rather than roll. However whether I try to bind it "E" just acts like an "Accept" or "Enter" keybind, even when trying to rebind the keys. KSP and KSP2 are backwards with the roll and yaw default keybinds in comparison to every other flight game I have ever played where Q/E are typically yaw and A/D are typically roll. Specs: Win11 CPU: Ryzen 9 5950X GPU: AMD Radeon RX 6700 10GB RAM: 32GB DDR4 3200rpm cooling: H100i Capellix AIO liquid cooler PSU: Corsair C750M mobo: ASUS ROG B550F Peripherals: Corsair Scimitar Pro RGB mouse Razer Blackwidow keyboard Logitech G432 headset Stream Deck MK2 Power A Xbox Series S Controller Thrustmaster T-flight HoTaS 4 (I felt it necessary to include peripherals due to potential conflicts, but if this is the case I have never experienced conflicts with them or their respective software together in the past) This topic was previously brought up in this post: Post is claimed to be resolved as of v0.1.3 but I am on v0.1.5.0.28833 Included Attachments:
  21. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 10 Pro 10.0.19045 64-bit | CPU: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz (8) | GPU: NVIDIA GeForce RTX 2060 SUPER (8019MB) | RAM: 32683 I've been working on the rover race challenge (#36). This has entailed me switching between the rover I'm using to race and a couple of other rovers I'm using to mark my breaking points on the track. A couple of times I've come back to the race rover and it hasn't been there. When I use the square bracket key to switch to it (from a nearby vehicle) I arrive at the expected point but the rover is not visible; all very mysterious. I just "launched" a third rover to the runway only to discover two of the previous rovers were now visible. I square bracket keyed to them only to find the kerbals and cockpits had been scooped out, again (see previous bug report I made). Included Attachments: Roversdisappeared.Nowtheyrebackbutthekerbalsaregone_logs.zip
  22. Reported Version: v0.1.5 (latest) | Mods: Community Fixes, MapView Focus and Targeting, K2D2, Micro-Engineer, Maneuver Node Controller, Flight Plan | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 9 | GPU: GeForce RTX 2060 Super | RAM: 32 GB Created a maneuver to go from LKO to Moho. LKO Ap ~324km, Pe ~300km. Burn originally calculated 2279 m/s of dV, but after burn timer hits 0 bar shows dV remaining to be burned. Furthermore, the original plotted trajectory was not matched upon burn. Images below show the plotted course, dV requirements, and new trajectory. Should have had an encounter with Moho after the burn finished, but no encounter at all. Included Attachments:
  23. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: amd ryzen 7 3800x3d | GPU: AMD RX 7900XT | RAM: 64 GB DDR5 @6000MHz Parts inside of the mk2 cargo bay seem to experience drag. There are 2 craft files attached to this report, one with a cargo bay with a light payload, and one with the cargo bay replaced with a short fuel tank of greater mass. The craft with the payload bay has significantly greater drag than the craft without a payload bay, as evidenced by the fact that it cannot reach a speed greater than 370 m/s, where as the craft without the bay is easily able to push past that speed and reach orbit, despite being heavier with the same external geometry. Included Attachments: SateliteTest1.json TestVehiclenopayload.json
  24. Reported Version: v0.1.5 (latest) | Mods: See description for full list | Can replicate without mods? Yes OS: Manjaro Linux + Steam Proton | CPU: AMD Ryzen 7 5800X | GPU: AMD Radeon RX 6700 XT | RAM: 32 GB Spicat Edit: This bug work with no mods and on windows (see below) Initial bug report (hidden for visibility) Craft file: Test.json Video evidence (from Spicat with the craft file provided): Spicat Edit: Steps to reproduce: In the vab, put a pod Attach a launch clamp to it (optional but it's to see the bug better) Attach a hub on top Next to the craft (in a different subassembly), put a tank and attach a decoupler Take the tank and attach it to the hub so that the decoupler is the part separating the hub and the tank - Important Copy the decoupler (thus, with the tank) Attach the copied part to another hub connection Launch and decouple Result: When the copied part is decoupled, he thinks that it's still part of the craft, so the camera follow and the part still reacts to the input. Video evidence (with all the steps): 2023-11-01 00-05-18.mp4 Steps to reproduce (Docking port version): In the vab, put a pod Attach a clamp to it (it's not mandatory like above) Attach a docking port to the pod (or any other part, a truss in the video below) Attach an engine to that docking port (to detach it) Copy the docking port (with the engine on it) and attach it next to other one Go to the launchpad Undock the docking port (the one that was copied) Video evidence: Additional Information: The version with the docking port also work if you attach another docking port instead of an engine but it triggers another bug (You can see what does the version with only docking port in it):
  25. Reported Version: v0.1.5 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel Core i7 9750H | GPU: NVIDIA GeForce GTX 1650 | RAM: 16 GB I connected monofuel tank to my craft with methalox KS-25 main engines and I was surprised, because dV increased. I connected monofuel and hydrogen tanks and in all cases dV increased like if I connected methalox tanks. Obviously the dV must decrease because the KS-25 engines don't use mono and hydrogen fuels and these fuels remain as cargo. The game doesn't seem to distinguish between fuels when calculating dV You can see process in attched video, where after attaching tanks dV in right part of screen increasing. For any cases I also attached craft Included Attachments: IncorrectdVcalculatorbehaviour.mp4 Spaceplane-1mk1.json
×
×
  • Create New...