Gordon Fecyk

Members
  • Content count

    187
  • Joined

  • Last visited

Community Reputation

115 Excellent

1 Follower

About Gordon Fecyk

Contact Methods

  • Website URL http://www.antiwindowscatalog.com/
  • Skype gordonf@pan-am.ca or live:gordonf_3

Profile Information

  • Location Manitoba, Canada
  • Interests I do IT for a living, especially desktop support, so I'm most interested in making popular applications safer to use and games safer to play.

    Since discovering KSP I've done some novice film making. Look for the "Agencia Espacial Kanada" channel on YouTube.
    --
  1. @nestor May I ask how difficult it is for a third party to create a language pack or modify an existing one? Could I do such a thing as an add-on? Any possible copyright or legal problems outside of typical modding ones? (I haven't tried a pre-release yet, so I haven't poked in there for myself.)
  2. Beauty! When I started the AEK story, I thought long and hard about add-ons and feedback from potential subscribers. Figured I'd get the best experience from flying 'properly,' even if the technology was not entirely realistic. It seemed especially strange to need to 'flair out' before landing a plane in stock KSP in order to reduce speed. Glad to see you've quantified what I could only understand empirically, regarding upper atmosphere drag. I still can't bring enough fuel up to low orbit to make Minmus with a single Panther, but now you've shown me why. Back to making Mk1 cockpits work in space planes: Something else I've learned is, if you're going to 'unrealistically' transfer resources to balance-out a craft, one can hold a re-entry angle easier by watching the pitch input while SAS is on, then moving resources forward or back until pitch input is near zero. The balance needed will change depending on where your craft is on its descent path. This way you save battery power for your reaction wheels on descent while protecting that cockpit from overheating. Some folks will mark the craft's centre of lift with some radial-mounted instrument like a thermometer, then match that to the centre of the screen as the camera focuses on the craft's centre of mass. I haven't mastered where CoM is on my screen though; if there's an add-on to mark the centre of the camera maybe get that.
  3. Yes the Mk1 cockpit is really prone to exploding on re-entry. The Mk2 cockpit isn't much better; I forget how many ships I lost (and saves reloaded) because of the things. It isn't impossible though. AeroGav might not approve of me re-entering 'full cobra' but it does seem to avoid the worst of the overheating: That was with a stock Aeris 4A, but modified for this scenario. You just have to be gentle at first. Then there's the 'antenna aerospike' trick: In this latter example the antenna is extended. In KSP 1.2 this will break the antenna if extended, but will hold if retracted. The radial mounted version, clipped into the nose, also works and gives the benefit of a radio link that can transmit science at all times.
  4. This brings up a question for me: Regional variances on language. For instance, Quebecois versus native French. Microsoft Windows has variances on localization such as en-us and en-uk for differences in English. How hard would it be to take an existing localization, for instance en-us, and make an en-uk variant? Or fr and fr-qc when the time comes? And maybe there's a need for es and es-mx in this case. I'd like to try my hand at making an add-on for en-uk or en-ca.
  5. If it helps, I was able to reduce the mass of the LTS Kestrel FC's wings and control surfaces by 50% for the Kerbin 2 challenge. They flexed a bit, but didn't break. Of course I didn't have three tonne LV-Ns attached to those wings. Could you strut whatever the LV-Ns are attached to against the fuselage? Strut connectors can't add that much drag. I usually fly with DPCR enabled too. This scales the input authority against the strength of the air frame. And one nice thing about FAR: You don't have to resort to nose cone tricks to work around the stock drag model. That is one gorgeous looking craft too.
  6. I use drogue 'chutes to assist with landing. This is also what the STS used. I usually end up with bullets approaching the runway, well above 120 m/s on approach. For instance, this recent Rick Kerman Report demonstrates an approach exceeding 200 m/s and still landing safely. Skip ahead to 8:30 for the approach: A couple of episodes back I showed how to adapt this space plane from stock to FAR, mostly adding tail planes. Or what about air brakes? Do you have any kind of mechanism to quickly increase drag when you're just above the runway? An early LTS Sparrow FAR craft used one pair of elevons extended down and the other pair extended up / inverted. At first the air ripped them off the wings, so I reduced the extension amount until it was just enough. It wasn't as effective as the drogues, but it got the job done. And since KSP doesn't check for colliders for parts on the same craft, you might even be able to have overlapping elevons and then have them extend in opposite directions when braking.
  7. Actually it seems some other part on the lifter is the root part other than the probe core you put on it. I checked all control points (the two probes and the cockpit) before takeoff, and all had correct orientations. After separating the lifter from the Kondor and switching to the lifter, try changing the control point to the probe core ("Control from here"). After doing that I found controls worked as expected. [Later] I managed to fly the thing to orbit. I cheated a bit and enabled fuel crossfeed through the structural hardpoint; it seemed like a waste to use fuel in the 'wings' until really necessary. Doing that plus a long ascent that took 20 minutes, I got the thing to a 106 km orbit with 1277 liquid fuel remaining. Does 2500 m/s dV sound about right for that much fuel?
  8. Pretty much. Check out this recent Rick Kerman Report; skip ahead to the 8:40 mark for the approach. Not my best approach; a metre to the left and I'd have been hosed. Cut to Peter Mansbridge at The National: "A tragedy today at the Kerbal Space Centre..."
  9. That's what drogue 'chutes are for. Every one of my successful space plane landings required a drogue or two. Even the Shuttle had to use one drogue to slow down on landing, and that had to descend after travelling 8 km/s in low Earth orbit. Curiously, the thing touched down at 100 m/s. assuming my math is right in converting from 226 mph.
  10. I ended up flying this using a similar profile to your D45-N: Extend canards before launch, and take off with SAS hold until... what was it... 8000 m? I forget. Then retract canards. With the AeroGUI up I waited until angle of attack was approaching zero, then hit SAS prograde. The craft started descending around 10 km, then started ascending on its own. Staged LV-Ns when the Panther's thrust was around 80 kN; I think this was about 13 km up and exceeding Mach 2. Re-extended canards as I was approaching about 22 km apoapsis. Lift picked right back up and I think I just scraped AP before increasing time to AP again. When I hit near 99 km AP (Wasn't paying attention!) I retracted the canards and coasted to AP. Before I closed orbit I was at 95 km AP and 1.5 km PE. Closing orbit took less than 100 m/s. Ended up reaching 95 km orbit with 800 units liquid fuel left, giving me 2200 m/s and change. Even stuffed the service bay with a Z-200 battery and some reusable science kit. I want to see if I can adapt it for Ferram Aerospace. While there'd be less drag, I think you have the drag problem covered with your strategic use of nose cones. Usually I have to add or enlarge tail planes to maintain control on liftoff, and add drogue chutes to land safely. In Stock aero though? I guess it's just a matter of figuring out the best time to extend and retract the canards, and not touching the stick. With this much dV to spare, as long as you're around 10 degrees pitch before igniting the LV-Ns you can get to orbit and back. Then it's an exercise in efficiency.
  11. @AeroGav Next time you fly that Kondor you need to have this music!
  12. With this Roadmap conversation, I wondered why Squad would publish a development plan for others to see. For modders, perhaps, so they can plan updates? Not likely; even highly popular mod-supporting games like XCOM 2 and Fallout don't have public roadmaps. The only thing I got from a cursory search was some predatory company selling garbage documents; nothing from Bethesda or Firaxis. Roadmaps come up for large business applications, like Office 365. But for a game? Folks are taking KSP way too seriously. It's being ruined FOREVER! supposedly. And if you get trapped in TV Tropes going to that link, that's OK. Take a break from the KSP community for a little while.
  13. Is there anything common that might pin down the cause of this slowdown? What can I do to help? My system uses an Intel i7-4771k processor with 32 GB RAM, and NVidia GTX 760 graphics card with 2 GB RAM of its own; it's MSI's Mini-ITX version of the card. And while I do play with a few other visual add-ons, I get a big performance drop using the shuriken particles vs the original ones even without those.
  14. If this helps any, I found copying the RealPlume-Stock and RealPlume / 000_Generic_Plumes contents from my KSP 1.1.3 installation on top of my 1.2.2 installation seems to replace the MODEL_MULTI_SHURIKEN_PERSIST settings with the MODEL_MULTI_PARTICLE_PERSIST settings, and not break anything else. I also get a significant frame rate boost, going up from 24 FPS (hitting physics delta limit) to 40 FPS just with four Panthers (and 80+ other parts) on the runway. This is on top of Scatterer and ParaSci Visual Enhancements running and eating GPU time. I can wring out a few more frames by adjusting the stock aero effects setting. That seems to work as a short-term fix, until improvements are made to the shuriken particle system or the stock configs.
  15. OK folks, having looked at so many atrocious applications over my IT career, it's easier for me to appreciate the kind of effort needed to retrofit an ANSI-only application for localization / language / Unicode / whatnot. This is why developers are supposed to code for localization from the beginning. 放他们一马 for at least considering a huge undertaking with little promise of reward. and I hope this web translator got it right...