t_v

I see. Thanks for the huge insight to the physics engine. The main use case for this theoretical mod would be to build orbital stations that could run well, large enough that there would be no real reason for attitude control or thrust. Initially I was thinking of making something that fused the structural parts together and made their joints rigid so that you could build large platforms that act as one plate of metal or a truss that goes the entire length of a ship that doesn't need to compute deformation because it acts like one gigantic part. But the wider use case of generally removing physics from parts is also a good one. That is probably true and I don't know nearly as much as you about this, but if vessels are packed like this, what trickery does the "persistent thrust through timewarp" feature use? Could it be ported over to allow for thrust, provided that you activated engines before packing the vessel? so as far as I understand this, the packed vessels are kinematic rigid bodies and the unpacked ones are non-kinematic, and they will collide fine. But if you take two packed vessels, they will not collide? I'm not sure if this is the correct interpretation of that, but if you had a small unpacked spaceship, it could collide with the rigid body that is the packed station. At that point, it would function the same as a landed base, right? The problem comes if you are colliding two packed vessels because they clip through each other. That is a problem I personally am ok with because at the point that I need to pack a vessel, there is no reason it should dock to another packed vessel because it has everything it needs already. yeah, this seems like a pretty major issue. I don't know why it would do that, considering that time warping while within range of another vessel does not cause it to instantly drop from orbital speeds to stationary, but I'm learning to mod and I might be able to come up with something. also, your mod looks really cool. I see that it is updated to 1.12! I'll try it out as soon as I have a surface base to be proud of. Good luck!

Two things I noticed: First, it appears that the supply lines will be the way I thought they would be, where the route you took repeats itself every time the same conditions are met such as a specific transfer window or time of year. I think this is pretty cool for both casual and advanced players because you can easily increase your supplies without being amazing at the game simply by flying more missions, and it gives a use to the end-game engines by allowing you to transfer to other planets at un-optimal times. For advanced players, I could see challenges where people deliver the largest amount of supplies or try to have the largest supply to rocket ratio or try to have a minimalist challenge to make the smallest rocket that can deliver x amount of supplies every day of the year. Pretty cool gameplay challenges. Second, when talking about the habitation rings and mentioning that there are more considerations to take into account when planning missions, that is good news because I take it to mean that kerbals can no longer sit in a wireframe seat for a hundred years or more. This will make optimizations a lot more interesting, as people will have to design for time as well as efficiency, and will have to come up with some interesting maneuvers to get to places as quickly as possible. This also gives use to the end-game engines because you can go faster and therefore further before your kerbals start suffering from whatever effect they are under.

I know this comes across as an ignorant move as I am asking someone else to consider developing a mod while I am unwilling to do it myself, but I was thinking about a mod that could reduce CPU load for large stations in vacuums. If you disabled the collision detection for individual parts but created a collision box for the station as a whole, treating it as a single rigid body until something touches it, it could cut down on a lot of computation. One inaccuracy that occurs here is that the inertia of the parts are computed as one spherical mass so some of the fancy effects that occur from having weird shapes spinning around would disappear but for most large applications, instead of checking each part for forces it would only check one big "part" for forces without necessarily combining the modules. What do you think?

I think that we might be able to get a hint from the statement that when supply missions are scarce, kerbals don't die but are less productive in colonies, and I take this to mean that inactivity will result in less production everywhere, to avoid this timewarp thing. for example, you could get income from delivering a payload to LKO but that income would decrease to a trickle over time, as if customers are turning to more innovative agencies, until you make a more efficient mission to attract business. This way you have an incentive to try the same thing with much better tech and avoid timewarping ludicrously far. Same with colonies, if there are no supply missions coming from Kerbin, which happens when you start to lose income, your colonies slowly slow down their production rates until you secure new income and therefore more snacks and moral support to the colonies. At the point where it becomes hard to make more efficient missions, you are already at endgame, at which point you can sell resources for big profit.

Hi, I recently installed the entire near future and far future mod suite, but there are no new radiators to dissipate heat, and my rockets end up covered in the max size vanilla radiators. I hear that near future electrical is supposed to have radiators to help with that but I have redownloaded the mod a few times now and it does not have any radiators in the files. Is there another mod that I do not know about here, or am I doing something wrong?

wireframe with flat sheets of color (just sample a point in the frame and take the color and average light value to make the interior) would look nice to me, although I understand if that is hard to implement as a shader

you can enable advanced tweakables in the game, use 6x symmetry and remove two of the things, that will give you the symmetry you need. They could make it so that it is enabled by default but then they would maybe add the other advanced tweakables and there would be too many buttons by default

This would have to be implemented with some sort of texture generation, because adding up to a few dozen textures for each part would blow up the file size and make adding parts with mods much harder. And I think that if it is added, it will be a mod because that small level of detail would not be implemented in the base game.

Just wondering @Nate Simpson, will there be a mouse-over text option for UI elements? because while old players may know what each thing means, newer players would likely not see the atmosphere gauge for instance, and having it being identified if you hover over the UI would be nice. Also, I'm with 1 other person in thinking that altitude should be more easily visible, with its own spot on the screen.

I've never really played with mods much, what happens when you install all the planet packs? If all the planets, past and present, are updated, will it form a sort of galaxy? Is there a mod to make sure the solar systems are spaced out interestingly?

Precisely- meaning they would have to be reality-defying. Out of all solutions, magnets, large masses, and some sort of artificial gravity would be the only "realistic" solutions to photon storage, a term which is likely never going to have a real-life use, and in any case, you can store much larger amounts of energy in antimatter/matter containers, rendering "photon drives" mostly obsolete. But if it were implemented as a mod, I would see magnets being used to contain the light

I think that having extendable cables would be great to build our own skycranes. Although, since dust is not a problem in KSP, this might not be a necessary addition

This sounds like a great idea for a mod! I'm concerned that the magnets required to contain photons in a space small enough to fly would be almost reality-defying, but considering that there are antimatter engines that do effectively convert mass into energy (a good portion of which comes out as photons), we might see something similar

The ksp 2 supply missions seem to be a great way to provide optional and worthwhile new content without overloading the player. Planning and executing missions allows players to both design and fly cool rockets and watch their capabilities grow. In my own playthrough, I oftentimes spend my time designing ships with lots of parts to deliver to colonies and it is great fun, especially when delivering parts for special missions. However, the question still remains, how will the supply missions actually work? Here are some ideas: 1. Taking stats from a mission and just using that This would be the simplest solution and probably the easiest to code, and it would result in only one mission being required for continuous supply to a base. If there are many planets and systems in the game, running up to a dozen missions for each colony could get tiresome and result in a less fun experience, which would mean that a single launch solution like this would help. Also, you can spend time optimizing a single rocket to deliver to a colony, which might be fun. 2. Taking stats from multiple flights This suggestion has been posted in this forum before, and as far as I understand it, the premise is that multiple resupply missions would be taken into account, averaging the cost of deliveries. This seems like an improvement of the first suggestion, as it rewards skilled mission planning and execution, allows for fun while repeating missions to try to get a better average, and is skippable if a player simply wants to use save states to guarantee the perfect supply mission in one go. As an additional suggestion, it would be cool if you got more supplies with more different supply missions, to incentivize repeating missions (but not too much) 3. Running missions when the initial conditions are similar First off, I admit that this idea will be hard to implement perfectly, but here it is: Essentially, say you wanted a supply mission from Kerbin to Duna, and you launched it at the traditional transfer window. the mission stats are saved, and the mission will run again, but only when Kerbin and Duna are once again at the same angle compared to each other. The issue with this is that direct transfers are always going to be more common than gravity assist routes, so it discourages smart mission planning. This is where the hard coding comes in. The missions are not linked to a specific angle each time, they always have a range, so for example if you assisted off of the Mun to get to Duna but on the next transfer window the Mun was 15 degrees off, the mission will still run. The third solution is helpful for a number of reasons: Players can simply run one mission and the same supplies will arrive each time, meaning that if they want to, they can launch a massive ship with enough material for a whole year and leave the route alone. Even without sending a massive supply run from the get-go, as you either increase the size or number of your supply missions, your colonies will get more and more productive over time. Also, this system does incentivize clever thinking as you will want to deliver the biggest payload possible, meaning gravity assists are essential for the biggest missions. And lastly, with the advent of interstellar engines, players can begin using their power to launch missions outside of traditional transfer windows, powering their way to the destination, which gives a new boost in productivity and also gives an excuse to use future tech in the now tamed Kerbol system. What do you think?

I think that the essential problem of things looking different between different levels of detail persists there. Also, in the case of bedrock, while the fading in does help, the fact that loading chunks are much farther away makes a much bigger difference. the way to get a sort of seamless transition is to have details be represented the same between LOD levels, similar to how some approximation methods such as Fourier transformations look relatively similar between "detail levels" but just gain smaller features. The issue is that setting up the system to be consistent throughout the approach and as different levels of detail are loaded in is mathematically challenging, not to even mention the challenge of implementing it with a custom landscape in a rendering engine with all of the coordinate challenges of ksp. I think that in the future, an update will come out that blends detail levels together, but for now, having a working LOD is good enough for me.

For challenges, I hope there will still be major orbital challenges, not simply infrastructure challenges. I know Rask and Rusk have their dual systems and any planet with rings requires you to navigate well or end up crashing into lots of space rocks, but I would also like to see challenges that require you to use "worse" engines due to limitations that the better engines have. As a (bad) example, a planet with an immense magnetic field that causes computer systems and any engine that relies on magnets to fail