Jump to content

allista

Members
 View Profile  See their activity

  • Posts

    2,208

  • Joined

  • Last visited

 Content Type 

Everything posted by allista

  1. allista
    I'm feeling that my explanations in the stream are... well, terrible. So I'll reiterate in text: Indeed, the trajectory lies mostly within the atmosphere, but that's OK, since mostly it's upper atmosphere with negligible drag. What's more important, along such a trajectory the component of thrust that works against gravity is minimal, which allows considerable fuel conservation. Solid boosters cannot be controlled. Cannot be (de)throttled, cannot be shut down. Thus, the only thing that's left to TCA is to try to rotate surface velocity with fins (that don't give that much torque) while staying within 5deg cone from it. This results in mostly vertical ascent until the boosters are separated. When TCA at last receives control over thrust and enough control authority it quickly turns surface velocity where it should be by that time and then simply keeps ApA at some 40-70s before the craft. This also conserves fuel, as often just a fraction of the full thrust is required at that phase, and rocket engines' Isp is usually better in upper atmosphere and in space. Following this route TCA brings the ship to an almost circular sub-orbital trajectory, leaving just a few m/s of dV for circularization. All hail @AndyMt and @Overengineer1 -- the developers of the GravityTurn -- for sharing this strategy with me!
  2. allista
    It seems simpler to just show (and explain along the way) how ToOrbit autopilot works. Join the stream now, or watch the recording later:
  3. allista
    Could you elaborate, please? I'v got no clue what the SSPXR is
  4. allista
    Better share the craft file for me to test. Preferably stock, but not necessary. Normally, what TCA does is alike to what the GravityTurn does; the algorithm is actually based on their idea. It starts vertically until a set of conditions is met, one of which is atmosphere density threshold. Then it turns the surface velocity vector 45deg to the horizon as fast, as aerodynamics allow. And then it maintains some time-distance to current ApA. This results in a very gentle trajectory that conserves a lot of fuel, even if most of it formally lies in atmosphere, because upper atmosphere is negligibly thin.
  5. allista
    For some reason Unity's procedural GUILayout framework started behave weirdly around KSP-1.4; this is one of the many symptoms, including not-working mouse scrolling in scrollable areas and such. I haven't found the solution, except moving to uGUI framework. The process is underway; currently I'm converting TCA's UI, which is also needed as the current one hogs CPU dreadly. GC and Hangar come next. Until then we'll have to bear with it
  6. allista
    That's a good one, thanks. Will fix it.
  7. allista
    They're completely different systems; and while both try to be as universal as possible, the accents in development must have been quite different. For one thing, stock SAS doesn't deal with torque created by thrust variations of individual engines. For that reason SAS doesn't handle well the torque that responds to control input with inertia (like torque from jets). That was the reason for creation of the T-SAS; heavens know I didn't what to do this until I was completely sure that SAS cannot work well with thrust generated torque. I can always install required mods, if need be.
  8. allista
    I see. When TCA tries to align thrust vector it deliberately ignores the gimbal (i.e. the actual thrust vector), using default thrust direction for each engine. This has to be done to prevent oscillations, as gimballing always shifts thrust away from the desired direction. However, the potential torque of gimballed engines is taken into account. What is not, is the finite speed with which gimbal changes thrust direction, and that may indeed cause oscillations on overpowered crafts with huge gimballing. It's a guess, though; I'd like to take a look at the actual .craft file and test things for myself to get the feel of what's happening. What causes the spin I can't say without trying, but what happens next is simple: as soon as attitude error becomes > 10deg TCA shuts down the engines (so as not to mess up the maneuver) and tries to realign. And, as I said before, when engines are off, gimbal is also off. There's no user-space way to control the PID, as it's actually a complex control system with double-PID cascades for each separate axis and parameter scheduling for different torque/MoI/thrust etc. All the parameters are in the .glob file here: https://github.com/allista/ThrottleControlledAvionics/blob/bd9f2e9b664936b264adec1e9ec47be380cf1c46/GameData/ThrottleControlledAvionics/Plugins/PluginData/ThrottleControlledAvionics/ThrottleControlledAvionics.glob#L119 ...looking at the vessel torque calculations I now see some weirdness in logic that accounts for gimbals. Have to explore this thoroughly.
  9. allista
    Replied in CC thread. All compatible with 1.6.1 to 1.7.2. See the .version file inside the archives.
  10. allista
    Hm... That's because both CC and GC netkan definitions use spacedock reported KSP version as compatible; while Hangar and TCA use AVC files. In any case, all four mods are compatible with 1.6.1 though to 1.7.2
  11. allista
    If you're interested: https://github.com/allista/PyKSPutils There are several scripts to automate release management, and two scripts to grep/search part configs for certain things. And this is the patch-maker script that uses it: https://github.com/allista/ConfigurableContainers/blob/master/PatchContainers.py
  12. allista
    I know kung-fu (c) Made a python library to read/write ConfigNodes from KSP and use it to auto-generate patches for all parts from a mod that fit certain criteria
  13. allista
    Version 2.4.1 for Kerbal Space Program 1.7.2 Released on 2019-06-17 Parts with selected resources are assembled and constructed with these resources By default only two such resources are supported: Ablator is made from MaterialKits during the construction phase Machinery is made from SpecializedParts during the assembly phase Other resources may be added by other mods: Add a resource name into a GC_CONSTRUCT_RESOURCES node in any of .cfg files in your mod to make that resource from MaterialKits in GC Add a resource name into a GC_ASSEMBLE_RESOURCES node in any of .cfg files in your mod to make that resource from SpecializedParts in GC Added patches for Mk3 ISRU from Stockalike Mining Extension made by @ZEROX7 For modders: renamed GC_KIT_RESOURCES to GC_KEEP_RESOURCES Download
  14. allista
    Version 3.5.7 for Kerbal Space Program 1.7.2 Released on 2019-06-17 Only show "AutoThrottle" switch if Altitude Control or Vertical Speed Control are available. Reimplemented the HUD windows using uGUI: Vertical Flight Controls T-SAS Controls Maneuver Controls Snap Desired Vertical Speed to 0 when in [-0.1, 0.1] Fixed out-of-range exception in editor while trying to set empty GID Closed #67 Fixed NRE in TCAGui.onVesselDestroy Download
  15. allista
    Version 3.3.7 for Kerbal Space Program 1.7.2 Released on 2019-06-17 Using the common Color Scheme for the hangar content hint color Fixed transfer window behavior when selected payload is switched Added Show button that displays content hint for a short time this is actually a step toward user-controlled orientation of the payload Download
  16. allista
    Version 2.4.6 for Kerbal Space Program 1.7.2 Released on 2019-06-17 Added patches Mining Expansion Kerbal Planetary Base System ReStock+ Streamline - Engines and Tanks Updated patches Bluedog Design Bureau Mk2 Expansion Mk3 Expansion Near Future Propulsion Mk2.5 Spaceplane Parts Squad Corrected a typo in squad xenon tanks' names Download @ZEROX, for other mods you've listed: Restock -- doesn't include any parts Lynx Rover -- uses ModuleKerbetrotterResourceSwitch to dynamically control resources Universal Storage2 -- uses USFuelSwitch to dynamically control resources Stocklike Station Parts Redux -- uses ModuleB9PartSwitch to dynamically control resources
  17. allista
    Looking at the code: there's literally only two cases when gimbal limit is manipulated at all (set to 0 in both cases): when the main throttle is 0; in which case gimballing doesn't do anything when an orbital maneuver is performed and the remaining dV is < 0.5m/s. Which is needed to perform the maneuver precisely. Indeed, this assumes that you have some control authority aside from the engines. But otherwise you wouldn't be able to perform any orbital maneuvering at all. In all other cases gimbal limit is set to 100. So, could you elaborate: what behavior are you seeing exactly?
  18. allista
    Thanks, will take a look as soon as i get home.
  19. allista
    Ah, indeed, @Critter79606 has added new patches for various ISRUs. Here, look at what ISRUs are supported and, if you want more, just make a patch using existing ones as template. https://github.com/allista/GroundConstruction/blob/development/GameData/GroundConstruction/Patches/ISRU_Patch.cfg UDP: and of course post your patches here so that community may benefit
  20. allista
    Nope, only the stock ones.
  21. allista
    There was a try to make such a patch and the result was posted in this thread some time ago. But I didn't adopt it, because 1) to work correctly it needs some math which is not-trivial to implement in a patch, and 2) wild conversion of parts from other mods is not something one would normally do, because it tends to step on other peoples' toes. It's always best to just post here names of mods which you want patches for, and I'll do the rest.
  22. allista
    Working on stand-alone recycling in GC The concept is that a construction workshop (i.e. engineers in it) can disassemble and recycle a whole vessel, a single part from it or a sub-tree of parts, salvaging some Specialized Parts and Material Kits (up to 50% of MK and 30% SP of what would be required to construct it back). The process of recycling of a single part is instantaneous and requires electric charge; usually a huge chunk of it at once. Crewed parts are skipped. Fuel and other resources within a part are transferred beforehand; if there's not enough space for them, the part is also skipped, unless the option to discard excess resources is chosen. The logic is mostly done, and right now I'm working on the UI. So my questions are: first, is the concept of disassembling following the part tree (i.e. which parts were attached to which in editor) seems intuitive enough? second, is this too much color?
  23. allista
    Nevertheless, it's technically easier to make the conversion than a full part, especially if I can't make it match the OPT style. I'm bad at texturing
  24. allista
    Technically there's no problem in realigning during launch however I like. But from the physical point of view, there has to be "space" to realign in. It's not that the packed payloads (may be many in this hangar) live in some isolated spacetime pocket outside of the hanger interior But. All this just adds up to some checks that would allow some orientation and forbid others.
  25. allista
    This seems doable now that I have some experience with the same task in GC. But there are some principle limitations: when a hangar stores a payload, it places it in a box of appropriate dimensions, then packs all the boxes without rotation, trying to utilize space better. Inline hangars, in addition, choose the best (in terms of storage) orientation before that; that's why your drone, @bcqJC, ended up on it's side. So to choose different orientation before launch, there must be enough free space in the hangar to accommodate it first. Combining two hangar parts so they act like one would be too difficult to implement; wouldn't even know where to start actually. What I can do though is to make conversion for OPT cargo bays, turning them into resizable hangars. That'll solve both the aesthetics and the length problems.
×
×
  • Create New...