DKnight54

Just to check, do you have Hullcam VDS installed? I'm betting that if you check the voxelization using the FAR supersonic tab, you'll see that it voxelizes the cockpit only, and that the docking port and anything attached to it will not be voxelized. Not sure what the interaction is, but because Hullcam VDS adds a camera to docking ports, this somehow breaks the voxelization to that part and anything attached to it. Please note that I've not done detailed testing, and am assuming that normal docking ports may have the same effect. I've only just caught the source last night have chucking mods one by one, and there's no errors(That I could see) in the logs. AFAIK, there was no issues with this in the previous "Johns" version.

Hmm... Just wanted to share a few things I learned about designing planes in nuFAR. When I started learning to design planes for FAR, the rule of the thumb was that as long as the Center of Pressure/Center of Lift marker is behind the center of mass, then the plane should be fine. However, it doesn't over work this way with nuFAR. Compare this two similar looking designs. You'd figure that performance be about the same right? However, the second design will actually have a tendency to pitch up. The reason? Average COL may be behind COM, with the majority of the life from the main wings in front of the COM, the lift from the main wing will cause the aircraft to pitch up. The good version The bad version Try it out for yourself. Note, you'd need SuicidalInsanity's Mk2 Expansion set's MK-1 Chines

Finally getting around to posting one of my aircrafts. Pretty basic design but neat to fly. Watch the throttle on the the turbojet though! Managed to set my plane on fire a couple of times when flying low altitudes... Craft file here Originally designed with Eskandare's Thermal Nuclear Engines and Nertea's Heat Control but revised to be completely stock and rebalanced. Mods used - Adjustable landing gear by BahamutoD Fuel amounts have been carefully calibrated to have zero COM movement.

Hi, Anyone else having problems opening the settings menu? Running KSP 1.0.2 64 on linux. Alt-B, Shift-B, Ctrl-B doesn't work...

From my own experience with flaps in front of wings, you'd need to set deploy angle to negative to get them to generate lift. Else they will deploy downwards and actually cause negative lift. Also, you need to set negative AOA else the flap will stall ( along with the rest of the wing) as soon as you pull up . On my plane, I set flap deploy to -13.5 degrees, AOA to -90% and control surface deflection to 10 degrees See if that helps. Edit: for true slats, we'd need something that pushes the leading control surface fowards.... Insane robotics might work except it'd be wobbly... Or maybe Ferram can add code to deploy slats?

Hi there, had much fun sticking this engines on planes and sending them to space. That being said, I noticed that the masamune is less efficient than the stock nuke engine. One a existing design, where I removed a nerva and replaced the stock turbojet with the masamune, I noticed a huge(close to half) reduction in delta-v. Looking into the cfg files, I realized that stock nerva engines had liquidfuel consumption of 0.9 while masamune was 1. Was this intentional for balancing reasons? I'd figure that masamune and the stock nerva have similar fuel efficiency while the masamune would weight heavier due to more complexity

Hi Ferram, first off, thanks for all the hard work you've put into FAR. That being said, I've noticed a problem with using Procedural Parts for cones with FAR, and haven't notice anyone mentioning it before I've noticed it in the last few Dev Builds of FAR, using the latest version of Procedural Parts. You can see it using voxel debugging in the editor. I tested this on a clean install of 64-bit KSP 1.0.2 on Linux with only modularflightintegrator, most recent FAR dev build, procedural parts and ModuleManager 2.6.5 and was able to recreate the issue. To recreate, just attach any of the procedural parts and select cone and set the tip to 0 or use the procedural cone directly. Log files look clear with no errors, but attached anyway. https://www.dropbox.com/s/0rdqzdac6zx9r97/KSP.log?dl=0 I don't think it's a problem directly from procedural parts because there was a dev build where the problem went away, but latter came back in a latter build. IIRC, the build without problems should have been the one before the negative scale mirrorRefAxis fix.

I've been noticing some weird interactions with ailerons that intersected with a vertical wingtips, and I've being encountering this issue since earlier build versions. That being said, being curious, I turned on the aero overlay in nuFar and discovered this: lift force for B9 control surface is calculated at the edges, while stock have it at the centre. I'm currently using the latest updated patch.

Looks like it could be a model offset issue. In blender, check to make sure that the that the centre of the model you are exporting is set to the actual centre, and not say offset to the origin of the scene.

Sorry, What do you mean by change their function? more specifically which object's function? If you're talking about sweeping the wings and whether it affects the flight characteristics, at the very least, it will change the location of the center of lift. That can have a very drastic change in a plane's performance. Also, do note that as far as I'm aware, for sweeping wings to have any effect on flight characteristics, you'd need to be using FAR or NEAR. In the plane I showed in the screenshots, the center of lift was originally quite near the center of mass, and the plane was quite acrobatic, and quick to respond to pitch control input. When I sweep the wings back, it actually became stable and sluggish in response to pitch. I also did a quick scan of the numbers in the FAR analysis, and sweeping the wings do modify the stability values. However, I have no idea of how accurate the changes match real world performance. Ferram would be a better person to ask. I suspect at that on the current version for FAR that it's not 100% accurate because part occlusion is not accounted for IIRC. In theory, one would sweep wings for supersonic flight, but my admittedly limited testing do not show any major differences in level flight aside for a drop in coefficient of lift. I do admit to playing without sudden aero dis-assembly though. Aside from that, I can only suggest that you play around with it and report back the findings Regards, DKnight54

Hi Guys, The other day, Jeb was testing some new wings from a new supplier under supersonic conditions. Apparently the wings' structural material was made from bamboo and started flexing backwards under the high dynamic pressure. To Jeb's surprise, that made the plane more stable as the center of lift shifted backwards. Upon landing, Jeb insisted on Bill making some wings that could blend on command, and Bill found the only parts manufacturer Krazy enough to do it, Dorky Krazy Wings. What this is: A infernal robotics powered wing hinge that allows attached wings to be swung backwards. Yes, you can also swing the wings forward by flipping the part backwards, but the models screw up for some reason. Required mods : Infernal Robotics plugin(Not included and found here) Download of parts here Credits: sirkut for Infernal Robotics, without which none of this would be possible ZodiusInfuser for his excellent Infernal Robotics parts which I have been dissecting to figure out how to make it all work. PolecatEZ for teasing me with the F14 swing wings in the D12 Aerotech. That was also where the initial idea of making the part with infernal robotics came about. Various Modders who have put together the various guides and tutorials. Known issues: Lousy/simple model : First time actually modelling something myself in any kind of 3d modelling software. Be kind Lousy Textures : See above:cool: The models flip out when rotated in certain directions : I have no idea myself. Advice would be much appreciated! Works with FAR? - Not too sure myself. Under a quick test, Cd did not change(Since FAR ignores part occlusion IIRC) but Cl changes(drops) and center of lift shifts backwards. Be careful with that, you can shift center of lift so much that the plane is too stable and cannot pitch up. Rotating the part under VAB/SPH causes the models to glitch out! - long noted Infernal Robotics issue. I'm not aware of any workaround that I can implement. License? I'm releasing this under Creative Commons - Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) since I'm sure there are many others that can do a much better job given this starting point and I'm unlikely to further improve the quality any time soon. To that end, I'm releasing the blender model as well. If anyone feels they can do a much better job, have fun! Regards, DKnight54

Hey guys, I need help with the colliders using this plugin. I figured out that to get working colliders, I've got to add them using the Mu Collider, but a couple of problems. For the box colliders, I can basically get them working, but I can't reshape them. or rotate them, or translate them. Is this intended behavior or am I missing something somewhere. I then tried the mesh mu colliders, and all seem well at first, but when I export and reimport back to check, the mu collider mesh has basically collapsed into a single dot. Did I do something wrong?(Should I not have applied the translation, rotation and scale using ctrl-A?) Please halp! Regards, DKnight54

I think the FAR values are messed up. For some reason, the center of lift is show as far behind the actual wings.

What I meant was that we wouldn't need to model specific wings to use with the swing wings part, that existing wing mods/parts would work fine.

Hmm... Methinks the solution to this is to add an additional frame that can rotate from horizontal to vertical position.

Basically, yes. But given excellent procedural wing mods that we have, I believe we can leave the actual wings to those and let players have more flexibility. We would just need to have the "wing_fold_main" part that players would then attach wings to and have it swing around. Of course if you want to model dedicated wings for this part, I'll be happy to write up the FAR configs for those as well.

Hi K.Yeon, The problem for you is this line: nonSideAttach = 0 // 0 for canard-like / normal wing pieces, 1 for ctrlsurfaces attached to the back of other wing parts If you put 0, it's going to act as if the whole wing is the control surface, except you've specified the amount of surface area so it acts like the control surface is in the middle of the wing. Just replace the 0 with a 1 and it should work right. Regards, DKnight54

Hi Phenakist, Glad to hear that you're interested. I haven't replied, but since I saw your interest, I've been busy mocking up the cfg to have an idea of how to get the part to work in game. Using the D12 swing wing, I've been able to get the effect ingame Kindly please ignore the obviously out of range angle, it's still a learning process! (P/s, you won't believe the amount of work to convert a Firesplitter plugin mesh to a infernal robotics mesh!) Now, don't get too excited but that wing swinging back and forth. Swing that wing around will have zero effect since I don't see a way to dynamically update FAR wing values without writing a dedicated plugin. So what I need now is a similar model except like this: Basically I want to be able to attach the wing parts to where the arrow is pointing in the picture above. Up for it? Regards, DKnight54

Hi Phenakist, Don't know if this will interest you, but I'm looking to make some swing wings root parts using infernal robotics. Unfortunately, I have zero modelling skills, but am pretty sure I can figure out the config files. So far we can approximate swing wings under FAR using the current infernal robotics parts, but they tend to be very unstable (I think due to size) and tends to involve part clipping. I would like to fix that. Currently, there are some swing wings by PolecatEZ in D12 Aerotech http://forum.kerbalspaceprogram.com/threads/77894-WIP-D12-Aerotech-A-B9-Aerospace-Expansion-%28Beta1%29, but they don't work in FAR as FAR doesn't support changes of wing surfaces due to change in part geometry. That means a purely IR robotics wing would likely not work either. But if we attach the wings to a moving surface, it is accurately simulated in game using FAR, and that's what I'm interested in. Basically, there are three types of swing wings roots that I'm interested in making, swing back, like the F14 Tomcat, swing forward (think the planes from the movie "Stealth"), and wide angle(180 degrees swing) To make the part move using IR, we would need to have two meshes, a root mesh that would be attached to the main body, and a rotating mesh that we can later attach the wing to. Rotation would be around the point of origin of the second mesh. To give an idea about what is needed for Infernal Robotics models, please refer to this link : http://forum.kerbalspaceprogram.com/threads/81568-Tutorial-How-to-make-robotic-parts-for-the-Infernal-Robotics-plugin Interested? Regards, DKnight54

Hi, Just wanted to chime in that I'm experiencing the same issue as this bug report https://github.com/AlexanderDzhoganov/ksp-advanced-flybywire/issues/31 where the hat button #0 status is inverted (Always true unless another hat button is triggered, reports false when hat button #0 is triggered). I would like to note that I tested with the SDL-jstest and confirmed that it's reading the hat state correctly. I'm using the Logitech Extreme Pro 3d joystick. Regards, DKnight54

Hi, Just wanted to say I'm loving the procedural wings. I find the sliders to be much more easier to use then my experience with the original p-wings. That being said, would like to make a request. Is it possible to add the edge modifiers to the tip edge? I understand that the tip edge was probably left bare as a easy to connect surface, but an option to toggle on a edge that matches up with the leading and trailing edge would give, imho, the wings a more complete feel.

Hi ZodiacInfuser, Love your parts, and a must have download for me(Although I haven't really made use of them yet, not smart enough to fully utilize them ) That being said, on the new lander legs, they look as if they would be perfect for hiding thrusters inside, making for an elegant combination for vertical landing operations., Of course size would have to be significantly scaled up to incorporate even a 1.25m engine, so not sure if you are interested in making a variation for that(If you do, can I beg for one that opens up to a back and front foot instead of a quad foot? With that, I might actually go forth with my dreams of making a macross Valkyrie ingame...

Hey guys, noticed that the default cfg files don't load goodspeed onto parts with MFT and FSFuelSwitch modules on it and hacked together a config file that does. Basically, it checks for the relevant modules and adds the goodspeed modules. // This config file REQUIRES ModuleManager to function! Get it here: http://forum.kerbalspaceprogram.com/threads/55219 // // By default, this file adds the Goodspeed Automatic Fuel Pump to anything that is not a command pod and contains LiquidFuel, Oxidizer, // MonoPropellant, and/or XenonGas. You may add additional resources below by copying one of these sections and editing the appropriate // resource identifier, or delete a section to stop ModuleManager from adding the pump to those kinds of parts. If you want the pump // added to your command pods too (most contain MonoPropellant these days), delete "!MODULE[ModuleCommand]," from each section below. @PART [*]:HAS[@RESOURCE[LiquidFuel],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]]:FINAL // Since this catches LFO tanks... { MODULE { name = GoodspeedPump } } @PART [*]:HAS[@RESOURCE[Oxidizer],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]]:FINAL // ...this is probably unnecessary, but you never know. { MODULE { name = GoodspeedPump } } @PART [*]:HAS[@RESOURCE[MonoPropellant],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]]:FINAL { MODULE { name = GoodspeedPump } } @PART [*]:HAS[@RESOURCE[XenonGas],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]]:FINAL { MODULE { name = GoodspeedPump } } @PART [*]:HAS[@MODULE[ModuleFuelTanks],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]]NEEDS[modularFuelTanks]:FINAL { MODULE { name = GoodspeedPump } } @PART [*]:HAS[@MODULE[FSfuelSwitch],!MODULE[ModuleCommand],!MODULE[GoodspeedPump]]:FINAL { MODULE { name = GoodspeedPump } } @PART [*]:HAS[@RESOURCE[Food],!MODULE[GoodspeedPump]]:NEEDS[Pump]:FINAL { MODULE { name = GoodspeedPump } } @PART [*]:HAS[@RESOURCE[Water],!MODULE[GoodspeedPump]]:NEEDS[Pump]:FINAL { MODULE { name = GoodspeedPump } } @PART [*]:HAS[@RESOURCE[Oxygen],!MODULE[GoodspeedPump]]:NEEDS[Pump]:FINAL { MODULE { name = GoodspeedPump } } // If you wish to only add the pump to specific parts, delete the stuff above this comment, // then use the example below, replacing "ExamplePartName" with the name of a part. @PART[ExamplePartName] { MODULE { name = GoodspeedPump } }