cyberKerb

Thanks @linuxgurugamer Same as you - I redownload KSP1, debugKURS, Toolbarcontroller, TuxLibrary, Notes2Log & ClickThroughBlocker I've done a numbers of tests and the results are as follows: For all program starts Doubleclick on KSP_x64.exe in Folder (portable version, not steam or package install) Launch 1 (Confirming you're not crazy - it does work out of the box) No edit to resolution 1280x720 (Windowed mode) UI Scale is 100% - left all settings as default from fresh install Created new sandbox game Clicked VAB, added lander can and onboard camera from parts list, launch Access camera PAW - Camera Launch (no issues) Quit Launch 2 (Re-Confirming you're not crazy - it still works) Resolution 2560x1440 (Fullscreen mode) UI Scale is 120% Swapped out KURS-Debug for new download from Spacedock Added ModuleManager & Squad Expansion Clicked VAB, added lander can and onboard camera from parts list, launch Access camera PAW - Camera Launch (no issues) Quit Launch 3 (Confirming I'm not crazy - reproduced error) Resolution 2560x1440 (Fullscreen mode) UI Scale is 120% Swapped out KURS for KURS from old install Clicked VAB, added lander can and onboard camera from parts list saw error in console (same as previous log) Quit Analysis Compared installs of KURS, the only difference was the DockingCamera.cfg file under DockingCamKURS\PluginData (mentioned in another users error report) Clearly the WindowSizeCoef shouldn't be 0 - also looks like the Window position data is in the winXXXX values and not the camWinXXXX values. No idea what's caused the data to generate in that order (from old installed). Especially weird as the KURS object initialises with WindowSizeCoef = 2. Below is the KURS generated file (I didn't set it manually) that is the culprit for the error: DockingCamera { WindowSizeCoef = 0 winX = 1253 winY = 341 winWidth = 306 winHeight = 210 camWinX = 0 camWinY = 0 camWinWidth = 0 camWinHeight = 0 } Many 2-step Launches later trying to get a bad config file to generate: Steps were: Launch 1: Delete DockingCamera.cfg, launch under a resolution / window/ full screen instance. Go to launch pad with camera active, quit. Launch 2: Change resolution to something lower to try and get the config to generate itself into a invalid state that is causing the error. I kept reviewing the console for errors during part attachment in VAB Failing at trying to fail KURS did not fail once during these many attempts. It kept working and I was unable to reproduce the error with a cfg file containing WindowSizeCoef = 0 I suspect there is a mod interaction here and without loading other mods to find it, it's hard to troubleshoot in isolation. (I know, the opposite of what you'd usually want) From memory, I had a number of IVA mods initially installed (ASET / ALCAR, RPM, maybe hullcam as well) when the KURS mod initially failed. My normal practice when encountering an error is to strip all mods from the install (in this case, except KURS and it's dependencies) to troubleshoot. However, in this specific error case, the invalid config was already in existence and continued to error. In retrospect, a clean reinstall of the mod probably would of fixed it. Suggested fixes: If time is short / need to work on other priorities: (No dev side changes required until known cause of cfg file being corrupted with invalid values) User Side: If getting a "Texture has out of range width / height" error during part onStart() Best to either reinstall mod from ZIP (delete all old files first) or delete file DockingCamKURS\PluginData\DockingCamera.cfg and try mod again before submitting logs Not sure if my error case is the same as others, but the error message is at least the same. However, if a few people with the same error is enough to put in a pre-emptive blocker of bad data... Dev Side: not allow WindowSizeCoef = 0 after reading in the plugin config data. In the end, I didn't bother to load any log file as all the results were successes with no hint of a problem. I'll reintroduce KURS into my KSP1 install with all other mods active. If I see the error again, I'll have a better idea what I'm looking for now that I know it relates to the cfg file That should allow me to track down what is causing it and report back here.

Hi @linuxgurugamer, just a ping in case you didn't see the initial log file in the above post. https://www.dropbox.com/s/545ci28oilowfpw/KSP.log?dl=0 Fresh install of latest KSP version and tried this mod. The KURS camera mod isn't initialising when added to a scene (flight or VAB)

I've added new Nav transmitters for the Making history DLC - but it wasn't a simple change what with each end of the runway needing to edit a separate file for Lat, Lon, Alt, Freq, LIM/LMM/LOM, Radio stations, Morse code sound files, among other things. All of it has been added into Pull Request #6 If it gets accepted, I'll look to update the ASET AEROCHARTS PDF that lists all the frequencies and add an approach map for the Dessert Airfield runways

This mod is (I think) the only mod that shows multiple external cameras, each within it's own resizable window. When combined with another LGG mod - AnyRes - which allows me to resize the KSP window across multiple screens, I've been able to create 'this' when the mod was working.

Anyone still using this mod to fly ILS at runways? Do you have the DLC? If you said yes to both of these, I've generated the elevation data for the 3 degree GS for the "36" Dessert Airfield runway. (Yes I know I'm nuts in that it's reading right to left - it's all still in test while I use the Waypoint Manager mod to manually generate 300 data points for each runway terrain profile - this is the first pass) Looking at it, I can only conclude that Jeb must of nominated the runway location when construction was first planned during DLC development. With the 3 degree GP, there's only a 14m clearance from terrain for a nominal approach While I've been mucking around at the Dessert Runway, I've tested alignment. With a line drawn 30km from either end and still seeing it bang down the middle, I can say that the angle is 1 degree off North. (Config file shows 0.4 degrees - probably doesn't make that much of a difference)

Adding this little gem of a MM Patch for those that might think to look here instead of elsewhere in the forum. Is it worth adding this to the community fix patch or would this be changing something too many people have grown used to by now? MM Patch to fix the Stock IVA Altimeter so it reads with the triangle hand being 10,000x like an IRL altimeter @PROP[AltimeterThreeHands] { @MODULE[InternalAltimeterThreeHands] { @hand100Name = MediumArm @hand1000Name = ShortArm @hand10000Name = LongArm } }

Arg! That was the thread I meant to post in. Sorry, stupid 2am brain saw the 'community' thread and got them mixed.

Easier option than changing the ASET model - change the ASET config ASET_ALTIMETER.cfg change line 23 to: controlledTransform = ALT100_arrow Add line into 34: controlledTransform = ALT1000_arrow change line 46 to: controlledTransform = ALT10_arrow ASET_ALTIMETER_Adv.cfg Line 24: controlledTransform = ALT100_arrow Line 36: controlledTransform = ALT1000_arrow Line 48: controlledTransform = ALT10_arrow (added to Issue #5)

(Edit: Sorry - wrong thread!) Adding this little gem of a MM Patch for those that might think to look here instead of elsewhere in the forum. Is it worth adding this to the community fix patch or would this be changing something too many people have grown used to by now? MM Patch to fix the Stock Altimeter so it reads with the triangle hand being 10,000x @PROP[AltimeterThreeHands] { @MODULE[InternalAltimeterThreeHands] { @hand100Name = MediumArm @hand1000Name = ShortArm @hand10000Name = LongArm } }

The cause of this is the ASET model labels / part names & mesh being 'incorrect' The 'incorrect' is given in air quotes as it matches how the stock altimeter works from the AltimeterThreeHands mu model. That issue has been around so long, and so well know, it's mentioned on the KSP Wiki and if it matches stock, is it incorrect? (IMO it's not correct, but that's down to how I play - it's up to the mod maker / maintainer to decide, the players don't get to overrule their preference) The 'fix' is to modify the ASET object names in the model I made an attempt (only to see if it's possible) to import the model into blender 2.83 via the old 'mu' plugin. After changing the object names and mesh names, exporting to a mu file again, it seems to work in game - but it has the side effect of inflating the .mu file to double the size Clearly I'm not using the correct tool for the job - but it works. This Object Show use this data value ALT10_arrow ALT1000_arrow ALT100_arrow ALT10_arrow ALT1000_arrow ALT100_arrow All info in this post was added to Issue #5 raised under the ASET-Consolidated-Avionics Noting it can't be fixed in RPM as that mod just allows you to position the stock prop without any other IVA mods installed I did a write a small MM patch, replicating an 11 year old fix by /u/deckard58 for the stock prop to change what data is used on what hand. @PROP[AltimeterThreeHands] { @MODULE[InternalAltimeterThreeHands] { @hand100Name = MediumArm @hand1000Name = ShortArm @hand10000Name = LongArm } }

Under the ASET-Consolidated-Props Github: Issue #28 lodged for the Resource Display Issue #29 lodged for the Terrain Altitude Display

For the "non functional" switch, it is actually functional (I know - it doesn't seem like it on the launch pad. After you take off and get over some terrain, you'll see it updates.. slowly) However - in the prop setup for this IVA pack, the altitude background (dark grey 888888) and decimal point values update every 1 second, but the altitude value only updates every 3 seconds. The update frequency looks like it can be changed on Line 87: RetroAltitudeDisplay.cfg to 10 instead of 30 For the value itself - that's the main issue for . It seems to be reading the RPM variable TERRAINHEIGHT. I'm thinking that is returning the height from sea level to the top of terrain. If that is the case, that would be why it's doesn't move much - and will be 0 when over water even when you are 2km over the water. "Terrain Altitude" = 0 = "Sea Level". Having said that, I've seen the Terrain Altitude indicator show -0.8 while over the Kerbin sea... sooo, not sure how it does that - it might be an old calculated variable that is usually clamped for other uses. My guess is that it should be pointing to the variable ALTITUDEBOTTOM (variable from RPM here). So the suggestion is to replace TERRAINHEIGHT for ALTITUDEBOTTOM in that Line 17: RetroAltitudeDisplay_CUSTOM.cfg file and I think it would fix this issue. Something for @Stone Blue to correct / investigate whenever they get time. (Also pinging @JonnyOThan in case he want's to correct something I stuffed up. RPM has a stack of different calculated "altitudes" (ALTITUDE, RADARALT, ALTITUDEBOTTOM, TERRAINHEIGHT, TERRAINDELTA) I might of suggested the wrong one for this prop and I can't remember which ones only work in a certain height range.

Hi Garwel - mod's looking great and I'm having fun with KSP again after a long break. Just a suggestion / request for the EVA penalty rate, is it possible to have the EVA penalty rate be 0 (or very low due to the suit) if the Kerbals helmet is off?

sure - Used notes2log mod to add comments on when I was going into IVA and when clicking the button. ksp.log Bare bones install with RPM, ALCOR, Vesselview and some of LGG support mods like Toolbar and clickthrough blocker

Hi @Stone Blue - thanks for picking up all of the ASET prop and IVAs, you are awesome to keep these masterful pieces of work from @alexustas Diving back into IVA for KSP1, I found a small display issue on the Mk1 LanderCan retro IVA - Not the IVA thought - looks to be a base issue in the Resource Quantity prop The Resource Quantity numeric display (Resource_Display/ RES_DISP_ModeSelector) shown on the left panel (has a dial to select between Off, Chrg, L/F/Oxid,Xenon) has an issue with the display order and content. The text characters (8888888.8) are always shown, the value of the resource is then shown over the top and then finally the decimal point is rendered last covering a tiny bit of the digits. It seems it's something to do with the colors assigned when displayed - I'd guess the 8888888.8 is meant to use the dull ZERO color to represent unlit segments of the numbers. The Altitude display seems to work the same and have no issues. Edit: I thought I found something that would fix it: within the file: GameData\ASET\ASET_Props\Instruments\Resource_Display\Resource_Disp.cfg change Line36 to the following with a few extra lines: positiveColor = COLOR_ASET_NUMINPUT_DISPLAY_ZEROCOLOR zeroColor = COLOR_ASET_NUMINPUT_DISPLAY_ZEROCOLOR negativeColor = COLOR_ASET_NUMINPUT_DISPLAY_ZEROCOLOR I later installed ResIVA (you get the white 888888 issue whether or not it's used) and found that it was better to just hard code the default text colour from the ResIVA patch into the default colors file of the ASET props. I couldn't find any other props that use that color identifier By changing the file: GameData\ASET\ASET_Props\GLOBALS\AsetDefaultColors.cfg it made all the 7-Segment displays to the same green as used in the DSKY (Timers / Mission Time / Stage number, etc..) ASET_NUMINPUT_DISPLAY_POSITIVECOLOR 0,255,0,255 ASET_NUMINPUT_DISPLAY_NEGATIVECOLOR 0,55,0,255 ASET_NUMINPUT_DISPLAY_ZEROCOLOR 0,0,0,255 ASET_NUMINPUT_DISPLAY_GHOSTCOLOR 0,255,0,90 I couldn't find a way to change the layer / render order or transparency for the decimal point.