ShadowZone
-
Posts
676 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by ShadowZone
-
-
Reported Version: v0.2.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: 65459I encountered this bug at Pol. My vehicle was in clear view of the sun, the panels pointed at it, but the game said "blocked by Pol". This was persisting through multiple attempts to repack and unfold the panels. It only went away when I undocked my lander and then switched back to the original vehicle.
Included Attachments:
-
7 hours ago, Ruedii said:
OK, let me put it simply, Agile purists are the absolute worst hypocrites in software.
Amen to that. Fundamentalists of any kind should be treated with caution. To stick with my earlier wording, these people are just selling you a different kind of snake oil
QuoteFollowing a specific manifesto and process as a means to complete software is a clear contradiction of Principal 2, and 12. Not adapting your development workflow and priorities and instead staying on a fixed set of priorities is against the very principals of Agile. So entering new methodologies, setting teams on other methodologies, is important.
I like to say that they're principles, not commandments. Or to quote Jack Sparrow (sorry, Captain Jack Sparrow), "they're more like ... guidelines". The whole idea behind the agile movement (or at least, the value that I personally took from it) is to make things more flexible and to be able to react to a constantly changing situation. If you try to force everyone to follow a rigid set of rules (and remember: rules != principles), then you are not agile, no matter mow many Scrum Alliance certifications you paste onto your LinkedIn page.
To me, it boils down to the axiom of "inspect and adapt", which coincidentally is also reflected in principle 12. So yeah, people that try to "make you agile" by prescribing certain processes or try to prevent you from coloring outside the lines are oftentimes making things worse.
When in doubt, refer to principle 1: is what you are doing helping you to deliver valuable software to your customer? The trick here is how to measure whether or not you're actually doing that.
QuoteFurthermore, Agile's 12 principals are seriously in contradiction to each other, because 6 assumes everyone works in the same way favoring face to face contact, but 5 says everyone should work in an environment best suited for them.
I for one do NOT communicate best in face to face contact. I find this sort of generalized broad brush fallacy a sham, which is exactly why you should never subscribe to a single management philosophy, lest you lose the ability to adapt to your fellow team members, and the needs of the project.I don't see the contradiction, because 5 and 6 are aimed at different aspects of a software development organization. Principle 5 is more aimed at upper management and how to treat your employees (especially the "trust them to get the job done" part. Oh boy, did I have heated discussions with managers about that one...). Principle 6 is more aimed toward the day to day operations. But you have to acknowledge the time the manifesto was created in, more than 23 years ago. Kent Beck's "Extreme Programming" was only released two years earlier, bringing the concept of "pair programming" to a wider audience (yeah, it had existed decades earlier, but Beck popuralized it).
For me, there's a two key things in principle 6:
-
efficient and effective method of conveying information
- to a development team
- within a development team
Me as a product owner, I'm responsible for the "to a team" part. In my experience, the most efficient way of explaining a feature, or a problem the customer has, is to sit down with the devs and have a conversation about it. The best outcome is when I get a gazillion questions and we can refine the item there on the spot with everyone walking away with the same understanding of what needs to be done. While principle 6 states "face to face", I have had good results with doing it via Teams/Zoom/etc and collecting everyone's input and thoughts on a digital white board (I'm a "drawer & pacer", I need to scribble on a whiteboard and walk around constantly when I'm thinking. I rarely have my camera on in remote meetings because I'm pacing up and down the office or my living room when I'm talking). Again, the manifesto was written almost a quarter of a century ago. They didn't have our means of communication. E-Mail was laggy, chat was minimalistic (yes, I remember and was part of various IRC servers in the Nineties), phone was cumbersome.
I know people who prefer writing meticulous JIRA tickets. I have had colleagues who recorded their "tickets" as a video and upload them as attachments to the relevant JIRA issue. It all boils down to this: "are you practicing an efficient and effective method of conveying information"? But it has to go both ways: just because that product owner likes to record videos does not mean the dev team is able to distill their tasks from it. Is has to work for both sides.
The signatories of the manifesto wanted to break the death spiral of "throw a spec over the fence, write dozens of e-mails back and forth until you really find out what needs to be done". To come back to the "inspect and adapt" part: if you and your co-workers are comfortable with the current way you communicate AND it enables you to be effective and efficient, then you do you. As before, the question is: how can you measure whether or not this is the case? A dev team might feel good about themselves, but they can still be inefficient and therefore not delivering valuable software early and continuously (principle 1).
QuoteI should say you should do an agile inspired methology with some things. You need to do much more rapid cycles and much more frequent changes to requirement in certain aspects of development. Fixing bugs and limitations are one of them. Honestly, the vast majority of Agile theory is extremely effective at triaging and addressing common bugs and limitations.
However, Agile is also very short-sighted and many functions require things it frowns on. For instance, forking a team and the codebase to add something that will take a lot of time. I find it one of those things managers come up with that don't really understand how programming and codebases work. Many major key items require a very large amount of base code and invisible background features. Agile is not very accommodating to the development of such code.I fail to see see how forking a team and code base has anything to do with the principles behind the agile manifesto. There's nothing in there that says "you need to do x" or "you have to use tool set y".
You mentioned things that "take a lot of time". If you have features that cannot be done within the confines of a single sprint, you have two options: preferably, put your heads together and try to split the item into more easily digestible chunks that chain together over the course of multiple sprints, or - less preferable - carry an issue over multiple sprints. Over the course of my career, I rarely had the latter situation. Yes, it can happen, but only after you made sure there's no other way.
Also, sprint cycles and release cycles do not necessarily have to be aligned. You can have two week sprints but release only every three months.
If I ever get into the unfortunate position of being a manager, I would be completely hands off about key development tasks like how to set up your code base or branching strategy or whatever. YOU as developers need to be able to work with the tools available, not me. If you have the plumber come over, do you lord over him and say: "No, don't use the wrench, use the screwdriver, I read that in a book ten years ago."? No, you don't. You trust the specialist that they know that the heck they are doing.
Coincidentally what you describe, managers interfering into direct dev work, is in contradiction to principle 5. They don't trust you to get the work done, so they mess with the environment because they (wrongly) believe they know better. Screw those people!
Management needs to get out of the way of day to day development (principle 5), the team needs to figure out how to best deliver themselves (follow principle 12 to be able to live up to principle 1). This is why the Scrum Master role is so important. They need to keep overbearing managers in check but also need to make the dev team really inspect how things are going and help them figure out what to adapt to constantly improve (which is in line with the Deming cycle and Kaizen both of which were inspirations for the agile manifesto).
QuoteWhen managing the roadmap you can take some inspiration from Agile. Determining what features should be delayed or canceled to get a new feature put in the roadmap is very consistent with agile.
Simply put, while it's a good theory to learn, it is rather short-sited, and broad brush to think it has to be applied to everything. Additionally, claiming it should be applied to everything is hypocritical in that it expressly says you need to adapt to the needs of your team and your clients. Sometimes what your team and clients need is not something Agile will provide, in which case you need to introduce other management and methodology theories.From what you write I get the feeling you have a more agile mindset than you give yourself credit, especially the way you recognize that organizations need to be flexible and structure themselves to be able to react to change and offer a good environment for developers. These are some of the most important aspects behind the agile manifesto.
But your final paragraph talks about methodology and application. As I said in my previous post, the principles are none of those, but just what they say the are: principles. They should be a guiding light to how you organize your work. Some of them might shine brighter for you than others. All of them need to be interpreted and adapted for your use case. I have heard of companies building ships that have adapted their work to incorporate the principles.
One big pitfall is what I repeatedly said about "how can you measure that". This is where most organizations start to flounder, because they often fall back into command & control rythms or try to create a tight noose around everyone with some KPI, OKR and whatever fancy management metric they come up with next. People like safety and large Excel files with a lot of numbers give the illusion of being able to control the chaos when in fact you can't often times. One of my other pet peeves I regularly have heated discussions about with our management staff.
Another pitfall is scaling. The manifesto is geared towards a single team working together but nowadays you often have large organizations with multiple teams. Along came LeSS, SAfE, CAS etc to muck things up even further, selling the illusion of a "one size fits all" framework you can put to your company. Snake oil, all of them.
History time: I was in a well functioning development organization that managed to implement a custom scaling strategy based on scrum and following the agile principles. It was not perfect, but it worked for us most of the time. Then we got new management and they immediately needed to mess things up by forcing SAfE onto us. We were forced into a box, nobody really liked or understood and the end result was less efficient development, lots of dissatisfaction which led to long time employees leaving but management still selling it as a success because THEIR plan was implemented. Textbook failure of principle 5 and also 12. We didn't inspect and adapt, we followed a fixed plan, to everyone's detriment.In closing, I just want to say I really appreciate this discussion, even if I disagree with you on some counts. This is how we can move the conversation forward how to best organize software development work. Maybe someone from the KSP2 dev team takes note and can pull something out of this for them to improve how they do things
-
efficient and effective method of conveying information
-
6 hours ago, Ruedii said:
Yes, the most common one is small bugs and high priority bugs are done AGILE, roadmap is planned Waterfall/Cascade, and implementation of major patches and roadmap steps is done SCRUM.
AGILE does not work well with roadmap as it results in a constant moving target, but it works well with smaller and high priority bugs. Leaning too much into AGILE planning methods will result in the project losing focus (e.g. KSP2 under the initial management team) but not embracing it enough will result in a lag between simple but game-breaking bugs from being fixed. It is a balance to do things right, and generally multi-methodolgy is the way to go.Very hard disagree on this.
Whoever taught you that Agile is something that you can do or that is a methodology or framework like some kind of cooking recipe, was selling you snake oil. The Agile Manifesto is over two decades old and people apparently still haven't understood it - or are deliberately misrepresenting it. It's far more fundamental: Either you (meaning your organization) are agile or you are not. If your work adheres to the twelve principles outlined in the manifesto (or at least most of them), then you are agile, no matter what framework you are using to structure your work. Scrum is just a methodology that developed from the agile way of thinking. But you can be agile doing Kanban or XP or yes, in parts even waterfall.
I have done long term projects in an agile environment with a team doing Scrum. Notice the difference: the environment (the organization, the system within which you act) IS agile (meaning it and the people within it follow the principles). The team is DOING Scrum. There are a gazillion teams out there doing Scrum but that are not agile. They go through the motions, they work in sprints, but it's all meaningless and in the end these teams end up going over budget, over time and not meeting their goals and everyone is wondering why.
So how did we do long term planning ("roadmaps" if you will) with Scrum? It all boils done to setting the correct goals, rigorous prioritization and constant application of the maxim "inspect and adapt". Instead of meticulously defining what the OUTPUT should be, the long term strategy must focus on OUTCOMES. Which is why the role of the Product Owner is so important when you are working within the Scrum framework. This role has to constantly prioritize the backlog according to the desired outcomes. The dev team is responsible to generate the output that iteratively gets the software towards the desired outcome.
In the end, the customer does not care about waterfall, scrum, kanban, whatever. They want to be able to reach their business goals and the software you produce needs to enable them to do so. Most customers engage in the fallacy of coming up with specific features and asking developers to implement those instead of saying "I have this problem that I need solved" and the specialists, the software developers, take care of the solution. I mean, nobody goes to the doctor and says "I need you to perform procedure xyz on me". No, you go to the doctor because you have some weird symptoms and want them to go away. The same thing needs to be applied to software development. Detailed upfront specifications are mostly done to reassure everyone that things can be planned in a world that is very unpredictable and ever changing. "No plan survives first contact with the enemy", as the old saying goes. As soon as the customer sees the first draft, they will want to change something. Having an Agile mindset enables your organization to adapt to this type of changes instead of slavishly following a rigid plan. In the end the goal must be to deliver the highest possible value within your software.
-
16 hours ago, Spicat said:
@ShadowZone, moved your bug report here, I think this is a more appropriate bug report for your report to be merged in.
Not sure the previous one it was merged with or this one apply. It happens really just right after loading up the game and then loading a save game with a craft that is prone to kill itself. You can see in the video that the game still slowly builds up the vehicle, making the parts appear over the first couple of seconds and then destroying itself. My assumption is that the game is still loading some physics stuff in background and once it is finished, it all applies at once to the vehicle, overloading it. Reloading the save always fixes it. Always. And it never happens afterwards, even with hours spent using that vehicle, hopping from it to others, docking vehicles to it. It only happens right after starting KSP2 and directly opening this save file.
-
I don't have any hard data to contribute but I can confirm that this has also happened to me.
-
Reported Version: v0.2.1 (latest) | Mods: Docking Alignment | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459I already reported a crash when docking something with 2 ports. After restarting the game it worked, but I tried to add another piece and then the crash happened again. So it is reproducible. Please merge with my previous report. Thank you!
Just logs this time, no additional video (but it does exist if needed).
Included Attachments:
ForSci_Bug45-DockingCrash2_logs.zip
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459Load the save game from the bug package right after starting up the game. It will result in disintegration of the vehicle. Load the game again and suddenly everything is fine. See also video.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: Docking Alignment | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459I am building a complex ring station. The final pieces need to dock two ports at the same time. The vehicles glitched into each other, the game claimed there was a successful dock (see "clonk" sound in video), then the game crashed (see log in bugpackage).
Included Attachments:
-
22 hours ago, ShadowZone said:
It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).
I just want to add that with mods like Flight Plan you can still create maneuvers that exceed the displayed dV of your vehicle. So the functionality IS in fact still in the game, just blocked when manual user input is applied.
Again, please change this. It's fine to show "vessel will run out of fuel" or some other kind of warning, but straight up preventing people from doing something that in fact does not hurt their gameplay is just wrong. I know it was said this is because something with interstellar later down the line, but even then I cannot imagine what this might be.
-
26 minutes ago, KUAR said:
At risk of deviating from the topic, have you ever tried running scrum for a hybrid software/hardware product which is subject to waterfall procurement and agile development (internally)? Really struggling to mesh the competing frameworks!
Unfortunately, no. I have only worked in software projects over the course of my career, no hybrid or hardware. But I was involved in a big project where our team was working agile and the rest pretty much did waterfall. The biggest challenge was syncing up with the other teams that worked differently.
But here is where one of the creeds of the agile manifesto help: "people and interactions over processes and tools". We tried to get in touch with the right people and managed to work with them, no matter what framework they were using. It was still challenging, but defining the interfaces between teams and having constant communication helped.
-
43 minutes ago, Darta01 said:
Ah yes! The maneuver planning tool that does not allow you to plan maneuver!
This is a terrible design choice
I just have to add my voice to the people asking for #20 to switch from "works as intended" to "redesign going on based on player feedback".
It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).
Please change this!
43 minutes ago, Sade said:What is sprint planning?
In modern software development and especially when using a framework called "Scrum", the development team works in short increments, usually 2 to 3 week cycles called "sprints". At the beginning the team pulls from a prioritized backlog what they believe they will be able to achieve during the coming 2 weeks. The backlog is usually prioritized by a product owner based on business value (based on answering the question: what will provide the most value to the customers/users of the software?).
This process of picking the body of work for the next sprint and committing to it is called sprint planning.
After a sprint, the development team presents their results and gathers feedback and after that usually sits down and discusses what went well and what could be improved in the upcoming sprints.
Switching to these shorter development cycles enables software companies to get feedback faster and improve on software faster than working months or years in the blind and then having to rework a metric ton of code at once if they realize they messed up a foundational feature.
At least that's the theory. Most software companies/teams use some variant of this process.
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459I made a mistake during a complex build and pressed "CTRL+Z" to undo what I did. That worked fine but afterwards I was not able to place parts in any symmetry anymore. This only got better after relaunching the game.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459Load game, wonder why dV says 0 (instead of over 5000), go into map view to find a completely absurd trajectory that looks like a wreath made out of infinite short lines.
Can be remedied by loading other save games or the same multiple times. See video for details, logs attached.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459Situation: retrograde orbit around Laythe. I want to flip the trajectory, so there is a maneuver plan already set in the attached save game. When performing the burn, the game always refuses to do burn under timewarp in this situation.
Being around Jool generally seems to trigger this bug very reliably.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459I have put a vehicle with multiple hydrogen tanks in an almost polar orbit around Jool. When returning from map view (but also on other occasions) the reflections on the tanks start to flicker like a strobe as if they were turned on and off.
Logs provided are from a playthrough with mods, but it also happens without mods.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: BepInEx/SpaceWarp, UitkForKsp2, MicroEngineer, LazyOrbit, AlarmClockForKSP2, DockingAlignmentDisplay, node_manager, maneuver_node_controller, flight_plan, K2D2 | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459Got my rocket on the pad. I hit "go" and one pair of rover wheels just falls off. Flight Report claims that they overheated. When I turn off part overheating, the message claims that they crashed. Logs, save file and workspace are all in the bug package I uploaded.
Included Attachments:
-
9 hours ago, Nate Simpson said:
Shadowzone is dunk-drunk, and now seeks out puddles across the Kerbolar System!
I feel exposed
Happy KSP-niversary to Nate, Dakota and the rest of the entire team! Looking forward to what you'll deliver this year!
-
I apologize if this is already written somewhere and I have glossed over it, but: transfer from moon to moon (e.g. Vall to Bop) is not yet implemented or is that one of the bugs that are currently open?
-
6 hours ago, Scarecrow71 said:
Sigh.
Sorry, but this isn't my first rodeo. Yes, time warp is set to 1x. I've tried space bar, opening PAM, save/load, save/restart/load. NOTHING WORKS. Period. Chutes do not open for me, which makes the game unplayable. For me. And the fact that it broke with 0.2 and didn't get addressed in this release is disappointing; I dislike having a $50 piece of software i can't play.
Just out of curiosity (and sorry if you already said that previously): do you stage parachutes while in atmosphere? Since 0.2.0 I had severe problems with chutes when staging them while in atmo, but when I stage them while still above 70km (at Kerbin), they usually work fine.
I had various combinations of that but: total failure, only drogues failing, half of my chutes failing, chutes opening way too late (past 1000m) etc. I agree, it's pretty infuriating, but the "stage while still out of atmo" thing has helped me.
-
Nice, about 6 weeks after "For Science" came out, we have the first patch quite a few issues I encountered myself are (nominally) fixed. Haven't been able to launch the game yet, but that will change soon
As per usual, here's the bugfix stats:
Version Total items Community % of total 0.1.1 281 42 15% 0.1.2 173 36 21% 0.1.3 165 17 10% 0.1.4 81 9 11% 0.1.5 86 11 13% 0.2.0 156 0 0% 0.2.1 68 14 21% While the patch with the least number of changes, we have to consider that the Christmas holidays and New Year's was in between. Also a lot of issues that were found and fixed thanks to the community.
Some more numbers:
Including the initial 0.1.0 release, we had 8 releases since February 24th 2023. On average, that's almost 7 weeks between releases.
Soooooo, mid March for 0.2.2?
-
Great update all around! The game still needs work, but I like to see the progress made.
Here are some stats in regards to bugfixing:
Total items Community % of total 0.1.1 281 42 15% 0.1.2 173 36 21% 0.1.3 165 17 10% 0.1.4 81 9 11% 0.1.5 86 11 13% 0.2.0 156 0 0% I'm curious: the rocket icon signifying fixes that were aided by the community is missing in the current release notes. Is this deliberate or an omission?
-
7 hours ago, Intercept Games said:
Heya Kerbonauts and welcome back to the K.E.R.B!
After the doozy of the last K.E.R.B. update, we have somewhat of a shorter post today. v0.1.5 has been out for two weeks and we've seen so much more engagement with the K.E.R.B. this update than ever before. As always, thank you so much for reporting and upvoting bugs - it truly helps the future development of KSP2
Last week we shared a major change to the K.E.R.B.: removing entries that require fundamental feature overhauls. You can read more about the justification for that change in the last update, but one of the things we did commit to was to provide insight on the issues that we remove from the list when we have notable updates. Thus:
Wobbly Rockets: Improvements have been fully implemented (see the video in the last update) and are ready to ship for For Science!
Calculating Physics of all parts of all Crafts: Improvements are fully implemented and are ready to ship for For Science!
Surface Rendering Fragment Shaders are Inefficient: We believe this requires some reevaluation by fans post v0.1.5 as we implemented mesh bucketing for terrain which should have significantly impacted the original issues.
Camera Resets Position Map View: Has been "upgraded" to this list as it and many other camera issues are planned to be addressed in future camera systems work, scheduled for post-For Science!
And now to the list:
Current Top Issues:
Note: this report is not fully representative of the work our team is focused on. This is just to provide insight into our progress on the most concerning issues to our community. Additionally, the lack of a status update does not imply a lack of importance or general progress - we just do not have anything to share at this time.
Lastly, we've opened up a K.E.R.B. feedback mega-thread so if you have any suggestions, please let us know. We're planning for some pretty significant changes to the K.E.R.B. post-For Science! and, as this is a collaborative effort between the community and the dev team, we want to make sure you all have a voice in the way we approach bug reports moving forward. Appreciate it!
KSP Team
Thanks for the update!
Question about process: I know the "floor hugger" regression we discovered does not have as many votes (yet?) as some of the other bugs listed here, but is it still treated with higher priority internally since it is a regression (at least the effect of the bug, maybe not the source of it)? @The Space Peacock said in a comment that there has already been internal analysis, so that's a relief!
Just trying to find out if we can expect this to be fixed in 0.2.0 at the latest.
7 hours ago, Dakota said:Going to call out the three issues that are asking for information. If you've experienced these issues in v0.1.5, please let us know!
I can make #1 happen with a specific vehicle all the time and have attached save game, logs, workspace etc here:
-
@Anth / @The Space Peacock I can trigger the orbit trajectory lines disappearing every time by launching my current Buran/Energia iteration. Load up the save in the bug package attached below, try it with a simple rocket (see video) --> orbits look normal. Then revert, launch "Buran Energia v2" and you will see that the trajectories are gone. Happens every time with this vehicle.
See also video below.
Bug Package with save game that was created fresh for 0.1.5, logs and workspace: https://drive.google.com/file/d/1sL7KWPWteFqxIPzaG4CXEJEK46IEW1KQ/view?usp=sharing
Reported Version: 0.1.5.0 | Mods: none | Reproducible without mods? Yes | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459 | OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit
-
9 hours ago, The Space Peacock said:
Don't worry about it, i'll have a look myself when i have time (probably also not within the next 16 hours xD). i've also passed this report along to the devs. it's a pretty serious regression
I got a few minutes, and yes, the workspace added to the crash bug immediately triggers the "floor hugger" when removing a part and pressing CTRL+Z
Eclipse is not shown in Map view
in Environmental & Terrain
Posted
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459
As you can see in the video, I started on the night side of Pol. I placed a maneuver node on the day side and time warped to it. There was some changes in illumination, for instance indirect lighting on the vehicle (light reflecting from Pol towards the "belly" of the ship), but the sun itself was gone. Switching to map view revealed the sun there, but it stayed hidden in flight.
Logs, saves etc attached in the .zip file.
Included Attachments:
ForSci_Bug48.mov
ForSci_Bug48__SundisappearsatPol_logs.zip