madlemur

....mumble mumble.... ....Neural Nets.... ....Flocking Probes.... ....mumble mumble.... ....K-9.... ....Resource management.... ....mumble mumble....

Which flavor? Tantruming toddler, or pouty toddler? And when do they get to "sullen teenager" stage?

Hmmm... kOS + RemoteTech = Compile In the Archive, upload the compiled code. Minimize time/elec for comms. Also, new CPUs that can compile, for stations/bases where there's more resources to code and compile the programs before giving the object code to the flight computers (assume Flight Center already has enough CPU power to compile Kerbin-side). Luverly! Only allow in-game edits when there's a comms connection to a compiler unit, or from a vessel with a compiler unit configured. Limit out-of-game edits to Kerbin Archive only? Hrmm... That might require more archive-level storage, for the compiler CPUs, perhaps a drive array of some sort? Unlimited on Kerbin, but you have to build your infrastructure off-world. Long term goals...

It appears my reply may have been eaten... Q is the pressure on the hull. It is based on the air density and surface velocity. If you watch the FAR GUI, it triggers the "High Dyn Pressure" warning when q > 40000. If I can find or compute some of the other data points in Stock, I'll also surface the various coefficients that FAR provides. I don't want to limit any data to only FAR users.

FWIW, I'm going to be working on integrating FAR with kOS, so that maybe we can get some aero-data that's useful. That may mean exposing more aero-data in general (useful bits like Q, AoA, etc., etc.) if they are not already exposed, and if they are readily accessible or reasonably calculated from the KSP API. Then you could program something in to make your throttle and pitch adjustments with bounds at certain values of Q and/or AoA. erendrake said he spoke with ferram, and trying to reach terminal velocity in FAR would be counter-productive to maintaining even short-term vessel coherence, although I would certainly expose FAR's terminal velocity values. I'm still digging through both the kOS code and the FARAPI code to see what will need to be done. Not to mention trying to learn about aerodynamics, orbital mechanics, and C#...

Given my (dis)ability when it comes to 3-D modelling and/or texturing, I'll just leave Unity alone for now. erendrake's helped me get things compiling on my system, so now I just need to figure out how to test for FAR, and hook into it for some of the flight variables.

I was going to use Ximian, but I think I'll grab VS Express since I'm on Windows. I take it you just compile the gzip code into kOS.

Which version of Unity should I get for use with KSP 0.24.2?

I agree that it's not the best solution. I'm not sure why ferram implemented it that way, but it's what's there. Maybe he was afraid of breaking something internal to KSP? Anyway, I'll clone the repository and set up a dev environment, and see if I can patch in some FAR support... Is there a standardized dev environment for kOS? i.e., What compiler, IDE, Unity ver, etc should I be installing for greatest compatibility with the existing code? Also, I'm going to need a fair amount of handholding as I get started. For example, should I add support via AddOns/FerramAerospaceResearch? How does one check for the existence of another mod? (I think I can guess at how to do it, but the details may be dim now. Something about walking the parts, looking for one of Ferram's modules...)

I've been trying to wrap my head around all this crazy, fun stuff (orbital mechanics, ballistics, Kerbals, etc...), and I have a couple of questions. Being the neuro-atypical I am, I'm diving in over my head. I think I've launched two "stock" vessels, everything else has been with at least Ferram's and Deadly Reentry. What I'd like to do is automate/optimize my ascents and insertions with kOS, but I know that FAR twiddles with things like terminal velocity. I'd be willing to try my hand at setting up a dev environment if anyone can point me in the general direction of how to build out a module/addon that would get kOS to pull terminal velocity (and probably max drag) from FAR rather than the KSP "model"... I just did some quick dipping into the FARAPI code and the VesselUtils code, and I think I might be able to cobble something together. Of course, if I'm missing out on something critical, like FAR integration already in kOS, or FAR hooking into the core system and transparently integrating, I'll crawl back under my rock in shame...