cyberKerb

March 8

17 hours ago, linuxgurugamer said:

Please try using this debug version:
https://www.dropbox.com/s/m2e679pdemdsjir/DockingCamKURS-Debug-1.3.8.6.zip?dl=0
It has some debugging statements, along with a quick patch to try to bypass the error. I NEED the Player.log so I can fix this permenantly

I also need to know your UI settings, specifically the UI Scale

Also, screen resolution, and if you are running in windowed or full screen mode

But I'd prefer the Player.log, not the KSP.log. It shows things a little differently

Edit: Very important, I need to know how you are starting the game. Please list all the steps and click you do

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.

February 19

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)

February 11

On 2/6/2024 at 1:21 AM, JeromeHeretic said:

And what about Desert airfield navigation? As i was looking, adding new navigation transmiters is not easy. It's defined on so many places. Do you understand to it?

BTW: It was just "nice to have" idea. Is teoreticaly possible build on planet real transmiter (probe core, battery, antenna) as VOR? Let say, i will do transmitter like this, and name it VOR_115.30, si it will be automaticaly visible by ASET pack as VOR on freq 115.30 MHz...

Like that you can do your navigation network on any celestial body, not just on Kerbin (you can do it anyway, and use it as VOR by selecting it as target, but ASET pack will not see it and you can use it just like target on navball.)

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

February 10

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.

February 9

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 :cool: 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)

February 5

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
  }
}

February 5

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

February 5

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)

February 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
  }
}

February 5

6 hours ago, JeromeHeretic said:

If you are collecting bugs for next release, so on this altimeter:

That tiny hand, with small triangle at the end, which looks as second hand on watch is in reality showing 10 000 (feets/meters/whatewa units), long hand, which looks as minute hand on watch shows hundreds of units and short one, which looks as hour hand shows thousands of units.

So what is on screenshot should be altimetry something like a 7900 meters (because tiny shows 7000, minute shows 900 and hour hand is completely wrong,, should be around 7) , but in game it is showing 1970 meters (hours 10 000, minute 900, tiny 70).

I don't know if this is extra setup in every IVA, or it is global settings?

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
  }
}

February 4

47 minutes ago, JonnyOThan said:

@cyberKerb if you can, it would be great to get all this info into an issue on github. It's far less likely to be lost or forgotten there.

Under the ASET-Consolidated-Props Github:

Issue #28 lodged for the Resource Display
Issue #29 lodged for the Terrain Altitude Display

February 4

On 2/2/2024 at 9:08 PM, JeromeHeretic said:

In Mk1 lander can is also non functional switch on altitude display. Switching between altitude and radar altitude is not working.
<snip>

For the "non functional" switch, it is actually functional :confused: (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.

February 2

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?

January 31

1 hour ago, JonnyOThan said:

Thanks for the report. Please always include your KSP.log file when reporting bugs or asking for support.

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

January 31

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.

January 31

Hi @JonnyOThan Firstly - thank you so much to taking on the ALCOR mod. It is my top mod to use anytime I play KSP1.
After a long break and downloaded the latest version of everything.

Found a minor bug for you in the ALCOR lander.
When flicking the switch to open the overhead shutter, (pilot seat front overhead panel, middle left side) the animation gets stuck in a loop and continuously plays the open animation without stopping.
When setting the shutter switch to close, it plays the close animation only once as expected.

January 30

Hey @linuxgurugamer!

New log file here for you when you get a chance: https://www.dropbox.com/s/545ci28oilowfpw/KSP.log?dl=0
Fresh install of latest KSP version and tried this mod.

No camera window is appearing for KSP 1.12.5.3190 after clicking the button in the PAW.
I only have the expansions and the necessary mods to run this test.
Had Notes2Log installed as requested and added a note before and after trying to open the camera window. (This doesn't help much as the part is erroring on scene load, not during operation)
The same error occurs when an instance of the part is added within the Ship editor scene.

It's giving an error in the function UnityEngine.Texture2D.Internal_Create within PartCameraModule during OnStart.
Happy to provide an additional logs or testing for you - just let me know when you have time to investigate and I'll be on it

January 30

I saw the KSP wiki page for the MK1 stock LanderCan has an old panorama pic of inside scene.

I've only just noticed there's now a number of buttons a switches missing in the current version of the game.
It's my guess that Squad removed some assets for some reason. I checked with Object inspector and confirmed there isn't anything "not showing".
The button and switch that are not immediate in front of the pilot are just no longer defined in the IVA Space config file.

Note - Not a problem, just an observation after a 3yr KSP1 hiatus.

January 30

Yep - just been on pause with other projects - but it is still a goal of mine.
I'm just returning to KSP1 and I'm currently trying to investigate which version of KSP works with the KURS camera mod. I need that for my split screen / dual monitor cockpit view

Having said that, I finally got that 3D printer I needed for this project now, but I'm thoroughly distracted with wanting to made a scaled landercan model for one of the old KSP sand Shapeways models I snagged before Squad pulled them from sale.

January 30

Awesome that people are still adding to the IVAs for KSP1.

Are using Unity 2019.4.18f1 and the parttools to do the placement?

I ask as I was looking to tweak the location of somethings, but wasn't sure if the old forum posts were still valid for the current KSP version/

September 30, 2023

Is there much in the current design scope to put the amount of ~~wobb~~ joint flexibility in the hands of the user that builds the ship?

By that, I don't means leaving autostrut on by default. I mean getting it down to a level similar to Nates description where certain parts would have an indicator to advise they can only be 'welded' to other parts (no physics cals, but still a break point for collisions), versus a part that is just 'attached' and has physics applied?

or is this temp fix more of a game design / behind the scenes fix with no user input/ choice?

February 21, 2023

Firstly - Nate, I do wish you and the team all the best for the release of KSP2. I can imaging you all pacing back and forth, like an expecting parent hoping for good news.
With all the hard work so far and plenty more still to come down the pipe, I hope this milestone fills you with the necessary positivity and thrill to build bigger and better things as you work through the roadmap.

Had a question as well - does the below comment imply there are 'features' to find or was it a mainly referring to landscape features like craters, canyons and the like?
(By all means pls reset my expectations if needed )

On 2/18/2023 at 5:34 AM, Nate Simpson said:

<snip>
Primary goal: Fly to the Mun and get a picture of a Kerbal in front of the most interesting feature you can find
<snip>

Also - will there be any feedback button for those that will be purchasing via direct download? Or is that only for Steam / Epic platforms where the bulk of people will be?

September 4, 2021

Using syncros would be quieter wouldn't it?

You could also see if a specific youtuber might want to use it for a content series / show & tell. You know of CuriousMarc? While the Navball is interesting and space related, it my not be vintage enough for him. However, if he's interested, it could be a win-win in that he gets a view videos out of the device restoration, and you get a circuit to help power it in your project.

August 10, 2021

Hey Rich, something for reference / idea on using your Navball

July 23, 2021

Great Insight Dr Dodd! Love reading the details of behind the scenes methodologies.

I had two questions for you, one of which I expect you probably knew was coming many kilo-frame-ticks away.

1) On a scale of 1m/s to 1,000,000m/s, how sad are you going to make @Danny2462? Is he likely to have to adopt Trackmania 'hunting' style game play where he spends hours / days / weeks to find a tiny incremental improvement on breaking your new KSP2 physics calculations? :wink:

2) Other question is (with tongue firmly in cheek), if 'Krakensbane' is being added to KSP2, and we have new expanses of the great unknown to explore, does that mean we'll be visiting the Kraken Homeworld?!! :0.0:

Maybe we can send a peace delegation to try and negotiate forgiveness from the species that took so many brave Kerbals from many players KSP1 experience.
To be fair, many of my previous noodle rockets were quite offensive, so I do hope the peace council doesn't devolve into a 'who started what' argument...

Articles like this directly save Kerbal lives through less sacrifices to the physics Gods (i.e you and your team) to understand their nebulous ways.

Noted exception of @Danny2462, who would sacrifice many Kerbals just to know they exist... or for a mouse cursor.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by cyberKerb