Nertea
-
Posts
4,722 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Nertea
-
-
On 8/18/2023 at 10:16 AM, regex said:
Just want to point out that the answer to this question was made without the additional caveat below it; my "user story" is creating a good looking R-7 rocket (basically a Soyuz, for the uninitiated) from actual fuel tanks (not random, spliced-together parts that add mass) of any desired size. There isn't enough variety of parts to do that. There are several ways to achieve this (additional tanks, part switchers, actual procedural tanks) and I suppose I should have asked directly about my "user story", because I'm not opposed to the LEGO thing, I just want more variety in fuel tanks without the ridiculous clutter we have now.
I hear ya, and the R7 is almost the worst-case scenario for this. It doesn't fit in the .625, 1.25, 2.5, 3.75, 5 pattern well at all. It has weird cones. It is... honestly best left to procedurals.
One thing I do want to highlight is the poor user transparency of part variants. This has to be better than the PAW stuff in KSP1 if we do it. I was always shocked at how many people when using mods/even stock just... didn't know it was there as an option. That's not very discoverable or useful.
On 8/18/2023 at 2:14 PM, 1straycat said:T_T
I guess I'm one of the three people that really liked that mechanic then, particularly with trimodal/bimodal nukes. Coming back to the game after that was patched out, I tried to recreate that functionality but haven't been able to figure it out.It's something that I found theoretically fun, but then when I actually tried to play a campaign more than a single mission, I found infuriating. Same thing with the short-lived 'use a kerbal to transfer a nuclear fuel container' feature.
On 8/19/2023 at 10:10 AM, PDCWolf said:This AMA was extensive, in depth, but still weak, as that depth is on what I gauge are the wrong places: personal stuff, personal wants, personal dreams. Also for the next time, I'll make sure to submit my questions to Kavaeric or Spicat.
There's the loaded question about the heat system, which is a simplification of the one we had yet it still comes loaded as "complex". From the thread on the heat system it became clear to me everyone is ready to answer to praise, but nobody was ready to answer genuine questions or respond to possible criticisms or player concerns.
I wanted to make sure the text question dump was in before responding to this, but asking viable questions for AMAs does require some crafting. In an hour I can't answer a ton of questions that are say, 5 minute answers, but I can answer a lot of 60 second questions, so those are the ones I'm going to pick. I'll leave the ones that were more complicated to a text answer where I can think on the response and actually give you detail. In addition, questions had a LOT of duplicates, and we tended to trim ones that were very similar and pick the one that seemed most productive to answer. We've also got the discord/forum volume differences here, and honestly the forum ones do trend to be a lot more detailed. So, text answers. Finally well, loaded questions... would you pick those to answer?
On 8/21/2023 at 4:07 PM, PicoSpace said:"Colonies: "We are designing...". Bad. I prefer to think it's just a missed form of speech than really starting to design colonies now." this and Multiplayer have me worried that they have an "idea" of what they want to do and they haven't figure out how to do it yet. Given these are the two of the tent-pole features for getting KSP2 over KSP1 in term of new stuff, its concerning.
I checked the answers to make sure but I just wanted to make it super clear. Stuff exists. A repeated set of challenges we have are (1) making sure things fit logically into our EA roadmap (we need XYZ before releasing ABC), (2) orchestrating things so features that are built up over a few updates work at all stages of the roadmap and (3) reacting to feedback and taking redesign actions based on that. We are quite happy with the end state design of Colonies, but that doesn't mean that there is no design work to do.
On 8/22/2023 at 9:41 AM, shdwlrd said:Love the fact you have to use the polite corporate speak of "It's not happening."
Sadly, yes.
3 hours ago, Pthigrivi said:@Nertea My god that was one of my favorite dev posts ever so thank you so much for taking the time.
Cheers, I like writing about work.
On 8/23/2023 at 6:09 AM, PicoSpace said:Given most of my questions didn't get answered, I concur. I'm really trying to be positive about this game
I think we may have compressed some of your questions as they may have been similar to others. Did you find what you were looking for in the expanded answers?
-
Answers to some questions we had to skip over during the AMA but I still wanted to get to:
Alexoff
What percentage of the parts in KSP2 was created by you personally?
Depends how you measure it. Effectively zero because I don’t do the asset work, by one definition. In terms of maybe inception/concepting, in the EA release I’d say I had a hand in about 10%?
What is the largest part will be in KSP2?
The largest part I have in my list right now is in the 80m+ size category. It’s a lot harder to measure these colony parts versus vehicle parts though…
Do you participate in the creation of parts for the colonies?
I participate in the concepting and design phase yes. It’s where I’m focusing a lot of my ‘thinking time’ these days. Colony parts are both similar and different from vehicles – in what they look like, how they assemble, etc. As we get to those milestones we refine our designs from player feedback.
How difficult is it to add a new part to KSP2? Is there a big difference? Is it harder than creating a new part for KSP1 for a modder?
Most things in KSP2 end up being more complex than KSP1. As an example at a basic level the PBR shading model that we use requires more texture maps than KSP1. That is mitigated by having access to internal tooling and a faster iteration loop (click Play in Unity rather than load the game).
Stephensan
is there any more concepts for more air-breathing engines like the J-90 smaller or larger
There’s been team interest in larger air breather engines, but as always that’s not so simple – adding an air breather of say, 2.5m size requires us to also look at the supporting parts in that size, like intakes and cockpits, so the player can have a good experience when using those engines. That balloons the required work significantly.
I would want to push out the different technologies rather than footprints first. Nuclear jets, propellers, all unlock interesting new player stories!
is there gear that is going to be angled from the fuselage not straight up and down and finally more tires/wheels in the concept stage, or even remotely thought of...
We definitely have people who want that on the team
.
LunarMetis
How will the sizes of different stars be scaled with respect to Kerbol? Will they be scaled at 1/3 their real-life analogs like Kerbol and the Sun?
Specific scaling of the actual meshes is less important than defining their specific insolation numbers for input into solar panel math but yeah they’ll be Kerbol-relative.
How do you plan to implement proper motion of other star systems, and how do you expect that to add to the challenges of interstellar travel?
Hah, interstellar travel is going to be hard enough already. Proper motion is something we need to balance carefully there.
Pthigviri
Hi, Chris! Im sure you've been deep in colony part design. What are your thoughts on greenhouses and simple life support with snacks for example? How do you see conveying that colonies are both real places where kerbals live and 'working machines' much the way vessels are?
Honestly I don’t like basic life support (by basic I mean something like having Kerbals on a ship consume a resource). I’ve played all* of the KSP1 mods for it, and I haven’t found something that is interesting and holds my interest beyond frustration for more than a few hours – just not my cup of warm beverage.
More seriously though, systems like this need to have a bunch of considerations:
- They need really carefully crafted player stories. Those stories need to support lots of different player archetypes – not just advanced players.
- They often should work on a carrot rather than stick-based approach. KSP has a lot of sticks right now.
- They need scalable solutions that are plannable and toolable. That’s a big thing and that’s where LS gets expensive in dev-hours
We have some things in the works around Colonies that ape some of the ‘results’ of life support, which I hope will get at the idea of colonies being a little more kerbal-involved than just plunking Kerbals in a command part.
* I think all? It has been a while, maybe some new ones have cropped up.
PDCWolf
Has the concept of heating changed at any point based on the feedback posted to its thread?
I read every post in the thread, which was nontrivial because it was a long and uh, vibrant thread. The short version is no, the long version is yes but…
A lot of the interesting discussions sat around things that are further down the roadmap, and they provided us with a couple additional things to consider. Interestingly, the player stories we have were well aligned with the comments that I read, but the way the player stories were addressed were not unanimously approved. That’s fine – part of the EA conversation– and in particular with a lot of discussion being on items later in the roadmap, this makes me confident in the iterative model.
We’ll get the basics of the system focusing on reentry stories out to everyone. We’ll evaluate how that works with the playerbase. As we move towards the next milestones, we can use the information encoded in the thread, which I’ve collected internally, to make sure we’re making choices (engineering or design-wise) in conjunction with the feedback from reentry to get good solutions. One thing that jumped out for me was that there’s a lot of talk about macro vs micro solutions. I’ll be the first to admit that the current solution is a macro solution. So future design work will probably focus on whether there’s more microscale interaction to look at.
If I know the peak or average specific heat flux a vessel is gonna go through on its final orbit/landing spot, what stops me from just adding enough negative heat flux parts to counteract it?
Nothing. That’s what you should be doing. Of course, it’s not really that simple. If this is atmospheric heat from going fast, adding a big radiator is likely to just increase the amount of next flux, because it has a large surface area. Most heat mitigation tools need something else too – a radiator might need electricity, which means you need to supply that, which will enforce additional constraints.
Considering its possible uses on the automated logistics network, long missions, and just straight up anything that only requires time to pass, how do you balance not timewarping versus just letting things happen in ultra-fast time?
These are the best questions because they’re the hard ones. Often we trend towards supporting a player path that doesn’t reward excessive timewarping, but doesn’t exclude it either. A good case study is resource extraction and deposit concentrations. There’s definitely fun in seeking out and finding the best deposit for mining. Obviously though timewarp makes that kinda moot in timing. You could just start mining a hypothetically low-grade deposit and warp for 50 days. That tells us that time and rate -based mechanics need to have more to work well. A specific example here is that a newly accessible resource should be constrained differently – challenging location, resource transport limitations, etc.
We try to move the real player decisions to things that are interesting with and without time as a mechanic. Mostly hypothetical examples, but here’s a few ways of thinking of these things on top of my head:
- Put a locational constraint on something. If you need to do something in orbit over a specific part of a planet, make it take longer than the average orbital cycle. This might encourage a player to put a satellite in GEO orbit over that place. If you do the work to put it in GEO, you get the benefit of being able to timewarp.
- Use binaries instead of gradients. Does ore concentration really benefit from a really detailed gradient from 0.0001% to 100%, or can you look at it as a yes/no? Trade that, see if you’re damaging player stories with that simplification.
- Use supporting systems. Sure, you could mine that deposit at high timewarp. But the deposit is on a planet with a day length of 200 days, and you need power, and the area has no fissionables. How are you going to power it? If you solve this problem, it is satisfying and you get a cookie. You did the work, enjoy your timewarpable extraction!
These are really big problems we look at for all of the more complex systems because hey, an interstellar transfer could be 100 years. Players will timewarp that and that’s… the whole length of a KSP1 campaign. Fun with and without timewarping like this is essential.
Socraticat
What are your favorite tips and tools for new modders?
My biggest tip is to do what you want to do and not focus on what others want. Lots of the most creative KSP1 mods didn’t hitch themselves to any one concept of the game, and that’s what made KSP1 modding so successful. You want RO? You’ve got RO. You want to launch kerbals in a cardboard box rocket? That’s there too. You want life support? Oh hey there’s about 5 different concepts out there to pick from.
Also don’t try to form a team day 1
. Get some experience, release some stuff, and the team will come to you!
Tools - Blender is an amazing piece of free software, and there are a ton of good coding tools out there for the software-minded as well. It has never been a better time to be an independent purveyor of these kind of things, you don’t need to suffer through e.g. gmax or the trial version of Milkshape3D anymore.
RoyalswissarmyknifeIs there any consideration of 1.875 meter parts
Building out a whole family of 1.875m parts that includes the core stuff (engines and tanks) plus the necessary ancillaries is a lot of work and not something the team is committing to right now.
StrawberryWhile we do know it wont be added in the short term, the team has previously been wishy washy if radiation/life support will make it into the game. Are these topics something that the team has decided wont be in the game until maybe after 1.0, something the team has a firm answer on what they want to do with but does not wish to disclose it (though if you do wish to disclose please do), or something that the team is geniunely undecided on
See answer to Pthigviri about LS stuff.Radiation is a bit more interesting to me because I have a fair bit of history in mods with it, and I’ve eagerly assimilated the early concept work the team has done for KSP2. There are two tradespaces in terms of vessel design, point sources and ambient radiation that we at least nominally want to think about including.
Ambient radiation is basically a time trade. How long can you spend in a radioactive environment? You can throw things like radiation shielding, storm shelters, etc but ultimately it all comes down to time to Bad Things. It’s harder to help a player to plan. You have to give them tools to determine how much radiation there is around somewhere and how to figure out how long they can spend there, etc.
Point radiation is nuclear engines and reactors. This is harder to implement but is definitely relevant in terms of craft design, because it is a big part of why fictional interstellar ships look the way they do. Interestingly it is easier to model and communicate to the player because you know lots of the variables at vessel build time. One of the messy things here though is that as soon as you throw in radiation, you railroad players into building ships with nuclear engines in a very specific way. We have to craft a solution that hits a nice middle ground. See this comment.
I’m candidly going to say that we don’t have the ideal solution in the bag right now – but that’s what EA is all about. I’m sure I’ll write some kinda discourse on radiation eventually for a dev blog and everyone can weigh in on why I’m wrong :P.
Pokaia
Are there any features you modded into KSP 1 that you are bringing into KSP2? What is your favorite?
I wouldn’t want to port anything specific without a good justification, but I really want to bring in more planning tools. The only ones I built were around heat and power management, but yeah. Something like that.
One of the cool things about this job is that I get to start again, so to speak, with the support of people who have been in the industry for a while. So if I want to bring in nuclear reactors, I can take my concepts from Near Future Electrical, talk to some Real Designers ™ and get their opinions on what works and what didn’t work, and make something cleaner for KSP2.
Filip Hudak
What are next parts that are comming into the game?
Science parts! But also those gridfins we teased a while ago should appear.stoup
Are there any kinds of parts you're going to be adding to KSP2, that as far as you know, weren't even really available as mods in KSP1? Some unexpected bits and bobs, maybe
The entire colony loop is more or less stuff that was never really available in KSP1 mods from a system perspective. Modding KSP1 was really wide though – hard for me to say.Kalessin1
Are all parts from Your mods to KSP1 will be implemented in KSP2? Especially large solar panels, station parts & MK4 spaceplane?
Hah, no not at all. I like to re-use concepts, but this is a great opportunity to start afresh and to fix some stupid things I did in development of those in my mods.
Gotta somehow get more Thunderbirds in the game though.
Cocoscacao
Will we get all size variants for all parts? Example, hydrogen tank with the smallest radius, only has long option. Why "semi procedural" parts weren't considered, where you can select a tank and set its lenght/radius to some of the predsfined available values?
You definitely have me to blame for no smaller hydrogen tanks – just don’t think they’re useful with the low density.
Why wobblyness still exists? What are design choices and reasons to keep it, if there is a way to remove it? If there is indeed a way to remove it...
I have a post on my thoughts about this as a player. Generally though – it’s not where we want it to be and we’re trying to figure out how to get it there. That’s extremely non-trivial, there are various posts in the forum that do a good job of explaining some of the whys.
SAP KSP
How advanced will the Kerbal's technology be, will there be very advanced parts such as anti-particle devices?
We’ll definitely get way up there in the tech tree. I do want to keep those under wraps for now tho.Infinite Aerospace
Are you able to tell us 'something' about science and career modes, there's been an alarming lack of any real information regarding the two.
Well! Science mode is cool. It is designed to be a progression-based mode that takes the aspects of KSP1’s Science mode that we like and build upon them to create a solid progression experience that has higher level of agency and approachability. You can expect the return of the experiment loop, with changes, and the inclusion of a very different mission paradigm from Career.
One of the fiddlier aspects of the last few months has been taking our full set of concepts from KSP2 1.0 and figuring out how they break down into the early access structure.
Delving deeper, what can we expect from science mode, is it the same ‘click and reward’ setup as KSP1 or are you going for a ‘science over time’ sorta approach more akin to Kerbalism?
The system as designed is independent from things like Kerbalism, but you could say there’s some concepts that aren’t dissimilar in there. It has been a while since I have played with that mod tough. We definitely want to get to more player agency in science. Instead of it effectively being mandatory to hide 4 tiny science experiments on every craft you send anywhere, we want you to make a more informed decision about what you take with you, and make the actions you take a bit more specific too.
I should write a little dev blog on this.
What sort of part numbers are we looking at, is there going to be the same sorta number of experiments as KSP1, or significantly more? What does that entail, are the experiments something more dynamic this time, looking at things like NASA’s GRACE mission for example?
I should definitely write a little dev blog on this. Similar number, more impactful.
In terms of career mode, is there a more dynamic contract system in place rather than the rather ‘rinse and repeat’ system of KSP1? There’s still going to be funding, reputation?
I believe we are on record about not using the same framework there. Funding and reputation weren’t our favorite systems and didn’t have the gameplay impact we wanted.
As a side question, stations and bases. Are these going to have something of a real use this time around, given that stations were limited to more or less just fuel depots in KSP1. I'm thinking more along the lines of long term research projects, with big pay-off for significant durations of time. Is there some sort of requirement to resupply the stations, perhaps required crew rotation, stuff like that?
The progression we want to deliver for bases and stations mirrors IRL conceptions about how these things should work. You will start out with outposts that have limited utility – let’s call that KSP1-like. Fuel depots, maybe comms relays, etc. As you progress through the tech tree, you’ll get access to stuff that provides them with greater utility. That’s shipyards and docks, fuel factories, launch pads, etc. Eventually you’ll get the biggest parts, which are mostly focused on giving you the full capabilities of the KSC at a colony.
A core piece of the utility in my mind comes with resource gathering (which is a ways off in the roadmap,) when the specific positioning and configuration of a colony becomes really important. Placing a colony with good access to progression-related resources and having easy access to heat management/power sources will allow you to build specific functions and cool vibes into each colony.
Crew rotations and resupply are not currently something we would want to enforce. I hope that when we get resources and delivery routes fully operational though, that this is something modders will hit really hard because the framework of stuff like delivery routes will be there.
TheAziz
Pineapple on pizza or not?
I don’t like it, but recently I was made aware that liking baked potato pizza was weird so I can’t really judge.
Superfluous J
Having done both, what do you think are the main differences between adding a part (or set of parts) to the game as a modder, vs as a paid member of the team?
Accountability and justification are big. It’s easy enough to incept a new part as a generalist modder. I just say that I want it and make the time to model/integrate/QA it myself.
In a professional context, that involves the use of studio resources and we have to balance that versus other work we want the staff that would be executing that work to do. A new part needs a concept, it needs artist time, it needs designer time, and it needs QA time. We have to really be sure we want a part before we do it.
Pat2099
Will the salt water nuclear engine make a return?
I’d like instead introduce the artisanal nuclear fresh water engine, using only the purest Vall-ian glacial meltwater and hand-centrifuged Pol-ian uranium. But yes.
TwoCalories
You've made several mods for KSP1 in the past. Will parts from any of those mods, like Restock, Far Future Tech, Near Future Tech, and Stockalike Station Parts make a comeback in KSP2?
Never exactly, though there’s similar roles. I have a 3.75m command pod in Near Future Spacecraft that is pretty similar in role and profile to one in KSP2, for example.What was the transition like going from being a modder (or, more honestly, a pillar of the modding community) to working on the development team?
It was really weird to come into the project and find pictures of my work as references in the team wiki.
But it has been great. We have a really solid team working to replicate what amounts to 10 years of hard KSP1 development work. Ways to go though.
Justspace103
Is the same approach to design & diameter consistency going to be applied to KSP2, similar to what you did with ReStock?
This is already ongoing – we sneak in consistency work where we can depending on the team’s bandwidth. We’ve sorted at least a dozen parts since EA release. The part-ists are probably sick of my hOw’S tHe SiDe CoUnT questions.
Mushylog
Hello Chris Adderley. How detailed will the reentry VFX be, on the vessel's parts? Will we be able to see the heat propagate relative to what part of the ship is hitting atmosphere the most? (As in, will there be a glow on the entire vessel that spreads as atmosphere becomes more dense, in a reentry? Or will the heating visuals display in every single parts of the vessel individually?)
I will leave this one completely to allow future dev communication to represent it. It’s really cool and I think the path to get to what we think is our final solution would be a fun thing to tell people about.
Heretic391
What steps is the development team taking to make KSP2 accessible and appealing to new players who may not have played the previous game or are new to the genre?
Obviously, the tutorialization we worked into EA will continue as we add new systems. Eventually though we want to enable players to do more with the same skill level. There’s some really big difficulty jumps in the game, and while we are more confident in the ‘get into orbit’ jump, we still need tools and strategies to tackle the next one, which I’d peg as going to another planet. After that, go to another solar system.
I saw a really cool concept from the UX team about this last week which made me squeal in happiness. I hope we get to it.
VlonaldKerman
Can you give some more detail on the supply route system? Can you automate the construction of supply vessels, or does a vessel have to be built to assign an automated route to it? In other words, when the route is finished, does the vessel have to be intact?
That system is a ways off and while I think our concepts are pretty solid, they have to survive another round of detailed design, and the EA feedback we get through that time period. So let’s save that for a dev diary later.
Intactness is an interesting thing that the system does need to consider. On the one hand, we obviously want you to not crash your ship to create a delivery route. However, we also don’t want to disallow multi-stage approaches to routes. You should be able to create a delivery route with a two-stage rocket. It won’t be as resource effective as a single stage one, but particularly for routes that launch from high G or atmospheric planets, we need to have a design that eventually supports this. It is possible that this could be delivered in phases for effective development – consider a V1 of routes that focuses on single-stage-to-place deliveries and a V2 that is more comprehensive.
Also, will metal to build basic rockets and methalox fuel be limited in the early game, or will there be infinite fuel on Kerbin? If so, how is this balanced against the ability to send an arbitrary number of refueling ships to a colony, as opposed to what I think you probably want to encourage, which is ISRU?
If you want to create an interstellar empire based on shipping methalox light years from Kerbin, I don’t want to discourage that. That’s kinda cool and would be a big investment in player time and resources, so we would reward that by not constraining it. You’re also probably not going interstellar on methalox… so you are going to be incentivized to not do that in a particular way.
Psycho_zs
In KSP1 some realism enhancements can be achieved with a relatively simple MM patch, because those mechanics are already in the game, but not used in stock (i.e. engine spool up time, throttle depth limits). Are there any realism mechanics that you wanted to put into KSP2, but couldn't because of the gameplay balance? Any of those that you or somebody else sneaked in for config tinkerers to find? What are the limits of stock realism options and will there be something extra under the hood, in a space between stock and full blown mods?
Yeah some of those do exist in the game. Part of that comes in the engine module that supports most of the ‘fancy’ stuff from KSP1 like spool up. As for new things, yeah I’m pretty sure there are some things we’ve asked for but not ended up using. I can’t really think of them off the top of my head.
NovaRaptorTV
What's your favorite part of the game to work on?
I really enjoy the small part of my job that’s artistic – making sketches, concept models and stuff to pass over to the team is quite fun. I also like to make the project plan go brr, ticking off things on milestones makes me happy.
M4D_Mat7
Will there be hydrolox fuel type given how we already have hydrogen as a fuel type for nuclear engines?
If we get the NERV-US in that will be a need for Hydrolox there.
jaypegiscool
Are there going to be more design challenges implemented with more fuel tanks and such? E.g. will there be fuel tanks that don't have a centered COM?
Fuel tanks are a basic component of ships that we don’t want to have players need to manage too much. There are some interesting trades about that for far future fuel types though. As we get there we’ll examine if they’re interesting to support or whether to leave it to the modding community.
norminaluser
Are there plans for adding nostalgia/legacy parts? aka, adding some revamps of the KSP1 parts? I mean, some old users would be delighted with these.
I’d argue that anytime we have a part that comes from KSP1 it is already a revamp, so I’d be interested to understand what that actually means to you.
barrackar
In the upcoming Science update - does conducting experiments give you science points? Will there be a tech tree?
There will certainly be a tech tree, and science points!
For colonies, do we know if/how lifesupport will work? Simple colony expansion or more complicated management of individual resource routes? Will users be surveyed for whether or not we want lifesupport?
See answer about life support from Pthigviri.
For interstellar, will there be astronomy aspects required to detect/map the other system(s)?
Fun things for the future! I can’t be more specific at this time.
poodmund
Why Quenya and not Sindarin, Telerin or Noldorin? Do you have something against Elves that went to Middle Earth? By the Ninth, I must know the answer.
The real answer is that the corpus of Quenya is a lot more complete than say, Sindarin, so when I went to try to learn it, that’s where I went.
piotr.__
What real life concept / scientific work gave you the most headache? Is there something you are really proud of, that your creations will introduce to players?
Heat and radiation are the hardest concepts to map to gameplay, so I’ll say those.
Every time we get a system that is showing a new scientific or engineering reality I get excited. Example - with 0.1.3’s new extensible engines, we’re showing the community that doesn’t follow aerospace precisely than extending engines exist and are useful in some ways.
bygermanknight#0 (554725693590732801)
Are we going to get some engines like the Orbital Maneuvering System from the Space Shuttle because the current (and only) monopropellant engine is not very liked among the community.
The Puff is pretty OMS-like. I’d turn that around and say that something more conventional in terms of attachment modality is probably more useful than something that tries to ape the OMS a lot.
M4D_Mat7
When will we see more interiors for the command parts?
We want to fully define the IVA system and experience before we commit to more interiors so we limit possible rework.
Will the team add RCS to the space shuttle front cockpit section eventually?
This is not planned.
suppise
How do you go about balancing new engines with twr/isp/cost/size/etc?
Check out the Engine Archetypes dev blog for the framework – but the overall concepts we use are related to…
· Spreadsheeting versus comparables,
· Looking sneakily at how mods have done things when possible,
· PLAYTESTING
Follow up question, with the full 1.0 tech tree, aside from cost/resources, will there be a reason to still use the basic methalox atmo/vac engines we have now, over newer engines/fuel types?
Resources accessible to a colony will drive this. Say you’re mining a frozen ice ball of a planet with water ice – that’ll be something that would drive you to hydrogen engines. However, maybe you’ve got a colony on a world with trace atmosphere of CO2 – that might make methalox attractive.
mgb125
I routinely exceed 150 parts for spacecraft in KSP 1, would the team consider a higher baseline for the “typical” vehicle? Do you have stats on how many parts players use for their EA KSP 2 craft?
We are building our analytics pipeline to give us that data. We have lots of legacy data from KSP1 to help us in the meantime.
sylvifisthaug
So someone in the KSP2_general channel have pointed out that the "brass line" vacuum engines in KSP2 have some resemblance to your previous modded content as Nertea.
How is the process like with implementing these similar designs into KSP2? Do you do it entirely by yourself, texturing and all? Do you do 3D models, coding, or maybe nothing? You just manage the team to do it?
I do very little of those things. Effectively I…
1. Try to incept the concept and discuss its utility with the rest of the team,
2. Make sure we can support it with the engineering that has been done,
a. There’s a whole side thread about when we need to ask for new gameplay functions.
3. Make concept models,
4. Hand it off to the art team,
5. Coordinate other things we might need for the model – VFX, SFX, animations,
6. Come back once we’ve got all that sorted and do the final integration into the game, and some tuning later on.
If you as a team manager delegate others to recreate your parts, how does it feel to let others rummage with your own engines?
To be clear, we’re not really recreating parts – when things are similar, there’s often just convergent evolution. But our art team is equal to the task!
-
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.
Just now, moeggz said:Here we have it. Confirmation that they’re are still in the conception phase, at least partially.
Well, I believe the devlog is pretty clear about allocating the radiator stuff for release around the Colonies update there
.
8 minutes ago, cocoscacao said:Wait... This is gonna be a thing? Base building sounds awfully more fun now
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.
19 minutes ago, Sesshaku said:As far as I understood it, multiple radiators in weird angles radiate heat to each other reducing efficiency. Will inter-reflection be included in the "deterministic" simulation? @Nertea
I'd place that in the 'computationally complex and challenging to make performant' category.
32 minutes ago, RocketRockington said:Your system also resolves to 'blow up if not enough radiators, perfectly cool if enough radiators' so I don't see your objection here being valid at all.
At least with conduction, some consideration of where and how parts are placed is a thing, which isn't the case under this extremely unrealistic heat model.
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.
-
3 hours ago, The Aziz said:
Can we get inline radial heat sinks though? I know the idea is to go procedural for side mounted ones, but circular ones would be super cool.
There's lot of interesting concepts out there for radiators and I would certainly like to represent more stuff than just linear things. Look up Curie Fountain radiators for example. Cool ideas!
3 hours ago, Strawberry said:We will see heating V1 with or before science, as mentioned previously vfx may come before this. The dev diary does imply that SWERV wont make heat, which is dissapointing, That being said, colonies having to deal with heat from the sun and ground is something I was very interested in and glad that it will be a thing.
I am definitely no stranger to making nuclear engines of lower power create heat, and I can say with some certainty that it isn't fun (can probably dig up a few pages of arguments from one of my older mod threads, haha). You need a big gameplay bonus to saddle the player with the negative results of heat production, or it feels like busy work. The studies the SWERV is based on also effectively say that the math works out if you keep the Isp below 1800s or so, and the engine's heat generation is fully covered by the exhausted propellant, and while I'm a little skeptical, it's not like we've ever built a functional closed-cycle gas core reactor to check.
That being said when these capabilities come in, we'll definitely figure out what plays well, and what appropriate trades to make a player try to work in. It might be that the SWERV is a good place to introduce a player to the concepts of having to add a little cooling for a powerful engine.
3 hours ago, Acid_Burn9 said:Well that's a little bit disappointing. Conduction between parts is understandbly hard to make performant on a large scale you'll get no argument from me there, but i was still hoping that it will be a thing at least for the active vessel and maybe ones within the physics range.
Nevertheless a very enjoyable read!In addition to what's said in the devlog, it might be worth highlighting a few things
- Conduction 'resolves' effectively instantly on any significant timewarp unless you are using a thermally isolating piece of kit. Your vessel just tends to a specific equilibrium - one that results in everything being fine if you have enough heat rejectors, or death if you don't. It is more math for the same result.
- KSP1's conduction model was... interestingly used. The two places you'd run into it most in average gameplay was reentry, where the tools you used were heat shields and service bays, which actually had special modifiers to NOT conduct effectively (or eliminate flux altogether).
- If you run conductive physics only the vessel that's in focus, you've now created two different thermal paradigms, and a player has to understand what context their ship is operating in to predict their regime. Both regimes should operate in the same way.
-
If your fission reactor is running at 3000K, yes, you will probably bleed heat to things beside it. However, your reactor has probably melted down now and you've got way larger problems. Those problems are the ones we want to focus on. From my previous employment and analysis of these kind of problems, that aligns with mission-level reality. Specifically
- Systems that are thermally vulnerable are thermally isolated, and tend to be very vulnerable (+/-50 K is the highest range I've seen between difference between instrument death and survival)
- Environmental conditions are far more important than other spacecraft components. Two macroscale components next to each other don't affect each other at anywhere near the same scale. Both are affected by the local environment before either (this isn't strictly true for the microscale, for example an imaging device increases in temperature while it takes pictures, which could bleed to the other side of the detector array. But even then, we'd thermally isolate them and then supply external cooling or specify a duty cycle for cooling off)
3 hours ago, Clayel said:are there any plans to implement systems for the reverse, aka when parts get too cold? i wouldnt want my kerbals to be at 50 kelvin!
I've got some ideas, but the first iteration of this system definitely focuses on cold = good, hot = bad.
3 hours ago, JedTech said:After reading the whole article I see that and am impressed with their approach.
Thanks! It's important to not go to deep, but also represent it as a real challenge.
2 hours ago, PicoSpace said:As an engineer, this looks like a good solution to a complex problem. I do have a few questions though.
1. How are we handling Kerbals in this equation (do they produce heat flux) in and out of the ship (EVA Space/Planetside)? What is their Max/Min temperature tolerances?
2. Are colonies required to be attached in some way to transfer heat from one flux to another (I'm thinking KAS here or something) or will there be an assumed "hidden underground system" between buildings/structures ships etc within the confines of a "colony" whatever that may be.
3. It would be nice if there was a "max/min" or "variance" flux marker for ship/colonies/kerbals which basically forward simulated them for one rotation of their current Planet/Orbit to ensure we don't accidently leave a ship somewhere and think "oh it will be fine" and during its orbit or the planet rotation it bakes/freezes all aboard. Obviously when its active or moving that isn't done but I can see players jumping from one ship to another and totally forget to check for hi/low fluxes.I guess the idea is that ships have internal temperature controls (fluid pumps etc) like you'd have with a water cooled PC, at the end of the day at this macro-level its not "did you provide enough cooling to your CPU" vs. did your PC start to combust because it has no fans.
I'm guessing from the Tempt/Flux that each ship will only have a single number, or is per part?Good questions!
- Kerbals don't produce any heat, but they do participate in the simulation. So they are an object when outside of their capsule that can be affected by flux, and have a temperature increase. They'll be thermally squishier than parts, as they should be, so that having things like thermally resistant rovers might be fun.
- I can't really talk about that too much right now, stay tuned!
- Yeah this is one of the big pain points of a high resolution system. That goes into player UI tooling. We have solutions in mind, but have to see exactly how you all use the system and where the pain points are.
Your comment about inputs and outputs is exactly right - we look at it as making sure you balanced the I/O. We assume the kerbals build their capsules correctly and that they know the heat exchange piping better than you do!
2 hours ago, regex said:I sincerely hope this means I'll be able to replicate the Firefly, wouldn't that be a beauty...
That would be a good goal, I personally don't love its looks though, so it'll be reluctantly
1 hour ago, Nexius583 said:Thank you for the insights on the thermal management system for the game ! As an aerospace engineer that means a lot to me
Something I did not understand clearly is if there are going to be individual parts temperatures and flux or only a global vessel net flux. For example, if we put a radiator far from a heat source, are the parts between the two going to be gradually hotter ? And will we have some sort of internal heat resistance and heat transfer inside the vessels so that we may need to put some radiatiors close to highly heat-producing parts ?
In any case, I look forward to see my beloved reentry plumes !
Flux and temperature have to be tracked per part. We assume that radiators added to a vessel include the piping for a high efficiency heat transfer system, because well, we do that with electricity and fuel flow. It's a similar level of detail.
1 hour ago, Angelo Kerman said:@Nertea This is a great explanation of the design goals for KSP 2's thermal system. Having seen you struggle with KSP 1's system- and running into the problems of heat management after timewarp or after being away from a vessel for a long time- it's good to know that factors like these are being taken into account in KSP 2.
Yes, I took a ton of lessons learned here to heart when we were building the concepts for this out.
1 hour ago, PDCWolf said:The writeup explaining the system is excellent, however the nature of the system and some stuff left out are clear problems:
- You're trying to tell me this is more complex, yet all you talk about is how it is more simple. Telling me how the sequel improves over the original is a main selling point, and whilst you tell me there's more elements, at the same time those elements are handled in a simplified way, in what's certainly a regression.
It's important to make a distinction between element complexity and system complexity, because that's a trade you are often making in any system. If you make a system out of high complexity elements and plug it into a high complexity system, that's scary. It's very challenging to design, implement and particularly, test and tune. Complexity isn't necessarily good, and though reality is complex, representing reality through system complexity isn't always good. A nice self contained example is how parts in KSP1 have heat tolerances in the 1-2 thousand K - though the system is more complex at the part to part level, the result of the complex interactions creates a need to balance out heat spikes with unrealistically high heat tolerances.
The core requirements for this system have to cover more user stories than KSP1, and I'm definitely aware that in doing this, I'm always going to break someone's workflow, or create something some players won't like. In this area, we think that serving stories that are completely unavailable in KSP1, like coherent heating from systems, tracking of part heat at high timewarps, and simulating heat items on vessels that aren't in focus, are more important than that.
1 hour ago, PDCWolf said:- Another thing that it fails to address, that seems to be too easy a conclusion for readers to come to: how is the heat system not entirely solved by just "add n radiators or heatshields"? Specially now that radiators are procedural parts.
I don't think that's actually wrong. If you have excess heat in space, you can solve it by one of two ways: add a system to take heat off (let's call that vessel architecture) or don't go into that situation in the first place (let's call that mission architecture). That's what we get here. We have situations where you solve a problem with vessel architecture and a ton of heat rejection equipment, and we have situations where you solve a problem by changing your mission. The latter is pretty wide, but that includes things like flying skimming reentries to bleed off speed so you don't need a heatshield, or building your colony near a water body so you have access to easy water cooling. The essence of this is making sure we are representing the right problems, and making sure the right tools are there to use them
1 hour ago, PDCWolf said:- Your "shadow of a mountain in a sun-grazing planet" colony example is probably the worst one, since it clearly ignores atmosphere dynamics (hot stuff makes air hot, should saturate radiator output).
Hey, that could be a airless planet you're talking about!
The point is there though, and functionally, there will always be places where a system will not represent reality. In even more places, a system will not be plannable. Lack of plannability is bad. The example there is pretty interesting because when you dig into it, you need to know a lot of variables. How long is the day? Is the colony ever exposed? Is there orbital eccentricity? What happens if a tiny edge of the colony is exposed? Even if you ignore atmosphere dynamics, radiator re-emission, etc, it's a really hard problem!
-
Speaking as a player first and dev second, I like to think of joint flexibility (wobble is a symptom, not a cause) like this.
For myself, when learning and when building vessels, there was undoubtedly an extremely satisfying A-HA that came from taking a borderline garbage design and carefully crafting that structural reinforcement web so that it worked correctly. Sending something to the pad, seeing it sag and instantly knowing that this would cause Bad Things, was good. Putting some struts on there and seeing that disappear, and knowing that this particular failure mode was removed, was great. Without that early puzzle-solution feedback I probably wouldn't have played the game long enough to transition to the long term exploration chunk of the game where you actually go places and discover things.
In that later stage, having to work out the structural problems of things you feel like should work is incredibly frustrating, and doubly so when your Jool-5's mission's return stage disintegrates when you separate it, or when you connect the 3 modules of your Copernicus replica in Kerbin orbit, get an intercept with Duna and fire your engines, you see your vessel fold into 3 pieces.
There's practically 2 different metagames there. Tuning a system to make players happy in both cases is challenging, regardless of the technical solution.
-
All great thoughts. Appreciate everyone who has take the time to write some reasoned, cogent suggestions.
I'm not going to speak to whether any solution is better or worse, but all-vessel approaches have some advantages and some disadvantages. An advantage is indeed that you can occlude things you 'should' occlude quite easily. Your cargo bays and clipped parts are going to be much easier to treat, and whole-stack occlusion will be simpler. I will avoid saying for free because that is never a realistic word to use in software development. The probable biggest challenge is going to be dealing with parts that should not be occluded when they should be occluded. If you get 6 drag calculation images from each face of a large vessel, you're going to miss stuff. An quick obvious example here is biplane style wings - from 2 key plan views, we'll only see one wing! We would have to introduce edge cases to deal with this. We also consider scale. Fundamentally the drag cube approach only works well because we are confident that for most parts, we can fully represent each face's data by 3 numbers. Most of the time, a part is a weird cylinder or a funky box. If we try to snapshot a whole vessel with our texture-based approach, we're going to get different drag values for different scales of an otherwise identical vessel due to the size of the textures used, and the drag contributions of smaller parts are going to start getting missed. We'd have to introduce scaling of the drag textures for different vessels, at minimum, and we're still going to get weird data at different step sizes.
To sort those two problems, we probably actually need more than 6 drag views, and we need a consistent sampling grid that is independent of vessel scale... oh, that's basically now an expensive voxelization approach. Yikes - maybe just go all the way to voxels. Not strictly bad, but now a completely different aerodynamic approach, and one that needs to cater to recalculating voxel sets in response to flight events.
Overall, I think some level of all-vessel or at least near-part approximations would indeed help treat some situations, but we've got to carefully design and balance implementing that versus other work we want to do.
I also want to touch on the part clipping note here because it is a super-excellent illustration of one of the most common KSP design challenges. I love part clipping. I can make so many better looking, more optimized vessels than I could otherwise. That KSP1 update that introduced the transform tools? Game-changing for me and I suspect a ton of others. As someone who wants to clip a bunch of greebles together to make a cool probe, or... I was going to list a dozen use cases, but we all know it's great.
Clipping is physically nonsensical though (well, depends on the part, but on average, yeah). I can literally cram 8x the fuel into the same space just by setting my symmetry mode to 8x and hitting the Roll hotkey twice in the VAB. I recall a fun KSP1 exploit that involved 2 Mammoths, a cubic strut and a resulting 8-nozzle engine monstrosity which let you get twice the thrust in the same footprint. This isn't a big problem in space, clipping doesn't save you mass directly, you're still at Tsiolkovsky's mercy, but in atmosphere it has gameplay implications. It lets me fit more into a cargo bay than I should, as a quick example. In the current drag model, with some exceptions, part clipping doesn't change the aerodynamic behavior of parts. Jamming 8 fuel tanks into one still preserves their visibility to drag, so you've got a little penalty.
Holistic all-vessel occlusion calculations would make this better. I'd then maybe be able to hide those 8 fuel tanks from drag. Now though... that becaomes fundamentally best way to build a rocket. There's no penalty for clipping, it gives me more fuel and better aerodynamics, and the most optimized design becomes the most clipped design, which to my mind is not ideal. If I wanted true physical realism, perfect occlusion calculations would need to be married with some way to stop players from doing that, which I absolutely don't want. Either way we go we end up with something that breaks reality in some way. It's a conundrum, and I'm really bringing it up because for me, it really focuses that physical reality versus excitement trade that I have to look at constantly when designing systems for KSP2.
On 6/16/2023 at 11:10 AM, jclovis3 said:I think now I am seeing another issue with this method of occlusion that may impact cargo bays and dynamic Fairings, which is that occlusion of a forward part is only tied to the one part behind it and that second part does not pass on the occlusion to the next part but simply provides only itself as the occlusion to the 3rd part.
We take a fairly different approach with fairings - when looking at this article, you can think of a closed fairing and its contents as a single part, from the perspective of the stack occlusion system.
On 6/16/2023 at 12:26 PM, Pat20999 said:Chris, is the new “torch drive” the salt water drive.
You know I can't answer that ;).
I can say though that the definition of torch drive varies, and there are a number of different hypothetical propulsion techniques that might fit the bill.
1 hour ago, 000PainKiller000 said:How do liquid hydrogen tanks behave? I'm asking because it's not clear to me. Visually, when nothing is connected to them, they seems like a big streamlined orb, with a little metal skeleton. Mostly is shouldn't be a draggy part. However, i can see that in the front and back (and also on it's side) there are connection nodes. According to ksp1 logic, if those are not covered, they should have big draggy surfaces right?
They're treated as any other part, so attaching nothing to the 'flat' front bit will create more drag if you don't have something rounded or pointy on it. Not a lot, because for those big tanks the difference between a flat surface and a slightly curved at 3 degree surface isn't a big change. One thing you'll see tough is that the LH2 spheres slow down faster purely because they're very light. You don't need a lot of force on a light object to change its velocity rapidly.
Also, the basic set of equations that KSP2 uses are not tuned very differently than KSP1, and I do know that they have some trouble creating intuitive drag on blunt-ish bodies (a topic for someone more fluent in CFD than me). It may be worth a look from the team in the future, Making History did some custom compensations to make the round ball pods behave a little more intuitively as well.
-
16 hours ago, Strawberry said:
Super informative dev post! I do wonder, I know yall have talked about in the past making sure the people with the right set of tools work on the right set of things, Im guessing Chris is a special case due to already having good familiarity with ksp's code, thus allowing him to work on a wider array of things then your average artist?
Hah, I can't really say that I'm an artist (my non-KSP life is systems architecture and software) - my role as a designer is a lot more general and I tend to limit my art contributions to part concepts. I tend to focus more on systems and how they fit together, I just happen to like making models of parts at times.
14 hours ago, Pyritin said:Out of curiosity is the occlusion logic an on/off sorta thing or does the model allow for partial occlusion. For example if the nose cone was placed on a rocket normally, and then translated up to create a gap between the two parts. Would the occlusion model partially occlude the top of the rocket (because the cone would then create a gap for air to pass through), act similar to as if the cone wasn't translated, or not occlude at all?
It is partial and handles rotation but not translation (an artifact of how the system is set up). This one's a hard one, because players use the translation and rotation tools to do cool builds and make exciting things that are often decidedly unaerodynamic. There's a narrow line between simulation and gameplay which we toe a lot, and I would love to write more about - IMO one of the most interesting things about this game. Reality is often punishing, and the right amount of punishment is a tough thing to determine!
13 hours ago, RocketRockington said:KSP used to have some pretty extensive debug info on aero, both in the PAW and visual info you could render . Shame that seems to only be a developer tool in Unity now in KSP2.
I think using debug tools for flight isn't the best solution out there and it folds nicely into the overall discussion the team has about creating and improving useful planning tools for all systems in the game.
1 hour ago, Mushylog said:Chris paintovers, terrible MS paint scrawls trying desperately to get a point across
I don't think you're really getting the full experience unless I'm ruining a really nice piece of concept art on a zoom call
.
8 hours ago, Dakitess said:Sadly, i'm quite concerned that, indeed, we fall back to KSP1 dead ends while it's the opportunity to do better...
I wouldn't characterize the drag cube-based system as a dead end. Sure, there's room for improvement, as with any system, and there are some addons in KSP2, but it is broadly a computationally clever solution to a very complex problem.
Always happy to discuss where you think it falls over and fold that into our internal discussions.
2 hours ago, Mutex said:EDIT: Thinking about it, perhaps an improved version of the way it currently works, which would still be fast, is to generate a cube-map of the entire ship at the start. Obviously re-generate it every time the ship changes (docking, parts breaking off). This would still be a pretty limited simulation, and it wouldn't take account of the ship deforming/bending severely, but it would at least probably be more robust than doing this part-by-part. (EDIT2: Actually this wouldn't work if/when we get robotics, or anything else that makes the shape of the craft dynamic.)
At least half of the complexity of this game is due to the... complexity. Anytime we have a new feature or even one we want to port from KSP1, the challenge is in handling the solution for a complex vessel. The individual part-based approach has some advantages here (and disadvantages - all about those trades).
-
3 hours ago, The Aziz said:
Last time I heard that devs hate QA because they give them more work to do
I love getting quality bug reports, however grumpy they may make me at the time!
3 hours ago, FlazeTheDragon said:That was a pretty interesting read.
Glad to see its finally getting solved :p
Will this also fix cargobays not shielding their contents from drag, or is that a separate issue?
The funny thing is... that often when we solve a bug, we discover more bugs that were obscured by the issue itself, and this is one of those times. I can say for example that we discovered two smaller knock-on bugs from the work I described here that have also been fixed. We'd hoped the cargo bay drag would be sorted by this as well, but it turns out that it isn't completely solved yet - we are tracking that parts that are stack attached to the internal nodes of cargo bays are sometimes not correctly occluded by the bay itself. The test cases I used when evaluating whether this functionality worked used surface attachment (it seemed like the harder case) - not stack attachment , which we've now identified as a problem to look into for the next update cycle.
2 hours ago, regex said:This is like 75% of the bugs I work on; tons of research, two lines of code.
Thanks for the detailed post!
No problem, I had an interesting time writing it up. I realized we didn't have a good description to the community of how our aero data is represented, so it was fun to be able to makes some little schematic diagrams of how things work!
3 hours ago, theJesuit said:Interesting and understandable!
Asking a question, IIRC, FAR in KSP1 does similar but for the whole craft at a time, so it is the forward facing whole face of the craft in direction of travel. Is there a reason this approach wasn't used for KSP2?
I think we're open to trades in specific directions for aerodynamics going forwards, but it's not quite as simple as that! FAR does a bunch more than area facing calculations and we determined that it wasn't the right solution for KSP2.
-
Lots of opinions here to unpack!
We have to walk a fairly fine tightrope when choosing to represent the complex reality of real rocketry. For a lot of historical space applications, a specific need was often defined (go to the moon), which drove the selection and development of all components of the spacecraft, including choice of fuel(s) and development of the engines (from scratch, from a study, or upgraded from a previous vehicle). With KSP, we're kinda working backwards - we get to make guesses like "here are the missions we think a player will want to do" and strive to provide a set of engine options that let them do that. That's a pretty big space - players want launch engines, space engines, efficient engines and such for their missions. Filling that need for even a single fuel type requires a lot of engine parts. There's 20 in KSP1 and there's sill frustrating gaps to me. I do like playing Engine Selection Simulator myself, but providing enough options for player flexiblity with several liquid fuel types causes the number of engines to go up fast. I should know, I made at least one KSP1 mod for that.
Approachability in this space is a huge problem too. New players end up with a lot of confusion over parsing through even the basic set of engines. More engines that use different fuels create more approachability challenges, particularly when trying to match them with their fuels and understand when to and when not to use them. That's a teaching challenge we have to bite off with our later, fancier engines, but there we have the advantage of being able to use fairly unique models and well-defined, different performance envelopes to do that.
All this is why we are effectively sticking with a single liquid bipropellant engine resource, at least at the beginning of Early Access. There's a long road ahead of us though, and room for a lot more things! Of course - like Nate indicated, you will see hydrogen for use in nuclear engines at EA launch as a new fuel as well as the old standards like Xenon.
There's lots of good discussion about methane as a base fuel in this thread, with some strong pros and cons. I'm always encouraged to see that these matched our internal design debates and I believe that we've made the right choice. Think of it as Kerbals taking a slightly different technical path to rocketry than humans. To quickly reiterate, we're not rebalancing our engines to be considerably different just because they use methalox or anything - you'll see craft with the same engines behave more or less the same in KSP1.
All the above being said I immediately expect modders to do what modders do, and show up very quickly with mods that add, for example, the 150-odd resources in the Community Resource Pack into KSP2. And mods that change the engines that look something like hydrolox engines to use hydrolox
. Modding is great!
-
I haven't changed that code in years, you'd have to ask the other poster and compare conditions.
-
On 10/17/2022 at 6:39 PM, Maurox said:
I may be wrong about this, but did you actually fix the ground sliding problem with the adjustable legs/base frames?
With KER, every single wheel and landing leg set give me that 0.000-something degrees/second rotation - brakes, ground tether, even the static anchors, doesn't matter. Nothing actually fixes the problem
Except for your base frame. The numbers jitter a bit at the beginning... and then they stop. As in, actually stop.
Now, pardon me, as I know next to nothing about coding, but from skimming over your source, you seem to be defining and referencing a value for static and dynamic friction in the AdjustableLeg module - could that be the solution? And if so, any chance of getting something like a universal friction module that could be applied to other base stabilizers and landing legs, like Planetary Surface Structures, Benjee's PES and such? Because I tried applying wheel module with friction modifier to PSS, but they are still sliding ever so slightly.
You can see what I'm doing here: https://github.com/post-kerbin-mining-corporation/StationPartsExpansionRedux/blob/f0c03675c817782d99c3e919c1e30d070f8a360b/Source/HabUtils/ModuleAdjustableLeg.cs#L156
It's not very groundbreaking and I'm honestly surprised it works as well as it does.
-
15 hours ago, beez1717 said:
I love this mod but the only issue I have with it is that it isn't compatible with the Interstellar Extended mod so I end up having to use kspi radiators for anything that uses waste heat and system heat for everything else. For example, I could use a kspi reactor but I then am forced to use the kspi radiators only, or I could use near future generators but then I'm forced to use system heat only. If I decide to use kspi's beamed power then I definitely can't use system heat for that. The issue is probably integrating waste heat with system heat, but I bet it can be done. Can someone make a compatibility patch perhaps? That would help a ton.
The two mods are fundamentally different in how they handle everything. A compatibility patch is changing all of one mod to fit the other and that's not something I'll ever make
On 10/12/2022 at 4:22 PM, Socowez said:Well this was certainly unexpected! I thought you were done with modding KSP1 and on the KSP2 dev team? or have you too much time on your hands and decided to do some bugfixing?
BDB team asked for some features and I have a good relationship with the devs .
-
2 hours ago, Bizobinator said:
Any chance there's an updated list/repository somewhere? Are there any other mods that have added in support stuff?
It's really hard to maintain such a list so no. I know BDB has good support I guess?
On 10/16/2022 at 3:49 AM, PrimeDirective96 said:What's causing this to happen?
I have no idea what I'm supposed to be looking at.
On 10/15/2022 at 11:47 PM, 1something said:probably was the NFLV waterfall stuff.
This seems unlikely because I manage that myself and there's no issues
-
On 10/13/2022 at 2:03 AM, GNO-SYS said:
At first, I thought this was Waterfall, but I uninstalled all plume-related mods and tested it again, and it kept doing it. For some strange reason, the engine glow effect inside the Restock engines is flickering black on my rig. I tried a bunch of things. Clean install, you name it.
The flickering remains constant even when the game is paused. Looks like a weird depth buffer/draw issue. It only happens on Restock engines. I have absolutely no idea what's causing it. I have an RTX 3090 FE running the latest 522.25 driver. This is my modlist:
Probably scatterer TAA.
-
System Heat 0.6.0
- Most UI fields now report in SI-prefixed units for flux (W, kW, MW, etc). This is not (yet) true for all modules though.
- Added new functionality to cool fuel tanks with radiators and the SH system
- Added optional patch to apply this to CryoTanks
- Added some guardrails around the handling of Kopernicus planets that might have inconsistently configured atmospheres
-
Added ingame settings. The following things can be customized per game
- Boiloff: enabled and scale
- Nuclear fuel transfer: require engineers, what level
- Fission reactor damage: allowed, various tuning variables
- Fixed engine heat for VASIMR argon modes
- Support USI reactors
- Fixes to universal harvester patch
-
On 9/25/2022 at 10:17 PM, ArkaelDren said:
@Nertea How would I turn all tanks that have boiloff into ZBO tanks? I like the idea of using the realistic effects of dealing with these fuels, but I don't like the tanks that have a constant boiloff with no way of controlling the rate. I just want to have all of these types of fuel tanks require electrical cooling. Several of the tanks I use boiloff and cant be used for long duration flights, except I really enjoy some of these tanks and need them for those long duration flights. I have read as much of the cfg files I can but only understand the basics. With in the CryoTanksFuelTankSwitcher and the CryoTanksModularFuelTanks I have read,
"Adds ModuleCryoTank to CryoTanks included built in ZBO tanks." with the module,
MODULE
{
name = ModuleCryoTank
// in Ec per 1000 units per second
CoolingEnabled = True
BOILOFFCONFIG
{
FuelName = LqdHydrogen
// in % per hr
BoiloffRate = 0.05
CoolingCost = 0.05
}
BOILOFFCONFIG
{
FuelName = LqdMethane
// in % per hr
BoiloffRate = 0.005
CoolingCost = 0.02
}
}
}and the other that includes the extra line "CoolingCost = 0.05"
MODULE
{
name = ModuleCryoTank
// in Ec per 1000 units per second
CoolingCost = 0.05
CoolingEnabled = True
BOILOFFCONFIG
{
FuelName = LqdHydrogen
// in % per hr
BoiloffRate = 0.05
CoolingCost = 0.09
}
BOILOFFCONFIG
{
FuelName = LqdMethane
// in % per hr
BoiloffRate = 0.005
CoolingCost = 0.045
}
}What do I have to change to make all tanks ZBO to give me control of all tanks that use evaporative fuels?
Thanks as always. Even though I have made it clear to many times, thank you for Keeping KSP fun for this community. At this point your name is synonymous with my KSP play times. I haven't started a playthrough with out your name being attached to it for 90% of my time.
You don't have to do anything, as far as I know. Every tank that is touched by the mod is allowed to have cooling, the non-ZBO ones are just disabled by default. Click the PAW option to turn them on.
-
I'm retired, I work on what I want when I want.
-
I managed to cook my modding computer but it's back now.
Some pictures of the process for the 2.5m reactor.
Looking at the old one, going to try to preserve some of the silhouette because it is dear to me
Gotta keep the look unique compared to the 1.875m one. Components blocked out.
Getting to a coherent external detail level.
Rolling in the machinery and pipes, nice lineage with the 1.875m reactors, but showing off some size optimizations and more turbines.
-
On 9/8/2022 at 11:06 AM, Ravlain said:
Hi @Nertea, I'm getting constant NRE spam apparently from DBS whenever i fly a manned vehicle (Not probes ).
Module DischargeCapacitor threw during OnFixedUpdate: System.NullReferenceException: Object reference not set to an instance of an object
at NearFutureElectrical.DischargeCapacitor.get_CurrentCharge () [0x00025] in <81c4957bdce64bef809a1ac06ed71d14>:0
at NearFutureElectrical.DischargeCapacitor.OnFixedUpdate () [0x00204] in <81c4957bdce64bef809a1ac06ed71d14>:0
at Part.ModulesOnFixedUpdate () [0x000bd] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0
(Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35)I haven't got any capacitors on any of my craft, so I'm not sure why this would be being called.
Modlist
Logs and MM cache :-
https://www.dropbox.com/s/7bnhngz1ptaw9zx/KSP Logs.zip?dl=0
The only mods that directly touch electrics as far as I know are ODFC and TAC-LS.
Log spam starts at line 135530
I've noticed that only the Mk1 and Mk1-3 command pods have a discharge rate slider. (and of course they're the only ones I've used so far
)
Something put a badly configured DischargeCapacitor module (part of Near Future Electrical) in those parts, which broke them, which in turn broke this mod.
Likely it is ODFC. I seem to recall some kind of similar bug ages ago with it.
-
Another option is to open up the debug panel and turn the heat generation slider to 0. This should affect SH parts and make them produce no heat. Thus invalidating a TON of development and balance work :).
-
On 8/7/2022 at 7:44 PM, mwerezak said:
I've run into a bug with the Rhea command pod. It thinks it is a probe, even when there is crew present.
I ran out of power and lost total control of the Rhea, despite there being crew right there!
KSP ver 1.12.3.3173 (steam)
Near Future Spacecraft 1.4.3 installed from CKAN
I edited the part and replaced "minimumCrew = 0" with "minimumCrew = 1". Problem went away, now says "Full Crew Control" with the crew icon instead of the probe icon in the upper left.
This is an intentional 'bug'. You have command all the time because it is a probe core. Also because it's a probe core, it has to be powered.
On 8/23/2022 at 11:21 PM, KSPMoose said:I know you've deemed this "Feature Complete" but is there a way you could make the reactors compatible with the existing radiators? Maybe give me some pointers on how I could modify the files in the mod to accomplish this myself? I love this mod and I appreciate all the work you've put into it, just this one little thing gets me. Thank you!
Edit: Tried to upload a pic of what is happening, the insane amount of hardware attached to one reactor and the temperature still going up, but the forum doesn't like any of my links...
Second Edit: After some extra research, I can see this post makes no sense. I must have something conflicting with the way systemheat interacts with all the different systems as it's not being distributed properly and/or the parts are not updated correctly. Ugh... Here goes one by one uninstall and reload....
Third Edit: The radiators that are supposed to come with the Near Future Electrical mod aren't showing up in any place that I can see. Not even in a search in parts or in the tech tree.
There are no radiators with NFE. Reactors are totally compatible with existing radiators out of the box, it won't even take a ton. They just will not be very efficient.
On 9/7/2022 at 7:44 AM, Zefnoly said:Are watefall effects missing for Aeronautics pack?
Missing implies I ever did any. Never got around to it.
-
23 hours ago, thelittleidot said:
@Nertea I've been trying to create a waterfall base config for a SpaceY engine. Could you tell me why my config does not work please? I'm currently at a loss.
@PART[SYengine2mR1] MODULE { name = ModuleWaterfallFX moduleID = ratiteFX engineID = SYR1 TEMPLATE { templateName = stock-hydrolox-upper-1 overrideParentTransform = ThrustTransform scale = 1,1,1 rotation = 0,0,0 position = 0,0,0 } }I think you're missing a pair of curly boys there.
-
19 hours ago, GusToTheMoon said:
is there a config anywhere that lets me swap the fuel used by the engines (similar to how tank contents are swapped) or am i gonna have to learn how to do that myself?
There is a patch in Extras that switches the fuel types but it isn't dynamic.
-
Adding the 1.875m reactor to the list.
.
Bug Status [10/4]
in KSP2 Suggestions and Development Discussion
Posted
Hey all, some clarification for #2. The core contributors to these issues are various gameplay systems (resources, thermal, orbital positioning) that currently run for all parts on all vessels, regardless of how close vehicles are to the player. To be crystal clear, we do not simulate rigidbody physics or perform rendering on parts that are not in the player's influence sphere. This is contrary to KSP1 which effectively rolls up all these things into a single vessel and doesn't do much when a vessel is 'unloaded'. This is in order to support key features like
There are a number of improvements we are looking to make as we go forwards because this is a key issue with scalability of saves. Notably, a lot of those features don't exist ingame yet and are coming further down the roadmap. So, our approach is going to be incremental and based on supporting the appropriate set of gameplay features for any given milestone.
One of the things we absolutely are doing for the future (past 0.2.0) is defining specific scenarios for the sizes of ships and saves we want to support as a baseline in each update. That means taking a good hard look at the systems involved in each milestone and putting good, realistic numbers on player vessels, parts, resource consuming parts, resource producing parts and other simulation performance costing items for the engineering team to work towards. We have to scale, and we need to know how much we need to scale.