Firespitter propeller plane and helicopter parts v7.1 (May 5th) for KSP 1.0

[Snjo]

Snjo, I wonder if it'd be possible to make an addition to your wing module that would give it FAR-compatible parameters (zeroing FAR-side ones in the process)? Ferram mentioned that it's outside the scope of FAR, but maybe you could do something like that.

The animated wing module has a lot of potential, a lot of stuff could be done using it, but unfortunately, it simply doesn't work with FAR. You can already detect the presence of FAR, so would that be possible to support it's flight model Firespitter-side?

The short answer is no.

Long answer:

FAR and the FS lift code takes two very different approaches to setting up wings. Ferram is not a part creator, he aims to improve pre-existing parts with code only. This means treating the part as simply a nice visual blob, and defining everything by cfg values and creating a sort of imaginary wing that will perform how a real wing would behave if it was in that location. The model itself is irrelevant. In terms of the average point of lift on a wing (or Center of Lift), he takes a similar approach to stock lift code, saying that it's in some fixed location. In stock that is the part's center of mass (its Vector3.zero), and for FAR, it is at the CoM plus some cfg based position.

My code demands that it is running on a part created with prior intent to use the FSliftSurface, and that it contains defined Transforms (3d location objects) that tell it where the Center of Lift is. Additionally, you can have more than one CoL in a single part. There's the main CoL for the large wing structure, but there can also be other, less powerful lift attributors in ailerons, flaps etc. The trick with these are, they can move.

This is important. The aileron section of the model moving and rotating alters the Angle of Attack of that lift transform, thereby creating force in a new directio, but the main wing lift remains the same. It also allows for stuff like folding wings, which PolecatEZ is playing around with.

FAR does not support moving lift transforms, or multiple lifts in one part. You could not create a single part space shuttle with FAR, you could do that with FS lift (but it's incredibly difficult).

OK, so they are different, big whoop. Can I just scrap my lift code and put Ferram's better lift code into my stuff and make it support multiples and movement?

I could - if I had been a bloody aerodynamics genius like Ferram. I am not. He spent years creating that code, and it is beyond what I have the knowledge and time to do. I assume that every part of his lift assumes his single point static setup. To even find out if that's true or not would require a large amount of research. These reasons are probably also why Ferram said it was out of scope. I assume he knows it requires a large rewrite.

Now, what can be done to alleviate the issues?

1) I can try to find out why FAR reacts badly to FS lift, and reportedly goes super speed etc. This would still mean those wings would not have all the other aerodynamic properties that all other FAR wings would have on the same vessel. Like proper stalling, supersonic code etc.

2) I can feed good info to values that FAR can read, and act upon, and update it's math from. This would mean a lot of works for Ferram.

3) I can admit that my code is better than stock (and solves some very important issues), but will never be better than Ferram's, and detect when you use FAR, and shut my code down, allowing FAR to take full control.

I have gone for option 3. You gain all the benefits from FAR if you choose to use it, but you lose benefits that have to do with independent lift sections inside a part. There is still room to do option 1 in addition to that, if the cfg explicitly states "screwFAR = True", but it requires massive amounts of testing. So then there's the question. Given a limited amount of time and inspiration, do I create new stuff, or fix something that in 90% of cases is not broken. OK, so that 10% is really cool, and at any point I may start working on anything that is "really cool", but for now, no, I'd rather get back to making the next stuff.

[Madrias]

Is anyone else having the problem where the props don't spin (except the PROpeller) with the new prerelease? I dropped the old .dll back in, all my old props spin. Drop the new .dll back in, the PROpeller works, but the nose engine and folding prop don't turn, which I would take to also mean that the stack mount prop doesn't work.

I know, it's a pre-release and thereby a beta test, but I feel obligated to mention it as I've done the .dll swap a few times to confirm my findings. New .dll, PROpeller works as expected, all engines still produce thrust, but any engine that isn't the PROpeller fails to spin (didn't test the Turboprop, but I hadn't thought to do it when testing. Was using an older test plane of mine that used folders, nose electric, and nose gas props). Old .dll, PROpeller fails to work (though this is expected. I just yanked all the code that makes it run), all working engines produce thrust, all props spin.

[Snjo]

Is anyone else having the problem where the props don't spin (except the PROpeller) with the new prerelease? I dropped the old .dll back in, all my old props spin. Drop the new .dll back in, the PROpeller works, but the nose engine and folding prop don't turn, which I would take to also mean that the stack mount prop doesn't work.

I know, it's a pre-release and thereby a beta test, but I feel obligated to mention it as I've done the .dll swap a few times to confirm my findings. New .dll, PROpeller works as expected, all engines still produce thrust, but any engine that isn't the PROpeller fails to spin (didn't test the Turboprop, but I hadn't thought to do it when testing. Was using an older test plane of mine that used folders, nose electric, and nose gas props). Old .dll, PROpeller fails to work (though this is expected. I just yanked all the code that makes it run), all working engines produce thrust, all props spin.

Thank you for the bug report. Luckily I just fixed it, but unfortunately that version of the plugin was also up on curseforge for a day or two. Get the working version by downloading the full release from curse now.

I like the features curseforge has for adding pictures and videos to the mod desciption, but the file upload and download has some issues. A user requested that I add a download for just the plugin, so I did, but then, even though it was marked Beta, it became the default download, which would be confusing for people looking for the parts.

So I figured, what the hell, let's just throw a version up without PROpeller, but with the wheel alignment. So then there were non spinning propellers all around. And now, because I updated the main mod file, I can't update the plugin-only download without also uploading the main mod again to keep it as the default download file. I like curseforge in general, but it still needs some tinkering, and I hope their code isn't too tied up into their setups for other games that they can't easily alter the options for the kerbal version of.

I will remove the plugin-only download from curse for the time being, because it will too easily be out of date. It is available at https://github.com/snjo/Firespitter/tree/master/For%20release/Firespitter/Plugins.

[LC NOoSE IV]

Hey can you make a turboprop that mounts directly to a one metre hull with the sideways exhaust

[LC NOoSE IV]

also the turboprop needs to have the jet and prop sound

[Snjo]

The turboprop is not done yet, it needs new code and sound, plus prop blur.

Check KAX for a very nice inline turboprop using Firespitter code.

[Justin Kerbice]

@snjo: a little question about airbrakes, correct me if I'm wrong but as I see, you use a little trick to just rotate the part itself as a whole on its node attach point.

So there is no way to make an airbrake with a usual animated part made by multiple meshes, right ?

Or is there any other way to make a working airbrake using your animate module + FSairBrake module ?

Last question, what do you think about compiling your plug-in against 0.23 KSP libs and provide the last release for KSP 0.23.5 and 0.23 (to be sure they both work) ?

I know it would means also more work for you but even a "release without any kind of support" will be fine IMHO.

[Snjo]

@snjo: a little question about airbrakes, correct me if I'm wrong but as I see, you use a little trick to just rotate the part itself as a whole on its node attach point.

So there is no way to make an airbrake with a usual animated part made by multiple meshes, right ?

Or is there any other way to make a working airbrake using your animate module + FSairBrake module ?

Last question, what do you think about compiling your plug-in against 0.23 KSP libs and provide the last release for KSP 0.23.5 and 0.23 (to be sure they both work) ?

I know it would means also more work for you but even a "release without any kind of support" will be fine IMHO.

While it looks like the whole part is moving, it only moves a named transform inside the part. It just so happens that that is the only mesh on it. If you look at the b9 air brakes, they have both a fixed section and a moving section using the same code.

It would be possible to rewrite it to also accept an animation, but I have moved on from the pure part.drag alteration, to using aerodynamic surfaces for the same job. That is FSliftSurface and an FSwing set up to respond to an action group, or a future air brake module that uses lift surface with low lift efficiency but high drag.

edit: actually you can make that right now by using the air brake module with a static drag amount and an additional lift surface, but the improved module would remove the lift and drag when not deployed

You can download the source and recompile for the dlls in 0.23, but there is no already compiled dll for 0.23.

In the future however, all previous version since 0.23.5 will be available in the releases section of the github repo. Each release is also tied to a certain commit in the code, making it easy to branch off the code from when it worked for that KSP version. It's harder to find the final commit for 0.23 (I only started using the Releases feature around the time of 0.23.5)

Edited May 26, 2014 by Snjo

[zack2014]

Bug Report here: The swiveling helo gear on the newest prerelease has really bad texture issues, instead of being wheels, they end up being very flat, very long ellipses. They still do all the animations, but they look rather odd. It might be a mod incompatibility (I run a lot of them) but I don't know.

[Snjo]

Bug Report here: The swiveling helo gear on the newest prerelease has really bad texture issues, instead of being wheels, they end up being very flat, very long ellipses. They still do all the animations, but they look rather odd. It might be a mod incompatibility (I run a lot of them) but I don't know.

No, it's me setting up the model badly. There's a non uniform scale earlier in the hierarchy that sometimes gets wonky if you switch to a vessel. Just need to redo the model setup.

[zack2014]

Alright, good to know it's not just me then!

[Snjo]

bac9 and Taverius have ben pestering me to make fuel tanks switch alongside textures and meshes. And after slaving away in the coding salt mines, it works!

FStextureSwitch2 + FSfuelSwitch

This is a single part, using four different textures, and switching fuel tanks automatically.

FSmeshSwitch + FSfuelSwitch

This is four instances of the same b9 part, which uses four different meshes inside one model, to create a single part that can hold several looks and fuels, but only uses a single texture. Other parts like this could have more visually distinct model changes.

And finally, in the vein of the wheel alignment guides, if you make a helicopter rotor with unclear mounting directions, they can now have arrows to guide the player.

These guides only appear when you are moving the part around, not when sitting nicely attached to the vessel.

Edited May 26, 2014 by Snjo

[Madrias]

Wow! This just keeps getting better.

Stupid as it might sound, I wouldn't mind all parts having one common texture they can align to. Possibly something civilian styled.

[Taverius]

bac9 and Taverius have ben pestering me to make fuel tanks switch alongside textures and meshes.

*lovingly fondles his whip*

[NoMrBond]

*lovingly fondles his whip*

I assume this is a feature you're intending to use in the next B9 release then?

[Taverius]

That's the idea.

I've already implemented texture switcher in quite a few parts ... now for fuel tanks and such.

[PolecatEZ]

I feel my love-hate relationship with Snjo kicking in again. I was literally about 2 hours of work away from a beta release of D12, and now he gives me new things to add. The parent B9 pack will benefit massively from this though...if I time it right now we can do simultaneous release (isn't that everyone's goal?).

-----

Did I also read the github correctly that texture switching just changed format in the MODULE setup? *back to the salt mines*

Any chance I could get either some documentation or sample configs for the following:

- FSmeshswitch with fuel switching (integrated or separate MODULE?) - too easy

- multiple prop setup

- new FStextureSwitch formatting - looks like old way is still backwards compatible

I'll hit you up for a unity config.

Edited May 27, 2014 by PolecatEZ

[Taverius]

Testing:

• Switching to craft via map
  
• Switching to craft via tracking centre
  
• Switching to craft via keyboard in range
  
• Docking/undocking
  

Everything passed, it all remembered the tank type and amount. Looks good to me

PolecatEZ, PM me your email and ill give you read access to git trunk on bitbucket - that should make it easier for you to target mainline.

We may make the repo public in the future, but for now its still set to private.

[Justin Kerbice]

@snjo: incredible but does it means we can switch tex/content of tank AFTER launching the craft too ? I hope not (a LF tank can't be magically mutated to a Ox tank, or LF/Ox one or anything else)

[Snjo]

I feel my love-hate relationship with Snjo kicking in again. I was literally about 2 hours of work away from a beta release of D12, and now he gives me new things to add. The parent B9 pack will benefit massively from this though...if I time it right now we can do simultaneous release (isn't that everyone's goal?).

-----

Did I also read the github correctly that texture switching just changed format in the MODULE setup? *back to the salt mines*

Any chance I could get either some documentation or sample configs for the following:

- FSmeshswitch with fuel switching (integrated or separate MODULE?) - too easy

- multiple prop setup

- new FStextureSwitch formatting - looks like old way is still backwards compatible

I'll hit you up for a unity config.

The fuel switch only works with FSmeshSwitch and FStextureSwitch2, not the old FStextureSwitch. I kept the old one intact in order to not break older parts, but it is now deprecated.

an example config:

MODULE
{
	name = FStextureSwitch2
	//showListButton = True
	textureNames = Firespitter/Parts/Fuselage/FS_oblongFuselage/model000;Firespitter/Parts/Fuselage/FS_oblongFuel/model000;Firespitter/Parts/Fuselage/FS_oblongFuselageRocketFuel/model000;Firespitter/Parts/Fuselage/FS_oblongFuselageBattery/model000
	objectNames = Cylinder_004	
	textureDisplayNames = Empty;Fuel;Rocket;Battery
	useFuelSwitchModule = True
	fuelTankSetups = 0;1;2;3
}

MODULE
{
	name = FSfuelSwitch
	resourceNames = Structural;LiquidFuel;LiquidFuel,Oxidizer;ElectricCharge
	resourceAmounts = 0;100;75,25;200
	hasGUI = False	
}

As you can see from the line resourceNames = Structural;LiquidFuel;LiquidFuel,Oxidizer;ElectricCharge, you can have tank setups with multiple fuels, but a max of four in each setup*. An unlimited number of setups in each part though.

Proper documentation is coming when it's all nailed down.

*I store the current fuel amoutns in a vector4, so it holds max four current values. If there is ever a need for more, it's easy to add another four.

Testing:

• Switching to craft via map
  
• Switching to craft via tracking centre
  
• Switching to craft via keyboard in range
  
• Docking/undocking
  

Everything passed, it all remembered the tank type and amount. Looks good to me

...

Awesome!

@snjo: incredible but does it means we can switch tex/content of tank AFTER launching the craft too ? I hope not (a LF tank can't be magically mutated to a Ox tank, or LF/Ox one or anything else)

You can decide in the cfg whether to allow in flight switching. The default is Off. If you allow switching, it will empty the tanks when you convert it. For certain tanks it makes sense, like switching a tank from Liquidfuel to Kethane so that you r rocket can become a mining station. (If Kethane allows any old fuel tank. Not sure about the code on that)

[Taverius]

If Kethane allows any old fuel tank. Not sure about the code on that

I think so? It just has a higher dry weight and lower capacities for gameplay balance.

The only thing when one does something like this is remembering to hook a fuel line going from the fuel tank to the converter, since that fills tanks by consuming negative fuel.

[Justin Kerbice]

@snjo: I found a little issue on 23.5 with FS 6.3, these propellers have

FS2ME: no right click info + no thrust displayed

FS1TP: no thrust display too

others propellers correctly show ex: 60 kN in the part window.

Hope this help.

[Snjo]

@snjo: I found a little issue on 23.5 with FS 6.3, these propellers have

FS2ME: no right click info + no thrust displayed

FS1TP: no thrust display too

others propellers correctly show ex: 60 kN in the part window.

Hope this help.

Yeah, they are both using the new module. I haven't added in the info stuff to them yet, like right click info and reporting the force to the thrust arrow.

Also, the electric engine's efficiency may be way too high in that version, I haven't play tested it yet.

[Kommitz]

The new additions for texture switching & mesh switching look fantastic for structural parts sets. I'll definitely consider making use of the plugin myself now, lots of features I've been looking for for a while now.

[Albert VDS]

Looking forward to the new texture switcher.