[WIP][TechTree @ 0.23.5] - [MS19e] - Realistic Progression LITE

[MedievalNerd]

MediavlNerd, are you planning to add to this tree NearFuture mod? It's much more realistic than Interstellar and is better looking.

Can you give examples as to what is more realistic/better options and/or features?

[Guest]

On the "near future" package, I feel interstellar has alot more features that work well with RPL, namely the lighter goo radiometer/magnetosphere probe (plus Antimatter resource), its great way it uses science lab/computer cores and its great inclusion of "mineral" mining. Although i see no reason why both couldnt be included, but i would hate to see interstellar go from the mod package, the only issure i could see is a conflict/confusion having the many types reactors/radiators. If we need to pick one to be used in the tech tree my vote goes to interstellar for its much deeper inclusion of real technologies (but currently unattainable at "real lifes" current energy generation capabilities) and more realistic thoughts on heat buildup/dissipation.

It also adds a more realistic science equip to be used & a "real way" of gaining science from long term study facilities using the science lab/computer cores, not just flying by the moon and taking a gravity and temp reading suddenly being "done" with studying it, its science lab allows for more cool "sky lab/mir" stations that really "do something" that can be extended out to venus, mars or even pluto as you continue to advance (if you can get the lab there and keep crews alive or have it run on pure AI), it would really work better with MCE also for setting up skylab like mission goals with a "put a science lab at such & such orbit hight, have it maintain a positive power charge and be crewed by 2 kerbals (via MCE's crew # report) continuously for XX years (via MCE's "timer") or until it generates XX amount of science, with atleast 1 crew rotation and/or resupply mission (via MCE's "docked" indicator)".

So if the aim is at realism: interstellar, IMHO, is slightly better just due to the number of things it would allow midevalnerd to do with MCE/custom missions

@ midevalnerd: : do you suggest i remove "all" the non-size adapting normal "non-stretchy" fuel tanks (including xenon/mono tanks) to save on load time, memory use and "parts clutter". I was also wondering if there is a stretchy version of the jet fuselages like the mk2/mk3 jet "body" fuselages as currently the stretchy tanks force me to use "cylinder" body jets or stock mk2/mk3 "body" tanks. As my tech levels go up it has left me wondering "how am i going to glide land a huge rounded shuttle?" as the mk2/mk3 "bodies" seem to have higher impact tolerance for landing and slightly better shapes for placing landing gear bays. (yikes as i post this i'm now thinking...how will my shuttle body/landing gear bays survive DRE heat effects lol, mk2/mk3 jet "bodies" & landing gear bays should have a small "ablative shielding" rating for shuttle use if they dont already other wise there will be now real way to return them to the surface making them kinda pointless). This has come to mind as i start trying to design rockets/shuttles that MCE reports all dropped stages as "recovered", as i feel once MCE is in this will become a must to make proper use of our allotted budgets, why "throw away" a stage you paid for when you can recover 66% to 75% its parts value by timing its drop hight/speed & adding X number of parachutes to it?

Edited December 4, 2013 by Guest

[funfight22]

What I meant was that all the stock science experiments would give overall a higher output, and be done without diminishing returns three times.

[BelgarionNL]

nice mod! tried it but for my serious game it needs a bit more work!

[Guest]

If earths circumference is aprox 40,075Km and semi-synchronous orbit is aprox 20,200km, could 3x comms sats a communitron 16 each remain in contact with eachother & mission control (seeing as they have a range of 20,000km) constantly, if placed just under semi-synchronous orbit hight (if there were say at 19,999km circular orbits)? i am unsure how to find the distance they would be from eachother if placed 120 degrees apart. Not that this is really something one should do (as most of us would have communitron 32's(50km)/600,000,000km dishes unlocked by the time we put comms sats up) more of an "i wonder" question, seeing if the communitron 16 has any "real use" once other comms antennas are unlocked due to how light/low power it is, unless maybe it or the 500km dipole would work for for the omni communication network between a small moons/planets own comms sat relay?? if someone knows the formula for finding the distance between equal orbital hight sats it would be great to know, i have tried googling it but it eludes me.

[RaccoonTOF]

@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.

Edited December 5, 2013 by RaccoonTOF

[Varek_Raith]

Hello, I am recieving the following error when using TreeEdit to load your tech tree.

[Error]: You are trying to load data from a www stream which had the following error when downloading.

Could not resolve host: www.kspmodders.com; No data record of requested type

Needless to say, I can't play.

[MedievalNerd]

@MedievalNerd -

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.

Yup, I saw that in the vertical tree thread. I'll arrange something similar to for Milestone 19 (provide optional tree.cfg download). But yes, once you F5 the tree, you can definitely quit. And then switch to treeloader and should be fine. Also, more lazy fix, is to rebind F5 quicksave to something else.

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 ).

Yup, that was all fixed in 18b. Also worked with nathan to fix the altitude thresholds for the other bodies (remained stock numbers which made funky things). I want to give him time to finish tech node implementation for MFT, and if possible the RSS additions so we can have proper tresholds. In the meantime I'm findagaling some new probes to help overhaul the probe line.

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...

Thanks, I might touch aviation in MS19, but for 20 i'll give it at least an overview with your feedback. Although B9/firespitter integration, that'll might come down the line as well.

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.

The units are decided by the game actually. You put the rate and based on what the value is it'll say per second, or per minute, per hour. I don't know if it's possible to force it to remain at a certain value. That's all stock KSP.

[NathanKell]

RaccoonTOF: thanks for posting the math so I didn't have to!

Regarding units--the KSP solar panel module (and most things that use or give EC, like generators or probes) defaults to EC/min instead of EC/s when < 1.0

That's not something we can change, AFAIK, though it is REALLY annoying, as you say.

[Guest]

i noticed the custom experiments descriptions is lacking the duna/eve probes data requirment and reward values, could you plz post them? also any pre-info on project bumper and other missions?

[GeoffreyY]

everybody's having problem with TreeEdit, can't somebody upload the tree.cfg instead?

Or is there some limitations?

[MedievalNerd]

everybody's having problem with TreeEdit, can't somebody upload the tree.cfg instead?

Or is there some limitations?

Here is a link to tree.cfg for V18b

https://www.dropbox.com/s/qw7k57s8fpihs29/tree.cfg

Cheers,

[RaccoonTOF]

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 .

Edited December 5, 2013 by RaccoonTOF

[Varek_Raith]

Here is a link to tree.cfg for V18b

https://www.dropbox.com/s/qw7k57s8fpihs29/tree.cfg

Cheers,

I appreciate it, thanks.

[MedievalNerd]

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 .

True but the thing that pains me the most about the description field is you can't insert line breaks. So putting a lot of information can make it very busy. If we could at least have line breaks then it could be interesting.

[GeoffreyY]

Here is a link to tree.cfg for V18b

https://www.dropbox.com/s/qw7k57s8fpihs29/tree.cfg

Cheers,

Thanks with the help!

[MedievalNerd]

Thanks with the help!

I appreciate it, thanks.

My pleasure! I'll include the tree.cfg file for all future releases as well, until we hear back from the great r4m0n.

Sorry for all the hassle, and thank you for trying out the tree.

For those wondering what's going on at this point, with the threshold values established, i'll use those to guide me in future experiments. Also, once implemented, i'll check out to see if I can implement near/far approach (using the atmospheric flying high/low flag).

Been working on probes, here is the latest look at their awesomeness. Be warned, that I am not a modeler. So these are simply resized stock or KW Rocketry parts. (Stayputnik 1 is already the correct size)

Edited December 6, 2013 by MedievalNerd

[Guest]

My pleasure! I'll include the tree.cfg file for all future releases as well, until we hear back from the great r4m0n.

Sorry for all the hassle, and thank you for trying out the tree.

For those wondering what's going on at this point, with the threshold values established, i'll use those to guide me in future experiments. Also, once implemented, i'll check out to see if I can implement near/far approach (using the atmospheric flying high/low flag).

Been working on probes, here is the latest look at their awesomeness. Be warned, that I am not a modeler. So these are simply resized stock or KW Rocketry parts. (Stayputnik 1 is already the correct size)

WOW, look at how small vangaurd is! 15.5 cm diameter?

[MedievalNerd]

@all

MS19 will most likely have integrated tech nodes linked to MFT! So you won't be able to set your engines higher than the related tech line. (IE, liquid engines / solid rocket boosters)

WOW, look at how small vangaurd is! 15.5 cm diameter?

Yup, it's that tiny.

From what I understand it was meant to be the first satellite into space, but the Russians beat the Americans with Sputnik I, and Explorer I ended up launching before vanguard.

For Project Bumper I made a resized skipper for the WAC engine. So I'll be including a 0.3M engine in MS 19!

I'm asking Frizzank if I can make a clone of his redstone to make a V2 1.5M core for the first stage!

See below for what it looks like using the current 2M C2 engine. It's about 18 Meters tall in total.

I'm thinking of making 2 "Bumper cores", one atmospheric, the other low sub orbital.

Then it'll be sputnik I, II, Explorer I and Vanguard with low orbital experiments.

What I meant was that all the stock science experiments would give overall a higher output, and be done without diminishing returns three times.

Ahh, ok I see what you mean. Instead of repeated experiments, there will be different ones per core, and more cores! (As i mentioned above)

@ midevalnerd: : do you suggest i remove "all" the non-size adapting normal "non-stretchy" fuel tanks (including xenon/mono tanks) to save on load time, memory use and "parts clutter". I was also wondering if there is a stretchy version of the jet fuselages like the mk2/mk3 jet "body" fuselages as currently the stretchy tanks force me to use "cylinder" body jets or stock mk2/mk3 "body" tanks. As my tech levels go up it has left me wondering "how am i going to glide land a huge rounded shuttle?" as the mk2/mk3 "bodies" seem to have higher impact tolerance for landing and slightly better shapes for placing landing gear bays. (yikes as i post this i'm now thinking...how will my shuttle body/landing gear bays survive DRE heat effects lol, mk2/mk3 jet "bodies" & landing gear bays should have a small "ablative shielding" rating for shuttle use if they dont already other wise there will be now real way to return them to the surface making them kinda pointless). This has come to mind as i start trying to design rockets/shuttles that MCE reports all dropped stages as "recovered", as i feel once MCE is in this will become a must to make proper use of our allotted budgets, why "throw away" a stage you paid for when you can recover 66% to 75% its parts value by timing its drop hight/speed & adding X number of parachutes to it?

Not 'all' tanks, but keep the ones you find either stylistic or useful. There are a lot of duplicates/redundancy, do what feels best! I suggest you move them to a temporary folder and if after a while you don't miss them, just delete them.

For shuttles, since those are late tech tiers, I haven't decided on what to do exactly with those. There are a lot of mods out there that offer shuttle engines and what not, I'll differ to Nathan for the selection.

nice mod! tried it but for my serious game it needs a bit more work!

It needs _tons_ of work! But glad you like this early version. Stay tuned!

Edited December 6, 2013 by MedievalNerd

[TranceaddicT]

Okay guys. I've installed this grouping of mods and have a few problems.

1) no shrouds for any engines. Does this come later in the tech progression?

2) Modular Fuels is messing with Stretchy. I can't get the fuel type to change when MFS is in place. Take it out and Stretchy fuels change, but then I can't launch ... no boom in the boom stick; fuel just leaks out the bottom.

3) For some craft configurations I can't control the vehicle. It looks good, but once I put it on the pad I can't launch. (Ex; Stayputnik Mk2 with MJ and FE.)

I also have a problem with engines not linking to the tanks. i.e., Liquid Engines no recognizing Liquid fuel. (I know this because FAR and MechJeb don't generate any deltaV values when the engine is attached.)

I'd really like to use this as I enjoy the added "realism", but after a day of struggling to get it working I'm at wits end.

I'm sure it's just something silly I've overlooked.

Fresh install.

Each Mod install as from Spaceport or forum link.

No duplication of dlls.

MMSarbian and ModuleManager not loaded. ModuleManager _1_5 is.

MODS: All Essential and additional listed in post #1. Also have TextureCompressor (This is a must have saves about 750Mb. 3.8Gb>3.1Gb)

Edited December 6, 2013 by TranceaddicT

[NathanKell]

MedievalNerd: nice!

TranceaddicT:

*no idea why you're missing shrouds

*Modular Fuels applies to all fuel tanks (including stretchies). You can and must change fuels for every tank you use, by going to Action editor mode in VAB/SPH, clicking on tank, setting tank config there. You definitely should read the OP in the MFS thread, it explains how it all works and mentions where to get info on the fuel types (engines use different, real, fuel types, not LiquidFuel and Oxidizer).

[Guest]

May i request/suggest that the interstage adapter be added to starting list of parts? I am unsure just how picky FAR is with the "smoothness" of a rockets body, using the starting parts i can construct a rocket with just over 16.5KM of delta-v although i am left with 2 areas that are an eye sore & pancake flat, i am unsure if this is effecting its atmospheric flight characteristics (it doesnt seem to effect it poorly). I know i maybe nitpicking and there is no reason to build such a rocket before i have unlocked pretty much all the tier 1 level nodes, but i built it as a "proof of concept" of what could be done with the starting parts for 2 of my friends also using RPL, and the 1st thing both of them mentioned was "that would never launch correctly in real life with the huge areas of drag", which somewhat took away from what i was attempting to explain to them (that "starting node" parts had the ability to reach geosynchronous orbit/moon flyby with some careful design engineering). If you think this is a poor idea please let me know, but i think its not hard to believe the knowledge that "smooth things launch better" would be common by the early 1940's (or even early 1740's for that matter lol)

Edited December 6, 2013 by Guest

[MedievalNerd]

Hey Azard,

Yeah procedural interstage will be a must (as you can see in my Project Bumper picture a bit higher above).

There is maybe a way to get size restrictions based on tech level, but that's further down the road. Ideally you could have procedural interstage unlock +1 size each tech node. That would be awesome.

With my new sub 0 tech level engines, it might make the curve more interesting on start. Only have the new V2 & WAC engines will be interesting.

It's taking a while for V19 but I think it'll be worth it!

Hang in there everyone,

[Thalur]

I've been playing with this mod for a little over a week now, and I have to say I'm rather impressed. Your pitch on the first page reads like a list of my favourite mods put into RSS and with a decent tech tree and revamped, more realistic science added on (the stock science and tech tree are bizarre).

To me, the tech tree and science scheme is like a tutorial: at each step you provide some more parts to use and some new goals to achieve. In a good tech tree, the goals should have a logical progression, each building on the ones before, and the part unlocks should provide the parts you need for the next goals. At the moment your tech tree does that well up to orbital flight (though the first QBE with the 'orbital' experiment is easy to do sub-orbitally), but I think having 'orbit the moon' as the last tier 1 task is more than a little too hard with the current set of engines. I spent the last 5 days (maybe 20 hours) trying to get the right balance of delta-v (easy to get) and TWR (very hard to get) as the tier 1 lower stage engines all seem to have too weak thrust for a moon rocket (I just succeeded, pics below), so it is a very good thing you are adding more low-level experiments in v19 . I also found a problem where the tooltip for the engines consistently shows a thrust that is two to three times bigger than what you get when you go to the launch pad, which didn't help things along.

The other thing that bugs me is the selection of parts in tier one seems a little off: you get 0.5m/0.625m fairings and separators (apart from the DRE ones) but engines and tanks up to something like 2.5m. It makes procedural fairings an essential mod if you want properly faired rockets. I also have version 3 of FASA installed and that has some Mercury parts that aren't in the right places in the tech tree (the capsule is in the starting node!).

I really like the science gathering idea; it is a neat mechanic that significantly improves the science aspect of the game by giving a concrete and realistic set of goals. I would like to see a difference between sub-orbital and orbital tasks (i.e. so I can't cheat and do the higher space orbital task with a sub-orbital flight), simply extending the data logging time to an hour (so long as it works with time acceleration) would do the trick. It would also be nice to have the ability to sample/take reading from that data when not in the target situation but having recorded data while in that situation (i.e. I want to be able to record the low moon orbit data while out of comms range, then transmit the sample when back in comms range but no longer in low orbit. At the moment I think it tries to take a high orbit reading). Perhaps a separate data resource bar for each situation on the same probe?

So, an excellent mod so far, and I am really looking forward to what comes next Now, time to open up tier two and start -killing- orbiting kerbals

For those that are interested, I've made a couple of albums of my successful flights along with some explanation of how I did them.

First up is a 250km suborbital sounding rocket to get that first big boost of science.

And if anyone else is struggling to get to the moon, this might help you out.

I could make a 'first orbit' one if people are interested.

[NathanKell]

Thalur: Thanks!

Note that in MFS RF or MFS RFRM, engines' thrust scales correctly with Isp, so thrust at any time = nominal_max_thrust * current_Isp / max[i.e. Vacuum]_Isp

For your lower stage engines you need, err, lower stage engines (Type L or L+). The ones with the higher sea-level Isp.

If you want to see your Sea Level TWR, use the latest dev build of MechJeb, open deltaV stats panel, click on all stats, and SLT column will appear.

Finally, you definitely could use the NovaPunch and KW Rocketry engines. Delete the other parts (or at least the ones you don't use) but those packs will give you far more variety in low-TL engines.