linuxgurugamer

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes OS: Microsoft Windows 10 Pro 10.0.19045 64-bit | CPU: 13th Gen Intel(R) Core(TM) i9-13900K (32) | GPU: AMD Radeon RX 7900 XT (20423MB) | RAM: 65276 This landing gear looks ok in the VAB, but on the runway, the wheels don't all show in the same direction Included Attachments: LY-60landinggearnotdisplayingproperly_logs.zip

New release, 0.5.0 Removed all reference to the allInOne option, not used anymore Thanks to forum user @anth12 for suggesting a lot of the following: Created installer Updated URL for bug reporting Put the installed files within their own folder within the KSP2 Installation folder Added shortcut to desktop GUI stuff Added window to display system specs, to make it easier to copy/paste to bugpage Added button to open the reports folder Added selection of first item in list box Added buttons to copy the OS, CPU, RAM and GPU info to the clipboard

New release, 2.0.1 Deleted duplicated part name in the KIS.cfg Commented out the references to the old mod neverUnload, since it hasn't been around since 2013 Moved missing cfg files into a MM_Patches directory Updated some of the NEEDS tags Updated CKAN to list all supported mods: BDArmoryContinued Graphotron InterstellarTechnologies KAS KerbalEngineer MechJeb2 RemoteTech ScanSAT TarsierSpaceTech kOS

I found a few missing cfg files which add what's needed for the parts to be working. I'll need a few days to be sure there isn't duplicated code in the files after MM finishes And I'll add your texture switch code to all of them One of the missing cfg files incudes this for all the parts

I think you need KAS in order to do anything. Try installing that and see what happens

FYI, the way you ping someone is by using an @ infront of their name. IE: @orionguy I'll look into this, this evening Ummm, try installing the mods which it uses, see this snippet from the log: [LOG 17:20:18.664] Deleting node in file ChromaWorks/Parts/ComputerPackage/chip/chip_antenna subnode: PART/MODULE:NEEDS[KAS] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting node in file ChromaWorks/Parts/ComputerPackage/chip/chip_B9_info subnode: PART/MODULE:NEEDS[KAS] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting node in file ChromaWorks/Parts/ComputerPackage/chip/chip_barometer subnode: PART/MODULE:NEEDS[KAS] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting node in file ChromaWorks/Parts/ComputerPackage/chip/chip_basic subnode: PART/MODULE:NEEDS[KAS] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting node in file ChromaWorks/Parts/ComputerPackage/chip/chip_basic_v2 subnode: PART/MODULE:NEEDS[KAS] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_graphotron node: PART:NEEDS[Graphotron] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_ID_tag node: PART:NEEDS[BDArmoryContinued] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_KER_build node: PART:NEEDS[KerbalEngineerRedux] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_KER_flight node: PART:NEEDS[KerbalEngineerRedux] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_kOS node: PART:NEEDS[kOS] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_mechJeb node: PART:NEEDS[MechJeb2] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_RT_antenna node: PART:NEEDS[RemoteTech] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_RT_SPU node: PART:NEEDS[RemoteTech] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_ScanSat-Traq node: PART:NEEDS[ScanSAT] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_superComputer node: PART:NEEDS[InterstellarTechnologies] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_TarsierSpaceTech node: PART:NEEDS[TarsierSpaceTech] as it can't satisfy its NEEDS [LOG 17:20:18.664] Deleting root node in file ChromaWorks/Parts/ComputerPackage/chip/chip_TT_neverUnload node: PART:NEEDS[TTNeverUnload] as it can't satisfy its NEEDS Looks like it deletes all the chips which don't have the mods needed.

I'm working on a new release, should be out in a few days. Will include an installer and some gui improvements

Try 3.4.4.1 before you do anything else

Well, you can copy from the text file

New release, 3.4.4.1 Added code to check for key values for toggleSymMode and toggleAngleSnap being null upon entry, if they are, then it resets to the default (X & C) and saves the settings This should put this bug to bed. While I'm not sure what's happening, somehow these two key values have been set to None, apparently at random upon exiting from the editor. But after a couple of fortitious instances, I was able to see some of what's happening. It may be do to a conflict with another mod which was also doing something with these keys and it being a timing issue, where sometimes that mod would override the values after EEX was done. For now, the values are being hard-reset (if necessary) to the X and C values, which are the game defaults. These are the same values that the Reset Symmetry Mode & Angle Snap keys were using, and since I haven't heard any complaints about those, I'll leave these for now

Hello and welcome. Is there anything you need help with?

Yuck. Oh well, more hunting for this bug

I'll make a special build of the mod and send it to you for testing If that's the Notes made by Hashashin & Zer0Kerbal, that's not my mod I'll do this one.

If I got you a special build, of one of those mods, would you be willing to run it and then send me the output? I want to write some data to the log file to see if I can track this down. Unfortunately, the list of mods you list which work includes a number of mine which work the same way (ie: internal code), so there doesn't (yet) seem to be a pattern. If you are, then let me know which one it is most consistent on, and I'll make a special build for you

New release, 3.4.4 Moved initiation of cached values for the toggles from being initted at class instantiation to in the Start I think this might fix the problem of the key toggles for Symmetry mode and Angle snap of being set to null. Please let me know if it happens after you install this version LGG

I have an idea for a fix, watch for an update

I remember this. The only thing I can think of is that you are running a French version of Windows, which _might_ be doing something funny with the paths? I just tested the mod, and it worked fine on my system, but I'm using an english system. I'll think about this, see if I can figure out something to help. Is it only with a few mods, or is it with all that use the toolbar?

Is it really every time, or just most? It's something that I may look into, but need to be able to replicate it. It only happens occasionally for me with my JNSQ. Wierd

Next time, try using the KSP2 Bug Reporter:

Refresh my memory, what "negative effect"?

Thanks for pinging me. it must have been reverted in another process, but I just did it again. And, I just did a refresh, it's now out there

The problem with RPM has been solved. Until a patch is made, either in the DF mod or RPM mod, add the following to a CFG file: // RPM is no longer inserting the computer, so this does it @PART[CRY-2300Freezer,CRY-0300RFreezer,CRY-1300Freezer,CRY-0300Freezer]:HAS[!MODULE[RasterPropMonitorComputer]]:NEEDS[RasterPropMonitor] { MODULE { name = RasterPropMonitorComputer } }

Ok, so I added it using a patch: @PART[CRY-2300Freezer,CRY-0300RFreezer,CRY-1300Freezer,CRY-0300Freezer]:NEEDS[RasterPropMonitor] { MODULE { name = RasterPropMonitorComputer } } and it works!

Ok, but that shouldn't cause a CTD. That indicates a lack of error checking. Given that this is being used with DeepFreeze (at least) which is somewhat idle, I think you should add a patch to add that to the DF parts.

The only thing this would cause would be a purple button on the Blizzy toolbar