Lisias

I think that mirrored gears are always "inverted" when put on the symmetrical point - but since some of them are already symmetrical in shape, the net result is an apparent copy of the mesh. So I made this monstrosity, and gone peeking on the .craft file. I have three identical gears - one pair is mirrored, the third is not. Let's compare: Mirrored Gear 1: PART { part = GearFixed_4293761660 partName = Part persistentId = 1351969621 pos = -0.585137546,9.84321308,-0.150621384 attPos = 0,0,0 attPos0 = -0.585137546,-0.150621355,0.156786948 rot = 0.00416839123,0.0108874142,0.130581394,0.991369128 attRot = 0,0,0,1 attRot0 = -0.698056281,0.100033544,0.08463642,0.703951299 mir = 1,1,1 symMethod = Mirror autostrutMode = ForceHeaviest rigidAttachment = False istg = -1 resPri = 0 dstg = 0 sidx = -1 sqor = -1 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = GearFixed_4293761560 srfN = srfAttach,Mark1Cockpit_4293781902 Mirrored Gear 2 (counter part): PART { part = GearFixed_4293761560 partName = Part persistentId = 1350094561 pos = 0.585137546,9.84321308,-0.150621444 attPos = 0,0,0 attPos0 = 0.585137546,-0.150621414,0.156786948 rot = 0.130581379,0.991369128,0.00416839123,0.0108873807 attRot = 0,0,0,1 attRot0 = 0.0846364349,0.703951299,-0.698056281,0.100033514 mir = 1,1,-1 symMethod = Mirror autostrutMode = ForceHeaviest rigidAttachment = False istg = -1 resPri = 0 dstg = 0 sidx = -1 sqor = -1 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 sym = GearFixed_4293761660 srfN = srfAttach,Mark1Cockpit_4293781902 ------- And finally, the single gear: PART { part = GearFixed_4293760032 partName = Part persistentId = 731760417 pos = -0.090433903,9.84336376,2.865376 attPos = 0,0,0 attPos0 = -0.090433903,2.86537576,0.156636 rot = -0.132891148,0.240856349,0.47938621,0.833377004 attRot = 0,0,0,1 attRot0 = -0.683254719,0.509288371,0.168666065,0.495318294 mir = 1,1,-1 symMethod = Mirror autostrutMode = ForceHeaviest rigidAttachment = False istg = -1 resPri = 0 dstg = 0 sidx = -1 sqor = -1 sepI = -1 attm = 1 modCost = 0 modMass = 0 modSize = 0,0,0 srfN = srfAttach,Mark1Cockpit_4293781902 ——— My current conclusion (subject to change as more informed people gathers here!) is that the "symMethod" alone doesn't define a mirrored part, you need **also** to define the counterpart on the "sym" field. The magic appears to be made by using the "mir" field, where you use a "-1" to indicate the axis you wanna invert. Apparently using the -1 on the third value invert the part the way we want on gears. Note the "pos" field - the first value is the X axis, negative numbers are "from the left", positive numbers are "to the right". Y is from the bottom to the top (see how all gears are on the same Y plane!), and Z is from back to the front (note how the third gear change the 3rd value relative to the first pair!). Building a craft like that and playing with that numbers on the craft file will render some interesting information!

Crashing is something I have a interest on! This was already tried before?

I found an issue with Atmospheric Autopilot. The first time you load your pre-existent (or downloaded) crafts, you loose the Control Surfaces configurations, as AA changes the name of that module to SyncModuleControSurface, and then the data under the ModuleControlSurface are lost. This used to work fine until 2014 more or less (see here), but obviously something changed in the mean time. AA made a "hack" by resetting the mirror info by brute-force, but that way doesn't works with B9's control surfaces. So, currently, I'm trying to figure out a way to overcome that.

By the way, a tool to "fix" broken or unset mirrored control surfaces would be hugely welcomed. Editor Extensions Redux is probably the tool that should implement it.

Are you sure? I'm using this one on my 1.6.1 installment: https://github.com/TidalStream/ProceduralParts/releases

Any part willing to use ModuleControlSurface needs to be aware of the following features: PartModule OnEditorAttach event handler symMethod field symmetryCounterparts field ModuleControlSurface usesMirrorDeploy field mirrorDeploy field partDeployInvert field Your part module must hook a EventHandler to the OnEditorAttach: part.OnEditorAttach += new Callback(UpdateOnEditorAttach); So, everytime the user attaches something with your module on another part on the Editor, you will be notified. On the event handler, you need to check the Symmetry Method - on this case, we need to check for the Mirror one. And then set some ModuleControlSurface flags, as follows: Check if the part has any Counter Parts on the Symmetry - no need to waste time when the part has no mirrored part! (technically, a bug but whatever - better safe than sorry). To be really pick, one should check if the Count is exactly one, but if you get a situation where a mirrored part has more than one, the user have a lot of worse problems to cope wth. Get a pointer to the ModuleControlSurface instance of the part. Get a pointer to the mirror counterpart's ModuleControlSurface of this part. set usesMirrorDeploy to TRUE set mirrorDeploy differently for each part using some criteria (any one fits, the important part is that one gets TRUE and the other gets FALSE) For a reason beyond my grasp, on B9 Procedural Control Surfaces you need to set partDeployInvert to the negation of the mirrorDeploy. Stock Control Surfaces doesn't use that. And that's it. Here is the code I used on my pull request to B9's Procedural Wings (released under the MIT, by the way): public void Start( { part.OnEditorAttach += SetupMirroredCntrlSrf; } private void SetupMirroredCntrlSrf() { if (part.symMethod == SymmetryMethod.Mirror && part.symmetryCounterparts.Count > 0) if (this.part.Modules.Contains<ModuleControlSurface>()) { ModuleControlSurface m = this.part.Modules.GetModule<ModuleControlSurface>(); m.usesMirrorDeploy = true; { Part other = part.symmetryCounterparts[0]; m.mirrorDeploy = this.part.transform.position.x > other.transform.position.x; m.partDeployInvert = !m.mirrorDeploy; } } } And that's it! Any part willing to implement mirrored behaviours (as elevons and flaps) and uses ModuleControlSurfaceonly need to do this, and that's it!

Yaeh. Me too. I fixed that on the second push request. — — — — There's an issue with Atmospheric AutoPilot. I'm trying to figure out a way out of the mess before Jebman82's next release (and without a change on AA, currently the only way I found to survive this).

There's a fix being tested. It will probably be available next release of Jebman82's fork. Proof:

I usually deploy my games on ~/Applications . I can run the programs with full R/W accesses to the DLLs (don't ask, but KSP don't load on a R/O filesystem! the DLL must be writable by the running user), and Apple don't bothers me on security issues.

I'm fixed (yet another) Add'On, made the thing work as it was originally intended and packed the thing for testing. It borked beautifully on the test bed, besides working fine on the dev installment. (sigh) I will save you the details, but after an entire afternoon of troubleshooting, I realized that I plain forgot to run the deploy script, so the the new DLL was not being deployed, and the test bed had a forgotten older DLL that wasn't being overwritten as I intended it to be. Working late night on weekdays before going to bed is a risky business.

KSP-RO's fork fixed a glitch with some really heavy vessels losing the PRELAUNCH status while still clamped - apparently this happens when the vessel goes to rails and then back. I didn't managed to reproduced it on the Meiru's code (merged on my fork) - he revamped the Clamps code, perhaps he just got rid of the very possibility of the issue, instead of fixing it when it happens (moar testing needed! ). But one thing that MeiruMeiru's code does better is that it's faster. You can build bigger vessels, or run it on potato machines, and still be playable. If you have perfromance issues on the "classic" KJR, try my fork to see what you get.

About Earthrise, I found this. Very, very good documentary, with the very people that did it.

Thx for the log! I didn't found anything wrong related to KJR, but noticed that the latests TweakScale withdrew itself from some parts due known (serious) problems: [WRN 23:23:59.925] [TweakScale] Removing TweakScale support for CAIRF. [ERR 23:23:59.925] [TweakScale] Part CAIRF didn't passed the sanity check due using FSbuoyancy module - see issue #9 https://github.com/net-lisias-ksp/TweakScale/issues/9. I also found a lot of missing props (that thingies that we put inside cockpits): [....] [LOG 23:23:48.311] Cannot find InternalProp 'LifeSupportMonitor' [LOG 23:23:48.311] Cannot find InternalProp 'ASET_RotationCtrl_V2' [....] You probably would want to read the Near Future Thread to find what you need to add these props to your KSP. — — — Since this is not (apparently) related to KJR, may I ask you to send me such logs in private messages? So people willing to know about KJR would not be bored reading about things unrelated!

It's not relevant for the spaghetification, but you may want to use KSP-AVC (and delete all MiniAVC.dll from your GameData) due a lot of these: [LOG 10:42:33.045] MiniAVC -> System.IO.IOException: Sharing violation on path C:\Kerbal Space Program\GameData\000_USITools\MiniAVC.xml at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0 at System.IO.FileStream..ctor (System.String path, FileMode mode) [0x00000] in <filename unknown>:0 at MiniAVC.AddonSettings.Load (System.String rootPath) [0x00000] in <filename unknown>:0 at MiniAVC.AddonLibrary.ProcessAddonPopulation (System.Object state) [0x00000] in <filename unknown>:0 I suspect MiniAVC is missing some updates for you. — — POST — EDIT — — *THIS* is relevante for the spaghetification! There's no KJR (not mine nor anyone else!) on your GameData! Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 KSPe v2.1.0.6 Firespitter v7.3.6867.18541 ModuleManager v3.1.0.0 ModuleManager v3.1.1.0 ModuleManager v4.0.1.0 KSPAPIExtensions v2.1.0.6 MiniAVC v1.0.3.2 USITools v1.0.0.0 CCK v4.0.0.0 / v4.0.0.0 for KSP 1.5.0 DMModuleScienceAnimateGeneric v0.20.0.0 InterstellarFuelSwitch v3.6.18.3 MiniAVC v1.0.3.2 Scale_Redist v1.0.0.0 KIS v1.17.6967.42198 / v1.17 for KSP 1.6+ KSPDev_Utils.1.1 v1.1.6967.2347 / v1.1 for KSP v1.6+ MiniAVC v1.2.0.7 MechJeb2 v2.5.1.0 / v / v2.8.1.0 MiniAVC v1.2.0.6 BackgroundResources v1.5.0.0 MiniAVC v1.2.0.6 RetractableLiftingSurface v0.1.5.5 / v1.0.0.0 CLSInterfaces v1.2.0.0 ShipManifest v5.2.1.0 SmokeScreen v2.8.0.0 MiniAVC v1.0.3.2 TacLifeSupport v0.13.11.0 / v0.13.11 MiniAVC v1.2.0.6 ToadicusTools v0.22.3.3 MiniAVC v1.2.0.6 TweakableDeployablePanels v0.1.26.0 TweakableDockingNode v0.1.26.0 TweakableEVA v0.1.26.0 TweakableFuelPumps v0.1.26.0 TweakableGimbals v0.1.26.0 TweakableIntakes v0.1.26.0 TweakableParachutes v0.1.26.0 TweakableReactionWheels v0.1.26.0 TweakableSAS v0.1.26.0 Scale v2.4.0.7 Scale_Redist v1.0.0.0

Yes. Unzip the ZIP into your KSP_ROOT and things will go to their place (ie, <ZIP>/GameData/<Plugin> into <KSP>/GameData/<Plugin> and <ZIP>/PluginData/<Plugin> into <KSP>/PluginData/<Plugin> - when existent).

Once you find the time and the mood, yes please. I'm compiling a database of the most common problems and borks on KSP, and those logs will be very handy to it. It's time for some serious DevOps tools here.

So I need the new log to see what else is broken. Computer programs are a Castle of Cards - you need every one on the place, or things will not work as expected.

You see, KSPe is a marvelous tool. But it lacks safeties. Publish the whole log somewhere. KSPe appears to had freaked out due something, and this something can be anywhere on the log file. I need the full log to see what's happening. Until the moment, every single occurrence of that is due some DLL failed to be loaded, breaking something inside Mono's VM data structures for Reflection, and KSPe borking while trying to use Reflection for something. The only way, until the moment, to fix this is to satisfy every DLL dependency, or delete the ones that cannot be loaded from the GameData.

Do you remember that? What do you say about this:

If you want to use my fork, you need to read this post: If you/your friend are using KSP 1.4.x and prefer something more orthodox, you only need KSP-RO's download. Unziping files into the GameData is not hard, but how to do it depends on the O.S. your are using. There're tons of tutorials on the Net about this subject.

Do you want some popcorns? I made some. Agreed. However, hard players usually wants to be recognized as such - it's the reason, for example, that some mainstream games remove badges or the ability to publish highscores when you use a "cheat" (note the quotes), and segregate highscores by dificulty level. Some games even mock you if you select an easy mode ("Don't hurt me" on Doom, oh boy, had my friends knew… hehe). Some kind of middle ground is needed, IMHO. On the other hand, there're players that for a reason or another are denied the use of joysticks, motor coordination (don't look on me! ) or just can't install Add'Ons (as console players). And these guys had also spend some money on the game. Using again the Doom metaphor, the "Don't hurt me, please" and the "Nightmare!" skill levels are not mutually exclusive - you can have both, and expand your paying users a bit. And if such auto-pilot would teach the user about the steps it's doing to land the craft, you will have nice learning tool.

The most recent appears to be KSP-RO's fork. But it's locked down to 1.4.x versions. This is ferram4's original code recompiled to 1.4, and I think there's some fixes by now. it has a fix about clamped vessels shifting from PRELAUNCH by a physics glitch. I think the second most recent is mine (you need to install this too). This ones has a lot (really lot) of fixes did by meirumeiru merged (that may or may not include the above mentioned one, I need to check -[just checked, that problem, if it has even happened on this fork, had been tackled down differently), and some improvements from yours truly. And I successfully tested this on every KSP version I tried it since 1.2.2 inclusive.

It may work as long you don't use any of the revamped parts, much less the new ones. Last time I checked, it would work only for parts that would run on 1.3.1. (on 1.4.0, new things started to introduced to KSP, so it's theoretically possible that Ubioweld will bork on a 1.4 compatible part)

Do you remember when they told us that in Real Life we don't just strap parts together to make an airplane? Well, someone tell that to these guys! (gp to 10:00 ) (excellent documentary by the way, it worths to see it wholly).

Real Life propellers also have adjustable pitch and and real life engines has fuel/air mixture. All of this is abstracted on KSP. Performance props adjusts the throttle in order to keep the engine on the best fuel/power rated RPM. The props are then pitched to get the needed thrust given that RPM. The fuel/air mixture lever is adjusted so you don't inject more fuel than is possible to burn given the current altitude' air pressure and oxygen availability, and so avoid wasting fuel by throwing it away with the exhaust. Throttle is not the same as Thrust. Stock KSP models Thrust, and the rest is simulated by other means (as drag). You need Firespitter if you want something more similar to real-life - but even Firespitter don't have propellers with adjustable pitch neither engines with fuel/air mixture levers. That lever on the Glide? It sets Thrust, not the engine's throttle! Kitty is a TurboProp, not a Piston engine. It's a completely different engine, that must be simulated differently than Piston engines! And the thing was modeled by another guy, so he could had choose to simulate the engine limitations by other means. Give a look on this video, it will explain how a turboprop works! POST EDIT: The A7 is a turboprop too! So a direct comparison to the Kitty is adequated, my apologies! I made a throughly research on stock engines and compared them to what apparently were the real-life equivalent, and apparently KSP engines are modeled to be equivalent to the thrust of the RL counterpart. The J404 appears to be the Kerbal equivalent of the F404 RL Jet Engine. And they both have 85kN of static thrust. This is the engine used by the F18 Hornet (it takes two) The Cessna Citation uses two 18.2 kN jet engines. Kitty is a small TurboProp, and it has 65kN of trust? Sounds excessive to me. The A7 definitely looks good to me. I just checked again some material, and (Re)learnt that kN is usually the "net thrust" of the engine (engine power * drag * prop efficiency), while the raw power is given in kW. While by definition 1kW == 1kN, we can't just take the raw power of the engine and use it as thrust! Remember, KSP models engine THRUST, not power. Kitty is just too small of an engine and with too small of a propeller to give you 64kN of THRUST. Yep. Will not be fixed because it's not broken! (couldn't resist. ). I just checked, that cockpit is called Clyde, and it's from SXT. And the front mount is non-stock, it have a 1.175 bulkhead while the A7 is a stock 1.250m. But you still have options! Check this images (click on them to go to the slide with the caption): (link) (link)