KUAR
-
Posts
63 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by KUAR
-
-
2 minutes ago, Westinghouse said:
See, I think this is a key thing that needs to be communicated - has Intercept Games completely closed down completely and the staff on paid gardening leave for two months? Or will they at least spend until the end of June working to deliver us some sort of version 0.3?
The reason this matters, we deserve to get at least something of what was promised and we paid for. Two months would at least give them time to deliver something along the lines of an orbital VAB and whatever they had planned for colonies.
In addition, maybe they won't have time to implement Interstellar travel, but maybe they could at least put in some sort of Warp Gate orbiting around Eeloo ( à la 2001 or Star Fox 64 ) so we could at least jump to the Debdeb system and visit Glumo, Ovin, Charr, Rask and Rust and whatever other planetary bodies they had planned. Obviously a Warp Gate isn't what we were promised, but right now it seems like the only short term solution. It would be a giant waste to never get to see all those celestial bodies and artwork the artists spent years creating.
Sorry to say, Westinghouse, but if it is cancelled the chance that any of that will happen is next to zero surely.
-
27 minutes ago, ShadowZone said:
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!
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.
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!
-
For me, the fun is about discovery. I don't think we need more planets, but I regret that we can see the current ones as clear as day from the KSC, mission control and the tracking station.
I wish that we started out not knowing anything more than Kerbin, Kerbol, Minmus and Mun. Everything else needs to be discovered. We can get a rough, grey-ish indication from a space telescope; we can get more information by flybys; more by putting a scansat into polar orbit.
That way, every mission adds something to our picture of the cosmos.
The concept could be extended to Interstellar. Rather than identifying a specific planet, perhaps we only know that there's a star our there. We need to send a probe to figure out what planets there are and their orbits, and whether they have atmospheres.
-
On 1/6/2024 at 5:21 AM, ArmchairGravy said:
This is the first time since .1 I'm having more fun than frustrations. I'm playing both Sandbox and Exploration, and I am very happy with what the team delivered in the .2 update. I am impressed at how few additional bugs were introduced, and how many long-term bugs have been eliminated or ameliorated.
The UI is in dire need of an overhaul. The more I progress in the game the worse it gets. Why isn't there an alarm clock and transfer window/angle calculator in the Tracking Station? Why don't I have access to advanced orbital characteristics? You want to improve the initial user experience. You want them to use external sources to access basic knowledge. That's contradictory. Put the info in there, somewhere. I don't care if it's pretty as long as I can read it.
Overall, I'll give the team a "That'll do, pig" for .20 and I look forward to seeing what 2024 brings.
Upvoted for the "Babe" reference
-
This is listed in "known issues" on the release notes
-
I have also seen this bug
-
I have also seen this bug
-
That's good and I agree...but figuring out the new drag cube maths will be interesting!
-
On 12/10/2023 at 7:43 AM, Periple said:
It is going to be tricky! Maybe some kind of physics LoD system where parts are auto-welded to cap the physics part count at some reasonable number? From the player’s PoV there isn’t much difference between a craft being simulated as 100 parts instead of 1000 parts.
This is honestly the only way I see it working and I (perhaps naively) think that it should work. Perhaps it's an extension of sub-assemblies: you can define an assembly which is a rigid body, with a single resource storage/generation/specification characteristic, etc. etc.
There would of course have to be limitations - decouplers/docking ports couldn't be in the middle of your assembly for instance, and perhaps it's progression-locked (rigid sub-assemblies up to X tonnes/Y parts, upgradeable like the VAB size/part count limits). It could also be limited to a certain percentage of your overall craft's mass or part count.
I can see that it would be complicated to implement with e.g. aero model, parts manager UI, etc. etc. but I see it as being the best option. A small number of large monolithic parts doesn't interest me as it'll kill variety. If they're going down that route then serious investment in part development would be required.
-
As a person who generally errs on the more positive and optimistic side for KSP2, sadly I've been a little underwhelmed at the imagination that the new science mode appears (at first glance) to exhibit. Then, positively shocked at the clunkiness of the work in progress reentry heating animation! I expect it will be made a little more slick before release but right now it looks like the graphics design apprentice did it as homework.
Sorry, I know there's probably a committed developer on the other end of it, and I'm sure there's complexities I've missed...but that's how it looks to me.
-
I disagree. I'm fine with being punished for forgetting to do this at the right time. It's realistic - we've lost control of the probe. Allowing us to deploy them after that is cheaty like the OP implied.
Now, there's an argument over whether some models of panels have some exposed area even when folded away - that's fair.
-
Better - scrap the current method and have a kerbal placement dialog after hitting the launch button. It's something I forget to check far too often.
I'm launching an unmanned rescue mission only to discover all the seats are already occupied by hitchhikers...
-
Before I start, I'm of the view that KSP2 should be aiming to differentiate itself from KSP1 and with the first two milestones it feels like the aim is to create a remaster rather than a sequel. It feels like the team is a little afraid of changing too much look and feel - although perhaps they have their hands full with the under-the-hood changes that are needed for the later milestones.
I'll also deliberately avoid commenting on specific parts, and gameplay mechanics that conceivably could be in announced milestones. That's a separate thread I think - e.g. "how should colonies work".
That said, here's a list:
- Take the most popularly-installed mods from KSP1 and bring them into core. The ones on my mind right now are procedural parts; docking port alignment; KER; etc. Specifically, I can't see a good reason why not to have procedural tanks, even if it's of a set diameter and variable length. Adds some graphical challenges for the part modellers but as a gameplay mechanic and general tidy-up of the parts catalogue, invaluable.
- More reasons to progressively explore planets with different science experiments to enable future exploration/expansion. For example, off the top of my head - we can use a drag prediction tool so we can get the right parachutes config...but only if we've measured the atmosphere composition at the relevant altitudes. We can EVA...but we need to have measured the temperatures, radiation etc. so we can "have a suitable spacesuit". I'm of the camp that says it doesn't have to make perfect scientific sense. It's a game and they rarely are completely logical. But, if you could imagine yourself convincing a five-year-old that "we need to do X so that Y can happen" then that's good enough.
- Mission planning tools. I've mentioned parachute predictions earlier - it's disappointing that we need to guess the number. Equally, landing stability calculations - will my craft balance OK with this much fuel left on this angle of slope (ok so perhaps we have CM indicators for that, so never mind). I'm not sure how realistic re-entry will be but do we need to identify how much ablator we need? Heat/solar management predictions. I know we can go get a notebook and calculator for some of this, but some in-built tools would be really cool.
- Ability to rotate docking ports once docked, or they snap on docking to the right orientation if you're close. If I'm building in orbit, I want to be able to get the modules of my space station lined up right. Aah dammit, just generally more support for orbital construction.
I'm now moving away from the things that have bothered me, and am now into the realms of pulling ideas out of thin air...
- Auto-adjustment to achieve a given CM or CT. If you're creating a non-symmetric design, when you thrust up it can start to rotate (obviously). Tools in the VAB to offset certain masses or thrusts to achieve alignment (might need to assume a certain fuel load) would be handy. Later, Auto-adjustment of engine thrust per-engine (or per symmetry set?) to maintain heading - we can do it with RCS, reaction wheels and gimbal but not dynamic thrust adjustment. Perhaps only certain engines can support it for "technology" reasons...
-
-
I can' believe we ever used to build wings from multiple fixed panels and it's revolutionary* (now one of the wings doesn't think it needs to be upside-down in the VAB).
*no pun intended
-
15 hours ago, PDCWolf said:
It'll never be compatible to me to hear "I have 30 years making games" and "we underestimated by a huge margin how long it'd take those tasks to be completed. In this case it was 4 years".
At least this interview puts the "wahh rushed into EA by evil t2" cries to rest.
I don't think those are necessarily incompatible. I don't work in the industry but I do work around Agile software engineering. I can see how 80% of big games out there are basically the same and how KSP2 is novel in many ways. That's why we love it and why we're excited about it.
Platformers, first-person shooters, open-world exploration, and real-time strategy. They've been done many times before. I reckon an experienced developer could put a pretty good estimate in terms of sprint points on how long it would take to develop a new level in COD 14 (Modern Warfare 5) for instance, or to develop a new diplomatic feature in Civilisation 8.
In contrast, how long is it going to take (for example) to develop a new manoeuver system which (unlike KSP1) double-integrates the acceleration over time in two orders, taking into account staging and mass changes, and god knows how many other external dependencies, to figure out a predicted orbit after burn; present it in a user-friendly way; and provide tools to support execution? When you think about the engineering challenges, re-designing that particular system so that it supports long and slow interstellar burns (DAWN-like) is actually a real headache with a lot of dependencies and unknowns, which hasn't been done in gaming before. The KSP1 equivalent now looks trivial.
And that's just one example - I'm sure there's others. The mechanics for interstellar, time-warp enabled multiplayer while simultaneously supporting automated colony/resource routes are a bit mind-bending. And I suspect they've been re-building all the base systems to support that.
So, I'm not surprised that estimating on this job is an absolute nightmare. We had an equivalent in our business recently - on a multi-million pound programme, where we're supplying subsystems into to a high-profile larger system, we under-estimated by a factor of three the complexity of doing one particular work package because we didn't understand the problem well enough. And a supplier to us, to whom we'd passed derived requirements, fluffed it even worse.
-
My views are that it's got to happen soon as people are "played out" in Sandbox right now. There's no point waiting for things to be perfect before adding features, just stable enough that you're not trying to build a house on shifting sand.
-
It's looking great! I actually played a relatively complex mission and most of the issues I was running into were design issues, rather than bugs.
I'm getting a weird bug where after timewarp some of the stacked parts aren't centered however a save and reload tends to fix that.
But, that was nothing compared to the multiple reminders that I need to consider the relative positions of centre of mass and centre of drag - both into and out of Duna's atmosphere with my crewed lander! I now remember the frustration of ship design rather than just the frustration of bug avoidance...
Performance is better but still not great and weirdly worse in map view?
-
10 hours ago, Alpha_star said:
Yes. They are mentioning an "upcoming hotfix" in the IG discord. You can actually see what the developers are posting on Discord here in the Forums by visiting the "Discord Dev Tracker" section which is on the right side of the screen if you use a computer and all the way down to the bottom in mobile version.
Digging up pat track record is probably a bit dumb, but seeing that past hotfixes include two bugs, I'd bet that this upcoming hotfix will likely include more than one single bug fix. Maybe orbital decay since they are already testing a fix two weeks ago. Just maybe.
Thanks, quite familiar with the Discord tracker - and so know there's a hotfix planned. But like you say, past track record of number of bugs per patch is dodgy ground for an extrapolation!
-
2 hours ago, Alpha_star said:
Good news! They are actually planning on a hotfix dedicated to solve the spamming bug and (hopefully) some other game-breaking bugs as well. I hoped in the 0.1.4.0 release thread that they could deliver another hotfix like done in the 0.1.3 era to fix the annoying orbital decay bug, and it seems like they are going to do something similar! Would be really nice if they could actually squash that very bug in the upcoming hotfix since that very bug is what's keeping me from playing KSP2 since the end of summer vacation.
I've not seen any evidence that they're hotfixing anything other than the registry bug. If you've seen it, I'd be excited - but like many others, I've actually put KSP2 to bed until at least v0.2.0
-
10 minutes ago, didkodidko said:
Any news on 0.1.5? Wen?
The last stated plan was 6-week intervals between releases. I've no idea if that's still the target. If so, that would place 0.1.5 on or about Friday 13 October.
-
I'm very interested in anything which adds progression, and limits visual interest until you are there in-person.
It's why I've mentioned in the past that I'd really like a "simulation mode" where you could check if something would land/take off from, e.g., Eve without spoiling the visuals by warping to re-entry and skipping the journey. The more you probe/scansat/science your way the more accurate your simulation mode can be.
I really like the idea that unmanned missions have limits/drawbacks but I agree, an optional setting. Flying solely off telemetry might be fun initially but does take away from the point of building pretty spacecraft.
-
11 hours ago, Nertea said:
An overall question I'd like to answer is whether you feel like this dev blog was a useful thing for me to put together. Given that my role on the KSP2 team is as a designer, I'm limited in what I can write about, and thought I'd try a long-form design document. If it was informative and interesting to read, I've accomplished my goal, but it is quite a time sink to write long things.
Well, I believe the devlog is pretty clear about allocating the radiator stuff for release around the Colonies update there
.
These are EXACTLY the stories I am excited about with this system. Reentry can be an interesting challenge, but ultimately it gets solved the same way every time - you use a heat shield or you keep your speed low - hard IRL, trivial in KSP. When you get that complex environmental context going, you start to have more options and trades to make about where you site something.
Ultimately I'd eventually like thermals to be as varied as engines in terms of problems to overcome. Just like engines have different situational uses and different requirements around sizes and fuel types, different cooling methods and approaches should be valid in different situations.
I'd place that in the 'computationally complex and challenging to make performant' category.
Fair. And I'd take the simpler system any day, if it will be computationally more efficient - I'm sure we can agree that performance is something we need to be cognizant of.
I would generally argue that heat in KSP1 has no practical utility outside of reentry and stars, because it vanishes when a vessel isn't focused, and reverts to analytic mode when you're over 1000x warp anyways, which disables conduction and replaces it with an approximation. The system is tuned so that the only time a player needs to interact with it is during reentry and atmospheric flight, which it succeeds very well at (this ignores the core heat system that runs drills and such which is completely different). I'd like to do better than that.
I doubt we'll convince each other here, but I hope we can demonstrate that as we deliver the system over the next few milestones that it makes for interesting gameplay.
Chris, thanks for an informative and interesting Dev Blog.
I'll be honest, my initial reaction was "sounds like an oversimplification" but having considered it a bit more I think you're on the right track.
Some people are complaining that by not modelling internal conduction you're allowing designs that weren't possible before. However genuine systems would always be able to factor in active cooling to radiator panels, so I think that's OK. In fact KSP1 had just such a system which led to the same results with a far higher calculation overhead.
I think that perhaps, with some refining of parts' thermal generation and emission rates in different scenarios (sunlight/shade/atmosphere/vacuum) it is a pretty solid basis. People harp on about realism but wouldn't recognise it if it slapped them in the face - KSP1 heat model was far from realistic in some ways and people were quite happy to learn the rules of the game in those cases. If they want more details, then they can wait for modders to get their hands on it.
As for was the blog worth the man-hours and the subsequent grief from committnegatives, I think that for your own sanity though sadly perhaps the time is better invested in developing.
-
2 hours ago, Nicrose said:
That could be it, it's been a long time however tbh I don't really remember getting too into mods. I found an image from a youtube video of what I'm describing though! I coulda sworn this was stock but I'm second guessing now with how many people don't know about it lol
Just posted one in my last comment
After checking out that mod, I can confirm it isn't that mod. It may have been another one I suppose but definitely did not use that one.
Well in KSP 2 I am forced to do that but idk, I just enjoyed the other perspective and the 2D representation of position resonated with my brain better
EDIT: Just looked on the KSP Wiki and found the page talking about it. It turns out it was in fact vanilla KSP!
https://wiki.kerbalspaceprogram.com/wiki/Docking
https://wiki.kerbalspaceprogram.com/wiki/File:Docking_lin.pngAh yes, now I do remember that. I just never used it really, found it awkward and preferred the modded one.
-
On 7/14/2023 at 6:17 PM, Nicrose said:
Is it just me or does anyone else miss that docking window visualization? I thought it was very helpful and intuitive when docking and using the controls for monopropellant thrusters. Is it permanently gone or just not added yet?
I'm with the others above, I reckon you installed a mod and got so used to it you forgot it wasn't stock!
I know the one,it is good and definitely a valuable feature
. 
Kerbal Space Program 2 (Version 0.3.0 and Version 1.0.0) Hype Train!
in KSP2 Discussion
Posted