Jump to content

shdwlrd

Members
 View Profile  See their activity

  • Posts

    2,009

  • Joined

  • Last visited

 Content Type 

Everything posted by shdwlrd

  1. shdwlrd
    His last comment in this thread was from mid 2020. He does have enough patches to do an interim update just to get it working with the current release. But it hasn't happened. So basically either Eskandare can't get Helldiver to ok the changes or he has lost interest in KSP modding again. Either way, this mod is dead in the official way of doing things. Unofficially, if asked, I willing provide the MM patches "as is" to whomever asks.
  2. shdwlrd
    This mod will never have an official update. It's ARR for both assets and configs. The original mod author jumped ship when 1.0 dropped and won't return. The short story is the mod author must approve all changes, and he either doesn't want to or doesn't care to. (If you can even contact him now.) This mod should be considered dead unless the author changes the licensing. If he hasn't done so now, it's never going to happen. If the configs were any other license, there would have been at least partial updates done. Alas, ARR is ARR, nothing is going to happen until the license changes.
  3. shdwlrd
    You're just scratching the surface. I've seen these bugs and can add a few more. A loose part sliding across the surface with a less than 1 degree slope. Stopped on the surface and still registering movement. Loading large complex crafts can fail. (See some of ShadowZone videos.) Bases loading in the ground and either exploding or jumping in off the surface. (Yes, this bug still remains, just much less common. ) Floating bases. Weird, unexplained physics reactions. (All the Kraken drives still hanging around.) Wheels clipping through cargo bays and ground. Inconsistent wheel behavior. Sometimes you drift, sometimes you flip. No leeway for wheel angles. Inconsistent suspension behavior. One jump they will survive, the next they will collapse and boom goes the rover.
  4. shdwlrd
    T2 is basing the price on hours of play, not features. The comparison to RDR, GTA, Fallout series, Mass Effect, Halo, Cities Skylines, The Sims, etc. has nothing to do with the type of play, but the time in hours players usually spend in the game. Now for a $60 game, I would expect a decently polished game, AAA or not. Intercept is exceeding my expectations with new and extended features. But only when the game is released can I determine if I will spend the money or not.
  5. shdwlrd
    That's funny. I've never worked for a company where they communicated everything they were working on to their customers. Have you heard the saying "one bad apple spoils the whole bunch." The few obnoxious users can ruin it for everyone. That's just the way it works. You'll only put up with so much before you say screw it, I'm done. Games are not like tangible industrial, commercial products where you need to know the full specifications to determine if the product is acceptable or not. Games rely on peoples emotions, and that is a very fickle thing to gauge. So it's better not to tell your secrets before you're ready to do so.
  6. shdwlrd
    That would be awesome to see.
  7. shdwlrd
    You have a bunch of valid concerns. But Intercept never said that physical crafts would be running these missions. The original flight is considered proof that it could be done. After that, the resources are transferred on a schedule related to you original flight. It's the easiest way to create a resource transfer system without having to consider all the minute details of doing an actual mission. There is no need to spawn an asset with that method. I maybe wrong, but this is the best solution to the infinite number of ways to do a mission. I personally don't like this method, but it makes sense in the ease of getting it working. Intercept may surprise us, but from everything that has been said in the subject, it looks like everything will be abstracted after the mission proof is done.
  8. shdwlrd
    They already said it will be about $60 usd.
  9. shdwlrd
    I'm not to worried. The current explanation for automation would be completely abstracted with no physical craft moving around. My little pipe dream scenario for automation wouldn't work beyond a planet's SoI anyway. You would need a couple static destinations or a destination that you can easily figure out the timing for it to work. So surface to surface, surface to orbit, orbit to surface would be the best uses for it. Every transfer would be very similar so you can set all the parameters and record all the maneuvers and execute them with the same results. But it's my ideal solution, not the one currently suggested be Nate.
  10. shdwlrd
    I don't know why you would, but I would build up the approach side of my colony because I will forget what the approach direction is. What? I can't describe the situation from the view point of the colony? Which would be a static point from that point of view. I don't know how you would setup an automatic route from orbit to surface or vice-versa. I would have it setup from a station to the colony. At that point the automation would be fairly regular. So the only thing that would be recorded is the actual landing or docking, whether it's good or bad. The rest is a series of recorded maneuver nodes executed at certain times and coordinates. That's my current thought process for the scenario, not caring what Nate said about automation.
  11. shdwlrd
    It would be cool to see. But you’re right, it's another point of failure that can lead to frustration. Imagine, you barely stick the landing, and having to watch that poor landing again. Or you adjust your colony and you see your craft go plowing into the buildings cause they weren't there when you first recorded the route.
  12. shdwlrd
    That's what you would have to do. It's just a matter of knowing at what altitude your booster dies out and planning for that. So planning and setting up your launch vehicle at the maximum weight possible, you should be set for anything weighing less. (There's always overkill, but none of us are guilty of that. )
  13. shdwlrd
    Tried doing that in KSP1, it's very good idea. In practice, it's a royal pita. My method of true intermodal containers did rely on actually moving containers around. What was I thinking? KSP doesn't make anything like that easy. It would have been much easier if you were able to easily change the cargo around instead of the actual containers. Again, without mods, that was impossible. I'm hoping that Intercept will make cargo hauling easier by not needing specialized craft for each item in the game. Or needing to physically move containers around. Intermodal containers would be a boon for KSP2 just how they are in RL. Just make them easier to deal with.
  14. shdwlrd
    We do know enough to speculate about the mechanics of the game. You could be as masochist as you want, but there will be mechanisms in place to make it easier to play through the game without making the game easier, if that makes sense.
  15. shdwlrd
    One of the dev diaries featured the composer. Don't remember his name though.
  16. shdwlrd
    Because it's easy, mindless fun or super challenging depending on the completion amount you're shooting for. (They really screwed up the mission selection by making it a huge open world with no obvious fast pathing though.) My patience as turned to whenever it releases. Me hanging around the forums is my way of not forgetting about it.
  17. shdwlrd
    It will depend on the TWR of the craft. The torch engines revealed so for would have TWR much lower than 1 in an 1g environment, yet alone a 4g environment. Your best bet would be a CeMH engine or a monster LFO booster. But remember, the rocket equation will always keep you in check.
  18. shdwlrd
    If Rask & Rusk was truly realistic, how would the player see it? You will have to account for the time it will take players to find and travel to the dancing duel. Not everyone will find it at the same point in the game. Player 1 can take 50 yrs to find and travel there. Player 2 takes 150 yrs, player 3 takes 300 yrs. So you will have to make it stable to account that players will visit the system at different times during their individual play through. That makes KSP a game, not a simulator. The little annoyances and not quite right things in reality can be ignored for a better experience.
  19. shdwlrd
    It's already understood that Rask & Rusk will collide at some point. It's just being created as a stable system for game play reasons.
  20. shdwlrd
    Better late than never... or so I've been told anyway.
  21. shdwlrd
    It's been confirmed already that only the Rask & Rusk system will use N-body. All other planets and moons will use the on-rail, SoI system like KSP1. No, Lagrange points haven't been confirmed, but most likely won't be simulated.
  22. shdwlrd
    You're a little late to the party. Yes, the cinematic trailer is quite good. Most of what they are showing in the trailer is described/discussed in the ksp2/show and tell section of the forum. If you do some digging, you can find some threads with the confirmed information about the game and a ton of discussions about speculative features and such.
  23. shdwlrd
    For KSP, the mod Part Commander worked perfectly for that purpose. You're asking for something like that to be included in KSP2?
  24. shdwlrd
    You can do that without BDA. It really doesn't take much creativity to make explosions and kill Kerbals.
  25. shdwlrd
    Lighting on your ship will help, but the will be light scatter from close by planets and moons. (Stock planetshine.) Your ships won't be in complete darkness for most cases.
×
×
  • Create New...