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

[mrsinister]

disregard my previous post...all is working now. I just downloaded the newest update.

[Snjo]

(...)

ETA: Snjo, I haven't looked into it myself yet - been busy - but is there a way to mod the .cfg file to get the 1.25m v5.2 engine with the old model to have POV-blur, or is that dependent on the new model?

The older model doesn't have the blur disc in it. I could of course include it and make it an alternate part...

[cross-posted in Ferram Aerospace Research Addon Thread]

(FAR stuff)

-Talon

I don't have time to test stuff for both stock and FAR (and still kep things relatively bug free), so the only reason the FAR cfg values are in there is because someone (Fennec?) created those values for me. I never heard about all these winglet problems before last week, so I thought all was good. Since I'm not doing any wing code, but just using the stock winglet stuff, there's nothing I can do about these bugs, it's up to Ferram to make stuff more compatible with stock stuff.

Mod cross compatibility is a tough issue, especially when it spawns bug reports that don't actually explain that people ARE using two different mods at the same time. I had one user report that lcok/unlock bug before, but I figured he was doing something very odd, cause he never mentioned he actually used FAR. Now I can see that the problem is that the FSwingletRangeAdjustment adjusts the max range when you load the craft, if it's not already set. So that explains the conflict. The only way around that is to either remove that module if you are using FAR, or include some extra variable to allow you to keep the module, but skip the setup stage. I imagine FAR has range adjustment though.

(Inverted controls and funny bussiness)

(...)

and would you mind if I painted your plane and heli parts almost black in color?

The way the control surfaces move is dependent on where the center of the wing is in relation to the Center Of Mass. If things are inverted, try moving the wings a bit. This way of figuring the control direction is also the reason for control surfaces freaking out when the CoM changes during flight, and the control surfaces no longer know reliably which side they are on. I wish they could be locked down, but I reckon FAR has already solved that problem, so if I create my own wing code, it might break stuff even more...

Go ahead, texture away! I used to pack in UV maps guides with the older parts, but I forgot, and no one has been complaining. If you need one. let me know.

[Black-Talon]

I don't have time to test stuff for both stock and FAR (and still kep things relatively bug free), so the only reason the FAR cfg values are in there is because someone (Fennec?) created those values for me. .... Mod cross compatibility is a tough issue, especially when it spawns bug reports that don't actually explain that people ARE using two different mods at the same time.

Completely understandable and as expected. Testing your parts with all the other mods would be ridiculous. Given I saw others with the same challenge I was having I just wanted to share what I'd found. I didn't see it clearly explained elsewhere so I hoped it would be helpful to some. Thanks again for the great stuff!

I never heard about all these winglet problems before last week, so I thought all was good. Since I'm not doing any wing code, but just using the stock winglet stuff, there's nothing I can do about these bugs, it's up to Ferram to make stuff more compatible with stock stuff.

Just to make sure my own confusion is clear, I don't really know if it's actually a problem with Ferram's support of this wing type. I mean, with my minor changes it seems to work... I wouldn't know if it's being modeled correctly but it works well enough for me. So I really don't know if Ferram needs to make changes to support this specifically or if it's just an opportunity for him to model it more accurately. I do know that I'm enjoying using both mods congruently with the few tweaks to eliminate the conflicts. I also know that I really appreciate all the enhanced entertainment I've had due to the volunteer work of all the modders. Thank you! It's been a blast!

[mrsinister]

The way the control surfaces move is dependent on where the center of the wing is in relation to the Center Of Mass. If things are inverted, try moving the wings a bit. This way of figuring the control direction is also the reason for control surfaces freaking out when the CoM changes during flight, and the control surfaces no longer know reliably which side they are on. I wish they could be locked down, but I reckon FAR has already solved that problem, so if I create my own wing code, it might break stuff even more...

Go ahead, texture away! I used to pack in UV maps guides with the older parts, but I forgot, and no one has been complaining. If you need one. let me know.

I have the regular .png files in your folders and some have the uv maps...it's not an issue.

here is a test pic though.... I think the white/gray wing lines need to be red as well....lol I like the almost black n red look

and the fuel can with the red stripe is mine. I did enlarge the small stabs though....for what I needed they were a bit small..

[Snjo]

Looking mean as hell

[mrsinister]

Looking mean as hell

thank you Sir!

[Caspian Sea Monster]

Love the mod Snjo! It was a bit buggy here and there, but your latest update seem to solve most of my problems! I made a amphibious VTOL with your parts and LLL stuff!

Simple and easy to control aircraft, very rugged too!

Anyway, thanks for the awesome mod and I can't wait for some rocket pods

What I am reminded of: Micro Machines Zi-9000 Assault Copter

[xvdBanksbvx]

I'm not sure if this is a bug or just how the engine works, but the FS1PE propeller engines centre of thrust is no centred on the engine but about 2/3rd's a propeller length above. It's only that part, no other prop or jet engines do this.

[Caspian Sea Monster]

The older model doesn't have the blur disc in it. I could of course include it and make it an alternate part...

You know what, don't worry about it. It gives me motivation to get off my butt and back into 3D modelin. I think I should just make I'm making a 1.25m to 0.625m nose adapter, sort of like the Mustang nose for the oblong fuselage, to mount the nose propeller and make it in the style of the Hawker Sea Fury, which does have a five-bladed prop.

ETA: Work in progress. Just placeholder textures/materials for now. Forgive me if it looks like garbage; I've been using Blender for a grand total of four hours now, and it's been six or seven years since the last time I did any modeling.

Edited June 29, 2013 by Caspian Sea Monster

[KhaosCorp]

Could someone please take a screenshot of a functioning helicopter in SPH with all 3 markers turned on (CoM/CoL/CoT)? I sure could use a nudge in the right direction...so far I have only made rotor driven backflip death machines...no helicopters.

[Supernovy]

Added [Plugin] tag.

[Senshi]

@KhaosCorp: A simple basic helicopter design:

Note that the "Lift" Indicator is only that far back because of the tail rotor with its fenetron. The actual "upward" lift provided is close (but not equal) zero. If you'd attach the tiniest regular wing you can find to the middle, the CoL would immediately be moved there. Firespitter helicopters are basically "zero lift"-vehicles .

It helps tremendously to have some sort of SAS mounted (note the nose-mounted ASAS in this design). Enable it while on the runway and you can perform a safe vertical takeoff. It's also invaluable to recover from uh... "acrobatic" maneuvers. And you will have a lot of those while trying to figure out how to control your chopper.

Basically just try and make sure the thrust is as close to the CoM as possible to prevent the introduction of any pitch rotation. The design above will start to pitch down very slightly once the fuel tank empties due to the reduced weight in the rear.

[Snjo]

I'm not sure if this is a bug or just how the engine works, but the FS1PE propeller engines centre of thrust is no centred on the engine but about 2/3rd's a propeller length above. It's only that part, no other prop or jet engines do this.

Oh wow! you're right! That explains the rebalancing I had to do on one of my planes.

Turns out I had two thustTransforms on the model, on eplaced correctly, and one at the edge of the blades. The result was a mix of those two positions.

Fixed it now, will upload a new version!.

edit: new version is on spaceport.

Edited June 30, 2013 by Snjo

[Black-Talon]

I've learned a few more things about using FAR with Firespitter Wings/Controls in case it's of interest to anyone trying to use both. I have a separate installation for FAR which I enjoy using to make/fly planes. I have Firespitter installed in both my non-FAR version of KSP, and the FAR-enable version. I do enjoy Firespitter in both!

Previously I noted that I was attempting to load and fly Firespitter's (Stock) K-17 in my FAR-enabled version of KSP and I observed a few hiccups that made it impossible to do:

• Controls don't update graphically unless they are locked and then unlocked prior to flight
  
• Even once the control surfaces are updating graphically they don't seem to apply much control to the craft
  
• Take off results in a uncontrolled loop and unintentional rough 'landing' ;-)
  
• For someone familiar with FAR you would notice that the control surfaces aren't configurable in the VAB
  
  These four issues can be resolved by eliminating the FSwingletRangeAdjustment Module from the Firespitter wings and changing the FAR Module from a wing to a control surface.

  
  

Previously I floated some questions about things I didn't understand:

1. It seems a FARControllableSurface is more accurate for the wings with control surfaces? Note that there is some concern noted in both the FAR and Firespitter threads that wings with integrated control surfaces are not yet supported in FAR...but I've found that without at least some tweaks, Firespitter wings are unusable in FAR, but work enjoyably once modified.
   
   This is all confirmed. In order for the Firespitter wings to be used as control surfaces with FAR installed they must be changed to be FAR Control Surfaces. This doesn't model them correctly, it treats the entire wing as a control surface instead of just the actual surface. That said, it does work which is better than not working. The root cause here is that FAR doesn't support this wing type.

   
   

2. The default drag and lift configuration is zeroed out on stock parts...should the same should be true for Firespitter wing/control parts?
   
   The suggestion is that no, there is no need for them to be zeroed out. FAR does that behind the scenes on it's own.

   
   

3. Some of the FAR configuration values used on Firespitter wings aren't documented in the FAR Readme.txt, perhaps they shouldn't be there? Others need to be there instead?
   
   These are older values and don't cause any harm but neither are they needed.

   
   

4. In FAR, when a AoA Sweep analysis is done, only CL is graphed... does the lack of CD and others indicate incorrectly configured parts?
   
   This is caused by the InfoDrive part that is installed on the K-17. A part I really enjoy! While I have no idea why, it seems that a part without a "rescaleFactor" defined in the config will destroy FAR's drag model. By setting "rescaleFactor = 1" for the Info Drive part, all works perfectly.

   
   

By making these minor adjustments I was able to enjoy a fantastic flight of the (Stock) Firespitter K-17 to the south pole and back. Nice!

Easy way to get Firespitter wings working with FAR so that the stock planes can be flown: use this Additional ModuleManager Config to make the modifications noted above. It is simpler than my previous ModuleManager Config and I'm just happy that it lets me enjoy the Stock Planes in my FAR-enabled KSP Installation. The config won't overwrite any parts and can be undone easily at any time by removing the config. Note that it only changes anything if FAR is installed (which comes with the required ModuleManager).

-Talon

[Snjo]

I've learned a few more things about using FAR with Firespitter Wings/Controls in case it's of interest to anyone trying to use both. I have a separate installation for FAR which I enjoy using to make/fly planes. I have Firespitter installed in both my non-FAR version of KSP, and the FAR-enable version. I do enjoy Firespitter in both!

[...]

-Talon

Great investigative work!

If you have made edits to the FAR values that I can pop into my cfg files, send them my way, and I can update the ones in my pack, and add comments to the cfg files for stuff to disable. Maybe I can also do a check to auto disable the wingletRangeAdjustment if FAR is present.

Added rescaleFactor to the info part.

[Snjo]

Texture switching is in!

What does this mean?

Well, not only can you switch stuff like the nose art easily, but you can have variants of the fuselage or wings parts for instance without filling up the parts view. So you don't have to be limited to the boring old gray texture for the oblong parts, but using the same actual parts, you can make BOTH a gray mustang, and a a flashy f-86, just by switching the texture in the SPH. And if they use a material set up for it, one can be shiny (specular), and the other matte.

The cfg file just needs the textures used listed like so

MODULE
 {
	name = FStextureSwitch
	moduleID = 0
	targetObjectName = noseartplate
	textures
	{
		name = Firespitter/Parts/Command/FS_bomberCockpit/noseArt/ozymandius_model003
		name = Firespitter/Parts/Command/FS_bomberCockpit/noseArt/early_bird_model003
		name = Firespitter/Parts/Command/FS_bomberCockpit/noseArt/swift_demise_model003		
	}
 }

This also means they can steal textures from other parts.

Edited June 30, 2013 by Snjo

[Senshi]

The suggested approach using modulemanager to assign the values is much easier on the user, I think. Earlier, FAR users had to go through every part.cfg and uncomment the FAR lines. With the MM .cfg, we can just pop in that additional file and MM makes sure that the FAR values are added to the Firespitter Parts as necessary.

Btw, adore the texture changer. Everything that helps reduce cluttering parts deserves a big plus, and this looks like a very nice solution .

[mrsinister]

Texture switching is in!

What does this mean?

Well, not only can you switch stuff like the nose art easily, but you can have variants of the fuselage or wings parts for instance without filling up the parts view. So you don't have to be limited to the boring old gray texture for the oblong parts, but using the same actual parts, you can make BOTH a gray mustang, and a a flashy f-86, just by switching the texture in the SPH. And if they use a material set up for it, one can be shiny (specular), and the other matte.

The cfg file just needs the textures used listed like so

MODULE
 {
	name = FStextureSwitch
	moduleID = 0
	targetObjectName = noseartplate
	textures
	{
		name = Firespitter/Parts/Command/FS_bomberCockpit/noseArt/ozymandius_model003
		name = Firespitter/Parts/Command/FS_bomberCockpit/noseArt/early_bird_model003
		name = Firespitter/Parts/Command/FS_bomberCockpit/noseArt/swift_demise_model003		
	}
 }

This also means they can steal textures from other parts.

Nice! helps me now that I dont need additional copies of the same part (changed the name slightly) with different textures.

I thank you! /salute

[MR4Y]

Tried to make a Borovkov D Fighter without sucess. Apparently, pusher propellers don't match well with ramjets.

[mrsinister]

Tried to make a Borovkov D Fighter without sucess. Apparently, pusher propellers don't match well with ramjets.

lol, I noticed that too....

[xvdBanksbvx]

Oh wow! you're right! That explains the rebalancing I had to do on one of my planes.

Turns out I had two thustTransforms on the model, on eplaced correctly, and one at the edge of the blades. The result was a mix of those two positions.

Fixed it now, will upload a new version!.

edit: new version is on spaceport.

Cool, that was driving me crazy for ages when all my planes just nosed down and i didn't know why. Now i can start building my fighter bomber.

[satcharna]

Do you have any plans to include a "belly jet", like the one on the Yak 15?

[Snjo]

That's an interesting design. If I get around to making wing/surface mounted jets, I should try to make them in such a way as to look OK mounted on the fuselage like that. Still would be tough to integrate without a tall nose too...

It's pretty quiet on the modding front right now, cause I've got lots of work while my colleague is on holiday, but hopefully it will quiet down, and some interesting new challenge will pop up, forcing me back in gear. I made voxels in unity yesterday, but that doesn't really help my mod any

I gotta get some new alternate textures going for the texture switcher. Hope I didn't mess up the UV unwrap too badly on the old parts.

[sumghai]

Snjo, I found out about your excellent parts animation module through my use of the B9 Aerospace parts - it's definitely nice to see multiple persistent animations per component

I've been studying the documentation you've written for FSanimateGeneric, and while for the most part it seems straightforward, I was wondering if you or anyone have used this module with deployable solar panels? I'm asking because I'm trying to retrofit another modder's solar panels, which have problems with multiple animations per part.

Said part is the Balka Solar Wings Block from CardboardBoxProcessor's Kosmos pack - it consists of two extendable/retractable solar "wings" mounted on opposing sides of a rotating hub. The combined rotation of both the solar wings and the hub usually allows the Balka to track the sun effectively, but when switching between flights, the panels would revert to their default retracted state due to stock KSP being unable to handle multiple animations per part. The panels are *enormous* such that it takes literally minutes to fully re-extend each wing.

Below is a snippet from CBBP's original CFG file.

// Right solar wing
MODULE
    {
        name = ModuleDeployableSolarPanel

        animationName = open_right
        raycastTransformName = sunCatcherRight
        pivotName = ArmLeft01_main
        resourceName = ElectricCharge

        chargeRate = 200
        trackingSpeed = 0.1

        powerCurve
        {
            key = 206000000000 0 0 0
            key = 13599840256 1 0 0
            key = 68773560320 0.5 0 0
            key = 0 10 0 0
        }
    }

// Left solar wing
    MODULE
    {
        name = ModuleDeployableSolarPanel

        animationName = open_left
        raycastTransformName = sunCatcherLeft
        pivotName = ArmLeft01_main
        resourceName = ElectricCharge

        chargeRate = 200
        trackingSpeed = 0.1

        powerCurve
        {
            key = 206000000000 0 0 0
            key = 13599840256 1 0 0
            key = 68773560320 0.5 0 0
            key = 0 10 0 0
        }
    }

// Central rotating hub
    MODULE
    {
        name = ModuleDeployableSolarPanel

        animationName = rotary
        raycastTransformName = sunCatcherRight
        pivotName = Main_Rotary_Pivot
        resourceName = ElectricCharge

        chargeRate = 0

    trackingSpeed = 0.1

        powerCurve
        {
            key = 206000000000 0 0 0
            key = 13599840256 1 0 0
            key = 68773560320 0.5 0 0
            key = 0 10 0 0
        }
    }

[Ganymede]

Are nose/wing guns a planned feature?