Lisias

This is EXCELLENT news! Thanks a lot! I mean it!

A plane with wings filled with water. David Rose's RP-4 Another source. — — POST EDIT - — Moar Pics! Source.

TL;DR: I didn't tested and I don't want to answer questions about it, so I declare it a conflict so people do not install it. There's a difference between being incompatible and being unsupported. I don't mind people not wanting to support TweakScale, the whole TweakScale Companion Program aims to seamless support third-party add'ons without hassling TweakScale neither the third-party add'on. But declaring it a conflict shuts the door for any official support, as the end user will need to override CKAN - denying one of the core reasons to use CKAN at first place. That said, this is not a TweakScale problem (neither CKAN, by the way - no need to hassle CKAN guys on this neither) - TweakScale is compatible to KTT in the same way it's compatible to others Tech Tree around here, it is only not supported by it. Unfortunately, due the KTT maintainer's decision to declare TweakScale a hard conflict, there's no incentive for incepting a Companion for KTT where such support could be added. So I don't see a reason for further discussing the matter here. Sorry.

Don't have a clue. All I can say is that someone declared TweakScale as a conflict on KiwiTechTree. This happened 9 months ago, by the way. You will need to reach CKAN guys and ask them about.

thanks! Ouch. Sorry for that. These messages are a pain in the SAS , I know, but sometimes these situations can screw up something. Not always, granted, but since it's pretty unfeasible to try to detect when it's fatal and when it's not, I choose to err on the safe side. I really need the KSP.log and the ModuleManager Patch Log - without these files, I can only do blind guesses. Most of the time these problems happens when more than one add'on patch a part completely disregarding that maybe someone else had patched it first. So it's pretty possible that KRE will not trigger anything on my test bed because it is only half of the problem, and I need the KSP.log to see what's the other half. You can upload the files using Dropbox or GoogleDrive (remember to allow people to download it!). Or if you have a github account , you can leave a comment on this issue dragging and drop a zip file with the logs.

"We fixed the docking ports!"

Well, since we are talking about vehicles with weird wheels, how about Rolligon? — — — POST EDIT — — — And CHECK YO STAGING! https://www.reuters.com/lifestyle/science/russias-nauka-space-module-experiences-problem-after-docking-with-iss-ria-2021-07-29/ ( Who never? )

Because you regulate voters, not funders. And the new feudal lords are the Energy producers apparently.

I agree. Please talk with the CKAN guys, I'm not responsible for this. I'm not aware of any problems on these add'ons, by the way - but there should be a reason for that - if you find it, report here and I will see what I can do. (Ping @DasSkelett )

Makes me remember something I did some time ago!

ANNOUNCE KSP Recall 0.2.0.4 is on the Wild, featuring: ChillingOut is not working as expected. Deactivating it. Any problems will need to be tackled out punctually. This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right now. CurseForge. Right now. SpaceDock (and CKAN users). Right now. Being a rollback release, all Distribution Channels were updated at once. Cheers!

So it's ChillingOut without the slightest doubt. I'll rollback it and I'll post a new release ASAP.

And I will not even talk about the push for Electric Cars - these things are not going to use the very same electricity?

Yep. This is what I was aiming to fix with ChillingOut . Ideally, I should find a way to identify what parts need the fix instead of applying the fix on everything as I'm doing now. Any suggestions about how to do it will be hugely appreciated! Probably because I may be stomping KSPIE's toes with ChillingOut. The root problem is simple, something related to Heat is not being correctly initialised sometimes as it was being done until KSP 1.10.1 . If we manage to zero in the culprit, a better fix can be cooked and so we ChillingOut have a better chance of not screwing up something else by accident. — — POST EDIT — — Uh.. Wait….. @rawhide_k, you are telling me that by using the previous version of KSP-Recall, things were not exploding? So the new KSP-Recall version is the one causing the problem??? o.O

Dude, you are appreciated . the next release will have some experimental thingies that need to be manually activated to be tested. My worst problem is not being able to predict how some changes will affect the mainstream - I know how they affect the part, but I have little visibility about how it affects real life users with real life save games. Someone willing to burn free time with a backup of his/het save games will be a huge help!

Unfortunately, an upgrade may be more problematic than expected... https://www.techradar.com/news/intel-warns-of-cpu-stock-shortages-in-near-future Not sure if this is going to affect only Intel or everybody, but in a way or another upgrading CPUs will be a problem. And this will affect the prices for used CPUs too...

Yep. But since most people usually buys a prebuilt PC (or so I was told), this appears to be a big issue. The computer mentioned on the Article (ALIENWARE AURORA RYZEN™ EDITION R10 GAMING DESKTOP) is not that big, 550W. I think my old PS3 is more of a power hog than it. Even my NAS, that supports 6 5.24" spinning disks, needs a 5A PSU... I think this will impact somehow the new generation of Games - and I'm not even talking about some issues on the current ones...

Yeah, I probably messed up on the Workaround for some exploding parts problem that were introduced on KSP 1.11. It's something related to heat no being initialised correctly, exploding everything on launch. Apparently, the thingy is screwing up KSPIE by accident. I opened an issue to investigate it: https://github.com/net-lisias-ksp/KSP-Recall/issues/25 Can you inform an engine that you had tested and confirmed the bug? This will save me the potential bad luck of choosing an engine that doesn't have the problem, what would waste some time (and unfortunately, I'm low on it these days - anything you can give me that would save even a hour of work will be a huge help). In the mean time, edit the file KSP-Recall.cfg on your GameData/999_KSP-Recall to be like this: KSP-Recall { INSTALLED { Attached = false ChillingOut = false Driftless = false Refunding = false Resourceful = false } } @KSP-Recall { @INSTALLED { @Attached:NEEDS[KSPRECALL-ATTACHED] = true // @ChillingOut:NEEDS[KSPRECALL-CHILLINGOUT] = true // Here! Comment out this line! @Driftless:NEEDS[KSPRECALL-DRIFTLESS] = true @Refunding:NEEDS[KSPRECALL-REFUNDING] = true @Resourceful:NEEDS[KSPRECALL-RESOURCEFUL] = true } } And then edit the chillingout.cfg file from GameData/999_KSP-Recall/patches to be like this: @PART[*]:NEEDS[KSPRECALL-CHILLINGOUT-IGNORETHIS] // Note the "-IGNORETHIS" { %MODULE[ChillingOut] { active = True } } This will override the internal code that decides what to install or not.

News from the Front. I finally got my… rectangular pieces of paper together and managed to enumerate everything that TweakScale was missing for KSP. TL;DR : Geez, I have some work to do!!! Theoretically, all the missing support for parts (but Serenity, as this beast will give me a run for my money and will be tackled down separately!) are "implemented" already, the next step is to revise all the Scale Exponents for missing modules. This is currently work in progress, and I may have some (good) surprises for you! For the sake of curiosity, follows a somewhat comprehensive report for all Parts and Modules that were ever present on KSP since the first release I had access on Steam (0.22, unfortunately not available anymore…): (not mobile friendly, sorry. You will probably need to maximise the Window to properly read the contents) This is the most cumbersome task from the scheduled ones for the next release, it will take some good days of hacking to iron out these ones. Please be patient. Cheers!

IMHO, one of the best features from Making History is the Mission Editor. And one of the best Missions built with it is this one - you may want to try it once you get a grasp on the new parts:

I found this one today and for some time I didn't knew where to post it. I think this fits this thread, so here we are. "Dell won't ship energy-hungry PCs to California and five other US states due to power regulations" https://www.theregister.com/2021/07/26/dell_energy_pcs/ Frankly, I didn't saw that coming and I don't like the smell of it - not to mention at least some of the mentioned states are pushing electrical vehicles...

Because I'm addressing your objections one at time. The last link was about how human eyes work, addressing your terrible statement that human eyes would be a kind of special devices completely unrelated to the Law of Physics. [snip] Exactly. What hints you don't need animations using fps faster than 75Hz, the whole point of the discussion. One just can't "perceive" anything faster that the brain can process it. Eyes are not autonomous devices, they need feedback from the brain in order to work - for example, to size the iris aperture to cope with the current illumination levels. Why do you think first-responders illuminate the iris with a flashlight to check the brain's responses? Not to mention the eye's cones themselves (as the rods are not useful on gaming as their "resolution" is too low, se my previous video) also have their limitations. The cones have a point of saturation where they don't work properly, and measuring these timings get us some very interesting data: This article I linked is terribly dense, hard as hell to extract layman understandable data - I took some time to get it), but in essence what it is saying is that once the rods are "overexposed", they took about 13 ms (interesting number) to cease working, and then another 7ms to get back to work. Monitors (and VR headsets in special) are nothing more than millions of small flashlights pointed to your eyes, by the way. Not being enough, I found an article where the rods and cones response time are being measured (forget about the brain, now we are talking directly to the photoreceptors on the eyes). These tests were made using saturation (and using photoreceptors from different animals so they are not directly applicable to humans). But some numbers are consistent with the discussion. Rods saturates after approximately 10 to 15ms (cones saturate way faster), and once they are saturated, they cease to work as expected. Unrelated to the discussion (we are talking about how fast the brain can perceive visual stimuli, not how slow the stimuli can be before annoyance), I found this interesting article - perhaps this could help to explain why you "perceive" some things differently from what science says:

Apparently my lack of understanding is pervasive in the scientific community.. On the other hand, I learnt that the minimum FPS for preventing headaches (that could be severe to the point of causing nausea) is 90Hz per eye. Appears to be related more to eye strain and eye fatigue than perception though.

Nope. The argument is exactly about how low framerates looks on the movie, and yet people still prefers it by reasons out of scope of this discussion. Being "technically better" doesn't automatically improves the experience. Nope. Your brain takes at least 13ms to process an image. Then it needs time to propagate the muscle's commands from the brain, another 16 to 25ms. So you have something like 26 to 51ms between the stimulus and the reaction (something between 40 to 20 Hz!!). So, you see, we have a significative lag between what we see and what we do about what we see. Considering that we perceive visual clues way faster than we react to them, 75Hz appears to be the best compromise. Not exactly. What's happening here is that the input controls are (wrongly on my opinion) tied to the framerate, Since we have a delay of about 26 to 51ms between the perception of the stimuli and the reaction, and the stimuli themselves takes down to 13ms to be processed, we have an additional 13 ms to confirm the results of that reaction. Let's assume a very responsive youngman whose reaction times are on the top of the species: 13ms to process the visual stimuli, and 13 ms to propagate the synapses into muscle's signal receptors. 26ms total, or 2 frames at 75Hz. You need an extra frame to process the results of what you did, so between the original stimuli and the processing of the feedback, you "waste" 3 frames and the cycle ends at the 4th frame (remember Nyquist - anything happening between two sampling points are detected on the second sampling point, unless it's duration is less than the delta-T of the sampling points when it is plain lost). On a faster framerate with the inputs attached to the frame, the computer will be able to show you the feedback earlier on that pipeline. Not because of the higher framerate (because you don't see anything below 13ms anyway), but because the processing of your reaction is on the critical path of the frame pipeline, what delays the resulting frame for you - and so fastening the whole pipeline ends up accelerating showing the resulting frame to you. So, yeah, on a system where the input is attached to the frame, going 120 or 150Hz will improve perception because the processing of the resulting frame will be ready before you can perceive a frame. But this is happening not because doubling the framerate is perceptible by you, it's happening because someone tied the input and the respective processing to the frame's critical path, delaying the results to you. Had the computer be programmed to receive the input and process the reaction at it maximum speed instead of be forced to pace down by the frame rate, you could have the feedback displayed already on the start of the 3rd frame from the stimulus that triggered the chain process. You can't "feel" anything faster than 13ms. Feel free to provide any material supporting your argument. Here follows mine: I don't know how VR headsets works nowadays, but from the days we were toying with it (we were using Nintendo Power Gloves and LCD shutter glasses both tied to a parallel port), the problem is that each eye receives half the framerate, as the computer needs to draw two frames instead of one, one for each eye. So the 60Hz CRT monitors we were used to have would render 30Hz for each eye tops, and people using more expensive 90Hz monitors reported better results for fast pacing animation, not to mention way less strain on the eyes (Anyone played Sega Master System with a 3D glasses? I did, lots of fun - but could not play it for too much time! ) In a way or another, the sickness is reported to be related to the disruption between the aparent movement shown in the headset and the lack of real movement reported by your body. This is disruptive for your brain. Our brains are biological/chemical computers and the Laws of Physics still applies. We have limits on our sampling rates we use to perceive reality. Sources, please.

O didn't said 24fps is acceptable for games, I said it's still preferable for movies. People's perception was the core of the argument. agreed on all accounts! I think we are not on the same page anymore? Low fps don't make things slower, make them 'chumkier'. An object that crosses the screen from on side to another in 2 secs will do it in 2 secs no matter.bow many frames it takes - 50, 100, 120 or 288. About the input, you don't need to attach the input to the framerate. Doing input on the critical path of a time critical computing is far from being a good idea a anyway. Every single academic text I ever read about real time computing advocates againt doing I/O on time critical code. And, in a way of another, the real bottleneck for a smooth animation is the Monitor's refresh rate. 4k monitors do 60 to 70Hz, and most affordable 1080p oned like mine does 75Hz. So stressing the GPU beyond that just don't improve the experience. Not to mention studies about human vision stating that we can process images as fast as 13ms (from 80 to 13, as I read) and so Monitors faster than 75Hz are just not helpful - 1000 / 75 is 13.33333, the most common limit for the brain to process human vision. I think that 75Hz with vsync is probably the same experience as a 144Hz image. But 'cheaper'.