Jump to content

Search the Community

Showing results for tags 'ksp2br-v0.1.4.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. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: win10 | CPU: 5900x | GPU: tuf rtx 3080 oc | RAM: 32gb 3.2mhz Title, happens on every plane that i've used these particular legs on. Small ones have no issues. Included Attachments: RottaPlaneCraftFile.json landingLegsLarge.mp4
  2. Reported Version: v0.1.4.1 (latest) | Mods: some but not relevant for this case | Can replicate without mods? Yes OS: W10 | CPU: i7-9700k | GPU: nVidia 1080Ti | RAM: 128GB Fairing cracks after time warp on the launch pad. Included Attachments:
  3. Reported Version: v0.1.3.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Win10 | CPU: i7-10700K | GPU: RTX2060 | RAM: 32GB Rendezvoused two vessels, as soon as the relative speed dropped below ~7m/s, the green markers (and probably others as well) started wobbling back and forth around on the navball even at relatively large distance from target. Included Attachments: KerbalSpaceProgram22024-02-0321-02-16.mp4
  4. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 When attaching radial tanks with engines to a center stack with engines, the game does not correctly calculate the dV available. In fact, it always shows more dV than is actually available. This prevents me from reliably building rockets that can reach orbit since the dV is usually displayed higher than is actually available. Video example attached. Also bug package including two workspaces that have the issue as well as log files. Included Attachments: BUG131.mp4 BUG131dVcalculationwrong_logs.zip
  5. Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i7-8700 | GPU: Geforce 1070Ti | RAM: 16GB As per the title, anytime you enter and exit the map view the flight camera gets reset back to its original position, rather than keeping the position before entering map view. Anth Edit: Adding More Information: Observed Behavior: The Flight View camera angle is changing on returning from Map View, and is regularly ending up in the middle of the craft. Expected Behavior: When going from Flight View to Map View and than back again, the Flight View camera angle and distance should be identical to what it was before. Steps to Replicate: Load EveOrbitCameraTestSave.json Note position Press M twice Note change in position Press M twice Note camera is now in the middle of the craft Video Evidence: https://youtu.be/q89Vot94fn8 (11 Seconds) Result: The player has to regularly zoom out again and again.
  6. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i9 9900K | GPU: 3070ti | RAM: 32GB Issue: Auto-hide Navball in Mapview set to On, turns it Off. Auto-hide Navball in Mapview set to Off, turns it On. Video Evidence: https://youtu.be/r7evCgU2X1I (31 Seconds) Credit for putting Jeb behind Bars in the Video: @Suppise
  7. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i9 9900K | GPU: 3070ti | RAM: 32GB Issue 1: BORDERLESS Not Working. Issue 2: Setting to BORDERLESS and Restarting KSP2 is Forced to be FULLSCREEN. Other Bug Reports Relating to this:
  8. Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz | GPU: NVIDIA GeForce RTX 2070 | RAM: 16GB If you do the following: Attach a part (A) radially Attach another part (B) to that radially attached part (A) Then change the root part to B The parts will disconnect when launching and then disappear when reverting to the vab. Included Attachments: testvabcorruption.json Video evidence: 2023-08-0501-41-20.mp4
  9. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i9 9900K | GPU: 3070ti | RAM: 32GB Observed Behaviour: Prograde/Retrograde Indicators are moving based on the other crafts rotation. Expected Behaviour: Navball indicators only move in reference to the two crafts relative positions. Video Evidence: https://youtu.be/rzTCBmVMpTc (27 Seconds) Steps to Replicate: Load TargetInheritorTestSave.json Load again to counter spinning bug Undock the docking port on the left Target the other crafts docking port Change to Target mode. Change to the other craft Push a little rotation Change back to the original craft Results: Retrograde indicator is reflecting other crafts rotational movement when it shouldn't be. Credit: @00Dave For help with getting the perfect way to demonstrate this for the video evidence.
  10. Reported Version: v0.1.4.1 (latest) | Mods: ITK 1.4.2, BepInEx 1.4.3, MicroEngineer 1.3.2, Transfer Window 0.1.5 | Can replicate without mods? Yes OS: Win 11 Home 64b | CPU: 13th Gen Intel i5-13600KF (20 CPUs) | GPU: NVIDIA GeForce RTX 4060 Ti | RAM: 16GB Struts connectors that are working fine under heavy stress... .... break when undocking and function no more. Included Attachments: Refuel.json
  11. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Independent | CPU: of | GPU: Computer | RAM: specs When adding launch clamps, each clamp/symmetry group makes its own new stage, instead of joining the current lowest stage like it did in ksp 1. If this isn’t caught before launch, it can result in the craft dropping to the ground. work around: check yo staging!
  12. Reported Version: v0.1.4.1 (latest) | Mods: micro engineer | Can replicate without mods? Yes OS: Windows 10 Home edition (Build 19045.3324) | CPU: Intel i7-9700 | GPU: NVIDIA GeForce GTX 1660 Ti | RAM: 16 GB 2666 Hz The drag created by airbrakes does not change when deployed or undeployed. This issues causes large sums of drag to be caused by airbrakes while the airbrakes are at any angle other than 0 relative to the oncoming wind regardless of being deployed or not. A workspace file has been included with the 2 planes used for testing. Expected result: Drag created by a surface mounted, undeployed, airbrake should not increase as the craft pitches up as the airbrake is out of the airstream and flat against the body. Current result: The game applies drag to the airbrakes on their AoA alone while disregarding their relative position to the fuselage of the plane Expected result: Left Current result: Right Testing to prove the theory. All testing was done by letting the plane achieve the highest speed it can in any given state, making sure it was stable, and then taking a screenshot. Plane WITHOUT airbrakes (405 m/s) Plane with airbrakes on the side (undeployed (361m/s) and deployed (187m/s)) Plane with airbrakes placed at a 90 degree angle by default (undeployed (188 m/s) and deployed (376 m/s)) Included Attachments: AirbrakeDragBugreport.json
  13. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Win10 | CPU: Ryzen 5 3600 | GPU: 3080 | RAM: 32 Recently on a trip to Laythe I found a drag issue after decoupling from inside a cargo bay. Load save file "Flying on Laythe" Change cam to auto Group 3 to open cargo doors Group 4 to control from Buggy Stage twice to drop buggy (or change stack to make drop next) Observe vessel has zero wing control or drag- there is no slowing. Create a save while Buggy is falling Load Save- Buggy should now fly like a decent plane. Included Attachments: FlyingonLaythe.json .ipsImage { width: 900px !important; }
  14. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 When trying to rendezvous with another vessel, trying to match orbits by locking both active and target vessel's PE visible results in the UI elements overlaying each other. This might be a regression, because I believe in previous versions the game realized that these two would inhabit the same space and put them apart from each other. Please correct me or close this if that was not the case. Because then it's not a bug, just a badly implemented feature not providing any advantage over how it worked in KSP1. Included Attachments: BUG134.mp4
  15. Reported Version: v0.1.4.1 (latest) | Mods: Community Fixes; Flight Plan; Interplanetary Calc; K2D2; Maneuver Node Controller; MapView Focus and Targeting; Micro Engineer; Node Manager; Space Warp | Can replicate without mods? Yes OS: Windows 11 | CPU: AMD Ryzen 9 3900 12-Core Processor 3.09 GHz | GPU: GeForce RTX 2060 Super | RAM: 32.0 GB Created a multi-stage craft to fly to Moho this morning. Needed to revert to VAB to add multiple parts to original craft (monopropellant tanks, RCS thrusters, and additional lifter stage boosters). Added the tanks and thrusters, and all seemed normal. When changing the symmetry for the lifter stage boosters, the addition of parts went wonky. Switched from 4 to 6, but only 5 boosters were added. In addition to this, the 6th booster was "held" as if I had selected it, and I could not put it onto the rocket at all. I had to delete it, and at that I could only delete it by going to the trashcan; both the Delete key and just clicking in the parts window didn't work. Problem is reproducable under all conditions with this craft. Launch/Revert to VAB, Load Saved Game, Exit and relaunch KSP2. Craft file provided. Video that shows the issue is linked in the bug report. Included Attachments: Desktop2023_10.23-12_00_49_01.mp4 MohoI.json .ipsImage { width: 900px !important; }
  16. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel i9 9900K | GPU: Nvidia 3070ti | RAM: 32GB Two scenarios: When craft's engine bells are sitting on the ground moving 2400m away from the craft it falls into the Mun When craft's tank is sitting on the ground moving 2400m away from the craft it falls onto its solar panels (SP-4L) 1. Craft's Engine Bells are on the Ground: 2. Craft's Tank is on the Ground:
  17. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: AMD Ryzen 5 5600G | GPU: NVIDIA Geforce GTX 1660 | RAM: 16GB I'm not sure what could cause this glitch, other than the collision of fairings has been very... interesting to say the least. It seems to be caused by a mixture of phantom forces and random impulses from the RoveMate body or wheels, which could be because of part clipping issues (please fix this one day) To replicate: Use the savefile I've attached, launch the rocket, then press space to detatch the first stage, and the rover begins to drift off-kilter. For stopping this glitch, you can begin timewarping and then stop, and the rover will stay in place. This affects the mass of the rocket now being offset and so I can imagine it treats the new position like it's been there as usual. I'll see if I can replicate it with just the fairing and other fairings as well Below I've attached a screenshot of the glitch, a video of replicating it (please ignore the initial fail, my record button is the same as the timewarp up button :P), the craft file and a quicksave to help Any tips on building rovers would be appreciated Included Attachments: 2023-10-2420-27-24.mkv RoverWorld.json quicksave_47.json .ipsImage { width: 900px !important; }
  18. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz | GPU: NVIDIA GeForce RTX 3060 | RAM: 32.0 GB As the title says above my orbit line suddenly disappeared after entering and leaving a sphere of influence (any celestial body). .ipsImage { width: 900px !important; }
  19. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 Tried to refuel a vehicle in orbit. Target vehicle was combined of 3 main vehicles: Mothership, lander and spaceplane. all sent up together in one launch (which was PAINFUL btw). When the refueler arrived at the target vehicle, the spaceplane was suddenly undocked, but it still reacted to control inputs given to the mothership and parts were also controllable via PAM. There was no "undock" option for the docking ports in question but the two vehicles were still treated as if they were one (except for position in space). This is infuriating on so many levels I cannot begin to describe. But I made a video for everyone to share the pain. Logs, relevant save game and workspace in bug package. Included Attachments: BUG135.mp4 BUG135Vesselundockedbutstillcontrollable_logs.zip
  20. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: I9 CPU Intel | GPU: 3060 6 gb (laptop) | RAM: 16 GB I found when taking off with my plane I made my kerbal EVA accidentally as the plane was accelerating. The kerbal started to slowly "shift" away from the ladder point and in the reverse direction of the acceleration. The kerbal was still attached to the craft and looked like it was still holding the ladder but after a point it was just holding air and was still "attached" to the craft. Images show example. Included Attachments: .ipsImage { width: 900px !important; }
  21. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 11 | CPU: I9 CPU Intel | GPU: 3060 6 gb (laptop) | RAM: 16 GB When on EVA the navball changes its color pallet to "nightmode"/"space" when even on an atmospheric body like kerbin. These images were taken on Kerbin and to note is my UI is scaled at 95%. I am pretty sure this is a bug but correct me if I am wrong. Images show the UI when in a craft at the same location as when EVA'ing as a kerbal. Plane Correctly Showing Navball Set to Surface: Kerbal Incorrectly showing Navball Set to Orbit Instead of Surface: .ipsImage { width: 900px !important; }
  22. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: 11th Gen i5-11600k | GPU: GTX 1080 | RAM: 32 GB DDR4 Title pretty much says it all, when a part is attached to the front of the tube and it is extended, that part gets pushed up, and when it is retracted that part will get pushed down Video Evidence: WeirdStructuralTubeBehavior.mp4 .ipsImage { width: 900px !important; }
  23. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz | GPU: NVIDIA GeForce RTX 2070 | RAM: 16GB Steps to replicate: Go to launchpad with a pod with any parachute on it Deploy the parachute Repack the parachute and observe the animation Second steps to replicate (to see the bug longer): Go to launchpad with a craft with a parachute and an engine&tank to fly Deploy the parachute Wait for him to deploy Cut the parachute Repack the parachute Additional informations: The bug seems to only appear on ascent where the parachute is not deployed in the intended way (to land). Included Attachments: 2023-10-2215-27-30.mp4 2023-10-2215-26-06.mp4 .ipsImage { width: 900px !important; }
  24. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel i9 9900K | GPU: Nvidia 3070ti | RAM: 32GB Steps to Replicate: Load CopiedForceTestSave.json Press ] Note the other craft exploding/disassembling for a moment Press [ Note: The rover that is upside down got sent into the air similar to the force of the other craft that was switched to exerted. Additional Information: If pausing then changing to the other craft and back, nothing happens Related to: Video Evidence: CopiedForce.mp4
  25. Reported Version: v0.1.4.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel i9 9900K | GPU: Nvidia 3070ti | RAM: 32GB Steps to Replication: Load SwitchTeleportTestSave.json Pause Press ] Note: It was above the surface for a fraction of a second before it suddenly ended up under the ground. Video Evidence: 2023-10-21 23-58-15.mp4
×
×
  • Create New...