Snjo

Double posted from its own thread This is the first public usable draft of the new flight recorder. You can record a path and then play it back later. A dummy plane will fly around following the path you flew originally. Download Control it via the gui window, and optionally use the following hotkeys: F12 - show/hide the menu O - Start recording the path. P - Stop recording K - Start playback L - Make the dummy plane go off rails, and fall out of the sky. (useful when you want it to look like you shot it down) Current limitations: -Recording will one be remembered in the current flight. Saving and loading from text files will come later. -It will not use your craft as the dummy, but the model in the models folder, but it can be replaced. Source code

This mod has been merged into Persistent Trails Head to that thread instead This is the first public usable draft of the new flight recorder. You can record a path and then play it back later. A dummy plane will fly around following the path you flew originally. Download v1.2 -Save and load paths to files. -Alternate models can be defined for the paths by editing the path file for now. Take care when loading a path to not occupy its starting position with your current vessel. Cause you will blow up. The recording and manual play back is now the "work path". When a work path plane ends its run, it will fall out of the sky rather than be deleted, even if Go off rails at end" is marked. Paths loaded from external files will play automatically, and the plane will either loop, be removed or fall out of the sky (go off rails) when the path ends. Menu explanation Record - Starts or continues recording to the work path. Stop - Ends the recording. Also calculates the time to return the start for looping paths. Clear - Clears then nodes, and adds the first node at the current location. Best used while recording is active. Add node - For precise work like recording a stand still, or small ground movements, add nodes at the start and end of the stop to make it look better. Loop path - If ON, the plane will return to the start of the path when it reaches the end, using the end speed. Off rails at end - If the path isn't a loop, the plane will fall to the ground after the path ends. Otherwise it will be deleted. (Unless it's a work path playback) Play - Plays the work path OffRails - Makes the work path plane fall down Save - saves the work path using the file name in the text box Load - Opens up the path loading dialog Alt+F6 - show/hide the menu Current limitations: -It will not use your craft as the dummy, but the model in the models folder, but it can be replaced. (You could make a new plane model, or a truck, whatever) -No sound on the dummy plane. How it works: When recording, nodes will be created storing the vessels current position, rotation and velocity. Nodes will only be created if there has been sufficient change to those values, so you will create lots of nodes during turns and other maneuvers, and very few when flying in a straight path. To precisely record a small taxiing maneuver or a stop,you can add a node manually. By default, no nodes will be created if you have moved less than 2 m. The precision settings will be controllable later on. Source code License: You can re-use the code as you want, as long as you give attribution in the forum post and readme file. You can rename and recompile stuff, but not repack the plugin as is in your own mod without permission. Any models, sounds, textures or other assets are not for re-use without permission.

It's called "An insight into owning, restoring servicing and flying", note the word insight. It has lots of details on selected minutiae, like changing the brake disc on a Lancaster rear wheel, but will be missing a ton of other equivalent things. It's filled with lots of history, articles and pretty pictures mixed in with schematics, checklists and such. So the target audience is the fan, not the mechanic, which I imagine suits all of us just fine.

I found them on bokkilden.no, but I'm sure you don't have to use a norwegian store for it

Just got these in the mail. That should help! Found a familiar scene

After placing a static, you need to exit to the space center and reload the database (Alt+F12 menu), or restart the game. If you place something, the start a new flight, it will not show up, unless there has been a gamedata reload.

That error is from KSP Interstellar, which assumes that all air intakes must produce intakeAir, and then swaps it for a custom IntakeAtm. That's a bad idea, but the author has been made aware of it already, so he'll probably fix it. Without a resource with mass, engines freak out, so an electric engine running on pure electricity without FScoolant or intakeAir in the mix will crash your game. Silly, I know.

Mr. Tommy the Gun. I approve!

I have to assume it's a mod conflict. Sadly the in game error log doesn't give the full error message. Post the matching nullref lines from output log in the KSP data folder, and then I can see which function the error is in. I'm on my cell, so no accurate file name. The blades normally pitch forwards and back to match the throttle value, which you can see when it's not running

Firespitter has a trim tool you can throw on your plane. It allows for super fine control over trim, with presets. Set up a -0.1 roll trim for instance, and keep flying straight. Stock roll and roll trim will always be super crazy because of a bug in the range of input that is actually used in roll. Only the first 20% or so is used. Can't say I've noticed that problem as consistently as you say though.

That was a bizarre thing to solve. I've been using a non KSP shader since forever on those propellers with no issues. Suddenly that wasn't good enough, even though the old ones still use it. Anyways, here's a new version. No throttle animation twisting the blades on that one, just so you know.

FNPlugin.AtmosphericIntake.OnFixedUpdate indicates that you have another mod that does fun stuff with air intakes, and may not support intakes producing FScoolant. You can try switching the intake resource, and fuel resource to intakeAir, but other than that I can't do anything.

Thank you! I think it's less than half But i have lost count.

Custom struts help a lot! Can never have too many wires, and wooden beams struts. Thanks to InfiniteDice for invaluable help with strut creation.

Oh You'd better believe I've already built one! It's just that it's currently racing green with british decals. As soon as that's sorted out, I'll throw it to you guys! Sweet! I tried making a remote control plugin once, but had some problems controlling all the axis and throttle settings, and the range stuff of course. What are you using to fly the remote plane? And are those guns currently out, or are you sitting on them like you like to?

That would probably be me Try this model then Just create a copy of the engine, rename it in the cfg, and replace the model files with these ones. (I have not tested it, but there is little reason for it to fail)

You can't scale just one piece of a model without either re-exporting the model, or writing some code to do that to a named object. If you just want to scale the entire thing down, that's as easy as altering the rescaleFactor. The base set of bi-plane parts is done. Now I just gotta do some alternate textures, a set of wheels and custom strut looks. ...and lots of cockpit IVA work

Impossible to say with all those mods where the conflict is, but since the only special thin about electric engines is the extra resource they use, I'd say any mod that messes with resource weights would be the culprit. Electric engines use an air substitute called FScoolant to get around the fact that you can't run on just the massless fuel electricCharge. If the FScoolant goes away or has 0 mass, bad stuff happens.

I can't imagine anyone ever wanting to put a dangerous thing like a machine gun on one of those beauties. KSP players are far too friendly for that. That's why I keep hearing "Can we please get some humanitarian aid air drop crates for this mod" or "How about a teddy bear launcher, or maybe a turret mounted jelly donut dispenser".

@Senshi Nice work! As you can probably tell from the curves above, I didn't put too much effort into making each engine different in those regards. That reminds me that I should tweak the values a bit for any engine that is supposed to be super powerful. (Of course there are limits to how fast a propeller engine should be able to go) @wasmic, turboporops. For now, the VTOL engines are the ones most similar in appearance. I've heard this request several times before, I've just been too lazy. Your contrail comment made me thank that when I finish my fx stuff, it should enable contrails based on temperature/altitude. Even propeller engines create contrails if you are high up in the cold air. Oh, and since I can't stop myself from sharing progress reports. I've set up some decent normal maps to bring the biplane wings alive: the flat section is how it loks with no normal map

It's important to be clear about what you mean by "the line of the force". In the first example there, the thrust are NOT in the line of the force, they are in the line of the lever. In the second, they ARE in line with the direction of the force. The second example is an interpretation of the pendulum fallacy just for kicks. An engine at the front of the plane should not pull the plane out of a spin as if the engine were pivoting freely towards the direction you wish you were going, it will pull you in the direction you are at that split second, and the in a different direction a little later. Not saying I've got everything right, just make sure which phenomenon you are describing. edit: As we know, in a rear wheel drive car, putting the pedal down in a slide is worse than it would be in a front wheel car, so it's not that cut and dry. But then again the front wheels can steer, so that changes everything.

Interesting fact about flat spins in KSP (and maybe unity in general). InfiniteDice did some test to try to reduce the tendency to spin out when losing one of two engines. He did this by moving the thrustTransform position away from the engine model towards the CoM. Imagine the span between the CoM and the engine as a range of 0-10000, where 0 is CoM and the engine is at 10000. Even when the thrust happened at 1, i.e. some millimeters away from the CoM, you would still flat spin if you lost an engine. Now, I didn't write the code, so I can't be sure how the positioning worked out, but if it's accurate, it means there is a bug in how force applied asymmetrically affects angular velocity on a rigidbody (or set of rigidbodies as in KSP).

I don't have any FAR specific craft. The included example craft have to work with stock+FS, which will often be slightly different than FAR+FS. I haven't noticed any styrofoaminess, but my parts are generally lighter than rocket parts since they are not full of fuel, and it's possible FAR creates more lift and less drag, so if you slap too much engine power one there, that could explain some of it. I think Ferram said something about the lifting ability of a stock wing being unrealistically low, so since the FAR lift values of my wings is based on their span etc, they will have more lift in the FAR version than stock.