Notice Canopy Integrity

If you had looked at the Companion API, Journal, or repair screen, you would find that the canopy used to break at 50% as reported by those (which was reported as 0% in the modules screen).

With the Canopy now breaking at 0%, this would appear to result in dropping from supercruise no longer causing the canopy to break, as dropping from supercruise does a random percentage damage to the remaining health of a module, and will not bring a module all the way to 0%.
So you're saying there was an inconsistency with how the canopy health was being DISPLAYED in the modules screen? It was showing as 0% there when the actual value was 50% according to journal and repairs?

This makes sense, and explains how the video could show a 40% in modules but still be intact. (Actual value would have been... 70%, right? 50% + (40% of 50%) )
 
Last edited:
Basically it seems the variable that controlled cockpit integrity was set to 30, but for reasons known only to FDev it was breaking once it was 15, so we only had 15 to play with anyway.

I'm a games developer so the code (very simply done and not in any real programming language) would be:

CanopyHP = 30;
If CanopyHP = 15 then destroy canopy;

On this scale 15 = 0% and 30 = 100%, so to get a value of 40% as shown in the images and videos we've been seen, then the value of CanopyHP would be 21. Because the UI is showing a percentage of 15 (from 15 to 30) and not a percentage of the full 30. 40% of 30 is 12 and we could never reach that number because the code is destroying the canopy once it gets to 15.

Now the variable is set a bit more sensibly and the code would be more like:

CanopyHP = 15;
If CanopyHP = 0 then destroy canopy;

On this scale 0 = 0% and 15 = 100%, so to get a value of 40% as showin in the images and videos, then the value of CanopyHP would be 6, which makes a lot more sense.

So, you see, we've not lost any canopy integrity, because we always had 15, we've just had the scale readjusted to work better with an absolute value of 15 being the maximum rather than having a value of 30 and destruction happening when we get to half of that... Which was a really dumb way of doing it.
 
Last edited:
If the canopy didn't shatter at the first sign of someone breathing on it then i'm fairly sure no one would be bothered and we wouldn't even be having this discussion. Please fdev just make it be able to survive more than me sneezing in the wrong direction and everyone will be happy.
 
If the canopy didn't shatter at the first sign of someone breathing on it then i'm fairly sure no one would be bothered and we wouldn't even be having this discussion. Please fdev just make it be able to survive more than me sneezing in the wrong direction and everyone will be happy.
I have to agree with that. I really don't see why they never used the full 30HP anyway... Why only use half of it in the first place?

It's a very odd way of doing things and is the reason why people are now getting very angry and confused on the forums.
 
That's 50% of the in-game variable not 50% of the percentage that the player sees in the UI, which is totally different.
While I suppose it's possible that he pre-3.4 UI was correctly mapping 15 out of 30 as 0%, that's (obviously) not how I was interpreting Frontier's statement, and I'm still not convinced it's the correct interpretation.

This wouldn't be the first time Frontier has had unclear changelogs or has actually not known how their game was really working.

I do thank you for the clarification though.

Now, does anyone have any screen shots or video of both the module pane and the advanced maintenance tab, pre-April Update, so we can see the discrepancy that was listed in the patch notes that was supposed to have been corrected?
 
Well, it's not the first time the UI is showing incorrect info.
The G5 raw materials and the NAV panel showing that a starport has no appropriate landing pad for a large ship are still badly bugging me.
But i really have to ask, what if the repair screen was wrong and the modules UI was correct?
If not, it means that the perceived canopy weakness after patch is just imagination.
 
Also, that say's cockpit and not canopy. Cockpit could be showing a value that includes canopy but has a percentage of lots of things combined... So, for example, you could lose 50% of a foot, but the foot only makes up a small percentage of the entire leg.

Would still hurt like hell, though.
 
But i really have to ask, what if the repair screen was wrong and the modules UI was correct?
Then we'd have canopies that went fron -15 to 0 integrity and broke at 0 the first time a stray fart hit them?

From some of the comments in these threads, you'd think that's what was happening, but cognitive bias an all.

I think I'll log in and find someone to shoot my ship in the face with a 100% breach chance weapon that does predictably pathetic damage (c1 cannon turret with high-yeild shell?) and take some measurements myself.

Also, that say's cockpit and not canopy.
Game ain't exactly consistent with it's nomenclature, man.
 
As I'm gasping to death in the inky blackness of space, Thargoids garthering around casting lots as to who gets to fire the killing shot, I will remember this posting and be thankful that I died with utter clarity on what went wrong.
 
Showing 25% cockpit:
Showing 62% in repair:
It would seem there's some crazy interpretations of math here and indeed a discrepancy on how canopy HP is displayed. My bet is the 62% is actually 62.5% and it's just showing the integer part. With that assumption in place, the 25% displayed is "1/4 of the range from 100% to 50% remaining" which kinda makes it the true canopy health%, while the repair screen is showing "canopy at 62%" , where 50% = broken canopy.

Just saying, 25% out of 50 is 12.5. 50 + 12.5 = 62.5. I know, I know, crazy, but that's the only conspiracy theory I can come up with where the numbers 50%, 62% and 25% can even remotely line up.
 
Life support synthesis took the air out of that possible source of tension.

I could start the longest exploration trip my CMDR has ever been on (~5700 jumps) with a broken canopy and it would barely matter.
Balls . I forgot about that. Shame!
 
Last edited:
I know, I know, crazy, but that's the only conspiracy theory I can come up with where the numbers 50%, 62% and 25% can even remotely line up.
I'm not even going to guess how the numbers shown in those examples were reached without more samples.

Without the sort of tests that would likely only seem necessary in hindsight, we are left with having to take Frontier's vague and occasionally contradictory statements at face value. This T-10 canopy integrity of 25, for example...or all these SLFs that still list 30.
 
I'm not even going to guess how the numbers shown in those examples were reached without more samples.

Without the sort of tests that would likely only seem necessary in hindsight, we are left with having to take Frontier's vague and occasionally contradictory statements at face value. This T-10 canopy integrity of 25, for example...or all these SLFs that still list 30.
I'm not sure I'm able to express it in the best possible way, but I could imaging the following scenario at FDev:

Dev A codes display_hp_percentage as

( canopy_current_hp - canopy_breach_hp ) / ( canopy_max_hp - canopy_breach_hp ) * 100 ,

while dev B codes display_hp_percentage somewhere else as

canopy_current_hp / canopy_max_hp * 100 .

Given the values

canopy_max_hp = 30,
canopy_breach_hp = 15,
canopy_current_hp = 18.75,

the first function would display 25% while the second would display 62% (assuming truncation from 62.5 for the GUI). The first function communicates that at 18.75hp you have 25% of the usable HP range (the range being 15hp from 30hp to 15hp) remaining, and at 0%, boom. The second function communicates that 18.75hp is 62.5% out of 30hp, and at 50%, boom. Do I agree this is how it should be done? Hell no! But it's the only way I can make any sense out of the figures. If it's not this, I'm at complete loss.

In the end, doesn't matter, I fly a Chieftain, I'm screwed no matter what...
 
Top Bottom