RaccoonTOF
-
Posts
156 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by RaccoonTOF
-
-
Question for those interested in SLS parts. I've got a lot of good information for measurements of the various sections, which I'm tempted to apply to the stock 3.75m tanks. I figure that most people are using procedural tanks for the majority of their custom stuff, so should I go ahead and make "fixed size" configs for the stock 3.75m tanks to match them up with the different sections on the SLS? Or leave them as-is, and just let people create procedural tanks of the appropriate diameters and lengths?
(Note: the "second stage tank" length listed is actually the whole second stage length prior to the taper above it - I was just using a procedural tank of that length total as a mock-up for sizing other parts
)
Sections in orange are repurposed ET sections from the Shuttle main tank, using the Super Lightweight Tank specifications. Sections in white are reinforced structural areas, auxiliary tanks, or areas with other systems internally (I've been using Service Module tanks to mock up those sections for trials). My thought if I do a conversion of the stock pieces is to have the entire Block I Core tank length be one part, in addition to the main engine cluster and the decoupler for the second stage. Then repurpose the other two tanks to model the "Stretch" section for Block II, as well as the second stage cryo tank for the EDS.
-
*chuckles* Glad you are doing the Aerojet parts, that was going to be my next project. I also looked at the Taurus as well, I think it can be tweaked to work for the Orion capsule, although for now I've just been using the stock 3-man pod for my Orion with the SDHI and Aerojet parts
[EDIT: in my stock kerbal install that is, which is what prompted the whole rescale and reconfig in RSS for me in the first place ] -
Uh...doh! Yes, all the SLS info that I have here for reference has the main engines and the boosters rated in SL thrust, and the various second stage and Orion engines rated in vac thrust. Totally didn't catch that before
Will fix that now (Actually, the 2278 figure is for the 109% throttle "emergency power" setting, so I may still go with the 104% throttle value of 2174, which was the max standard operating throttle for the Shuttle. Then again, the -E variant is meant to be disposable, so the "extra wear" from the 109% throttle setting is probably acceptable too. Would keep them all in line with each other for performance then...)Also, I tracked down the section that is causing the issue at least - it's the SmarterGimbal module. When I comment out the entire gimbal section from the MM file, it loads fine. It ALSO loads fine if I input the SmarterGimbal settings directly into the original part.cfg file. It only doesn't work when I try to change that module through MM...
[EDIT: This also means that the issue I am having with the stretchy SRB nozzle size to thrust ratio is even WORSE than I thought it was. I was having difficulties already using the SL thrust values for them, resulting in nearly 9m diameter SRBs...it's gonna be even worse after I figure out what the vac thrust for them should be...]
-
The actual thrust for a single RS-25D is 1817.4kN. And the figures for the quad-mount RS-25E is 7440kN (which he has at 9115kN for the RS-25D quad-mount). Unless I am missing something with how RF treats the thrust numbers here?
EDIT: Also, adding the type = ModuleEnginesFX did not fix the problem, same issues as before. Double checked that I only have one MM DLL in Gamedata. Will pull the output log next.
-
I did look at his RS-25 specs, but they don't appear to match up with any of the specs I've found for the actual engine (his max thrust in particular is MUCH higher than even the 109% throttle setting for the real SSME, though the ISP numbers are very close). I'll take a look at the way he does the throttling though, forgot to look at that part
As for the !NODE{} I'd already commented that out when I realized that the original part.cfg didn't have one, but apparently didn't update the post above when I did so I'll go try adding the "type = ModuleEnginesFX" now and see how that works, then check the throttling stuff.EDIT: After looking at his numbers again, it appears that his thrust is so high because his mass is much higher than the actual engine + thrust plate combo too. His T/W ratio comes out accurate, but the total thrust is very high to compensate for his "overweight" engines
-
Ok, I'm running into an odd issue I've not seen before. After having done the first config for the RS-25E (four) cluster for the Core stage main engine block (and prior to adding the fuel tanks to the part), all the values show up properly in the VAB "more info" section, but when actually attaching it to a rocket it does not appear to be being recognized as an engine at all (no staging icon, no RealFuels dialog, etc). Here is the MM config that I worked up with a combination of your spreadsheet and some manual editing for the rescaling and such.
@PART[Size3EngineCluster]:Final
{
%title = RS-25 (Four)
%manufacturer = Rocketdyne
%description = Expendable version of the SSME (RS-25) intended for SLS Block I/II Core Stage propulsion.
%rescaleFactor = 2.2333
!NODE {}
%node_stack_top = 0.0,1.527248,0.0 , 0.0, 1.0, 0.0, 8
%attachRules = 1,0,1,1,0
%crashTolerance = 20
%breakingForce = 8304
%breakingTorque = 8304
@mass = 12.798
@maxTemp = 2400
@MODULE[ModuleEnginesFX]
{
@minThrust = 7440
@maxThrust = 7440
@heatProduction = 162
@fxOffset = 0, 0, 0.558325
!PROPELLANT[LiquidFuel] {}
!PROPELLANT[Oxidizer] {}
PROPELLANT
{
name = LiquidH2
ratio = 72.856139
DrawGauge = True
}
PROPELLANT
{
name = LiquidOxygen
ratio = 27.143861
}
@atmosphereCurve
{
@key,0 = 0 452
@key,1 = 1 363
}
}
@MODULE[ModuleGimbal]
{
@name = SmarterGimbal
%gimbalRange = 1
%gimbalResponseSpeed = 7.46271439024869
%useGimbalResponseSpeed = true
}
!MODULE[ModuleEngineConfigs] {}
MODULE
{
name = ModuleEngineConfigs
techLevel = 7
origTechLevel = 7
engineType = L+
origMass = 12.798
configuration = LiquidH2+LiquidOxygen
modded = false
CONFIG
{
name = LiquidH2+LiquidOxygen
maxThrust = 7440
heatProduction = 162
PROPELLANT
{
name = LiquidH2
ratio = 0.72856139
DrawGauge = True
}
PROPELLANT
{
name = LiquidOxygen
ratio = 0.27143861
}
IspSL = 1.234519
IspV = 1.3026
throttle = 0.75
ModuleEngineIgnitor
{
name = ModuleEngineIgnitor
ignitionsAvailable = -4
autoIgnitionTemperature = 800
ignitorType = Electric
useUllageSimulation = true
IGNITOR_RESOURCE
{
name = ElectricCharge
amount = 99.2
}
}
}
}
!MODULE[ModuleEngineIgnitor] {}
MODULE
{
name = ModuleEngineIgnitor
ignitionsAvailable = 3
autoIgnitionTemperature = 800
ignitorType = Electric
useUllageSimulation = true
IGNITOR_RESOURCE
{
name = ElectricCharge
amount = 99.2
}
}
}Also, what value do I need to insert to set the minimum throttle value to 67% like the real engines?
EDIT: I got the engine ignitor values using your spreadsheet, and decided that a "3 ignition" option for them seemed reasonable - the RS-25D are rated for 10 restarts prior to servicing, I figured that since the "disposable" E versions are not going to be built as robustly (and at least one of the second stage options is specifically intended to use a restartable variant) that 3 for the main cluster and 5 for the second-stage version seemed reasonable.
Second EDIT: Also, the attached TANKS recognize it as an engine, and allow me to select the proper fuel mixture to fill them with, I just have no engine-related interfaces for the part itself...
Third EDIT: When I went to attempt to launch, to see if I had engine controls there, it also fell through the pad with no collision at all...I'm just getting more confused here
Fourth! EDIT: It definitely appears to be an issue with MM somehow. When I add all of the above in manually to the original part config, it works fine in game. So...what am I missing to make it work for MM?
-
I'm still quite hazy on Engine Ignitor customizing myself, so I won't be able to add those portions to the SLS engines, but I can do up some configs to set them to the proper real-life diameters, thrust values, ISP, etc. I also need to figure out how the nozzle thrust factor works on the procedurals SRBs, so that I can actually properly replicate the thrust values of the SS-SRB for the Block 0, as well as the proposed "uprated" versions for the Block I/II SRB option (for those that want the choice between the SRB and the LF versions). Will see what I can put together in the next couple days, and then PM you with the configs, so you can finish up any additional tweaks you want to make them fit with the rest of the update and incorporate the EI code.
-
Has Jack's RealEngines been updated to update the stats on the new ARM engines yet? I've searched around but been unable to find any update past 0.6, which does not include them. I'm working on building a series of SLS launch systems, starting at Block 0 and working up to the full Block II with complete EDS, but not having proper booster options and main engine stats is making it quite a challenge (at least if trying to keep the physical dimensions close to the same...). I've no issue with having to create a couple config files myself, I just wanted to see if it had already been updated prior to my doing so.
-
Just a balance comment here: Having the bell size (and required part diameter) increase with increased thrust for SRBs is great - but having it be a linear relationship is not so much. In trying to replicate the Space Shuttle SRB, it fails badly. Admittedly, these are the "most powerful" SRBs made to date, especially if trying to replicated the "uprated" versions proposed for the SLS - but they are still way out of proportion even given that. The original SRBs generated 12,000 kN in a 3.71m diameter booster, the "uprated" ones proposed for the SLS generate just over 16,000kN in the same diameter. To get the same results using procedural SRBs requires a nearly 9m diameter booster. Burn time for volume seems about accurate, but really we should be seeing higher thrust out of smaller diameters, and longer burn time using longer boosters, rather than requiring short and stubby boosters to match the same performance numbers.
-
Davjet, I was having the same problem and tracked it down to using KSP Mod Admin to launch. You can still use KSPMA for installing and managing mods, but it appears that the old bug with ModuleManager from KSPMA is affecting the RSS configs, even though it handles the rest of the MM configs fine now. Just use the main KSP.exe to actually start the game, and you should be fine. (If you aren't using KSPMA, then I'm afraid I can't help much...other than suspecting it is some other ModuleManager-related conflict).
-
The updated DLL's fixed my inability to resize or change textures, but I've lost all tank types except for the standard "liquid fuel" and "monopropellant" types. Other types of tanks previously launched still appear to be on the ships they launched on (at least my station in Kerbostationary orbit hasn't lost its procedural service module tanks), but I cannot add any to new ships in the VAB.
EDIT: It appears that the new DLLs are not detecting RealFuels as being installed anymore. All of the missing tank types are the ones that are in the RealFuels subfolder...
-
Good to hear! I think I finally sorted out all of the "new-pc-teething-pains" that I always get with a new system, especially with a new OS (First PC with 8.1 on it...probably the biggest "learning curve" jump I've had setting things up since NT 3.51, lol). And now of course I have to go and re-track-down all of the updated addons for .23
.Aazard: I hope I remember you being the one with the "rover problems" - this appears to be an issue in RSS with the visual surface and the mesh surface not aligning quite accurately (It occurs on Kerbin too for me, especially the area directly north of the runway). My solution has been to build much wider-stanced rovers than usual, with as low a CoM as possible (hint, if you have lander/rover combos, have the descent stage fuel on the upper part of the rocket, and ascent stage fuel on the lower part - takes some funky plumbing sometimes, but helps with CoM greatly) and be sure to include a good RELIABLE and STURDY flip/roll recovery mechanism. In fact, having "outrigger" landing legs arranged so that they will "float" just above the surface without hitting the smaller obstacles, but providing "sliding" stability for larger dips/turns helps a lot here too, and can then also be used as one "half" of your anti-flip/recovery setup as well. I can get a good design going 20-30m/s over even the nastiest terrain around KSC, in full-control-extent turns without flipping in this manner - especially if you position a couple of structural elements directly in front (with nothing else attached to them) positioned so that in case you do crash hard into something "unseen", they can act as a bumper/"emergency ablative armor" in the worst cases
. Control is still kinda skid-prone, and you do still get tossed into the air at some apparently random moments, but if designed in this way at least it shouldn't be fatal to the rover or rover/lander primary systems... -
With the texture compressor especially, you can actually have a lot of additional mods above those listed for this mod/tree actually. Just as an example, I'm able to run with B9 (reduced textures version) and Firespitter installed as well (both fairly large mods), high-res universe replacer mods, visual enhancements (city lights and clouds), plus a dozen or so additional medium-sized mods and a host of smaller mods. However, without using it and/or the compression packs, it does indeed tend to cap out the memory limits of the Unity engine with just the "essential" mods listed here.
-
@Rjhere: Most likely you are running into the memory limitations of the Unity engine. Are you using the texture reduction mod, and/or the reduced texture size versions of the larger mod packs? I had the same issues as you (game loaded fine, but crashed when trying to actually add a part in the VAB) until I did this. This is assuming that the issue occurs with pretty much any part, and not just one or two specific ones...
-
I realize that the "stock" info readout automatically decides the units based on the cfg info - however, you can add any information you want into a part's description field. That was how I modified my own versions to display them all in "per minute". Basically, I still had to do all the usual math...but I only had to do it once
. The problem is that I'd have to go and re-do it - or at least re-check it - with every update, as I don't know myself what if any changes are made to the parts themselves on each update. However, it's a very easy thing to add/update while already making changes, which is why I suggested it be included with the mod as distributed...EDIT: Actually, more use of the description/info fields in general would be handy for all of the non-standard stuff as well. Like probe experiment info (data costs, situation requirements) and other such things, particularly for parts which are visually identical to stock parts or another custom part. Would save having to mount the part, go through all the action group options, realize it wasn't the one you wanted, swap it out...repeat...etc. For that matter, since you have the plugin already to support them, that info could all be added into the info section itself, since you wouldn't be limited to just the description field changes then, and it could be automagically updated when values were changed in the cfg files
. -
@Aazard - what you want to be looking for is basic trigonometry functions. In this particular case, what would be most useful for you is the Law of Cosines, to find the "third" side of the triangle with two known sides and one known angle (a "SAS triangle solution").
In this particular case, assuming that both orbits were at the same altitude from the CENTER of the planet (will use 20,000 km orbit altitude as example, it works for any length, even if the two altitudes are different.) The altitude from center of the planet is simply the altitude of the orbit + the radius of the planet (6371km for earth, I think this is the same for Kearth in RSS). This would give 26,371km for your altitude from center. Also assuming that the angle between them is exactly 120 degrees (though in reality it is easier to go for longer-range antennas than to get EXACT positioning on your geosynch sat network
).c^2 = a^2 + b^2 - 2ab cos©
c is the length you want to find - the distance between the two sats. a^2 and b^2 will be identical in this case (26,371^2=695,429,641). C is the angle separating the two sats, in this case 120. cos© = -0.5 Plugging these in, we have:
c^2 = 695,429,641 + 695,429,641 - 2(26,371*26,371)(-0.5)
c^2 = 1,390,859,282 - (-695429641)
c^2 = 1,390,859,282 + 695429641
c^2 = 2,086,288,923
c ~= 45,676km
So you would really need to have a Comm32 antenna to be able to do this with only 3 satellites and an orbital altitude of 20Mm. However, you CAN do it with the C16 still just by using more satellites. To compensate for inaccuracies in exact separation angles, and make positioning simplest, I generally use 8 small satellites separated by roughly 45 degrees each if I'm putting up a "quick and dirty" comsat network using only short-range antennas. I also don't generally bother to put them all the way up to 20Mm, usually about half of that, but they would still have the range to do so if you wanted to.
@MedievalNerd - Sorry for the lack of posting re: the aviation side of things I said I would work on. Lost net access shortly after my last post and just got it back today (dunno if I've mentioned it before, but I live on a 30' sailboat - had a storm come through here which took out power on the island, and trashed the wifi connection at the marina, I just got it all fixed for them this afternoon
). Good news is that now I've also got the new computer to use as well. I'm currently in the process of doing a fresh install of KSP and the mods as listed in the first post (I'll be sticking with TAC instead of ECLSS though - I like the constant tracking of power in ECLSS, but I like the versatility and performance of TAC and the integration it has with some other mods better). Couple of things to note that I saw mentioned over the past couple of pages: The lack of the tree staying saved when using Treeedit is a problem with how it handles the F5 saving of the tech tree. It never STOPS listening for F5 input...even when you leave the tech screen. So if, for example, you use F5 to quicksave in flight, it will save all of the "current nodes" to your tree.cfg file. And since you are in flight, not at the tech center, there aren't any "current nodes", thus resulting in a blank tree.cfg file, thus reverting it back to stock until you reload the tree again. Hopefully this will be fixed if TreeEdit actually starts getting updates again, but in the meantime there is a work around for it: Create your new campaign save and select RPL from the TreeEdit menu as normal. Hit F5 in the tech screen to save it to the current savegame. EXIT KSP without doing anything else. Now you have a "stock RPL" tree.cfg file in that campaign save folder. Copy that tree.cfg file into whatever save you want to play (or leave it where it is if this is the first save for you...). Now REMOVE TreeEdit.dll and use TreeLoader.dll instead (this does not have the editing/saving functionality, so does not have the F5 bug of course. It also keeps the tech screen cleaner without having the edit window to have to move out of the way...). Since TreeLoader will not search for a new tech tree online if a tree.cfg file already exists for that save, it will load the existing tree.cfg just fine (and can even be used offline since it doesn't need to connect to get the list of tech trees
). This can also be used to "publish" your tech tree "publicly" by the way, without needing the user to have TreeEdit - it just requires the user to have TreeLoader installed, and to manually move the tree.cfg file (supplied by you, downloaded by them in the distribution package) into their savegame folder prior to use.Probes/Science: I assume that this was what you were talking about with the v18a issues on probes, but I'll point it out here in case it was not - your custom experiments in v18a (I've not downloaded v18b yet since the last copy I had before losing net access was v18a) are missing TargetSituation masks for the Mun and all later experiments (they just have the target body specified). This is what causes the calibration error reading showing that the experiment is calibrated for ", ,", and prevents the proper execution of the experiments. Also, the Duna and Eve experiments had the target bodies set incorrectly, but I don't remember how they were messed up right now...I already fixed them in my copy. Might want to double check those as well (or I'll check after I finish getting the new install done on the new computer
).General Aviation Tree Stuff: The suggested node separation that was made above was basically how I was planning to divide up the parts myself as well. Basic flight would be a node off of the start node which would give access to the MkI bodies and cockpit, the most basic stock wing, the small control surface, and the AV-T1 fin/winglet. I planned on using 2 stock/jet engine nodes, 3 nodes for FireSpitter and B9 special engines (props, electric engines, and the SABRE engine which could also include other mods late-tech multipurpose atmospheric engines), and only 4 aerodynamics nodes (basic lifting surfaces, which would include all fins that don't have control surfaces + the basic wings; basic control surfaces, which would include all of the fins with built in control surfaces (like the Delta-Deluxe) as well as the stock large control surface and the simplest of the add-on control surfaces; advanced aerodynamic surfaces, which would include all of the remaining fins and control surfaces that are wholly moveable (like the AV-R8) as well as the various canards and the more advanced control surfaces from the add-ons, plus all remaining general wings; and the last node would include any special-purpose or advanced wing/lifting/control surfaces (like the extra-heavy lifter wing, or procedural wings, or the slotted fighter wing from Firespitter). Finally, the fuselage section would have a node chain with nodes for each successively larger "size" category (each node would include the associated cockpits, cargo bays, adapters, etc. appropriate for that size - except that adapters would be placed with the LARGEST size that they could adapt to - like the MkII tail piece that has two 1.25m engine mounting points would be placed in the same node as the fuselages that are roughly 2.5m size. Alternatively, these various fuselages/adapters/etc could just be fit into your existing rocketry scheme without being part of a separate aviation tree section, but that might cause balance issues, especially for the cockpits...
EDIT: One other general suggestion that I had for the mod as a whole - It would be really helpful to have the units of measure which are displayed on various things with ranges or power and the like to be standardized. It's pretty simple math to do the conversions ourselves but picking one standard multiple and displaying the appropriate decimal values in the description would make things a lot easier when - for example - creating comm sats...rather than having to take the pod energy usage in per minute or sometimes per hour values, the panel outputs in per minute, the antennas energy usage in per second, and so on and converting them all to a single base unit to figure out how many panels I need to power 2 pods and 4 different antennas...and then converting that to sat usage per hour to determine how much battery capacity I need to carry with me
. I already tweaked all of the descriptions in my previous install to make everything reference "per minute", but would be nice to have this included in the basic mod pack install. -
Just a note for your combined install pack (going about setting up a separate install for RSS and this mod, will be attempting to run it all on this PC but if not at least it will be all set to directly copy over to the new one when it arrives) - your tweak pack readme still references the RT2 folder that needs to be copied and deleted. This doesn't exist in the current version of the pack, due to you changing the way you handled the RT2 tweaks
-
Have you done the stock science missions for all of Kerbin's biomes?
-
MM tweak files get overwritten by tech trees btw. It sort of works for Tree Edit, but messes up with Tree loader. So I'd have to have all of them loaded and save the tree, then I could remove them as I wouldn't be using them myself. Also, engines which aren't part of the rebalance will definitely through the balance off of the tree/progression.
B9 isn't just wings and control surfaces from what I understand.
MM tweak files work fine for parts which are not specifically assigned in the tree - that's how I've been using a LOT of the mods that I have which are not supported in various trees. The trick is that they have to be assigned to a node (in the MM cfg tweak) which actually exists in the tree. This works great for trees where the stock nodes are just moved in location/cost but still have the same basic purpose, but less well for trees like yours where the stock nodes are almost completely repurposed. Thus why I had to make a set of MM config files for B9 and Firespitter (and a few other choice mods) specifically designed to work with your tree.
However, the most reliable method is indeed to do as you suggest, load the mods yourself prior to final save of the tree, save the tree, then remove the mods if you don't want to continue using them. Shouldn't be too much of a concern though if you are willing to do that extra step, as you can load in 1/4 res just for the editor save which should leave you plenty of memory still. Alternatively, you could just have a separate "TreeEdit Building Install" install of KSP entirely, separate from your "Personal Play" install (which could also be useful for testing the mod from the perspective of an end user too
).As for the balance issues themselves, both of those mods packs do install additional engines, RCS, etc. which is why I said that the one(s) you chose would change the way that the tree would have to be balanced (or end up with "empty" nodes in some cases, like without Firespitter you would have no need for a notional Piston Propeller Engines node
) However, they should not throw off the balance of the current parts for the rocketry side of things with a few very minor exceptions which could just be added to the current appropriate nodes (like the larger fuselages which can carry rocket fuel would be placed in the appropriate node on the rocketry side of things, instead of in the aviation branch of the tree - which would only have the fuel tanks for jet fuel. And yes, even with MFSC installed, the different fuselages are "intelligent" and the "Jet Fuel" tanks/fuselages can't hold any of the oxidizers ) The one exception to this that comes to mind off the top of my head is the SABRE engine, especially in its current incarnation where it is more vacuum efficient than the previous versions of the mod. If it would be possible to have your currently proposed shuttle node or something similar also have a rocketry requirement (might be hard with the current tree organization) then this could be solved that way - or it could just be assumed that by the time someone has the highest tier of rocketry research then they can be given semi-"free" jet technology just for that engine only and make it fit into your existing tree structure.The only potential balance issue would be if someone was really focused on building an SSTO from the very beginning, and spent an extensive amount of time/science towards getting the upper end air-breathing engines, cockpits, aerodynamic surfaces, and fuselages and stuck with low-end rockets for orbital maneuvers with "narrow" tanks. This might change a bit of the balance around but personally (having tried similar in a different tree that separates the aviation and rocketry branches) it is EXTREMELY hard to do well without the other "normal" rocketry advances and structural advances, and honestly if someone chooses to put in the extra effort required to do so I think it's a perfectly reasonable "alternate" route to space for them to be "allowed" to pursue. But that is of course your choice as the developer of the mod
.I'll work on two sets of "tech sets" for you, one which includes a listing with just stock/NP/KW (which I'm going to install again at least to get the parts in the right places for you) - and one which is designed to be used with the above + firespitter and b9 (as I think most aviation enthusiasts - like myself - will likely have both of those packs installed rather than just one or the other). Then you can choose which one you want to use and which one not as you like (and if you stick with just the stock+NP+KW set I can just keep using my current MM tweak files modified slightly for the new node names/locations).
EDIT: BTW, there is one other balance issue that comes to mind, but it's entirely tech-tree independent and has more to do with FAR - B9 and Firespitter both give MUCH better control surface options available for use as rocket fins than having to use a dozen or so of the stock canards/winglets. That's actually what prompted me to install B9 in the first place, was to get the new winglets and other control surface systems integrated in the wings for use with FAR, since my performance limitations are primarily part-count related rather than memory-footprint related issues. So with either of those packs installed people would have the ability to use larger lifting surfaces with integrated controls as rocket fins, which does have a slight actual performance advantage on very large rockets in terms of weight and dV numbers for launch as well - but even then, the difference is only 50-100 m/s dV savings from the slightly added lift for less weight than just using stock controls and that only really applies to the very large rockets which would otherwise be using 12-20 of the smaller stock control surfaces instead.
-
I don't have KW installed myself, but I'd be happy to do the listing for the stock and NP parts. And if you are only looking for a few tiers, it's not too hard to add the B9 parts and Firespitter parts as well (I had already made some modmanager tweak files to fit them into your tree as it currently existed prior to the latest version already, so it should be pretty easy to adapt those). Will give me something to do for the next couple days till the new computer gets here
-
I'd be happy to help with the aircraft side of things if you tell me what mods in particular you want to focus on there. This is primarily because the two most popular aviation mods, Firespitter and B9, while they work together they go about things with a very different approach. They can certainly be used together, but if you want to have meaningful tech progression then you need to setup the tree differently depending on whether the user has Stock, just Firespitter, just B9, or both. And then other mods such as Interstellar add their own bits and bobs that would need to be fit into whichever "primary" approach you used for the tree.
Edit: It also depends on how detailed you want to make the aviation portion of the tree in general - personally I'd love to see it be split up as detailed as the rocketry side of things is, but you might not want to have that many nodes on the aviation side for whatever reason
-
Yup, without stretchy tanks, and a number of other parts reducing parts/plugins, I wouldn't be able to fly more than very basic rockets/aircraft. Definitely looking forward to the new computer too - it should even allow me to see all of the pretty textures and graphical effects that I so envy in others screenshots as well
-
Your career got messed up because of the new tree? Pretty sure that once a career is started, you run off the locally saved copy of the tech tree you loaded initially. Let me know if I got that straight, because I want to make sure I'm messing people's games when I perform updates. From what I could see, my old saves still had the old version of the trees.
This is because of how TreeEdit works in comparison to TreeLoader. You are the "owner" of the tree, so you have a "local copy" of the tree stored. Unfortunately, the F5 save functionality does not seem to work the same between reloads of KSP for trees that you are not the "owner" off when using TreeEdit - you have to reload the tree each time you restart KSP from the online version, so your career gets updated to whatever the lastest public version of the tree is. This is a large part of why TreeEdit is not in "general release" yet as far as I understand, and why trees need to get "approved" before they go into public display for TreeLoader users (which does save local copies of the tree.cfg properly, only needing to be loaded once per career save).
@Aazard - I agree that you don't have to pull months or days of aerobraking, but as you said it means you need the proper insertion angle - thus needing the extra dV that I mentioned unless you happen to have a very well timed return window and a good launch orbit from whatever body you are returning from. I was also thinking about it as I was doing a stock-scale Munar landing earlier in sandbox, and it's also possible that some of my extra dV usage is because of how I do my landing profiles on non-atmospheric bodies - largely due to the poor framerates the current laptop gets when loading the surface texture chunks, I use a somewhat less-efficient decent profile which kills all horizontal surface speed at a much higher altitude than a more efficient pure-suicide-burn landing would (this means that I only get one spot of framerate lag for that texture chunk, which then doesn't change because I am descending straight down over the same surface location, rather than still travelling horizontally and loading progressive texture areas as I do so). Can hardly wait to get the new computer here (KSP being the first thing being intalled onto it beyond basic system utilities, lol) and see how it changes my "piloting/lack of control workarounds" that I've been using thus far
EDIT: btw, it's not memory issues I'm having with the current laptop, it's just simply that it is about 6 years old with integrated graphics
It's actually got 8G of RAM on it, with more than enough free for KSP to utilize to the best that it can, and I've done some pretty serious texture reduction and parts pruning so that I usually am only running about 2.7G of memory in use by KSP at runtime. But it still takes 20-25 minutes to actually get through the load process (and even with no mods it takes about 15 minutes just using stock KSP) and has horrible issues when swapping textures in game even at 1/4 res. Honestly I was rather surprised that it is even playable at all on this machine, even though it does mean that I have to sometimes focus far more on "parts-count-performance" optimizations or "piloting-lag-induced" overengineering rather than "rocket-performance" optimizations - as mentioned above with how I do my non-atmospheric landings for example, and why I tend not to use the "just add more struts" approach to building. In fact, my first successful SSTO in FAR that used no struts, no SABRE engines, and no PWings, just to keep the parts count and processor load down as far as possible to make up for low-fps controls, and could still put a 10t payload into a 100km orbit -barely It was an...interesting...challenge... -
Well, this new version came out earlier than expected
I've got my new laptop showing up on Wednesday, which should finally eliminate all of my performance-based issues due to the current one, and allow me to run RSS again. Unfortuntely, my current career got totally borked by the update . So now I've got to decide if I want to start another new game for the few days till the new computer gets here and then start again, take a break from this pack for a few days and play around in sandbox for a bit, or just bite the bullet and deal with the somewhat frequent crashes and 20 minute load times with RSS installed to play the new pack in full so that I can just migrate the save over to the new computer when it gets here. Decisions, decisions...@Bricked: Have you looked at the stretchy SRBs? I agree that I find myself with no real use for the stock SRBs just because liquid boosters are far more controllable and customizable (especially for burn times and thrust values) but the stretchy SRBs solve both of those problems. They still have poor ISPs (as expected from solid fuels), but they DO have good TWR ratios in comparison to the earlier available liquid rockets...very useful for your first atmospheric stage (either as designed to boost an existing stage, or even to be the entirety of the first stage itself).
@Aazard: Not sure about the tech levels required in the new version under RSS, but the dV number you have there seems a tad low. I seem to recall needing 20-21k dV for a Mun mission under RSS with FAR and DR (the latter especially makes it more difficult because you usually need an extra ~500 m/s in comparison to without DR to fly a safe return insertion - at least, to do it in a single pass without spending "months" in space doing repeated aerobraking). Then again, I generally go for lower-than-average TWR on my rockets (especially manned ones) under the combination of FAR and DR for safety and control reasons. If you want to push the edge of capabilities (and are a good enough pilot) then you might indeed be able to do it in the 18k range.
)
[EDIT: in my stock kerbal install that is, which is what prompted the whole rescale and reconfig in RSS for me in the first place 
.
[0.90WIP] Procedural Parts - Parts the way you want 'em 0.9.21, Dec 19
in KSP1 Mod Releases
Posted
Rioliki, you might be surprised at just how "lightweight" real-world decouplers are. The decoupler system used for many "secondary payloads" is really quite lightweight - in some cases the entire satellite weighs less than 10kg! Even for the larger decoupler systems the actual decouplers themselves are pretty lightweight, much lighter than is modelled in KSP - still small enough to not even be included separately in the total vehicle weights listed for the various Apollo missions due to "decimal truncation" (in other words, the actual decouplers for the SI/SII interstage weighed less than 10kg.) Now, KSP models more than just the decouplers themselves in the "decoupler" parts - it includes the interstage structural and other elements aside from the ullage motors/fuel as well. So those weights will be higher if using separate "decoupler" parts obviously. But the current values used in the mod are actually pretty good from both a realism and simplicity aspect (to be "really real" you would have to have multiple categories of structural types for the decouplers, just like multiple "basemass" values for tanks when using RealFuels.)