SpaceNomad

Yes, I understood that and didn't expect that the Symmetry setting would affect loading. One more funny detail I discovered after reporting: It seems that on the first load after starting KSP the actions do not mess up. At least, this time it worked properly once and when I tried to reproduce what I had done different than before (loading, renaming the vessel) it failed again. So, I think the only thing that made it work was, that it was the first load after KSP start.

Hi, with AGExt 1.34d installed via CKAN on a heavily modded KSP 1.0.5."Silent Patch" I'm seeing the old symmetry bug, that was reported here but was deemed fixed in 1.33a as confirmed by the original reporter here The symptoms are exactly the same as discussed back then: When loading a ship with action groups with "Symmetry: No" in the VAB, the action group suddenly also contains the symmetry parts This happens for both groups below and above #10. This does not happen when just leaving and re-entering the VAB to the KSC or when reverting a flight to the VAB. It happens only when loading the ship with the yellow "Load" button.

Ahh, this is how you breed and feed the Krakens in the KSP codebase.

or on the main menu. So, the only way to get rid of it again is completely quitting the game (and restarting takes minutes with >100 mods). For me, this happens every time I forget to close the menu before switching scenes (say by clicking on a Kerbal Alarm Clock notification).

I think, this is a known issue with ScienceAlert not having been updated to KSP 1.0.5. There is a patch posted in the ScienceAlert thread.

Yes, the contract was picked up before 1.9.2. I now finished Episode 1, so let's hope in Episode 2 they will interfere less A few comments to Episode 1: "Load Mulder Kerman on the launchpad." is a bit misleading since this is clearly a job for planes. (Admittedly, this probably only lead to confusion because I was struck by the bug that Mulder was not recognized on board.) When sending Mulder out to the "weather balloon", I was expecting some immediate reaction and was suspecting "yet another bug" when that did not come. Only after some fiddling I saw, that it triggered a countdown. Maybe insert another dialog window hinting at the countdown ("Now this looks interesting! Give me some time to take samples." or something like that)

I have an issue with the first "real" episode. I landed nearby the "weather balloon" and the first series of text boxes triggered (after Contract Configurator had fixed the issue that the game was not recognizing Mulder being onboard, that is). Now, I'm supposed to send Mulder on EVA as far as I understand. But that doesn't work, because he is classified as "Tourist" and tourists can not go on EVA. Edit: I worked around it by editing the savegame (changed type/trait from Tourist/Tourist to Unowned/Scientist).

That indeed fixed it. Thank, you! And it (or 1.9.2 most probably) even fixed a bug I discovered while you were fixing the backwards compatibility issue (the game did not register that Mulder was onboard). Unfortunately, I now have another problem, which I suspect is not a Contract Configurator bug, but a logic error in the K-Files pack (Mulder is supposed to go on EVA, but he can't since he is a Tourist). So, I'll report it there.

Yes, they indeed were. So, I'll do as you suggest and upgrade after I finished those two. (So, I better figure out how to reach those two monoliths on the mountains )

Hmm, it seems that this broke something. I was upgraded from ContractConfigurator 1.9.1 to 1.9.2 through CKAN today (no other updates) and all waypoints related to ContractConfigurator contracts vanished (not visible in tracking station nor Waypoint Manager mod). Custom waypoints (created via Waypoint Manager) and waypoints of non-ContractConfigurator contracts still appear. Downgrading back to 1.9.1 makes the issue go away (so I'm pretty sure 1.9.2 broke it). The affected contracts were K-Files EP1: Strange Things ("The K-Files" pack) Investigate magnetic anomaly on Kerbin ("Anomaly Surveyor" pack) Unfortunately, I forgot to save the log when on 1.9.2, so I'll re-install it and see if there are any exceptions.

Does anyone know what this setting does? ASTRONAUTS { unlockedEVAClamber = 3 } I guess, this unlocks something EVA-related at level 3 of the Astronaut's Complex, but what? I'm at level 2 and the only difference the GUI tells me for level 3 is "unlimited crew".

Strange indeed. I just looked into the sources of PortraitStats which seems to use KerbalRoster.GetExperienceLog() from the KSP assembly. I suspect, that it's just rounding to the closest integer somewhere, though the code monodevelop shows me for the relevant functions seem to use float. Anyway, no bug in FieldExperience as you said. Thanks for looking into it!

I have an issue with FieldExperience 1.0.2 installed via CKAN on KSP 1.0.5 for Linux 64 bits: The experience of the current flight is not registered even after doing the usual "go to spacecenter" or "quicksave/quickload" dances (I also exited and restarted KSP). My crew is currently in the SOI of Minmus (but not yet in orbit). The PortraitStats mouse-over on Bob says: Experience: 5.00/8 Career Log: Orbit around Kerbin = 2 Orbit around Mun = 3 Current Flight: Orbit around Kerbin = 2 Fly-by Minmus = 3 As can be seen he should have 8 points needed for his second star (Orbit Kerbin, Orbit Mun, Fly-by Minmus) but still has only 5 points/one star and thus can't reset the Science Jr. The other four Kerbals onboard have the same issue (though they don't have enough XPs for the next star, yet). Log/savegame can be found in this GIST (the career uses >100 mods though). The affected mission is the "Minmus Orbiter 1" (yes, I know, very creative name :P) I did not see anything seeming relevant in the log (other than that the FieldExperience mod is in fact loaded). Edit: Turned out I can restore the ScienceJr with a level 1 scientist. Edit2: After going into orbit of Minmus (and switching to KSC and back), Bob finally got his star.

It looks to me as if KSP has a tech tree editor built-in. When activating the debug screen in the R&D building (Mod+F12) there are options to change tech nodes and save the tree. I never tried if they are fully operational, though.

I'm missing a topic: Altitude boundary charts for science and warp speeds. Searching for either "altitude", "boundary" or "charts" in topic titles does not find it ("boundary" does not give any result).

[quote name='Probus']Thanks SpaceNomad! If you don't mind I will include it in the tree and tag you as a contributor. I will have to make a few subtle changes, but other than that looks great![/QUOTE] Of course, I don't mind if you include it and make any changes you see fitting! Consider it contributed under the terms of CC-BY-NC 4.0. Thank you for this great tech tree BTW I really enjoy it.

For all that are fans of RLA_Stockalike: I did a quick and dirty ModuleManager patch moving the RLA parts to sensible (I hope ;)) tech nodes of this tree for my own use. I thought, I should share it with you. Just put it in a file with a ".cfg" extension anywhere in your "GameData" folder (maybe in a personal subfolder for local customizations): [spoiler="MM_RLA_ETT.cfg"] [CODE] @TechTree:AFTER[zETT] { RDNode { id = advMiniaturization title = Advanced Rocketry 0.625 description = Advances in small rockets. cost = 50 hideEmpty = False nodeName = node5_advMiniaturization anyToUnlock = True icon = RDicon_miniaturization pos = -1951,841,-15 scale = 0.6 Parent { parentID = miniaturization lineFrom = LEFT lineTo = RIGHT } } @RDNode:HAS[#id[precisionEngineering]] { @nodeName = node6_precisionEngineering @pos = -2050,841,-15 @Parent { @parentID = advMiniaturization } } } // Control / RCS // @PART[RLA_rcs_2way]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = advFlightControl // } // @PART[RLA_rcs45_2way]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = advFlightControl // } //@PART[RLA_rcs_linear]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = flightControl //} // @PART[RLA_rcs_micro45]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = advFlightControl // } // @PART[RLA_rcs_micro]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = advFlightControl // } // @PART[RLA_rcs_micro_linear]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = advFlightControl // } // @PART[RLA_rcs45]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = advFlightControl // } // @PART[RLA_rcs_5way]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = specializedControl // } // Control / Reaction Wheel @PART[RLA_tiny_torque_radial]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advFlightControl } // Electrical / Solar @PART[RLA_medium_solarpanel]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advPVMaterials } // Electrical / RTG @PART[RLA_mmrtg]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = nuclearFuelSystems } // Electrical / FuelCells // @PART[RLA_mp_small_fuelcell]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = largeElectrics // } // Engine / Small Electric @PART[RLA_small_arcjet]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = highTechElectricalSystems // lowTechIonPropulsion would be handy } // @PART[RLA_small_ion]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = ionPropulsion // } @PART[RLA_small_resistojet]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = highTechElectricalSystems // lowTechIonPropulsion would be handy } // Engine / LiquidFuel @PART[RLA_lfo_medium_linearspike]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_165 } @PART[RLA_small_highthrust]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = miniaturization } @PART[RLA_small_spike]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = precisionEngineering } @PART[RLA_tiny_vac]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = precisionEngineering // maybe a node higher if that would exist } // @PART[RLA_small_ntr]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = nuclearPropulsion // } // Engine / Monopropellant @PART[RLA_mp_large_spike]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_6296 } @PART[RLA_mp_large_vac]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_6296 } @PART[RLA_mp_medium_vac]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_165 } @PART[RLA_mp_small_radial]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advMiniaturization } @PART[RLA_mp_small_stack]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advMiniaturization } @PART[RLA_mp_tiny_radial]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advMiniaturization } @PART[RLA_mp_tiny_stack]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advMiniaturization } // Engine / Solid Boosters @PART[RLA_solid_medium_upper]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = AdvancedSRB } @PART[RLA_solid_small_long]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = AdvancedSRB } @PART[RLA_solid_small_medium]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = AdvancedSRB } @PART[RLA_solid_small_short]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = solidRockets } // Tanks / LFO Small @PART[RLA_small_LFO_tank0]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advMiniaturization } @PART[RLA_small_LFO_tank1]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advMiniaturization } @PART[RLA_small_LFO_tank2]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = miniaturization } @PART[RLA_small_LFO_tank3]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = miniaturization } @PART[RLA_small_LFO_tank4]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advMiniaturization } // Tanks / MP Various @PART[RLA_large_mptank]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = largeControl } @PART[RLA_medium_mptank]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = largeControl } @PART[RLA_small_mptank]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = flightControl } @PART[RLA_tiny_mptank_rad]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = flightControl } // Tanks / X Small // @PART[RLA_x_small_tank]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = ionPropulsion // } // Small Probe @PART[RLA_small_probe_24sides_gold]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_1779 } @PART[RLA_small_probe_24sides]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = advUnmanned } @PART[RLA_small_probe_4sides_gold]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_1779 } @PART[RLA_small_probe_4sides]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = unmannedTech } @PART[RLA_small_probe_6sides_gold]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_1779 } @PART[RLA_small_probe_8sides_gold]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_1779 } @PART[RLA_small_probe_QBE_gold]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_1779 } // Structural / Frames // @PART[RLA_large_frame]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = fieldScience // } // @PART[RLA_medium_frame]:NEEDS[zETT,RLA_Stockalike]:FINAL { // @TechRequired = fieldScience // } // Structural / Med2Small Adapters @PART[RLA_med2small_biadap]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = precisionPropulsion } @PART[RLA_med2small_triadap]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_165 } @PART[RLA_med2small_quadadap]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_165 } // Structural / Various @PART[RLA_medium_radext]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = nanolathing // seems a bit cheap } @PART[RLA_small_attach_radial]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = nanolathing // seems a bit cheap } @PART[RLA_small_decoupler_radial]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = KETT_3178 } @PART[RLA_small_decoupler_stack]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = miniaturization } @PART[RLA_small_radext]:NEEDS[zETT,RLA_Stockalike]:FINAL { @TechRequired = nanolathing // seems a bit cheap } [/CODE] [/spoiler] If you don't like the inserted "Advanced Rocketry 0.625" node, just remove the two "RDNode" sections in the beginning and replace every occurance of "advMiniaturization" with "miniaturization". I also considered inserting a node between "Nickel Metal-Hydride" and "Ion Propulsion" (maybe "Electrical Propulsion") for the two engines I put in NiMH, but was to lazy so far :P Also, maybe the three parts I put in "Advanced Bearings" could have gone in "RadialDecouplers2" as there already is another "Radial Attachment Point" in there. I only discovered it when I was done with it (and on the other hand "Advanced Bearings" was empty for me before). The parts which are commented out (those with the two slashes in front), are the ones where the TechRequirement stayed the same as in original RLA_Stockalike mod, as it seemed correct with the ETT tree as well.

[quote name='TMS']Could somebody comment on why Blogs will be removed, given that IPB has that functionality? Ideally, can the explanation be added to the OP? TIA[/QUOTE] And why the blog content is not at least preserved in a read-only area. As a blog consumer I'm worried that useful information is lost, because the author is no longer interested or has no time to carry it over. It may still be of interest to hundreds of readers.

[B]@KasperVId: [/B]There are two things that worry me most: [LIST=1] [*]Blogs contain a lot of useful information for all of us even if the author is no longer active in the community. So, relying on the authors to preserve those, seems to be a really bad idea. So, could you please just [B]automatically[/B] [B]carry over the blogs as (read-only?) posts[/B] to the new forum (maybe in a Blogs subforum or so). [*]There are a lot of external places that link to forum threads. Google results, Github, KerbalStuff were already mentioned, I'll add CKAN to the list. While links within the forum can (and hopefully will) be automatically converted, that's not possible for links from outside. Would it be possible for the [B]URLs to old threads to just forward to the new location[/B] on the new forum? [/LIST] Moreover, an advance notice of one week (including only [B]one[/B] [B]weekend[/B]) seems extremely short. If people are working during the week and have other things to do on this weekend (or are on vacation) they have no chance to save their work. Maybe you could just [B]preserve the old forum installation under a different URL and in read-only mode for a month or two[/B]? That would give people a fair time to migrate their content.

BTW: Thanks to the staff for participating so actively in the discussions, recently. There were times not so long ago, where the devnotes seemed like fire-and-forget. And I also join the crowd thanking for the great detail in the devnotes. It's really appreciated!

[quote name='Dr_Turkey']No! We march till victory is ours.[/QUOTE] I really hope this was meant tongue-in-cheek. [quote name='Taowulf']hell no. He delays Christmas. Then 1.1 will not be late.[/QUOTE] Who said Christmas [B]this year[/B]? :D

[quote name='MrOsterman']..... That the save game features are broken and you need to click "Save" rather than hitting Enter? I'm still a little cheesed over how often I've lost my "backups" to that bug. Upside is that it did, briefly, force me into a "Well you done screwed that one up" moments that forced me to go back and fix things which ultimately were kind of fun, but I really would have preferred to know that was the case.[/QUOTE] For this Dated QuickSaves of [URL="http://forum.kerbalspaceprogram.com/threads/107663-1-0-x-Magico13-s-Modlets-%28Field-Experience-Sensible-Screenshot-etc-%29"]Magico13's Modlets[/URL] might ease your pain a bit. It automatically copies unnamed quicksaves (those created by F5) to a name including timestamps, so you automatically keep previous saves. It also performs autosaves. Still works in 1.0.5.

What bothers me even more about staging is that after you got everything right and then notice you need to insert a tank or so, after stripping off and re-attaching the lower stages, they'll mess up again. Always! :mad: I could swear that in 0.90 they remembered the staging before the detachment and restored it after the re-attachment. Or was I just dreaming?

[quote name='LitaAlto']Just following up on my post. I upgraded to 0.2.10--no change. And I just realized that my base [I]does[/I] have an antenna directly attached to the planetary lab. But transmitting science from there is still not possible. I didn't see any noteworthy issues in output_log.txt, aside from "WheelCollier requires an attached Rigidbody to function" arising because I used the old combo wheels/legs. I can post the whole file if deemed necessary.[/QUOTE] Do you use RemoteTech? There are known issues with transmitting science with the current RemoteTech 1.6.9 on KSP 1.0.5.

[quote name='blizzy78']Hate to say it, but have you been rebasing [B]regularly[/B]? 390 conflicts sounds like a hell of a mess that shouldn't have happened in the first place. You can't just rebase at the end of a large chunk of work, you need to rebase regularly, say daily. Yes, you will be getting conflicts, but only a few per rebase, not a huge pile.[/QUOTE] Exactly, what I was thinking. From what I got, they merged two lines of development going rather indepently for the last 6 months. From my experience this will have resulted in quite a few bugs that haven't been caught. It's inevitable that during a 3-days merge something is dropped under the table and lost. We are all just [s]human[/s] kerbal. Unfortunately, by rebasing and thus effectively changing the past in git it might be really hard or even impossible to detect now. Merging might have been the better option in this case. Anyway, this is spilled milk now. We can't change the past like in git ;) I'm sincerely hoping that I'm just overly pessimistic and it did not cause that many hidden problems.