Incarnation of Chaos

This is basically a netbook, and while mobile parts have come some way since those things i don't think you're going to have much luck running games on it period.

DX12 Ultimate is also just a set of extensions to DX12, so it's more like a DX X.1 than a new version. The entire reasoning is so vendors can distinguish between GPU's that support the full DX12 feature set and those that support the "Original" DX12 implementation. So really it isn't about the games, it's a hardware specification with a software back-end. For the rest; that'll all change come this holiday season. The "Next-gen" of consoles are going to have some form of Hardware-Accelerated Ray-Tracing, and are confirmed to use AMD GPU's. So Microsoft's box will have DX12 Ultimate running on RDNA 2.0 GPU's at least by then; if not before. But the overall point of your statement i agree with; at least for me it seems that Ray-Tracing is still several generations of GPU's and games from being a desired feature. And currently it's nothing more than an expensive way to halve your framerate and get better reflections, and i honestly don't see it becoming viable unless Vulkan Implicit/DX12 Implicit display modes are implemented by developers to use multiple GPU's to handle the overhead in the interim. But KSP2 will likely still be on whatever DX version Unity shipped with back when they started development, and i have a sneaking suspicion they're going to leave all of the Linux people out in the cold. I'd be ecstatic if they made a version on Vulkan, but right now it seems that they're targeting Windows PC's exclusively even forgoing consoles. With the recent shift of developers, and the uncertainty that brings this is all subject to change however.

That i don't have an answer for, but i'd say likely not.

Welding is taking two seperate parts and merging them into a single part, so because of how KJR works i doubt it would help with those. Not sure about it's interaction with those "Virtual" welding solutions, since those more closely resemble KJR than a true welding system. The strength of any docked connection is dependent on the size of the ports, and how securely they're connected. So KJR doesn't directly add additional reinforcement to docked ports as far as i'm aware, but KJR makes the connections between the docking port and whatever it's attached to much stronger. So it indirectly increases the strength of docked connections despite this, and it's a godsend.

Yeah i shouldn't have said "Next" I was trying to say the most recent DLC was leaked via SteamDB and the like, but i struggle with da english.

While that is true; KSP has continued chugging along since KSP2's announcement. Meaning that until KSP2 releases; there's no proof either way for the claim that Squad is lying about the continued development of KSP. Also you've already had an entire thread with numerous people explaining why these points are dubious at best, so at the very least could you chill? As for the OP We got hints of the next DLC from SteamDB and Repos for "Serenity", so i'd be watching for anything there.

Ah i see; i was thinking of a falcon9/Starship design with a independent cluster for reentry/boostback/landing. My apologies.

Depends on how big your lander is xD Also I'm pretty sure KSP2 has already confirmed that they're implementing clustering from the get go, but it's not a good solution around limited ignitions without some serious upgrades to the action group system. For instance it would be great if I could set an action group to fire engines at a specific thrust limit or throttle level.

How do landers work under this model? Would we get some beefy hypergolic engines for them? Would we get improved tankage for Monopropellant? Right now the current 2.5M parts are just sad. I don't really have an opinion either way about this, but when you're proposing limited ignitions it should also take into account the numerous other changes that would need to be done to accomadate them.

KJR is the abbreviations for several mods named "Kerbal Joint Reinforcement" that help with exactly what you're describing. It uses a bit of logic and the autostrut system to prevent ships from becoming pasta noodles, and does it much better than stock autostruts could.

+1 for KJR, and I've occasionally had some really wack physics interactions ( like a center engine detaching from the base, orbiting the COM and then tearing up the rocket). Sometimes you just have to embrace the jank and redesign with it in mind.

Gonna do this kinda backwards, so forgive me. But the only reason i mentioned that was that this is a common mode of failure for contacts now, and i couldn't see how they'd really prevent it from occurring. Therefore to me it's important to consider; rather than more rare/specific bugs. Being able to farm the entire TT within the Kerbin system is somewhat of an issue, but it could be easily corrected by reducing the science multipliers within the kerbal system. And Gilly is actually pretty easy to get to, with transfer windows to Eve occurring much more frequently than Duna. So there's multiple reasons you'd want to go for Gilly rather than Duna or other planets within a career save; especially if you're not as experienced with transfers. As far as the center portion; this i do actually agree with. But i don't think a rigid structure that forces extremely specific achievements is needed to get a better sense of progression; especially if they decide you can't just make the fuels for Orion or Torchships in the Kerbin system easily or make the concentrations so low that they'd take hundreds of days of game time to get enough to do anything interesting.

I still don't like it because the beauty of the TT is that it doesn't railroad you into any one specific way for unlocking it; if you want to get science early-game by going to gilly instead of the mun or duna it's totally possible. Or perhaps you'd rather just get all of it from minmus and the mun. KSP2 has been about more options, bigger sandboxes to play in, and more tools to stay on the places you visit since the first previews. This would be a considerable downgrade from even KSP1, and wouldn't really mesh with what we've seen of KSP2. Also imagine how frustrating it would be to not get a key technology just because something bugged and one of your conditionals failed to fire? Or how much of a nightmare this would be for modders, since now modded parts don't "Count" for progression unless they explicitly patch them into the statements. I just don't see it working well, or being recieved well by most of the community.

That's basically turning the Tech Tree into the Contract system; which i'd honestly say is the last thing I want to see.

Well yeah; though i seem to misplace brackets or semi-colons more than flub on a comparison xD

The reason they're so complex is because currently you have to use the robotics system, know how torque works, and manually adjust blade pitch to get anything off the ground; a propeller engine rolled into a single part wouldn't have nearly as many issues. You would still have to have a tutorial covering torque and blade pitch though, and KSP2 already committed to far better on-boarding so that's a non-issue. Also that's the thing; i don't need a compatibility chart for my current install. And what kerbalism considers compatible isn't always what i want, and i can't change that without breaking the entire suite of mods along with it.

Where did he use "=" instead of "=="? I know "=" assigns a value to a variable, and "==" compares two variables. iv'e been writing conditional statements and loops most of the evening actually, so i guess my brain may be a bit fried and i'm not seeing something right in front of me.

Care to explain? Both are asking the same question "Is a Class named Eeloo part of the Planet Class", so any differences would be down to order of operations. Also i didn't see either with any single "=" operators.

That's actually pretty hilarious; if you ever make a game that'd be a fantastic Easter egg

Yeah; they're intending it as a Module Manager replacement. Anything beyond that would be done by calling KSP2's modding API's that they've implemented; which as you said would be C# or C++ depending on the scope of the mod. And that would be incredible honestly; I'd much rather deal with my configs being classes than seemingly random files. At least then i know exactly what trail to follow if whatever I'm trying to do isn't in that class; due to inheritance. Didn't even think of localization because I'm a filthy English speaker, but you're correct that's going to make it 100 times easier. Instead of building everything from the ground up for a given language, you'd just have to replace all the calls to the EN localization module with calls to one of the desired language. The code itself wouldn't even care to know what language it was outputting (Rightfully, computers only know binary at the end of it all anyway)! But yeah; i never thought they were going for a full .Lua implementation. They've always talked about it in the context of scripting; still excited to see what people do with it though.

I've honestly gotten more of a performance improvement in loading times with more and faster system RAM, and more VRAM on the GPU. If you have already maxed out all other components then I'd recommend a NVME SSD, but your system looks budget. So I'd say you should get a 256GB Sata 3 SSD as a boot drive, and a 1-2TB 7200RPM HDD for storing games. Then focus on the RAM and GPU for the most part. Are you planning on running the APU until you can save up for a GPU? If that's the case I'd invest in a kit of 3200mhz DDR4, 16-32GB capacity. Also I'd honestly say that you should look for a B350 micro ATX board at the minimum (Full ATX preferred). That A320 is ending up in the garbage if you plan to upgrade.

I didn't know if Lua would be able to access these things and make edits, so that's most of the source of my confusion. I'm aware of it being a scripting language, but that's about it... And being able to pull a KSP .cfg file into notepad++ and use XML highlighting would be awesome, but i do understand that's not really a huge benefit. One of the biggest issues is just documentation; it's very difficult to actually figure out what in a .cfg file does what. And makes anything but very simple edits much harder than they should be; which is why i'm all for a more standard format be it XML or not. But most of that should come with KSP2 being built from the ground up with a skilled team knowing what the ultimate product should look like/be capable of, so i'm not too worried.

Kerbalism is a compatiblity nightmare, and doesn't handle it gracefully either. It shoves it's own modules on modded parts instead of even caring about how they're supposed to work; which is fine honestly. I get a mod maker having a vision and deciding to override the behavior of anything else to preserve that, but it's also meant that at least for me i wouldn't touch it with a 50-foot pole. Also there's the small matter of my main rig being down for the past month (I'm going thru KSP withdrawl pls help meh!). Yeah the fact there's no basic set of aircraft parts at the beginning with propeller engines, canvas wings and the like is pretty large omission; along with you unlocking Afterburning Turbofans at the next node. Logical progression would be from low TWR fabric and stick craft, to moderate TWR monocoque prop planes (Think ~30's era aircraft), then finally high TWR heavily reinforced prop planes along with more exotic engines like https://en.wikipedia.org/wiki/Turbo-compound_engine These would represent the cresendo of Propeller craft until Turboshafts introduced later, and would introduce early Turbojet engines like the Jumo 004, Rolls Royce Welland and the GE J31, along with whatever the USSR was (Likely a copy of German engines). Then you'd enter into the 50's era of engine technology, progressing into the highly experimental and bleeding edge Hypersonic and SABRE-like engines. Rocket Technology would be more fleshed out at the beginning; we didn't start the space race with solid boosters! Something like the A-4 or V-2 would be your starting rocket, and you'd gradually unlock extentions for it until it became more viable to have a clean sheet design. Then you could introduce our beloved kerbal engines, tanks, and some better probes; manned flight happening more mid-game than from the very beginning. Contracts should be overhauled; exploration contracts should be designed to trigger the next series upon arriving at the first body instead of waiting for all of the set to be completed. More scanning, relay contracts should also be present, IRSU and space stations should be positioned more tactfully. There's a lot of low-hanging fruit here; i think we're all agreed on that.

Alright you got me here; i actually haven't heard of any of these. I'm aware; i was just surprised at most of the strong reactions to some of this stuff and wanted to get some cheeky laughs. But even XML would be a massive improvement over what KSP implements now, but they have teased a scripting language based on Lua in KSP2 that may be a replacement for Module Manager. So anything for file/data formats would have to be compatible, and i'm not that familar with .Lua to know that.

XML stored in a SQL database defined by a public XML schema.