Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

64 Excellent

About Linkageless

  • Rank
    That rattly bit somewhere down on the left

Profile Information

  • Location
    In a discontinuity nowhere nearby

Recent Profile Visitors

614 profile views
  1. My gut reaction is to ask for it as the Aerodata GUI shows it, negative drag. However, I found that counterintuitive initially so suspect others would, too. Would it be difficult to offer both, or one or the other depending on a tick box? Could there be situations where the drag of hub, spinner and blades would outweigh the blades thrust, hence show as neagive thrust?
  2. Certainly, my machine often is running with >2 load average and plenty of cpu use, so this doesn't surprise me. As ever, looking forward to the fruits of your efforts.
  3. You weren't kidding about props being difficult. Again, it's a wonder they work at all, eh? Hopefully this is not too naive... How about if you calculate potential max thrust/power and allow the user to apply their estimated percentage of that across the board. This is assuming there will be a linear relationship between what is calculated and 'real life'. Oversimplification, I know, but if by testing they find practical thrust they achieve is only 50% of what is calculated, they can feed that back in. Perhaps the scale would need to go up to 200% if you think the opposite could be t
  4. Mostly in use for helis, I think Brikoleur has demonstrated this at various points. A motor is mounted without being motorised, blades attached, then another motorised motor attached on top, with blades attached. The motorised motor on top is powered up, and the torque is split across the two rotors, in contra-rotating directions. Myself, no. I've only build hybrid vessels, usually that tuck their blades away by closing bay doors to dodge the drag when the rocket engines are engaged. I know Stratzenblitz75 and Bradley Whistance have exhibited some amazing stock prop designs that mi
  5. Ah, of course! No need to iterate like we have to do when controlling it. Manual control won't get you exactly what's predicted, but be something to aim for at least. As you no doubt know, a common kerbal way of torque cancellation is to use contra-rotating blades, the first rotor just freewheeling in reaction to the second. (Engineering it that way in real life must be an extra challenge, much like variable pitch props or heli rotor swashplates.) Would this the best thrust or power need to be applied to the whole nested approach would be needed to cater for such a setup? Perhap
  6. Yes, typically I bind pitch to the up/down translation keys and regularly adjust while watching the aero gui so I can maximise the -ve drag while they're in use. I have built some in-atmosphere fixed props, or at least preset to a pitch that gives me sufficient takeoff thrust while still allowing a reasonable top speed and service ceiling, but any vessel of mine that leaves Kerbin with a BG prop I'll be wanting to tweak the pitch on the fly. All I've achieved in this respect is through iteration, and you're absolutely right, it can be hard work! All I can suggest is that you either have
  7. I vote for BG Propeller support, then re-entry. That's simply because I don't currently use FAR.
  8. Completely stable so far on Linux 1.10.1 on my somewhat overworked laptop Good work Booots!
  9. I'll glady test on Linux 1.10.1 with MH & BG for you, just say where from and I'll be on it.
  10. Excellent news! Your efforts and the update on them is much appreciated. Seems very reasonable to me. I can appreciate how props could be a challenge and a working wind tunnel without will be way better than none. Until you've got it cracked, I suggest a visual cue to indicate what parts it's ignoring or treating as static, eg red and white stripes overlaid, or a thick outline, whatever might be easy. Even a text note to point out part types it's found and ignored. (Only if that's not a massive project in itself, of course!)
  11. Excellent to have this in stock, I love it! Ooh! So potentially, the lightest crewed craft just got lighter!
  12. Another interesting tidbit I hadn't appreciated - I don't know if this has changed from previously as I'd never tried - when a backward facing part is selected as root, the green & yellow plots get mirrored to the side I'd expect. Perhaps this is just this craft, the backward part in this case is a long mk2-mk1 adapter tank.
  13. I, too, am wondering why I can't make sense of the graphs. I haven't compared with 1.9.x or earlier, but am wondering if the Torque vs AoA are reversed somehow. Is the right hand side positive AoA, left side negative AoA? I think it's a fair assumption that up is upward torque. What I see is the green and yellow lines start from the top left and slope down to the bottom right on what seems like a generally well balanced craft. To me, it appears the upward torque is on negative AoA, going to downward torque on positive Aoa, which is the opposite of reality. I suppose you could a
  14. I'll second these two button feature requests. I'd also request that an 'immediate update' tick box be added, disabling the 'apply angle changes' button. I'm not sure they'll solve the mirror symmetry issue we've described, but would at very least make working around it easier.
  15. It does seem like it's down to floating point errors. Seeing them right in front of you makes them all the more frustrating! I suppose the thrust of my question is, what do people do to mitigate this? Build in tolerance? (eg moar dihedral, lots of roll authority) Find a way to balance out the errors so they mostly average out? (Not so easy on a small, fast aeroplane). Do people just cope with it in flight? (eg trim, or constant/repeated control input). Come to think of it, this may be why I've generally shied away from very small spaceplanes. It seems easier to build a mid or l
  • Create New...