tecknobabble

This pretty much sums up how I feel about this issue, thank you for saving me from having to articulate it myself. My experience under x64 has been relatively trouble free, certainly no worse than with x86, and unfortunately because of this schism I've been playing it less because mods I used, enjoyed and relied on have been blocked from my environment of choice. Not sure I am going to take any side, I'm more likely to devote my time to something less fractious instead and see if things improve with later releases.

Guess I'm in the "works for me" club too. I've not noticed much difference between my previous play on the 32-bit versions and the 64-bit 0.24.

This module manager change swaps round the chargeRates before the WarpPlugin configuration is processed. That added waste heat to the Balka panels on one of my in-flight craft: @PART[Kosmos_Balka_PanelBlock1]:BEFORE[WarpPlugin] { @MODULE[ModuleDeployableSolarPanel],0 { @chargeRate = 400 } @MODULE[ModuleDeployableSolarPanel],1 { @chargeRate = 0 } }

Peeked at the source. string FindPartMod(AvailablePart part) { UrlDir.UrlConfig config = Array.Find<UrlDir.UrlConfig>(configs, (c => (part.name == c.name.Replace('_', '.')))); if (config == null) return ""; var id = new UrlDir.UrlIdentifier(config.url); return id[0]; } Problem is the penultimate line, which is returning the first element in the string array returned from the UrlDir.UrlIdentifier() call. In theory it just needs a loop to concatenate the elements of the array together and return that...

What was suggested was very subtle. The problem is the different type of brackets... you had: ( @TechRequired = advElectrics } That is, opening bracket is a plain parenthesis while the closing one is a curly bracket. Depending on your font the difference could be very subtle in the forum posting. MeCripp's second suggestion corrected it to: { @TechRequired = advElectrics } I would suspect the different brackets would cause a problem.

There doesn't seem to be that sort of naming consistency to Procedural Wings parts.... most, but not all the part names have "Procedural" in them somewhere, except one control surface. The all have the WingManipulator module, so a tweak to the above could be: @PART[*]:HAS[@MODULE[WingManipulator]] { @maxTemp = 1700 MODULE { name = ModuleHeatShield direction = 0, 0, 0 // full-surface coating reflective = 0.1 } }

A better indication as to whether it is enabled or not would be useful so you know what state it's really in.

Thanks to both of you... with the updated version my test SSTO craft with a rapier gets to orbit without the engine deconstructing itself.

When I see the problem all the F3 log says is RAPIER engine exceeded g-force conditions. At the time the craft was in level stable flight, g-force needle in the green, doing 1056 m/s at a height of 17km. Highest g-force experienced was 4.8g, but that was earlier in the flight. Manually switching to the rocket mode does avoid the problem, but that should be unnecessary as there's still enough air intake to stay in air-breathing mode.

Ok. I thought of it more of a function of the vessel. It has a set of private resources for each crew member. Those give them their starting resources for the EVA. On return from EVA the vessel resources for the crew member (assume there's some index to abstract crew identity) are updated. If they then make a subsequent EVA a check if made to see if they need a top up, at which point resources are drawn from the vessel's main tanks, if available. More work to implement, but slightly more elegant than having to stick RCS on a vessel with no RCS thrusters to perform an EVA. I'll shut up now

Just a thought, and rather minor, but shouldn't the first EVA be free? That is the suit's EVA primary life support pack/maneuvering system (o2/rcs) is already fully charged at launch. If a Kerbal EVAs, then when he returns the suit is depleted by whatever resources are consumed during the EVA. If subsequent EVAs are made then the suit/pack needs to be replenished from the resources in the vessel to ensure it's full prior to the next EVA commencing. If the ship has no RCS then only the o2 is replenished. If there is no subsequent EVA no resources are taken from the vessel.

The new standalone docking camera download doesn't have any parts. I have the parts from the previous version so everything appears to be working fine - I did remove the old Romfarer.dll from the plugins directory before putting the 0.20 bits in its new location in the GameData folder, but I've left the parts in place.

In my case no amount of clicking on the Vessel Information in the MechJeb side panel in 1.9.8 helped. Turns out looking at the MechJeb.cfg that the windows's position co-ordinates was negative - so it wasn't visible on screen.... e.g. windowPos_MechJebModuleVesselInfo=4,-522,215,0,0 Made it match one of the others and it returned to where I could see it.