Loading [MathJax]/extensions/Safe.js

Special Aircraft Service

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2] 3 4   Go Down

Author Topic: A vexing problem with instrument damage SOLVED  (Read 8030 times)

0 Members and 1 Guest are viewing this topic.

WxTech

  • Modder
  • member
  • Online Online
  • Posts: 6195
Re: A vexing problem with instrument damage
« Reply #12 on: February 02, 2017, 06:31:33 PM »

Mike,
Thus far one other user has reported a failure for the instrument damage textures to appear when they should have changed state. Because this is the case for me when going back to the stock (4.08) 'Cat, I'm increasingly suspecting the problem is a fundamental one independent of any modding.

Might you be so kind as to don your Deerstalker, and apply your considerable talents to sleuthing out this thing?

Or any and all Java Meisters within reading distance of this challenge! ;)
Logged
Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Hyman Rickover (but probably predating his use.)

WxTech

  • Modder
  • member
  • Online Online
  • Posts: 6195
Re: A vexing problem with instrument damage
« Reply #13 on: February 03, 2017, 10:24:41 AM »

Ton414 over at IL2 Free Modding points out how the stock dakaged gauge graphic DGP_03.tga has an 'incorrect' alpha channel.

I looked at my extracted copy, and with Irfanview it shows as fully black, presumably due to the fully black alpha channel it shows. That would make its four gauges fully transparent. But why this should cause all the rest of the damaged gauges to fail to be drawn escapes me...

...However, using Photoshop to open thst very same stock DGP_03.tga shows a normal image, with a white alpha channel. This would make those four gauges fully opaque. Baffling how two different software tools show such a difference for the same image!

In any event, my graphics exhibit no such schizoid behavior.

Ton414 indicates that the method in the class file to control the damaged panel contents looks to be normal. So what the heck gives!?

So far no one has reported back on whether the *stock* F4F has this inability to show gauge damage, as is the case for my 4.08 bird.
Logged
Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Hyman Rickover (but probably predating his use.)

SAS~Storebror

  • Editor
  • member
  • Offline Offline
  • Posts: 24055
  • Taking a timeout
    • STFU
Re: A vexing problem with instrument damage
« Reply #14 on: February 03, 2017, 10:45:17 AM »

Can't confirm what Ton though he saw.

The only thing I found so far is that in the F4F-4 cockpit the "DGP_04_night.mat" file is missing the reference to the F4F-3 cockpit folder, therefore the cockpit didn't load until I changed the line
Code: [Select]
TextureName DGP_04_N.tgato
Code: [Select]
TextureName ../F4F-3/DGP_04_N.tga
Other than that, the undamaged panel for me looks like this (click for full size):


...and the damaged one looks like this:


Best regards - Mike
Logged
Don't split your mentality without thinking twice.

SAS~Storebror

  • Editor
  • member
  • Offline Offline
  • Posts: 24055
  • Taking a timeout
    • STFU
Re: A vexing problem with instrument damage
« Reply #15 on: February 03, 2017, 11:08:40 AM »

*bump*

even when I disable my Wildcat mods and go back to stock (4.08), the instrument damage here also does not appear when the plane is cut to tinfoil. I now wonder if this is a problem with the F4F right from its introduction in PF??
This could very well be true.
The damage code is in the F4F.java classfile (the base plane itself).
It's in the "hitBone" method and the relevant part is this:
Code: [Select]
            if(s.startsWith("xxarmor"))
            {
                debuggunnery("Armor: Hit..");
                if(s.endsWith("f1"))
                {
                    if(getEnergyPastArmor((double)World.Rnd().nextFloat(8F, 12F) / (Math.abs(v1.x) + 0.0001D), shot) > 0.0F && point3d.y > -0.442D && point3d.y < 0.442D && point3d.z > 0.544D)
                        FM.AS.setCockpitState(shot.initiator, FM.AS.astateCockpitState | 0x40);

This means that in order to damage the panel, a bullet must hit a hitbox where the name starts with "xxarmor" and ends with "f1", the bullet must have a certain energy, it must be centered on the y-axis with +/- 0.442 units tolerance and must be above 0.544 units on the z-axis.
The question is: Is there any hitbox with a matching name on the F4F? And if so, does the location fit these bounds? And if so, does it make sense to damage the panel when a bullet runs in there?

For comparison, this is the same relevant part of the F6F class:
Code: [Select]
            if(s.startsWith("xcf3") && point3d.x > -0.645D && point3d.x < 0.406D && point3d.z > 0.3D)
                FM.AS.setCockpitState(shot.initiator, FM.AS.astateCockpitState | 0x40);
Different part, completely different location check, and most of all: No "armored" panel.

Best regards - Mike
Logged
Don't split your mentality without thinking twice.

WxTech

  • Modder
  • member
  • Online Online
  • Posts: 6195
Re: A vexing problem with instrument damage
« Reply #16 on: February 03, 2017, 12:30:24 PM »

Mike,
Ah, it looks like we're getting somewhere. So either a nonexistent hit box, or a misapplied or ridiculously stringent constraint is the culprit? What would it take to redress this? And why on the Maker's verdant globe did the original coder not catch the fact that his construct did not work?
Logged
Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Hyman Rickover (but probably predating his use.)

WxTech

  • Modder
  • member
  • Online Online
  • Posts: 6195
Re: A vexing problem with instrument damage
« Reply #17 on: February 04, 2017, 06:02:04 PM »

It seems that Ton414's cockpit classfile fix does indeed permit the damaged instruments to be drawn after the required damage has been sustained. However, after a number of tests I've yet to see this occur myself. Apparently the threshold is still pretty stringent, based, it would seem, on reports/assumptions of a certain hardiness of the plane that protected the panel.

I've asked about adding a download link to my post here which contains the link to my Wildcat cockpit mod. In the meantime, over at Free Modding site one can find a link in a thread I started regarding this matter of the damaged instruments...
Logged
Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Hyman Rickover (but probably predating his use.)

WxTech

  • Modder
  • member
  • Online Online
  • Posts: 6195
Re: A vexing problem with instrument damage
« Reply #18 on: February 04, 2017, 06:11:56 PM »

By the way. On this matter I'm jumping back and forth between SAS and 'another' modding site where much appreciated help has been forthcoming as well. Too bad about the dispersal of brain power among separate communities, even though there is cross talk. We lot of enthusiasts already make up a small enough gang in aggregate; these 'diasporas' are regrettable.
Logged
Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Hyman Rickover (but probably predating his use.)

WxTech

  • Modder
  • member
  • Online Online
  • Posts: 6195
Re: A vexing problem with instrument damage
« Reply #19 on: February 05, 2017, 10:23:39 AM »

Courtesy of Ton414, who addressed the failure of the damaged instruments to be drawn via a first stab at the problem, are two versions of the F4F cockpit class file (4.09/4.10, and 4.12/4.13). Download links for this provisional fix can be found in a post of his near the bottom of page 1 of this thread:


 ]nono[
Logged
Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Hyman Rickover (but probably predating his use.)

SAS~Storebror

  • Editor
  • member
  • Offline Offline
  • Posts: 24055
  • Taking a timeout
    • STFU
Re: A vexing problem with instrument damage
« Reply #20 on: February 05, 2017, 11:12:11 AM »

Does it really fix the issue?
As much as I can see, it's just the "cheap" change of making the wrong hitbox unarmored.
No trace about whether or not the hitbox is okay at all, whether it's in the right spot, nothing about hurting/killing the pilot...

Nevertheless at least it shows that working on the hitbox code is the right path to go.
I'd just rather like to see the issue fixed for real, not just some of it's symptoms cured "in a way".

Best regards - Mike
Logged
Don't split your mentality without thinking twice.

WxTech

  • Modder
  • member
  • Online Online
  • Posts: 6195
Re: A vexing problem with instrument damage
« Reply #21 on: February 05, 2017, 11:32:09 AM »

Mike,
I see what you mean about changing the collision object from armored to not armored. That roughly circular hit 'box' is pretty large, and might represent also the sheilding by the engine.
Logged
Great minds discuss ideas. Average minds discuss events. Small minds discuss people. - Hyman Rickover (but probably predating his use.)

SAS~Storebror

  • Editor
  • member
  • Offline Offline
  • Posts: 24055
  • Taking a timeout
    • STFU
Re: A vexing problem with instrument damage
« Reply #22 on: February 05, 2017, 12:41:40 PM »

I'll take a closer look at the matter tomorrow.
Logged
Don't split your mentality without thinking twice.

SAS~Storebror

  • Editor
  • member
  • Offline Offline
  • Posts: 24055
  • Taking a timeout
    • STFU
Re: A vexing problem with instrument damage
« Reply #23 on: February 06, 2017, 06:09:44 AM »

Okay, here we are again.

Let's summarize the current status first.
We have the F4F where the panel cannot be damaged (alternatively: Cannot be damaged with a reasonable probability).
The suspicion expressed that this might have been caused by a "wrong" alpha channel of the panel textures turned out to be wrong, a dead end.
Evidence shows though that the F4F class code causing possible panel damage is suspicious:
Code: [Select]
            if(s.startsWith("xxarmor"))
            {
                debuggunnery("Armor: Hit..");
                if(s.endsWith("f1"))
                {
                    if(getEnergyPastArmor((double)World.Rnd().nextFloat(8F, 12F) / (Math.abs(v1.x) + 0.0001D), shot) > 0.0F && point3d.y > -0.442D && point3d.y < 0.442D && point3d.z > 0.544D)
                        FM.AS.setCockpitState(shot.initiator, FM.AS.astateCockpitState | 0x40);

Ton414 followed my suggestion that this code part is wrong, he replaced it with parts of the F6F code, turning it into:
Code: [Select]
            if(s.startsWith("xxarmor"))
            {
                debuggunnery("Armor: Hit..");
                if(s.endsWith("f1"))
                {
                    if(getEnergyPastArmor(point3d.y > -0.645D && point3d.y < 0.406D && point3d.z > 0.3D)
                        FM.AS.setCockpitState(shot.initiator, FM.AS.astateCockpitState | 0x40);
This, sorry to say, is bollocks too.
It still binds the panel damage to the wrong hitbox, and to make matters worse, puts the bullet location checks into a completely wrong spot.
It's questionable whether the armor plate can be hit at these coordinates at all.

Let's face the facts.
This is what the armor plate looks like, the part which is currently used by Stock IL-2 and by Ton's modification to check whether the panel was hit (the hitbox is the green dish):


Doesn't look to bad, eh?
Well... it does.
The problem is: This hitbox would only work when the plane is hit from the front, but then again, a bullet likely won't ever get there, since it would have to travel through all the hitboxes of the engine first. That's like real life: You can hardly shoot the panel to pieces when shooting at it from the front.
Why that?
Why can't I hit this hitbox from behind?
Because there's another big hitbox covering it (the big blue something):

(And to make matters worse, the green dish hitbox is bound to the "blister" mesh which is the moving part of the canopy, meaning that the hitbox moves aft when you open the canopy - fail!)

Looks weird?
Not really.
Let's take a look at the F6F comparison, a plane where the panel damage is known to work flawlessly.
The hitbox used for panel hits on the F6F looks like this (the big red something), note the similarity to our big blue something on the F4F:


Isn't that a tad too much of a hitbox just for the panel?
Nope, not when you take the additional coordinate checks in Java Code into account.
Applying them, this is what remains of the hitbox when it comes to panel hits:


Okay then, back to our big blue F4F hitbox. It's called "xcf1" (for the F6F the panel hitbox is "xcf3" but we don't have that on the F4F, "xcf1" is the equivalent):


Applying a few simple coordinate boundaries to it, we get this final reasonable, uncovered and unarmored hitbox:


The regarding mod is here: https://www.mediafire.com/file/wxaxr4ua1kncyel/F4F_Hitbox_Fix_2017-02-06.7z
It works with all base game versions.
IL-2 4.09 Rebels need to have the "AircraftLH Stub Class Mod" installed (it's a mod that add's a "placeholder" AircraftLH class to close the gap for something that has been introduced with 4.10m).
If you don't have it yet, get it here:
AircraftLH "Stub" Class Mod for 4.09 Rebels only:
AircraftLH Stub Class Mod for 4.09m based games only

This should work for 4.08m as well (untested though).

Java Sourcecode can be found here: https://www.mediafire.com/file/3nwatnobivhi0n9/F4F_Hitbox_Fix_Sources_2017-02-06.7z

I've performed a couple of test sorties against A6M fighters and my panel did get damaged successfully now.

Best regards - Mike
Logged
Don't split your mentality without thinking twice.
Pages: 1 [2] 3 4   Go Up
 

Page created in 0.09 seconds with 21 queries.