Snjo

Feel free to create a new thread, and I will update the first post with a link to that one.

It's cool guys. I don't mind people reusing any part of Firespitter, as long as it's within normal modding terms. I put in a no model reuse clause to have a recourse against shady russian sites or commercial entities ripping off the mod wholesale.

If I remember correctly, you need a slash at the end of the texture root folder line

If it still uses FSwheel, the tail skid is secretly a wheel, but with some braking torque always applied (if the throttle is off). It had to use FSwheel since it has no animation, no suspension, and is always deployed. That wasn't an option in the stock wheel code when I made it. It also used the wheel steering module to make you able to turn with it. How's it set up now @RoverDude? (I assume it was disabled due to explodey issues)

I haven't looked at the game for so long that I have no idea how the stock game's modules work any more. Did the issue with ailerons flapping when the CoM starts matching the wing's position get fixed too? Can you set an aileron's function independent of its position on the vessel?

That paint job looks awesome!

For part makers who want some insight into how some of the models are arranged, you can take a look at this dump of my model folder https://dl.dropboxusercontent.com/u/22972712/ksp%20forum/Firespitter%20model%20source.zip. It's a mess, and mostly made for the Unity 4, but if you can wade through it, and assume which file is more relevant based on the date, you can maybe learn how propeller blur discs, wheel setups or wings control surfaces are done. License: Do whatever you want with these files, modify, redistribute etc. Warning: 546MB zip file. No logical system.

I can't say I agree about the reaction wheel approach. It is possible to do proper roll and pitch control in Unity, and the newer FS rotors do it by altering the pitch of the blades as they rotate around. There is wing code running on each blade. (It worked so well that by default I turned off adding real world speed into the math because it caused too much asymmetry of lift in anything but a dual rotor setup.) The older rotors do it by altering the thrustTransform angle instead of moving the thrust average position, but the effect is pretty much the same. Reaction wheels are a cheat, and I have never been a fan. You might notice reaction wheels are off or incredibly weak on the FS cockpits, because it doesn't let you simulate the actual effect of the rotors, or control surfaces and wing setup. Which for me is the whole fun of it. Both the old and the new rotors have functioning hover (or did last time I checked, which is a while ago). Instead of checking the mass etc, which would not give the right result when at an angle or while not vertically stable, it checks the split second changes to vertical speed and compensates as needed. It does however require the engine be powerful enough to get you out of a jam. If it's not powerful enough to lift you at 50% throttle, it's probably not powerful enough to reliably hover your vessel. I haven't played with the fuel flow in a long time, so it's possible there are better solutions now for sure.

Sounds good! For all I know the winglet range adjustments are less important with improved aero. I think I used it a lot because of the input bugs in the roll, where any small amount of roll input would cause full deflection. You have probably noticed that a lot of values are wonky, not just thrust, but prices and max temps etc. Do whatever you need to them.

The drop tanks unfortunately need fuel lines. Getting them to be their own fuel lines, or routing fuel through the wings would have been ideal, but the Squad code I needed to understand was pretty damn confusing. The size and number of blades will cause more lift, but also more drag and weight. Until you reach the max potential power output of the engine, you gain thrust, after that sweet spot, you are just wasting fuel. I can't remember what the deal was with the RPM though, except it probably has a max RPM since lift doesn't work too well in real life when it spins too fast*. *It's complicated. I'm not.

Not at all!

v3.3 Download -Enabled config values for camera max distance and work area. Check settings.txt -Defaults are now lower than before to avoid too high cam distance when entering the editor. I couldn't reproduce the error myself, but hopefully, this fixes it well enough for you. If you still get too much scrolling set the cam distance in the settings.txt, but it's only 80 now as opposed to 1000 meters.

I actually made the old heli rotors overheat when you use the "OH ...."-button / auto-stabilizer, and with new heat rules that probably happens pretty fast. If it's not when using that function, I wouldn't know, unless toggling between full and no throttle really fast is an issue now. Which parts are you using and how?

The thing with the biplane wings is they need to have a lot more lift than stock to fly at the correct speed. I made it out to be about 3x, Ferram actually did some proper work and said stock lift was 3.4x too low. I tuned it until a sopwith took off at almost the listed take off speed. The trade off should be that they aren't usable for space and high speed, possibly that just requires a low temp tolerance. I never got around to making them snap at high speeds or making the canvas tear with some funny shader work with lift loss There are some benefits to the way those wings work, they don't suffer from the indecisiveness stock does or did when the wings lift point shift in relation to the CoM, and they can have several lift points per wing, making proper ailerons etc possible. So the biplane and fighter jet wings should remain FSwing. the rest are stock anyway, or are set up to handle stock modules. (The fighter jet wing has both versions available)

Sure, if you have a kerbalstuff user name, and if people still use the other thing, that name too (if it has multi-author support) I stopped updating curseforge way back because I wasn't able to upload files to it.

Roverdude has been added as a collaborator on the Firespitter repository, so he now has the option to post official dll updates

the plugin is available for download from github, the direct link to it is always https://github.com/snjo/Firespitter/blob/master/For%20release/Firespitter/Plugins/Firespitter.dll?raw=true, but you can also use the Download Plugin button on http://snjo.github.io/ I wouldn't base too much off of it until people have chimed in on how broken or not it is. As I said, I only had time to take off with an old plane, thereby testing: -wing lift and control surfaces -wheel code -sound playback -propellers Other parts are likely OK, but you never know. I'm going away for the weekend, so I'll have to test more after that. - - - Updated - - - I don't think there's any particular reason the old module shouldn't work. I kept it around for legacy support reasons, but I haven't made any changes or used it since creating FStextureSwitch2. The newer module probably handles symmetry etc way better, aside from all the other features. It was deprecated instead of replaced since the cfg layout for it was completely different, which would have caused a lot of issues.

Well, I haven't played KSP in a long time, but I don't want everything to break Now that there's mining and new aero, I'll have to take another look.

I've done a quick build for KSP 1.0, get the plugin in the usual place. Haven't had the chance to test anything more that prop spin, sounds and wing lift, but it's promising. It's possible drag changes in the main game will mean some retweaking of planes, but I only tested it via RDP with unreliable key inputs.

It was this mod, but I just had to redo a lot of stuff, so it hasn't been rei-mplemented.

The 6dof camera is separate from the other cameras. I originally did some extra stuff for it, but in the most recent version I didn't get around to fixing that. I'll have to dig out the thing and do some tests.

Oh, that's a bit too much zoom out then for sure. It must do some auto scale to the furthest distance in some cases then. The * forces a rescale when it hasn't happened automatically. No visual changes to the hangar, but sometimes the scale for the work area and camera boundary don't get applied at the right time. I'll see if there's a smoother way to check it.

You are absolutely right! I had somehow dropped the line that updates the max zoom. Get the new version. v3.2 Download -Fixed camera max zoom distance not being set. Stayed at default 35m, Now 1000m.

Try this one and see if it works well v3.1 for KSP 0.90 Download If the work area and camera movement stays small after loading the SPH/VAB, press the hotkey to reattempt the fix. The default hotkey is Numpad *. This key is reconfigurable in settings.txt. For the custom key to work, the settings.txt file MUST be placed in GameData\FShangarExtender\settings.txt The reason the scaling sometimes doesn't happen is probably due to timing between the scaling attempts and the speed the game loads the scene and settings.

You don't anymore. I disabled all the old code, and haven't attempted to scale the models yet, so for now you simply have to build through the walls, or on the ground outside if the walls a re a problem. Unfortunately a craft built far away will also launch in an odd location, so moving it back to center before launch may be necessary in some cases. Just extract the folder to the GameData folder so you end up with a folder KSP_win\Gamedata\HangarExtender\ or something similar. IT really doesn't matter where it's extracted in there because it's just a dll, but it's good to keep things tidy, especially if I re-implement the settings file, which would require the correct path.