I understand what you wrote but it did not directly answer my question, maybe by inference it does but for complete clarity, simply put, yes or no - do I have to make MRA files to go along with the MX files to avoid CTD's?

With the last two files I sent any "plane01mx.tpc" needs a corresponding "plane01mra.tpc" etc.
This is not the case with the previous version which does not have the mapping.

This was done to accommodate Iron Mike's skins which had them.
However, it might be worth your investigating what the actual files are, and what the MRA.tpc was meant to do. Are there areas of the MX files that need a transparency? If not then we can cut the MRA link.
There is a number of his multiskins in the "Planes_ETO" folder.

Ok, good enough.

It's not a problem to include a blank MRA file with the MEX files to avoid CTD's.

The MX files do not need a transparency if they are used for the middle and long distance models because at the view distance that the models come into play you can't see if the glass is transparent and most of those models don't even have props

They would be needed it a modder utilized the MX for something else, as Mike has done.

But as I said, it's not a problem to include an "empty" MRA file if it means Mike's stuff, all 700 or so files, doesn't have to be changed.

I have PMd Mike about it because I prefer to know the real reason for the MRA in his files

In most cases is looks like Plane01Y.3dz referencing Plane01MX.PCX and therefore Plane01MRA.PCX
1. If these existing MRA files are blank, and therefore just there to prevent a CTD then we do not need them or the mapping, so we use fewer files.
2. if they serve a purpose then we need them, and any new skin with the MX will need its MRA file (blank or otherwise) to avoid the CTD.

Fortunately so few people have worked on multiskins and made them available that we should be able to decide whether it is 1 or 2 and act accordingly

I'm pretty sure he does need the links as he uses the MRA the same way I use PRA and SRA. That is, to provide transparencies on main model sections rather than on long distance models.

If that's the case it's a lot easier for me to just add empty MRA files then it is for him to convert all his MX/MRA files to some other texture. If he's even able to do so. He might have used up those other linked textures and so had no choice but to use the MX/ MRA link.

Comparing Mike's Plane01 for the B-17F and Chompy's original



Chompy used the MEX a lot but there was no MRA

Where there are equivalent 3dzs the TPCs match perfectly.
TX-TEX
BX-BEX
N-N
LX-LEX
RX-REX
MX-MEX


There was no MEX=>MRA mapping so Chompy had no MRA file, so his the MEX file did not need a transparency even though the MEX is used for the L, M, R and S 3dzs
Mike uses the MX for the U and Y 3dz files which Chompy did not include. They are not in the default CDF either.

The more I see of this the more I am convinced that the MRA files have no real use

Mike's use of the MX for the U and Y would need the MRA file to go with it because those two sections include spinning props. However, since the link never existed the props would have suffered from the blocky prop syndrome. Not sure why Quality Control never caught the problem.

We are getting deep into the weeds here, mainly because we never came up with a standard naming convention and so we're trying to accommodate the eccentricities of various modders.

Honestly I think the best approach is not to fix anything, just make it aware to the few remaining modders that if they use the MEX texture they need to include an MRA file with it.

This is the "PBB1701mra.png" picture made for posting here but from the "PBB1701mra.PCX" extracted from Mike's original "PBB1701mra.TPC"



It looks almost blank, so I do not think it works as a transparency. This may explain why the B-17 props are always blocky.
The link "PBB1701mx.TPC"=> "PBB1701mra.TPC" was working. The one that was never set was the "PBB17mex.TPC"=> "PBB17mra.TPC" for the base skin.

When I converted the B-17 to 1.6 I pointed the U.3dz and the Y.3dz to Y/YTR so the props are not blocky.

Mike has confirmed that the MRA files were blank and added to avoid the CDT from the MX/mra mapping.
As they were not valid transparency files we have blocky props in pilot view.
What would need to be done in order to get good props, whilst retaining the remainder of his multi-skins?

When I converted the B-17 to 1.6 I pointed the U.3dz and the Y.3dz to Y/YTR so the props are not blocky.

I tried that just on plane01 but I was still getting blocky props on the starboard side in pilot wing view.

Odd, if both the U and Y are pointing to the Y/YTR set why would one side look Ok and the other side not?

I'll put my B-17G set in your folder for comparison.

Thanks
I have your single skin but not a multiskin B17

Ok, I uploaded B17G(multi)12-14-2018.zip to your folder.

I included a flight model set with the view distances pushed back about 20% so the flashing silver/green long distance model problem doesn't show up.

Thanks, but now I am seeing brown wings on silver planes

We never fixed the B17 wingview problem. We fixed the B-26.

All the B-17's will have the wingview of the lead plane. Righ now that's green but If you switch the lead plane from the green texture to the silver texture all the planes will be silver.

I though we decided to leave it be since the playability of level bombers is so low that it wasn't worth the effort to fix it.

This morning I fixed it because I need to know that the exe is working properly.
The default "planey.tpc" is the silver one from your single skin B-17.
All the silver multiskins have no "u.d3d" or "y.d3d" so they default to the silver "planey.tpc".
"Plane01u.3dz" and "Plane01u.3dz" both reference "Plane01y.PCX" which is brown
The same goes for Planes 03, 04, 06, 09 and 10 which all have a brown skin of one shade or another.

Tony,
Check that the player's "current" texture pointers are cleared and reloaded when jumping planes.
All of the texture pointers for multi-skins, other then the leader, are stored in the lettered 3dz for Wingman. The leader plane is the assumed player. I never considered the player jumping planes when I did the multi-skin for EAW, but I did work out the bugs in Lar's jump code or PE.

Make sure you have an array for each model part that is needed, or the game engine will grab random blocks.

It seems to me that you are dealing with pointer mismatches. The arrays I created are memory locations where the game originally loaded the unique object and it's texture. If you have all of the parts of a model entered into arrays at load time, you will be able to access that 3D model, at any time during the simulation. Try to leave these arrays intact if you copy the data to the leaders data. Create a new set of arrays if you also need to keep the pointers for the leaders plane.

Something to remember is that debug builds always fill arrays with 0s. With release builds, any newly created arrays contain what ever data is in that memory block

Thanks Allen.
I guess that players would not normally jump planes, and I would not either. However, I needed to in order to test the pilot's view of the wings in the multiskin cockpits.
The code I added to fix that problem was basically a repeat of yours (which loaded the multiskin "U" files) so that the exe also loaded the multiskin "Y" files to display the starboard wing view.
I will have a look at the code relating to pressing the "J" key in-flight.