Jump to content

OHara

Members
  • Posts

    1,115
  • Joined

  • Last visited

Everything posted by OHara

  1. It flies nicely hands-off, but the ailerons roll controls are reversed so SAS fails to control roll. The automatic assignment of controls sometimes gets confused, and in this case I don't see an easy way to un-confuse it. This plane flies nicely, though, if you have each control respond to just one of pitch/yaw/roll, and reverse the control-authority on roll to compensate for the error.
  2. Waypoints do seem a little more convenient for the KSP runway: + you avoid the 175m/s offset in indicated airspeed, that appears 60km away when the navball switches to target mode + you can put them right on the runway, whereas flags or rovers need to be 30m or so away so they don't count as vessels on the runway - but you need to have a probe core on the rover to set the waypoint Directly targeting the base stil seems more convenient to land at bases on other bodies: + you get anti-target and retrograde markers, so you can aim a lander with its control-part oriented so the nav-ball points to the sky as usual + you get AN/DN markers that can help align your orbit to the base - you just have to remember to set the nav-ball back to surface mode, when it switches to target mode 60km from the target Interestingly, if we go within physics-loading distance to a landed target, which corrects the indicated velocity to the target, and then move away beyond the unloading distance, the velocity remains correct... until the next quicksave/quickload. I couldn't make good use of this quirk, though. A module-manager patch to increase the physics-loading distance:
  3. In Category III, I noticed that @NightshineRecorralis had room for a third ore tank in his cargo bay, so I copied his plane from his pictures, and flew it with 10.5 tonnes payload / ( 34460 cost - 33341 recovery) = 107 funds/tonne Maybe I used a bit more wing incidence, and followed prograde all the way up, rolling inverted to slow the climb for the speed-run. Somebody should break 100/t soon.
  4. There is an old bug, beautifully described on the tracker, about how the rotation of the planet is sometimes wrongly left out of the velocity of a landed target, for purposes of the nav-ball indicators when in 'target' mode. There is a very nice video https://youtu.be/VU-_InTkc54?t=681 warning new players about this, for aircraft landing. It also affects targeting bases on other bodies, whenever the body has noticeable rotational velocity. I get tired of manually switching the nav-ball back to 'surface' mode, and often think there must be a better way to avoid the bug. Does anyone know a better way? I can increase the physics loading distance for 'landed' objects, because the bug is avoided when the target is physics-loaded, but would not recommend that in general. Better would be a way to prevent automatic switching of the nav-ball to 'target' mode, or at least delay the switch until we are in physics range.
  5. Clarifying a little, the save-files store the relative positions of all the parts, in absence of any forces. Quick-saving in a 3-G turn, or zero-G nose-over, results in the same part-positions in the save-file. So if I save with my wings flexed, upon reload they are at first straight and have to flex again. So Delay's DC-10 (a nice craft) was quick-loaded with no flex at the wing-roots buy flying 240m/s; the body started to fall, while lift started flexing the wings up, and the peak stress broke off the wings. Setting unbreakable-joints and then re-re-loading is a great solution, because we can apply if after we discover we have a problem.
  6. There is a discontinuity in the forces on a craft when it quick-loads. The forces do not seem to be saved in the sfs-files, just velocities. I would speculate that the physics engine throws the craft at that speed through the air and then figures out what the forces are and how much the joints flex. I would speculate that any particularly stiff joint could be overstressed at this point more likely than when the forces and flexing have had time to settle down. I notice the problem rarely, mostly when I try other people's aircraft, probably because I'm not familiar with their stress limits. Make a named save with alt-F5 as a backup, sometime when the aerodynamic forces are relatively low, so you won't be scared to quicksave.
  7. The third (more fun, IMO) way to stay stable on the takeoff roll, is to trim up. Take weight off the nose-wheel, or in general off the front wheels, by pulling a bit up, trimming up with alt-S, or deploying flaps/canards to pull the nose up a just bit. Nose-wheel, or tricycle, aircraft do tend to wheelbarrow once they build up speed if you don't trim up enough, which I expect based on where the wheels have to be. The weight of the craft is distributed on the gear so that the sum of their forces against the ground is directed straight through the CoM. A first approximation of rolling friction would give each wheel rolling drag proportional to is force against the ground, so there you have a drag force acting at ground level just below the CoM. In absence of aerodynamic forces, this would pull the nose down, putting a bit more weight on the front gear, making their contribution to drag a little higher, until eventually the net drag force acts from a center ahead of the center of mass, making the craft unstable in yaw. @Spricigo, probably you know (but just being sure) about trim, and alt-X to re-center the trimmed position of the controls.
  8. The specifics of your suggestion are a slightly unclear among the mentions its desired effect. It seems like a good idea to have SAS do its job by adjusting the same trim setting that we adjust with alt-WASDQE. Then our WASDQE-or-joystick inputs move the controls from the SAS starting points, just as they move from the trimmed point today. Then as I understand you, releasing SAS would leave trim, and the control positions, in whatever off-centered position was last used by SAS. The second paragraph of an old suggestion is very similar. Probably SAS should leave the trim fixed while user-inputs are active, so that SAS does not fight the pilot. The current system, where user input causes SAS to restart from zero control-inputs, is very awkward, but probably the improved system should keep an option to revert to current behavior.
  9. I tried version 17.5 using an existing game last saved using ScanSat 16.11, and agree that 17.5 looks very nice. [Bug]: In the Settings window, every time I enter the Background Scanning tab, all celestial bodies are shown as selected, even though I had deselected some. Toggling background scanning for individual celestial bodies still functions correctly, and is saved in the .sfs savefile; only the UI indications are wrong. Looking at the SCANcontroller section in the save-file, it occurs to me that maybe you could integrate ScanSat into the new Commnet feature by storing mapping progress individually for each scanner, merging that map into the celestial body map if there is some Commnet connection to Kerbin when we use the "transmit data" action on the scanning device -- the mechanism Orbital Survey Plus seems to use. That would seem logically consistent with the Commnet model of communication, but not many people would opt for extra clicking. Alternatively, maybe each refresh of a ScanSat map window could merge maps from all Commnet-connected active scanners in the SoI of the body shown in that map window. After thinking about this, though, I like ScanSat just as it is.
  10. There is feedback on the bug tracker with this same title, marked 'needs clarification'. The ablation rate uses an activation-energy model but with a strangely low activation energy, so that the rate depends rather weakly on temperature. Ablator goes away during mining or being near the sun, but often remains when the heat shield reaches its structural failure temperature of 3300K on reentry. The heat being carried away by ablation is not much more than that being radiated away. Ablator seems to have a narrow range of usefulness. Using what seems to be a standard use-case of a Mk1-2 pod on a 2.5-m heatshield entering Eve's atmosphere at 5600m/s, I found with no ablator, I need a periapsis 59km (3 Gs) or lower to aerocapture; a periapsis of 48km (10 Gs) reaches the 3300K limit of the shield and explodes. with 800kg ablator, I need a periapsis of 58km to aerocapture; a periapsis of 45km reaches the temperature limit of the shield and explodes when 540kg of ablator remain I suggested a module-manager patch that increases the temperature dependence of the ablator. Now the MK1-2 pod can survive any periapsis, although the G-loading can be extreme, because there is enough ablator to carry away the orbital energy. If I add 10 tonnes of ore below the pod, for a total of 14 tonnes behind the heat shield, then I do use up all the ablator. In this case, with no ablator, a 56km periapsis barely aerocaptures with heatshield-temperature right at its limit stock ablator lets me lower the periapsis to 50km, but at 49km (7 Gs) it explodes with 500kg left modified ablator lets me lower the periapsis to essentially the same level, but all the modified ablator is used up before I explode. I like the modified ablator because it behaves more predictably, without my wondering when I might get 'a spot of burn through'. If you all agree, change the status on the bug tracker, or suggest different test cases for ablative heat shields.
  11. 1) Make the rate of pyrolysis of ablator depend more strongly on temperature. Then it will not evaporate during normal operation, but will carry away significant heat on reentry. 2) Reduce the default amount of ablator on a heat shield, as it is not necessary for entry from Kerbin orbit (so its extra mass does less harm for new players).
  12. The advantages of familiarity or simplicity, of one system of units over another, is minor compared to the frustration of converting. Where I work in the US, we manufacture products in metric dimensions so we can ship and service and repair worldwide, but use tools built largely to US/Imperial dimensions limited by what is available. We need many tools in more sizes to cover the two systems, but we cope. Change comes slowly, when new parts come that no longer need compatibility -- like the spacing of contacts on integrated circuits, once 0.1-inch and now 0.65mm or 0.5mm. It seems to me wisest to embrace the system commonly in use, in whatever field I work in. Commercial aviation universally communicates altitudes in feet, 30 quarts of water fills a cubic-foot container where I live, but space and science in general use metric. A mod like Speed-Unit Changer is nice for a game, but learning a new measurement system that is commonly-used in a new field, is probably better practice for real life. If you come to the US, though, be prepared to ask for 20-ounces so you are not disappointed with our 16-ounce pints. (Also the US ounces are slightly different to UK, but close enough that I don't know which is bigger)
  13. None, because for each feature I don't like, the game lets me ignore it (strategies) replace it with my own rules via cheat menus (science points, etc.) or replace it with a mod (Kerbnet->ScanSat) The only annoying feature that leave, for me, is the the loading screens.
  14. When I try the craft you linked in KSP version 1.2.2 it is very nearly neutral in roll, returning to wings level with about a 100-second time-constant. In version 1.1.3 a few short months ago this stability seemed impossible. The code cleanup leading to version 1.2.0 seemed to help many such details in KSP. Even when I auto-strut to heaviest, it rolls only 0.5°/s (roughly). Auto-strut asymmetry was also much worse in version 1.1.3. Auto-struts are still relatively new, and were added to solve different problems, such as keeping rovers in still cargo bays. Given the way you approached this aircraft, I think you will get more out of KSP if you leave auto-strutting turned off. The aero-GUI rate readouts behave as if they were rotation rates, in °/s, with the axes of rotation being aircraft-Relative and Absolute (I'm just guessing words that match the 'A' and 'R' labels and which match the behavior). Next to heading for example, you see yaw rate relative to the aircraft yaw axis, and then heading-change-rate relative to Kerbin. Pull your airplane into a 90° bank and pull the stick back hard, and you'll see what I mean.
  15. Mode 4 seems to be a mistake. I have never noticed it as the default. I once found mode 4 referred to as 'LERP mode' and it does seem to add a linear interpolation from the point we enter a body's SOI at some point in the future, to the current position of that body. I do not know why that could be useful. I think it was an easy-to-program idea that the programmer never bothered to remove. link to a nice description of the modes
  16. @Foxster there is a parameter ablationTempThresh=500 in the part-configuration file for each heat-shield, so you might try changing that entry, or if you have ModuleManager installed putting something like this in a *.cfg. @PART[*]:HAS[@MODULE[ModuleAblator]] { @MODULE[ModuleAblator] { %ablationTempThresh = 1200 } } I'm trying this myself, as well. [Edit: Increasing ablationTempThresh to 1200K worked well for me. I checked for unwanted side-effects using a quick-saved Eve re-entry and found no change (<0.5%) in ablation rate or temperature. The threshold changes behaviour only below the threshold temperature according to this thread, which would explain why I saw no side-effects. The equation for ablation rate is just the Arrhenius, rate = constant×exp[-E/T], which is physically reasonable for something like evaporation, so I wondered why the threshold was even necessary to prevent noticeable evaporation at 500K. The constant E=7500K=62kJ/mol is about 3 times too low to be a reasonable vaporization energy, assuming KSPs temperature unit should correspond to a real-world Kelvin. E should be 3× larger and the prefactor constant larger so that the evaporation rate changes more steeply with temperature.] I hear the word 'ablation' mostly to mean sandblasting with molecules. People use ablation to describe cleaning things in a vacuum chamber by bombardment, for example, whereas simply heating a part to clean off any residue has different words, like burning-off, evaporation, or sublimation. I don't expect KSP to simulate on a molecular level, of course, and hope that having the 'ablator' start to evaporate away when the shield itself reaches 1200K or so might be a satisfactory simulation.
  17. The effect of wing dihedral in stock aerodynamics (where all parts see aero forces from the undisturbed airflow) works pretty well, probably because the wing parts with functional dihedral tend to be in undisturbed airflow anyway. The first serious aircraft I built in KSP, trying to make something that would handle well based on my experience as an engineer and a pilot (but not knowing the KSP aero model) slowly levels from a roll. You can also make a plane that over-corrects roll, doing the wallowing 'Dutch roll' motion. That first aircraft had long wings because it wasn't meant to go fast, so it was mildly disappointing when I found that long wings don't help low-speed lift-to-drag ratio at all in KSP. I can't imagine a way, though, to simulate the effects of one part of the airframe on the airflow around another part, like shock-wave cones, simpler than figuring the airflow in a mesh of voxels in 3D space like Ferram's FAR mod does. Is there an alternative to FAR that does less computation but handles wing-shape effects more satisfactorily ?
  18. To push an asteroid, keep the pushing rockets short, or disable gimbal. In the picture below, the poodle engines on the orange tanks have gimbal disabled, otherwise they would turn the orange tanks alone by flexing the klaw, resulting in gimbal opposite the desired direction relative to the asteroid. The gimbal on the small pushers works as desired, and is sufficient for steering. It might have been obvious from the linked photos, but to be explicit: The game allows transfers of fuel, kerbals, electriity, etc., between any parts of an assembly attached by klaws and docking ports; you might say it abstracts away the details of hooking up fuel lines and EVA tethers after the docking or klawing is complete. This encourages base building with parts separately klawed to the rock. Going in and out of time-warp, the game's physics simulation still has some discontinuity in objects momenta, sometimes causing klawed parts to crash into the asteroid. Keeping bulky structures far from the rock, where possible, reduces this problem.
  19. In case you decide to try your original plan -- aligning docking ports on the ground -- I have had success on Mun and Minmus building a base with small sections, each section having both rover wheels and landing legs. The landing legs are set to lift the section somewhat higher than it sits on the wheels. Given a base with its legs extended, a new section with its own probe core and solar power to drives up to align docking ports with the base in every direction except height. Upon extending its legs the new section is likely to dock to the base the new section rises. If the new section doesn't rise high enough, I briefly retract the legs on the base. This does require a flat patch of ground, but the flat patch can have some slope, so long as the rovers are capable of driving around on that slope, maybe up to 15°. When I put this into practice ( image image image ) I used struts instead of legs for some parts, and sometimes moved un-powered sections with a rover, but given hindsight I would prefer to have done exactly what I wrote above.
  20. We should acknowledge that the original post did report an experimental result that agrees with others' results, but not the outdated KSP wiki. I created myself a wiki login and updated the two linked entries, based on the information in 'PartDatabase.cfg'. It seems that the individual part .cfg files still contain the old drag coefficients formerly reported in the wiki, presumably for backward compatibility using the option 'replace drag cubes with spherical model' in the alt-F12 menus.
  21. Games like this are fun because they are just challenging enough to be interesting. A plane with just enough wing-area and thrust to support its weight at 3° incidence at 500m/s, does need some extra design feature to take off and land in 2.5km (plus the descending glide over they bay). It could be an engine with good low-speed thrust, or flaps (to the small extent they help in stock aero with non-interacting wing parts) or gear positioned to give the wing 15° AoA, or rocket-assist, or just larger wings chosen as a compromise to best serve the whole flight envelope, and then maybe arresting chutes for landing. These challenges appeared just about when I was ready to deal with them, so 2.5km might be just about right. Some other area to use for specialized aircraft might be nice. Specialized aircraft use dry lake-beds. In KSP we have the ice caps at the poles, if we somehow teleport there. A dry fossilized tidal flat south of KSC might be nice.
  22. There is a new bug that matches this symptom, and a text-file edit to workaround the issue described the bug-tracker. The workaround seems to have no side-effects, and I was glad I applied it to my install.
  23. Real Solar System makes Venus rotate retrograde by giving it a negative 'rotationPeriod'. The 'north' pole is in the same direction as the other planets' north poles, due to the fixed orientation of the poles in KSP, making the sun rise in the west in RSS Venus -- same as for the real Venus using the convention NASA chose to orient Venus's 'North' generally along ours. It looks like each of RSS and Kopernicus have code in their .dll s to read such values from configuration files, so at least that amount of code seems necessary to un-align Kerbin's orbit- and rotation- axes.
  24. I do. Axial tilt of Kerbin's rotation axis relative to its orbit (the nit-picky definition) is the interesting part of the tilt. It gives seasons, and makes launches to other planets a bit more interesting. It was still worth implementing in the 'Real Solar System' mod by tilting the orbit, rather than the rotation axis. I have been tempted to try re-configuring the orbits following the very good suggestion from guigui30000 linked above (following a couple levels of links) and wonder if can be done through edits or Module Manager following RealSolarSystem.cfg as a guide.
  25. When the 1.25-m ISRU was new there was some discussion about its role here. It was easy for me to guess that the smaller ISRU would produce less output, and the thread linked by Magzimum above explains how it would be less efficient in terms of output per electricity consumed and per heat generated, compared to the larger version with its efficiency of scale. The lower efficiency in terms of output per input ore, however, is harder to understand and remember, and is frustrating for people designing their first asteroid-mover where ore-mass is limited. The current design encourages the use of the 1.25-m ISRU with a field of drills manned by an engineer. The balance works better for me if I use the same mass-ratio between input and output as the large drills, and maybe reduce the efficiency of fuel-per-electricity even further. Then the small ISRU works on a hopper, limited by the solar energy collected between hops.
×
×
  • Create New...