philly_idle

Here's the file: https://onedrive.live.com/redir?resid=ba4082b106bb82c5%21226. Put it somewhere in your GameData directory, I recommend either into GameData/HabitatPack or (which is what I'm doing) GameData/your_username. Note that you need Module Mananger for this. Also, put the Module Manager DLL into GameData.

The node issues are pretty easy to solve using Module Manager: @PART[BaseMount] { @node_stack_bottom = 0.0, -0.15, 0.0, 0.0, -1.0, 0.0, 1 } @PART[centrifuge1] { @node_stack_bottom = 0.0, -1, 0.0, 0.0, -1.0, 0.0, 1 } @PART[inflato1] { @node_stack_bottom = 0.0, -2.5, 0.0, 0.0, -1.0, 0.0, 2 } @PART[inflato2] { @node_stack_bottom = 0.0, -1.9, 0.0, 0.0, -1.0, 0.0, 1 } @PART[inflatoFlat] { @node_stack_bottom = 0.0, -0.9375, 0.0, 0.0, -1.0, 0.0, 2 } @PART[orbitalorb] { @node_stack_bottom = 0.0, -1.18, 0.0, 0.0, -1.0, 0.0 } This pack works just fine for me with recompiled habitat.dll and LayeredAnimations.dll. I didn't test it with the prebuilt ones. EDIT: Here's a link to the file: https://onedrive.live.com/redir?resid=ba4082b106bb82c5%21226

Since ActiveStruts has been more or less abandoned, here's an update of DockingStrut for KSP 1.0: Download DockingStrut 1.0.1.0 for KSP 1.0 It compiled just fine against 1.0. No errors, no warnings. Let's hope there are no sneaky hidden bugs

Same problem with NEAR EDIT: I removed NEAR and attaching / manipulating a wing worked. However, when I remove the wing or try to sick it on somewhere else, nothing (not even other parts) will attach anymore.

You're right, thanks. I had to restart a couple of times...

Whow, that was quick! Thanks for your hard work! Perfect!

MachXXV, may I request a small addition for the next release? Angle snap do 22.5° would allow us to attach 8 boosters and 8 (or 4) fins between them. Looking at your code, the values are stored in a float array so this should be quite minor to add? EDIT: I just tried it in .25 - adding 22.5f works. It just messes up the angle and symmetry indicator in the editor because "22.5°" is too long.

Hi, the habitat pack works fine in .90 (I did however recompile Habitat.dll just to be sure) except the F.L.A.T., which is missing its texture. Any ideas why?

I can confirm that setting VAB_ANGLE_SNAP_INCLUDE_VERTICAL = True in settings.cfg has no effect. Still workes in .25 though. SQUAD, why did you remove this...all you had to do is keep this feature in!

MachXXV, please don't let this mod die. I don't want to live in a world without vertical snap

It loads for me, the wings also show up in the editor. However, I can't manipulate them, or even grab them once I sticked them on somewhere.

Does it work in sandbox mode? I put it in Composites, so it is in the very last tier.

Hi e-dog, with SQUAD's release of the World Cup addon, we got the new ModuleBounce module. Do you think you could create a Bouncy Procedural Shell with that? We could land on Duna like that: It doesn't have to expand like the real thing, just something that bounces (which is cool) and has a higher tolerance to lithobraking than the other parts

Thank you JDP, we really appreciate it! Great to see you're still around here! Download Docking Strut This is the original version, recompiled for 0.23.5. No changes were made to the source code. Tech tree integration has been added to the cfg. All credit goes to JDP for making this awesome plugin!

I just PM'd JDP about this issue, hopefully he allows us to re-upload it somewhere.

I thought so too...attribution wouldn't be required if I just mod it for myself. What do you guys think? Shall/may I share the plugin here?

The thing is the source code doesn't have such a restriction, it doesn't say anything about redistribution: https://github.com/JDPKSP/DockingStrut/blob/master/ModuleDockingStrut.cs One could argue that - as long as you just use the source and not the original dll from spaceport - this sentence is the only license. I did a recompile against 0.23.5 but since it doesn't explicitly allow redistribution I'm not sure if I can share it here.

Starwaster you're awesome, thanks a lot for this detailed explanation! To summarize: For maximum reflection, the heatshield vector has to point in the same direction as the velocity vector. Assuming an (unrealistic) reentry with an attitude perpendicular to the trajectory as shown in your picture (belly forward), the heatshield vector should be the yellow one in your picture for max reflection (i.e. -Z and NOT the blue one). Or in mathematical terms: the unit vector of velocity (v) is the same as the unit vector of heatshield (s) and they're the negative of the incoming heat unity vector (h): v / |v| = s / |s| = (-1) * h / |h| Did I understand you correctly?

That is kinda weird... In the DREC configs the stock MK2 Fuselage vector is (0,0,1) and for the B9 parts it is (0,0,-1). Do you think there's a bug in those configs? Personally i think the B9 configs are correct since a) i believe you and there are probably more players using B9 than stock for their spaceplanes. I updated my original post to reflect that. Of course, yes, but for balancing reasons it might be better to keep (0,0,-1) so the SPP parts aren't overpowered. What do you think?

Here's a ModuleManager CFG to add Deadly Reentry support to the space plane parts: @PART[mk2_1m_Bicoupler]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[mk2_1m_AdapterLong]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[mk2_1m_Adapter]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[mk2CargoBayL]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[mk2CargoBayS]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[mk2Cockpit_Inline]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[mk2Cockpit_Standard]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[mk2CrewCabin]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[mk2FuselageL_long]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[mk2Fuselage_LFO]:NEEDS[DeadlyReentry] { @maxTemp = 1500 MODULE { name = ModuleHeatShield direction = 0, 0, -1 reflective = 0.25 } } @PART[IntakeRadialLong]:NEEDS[DeadlyReentry] { @maxTemp = 1700 } @PART[scramAirIntake]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.25 } } @PART[wingConnector1]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.2 } } @PART[wingConnector2]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.2 } } @PART[deltaWingX]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.2 } } @PART[elevon1]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.2 } } @PART[elevon2]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.2 } } @PART[elevon3]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.2 } } @PART[wingStrake]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.2 } } @PART[structuralWing1]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.2 } } @PART[structuralWing2]:NEEDS[DeadlyReentry] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.2 } } I'm not entirely sure if the heatshield direction is correct. I did test it by creating a test attachment node (e.g. for direction = 0, 0, 1: node_stack_test = 0.0, 0.0, 1.0, 0.0, 0.0, 1.0). Anyways, you've been warned. Feel free to correct my mistakes

Just tested it...it happens to all the wings.

Yep, it "failed due to aerodynamic stresses" (i.e. FAR). I forgot to mention that it only happens while using Fraz86's FAR configs from a couple of pages back. They do seem to be sound however, the config for the delta wing looks very much the same as the official FAR config for the stock wing.

Hi Porkjet, i had a problem using FAR with your delta wing. The wing always broke off just after takeoff at a relatively shallow AoA (~5deg) and slow speed (~160m/s). The problem is you defined a node size in node_attach: [delta.cfg, line 17] node_attach = 1.25, 0.0, 0.0, 1.0, 0.0, 0.0, [B][COLOR="#FF0000"]1[/COLOR][/B] I just removed the last parameter (the stock delta wing doesn't have this set either) and it worked. Setting it to 3 also makes the wing much stronger. I'm not sure what's causing this, the default node size (at least for node_stack) is 1, setting it explicitly to 1 shouldn't change anything. Maybe FAR does it's own calculation on the strength of the connection.

While looking at the DR configs i found something odd (bug?) with the 3.75m heat shield: The 1.25m and the 2.5m shield both have 203.72 units of AblativeShielding (AS) per m2, however the 3.75m has 362 AS/m2 (a total of 4000 AS). 4000 would be a perfect match for 5m (again 203.72 AS/m2); for 3.75m the total amount of AS should be 2250. I'm not sure if this is intentional, but i thought i report it anyway

How about removing inertia? We could go from zero to c in no time at all