RaccoonTOF
-
Posts
156 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by RaccoonTOF
-
-
I have pretty extensive MM patching/general cfg editing experience (I tweak a LOT of stuff for personal use to make it more "real" already) but right now my focus is on creating realistic values/patches to parts for a full progression of the SLS, including all of the "options" which have been considered for it. If you have not gotten something together by the time I get that all finished though, I'll be happy to help out then too (and of course always happy to answer what questions I can as I peruse the forums in general
). -
Ah, I hadn't even noticed that, because I was already creating a "new" SRB type for each of the different types of boosters aside from the ones I was using to test the baseline values with - since I was changing the fuel densities as well to match various solid fuel types in real-world use
. I'm hoping to get it all refined into an actual modification to RealFuels so that you will have choices for PBAN, HTPB, as well as for non-APCP-based propellants. -
Ah...I thought that indexing was supposed to be "properly" fixed in 2.03 already. If not, that would certainly explain the failures
-
Wait...you mean...I might be able to use an ACTUAL in-game sextant for celestial navigation on my earthside vehicles? Oh boy, this just got SERIOUS...
(I find particular humour in this because in real life...I live on a 36' sailboat, and am shortly getting a new (replacement) sextant for real-world celestial navigation use as a backup to the GPS ) -
Oh it is definitely quite a feat, to do so in a fully-closed self-sustaining system, lol. The above mentioned Biosphere 2 occupied just over 3 acres of "ground" space, and enclosed over 7 million cubic feet of space, plus the huge underground diaphragms that were used to automatically maintain constant interior pressure even during heating/cooling cycles. Again, this can definitely be made smaller with a more limited (but still self-sustainable) ecosystem, but the scale for a real "greenhouse" that had absolutely no needs for any exterior input aside from a power source are beyond what could really be carried "pre-assembled" by anything you would even consider launching as a "part". It would be more like making many, many launches and assembling the "greenhouse station" - or multiple trips to construct it on-site for a ground base. Nothing with that sort of capability should be considered a "ship" at all - it really is a "mobile space station" by that point...
[EDIT: This is not to say that a hydroponics lab purely for FOOD production, to lower the resupply requirements drastically is not possible as a "part" - though it would still be a fairly large part. But it would not be a fully-closed-loop system by any stretch, and would still require ongoing supply - just much less frequently than shipping up pre-made food supplies would. No idea on what would be accurate numbers for this, as there is nothing currently equivalent in real life for supplying 100% of ongoing food requirements in space. To give an idea from an agricultural perspective though - the average person on Earth requires roughly 1,000 square feet of good agricultural land to meet their yearly nutritional requirements, while to meet the actual consumption in the US we average 1.2 acres per individual. That latter figure takes into account all cultivated land used for anything at all related to food production though - and a large portion of that is for the production of corn syrup in soda, hardly a requirement.
Hydroponics of course can be smaller systems - but require a good water reserve (even though only a portion of it actually gets "used", it needs a large reservoir that cycles) and would still require resupply of the nutrients added to that water supply on a semi-regular basis.] -
You can also use the "Interstage" adapter from the base Procedural Fairings release. Just set your extra diameter on it to a negative value, adjust base and top radius to line up with the service module, and then adjust height to match your SM. Your SM (or separate decoupler for it, but the base ring has a decouple option - just with 0 decoupler force) has to be attached at the "middle" node of the base ring for this to work, not the "top" node as they would normally be used (where the fairings support what is on "top"). I use this for exactly that reason with my "ATV-based SM" for Orion (the current plan for the Orion SM is based on the ATV rather than the original design modelled by sumghai now) in combination with the ESA pack. I'll try to get a pic up of what I mean when I get to my next round of parts testing (I'm currently working on rescaling all the new ARM parts for proper sized SLS parts in RSS).
-
Yup, I've been having issues with odd activations of second and third stage engines at launch too for some reason. I've lately been creating action groups for each stage, set to toggle all engines on that stage. This way, right after launch I can quickly shut down any random stages that got triggered by the launch too. Would be nice to know what exactly is causing this, although it appears to be independent of RO/RSS (the Taurus HCV is having the same issues with spontaneous ignition of the escape system at launch as well, but again it doesn't affect everyone...no concrete commonality determined yet).
@Aazard: A fully closed system with no venting SHOULD be a "no-loss" system actually. The only actual "loss" would be heat, which would be replaced by the "energy generation" in theory. Check out "Biosphere 2" for a real-life attempt at constructing a fully enclosed complete ecosystem covering most of the environments found here on Earth. Some technical issues with the first sealed experiment (which lasted 2 years), and management issues during the second, caused it to not be a complete success nor a completely "closed" environment (CO2 seepage from the outside and an imbalance in soil bacteria being the primary issues preventing success in the first case). However, it was a very good "proof of concept", and further research at the facility since then at various times has shown that both of those issues are easily solvable. Also, a more limited ecosystem (that wasn't trying to model all environments from arid deserts to rainforests to ocean including coral reefs to open grasslands - all simultaneously in the same structure) could potentially be a lot easier to manage in a closed-cycle aside from power input/heat radiation.
-
Yup, looks like I missed it indeed (odd, I didn't get a notification like I usually do either) The config I posted was from X0.04-2 rather than -3. I'm still just as baffled by why the @MODEL,x{} syntax isn't working too though. Assuming you actually have the 2.03 MM installed, and no other versions of the MM DLL anywhere? (1.5.6 and 1.5.7 seem to coexist alright with each other in most cases, but any of the 2.x versions seem to be back to the old system of only one allowed, period, anywhere in gamedata)
-
@Thor: What version of the FusTek pack are you using? The one I have (latest dev release linked in the thread, which is the one I thought you were talking about over in the RO thread) has the part named "KuestAirlock" and not "FusTekKuestAirlock". Double check that you have the part name correct. As for the original config, here is the relevant portion of the original for reference:
MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KuestAirlock
scale = 1.0, 1.0, 1.0
}
MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KarmonyEndRing
position = 0.0, 1.09375, 0.0
scale = 1.0, 1.0, 1.0
}
MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KarmonyEndRing
position = 0.0, -1.09375, 0.0
rotation = 0.0, 0.0, 180
scale = 1.0, 1.0, 1.0
}
// Top (Forward) Hatch
MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KarmonyHatchEVA
position = 0.0, 1, 0.0
scale = 1.0, 1.0, 1.0
}
// Bottom (Aft) Hatch
MODEL
{
model = FusTek/Station Parts Expansion/Parts/model_KarmonyHatch
position = 0.0, -1, 0.0
rotation = 0.0, 0.0, 180
scale = 1.0, 1.0, 1.0
}
rescaleFactor = 1
node_stack_bottom = 0.0, -1, 0.0, 0.0, -1.0, 0.0, 2
node_stack_top = 0.0, 1, 0.0, 0.0, 1.0, 0.0, 2 -
First page answers the first part of that Chris:
Features That Are Not PlannedShapes with 'holes' in them and concave shapes - including toroids.
As for surface attachment, that should be a pretty easy change I would think. Change the NoseCone.cfg file from
attachRules = 1,0,1,0,0
to
attachRules = 1,0,1,1,0
If you want to use surface attach as partial clipping (to somewhat replicate "flat side" or "offset" nosecones, for example) change the last 0 to a 1 as well (which allows the part to still be placed even when it is in collision with another part).
-
Yes, I used the "utilization" method myself with my old configs, taking into account the volume (packaged) of a variety of foods and food-budgets for previous RL space missions. Of course, those numbers didn't match exactly with any of the other "container" authors either
. There is more talk about the "packaged density" that food should be over in the TAC thread as well. Also, bear in mind that the caloric expenditure of astronauts during a mission is historically much higher than any of the "recommended daily values" given for general civilian use dirtside, and with very different nutrition requirements. Same issues when looking at MRE specs - they are 1200 calories each (on average) but still intended to have 3 consumed per day, minimum, for a soldier in the field in any situation where they would be eating MREs in the first place, because their expected caloric intake needs are much higher than the "average" civilian at home reading ingredient labels. Coming up with these "standards" here for realism isn't a bad idea - but they should be based on a TAC-supplied baseline value for mass AND volume, and it currently does almost nothing to provide the latter.That said, if the TAC update ends up being pushed off too far, or someone really wants something to use "right now" - you can always take the stock containers supplied in the mod (use those for a baseline reference on stats, not any of the other containers supplied by different authors), figure out how much usable space a ServiceModule tank of the same size would have, and divide that volume by the number of TAC units the equivalent container provides - that would give you a good working volume per TAC unit, which can then be converted to liters via the utilization option in the tank definition. It's clumsy, but it has worked for me in the past (I created a completely new tank type rather than using ServiceModule though, with the new resource values in the definition, and then just applied it to appropriate parts as necessary). Since the recent changes to TAC I've not updated it though, because of the good possibility that it is going to swap to using liters for units soon anyway - that's actually what got me to put my large-scale colonization efforts (fully developed self-sufficient bases on every solid planet with service stations in orbit around all, and full com/gps/mapping satellites for the entire Kerbol system was the eventual goal) in stock-Kerbin scale on hold and switch back to RSS for a while, though currently without using any life support addon
-
One unit per day definitely makes things nicer on the user end - the problem is that while we know the mass for those units, we have no idea what volume they take up. This makes creating "realistic" containers for them nearly impossible - especially in the case of food. By having them be density per day of use, rather than density per real unit of volume, every individual container-maker has been being forced to guestimate "reasonable" values (based on their own definitions of "reasonable") rather than having a universal system so that 1 unit of resource takes up x space and has y mass no matter what container type it is stored in. From the UI perspective of the user, it can still remain DISPLAYED to them in the TAC interface in "days remaining" just by having it do a conversion on "Units per time per kerbal", which itself is already a tracked and tweakable value.
-
Oh, I use the sliders already too - but KSP seems to not like leaving parts left exactly to what the slider gets set to. When you go away and then back to the part, the value seems to be changed to some seemingly arbitrary value that was just "close" to your slider setting. So I like using the .05 for the exact quarter-meter settings, and the sliders just for fine visual tweaking instead.
Also, it appears that the proper multiplier for thrustScaleFactor to be able to replicate all current/previous SRBs designed, as well as the proposed new Advanced Booster SRB option, is *7. This gives a 3.7m booster a max thrust of 20.3MN, which covers the Adv. SRB 20.01MN proposed value with a little room for leeway if the actual motor performs a bit better than ATK expects (as they tend to have a history of doing - one of the few companies in the space industry that pretty consistently under-projects performance numbers
). Unfortunately, it does NOT match for burn duration when built to proper length - a 53m surface SRB at 15.1MN thrust has a max fuel capacity to burn for 1m17s. The Shuttle SRBs of the same size and thrust burned for 2m12.5s. However, total delta-V supplied appears to be pretty close to accurate, since the KSP SRBs supply full thrust for the entire burn duration, rather than tapering off at the end of the burn.I am testing it on a Block 0 SLS mockup that I'm making, with real-life weight and size values on the core stage, tweaked main engine settings to duplicate RL, and a dummy weight payload - the SRBs were the last piece missing for accurate numbers, and now I can get to within 2-3% of accurate total dV and surface TWR values for the Core + Booster assembly combined with the projected payload capacities - so good enough for me (even though in real life, a 3% loss in dV capacity can mean the difference between a proper orbital trajectory, and a tumbling re-entry and burning up of the payload, as happened with a recent Chinese launch that had the orbital burn cut off a little bit sooner than planned
) -
Ah, excellent. I hadn't opened up the config myself, just renamed it - I thought the 2.5 multiplier was already included in the 0.9.3 version. The above should fix the issue nicely, about to go check it out. (Looking over the cfg more closely this time, I also changed the step size to 0.05 instead of 0.1, so you can still get the quarter-meter values at least).
EDIT: It's still too low, but it is a LOT better. Current max thrust for a 3.7m SRB is now 7.24MN in-game, which is indeed enough to replicate the Titan IV SRB, but still less than half that needed to replicate the space shuttle SRBs, and about 1/3 that needed for the Advanced Booster (Solid) design proposed by ATK for SLS. If I understand the math correctly now, this means I should be able to get proper values by putting ~4.6 into that multiplier, so I'll go test that now
-
I had a set of FusTek configs for TAC, but they are outdated now with the updates to both. And I'm really hoping that TAC is going to change to using liters for their units in the next version as has been discussed (rather than "kerbal-days") so I've not updated them yet. Could probably do so if the TAC update gets pushed off too much longer though.
-
From nasaspaceflight: "The deployable extension is connected in one piece, but it consists of two parts (called the "B-cone" and "C-cone"). A third nozzle extension (called the "A-cone") is fixed to the main nozzle. The fixed versus extended division point is seen as the broad black band in the attached image."
And a pic with good working dimensions:
Hope these help, I'd love to have an accurate RL10 with deployable nozzle for many purposes in RSS
Oh...and here's another one with it retracted and mounted:
-
Yes, I'm using the entire RO suggested modlist (including RealFuels), and about 2 dozen others besides (active texture management is my dearest friend
). The numbers above were with 0.9.3 of PP installed, with the config changed from "notused" already. I have similar "unreal" issues with the secondary standard kerbin install that I also have though, though I didn't check exact numbers there. I know that they are of course lower due to the significantly smaller scale, but even trying to model them "performance-wise" rather than "realistic numbers for thrust- and weight-wise" they still fall very short (so do the stock SRBs in the game of course, but I would hope that the ones in PP are at least capability-wise useful in the same sorts of situations one would use SRBs in real life - and right now they are not, they are almost purely for looks.)As for the dry density of tanks - it is dependent on TWO things: the tank class, AND the actual tanks installed. The tank(part) type determines the basemass per tank(part) volume, and the resource within the tank(module) determines the tankage mass for the tank(module) actually chosen. The "default" tank type is 0.000625 tons per total liters of tank volume, while RCS tanks have a base mass of 0.0016 tons per total liters of tank volume. This is without ANY resources added to the tanks, it is the base mass for the empty part itself. (In RealFuels these numbers are 0.000011 tons per liter total volume for the default type, and RCS is 0.0004 ton per liter volume - stock tanks really have WAY too much of their mass in the structural part of the tanks compared to real life tank weights).
EDIT: Oh, and with neither Modular Fuel Tanks NOR RealFuels installed, just using PP, they are different as well - dryDensity for Liquid tanks is .1089 t/kL and for RCS tanks is 0.22 t/kL. He already had said that he had MFT installed though, so those were the first numbers I checked
-
Er, yes, I keep forgetting that people DO actually use those parts as root parts sometimes
The only one of the Fustek ones that I've ever used as a root part (aside from quick-viewing stats on them) was the new resupply module, since it is effectively an ATV in FusTek style That said, I suppose I should go re-adjust the core stage scaling just in case someone wants to use it for root as well, lol... [EDIT: the reason why I usually use rescaleFactor on multiple model parts unless it is intended to be a root, is because it handles the position and node placement much easier. But that's been for my personal use almost exclusively so far, so I feel safe doing so because I know what parts I don't/won't ever use as a root part myself. Gotta remember there is always someone out there who will make the most insensibly assembled designs, and then complain when it breaks...] -
@K3|Chris: The reason they are separate parts is because the tankage mass for RCS tanks is a different weight than normal fuel tanks per volume. This is especially true for the extra tank types you get with Modular Fuel Tanks or Real Fuels. There are some issues with Modular Fuel Tanks if you are not running the correct version of MM, make sure you are using the latest version in the mod packs you have installed, rather than the most recent dev release version of it. Also make sure you ARE running the most recent PP DLL, which I dunno if the first post has been updated to include the one just posted a few pages back or not yet.
@swamp: SRB's max allowable thrust to diameter still appears to be off by nearly an order of magnitude for replicating real-world SRBs. Very obvious example that fails: a 3.75m diameter surface-optimized SRB has a max thrust of 2975 kN. The Space Shuttle 5-section SRBs (3.71m diameter) have a real world liftoff thrust of between 14,012kN and 15,617kN depending on time period. And the proposed Advanced Rocket Booster SRB design has a projected 20,015 kN in the same diameter. Are you sure that you aren't calculating the max allowable values in tons-force instead of kN in the math for the code? 15,617kN is 1,592 ton-force, which would fall right in the range being set for the SRBs in game
-
@Nathan re: Core Stage - What I have done right now is to set the total volume to the total available volume for the tank part, with the prefilled default tank values, pretty much as you had suggested there. The main issue is with the masses - there is no way to add the mass to the interstage part, because presumably people will be using procedural fairings or similar for that part (the interstage depends on the choice of second stage/payload). I could theoretically take that approach if I were to make new parts for all of the possible options, but that would be well beyond just a MM config then. And seeing as how there is already a very nice looking "true" SLS mod in the works, I think that'd be pretty redundant - my goal right now is just to get the stock parts to be accurate for what they were intended to be in the first place, adapted to RSS/RO and a few other tweaks to existing engines when there are multiple models already available for that engine. I have left the "tank mass" portion out entirely though, letting it be calculated by RealFuels created tanks, or the default tanks included in the config, while setting the part mass (with basemass=-1) to be the "dry" mass of the entire stage minus the engine block (since it IS a separate part already). End result is basically - you'll have flexibility in your tankage and the mass for it will be accurate, but if you choose to use the core stage as JUST a tank for something else, you'll have a different mass value for doing so than if you just made a procedural of the same size.
@ThorBeorn: If you are not doing rescaling in individual dimensions separately, it is much easier to rescale purely using rescaleFactor = X and setting your scale within the MODEL{} section to be (original scale/X). (In most cases "original scale" will be 1, and I believe that is the case with all of sumghai's parts, but double check them to be sure). That way all of your nodes SHOULD get adjusted as well by the same proportions, without running into the bug that applies rescaleFactor twice.
If you are having to rescale any parts in one dimension by a different value than in the other dimensions, it gets quite a bit trickier. I'm not sure if that applies to any of the FusTek parts with the new models, I don't think it does, but if so lemme know and I can try to do a more in-depth explanation of the math needed then (I had to do exactly that to rescale the core stage tank, since it required a significantly larger rescale in the vertical than in the diameter).
EDIT: Also, you are adding just "scale=1.6, 1.6, 1.6" to the MODEL node - you need that to be a "%scale=1.6, 1.6, 1.6" or else it might create a duplicate scale value within the node (on any parts that already have a scale value), which could do very strange and unpredictable things
And finally, another teaser. Block 1A Crew version with one of the ICPS variant possibilities and the solid boosters. I've also added a bottom node to the main engine section, spaced to allow adding the existing single RS-25D engine to it, for if anyone wants to run the 5-engine variant that was in the early planning ideas.
-
Odd bug occuring with the latest version of PP. Take a procedural tank. Stack-attach a normal tank to one attach node (or any other part that is capable of both stack and surface attach). Pick up the part you just attached, then reattach it via surface attach to the procedural tank. Now pick it up again, and reattach it to the procedural tank via stack attach. Result is that the part gets attached via its center (I believe CoM) to the procedural tank node, instead of node to node. Can be kinda handy for hiding some engines inside of the procedural tanks (if the engine allows surface attaching in the first place), but definitely seems to be a bug. The only way to get proper node-to-node attachment back is to remove the part and replace it with a fresh one - no amount of moving it around and then back will resolve it.
-
Ya I'm aware that the "fuel tanks" are not fully utilizing the space, due to the internal tanks and such. But if you look at the numbers I put up a little closer, you'll see that the new stock tanks are actually giving even MORE fuel tank volume than the entire volume of the cylinder that they are contained in. Even if they were purely fuel bladders, they shouldn't have that much volume
I am working "backwards" from the SLS specs, but I only have stats for the entire stage weights and propellent weights, but there is still a fair amount of "empty" volume in even the Block 0 Core (because of how they are reusing bits from the shuttle ET, the "intertank" section is a lot more wasted volume than it would need to be for a stage built from scratch.) So ya, I can give accurate numbers to duplicate the SLS itself, I just wasn't sure how to then give an accurate volume for people to use for RealFuels if they wanted to use the monolithic tank visually but for some other tank arrangement (which would be "empty" non-tank volume for the base version). The "stretched" Core Stage has a lower proportion of "wasted" space as well, because the entire length of the "stretch" is usable tank space.
As for the N-1, the NK-15 was used for the early ones, but the NK-33 (which was based heavily on the NK-15, it was almost the same engine) was used for the later tests (along with the NK-43, which is just an NK-33 adapted for better vacuum performance). So yes, while the N-1F never actually "flew" prior to cancellation, the NK-33 was definitely built for the N-1 project and assembled into a launch vehicle prior to cancellation.
ThorBeorn: The issue with the new Fustek parts is that he has split up the various elements (core, hatches, ports, etc) into different model assets, to save on space/memory and allow textures to be easily reused between the new parts. I looked at them when I first fired up RO, as I love using them in my stock Kerbin game, but it'd be a lot of work going through and rearranging all the different nodes to be in the right places. And since those locations have been changing with every few dev release versions anyway, I figured I'd just wait till the dev version gets finalized and released as an official next version prior to updating the cfg for RO.
-
There are two versions of the NK-33 in RealEngines, one in the KOSMOS pack and one from Bobcat's Soviet engine pack. Are there any concerns with me redoing the stats of the one in the KOSMOS pack (it fits the sizing best) for the Aerojet booster option? It is supposed to be using 4x uprated AJ-26 (the Aerojet designation for their version of the NK-33) engines, designated the AJ-26-500, per booster. This still leaves the Bobcat version with the original stats, for those who want to try to build something else which uses the NK-33 (like an N-1 perhaps?).
Teaser Pics: Block 1A Mockup and Test Flight (Prior to redoing the new stock tanks):
Aerojet Advanced Rocket Boosters Closeup
Block 1A with delta-V stats
Pretty day to go to space
And...we're off!
Orion deployed (released prior to proper circularization as I was mainly testing staging)
Also note that this is a mockup of the ATV-based Orion SM.
Safe recovery.
-
Yup, that was my general thought on it too. And they are already the correct "style" for it visually of course, which is the only time I really use non-stretchy tanks in the first place anymore
EDIT: Well, in beginning to sort out the proper rescales (since they are different rescale factors in height and in diameter) I also discovered that apparently the volumes of the "stock" parts are about double what they should be for RealFuels tankage? I'm assuming that the part volume is still being measured in liters. The S3-3600 tank measures 3.75m dia by 1.875m tall, with a tank volume in RealFuels showing as 36,000 (which kinda makes sense considering the part name). However, a stretchy tank of the same size gives an available volume of 17,969 and the actual volume of a cylinder of those dimensions (assuming 100% use, no wall thickness or tank "wasted" space) is 20,709L. I'm thinking this might be a large part of why people consider the new parts to be OP, even aside from the engine specs - the new tanks are holding twice as much fuel as they should be able to. Where can I find the information for RealFuels/Procedural Parts that determines the "proper" volume/base weight formulas that it uses? I need to figure out how much "RealFuels volume" to assign, and appropriate amount of base weight to subtract from the real life totals, to allow duplicating the same tankage as will be available to the real SLS while still allowing the RealFuels flexibility in tankage... (though I suppose I could just use a basemass value of -1 and assign the tanks to be fixed for the SLS replication, that would lessen the customizability of the new tanks to be used for other stuff as well).
Second EDIT: The other fixed-size tanks appear to have the usable volumes closely matching the actual volume of a cylinder of the same size, so it appears that it is just the new stock tanks that are magically doubled in storage compared to their actual volume...I bet NASA would LOVE to have some of those IRL
).
(I find particular humour in this because in real life...I live on a 36' sailboat, and am shortly getting a new (replacement) sextant for real-world celestial navigation use as a backup to the GPS 
[1.1.2]Aerojet Kerbodyne 3.0 (4/29/16 Better FX, still good for 1.1.2)
in KSP1 Mod Releases
Posted
The directions I was giving were for in-game assembly of the craft, not for any modding needed
The interstage procedural fairing has 3 "stack" nodes on it - in most cases, you have the stage below it attached to the bottom node, and the engine/payload attached to the top node, with the middle one unused. This way the fairing walls support the stage above it while shrouding any lower protrusions (like engine nozzles) from aerodynamic effects. However, you can also mount something (like a service module) on the "middle" stack node as well. Unlike a "normal" procedural fairing, the interstage fairing won't extend all the way to the top of your craft and shroud the whole thing when you do this - it only extends up to the height you set it to. The settings I listed are for the various dimensions of the adapter part itself, prior to adding the sides. Sorry I've not gotten pics yet, having a few loading issues currently due to some texture issues 
Although, as you mention, it won't help if you don't have the interstage adapter itself unlocked yet in career mode (I don't recall what tech it unlocks with, but once unlocked it can be used for any base size IIRC - it doesn't have say, 1.25, 2.5, 3.75 etc versions, just one that can be resized as needed.)
[EDIT: And I believe the base works identically whether you get it from PF or from blackheart's pack, the only difference is the choice of fairing walls that get attached to it]