Jump to content

m4v

Members
  • Posts

    884
  • Joined

  • Last visited

Everything posted by m4v

  1. I did rather see development effort go into improving the current solar system than add another system that is going to be basically "more of the same" with a slight different flavour. I feel that people wanting a new system to explore are just reacting to the lack of variety our current system has. But if they do add a new star system, please no FTL or other magical engine, just because now a warp drive doesn't need to eat Jupiter in the process doesn't make it feasible. A wormhole seems like a good compromise though.
  2. The warp kill is probably a feature so you don't accidentally lose your crew because you didn't cancel warp fast enough. Dunno about the orbit change.
  3. Pretty much everything is a subclass of MonoBehaviour, Part and PartModule subclass it, so I don't get what is this "Modders don't usually deal with UNITY if we don't have to" you speak of. Modders might not know they are dealing with Unity, but they are.
  4. Thanks everyone for the comments, I uploaded a new version, which fixes several issues the initial release had. Now it shouldn't calculate stuff with detached parts, forces are shown correctly in B9 parts (some B9 parts might be still near impossible to balance due to the odd placement of RCS) The change I have to point is that it doesn't use the spacebar anymore, but the "hnjilk" keys (see OP). Now there's no key conflict with the game but I'm still not happy with this so I'll probably have to change it again in the future. My bad, uploaded to spaceport this time around, check OP.
  5. If by KSP's API you mean the .cfg files only. The scripting API is almost the same as Unity's so we can't say it can stay the same after an engine switch, most likely it can't. And I don't see why KSP's API has to provide mechanisms that are already available with Unity.
  6. Changing the engine would be a pain, all KSP mods out there would need to be rewritten from scratch.
  7. Is not nonsense, the air on top of the wing does go faster. What is nonsense is the equal transit time theory taught in schools for explain why it goes faster.
  8. hey, I did a quick look and I do believe there's something wrong going on with my plugin. But I need to investigate further for understand what is exactly.
  9. Disable the CoM marker and enable it again. Thanks. This is a bug , I'll look into it. ok, though I'm not sure if I should support other mod's quirks regarding RCS I created an issue just so I don't forget about it and at least look into what is going on.
  10. Just in case I'm going to point that the thing that is getting zeroed is the torque force, the shrinking CoM is a gimmick I came with since otherwise the arrow will sink inside the sphere and you couldn't know if is getting smaller or bigger. I'm not sure if it is what you want but you can do something similar if you do the process backwards (ie, place the RCS thrusters first and build the vessel last) I mean, you put your orange tank or whichever as first part, place the RCS thrusters, check there's no torque force, and then build the rest of the vessel. As you add parts the CoM will move and a torque force will start showing, this time around instead of repositioning the RCS thrusters you will have to move parts around for keep things balanced. But I think that trying to keep things balanced will only work for a vessel with one tank only, since fuel is always consumed one tank at a time unless you start transferring fuel around things will get unbalanced. With mono-propellant since it's consumed in all tanks equally you can solve the unbalancing by placing tanks in pairs and in symmetry, not so with liquid fuel. You can't make the torque force disappear, you can't make it zero exactly. If you can't see the CoM then the torque magnitude is really low, like below 0.09. Anyway trying to get almost exact to zero is worthless because your ship will get outside of that value the moment you burn some fuel.
  11. This is something I made for placing RCS thrusters in the right positions in the first try without having to go back and forth between the VAB and the hacked gravity launchpad. Features: Display thrust and torque forces caused by RCS or engines. ΔV readout for monopropellant RCS. Dry center of mass marker (DCoM). "Average" center of mass marker (ACoM). Center of drag marker (CoD) for assisting in parachute placement. Ability to resize editor's overlay markers. Display total mass of resources. Supports: blizzy78's toolbar KSP Add-on Version Checker Once enabled you should see RCS Build Aid's window, select the translation mode or press any of the translation flight control keys ("hnijkl" keys) and then you should see something like this: Cyan arrows represents thruster forces, the green arrow represents the translation motion (or thrust). The red arrow represents the torque force in your vessel, if you have a red arrow then your ship will rotate when trying to translate in docking mode. So all you have to do is place your RCS thrusters in a way that eliminates this force. The red circular arrow is an indication of how fast the vessel will rotate. The red CoM marker is the dry center of mass (DCoM) which represents the center of mass of your vessel when it doesn't have any fuel (in the picture, without liquid fuel, oxidizer or mono-propellant, but is configurable). Video explaining how to use RCSBA (version 0.5) by Geneborg This plugin only works with parts using stock modules such as ModuleRCS and ModuleEngines, mods that use custom modules will not be detected. Known issues: delta v readout will only show for monopropellant RCS, doesn't work for the new Vernor RCS. Parachute mode only works with stock aerodynamics and parachutes, will not work with mods such as FerramAerospaceResearch and RealChute. Download GitHub repository - Documentation - Changelog Licensed under LGPLv3. This program is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.
  12. is probably your typical texture artifact when you apply a flat texture to a spherical object.
  13. "We placed the oxygen tanks outside the ship because inside is already too cramped with our big heads and everything."
  14. The red valves are somewhat silly, do you have to go out in space and open them for get some oxygen?
  15. If you take the ElectricCharge unit literally and we believe that the devs didn't call it "electric charge" just because then it should be measured in Coulombs, that translates nicely all the sources and sinks of electricity into Amperes (1A is 1C/s, ie, the small solar panel gives 0.75A or 750mA, the spotlights consume 40mA, etc) but then the batteries ratings get awfully low like Z-400 getting 0.111Ah or 111mAh, which is like 10 times worse than a typical AA alkaline battery. Also "electric charge per sec" isn't energy, you can't compare it with joules, for talk about energy we need to know the potential or voltage involved. I suppose that electricity in KSP is so disconnected from reality that we can't say what it is
×
×
  • Create New...