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

[Guest]

Ok, decided to give your Mun custom experiments a go now that I finally have the power generation ability to actually run the data recorder for an extended period of time. However, I ran into an issue once I reached Munar orbit. The data recorder on the probe only appears to be "calibrated" for one Mun altitude while it has 4 experiments on it at varying altitudes (including surface). So I am unable to gather data for all of the different experiments... (trying to use the data generated at the "calibrated" altitude, even at the proper altitude for the experiments themselves, fails with the message that I need "at least 100/200/etc data"...

EDIT: Also, gravity scans show a value of 198 science, but upon completing the transmission they actually deliver 0.0 science...

Did you take more than 1 gravity scan? as base and cap values seem to be the same (so 1 transmission should max its total out) for experiments other than magnetosphere readings (which are 60%), i am about to head for the mun and now i'm worried about the data recorder lol

[MedievalNerd]

Ok, decided to give your Mun custom experiments a go now that I finally have the power generation ability to actually run the data recorder for an extended period of time. However, I ran into an issue once I reached Munar orbit. The data recorder on the probe only appears to be "calibrated" for one Mun altitude while it has 4 experiments on it at varying altitudes (including surface). So I am unable to gather data for all of the different experiments... (trying to use the data generated at the "calibrated" altitude, even at the proper altitude for the experiments themselves, fails with the message that I need "at least 100/200/etc data"...

EDIT: Also, gravity scans show a value of 198 science, but upon completing the transmission they actually deliver 0.0 science...

Oups!

Thanks for pointing that out!

Yes, I need to tier that up! Helping out Nathan with some rescales, then I'll make more experiments and fix those things for V18.

No idea about the gravity scan, i'll have to look into that.

[RaccoonTOF]

On the gravity scan, I did do more than one, but only because the first one reported something like 250 science and gave me 66 delivered. When I ran it again, it showed 198 for the value, and delivered 0. Interestingly enough...66 is the size of the data itself...and 198 is 3x the data size?

Also, yet another issue with the Munar experiments. I did manage to get the low orbit readings sent off properly using the method above, but when I went back to land...stocked up my 300 data...landed...and then it failed to do the experiment. It DID however use up the 300 data...while on the surface...with no way to get more...

The temp scan, probe science, and grav sensor are all reporting me to be landed on (in...) the Mun's East Crater biome...but none of them are actually transmitting any data back either. Going to try storing the data instead, and then see if it will be there when I return to Kerbin...

Edited November 20, 2013 by RaccoonTOF

[Guest]

Another Edit: Ok, so gathering all of the data for the upper experiments and then actually performing them, will allow you to gather data for the lower experiments - but still at the upper altitude. So you need to gather 350 data in the upper orbit, then do both upper orbit experiments, then gather another 500 data, then go to low orbit, do readings there, then land, then do readings there with the last 300 data...seems a bit awkward, but it DOES work at least...

YIKES!! that is odd

[RaccoonTOF]

The Grav sensor reports 66 science over Kerbin (Upper Atmosphere, over Highlands) but delivers 22 science. Definitely seems to be an issue with that sensor, the amount of science it reports, and what it actually delivers being 1/3 the actual value.

[andqui]

The Grav sensor reports 66 science over Kerbin (Upper Atmosphere, over Highlands) but delivers 22 science. Definitely seems to be an issue with that sensor, the amount of science it reports, and what it actually delivers being 1/3 the actual value.

That issue isn't due to this, that's been here since the update (for me at least). I asked earlier and was pointed here:

http://forum.kerbalspaceprogram.com/threads/53793-Atmospheric-Analysis-reported-science-value-is-10-times-the-recovered-value?p=718132&viewfull=1#post718132

[RaccoonTOF]

Ah ok, so hopefully that at least will be fixed in the next patch.

On the other hand, for some reason it doesn't even think that my probe actually LANDED on the Mun...which explains why it wasn't allowing me to do the Mun surface readings (though it really should NOT deduct the "data" if it cannot perform the experiment...). And of course, I didn't get any of the "saved" normal sensor data either...

Note that it gave me credit for recovery of a vessel "returned from orbit" around the Mun, and not landed on it. On the other hand, I do have another 2k science to play with now and see what else the tree has to offer me...

[MedievalNerd]

Ah ok, so hopefully that at least will be fixed in the next patch.

On the other hand, for some reason it doesn't even think that my probe actually LANDED on the Mun...which explains why it wasn't allowing me to do the Mun surface readings (though it really should NOT deduct the "data" if it cannot perform the experiment...). And of course, I didn't get any of the "saved" normal sensor data either...

Note that it gave me credit for recovery of a vessel "returned from orbit" around the Mun, and not landed on it. On the other hand, I do have another 2k science to play with now and see what else the tree has to offer me...

Ahhh,

That's, peculiar. And you aren't using RSS? I'm puzzled how the craft wouldn't understand it landed on Mun. The recovery functionality I haven't touched and is stock. Very weird. Ethernet did suggest me a different way to check SrfLanded &SrfSplashed, I'll review his suggestion and tweak the code for the plugin for V18 update.

EDIT: A ha, I messed up the situation mask for SrfLanded & Splashed in the actual experiment itself. Which is why you weren't able to trigger it. Darn. But the vessel not being reported as having landed on Mun in recovery... that is strange!

Edited November 21, 2013 by MedievalNerd

[Guest]

is there a "quick fix" we can apply to get around this until the update V18 is released??

[andqui]

Do your tweaks nerf the torque produced by SAS? The originals did always seem overpowered and this is proving to be a nice challenge, especially since rockets need to be much bigger to get into orbit with RSS. If I'm at an early tech level, and don't have powerful torque motors or pivoting engines, is there anything you would recommend to improve the ability to turn larger rockets? RCS isn't typically used in atmosphere, is it? I've even tried adding lots of those moveable fins and it's still very sluggish.

Also, have the new KATO engines been released?

[RaccoonTOF]

Adding lots of fins isn't as important as adding the right fins in the right places. What I generally do (for rockets) is to put 4 sets of two fins on in the following setup (built from the top down, assuming two atmospheric stages):

On the second atmospheric stage put 4 smaller fins in two pairs forming a cross when viewed from below (as if you were using 4x symmetry, but put them on using 2x twice so you can change them separately in FAR) located as close to the CoM as you can while still keeping the CoL behind the CoM. If you have a reasonable taper to this stage (including everything above it) this shouldn't be too difficult to achieve placing them pretty much right on the CoM - not necessarily at the "rear" of the stage as a whole - and choose your fin size appropriately to get this positioning correctly. Now setup the left/right pair in FAR to be Pitch only, with AoA limited to about 3-4 degrees less than their stall angle. Do the same with the other pair, but set them to be Yaw/Roll only.

Now attach the bottom atmospheric stage (not including any clamps/etc.), and repeat the process above, usually using larger sized fins. In this case you want to make sure that your CoL is well behind the CoM but still not all the way at the rear. My personal preference, launching without gimbals activated on the bottom atmospheric stage, is to try to get the final CoL about halfway between the CoM and the CoT. Exact position depends on the individual rocket and your personal control preferences. Again, make sure that the left/right pair is pitch only, and the top/bottom pair are yaw/roll both, with max AoA again a few degrees less than the stall angle.

Now when you actually go to launch, you may find that you still have a bit too much "control authority" - if the rocket tends to waggle a lot under control input, or jerk around, then you need to go back to assembly and turn down the max deflection angles a bit. Personally I tweak the FAR dynamic control settings instead, so that I have the possibility of maximum controls if they are needed, and just use a "light touch" on the keys, but it can be easier to setup if you just limit the control surfaces themselves.

If this doesn't make sense, I'll try to get a few pics up showing the CoL/CoM indicators, but you can look at the first pics I posted above of my comsat launcher on the pad to see the general position of the fins themselves for that particular rocket.

EDIT: Pics included now

Upper Atmospheric Stage

Base Atmospheric Stage

Note the use of two separate stretchy tanks in the base stage - this is just to make positioning the fins easier using the "Vertical Snap" function in the Editor Extensions plugin, so the two pairs end up symmetrically located still in respect to each other. You can do this by eye still, but it's a lot easier with the Extensions plugin, then you just need to adjust the size of the upper stretchy tank to position the CoL properly, and balance the lower tank to meet dV requirements.

Edited November 21, 2013 by RaccoonTOF
Added Pics

[stevron]

I'm having an issue with RT2 antennas with RSS + RT2 tweaks.

So I was getting underway to put a GEO sat network in place but I'm having weird range issues. As it stands the Commu 16(the most basic omni) somehow is reaching mission control from 30Mm+ even though it is rated at 25Mm, and the Comm's DTS-M1(500Mm, 45 degree arc) which was going to the the dish at be pointed at Kerbin does not reach mission control when it's pointed at the planet, but if I specifically target mission control it will indeed work.

So I'm just wondering if anyone else has issues or if I've buggered something somewhere with the tweak files, thanks.

[RaccoonTOF]

The difference between listed ranges and the actual working range is because with the tweak file provided it sets the RT2 settings config file to use additive ranges instead of the normal RT operation. So you are getting the 30Mm range of the antenna added to the base range of KSC mission control for your actual "operating range". If you don't like this, you can go into your RT2 settings config and set it back to the default operation instead of using the additive mode.

EDIT: I think keeping it in the additive mode is appropriate for this mod however, as with the altered energy rates (production and consumption) on the panels and antennas, it can be very difficult to power a long range dish on the craft itself, capable of reaching back to your comsat array. Instead, you can put a shorter range omni antenna on the craft itself, and then put a very long range dish on your comsats - so the power infrastructure is larger on the comsats, but only needs to be launched and put into orbit once, instead of being required on every vessel that you launch...

END EDIT

As for the failure to connect to KSC Mission Control when pointing it at the planet, I'm not sure why that would be an issue unless KSC is currently located outside of the 45 degree arc - the antenna will point to the center of the planet, so if KSC is close to one of the "horizons" you might not hit it aiming at the planet, but when targeting it directly the antenna centers the cone on it rather than the center of the planet.

Edited November 21, 2013 by RaccoonTOF

[issarlk]

Hmm, I recall someone talking about this issue on some other thread related to a mod. I use so many I can't recall what it is. But yeah, I'm currently a few launches into my balance pass, and I was able to recuperate a few ships and no, they don't stay on the map after recuperated. Well, just to be clear, do you see them when you go to the radar tracking menu? IE, show up as available flights?

they were showing as flight on the radar. But I made a clean reinstall and now it works correctly.

[stevron]

The difference between listed ranges and the actual working range is because with the tweak file provided it sets the RT2 settings config file to use additive ranges instead of the normal RT operation. So you are getting the 30Mm range of the antenna added to the base range of KSC mission control for your actual "operating range". If you don't like this, you can go into your RT2 settings config and set it back to the default operation instead of using the additive mode.

As for the failure to connect to KSC Mission Control when pointing it at the planet, I'm not sure why that would be an issue unless KSC is currently located outside of the 45 degree arc - the antenna will point to the center of the planet, so if KSC is close to one of the "horizons" you might not hit it aiming at the planet, but when targeting it directly the antenna centers the cone on it rather than the center of the planet.

What does one type in the "RangeModelType = Additive" to set it to default, I would rather not try "Default" in case I bugger something. As for the dishes pointed at planets are you saying it could be an inclination issue? If so my sat is on a 0.01 inclination and is fairly close to directly above ksc at 35Mm+ which completely blankets Kerbin and then some.

edit. Scrap the what put after equals sign, what you just said makes perfect sense.

Edited November 21, 2013 by stevron

[Guest]

.

EDIT: A ha, I messed up the situation mask for SrfLanded & Splashed in the actual experiment itself. Which is why you weren't able to trigger it. Darn. But the vessel not being reported as having landed on Mun in recovery... that is strange!

is there a "quick fix" we can apply to get around this until the update V18 is released?? it is worrying me to try the mun probe now

[MedievalNerd]

is there a "quick fix" we can apply to get around this until the update V18 is released?? it is worrying me to try the mun probe now

Hi Aazard,

Not 'really'. I got caught up in the grand rescaling with Nathan, we are almost done so I'll be able to go back to finishing the V18 update.

You can try to go find the experiment in the sciencedef and the customexperiment module in the probe itself, and check that i'm using the right situation mask. If you look at my note in the situation mask list, I inverted both splash/land!

Might be a little confusing unless you are used to messing with Module Manager & .cfg files.

[Guest]

Might be a little confusing unless you are used to messing with Module Manager & .cfg files.

I am not overly used to cfg edits in KSP, although i am getting alot more comfortable with them, i will look but not touch without asking if i manage to find the line in question,

NOTE i did run into a small "out of place" issue with the base and cap values to remove "grinding" science, The magnetosphere probe from "interstellar" still reports 60% transmission rate (needing about 5 transmissions to complete 100%), and seems to need 2 probe readings RETURNED without transmitting to reach 100% of avaible points in R&D overview window. Is this intentional or an oversight, or something from interstellar mod that wont be changed to maintain the way interstellar does things?

[Guest]

A HA! is this the line in question??? i found it repeated a few times in "Kerbal Space Program\GameData\MN_MissionPack\Tweaks\Science & Resources" scienceDefs.cfg file

All kerbin exps say:

//001000 = High Atmosphere = 8 // FlyingHigh

//000100 = Low Atmosphere = 4 // FlyingLow

//100000 = High Space = 32 // InSpaceHigh

//010000 = Low Space = 16 // InSpaceLow

//000010 = Splash Land = 2 // SrfLanded <<<<<<<

//000001 = Surface Land = 1 // SrfSplashed <<<<<<

-------------------------------------------------------------------

all munar exps say:

//001000 = High Atmosphere = 8 // FlyingHigh

//000100 = Low Atmosphere = 4 // FlyingLow

//100000 = High Space = 32 // InSpaceHigh

//010000 = Low Space = 16 // InSpaceLow

//000010 = Splash Land = 2 // SrfLanded <<<<<<<<

//000001 = Surface Land = 1 // SrfSplashed <<<<<<

i assume switch each line where i see this equals: (please tell me if this would exist in multiple files)

Splash Land = 2 // SrfSplashed

Surface Land = 1 // SrfLanded

Edited November 21, 2013 by Guest

[BrickedKeyboard]

Ok, so I'd like to try this thing out. I opened up the Excel document...and there are 35 files I need to dig up from 35 separate forum threads?

Ouch.

Ok, so after installing all 35 files, do I only need to install the tweak pack, or is there something else to do...?

[Guest]

Ok, so I'd like to try this thing out. I opened up the Excel document...and there are 35 files I need to dig up from 35 separate forum threads?

Ouch.

Ok, so after installing all 35 files, do I only need to install the tweak pack, or is there something else to do...?

On top of this a assume the kw/novapunch/squad texture reducer files are also required (i needed to add them & i have 64GB ram)??

[Razorcane]

On top of this a assume the kw/novapunch/squad texture reducer files are also required (i needed to add them & i have 64GB ram)??

That's not how games work. No matter how much memory you add, 32-bit games can only use 4gb, because it only has single-precision floating points, and can only address 2^32 integers. 64-bit, however, uses double-precision floating points, and can address 2^64 integers. Games using older technology, like KSP, are only 32-bit. So 60gb of your RAM is useless in KSP.

[Guest]

That's not how games work. No matter how much memory you add, 32-bit games can only use 4gb, because it only has single-precision floating points, and can only address 2^32 integers. 64-bit, however, uses double-precision floating points, and can address 2^64 integers. Games using older technology, like KSP, are only 32-bit. So 60gb of your RAM is useless in KSP.

thanks for the info Razorcane

[Guest]

i found probecube2's part.cfg file in probesphere2's folder as "part.cfg - copy", i moved it to the probecube2 folder and removed the "copy tag", and it seems to work fine. Other users please let me know if this works for you also.

[BrickedKeyboard]

Alright, I just checked. There are approximately 4 mods in this list that can't be packed into a mod pack "legally". (not that anyone is likely to be suing anybody)

Those mods are both KAS and Kethane, and like 2 others.

Yes, a file with all mods in it would be a big download, but I would much rather click 1 file + maybe 4 others tops than have to dig up 35+ files.