Jump to content

starcaptain

Members
  • Posts

    147
  • Joined

  • Last visited

Reputation

248 Excellent

2 Followers

Profile Information

  • About me
    ambitious thing-maker
  • Location
    vancouver
  • Interests
    we'll have an adventure
    and several long trips
    we'll make some new friends
    and maybe get a bite to eat

Recent Profile Visitors

1,836 profile views
  1. Parts fail if they get too hot. Can they fail if they get too cold?
  2. I too am in support of the "as long as it takes" timeline.
  3. Still picturing that silly monorail mod idea I posited: can requests be made so that are sent or arrive in block-like increments? I know that "rate-based" means basically Flowrate and assuming the resource (say, a fluid, or even electricity or solar energy) is arriving by some kind of direct pipeline (fuel pipe, wire, line-of-sight to a star, etc.) Would it be a manner of programming to build a flowrate so that the resource "is delivered" as, say, a tank of fuel that's 5000L all at once (because the tanker arrived at the depot) instead of 50L/min ? Or is the core of the system made so that the only way fuel can be transferred is between containers with the flowrate? Meaning if I want to run a fuel delivery railroad, I still gotta discreetly transfer fuel from the depot tank to each railroad car.
  4. Will clouds get shoved out of the way when our flaming piles of garbage that used to be rockets careen through the clouds? Praudl-glauert singularities? Double-rainbows?
  5. I think the light source method is the most likely method that they'll do, but I suspect that it won't be something updated every frame. Unlike thermal radiation, I don't think it's going to have impacts that will hurt your spaceship as fast as reentry heating could. But I can imagine the following: You're physical-timewarping your vessel from star A to star B, and the radiation meter starts building up on some parts, over the course of weeks or months instead of seconds. It looks exactly the same as the thermal indicator, but a different color. If it "overheats", the part fails. As for crew exposure, I imagine it'd be a place where crew health bars makes sense.
  6. You do realise that Ovin will win the vast majority of the time, right? It's like picking a fight with a wall.
  7. Friend of mine is sus that the blendshapes don't conform to real world maths. He sent these citations from Rocket Propulsion Elements by George P. Sutton. As usual, I expect my (or my friend's) pedantry can be solved by mods but nonetheless I'm delighted to see the game's progress nevertheless.
  8. The video I saw on twitter looks like the thrust plume also works as a local light source, at least against the engine. However, it seemed to my eye that the lighting was very harsh and overblown. It was also emitting light through the thrusterbell, which means self-occluding shadows were not enabled, which is understandable from a debugging point. I am curious though: will things like the shock diamonds have HDRI lighting? Or is that beyond the scope of KSP2v1.0/a question for the modders? (Also, practicality doth protest to using rocket engines as area lamps around your colony.)
  9. Here's hoping mods can also change the UI. Oh, jolly good. Can't wait to fly my ship using controllers that read out in: * Digital * Roller dials * Analogue needle mach gauge * 7-seg liquid crystal displays * Split flaps * Nixie tubes * Conway's Game of Life sims * Japanese synchro-walking * Skyrim handwritten notes * etc
  10. Do you think that Unity could support hot-swapping the host? Picture this: you and x friends keep a server continuously online by always having overlapping sessions at some point.
  11. I am imagining KSP2 will have multiplayer up like, maybe 8, much in the same sort of manner as Terraria, like K^2 said. Colliding vessels while in space is one of those things that's destructive but also takes effort, like making a coordinated demolition in Garry's Mod. So i don't think that's a route of problems. And the editors aren't multi in of themselves, so players can't ruin each other's building task...
  12. We all have high hopes for the multiplayer features of KSP2 but it occurred to me: not everyone likes to play nice. Seeing as we have little to go on for how multiplayer works, it's hard to imagine what kinds of griefing or abuses may appear. But i raise this as a topic of concern, because the online culture of a multiplayer video game is greater than the sum of the many different parts that make it up: *General player attitudes within the game *Groups, cliques and common play styles *Attitudes of the developers towards the online culture *Tools made by the developers for ensuring safe, uncorrupted play These and other things will have great impact on how and when trolling might occur, and how amusing/annoying/destructive/toxic it may be. I want KSP2 to succeed, and the main thing i can do in that dimension is wanting to be a supportive, friendly, and polite player. But I don't know how core these sorts of thoughts are for the developers.
  13. I'm curious: What if two players set up their velocity so that their orbits are very close to one another, but with inclinations nearly exactly 180° apart, so that their relative velocities are basically 2x orbital speed; I imagine the continuous collision check is happening every frame where their trajectories are similar. Wouldn't this have an impact on performance, even if the players were in opposing positions on their orbits where collisions wouldn't happen (yet)?
×
×
  • Create New...