Lisias

Damn, I completely forgot about this. (sigh) This is still a problem? (sorry, Real Life™ got into my way...)

Well... Obviously the Military don't want the highly busy Civilian communication overloading their military pilots with useless information for them. They operate under different rules and, at least theoretically, they have people looking for them and sorting out what they need to know from what's irrelevant for the ongoing mission. Excessive information is as good as no information at all - even the plane's warnings are prioritized, anything serious but not immediate threatening is suppressed if a immediate threat is detected by the flight computer - like a over-g warning while a close encounter with the ground is ongoing...

Being the reason we usually don't fly airplanes on warzones. This is another one of "that accidents" that I can't openly comment about without getting some moderation points (or even a lawsuit). What will not be the case on USA's mainland for the feasible future - there, the problem will be natural disasters or even a terrorist attack. A first strike, on the other hand, would prompt the VIP to get into a bunker, not to flee the area (it would be fruitless, they would be caught by the blast). You should take a peek into USA's emergency protocols since 911... It's essentially "proceed to your alternate, but I really don't care for anything but getting rid of you. bug out or you will be shot down.". Don't be. You don't want military communication overloading the already overloaded civilian channels - neither vice-versa. The root cause of the accident IMHO is allowing the crafts to get near each other at first place. How in the deepest darkness of Hell they allowed two crafts to be in a position in which they could remotely risk scratching each-other, what to say about effectively colliding to each other? Neither the HELO neither the CRJ had big, nice and shinny RADAR fed Situation Displays, and the very few military crafts that do, have them turned off to avoid disrupting the ATC's. The only dude with complete situational awareness was the ATC. TRAFFIC ALERT PAT 2-5 OVER HANS POINT NORTH-EAST OF DCA ADVISE YOU DESCEND TO 100 FEET IMMEDIATELY AND HOLD UNTIL FURTHER INSTRUCTIONS. And if by any reason the HELO would not comply in 10 seconds, immediately: TRAFFIC ALERT BLUESTREAK 5342 APPROACHING DCA RUNWAY 33 ABORT LANDING ADVISE YOU TURN LEFT 300 CLIMB TO 1000 FEET IMMEDIATELY. Anything else, AFAIK, is utterly imprudence. At best. (and even that, would already configure another near-miss event with the necessary FAA investigations being triggered)

Since you worked around the issue, from this point is for the sake of curiosity ("for science!!"). Could you please run the following command in the terminal and then send me the file it will create? cd <KSP_DIRECTORY> ls -lR > ~/Desktop/KSP.DIR.txt --- where <KSP_DIRECTORY> is where you unzipped your game, you should find a "readme.txt" file there, as well a "buildID.txt" one. Then publish the file on dropbox or something, it will be a file called "KSP.DIR.txt" in your Desktop - it will be placed randomly somewhere on it. It will be a very, VERY big file, don't try to paste it here! For example, this is a small bit of mine: .: total 3476 drwxr-xr-x 2 lisias staff 64 Nov 28 00:54 AutoSpawn drwxr-xr-x 16 lisias staff 512 Feb 14 09:08 GameData drwxr-xr-x 2 lisias staff 64 Jan 13 2023 Internals drwxr-xr-x 3 lisias staff 96 Jan 12 2023 KSP.app -rw-r--r-- 1 lisias staff 3142760 Feb 14 16:39 KSP.log drwxr-xr-x 3 lisias staff 96 Jan 12 2023 KSPLauncher.app -rwxr-xr-x 1 lisias staff 14346 Jan 12 2023 LegalNotice.txt drwxr-xr-x 10 lisias staff 320 Jan 13 00:58 Logs -rw-r--r-- 1 lisias staff 178886 Feb 14 16:39 PartDatabase.cfg drwxr-xr-x 2 lisias staff 64 Jan 13 2023 Parts -rw-r--r-- 1 lisias staff 23538 Feb 1 11:26 Physics.cfg -rwxr-xr-x 1 lisias staff 23128 Jan 12 2023 Physics.cfg.bkp drwxr-xr-x 14 lisias staff 448 Feb 14 10:01 PluginData drwxr-xr-x 2 lisias staff 64 Jan 13 2023 Plugins drwxr-xr-x 2 lisias staff 64 Jan 13 2023 Resources drwxr-xr-x 85 lisias staff 2720 Feb 14 21:54 Screenshots drwxr-xr-x 5 lisias staff 160 Nov 2 2022 Ships drwxr-xr-x 10 lisias staff 320 Apr 3 2023 UserLoadingMusics drwxr-xr-x 3 lisias staff 96 Apr 3 2023 UserLoadingScreens -rwxr-xr-x 1 lisias staff 108 Jan 12 2023 buildID.txt -rwxr-xr-x 1 lisias staff 427732 Jan 12 2023 readme.txt drwxr-xr-x 41 lisias staff 1312 Nov 19 09:51 saves -rw-r--r-- 1 lisias staff 36455 Feb 14 15:40 settings.cfg drwxr-xr-x 97 lisias staff 3104 Feb 14 10:05 thumbs ./AutoSpawn: total 0 ./GameData: total 456 drwxr-xr-x 14 lisias staff 448 Dec 9 00:51 000_KSPe -rw-r--r-- 1 lisias staff 32256 Dec 17 01:09 000_KSPe.dll -rw-r--r-- 1 lisias staff 186880 Dec 17 01:09 001_KSPe.dll -rw-r--r-- 1 lisias staff 31744 Aug 31 23:38 666_ModuleManagerWatchDog.dll -rw-r--r-- 1 lisias staff 6144 Feb 7 11:48 999_Scale_Redist.dll drwxr-xr-x 15 lisias staff 480 Aug 3 2024 DistantObject drwxr-xr-x 6 lisias staff 192 Aug 3 2024 ModularManagement drwxr-xr-x 8 lisias staff 256 Jan 27 18:42 ModuleManager -rw-r--r-- 1 lisias staff 135168 Feb 7 13:17 ModuleManager.dll drwxr-xr-x 11 lisias staff 352 Aug 31 23:38 ModuleManagerWatchDog drwxr-xr-x 28 lisias staff 896 Jan 14 2023 Squad drwxr-xr-x 4 lisias staff 128 Aug 4 2021 SquadExpansion drwxr-xr-x 3 lisias staff 96 Feb 12 18:18 net.lisias.ksp ./GameData/000_KSPe: total 132 -rw-r--r-- 1 lisias staff 35174 Dec 17 01:09 CHANGE_LOG.md <YADA YADA YADA> This is my test bed, almost nothing installed other than my testing tools, and this thing had almost 27.000 lines!

Despite decades of searching, no sign of alien life has even been confirmed, intelligent or otherwise From a video I did watch today.... Well, that's not a surprise, as we are still struggling to find (intelligent) life in our own planet... There're some hope about dolphins, however - assuming they would stick around for the fish time enough.

I found this video on YouTube yesterday, and watched it today. Pretty optimistic, but without being unrealistic - and with some new information I didn't knew about... Two possibilities exist: either we are alone in the Universe or we are not. Both are equally terrifying. Arthur C. Clarke LIFE BEYOND: Chapter 1. Alien life, deep time, and our place in cosmic history (4K). And one of the best parts are not in the video, but on the Summary: a list of every source used to create the video!

Don't worry, this is not a job. We do what we can with the time we have available! Thank you very much for yours! Not anymore! I just published it! Cheers! https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660589340

And, so, half the humanity were saved by hardware failures! (yeah, I had a hell of a week...)

What MacOS you are using? At least on Mojave (that I still use due my 32 bits games), every directory with a `.app` extension launches the program when double-clicked from Finder (or using `open KSP.app` from a console). Check if there's a file called `Info.plist` inside `KSP.app/Contents`. Mine have the executable attribute set, and looks like this:

Let me know if you need some help, my exchange rate favours you by the way! I'm currently pretty cheap!! (I surely could use the Money so I can buy some new gaming hardware and play KSP2!!!! )

By being a hit-man?

That's weird. I could not reproduce the problem on the 5h use case. It worked perfectly for me in both situations - still checking the other 4 use cases. Can you please send me somehow (as posting on https://github.com/net-lisias-ksp/DistantObject/issues/31 ): The whole savegame directory where the problem happened The KSP.log after reproducing the problem. Please remember to quit KSP before zipping the artifacts. ---- POST EDIT ---- I did a full blown Test Session, and everything worked fine for me. Unless there's some environmental glitch, I'm prone to believe you have some configuration or perception issue, and are misdiagnosing the problem. https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660139215 HOWEVER. I think I'm contributing to such misdiagnosing, my screenshots apparently are showing the dimming somewhat aggressive than I remember - it's day time right now, I have Sun hitting my eyes and this may be hindering my judgment? I will check these screenshots again by night to see if I have the same perception. And I also found a glitch on the ground colliders while sitting on Mün (notice Kerbin being drawn below the ground level, the second screenshot is the same scene some time later): Check first image on "Glitch Found due Ground Colliders" from https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660139215 Check second image on "Glitch Found due Ground Colliders" from https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660139215 Since I'm using the Sun's visibility on my algorithm, perhaps we had found the reason for some apparently glitches on the dimming? I initially tried to check the Sun's Coronas, but since there're at least two for Stock, I tried to cut some corners by using the Sun directly, but apparently this is backfiring. I will rework the code to check the Coronas too if the Sun is visible (and will avoid doing if the the Sun is not, to save some CPU cycles where possible). ===== POST EDIT ===== It's night now where I live, and that screenshots are sensibly more visible to me right now. So the sunlight was interfering with my perception. Since I do most of my coding by night, it's not a surprise that I didn't see any problems where @Errol where (not) seeing some. I'm coding a DEBUG window so we can track the Dimming Factor and, then, check if we have really a code problem happening on the user's machine, or if it's a perception problem... ===== POST POST EDIT ===== Oukey, no subjectivity anymore. I implemented a Debug Window that will give us exactly the numeric value used to dim the SkyBox. @Errol, please download and install the RC1 hotfix from https://github.com/net-lisias-ksp/DistantObject/releases/tag/RELEASE%2F2.2.1.2 . From this point, I believe that we will not lose ourselves anymore in our own personal perceptions and will be able to discuss objectively about the skybox dimming! Further instructions on this link: https://github.com/net-lisias-ksp/DistantObject/issues/31#issuecomment-2660589340

Plain luck - I don't know why it works (and I should). One of the reasons I'm struggling with this issue is because the code that appears to do the job is duplicating computations, what it's a hint that I should refactor the code again to avoid recalculating values I had already calculated - and I was trying to avoid the extra work. Oh, well... Well, first things first. Below, you will find a HOTFIX with my last attempt. I will publish hotfixes until getting this thing right, https://github.com/net-lisias-ksp/DistantObject/releases/tag/RELEASE%2F2.2.1.2 I didn't fully tested this one, only a couple of use cases - I will do it later, right now I need to pay attention to other affairs. Thanks for the help!

Humm... I completely forgot this use case. (when something it's too good to be true, it's usually is). So, let's enumerate the use cases so I don't lost them again: When the Camera is looking into the Sun, the Sky shall dim. Working on 2.2.1.2 When the Camera is looking into a Planet's illuminated side, the Sky shall dim. Screwed on 2.2.1.2 When the Camera is looking into a Planet's dark side, the Sky shall be visible. Working on 2.2.1.2, but probably by collateral effect When the Camera is looking away from the Sun and from any planet, the Sky shall be visible. Working on 2.2.1.2, but probably by collateral effect When the Camera is "landed" on an atmosphereless body, the Sky shall dim when the ground is being illuminated. Screwed on 2.2.1.2 There's something missing? Since I'm working on this thing in small pieces, I think my problem is not having all the Use Cases listed under my nose so I don't screw one by fixing another again - but, thinking a bit on what I had done in 2.2.1.2, from the code point of view it appears to be a step on the right direction.

Yep. And was exactly this phrase that ringed a bell in my dull, thick skull. I just released 2.2.1.2 . Please try it. TL;DR: I ditched all that code, replace a min with a max, and everything is working as expected since then.

Thank you very much! I know exactly which line is the problem now, and also where the problem lies! (I will need to burn some neurons on this one). Land a ship on the Mün and see how the SkyBox behaves as you look down or up! (also screwed on the last PRE-RELEASE, but I'm going to fix it ASAP)

Humm... This appears to be the new code screwing with the feature... Can you please install the current release (2.2.0.2) and see if the problem happens the same? I'm currently on Working Hours (don't ask how I managed time to post here, you don't wanna know), and having this information will save me a bit of time later when I came back to the issue - the thing is still fresh on my head, the time to fix this is "soon as possible", before I forget everything and need to restart from scratch...

Besides my big, wide mouth complaining all the time, I'm really grateful for still having a Forum - the reason I complain so much sometimes it's because I want to see Forum still relevant, and so any perceivable problems should be tackled down - ideally before causing too much damage. But, still, I am very grateful for it. Perhaps I should externalize it a bit more. RealLife™ is not helping, as usual - I did a somewhat interesting (well... perhaps not that much) mission in early January that I'm still trying to proper format and diagram to be published on "what did you did today" thread - 3 or 4 days playing, 6 weeks trying to write the damn post. We quickly lose a bit of perspective when we are overloaded.

AFAIK this is the desired result - if the planet is "visible enough", it's brightness will dim the stars completely. The nearer you are from the planet (i.e., the lower the orbit), quicker will be the effect. Keep in mind that now the Sun is also playing a hole on the dimming if it's somewhere ahead of the camera. So, now, we have two bodies that "when visible enough" will sum their effects. You should see the dimming changing as you rotate the camera to a position where the Sun is somewhere ahead of it, and then behind it. So it rotating the camera around the normal axis (i.e., point the camera to prograde on a circular orbit, then move to north/south, then move to retrograde). The dimming, now, will be different between prograde and retrograde unless the Sun is exactly at the top (local midday). It's about the "angular size" of the celestial body in relation to the horizon. To get your eyes screwed into not seeing the stars, you don't need too much light, a puny flashlight will do the trick. So, if you are into a lower orbit where the planet's "angular size" is considerable big, it will affect you vision into a wider FoV than the Sun, as the Sun's 'angular size" is way smaller. Cheat the vessel into a higher orbit, where the apparent size o the planet and the Sun will be more or less equivalent, and so some tests: Look directly into the celestial body: the sky should be completely dark. Start to slowly mode away from it: the sky will start to fade back gradually, but not linearly - more like logarithmically. Our eyes adapt to the lightning into a non linear curve. It's logarithmic when going to a brighter environment, and more or less exponential when going to a darker one (i.e., we adapt pretty quickly to lighter envs, but very slowly into darker ones). This is something I wanna tackle down eventually on https://github.com/net-lisias-ksp/DistantObject/issues/26 This is where looking into the Sun or into the Planet should cause some different effects, as the Sun is way brighter than the Planet and, so, will demand more time to recover once you look the other way. It's bright enough to hinder the whole view, and not only the skybox! I will be able to do some screenshots demonstrating the features ("or documented bugs" :P) by night. In the mean time, I understand that there're some improvements opportunities here, but... We are reaching quickly the peak of the curve of diminishing returns. Once the lower hanging fruits are collected, the efforts to reach the higher ones will be greater and greater, while the rewarding will be... lower and lower. And some of them would not be even desirable - who wants to be blind for some seconds after looking into the Sun? On the middle of an important burn, for example? --- --- EDIT --- --- Additionally... When I implemented this last feature, I was focusing on making the thing work fast trying to avoid to create that hotkey to brute-force dim/undim the Sky and quickly deliver something that would solve your problem now. So the code that would (or not) undim the sky when you are on the dark side of the planet are bluntly capping MAX or MIN dim into the current environmental brightness. It's the reason I didn't pushed it into the mainstream, I didn't gave too much thinking on the caps and I can probably make it slightly better without too much effort after thinking a bit more on the problem - worst case scenario, I shove this "bug" on the #26.

Crap... I screwed the dependencies last year, and didn't realized. On the bright side (#badumtss), white testing the thing properly this time, I detected that I had screwed the planet's influence on the Sky Dimmer, so I fixed it too. Please try: https://github.com/net-lisias-ksp/DistantObject/releases/tag/RELEASE%2F2.2.1.1

ANNOUNCE Release 2.2.1.0 2.2.1.1 2.2.1.2 is available for downloading, with the following changes: Finally implements Sky Undimming when on the dark side of a planet where the Sun is not visible! Fixes a potential glitch involving Kopernicus, discovered while implementing #31. Closes issues: #31 Check the SkyBox Dimming when looking on the Planet from it's dark side. So... Last year I chased my tail on this thing trying to do things the... hum... "smart" way: I computed the angular size of the Sun, then launched 3 ray casts (to the center, to the leftmost and to the rightmost, these two inferred by the angular size - in KSP¹ there're no planetary tilts, so I didn't had to check the topmost neither the bottommost). I wanted to know when the Sun started to be eclipsed, and when it would be completely eclipsed. Obviously, this performed like crap due the raycasts and extra trigonometry. Then I tried to be "smarter", computed the apparent size of the Sun, got the boundaries, cropped the damned thing using current viewing frustrum, and then tried to figure out if any planet also inside the frustrum would be eclipsing it. I realized the idiocy of this thing when I considered using a ray cast to see if there's anything between the camera and the Sun, what would just degenerate the "solution" on something like the first try. Then I tried to monitor the Sun's Coronas (there're two on Stock), trying to figure out if they were being drawn or not. Reading code around the World, I found one dude doing a similar check but using the GameObject's Renderer IsVisible attribute... And then something finally sparked inside my dull skull, and I just checked if the Sun's Renderer exists and, if it exists, if the IsVisible is true or not... (sigh) And finally I shoved all this code in the trash bin, replaced a min with a max and "implemented" the feature without collateral effects... Oh, the joy of fixing issues by removing code... The difference between humility and humiliation is... thin. Only to realize that such code were important to an important use case, and by "luck" I had tested the thing only on the very use case where it would not matter, and screwed everything else. Currently I finally managed to secure the Use Cases, and are currently debugging any mishap on the algorithm that could be happening on borderline situations. But the code is somewhat inefficient, and I will probably try to optimize it a bit before a proper release! This release will be available only as a PRE-RELEASE on github: https://github.com/net-lisias-ksp/DistantObject/releases/tag/RELEASE%2F2.2.1.2 I want to tackle out some more glitches before doing an update fest to the rest of the World. Ping @Errol, @Krazy1

Yep. And unless the user would be willing to play just a little bit some of the newer ones, why in hell he will waste money on new hardware? At very least, the user will buy a second hand one, the minimum needed to maxout the games they want to play. This is not too different from a egg and chicken situation, kinda what we had in early 80s and 90s with sound cards. Sound cards were hellish expensive on my country, besides not being a novelty. There're soundcards already for the Apple II, but... hell, who had the money to buy them? Everybody was trying to do anything they could to avoid them, from COVOX thingies plugged into a printer port to special device drivers to transform the crappy PC-AT's internal speaker into a PCM player. Heck, I played wave files this way my whole Windows 3.11 era. When the PCs got powerful enough to render Amiga's MOD musics at runtime, a lot of DOS games started to use it and with the PCM driver for the PC's internal speaker, heck, I soldered a cap and a resistor and pulled a wire into my stereo from the Speaker's connector. What I had done previously on my Apple ii, by the way. I just bought myself a Gravis Ultrasound way into the 90's, when finally a Killer Application for SoundCards became popular enough: Doom. I don't remember who authored that MIDI music, but, boy... That Soundtrack on a Gravis Ultrasound was simply something out of this world. It took me 15 years from my first computer (that already had SoundCards available) until I finally bought my first. And the reason was Doom. I think that we have a similar Modus Operandi nowadays. Hardware is not so cheap as people used to remember, we have way more expenses nowadays, rendering the tag price of the product not meaningful by itself to evaluate the real life cost of the thing. It's no joke, my electrical bill is two times the value I used to pay before the Pandemonium even by my consumption had dropped by half - so electrical bills are, well, four times the price I was paying a few years ago. And so it goes. I'm not alone on this boat. But they are preferring playing games that would run fine on older hardware, and since there are the other 30% still around, targeting such hardware will increase your target audience significantly, allowing you to expend more money on eye candies for that 70%, that so will show it off for that 30%, and since they already bough the game, perhaps would consider upgrading their hardware and so, in a few years, a slightly beefier hardware will be the new normal. Rinse, repeat. Keep your decisions around the Bell Curve, and your chances of improving your incoming will be probably better than otherwise. Sell games for your users of today, and let your future you worry about the users of tomorrow. It's about money. It's always about money. Most users see hardware as a way to accomplish something, not as a goal. Unless a new killer application pushes them into buying new hardware, they will stick with whatever they have until it breaks - and probably will try a second hand slightly better hardware before considering something really new. Draw a curve on games sales versus hardware sales - they are going opposite directions. Why? How? Well, one possible explanation follows: everybody and the kitchen's sink upgraded their hardware in 2020 due Pandemonium, since a lot of people had to work from home. So they ditched whatever they had and bought something reasonably good at that time. At somewhat premium prices, by the way, as the supply chain was collapsing at the same time the demand was rising. From that point, most people are facing higher costs of living, really higher costs of living (like me), and very, really very few of them (me included) are inclined to spend money on fixing what's not broken - or updating hardware that are still cutting it perfectly, even with some compromises. Last year my older MacCrap gone belly up - the fan died when I was sleeping while the machine was munching some numbers, the thing overheated and fried. Total loss. My options at that time: Buy a brand new Mac Mini. R$ 7900,00 (local currency) Buy a brand new generic but reasonably contemporary i7 16GB Mini PC. About R$ 2700,00 (no mass storage included) And expend days rebuilding all my workflow from scratch, as 80% of all I do is relying on MacOS. Buy a refurbished Mac Mini 2014 i5 16GB. R$ 3000,00 (hard disk included) - the shop was going out of business. And essentially duplicate the older HD into the new, and I would be working next day. Buy a refurbished MacMini 5.2 motherboard from China for R$ 700,00. Since I'm expending some really serious money fixing my home (and my son), what did you think I did? Obviously, I then bought the refurbished MacMini - only marginally pricier than the other MiniPC (pero no mucho, brand new 1TB hard disks costs R$ 250,00 around here, R$ 430 if NVME). People around the World are facing choices pretty similar to mine. This is the new norm.

Ah, now I see. Kinda a "gambiarra", but heck, why not? I got kinda conscience-stricken on the subject and I'm revisiting the code I wrote sometime ago and left behind. I had found some idiocies while handling Kopernicus, anyway, and frankly I don't know why nobody had complained before (or someone did and I forgot about?). So I have material to at least one more bug fix release. Anyway, I'll commit that trashy, really unforgivable way to handle the use case I ended up writing and got ashamed of publishing it before being dragged out of the task. Let's see if it would be good enough for your use case, I'm trying to make that thing not too horrible to be published as a EXPERIMENTAL release. I will add too the brute-force option (key binding).

The search, for obvious reasons, doesn't works. But the links for downloading the documentation in XML and HTML format are there.

Nothing that I would be willing to share. The last hack I tried backfired, run out of time for modding since then. If you have any hint of idea that you tried and worked, I'm listening!