Jump to content

Tomator

Members
  • Posts

    7
  • Joined

  • Last visited

Reputation

1 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The aim of maneuver is to change velocity to reach certain target. A maneuver is complete when the velocity vector V is changed by dV planned by a maneuver. Since the acceleration vector is rarely perfectly aligned with dV, usually some deviation occurs. When maneuver mark doesn't follow this deviation, we're unable to compensate. Playing KSP2 I just watch the remaining dV bar to shut down engines when I see it rising. This means I can never do good maneuver. In KSP1 the maneuver mark was going aside so I knew if further burning can get me closer to the desired V or not and in which direction I should compensate. If I caught an asteroid or for any other reason had asymmetrical thrust the problem with static maneuver mark would be more than annoying. It was done perfectly well once. Please bring the KSP1 experience back!
  2. I miss the way how maneuvers worked in KSP1. Here the maneuver's aim is to change velocity by adding planned vector. In KSP1 it was to achieve specific vector of velocity, when the target velocity was a sum of maneuver's vector and the ship velocity at the point of the maneuver. The difference is significant when, during the maneuver, any deviation appears. In old game the marker reflected this deviation so it could be corrected during the burn and get quite accurate result. In KSP2 the change vector is constant and when deviation occur, the remaining dV just won't hit 0. Instead, it'll bounce up. The burn cannot be the done as accurately as possible since the player must wait for the bar to bounce back to shut engines down. I KSP1 when the marker went off sight on the navball it was a sign the burn must end. Ant, if maneuver's dV was significant, the ship could be rotated and the remaining portion of velocity change could be done. In KSP2 another maneuver is necessary to be planed. And another...
  3. Hi, I've made a quadcopter and found I cannot control it. If I attach rotors to yaw/pitch/roll and thrust I am able control thrust but yaw/pitch/roll override each other so only one is effective. Thrust works because it's incremental while yaw/pitch/roll are absolute. At first I wanted do demand multiple overlapping controls to work additively (and they should) but then I realized that won't be enough. The collective throttle must lift the craft while axes control should only modify torque to control its movement and may work much weaker. So the torque for single engine could be calculated by a formula T=(1 - 3k)t + ky + kp +kr, where T is torque, t is throttle, and y, p, r are yaw pitch and roll, respectively. k is axes to throttle coefficient, let it be 0.1, for example. Now, this cannot be done. So I think the formula controller should be available for our creations. Of course this will be usable not only in quadcopters. Why not control ailerons in function od speed? In supersonic flight they are too strong while in low speed maneuvering they could work stronger. We could also describe by formulas hinges' movements as a function of time or the controller's value (then a controller's path could be a variable, not necessarily bound to a part).
  4. Hi, The game has bugs, obviously. Then the updates are required ind it's great they are provided from time to time. However, they ruin the game when the user uses mods that are aware of the game version. But... Mods integrate with the game by some interfaces. What if these interfaces were versions were essential instead? Mods that use interfaces that didn't change would still work. While the game version is changes arbitrarily and the only difference may by texture update or adding new parts, which has no impact on mods, it can disable mods the user has installed. A nightmare is that when a mod defines some parts, no ship containing these parts can even be loaded. They disappear in the game. If the interfaces were versioned, mods would still be loaded, parts displayed ships could be edited and even fly - some part would cease function yet they still could be targets of a rescue missions - in worst case.
  5. I like new rocket engines sound but vacuum cleaner that replaced sound of Whesley must be a mistake!
  6. At 30km the air is so thin that aerodynamic steering may not suffice. Usually I have gyros that help keep the plane under control and maneuvering engines that let maintain safe attack angle when re-entering before the speed falls. Also, having 1500 m/s at high altitudes is quite good for gliding.
  7. The wheel suspension leaves some space between the wheel and the vehicle's body to place some parts, like rover's batteries. Theis was very usefull in 1.05 but since 1.1 it makes wheels blocked and "engine inoperative". Woth to mention I carefully placed these batteries not to touch the wheel even when turned. It's safe amount of space to let the suspension work too. The change made my already deployed rover useless. Any space is valuable and I miss the one between the wheels and the rover's body. Above is my rover with bateries placed on its sides. It's not the best angle of view but the batteries and wheels are well separated. No wheel can roll nor turn, however.
×
×
  • Create New...