Habalabam

@Brikoleur My post stated that I agreed with you. Did you read the last sentence of the main paragraph? It was a response to the notion that a simple "lowest bidder decides the global time compression" was from a lack of considering other options.

It can of course be the absence of effort. It can also be, in spite of considerable effort, not finding one. It can also be because there isn't any better. Either way, it is the one to beat. With burden of proof lies on the challenger. It would be nice to have a cake and eat it too. Like I said, playing around with your fuel extraction+refinery+depot another player has a completely independent experience with time compression in another part of the solar system, but I've seen many suggestions at spheres of influence, but they run into persistence issues. In the previous KSP forums, I remember a "look ahead" model where the game could incorporate separate event bubbles. Meaning that if a guy was mucking around at the Mun base, then you could launch another satelite in orbit around the Mun while he was active on the mun surface at 1x time compression the whole time. However, in order to complete the mission with time compression, you jumped ahead of him on the timeline. When you had completed your mission, you could jump back to his time and the mission would unfold just like you performed it, meaning that the mission would complete itself sometime in the future. A sort of advanced mission planner that would unfold exactly as you did it unless something affects it, erasing its future timeline. But the edge cases became too many and contrived and the end result would hardly be possible to utilize. Since we have such a beautiful time sink as the VAB, I don't think it will be a problem.

To me, the multiplayer scenarios are: Mayhem. Let's take the designs and go crazy. Be it flying, racing, fighting etc. I believe the spaceports should have a little distance, but not so much that meeting up with land or sea faring vehicles is impractical. Dual campaign. We play in parallel, but we interact. Separate tech trees, separate spaceports, separate installations. You can dock with my stuff, but I still need to activate my valves before you get any fuel. Or I need to grant your kerbals permission to enter. Co-op campaign. My favorite. PVE. We co-operate. We can even work on the same design simultaneously (co-op in editor) if we so choose. I think the most obvious solution to time warp is that the person with the desire for the lowest time compression decides. So, if I desire a 100x time compression, but my buddy desires 1x, then we go with 1x until he ramps it up or surrenders control to me. The problem then is, what do you do with time consuming stuff such as driving a rover or flying a plane? Must everybody else wait while somebody does that? I think the simplest answer is "yes". I think that an alarm clock system is necessary, so I can set the my rocket to give an alarm and go to 1x time compression when my rocket reaches Mun. This leaves me free to play around in the VAB or something in the meantime until my event comes up. I agree that there can be situations where it would make sense that a person could muck about on the Mun surface at 1x speed and not caring that day suddenly turned into night because someone else needed time compression on the interplanetary scale, but I don't see how this would be practical. This is simply the price to pay for multiplayer. And, of course, I want to undertake a mission as a kerbal, maybe even first person perspective only for the hardcore players, with my buddy sitting next to me while we together. With only access to the controls that my kerbal is operating from his/her IVA seat. And we can reenact the Apollo 11 mission.

1. What happens when only one player warps? Does only your ship move? Do planets/moon move? If you time warp to meet with some other thing, then surely the thing that you plan to rendezvous with must also move even if it there is another player near/on/in the vessel/moon/planet that you want to meet up with. 2. I believe this can be solved by every player being the authority of who gets to control his/her kerbals (/probe core). If you dock with something, and no kerbals that you may control is at the helm of the space station, then you will not start controlling the space station upon docking. 3. ...Or multiple space centers. Or just multiple launch pads (purchasable in career).

I don't think multiplayer will be multiple players in one craft. Of course you may have occasional serious roleplaying sessions where this would be cool, but mostly not as there is only one pilot to a craft. Although the other roles are useful, they are more like tools being 95% idle. My buddies and I will most likely play cooperatively, trying to get a successfull mining/habitation/research enterprise rolling. Populating the Kerbal/Mun/Minmus system. Many independant activities that will cross paths. Time acceleration across all the various activities that will take place is a complex problem. There are multiple approaches that are simple, but I don't see any that is without drawbacks. The crux of the problem is to have long running treks in 1x time accelleration (like rover missions, atmo flights, probe hopping, base mining/trucking/assembly/management) without forcing everybody else in 1x. I realize that you can mitigate this by having time elastic activities, like tinkering in the VAB while others are out flying an airplane. If SQUAD has the time warp system down, then I would very much like to see a thread describing the details. If anybody else feel that this is a solved problem, then please describe the solution (I never played the unofficial MP mod) and please also state what weaknesses you yourself recognize with the solution.

The problem is that when you time accelerate, you expect everything else to move as well. If we are allowed to time accelerate completely independantly, our two game sessions will not agree on where anything (moons, planets, space crafts, orbital stations etc) is. The point of multiplayer is that we operate in the same universe. Let's take an example: If we are able to time accelerate completely independently (as you suggest), and we are both floating in space by the same space station. I press time accelerate, what do you expect to happen? Shall the position of the space station and your vessel be dictated by my 10x time acceleration or your 1x time acceleration? Another example: What if we were both trying to reach the Mun? If we use different time accelerations, then the Mun will not be in the same place or facing the same way.

I appreciate that the idea is understood. Yes, the concern is that everybody will be slowed down to the lowest setting in global time, which will result in idle/waiting for other players. Unless you want players to go in different time lines, and then later "synch up", I don't see how you can avoid this. The crux of my idea is the opportunity to opt out of global time so that lengthy treks with the rover are not frowned upon by people doing orbit transfers because they want to time warp. The pace of the game varies extremely. Also, it is just a toggle button that with a simple concept allows to play the game in many ways depending on how the functionality is used. But there are of course many things that still would need to be hammered out. For instance: * How do we handle when players at different time accellerations come into proximity? A: I'd say that they need to be slowed to the slower of the two. * When you are doing small maneuvers out of global time on the Mun, will the Mun suddenly spin underneath you ("Smacking" you with a mountain peek)? A: There seems to be a certain altitude for celestial bodies in KSP where the indicated speed jumps from surface speed to orbit speed. If you are below this threshold, I would say that your craft should follow the rotation of the planetoid (the sun will be racing around). If you are above this threshold, that's a tougher call. The ideal thing would be to have EVA and such possible to be done outside global time as such activities can also be time consuming all the while you may not care about the rest of the universe. However, I cannot see how that could work. Multiple vessels (including the EVA kerbal) involved in any EVA/docking operation will have slightly different trajectories which needs to be reflected when global time accellerates. So, I tentatively conclude that opting out of global time can only be possible planetside, which results in everybody having to wait for docking/space station assembly/EVA/repairs etc to be completed. I still think it would be a big win if you were able to do 1x stuff planetside while not stopping others from doing time accelleration, even if it is restricted to planetside operations below the aforementioned altitude.

(I didn't find a recent thread on multiplayer) To me, the griefer potential of KSP is too massive for MMO. Multiplayer, to me, will be my friends and me trying to set up some joint effort. Mining/refueling orbital stations. Establishing some large colony. Multicraft missions. Rescuing/Supporting each other. Space tugs. Flyby shenanigans (formation flying/dogfighting on Kerbal). Roleplaying a lunar mission (each one controlling a member of the crew in the same craft). Gameplay wise, the large discussion seems to be around time warp. I've already dismissed the idea of MMO, so it seems to me that the best solution would be to have time acceleration set to the lowest that is desired by any one player. If somebody is in the process of landing on the Mun, the rest of the players will spend the time at 1x acceleration. As long as it is easy for me to either watch the other players (performing their docking maneuver or whatever) or spend the time in the VSB, then I do not see it as a big problem. Of course, some good alarm clock thing is needed so that if the time warp is accellerated back up, then I have the time to jump back into my ship and proceed with my mission. However, what if a player is driving a rover around or flying an airplane? These are long running activities that are spent in 1x. While doing this he may not really care about planets positioning. Should then the whole game wait for him? I don't think it would ruin his gameplay if suddenly the sun raced across the horizon, even though he was driving in 1x. So I feel that, in the name of players respecting each others time, you should be able to time accellerate in space while 1x operations are going on planetside. But what operations are "planetside"? How would the game know that you are not caring about rendezvous, transfer windows, day cycles etc? So here is my suggestion: I believe that this must be a new toggle button alongside the Time acceleration controls. Call it timesynch, global time or something. When enabled: You are part of the time control that includes satelites, planets, moons etc. Time accelleration for everybody in "global time" is decided by the lowest desired time acceleration among the players in "global time". When disabled: You are NOT part of the global time. You can be in any time accelleration lower than the global time. You risk some weird effects. Such as the sun suddenly racing across the sky and turning things to night without affecting your driving your little rover. If you forget to enable "global time", you risk that your planned rendezvous target suddenly is on the other side of the planet. You may crash land on the mun and try to fix stuff (in 1x speed) for just 6-7 minutes and suddenly see the rescue mission coming for you even though it strictly speaking took much longer for the mission to get there. If a person in "global time" desires 1x time acceleration, absolutely every player will be brought to 1x. The crux of this idea is that although you cannot opt out of being "hampered", but you can opt out of hampering if your current mission/activity allows for it. It brings flexibility. It allows for a mostly FFA model if everybody has it disabled, and it allows the die hard gaming people of forcing 1x across the board. This requires a good alarm clock feature, so that you can spend time in VSB if you do not want to follow the landing/launch/docking or whatever which is going on.... without having to baby-sit your in-transit vessel in case the time acceleration suddenly kicks back in. What do you think?

Question: Exactly HOW is a chute deployed at high velocity in upper (thin) atmosphere supposed to act? It seems weird to me that you have reentry heat before significant drag effect from the parachute. If you deploy it LKO, shouldn't the parachute start to work the moment you start grazing into the atmosphere? Granted that it should be destroyed, but shouldn't it tear up because of the unrealistic deceleration rather than burning up?

One thing that I think should accompany every release is a working set of stock crafts. I don't doubt that the QA and independent testers have tried both massive aircrafts and SSTO. But with every major overhaul of basic physics, the paradigm of ship building changes. Online material from youtube/images become obsolete and even misleading. To have these differences visibly expressed in the catalog of stock crafts would keep everybody on the same page. Since we're now out early access and going mainstream then the stock crafts are even more important.

Please edit your first post in this thread and set the state of the thread to "Answered"

And, it's not a far stretch to go from a refueling station to a service station (doing repairs) into a space yard. Kerbal would be space engineers.

It makes sense that the Ore will not be valuable back on kerbin. The main value of Ore is that it is fuel outside the gravity well of Kerbin. To bring it down planetside would mean that it is just unrefined fuel. That being said. I, for one, would like to see mining being expanded upon. Maybe three different resources. One for construction, at least one for energy/fuel (conventional and futuristic) and one to bring back for money/science. To set up a thriving infrastructure in the kerbal system is something I would like to spend a lot of time doing. Running it is also a decent backdrop for multiplayer. Deep space missions require little interactions. Running the "family business" together would be a better premise for player interaction than one going to Duna and another to Jool. I also would like there to be more energy intensive stuff that would warrant a large solar array or nuclear reactor.

The TT18-A Launch Stability Enhancers left on the launch pad when a craft takes off are, when I return to KSC overview after mission, indicated on the launch pad as "debris" which I need to individually click and choose "recover". I don't think Jets are necessarily overpowered. If you attach an engine, which conceivably should be able to lift a large 747-like SSTO, to nothing but a fuel tank and single seat cockbit with landing gear, what happens is about what I expect to happen. This is just weighing in. I have done zero math on this to find the real world comparison. Also, IIRC, the only reason why fighter style aircraft can fly is because they are micromanaged by computers. If the developers are trying to find a stabile aerodynamic model to support such crafts, it is entirely possible it may not even exist. Since KSP is going mainstream, I find it odd that a player who chose easy difficulty in career mode and has chosen stock rockets/aircraft to be available, will be unable to find any crafts that are only based on early techs. What is the point of having that option if it does not help the player over the starting hump or at least use as templates/starting points? When going through the tutorial, the first time I did "go to mun 1" (sp?), the craft did not load and my camera started with the sun in the center. More people have reported this. I went straight from install to the tutorials, FYI. The second try, it loaded fine. There is something weird going on with whatever flags an item as "stowed away". I had two lateral chutes on my Mk1 command pod. They were placed using the symmetry function in VAB, but only one deployed. When trying to deploy the last one manually, it said that it could not deploy "while stowed".

Exact same thing happened to me. Radial parachute would not deploy "while stowed" whereas the symmetrically placed one opened fine.

You should consider having the Engineer Redux mod. It will show you the realtime data on the orbit. Especially useful during ascent is the height of the apoapsis and the time until you reach it. Your goal is to reach the apoapsis with as much horizontal velocity as you can muster. Once the Apoapsis reaches the desired height, usually about 75K, the your focus should be having adequate speed when reaching it. A good way to achieve this is to find the horizontal burn that will "push" the apoapsis in front of you. If the "time to apoapsis" is counting down, you need more thrust (or slight inclined upwards if at max thrust). The closer it is to you, the closer to orbital speed you need to be in order to avoid it counting down. Usually, the apoapsis can stay about 0.5-1 minute ahead of you. As you pick up speed, you'll find that you can be closer and closer to the apoapsis. As you are close to the apoapsis, only the periapsis will be raised by your thrust, thus achieving a circular orbit.

Thank you.

Thank you very much. How do I change the prefix of this thread to "answered"? It's not in the edit post options and it's not in the thread tools. I did not get an option for it when upvoting your answer.

I have a moon base up and running. I created a utility rover to be a workhorse around the base. It's really handy. it has three containers for various stuff that the kerbals can do small modifications with, a winch, a bunch of connectors, a portable generator, a nice fuel tank and all science instruments I have unlocked thus far. However, I see that it cannot really tow much using just its wheels. For instance, one of the modules of the base detached a stage during landing which contains a decent size fuel tank. The tank and engine survived and was laying not far from the base. Since the base is mining karbonite and refining it to fuel, I wanted to retrieve the tank for the additional capacity. The tank was much too heavy for my rover. However, the rover had four downward rockomax thrusters that was used during landing. I never planned on those being actively used during operation. Modding the rockomax thrusters to point backwards made the task easy peasy. However, those toroid tanks dry out fast. And I am wondering what I can do. I realize I can take those big tank pipeline connectors that usually connect the various modules of the moon base, but it looks strange to have two major components and a overly dimensioned pipeline just to transfer the fuel a few feet (from the utility tank of the rover to the four toroid tanks). I thought I could haul the fuel using the Karry Kans that I had brought. However, it does not carry regular liquidfuel and oxidizer. Is there any lightweight carryable (by an individual kerbal) container for fuel for this purpose? Is there any flexible component that a kerbal can use to connect two tanks and allow a regular fuel transfer? Preferably something that can be stored inside the "Container Type A" or "Container Type B"?

I have a moon base up and running. But I can't remember who had what job. I want the scientists in the laboratory. I want the engineers doing modifications on the facility and I want the pilots piloting rovers and short range excursion.

Yes, they are shown when you have a target orbit. Since we cannot set orbits that are part of objectives as target, we do not have the benefit of them. Thank you. I don't see what your concerns are, though. Whenever you are close to another orbit, there will be a point on that orbit that is the closest point to you. All I am asking is that the navball should should have an indicator allowing you to match velocity with the tangent of that point.

I apologize for not revisiting this thread until now. I thought I would get a notification if there were replies. Yes, I know about maneuver nodes. My grievence is two fold. First is the fact that you cannot set an orbit as target unless you target an object that follows the desired orbit. In a rendezvous mission, there will be an object to target. In the missions that reads "put such and such an object into such and such orbit", then the orbit is indicated in the star map, but there is nothing to "set as target". Thus I will not get an indicator on Na/Nd. Furthermore I wont be getting the indication on orbit inclination match either (by having Na/Nd beginning to swap places). Given enough time, you can always go back and forth between Ap/Pe to match orbits, but this can be time consuming and fuel inefficient to do this in stages. Any time you cross paths with your target orbit, you have an opportunity to completely match orbit. It is just a matter of delta-V. We have perfectly good navball indicators for that purpose to match speed of a target object. Why can't we have the same thing for target orbit? The targeted vector should be the velocity vector of the closest tangent of the target orbit. If that was in place, then any time you intersected the desired orbit (no matter where), you could just burn to match velocity to the tangent of the orbit and you would immediately be in the desired orbit. Of course you can perceivably do a docking operation without navballs indicators to match target object velocity, however I think we all agree that that would be needlessly hard. Since such obvious navball indicators are absent, nor exist in any of the mods I have seen thus far, I was wondering if I was missing something obvious. Thank you, all.

Hi. Several missions require me to match some specific orbit, either directly or indirectly (rendezvous missions). I miss two things and I am wondering if there is some better way of achieving these things. * The ability to target an orbit ("set as target", but targeting an orbit instead of an object). * Navball should have "closest target orbit tangent prograde marker". The latter marker would indicate the vector for matching velocity with the closest tangent of the target orbit. Thus you would be able to perfectly match orbit with a target even when the target itself is currently on the other side of the celestial body being orbited. Any time you cross an orbit, it is only a matter of delta-V to enter the orbit. A navball indication for it would make it a lot easier than all those nav markers. With a pilot kerbal assisting for this marker, it would make matching orbits a breeze. I find it weird that those two things do not appear to be in the game. Have I missed anything?