Bitmap juggling

To test the multi-skin maker I chose one of Ray's planes that had no BMP files.
It worked, so I wanted to add the BMP files because they can be edited directly without the need to convert them.
So I unpicked the TPC files to make PCX files and used a converter to make BMP files.
They did not work as one which I has edited seemed to show the original and not the edited version.
Investigation showed that the converted files were 8-bit BMP and the 160 exe is programmed to read 24-bit.
As a result they were not being read

So I made a 256x256 blank 24-bit BMP file and pasted my edited file into it using MSPaint.
It retained the 24-bit format, and worked when I ran the exe.
However, some patches of additional colour appeared which were not in the original. I could see them in the BMP file after pasting.

So I looked for another solution. I loaded the 8-bit BMP into MSPaint, and saved it as a JPG. Then I saved the JPG as a 24-bit BMP.
It worked perfectly



Jel

aww, cool. But JPG sucks arse, even with low compression. You don't want to ruin a BMP that way.

There is a free Photofiltre program out there (there is a free one and a better one that cost money), it allows index pallets. (VBH would know more about the PALs than I of course.)
But makes it easy to clean up stray colors. But I'm not 100% sure what needs to be done to avoid JPG. lol.

So here's a question.

Can you mix BMP's and tpc/pcx's.

I ask because the BMP's are a lot larger in size than the tpc files

A little background.

I'm working on a B-26 multi-skin project and I've come up with a way to make the folder size quite a bit smaller.

Since the game will use the main plane's skin if it doesn't find any multi-skins we don't need duplicates of some parts such as the cockpit, shadow and in some cases, the props, fuselage and wing views.

So I made a "B.3dz" with only one transparent element which points to PLANEB.pcx. This pcx is nothing but a single picture made up of nose art. Then I attached the "B" with a hardpoint to the appropriate spot on the "C.3dz", which is the left half of the nose.

It shows up perfectly in the game and it works for the multiskins too. The advantage is that I don't need many of the 3dz and tpc files as long as the basic skin is the same. So, for instance, if the third, fourth, fifth and ninth plane are sliver, as is the lead plane, I can leave out the fuselage 3dz's and tpc's for those planes.

The "B".tpc is pretty sharp since it takes up the entire pallet but I'm limited to the 256 color pallet and with that limitation skin tones are tough to get correct. (And as we well know, lot of the nose art involves scantily clad women).

So, could I make a "b".bmp to replace the B"B.tpc, without converting the entire set of files?

Mark:
The point is that the BMP made from the PCX is 8-bit, with the same colours as the PCX, so it is not high quality in the first place. The goal is just to get a 24-bit version with exactly the same colours, which can be duplicated from plane01 to plane02-15 by the multiskin utility. This would then give the modder some BMPs to work with.
It is not intended to be a finished product, but something that creates 24-bit BMP files from the PCX in the case where no BMP files exist.

Ray:
You can mix BMP with TPC files
If there is a "Plane01TX.TPC" and a "Plane01TX.BMP" then the "Plane01TX.BMP" will be used as the texture file. If there is no "Plane01TX.BMP" then the "Plane01TX.TPC" will be used.

Jel

Ok, good, I'll give it a try and report back.

I see some "empty" tpc files in Iron Mike's 24bit multiskin sets.

Do I have to include something like that with the set?

Your comment seems to indicate that I don't but then why do IM's sets have them?

There must be a matching TPC file to the BMP. The exe reads it to get the size, then reads the BMP to get the textures. So if the BMP is 256x256 then the TPC must be 256x256.
A "blank" TPC file is OK if it is only there for the exe to get the size.

Ok, thanks. I'll start with a set from IM since they meet the stated requirements.

No luck with the BMP file.

All I see in the game is the blank .tpc file that I made to go along with the.bmp file.

There are NO multiskins presently in the folder, just the primary files with the normal naming convention.

Does the game need to see some multiskin files for the BMP to work?

Check that the BMP is 24 bit.
I will check that the BMP works with just the primary skin and get back to you.

Yeah, that was it. I set it to 24 bit in Photoshop and I can see the image.

The .bmp picture looks WAY better in game than the pcx picture it replaces.

OK, next question.

How do I get the bmp to show up in 3dz Studio?

I want to improve the "B.3dz" to better conform to the contours of the nose on the B-26 so I need to add a couple of elements rather that having one square element.

I can add the elements without any problem but I can't see the picture to adjust the mapping.

I just did a test to get a definitive answer to your earlier question, but I will use it to ask for ideas on another matter that I raised at the Gen earlier today.

This was my skin folder with just the primary files.
I made copies of my "Plane01" BMPs and re-named them to match the names of the primary TPCs



It worked, as we can see the "Plane01" BMP textures on the primary 3dzs:



What I mentioned at the Gen is the rear wheel and the aerial.
In the "PlaneAEX.TCP/PCX" there is a pink area which is a transparency.
The colour is the same in the BMP, but it does not work as a transparency.
Is it possible to fix this?

Just a reminder that this is part of a project which is meant to go like this:

1. A player has a good single skin in 160 format, but no BMP files. He wants to make a set of multiskins, with editable BMPs using the editor I have just made.
2. He "unpicks" the TPCs, and converts the PCX files to 24-bit BMPs so that now he has the BMPs.
3. Using the editor he makes the Plane01 files, modifies one of the Plane01 BMPs, and tests them.
4. If he sees that the modification shows on the Plane01 he knows it is working, and on a couple of mouseclicks he can make the Plane02-Plane15 files.

At a very simple level a player could create 24-bit BMPs for a single skin and edit them in MSPaint just for a bit of fun. The TPC files are not changed so nothing can be lost.

So I would like some means of fixing the transparency problem, that players can use.

Jel

There is a version of the studio that uses BMPs.
I have not used the studio for years, so it may take a while. Iron Mike may know.

The settings for transparency on an 8 bit pcx are :

Red - 252
Green - 0
Blue - 252

Hue - 213
Sat. - 255
Light - 126

Edit the pallet so that the first color has these settings.

I used the same settings on the 24 bit bmp that I just made and it worked. Which surprised the hell out of me.

BTW, in case it wasn't clear, you color around the wheel texture with the pen set to this color.

Don't forget to make sure the element is set to "transparent" not "texture" and has a 0( Zero ) in attrib 1 and a 5( five ) in attrib 2 otherwise it won't work.

I'll poke around the GEN server and see if I can find the correct 3dz program. If not, I'm sure Mike has it.

Found a bunch of 3dz Studio programs at the GEN, some of them even include the phrase "BMP" in their program name, which would lead you to believe that they work with BMP files.

Unfortunately that is fake news. I couldn't get any of them to open the PLANEB.3dz. They all show an error phrase like "Needs a valid .pcx file".

I am far from being a photoshop expert and had all sorts of trouble when I tried to change those settings with the BMP file loaded in Photoshop 5.3.
If you get chance please have a look at my folder which is in a "SpitfireF-XXII MSBase.zip" in your folder on the server. It is one of your skins anyway

Fixed
It worked if I edited the palette in PShop with the PCX loaded to your values of

Red - 252
Green - 0
Blue - 252

Then I saved it as a BMP, loaded it in MSPaint and re-saved it as a 24-bit BMP.
The "PlaneCEX.TCP/PCX" had the same problem which I fixed using the same method

Not sure whose this is, kinda looks like Skylark's work, but for sure, it's not mine. I just included it in the inventory after conversion to 1.6 and the addition of the improved 3dz wireframes.

Anyhow, I put the edited PLANEAEX.bmp and PLANECEX.bmp in your root folder Let me know if that fixes the problem.

Ray, Jelly:
I commented the code with 24bit and aldo where I made changes so it would read bmps. The transparency is taken from an additional file if I remember correctly. The BMP format used is uncompressed, 24 bit, and the standard upside down BMP format. I thought I did a decent job commenting those changes to the code. It would have been the same as the version I shared with the code group.

I still have that code, let me know if you need me to look at something.

Alpha channels are always (some rare exceptions) taken from palette order.

Is there an easier way of doing 3dz,s or are we stuck with it.Heres something I threw together with the 3D program I use for designs.

Is it safe to assume that the last colour (or first depending on which way you are counting) on the PCX palette is the transparency?
If so I can write an editor which will make it FF 00 FF which works on the spitfire files I have been working with.
Then I could use my freeware PCX to BMP converter and not photoshop, make a 8-bit BMP and convert it to a 24-bit BMP with MSPaint.
That way a player could make 24-bit BMP files to play with, without the need for expensive software

Don't know about BMP's but yes, on the PCX pallet the transparent color is in the first position.

Ya' couldn't a made this utility ABOUT AN AEON AGO could ya'?

Well, I managed to get the mapping done properly on the nose art without a 3dz editor that does BMP's. It just took prior experience working with textures and some guess work.(And more than a few in game tests)

You can see how much sharper the image is:


Now that I have the "B.3dz" set up I can use the same process to make very hi-res nose art for the rest of the squadron.

Once that's done we still need to figure out why the wingviews won't change from plane to plane but one step at a time.

I just had a bit of fun testing the multiskin making software with one of Moggy's Midway planes









The names were added using MSPaint, which I also used to blacken a couple of rogue pink areas which I saw on the first run.
The bulk of the time taken was to individually convert each PCX to an 8-bit BMP, and then to convert each 8-bit BNP into a 24-bit BMP
I did not use Photoshop.

Ray I just checked Mike B-17 multiskins


I jumped to the fourth plane which is brown to check the wing views

The port wing is brown despite the green engines:


The starboard wing appears to be silver:


I cannot be certain if this is a fault in the skin files or a problem with the exe.

The green panel you see on the silver side is not a mistake. It is an anti-glare panel put there by Mike.

Not sure what's up with the different color wings though.

The only skin that displays the correct wing view in the B-17 slot is the first plane. I could not get the other skins 01-15 to display the correct wing. It did not matter that the 3dz pointed to the correct texture panel for the skin number. If you are not seeing silver wings on the plane you do not have the correct texture panel loaded . The wing view comes from the B17mex.tpc/bmp. Y'all eliminated the m3dz and most likey the mex.tpc/bmp from the skin set. So, the issue is that you are not using the wing view from the unit because of the missing mex texture panel. You are getting the generic included texture panel/s since the program is defaulting to the base model in the plane set.

Mike
The code for the "m.3dz" was still there but remmed out.
I have restored it, but with the B-17s I am still not seeing the correct starboard wing.
I will investigate further.

Look for the b17mex.bmp/tpc, it should be the old tex

I did not expect to have these skins flown so I used the files that Chompy created.

I didn't do much just threw together a basic copy of the original mex.pcx for the silver planes. This was primarily for the distance view, not a pilot view.



I did do a wee bit more for the green forts.




I did do a wee bit more for the green forts.

I made a BMP of the Plane01 "m" texture, flew a mission and jumped from the lead plane to plane01

The BMP


I can see the blue text


Still silver


It looks to me as though there is no texture area for the starboard wing in the BMP.
The textures appear to show the upper and lower sides of the port wing and port tailplane.
I do not know if this is part of the problem. I would guess that maybe another file would be involved.

This is a result of a little investigation with the SPAW B-17 single skin


The Y texture looked as though it was for a wingview so I made BMPs of the M and the Y and put blue text on them





I can see blue text in both views




I will investigate further and report back

Pretty sure this wingview problem relates to the "Y.3dz"

I have a mixed squadron of Mike's P-47D''s that have 4 or 5 different camo patterns plus some silver ones and they all show the correct wingview. The single engine planes use the U.3dz which is pointed to the *UEX.3dz.

The two and four engine planes use the Y.3dz linked to the Y.pcx and since the props are on the Y.3dz there has to be a YTR.pcx or you get the old "blocky props" issue.

What I found was that if you point the Y.3dz to anything other than Y.tpc, such as YEX.tpc, the YTR.tpc is ignored.

As to the use of the MEX.tpc for the wingview, this is not the standard approach that we've come to use. You copy the MEX.tpc and rename it Y.tpc. I saw this issues when I set up the B-17 squadrons for the new aircraft_inventor and I made the appropriate changes but the wingview issue remains unsolved.

No real luck. On the Y texture for this plane I changed the text colour to red, and saw it on both port and starboard views, so for this plane the M was not used for wingviews.
However, if we cannot crack this it is of minor importance because flying a four engined bomber is of little fun in EAW when all you can do is drop bombs with very limited accuracy, and hope that your gunners and your escorts can keep you safe.
For AI bombers the cockpit view is not needed.

While I agree with you about the level bombers in EAW this does affect the twin engine bombers like the B-26 and B-25 which are fun to fly as attack panes.

Upon further research at least one other linkage in the multiskins is not working.

In the B-26 package PLANEA.3dz points to PLANESEX.pcx because it needs the transparency file PLANESRA.pcx for the rear and upper turret glass.

This works but the next plane in line, which points to PLANE01SX.pcx, does not link to the PLANE01SRA.pcx so the turrets are opaque. And of course we also have the problem that PLANE01SRA has one more digit that PLANE01SX, thus complicating the file conversion routines you are working on for the new utility.

By extension I think it's probable that ALL the multiplane linkages are not set up correctly. That would be PX.tpc, MX.tpc, SX.tpc, TX.tpc, YX.tpc and ZX.tpc.

I will point out that the PX.tpc is not actually necessary if the props are left off the secondary aircraft. The game will use the props from the primary aircraft. Same for the ZX.tpc as the gunsight from the primary will be used if the secondary ones are left out.

So really, it comes down to the MX, SX, TX and YX that need to be fixed because, as presently configured, we can't have multiskin twin engine aircraft that use the extended transparency files. (Planes like the P-38 and Mosquito are OK as their multiskins don't require transparencies other than the cockpit and props.)

Also, if you're going to fix this might as well do it correctly and fix the digit issue by making the transparency files have the same number of digits as their comparable texture files. For instance, PLANE01SX.tpc should link to PLANE01SR.tpc, not PLANE01SRA.tpc. And PLANE01YX should link to PLANE01YR, not PLANE01YTR. I think this last one will fix the wingview issue as well.

Far as I can tell this wouldn't affect Mike's multiskins since they are mostly single engine aircraft.

I re-did the linkages and I will put the two files in your folder. I will also put the exe I made this morning with the m.3dz loading again.
I just need to change drives from W7 to W10 again.


Edit:

It is there now "Good tex link 021218.zip"
It has the "EAW Versions" folder with the new exe and my "EAWTM2" folder with the two texture link files, plus the text versions

I do not want to edit the filenames in the "TextMap1.str file".
If you recall the problem was the header in the "01-15" 3dz files where he extra two characters made the filename use all of the bytes from 3-16 for the name
Byte 16 has to be a "00" terminator, because the data starts at byte 17. This problem does not apply to the filenames in "TextMap2.str", so there is nothing to be gained from changing it

Urm, mine work just fine, it is in 1.28 though...

Mike your pictures do not relate to the problem
They are external views, and we get the same in 160 with no problems.
Fly the B17, and hit J to jump to the next plane so that you are in a brown one.
Use your mouse to see the pilot's view of the starboard wing and the port wing.
Are both wings brown?

We see the starboard one as silver.

But there is a problem with the external views too, just not on these models.

Amy model that uses one of the new transparency links, PRA, MRA and SRA does not work in multiskin mode even with the new exec you sent me.

Something very basic is wrong here.

Take this as you will since I'm NOT a code guy, but I'd suggest going back and seeing how the TEX/TRA, Y/YTR, V/VTR and Z/ZTR links work. Then figure out how to make them work not only for PRA, MRA and SRA but also with PLANE01PX, PLANE01MX, PLANE01SX and PLANE01Y. This last one is a PITA because it doesn't adhere to the new *EX naming standard.

Edit:

I forgot to mention that there is a problem with the middle distance models too.

Load Mike's 100th Bomb Group B-17G multiskins. The one with the silver, brown and green aircraft.

Line the whole 16 of them up on the runway and zoom out. Then pan side to side and watch the planes blink from silver to brown or green depending on the angle.

I got rid of the problem by editing the view distances in the plane.dat file, extending the views out by about another 50% but that's not a proper fix.

It has been a long day, and there is no *EX naming standard.
Did you use the new "EAWTM2" folder I included?
Check out the two text files to see the mapping.
There is no specific code for the mapping- it just happens when the two string files are read.

1 - I did use the new EAWTM2 folder.

2 - There is a naming standard, admittedly adopted late in the modding cycle but there is one none the less. It is based on the *TEX.pcx from the original game set up. In this scheme all the texture files are called AEX, BEX and so forth. Some of them are also assigned transparency links just like the TEX / TRA link, namely PEX / PRA, SEX / SRA and MEX / MRA. but the links don't work for the multiskins where the naming convention has a different number of digits for the textures and the transparencies.

3 - Even with the middle and long distance models deleted from the folder the planes blink back and forth between silver and brown or silver and green.

4 - Long day indeed.

Edit:

The TX/TR link works. The B-17 turret points to PLANE01TX.pcx / PLANE01TR.pcx and the turret is clear not opaque.

I have not finished reading the thread, but it is easiest to comment such a fast moving thread this way. Well for me, when I am late to the conversation.

But there is a problem with the external views too, just not on these models.
Amy model that uses one of the new transparency links, PRA, MRA and SRA does not work in multiskin mode even with the new exec you sent me.

we are talking about models other then single engine fighter file standards. This leads me to believe there is an if statement missing in the code. Jelly, if you are looking for my work, you should find an Aldo, 32bit, multi, or skin comment. Those are the search words I would start with if you ask me to look.

The rendering uses a path flow ( "for" or "case" statement) to check all of the original parts of a 3DZ. IF, the new part is within one of these case statements, then if would be ignored. I sounds like a follow the IF trail. If you leave a subset of a path flow, you return to the original path.

again, another indicator that the loop is returning control. Sorry for the programming words, I am thinking.

another indicator that the flow reverts to it's parent before a child is searched for.

I am not surprised, a motorcycle mechanic started that code path.

This is important for rendering efficiency.

If I can help, tell me what you need from me.

Mike's work is limited to art? If so, fixing the problem will not change his work unless he was required to make a "bodg" with his original work.

posting incase my computer crash. will edit, which it did
Jelly, you could be dealing with a memory pointer issue. If the cockpit memory is pointing to the wrong memory, you will see an error like this.

This is a new part of the model. It reinforces the suspicion that there is an incorrect memory pointer after switching to the the players cockpit. Is it the same error when the players starts on the runway with this 3D model?

I think I am done, and #10 is opened so I know I am done for this post.

Slipping in a side comment. IM, I wish you and yours a Merry Christmas, Plus a better and blessed next year.

Guys, PM me if I seem to dissapear from a conversation. OG has fixed my PM notificaton. Too bad he can not do the same for this Aldo.

Fly the B17, and hit J to jump to the next plane so that you are in a brown one.
Use your mouse to see the pilot's view of the starboard wing and the port wing.
Are both wings brown?

We see the starboard one as silver."


Tony, I have already answered that question.






I am getting the feeling that I am not welcome in this discussion. My offers to help have been ignored. Too effen bad ain't it. I am out of this thread.

p.s. the mex.tpc is what is needed, not the m.3dz. The wing view on the original skin points to the b17mex.tpc, the 3dz is for the distance view used in the earlier exes like 1.0-1.28. That was eliminated when y'all made the slotless system.

Mike,
Your input is needed! Your work is respected. You are not a coder, do not be offended when a guess at the code points to the artwork.
Edit: and you knowledge of EAW is respected. Your suggestion would be the first that should be tried.

Thanks. You are correct, I am not a code writer. I paint skins and "iron out the wrinkles" that the detail I put in points out. Nor do I posess the skill or knowledge to create skins of the highest quality like Col. Gibbon. I am fortunate to be able to connect the dots and align the off kilter elements that are contained in most models and passed on as these models are reused and modified. Anyway, that doesn't really matter anymore.

Mike. Just step back a moment and look at it from my perspective.
You posted a series of pictures and said they were fine. They were, but they did not relate to the internal view problem which has become the focus of this thread. There is so much comment regarding this problem, and given that I had been working on it and testing things all day, I had simply forgotten about your earlier post.
Hence my reply.
BTW your black colour for transparencies works fine with 24-bit BMPs in MSPaint and that is what I use

The 3dz header constraint:


Note how the name of the texture starts at the third byte in the first row, and after the last character the bytes are 00. The first 00 indicates that the text has ended, and is vital to the process.
In" PlaneA.3dz" bytes 15 and 16 are both 00
In "Plane01A.3dz" byte 16 is 00
The data starts at the first byte of the second row.
If the header in "Plane01A.3dz" were "Plane01TEX.PCX" then the last "X" would be in byte 16 and there would be no room for the essential 00 terminator.
This is why the filenames for the 01-15 3dz headers had to be shortened, as in "Plane01TX.PCX".

The latest texture mapping files (as text not str):


The versions for Plane02- Plane15 are the same as Plane01 but with the appropriate number.
The text in "TextMap1" refers to header in the 3dz file
The equivalent text in "TextMap2" is just the link, and not a header in a 3dz file, so there are no restrictions on its length.


Ray:

I would be happy to add "Plane01y.TPC" mapped to "Plane01ytr.TPC" etc, and any others that you suggest.
There is one potential problem which is when a "Plane01y.TPC" exists, but there is no corresponding "Plane01ytr.TPC" and a file not found CTD could occur.
I cannot remember for sure, but I may have put a workaround in the code that only loads the linked texture file if it is there, and does not CTD if it is not.

Please send me the skin files you are working with so I can see the problems that you are encountering and try to fix them

Allen:
I just sent you a PM

I'm surprised that it might lead to a CTD.

From day one of EAW, well before any of us were modding, when other transparency files were missing the game ran but you'd see opaque elements rather than see through ones. I would have thought the same thing would happen with the Y.

I will put a B-26 package together today and put it in your folder.

I have sent Aldo a clink to a file with a lot of his code in it. If there is a problem he might find it a lot quicker than I can.

I put a zip in your folder called B26B(Multi).

I included PLANE01A.3dz along with PLANE01SR and PLANE01SRA, the texture and transparency files for the second plane in the group.

You will see that all the planes look correct EXCEPT the second plane because the rest of the group uses the primary plane files. You do have to look closely at that second plane, it's not obvious at first but the tail gunner and upper turret are opaque.

You will also find the nose art for the first ten planes in the group.

I have it loaded and see the problem.
Which 3dz / TPC has the rear and upper turrets?
I guess the "A".

Yes, it is the A.3dz which points to the SEX / SRA textures on the lead plane and SX / SRA on the secondary planes. I only sent the offending files on the first of the secondary planes (PLANE01). All the remaining planes are still using the primary skin so they will look correct, but it also means they have the same identifying letters as the lead plane.

Don't forget to check the other problem I described on Mike's 100 BG B-17 mixed silver, green and olive drab skins.. That is, zoom out as far as you can and pan side to side. You will see the green and olive drab planes turn silver as you go side to side.

I am looking into this now.

Can someone tell me if I am missing any of the parts that make up the 3DZs used for the internal and external views?
F, P, A, B, C, E, G, M, U

I think you are correct about the missing bit in the code. I have successfully used PRA, MRA and SRA in my 1.28 sets. I have even used 3 in the same skin set. I hope you can iron out the wrinkle that is preventing them from showing up correctly. So, in my "non-code writer-muggle mode" I agree with you. It must be a code issue concerning the running those pesky multi-skins in 1.6.


P.S. you are missing L & R for damaged wings, v, w, x for internal cockpit and y for the internal prop view.

The complete list, if they have one, their corresponding hardpoint codes, plus if there is a transparency link:

A- 25
B- 26
C- 27
D- 30
E- 28
F- Main model on single engine planes, left side of miltiengine planes and central file for the "Empty F" planes. (uses TEX/TRA)
G- 29
H- Shadow ( uses TEX/TRA)
I- 31
J- 32
K-33
L- Left shot off wing
M- Middle distance model (uses MEX/MRA)
N-Nose art
O- 34
P- Outside prop (mostly but not always)(uses either TEX/TRA or PEX/PRA))
Q- 35
R- Right shot off wing
S- Far distance model (uses MEX/MRA)
T- Furthest distance model ( simple lines without need of textures)
U- Single engine wing view ( but some multis use it also, like the B-17)
V - Left side of cockpit
W- Right side of cockpit
X- Gauges
Y- Interior prop in single engine models and wingview on most multis.(uses Y/YTR)
Z- Gunsight (uses (Z/ZTR)

Note that SEX/SRA are not used for the S.3dz but rather can be used as needed when a model needs an extra transparency set.

Note also that these are generalizations. There are many, many models that don't adhere to this texture file standard since any 3dz file can be pointed to any texture set the modder chooses simple by changing the internal header with a hexeditor.

OG, if my posts are in violation of the code publication rule then strike them and let me know. I have tried to edit a response to Jelly's PM, but if I work in VS6 while the editor for PMs is open, my wireless card crashes XP. CNN has teached me the meaning of redacted.

Jelly,
Did you intend to leave slot 35 of the data untouched in the reset?
whole_plane[36];
clear_bytes( &whole_plane[1], XXXXX*sizeof( obj3d) )

Ray, thank you. That is the information and insight to the group thought that I need. The group has added a number of letters to the 3Dz. I need to compare your numbers to the spreadsheet I have been working on for the whole_plane buffers. This is an array of obj3d. This is an array that is local, not global. The naming convention of whole_plane is used for a obj3d array in several places. The numerical values in your list lead me to believe that you assume these "slots" are the same for every whole_plane array. I did find that hard-points uses a local obj3d array named whole_plane.

A- 25
B- 26
C- 27
D- 30
E- 28

Ray, Jelly;
Are those slot numbers in a assumed global array?
10;pPlane->Type->Nose;
25;pPlane->Type->TopTurret;
26;pPlane->Type->BotTurret;
27;pPlane->Type->NoseArt;
28;pPlane->Type->FullSecondHalf;
29;pPlane->Type->FullOtherHalf;;;;xxx;object_vars;;

Sig for this post: I am not god, I stand ready to be corrected.

Hold everything- the B26 turret problem is fixed, and I need to check those other problems.
I need to re-code the routine that loads "textmap1.str" and "textmap2.str".
The turret fix was putting them in the root folder or the theatre folder.
Originally the default versions were in the "EAWTM2" folder, but if there is not a copy in the root or the theatre folder the current exe is giving a file not found error.
The same error occurs even with copies in the "GameData" folder.

Ray.
Unfortunately the pilots wingview problem remains
There is a problem with the new "Y" link. Several existing skins have the "Y.TPC" but no "YTR.TPC" and the CTD I predicted occurs.
Why is the "YTR.TPC" needed?
If I remove the link the B-26 turrets still work as the "Y.TPC" is not involved.

You need the YTR to make the prop blades transparent from inside the plane.

Can you tell me which skins are missing the YTR?

A lot of Mike multiskins have a "Y" but no "YTR"
I was looking at your files


How does the YTR relate to the Y in this case?

Could there be a generic YTR?

Notice on the Y that there is a black area with a yellow line across the top and next to it a horizontal black area with a yellow area to the left.

Then note that on the YTR there is a blueish "V" shape surrounded by pink. Pink being completely transparent.

The static prop blades are mapped to the horizontal black area on the right where there is pure blue on the YTR and the spinning prop blade are mapped to the "V" area where there is a less blueish area.

If you look closely at that "V" you will see a range of blueish colors. The bluer the color, the more opaque. This is how you get the spinning blades to have a darker tone towards the middle.

As to the idea of a universal transparency, I tried that with the original SPAW and you remember what happened. It cause all sorts of havoc when converting to the slotless system and I ended up reinstituting transparencies for all the slots.

Once we got the extra transparencies PRA, MRA and SRA I began to convert to something like what you are proposing but only for single engine planes.

I exclusively assign the PEX/PRA to the external prop and I've built a library of props that I can drop into any aircraft folder without interfering with the existing TEX/TRA files which is where the prop used to be assigned.

Same thing holds for internal props on single engine planes. I exclusively assign the Y/YTR for these props and have them in the same library as their external prop counterparts. So it's also a simple operation to drop them in the appropriate plane folder.

Saves a huge amount of time

However, internal props on multi engine plane is another thing. With the single engine props the textures are pretty simple. There are three texture types, Allied with yellow tips, pure black for German / Italian and various colors with a mid-blade stripe for Japanese. I can change the color of nose cones and prop blades in no time at all depending on the model.

With multiengine planes I need internal textures that match the external wing textures. FWIW, I do cheat a bit on this by using the same Y.3dz on similar planes. A perfect example is the one you've posted. That set of Y.3dz plus the Y.pcx / YTR.pcx textures stared life on the A-20 and has been used in one form or another on about 3/4 of the twin engine planes I've made. Just need to change the wing textures and the position of the wing relative to the cockpit and I'm done.

Still, there would need to be a change in a lot of aircraft setups to make this universal.

Is there any difference between the "Plane01.YTR " and the base "Plane.YTR"?
If not the "01-15" mapping could be to the "Plane.YTR" which would entail less fixing and also give fewer files to load?

There is no difference in the YTR.pcx, only the Y.pcx so that would be ideal.

In fact, we could save some storage space, memory allocation and load time if all the transparencies pointed to the primary slot rather than have their own links.

It would also do away with the problem of a different number of digits in the internal headers that's been a hangup for the new utility you were working on.

What do we use the "PlaneMRA.tpc" for?

It is normally used as a transparency for the M and S distances models. In my opinion totally useless as you can't see if a cockpit is clear or opaque at that distance and most distance models don't even have props.

Be aware that the MEX/MRA set has been appropriated for other purposes. I think IM said he used it for the wingview on the B-17.

I used the 3dz that Chompy put into the original hr model. On your new tra there isn't a spinning prop in the texture. They look like an old fashoned ladies fan. Look at the original pbb17tra.tpc or any other to see what I mean. It may relate to the upgraded props Ray is using.

Look at the mex.tpc Jell posted on page 5. The external prop is on the left hand side. It is where the b17 wing view looks for the props. if I am correct then you will have to mod the texture and tra for that new 3dz.

Or, Ray’s mods are in conflict with the ms bit in the code. MS was written for the older exe.
So, that bit may need to be looked at and changed to take into the changes Ray is making with his super models.
Just a guess on my part being a code muggle.

If this is true wouldn't it a good idea to compare 1.28 code to 1.6 code and see what's different?

Yes it would be. I really think that those new 3dz's you are using are not being properly recognized in the MS section in the code. Jell didn't report issues with my older units under their conversion to 1..6.
Well at least I don't remember any. Next thing to do is load up the plane set Jelly put together of my squadrons and run the Forts. They may not have the newer bells and whistles but they should render correctly. Let me know because I am without a PC that runs Windows 10. The one I bought came out of the box dead last Thursday and I have to ship it back to HP for repair. The one I had hoped to replace passed to the digital heaven the week before.

Jelly,
There is a second spot where you did not add to the array calculations commented with "//Omission correction by Jel"
copy_words(pPlane->xxx, object_xxx, 45);
Shouldn't the increase match the number of additional parts you added?

You have changed the prop animation from a bit shift of 8 to a variable. Is is possible that the data you are using shifts the bits wrongly?
short propspeed = xxx;
You may consider using floating point for this. You then need to add a type cast to make the compiler happy.
object_xxx[VAR_PROPxxx] = -(type cast)((pPlane->xxx].xxAngle / propspeed)); That is just a thought. this is how you achieve smoother animations.

M model is not loaded unless it is the leader in draw_one_dot_part. I believe this is the medium detail model. That could explain the switching skins of the FW190 reproted by Ray. I am unsure if you still use the far view dot of the original code.

M is not loaded within "load_plane_model". This could be the object viewer routine. I do not remember, but Gibbons added the S in 2010.

Look at the extern declarations at the top of the file add by CG and myself. Are you missing any that you need?

You have changed the file names from the stored data name to a dedicated "plane" name. Is there a misspelling error in the 3dz?

The global variable "whole_plane" array is used for internal and external views. The array is cleared before loading external views. You may consider clearing it before loading internal views.

It is almost 4 am, I am calling it a night.

Thanks Allen. I will get back to the source code once I have finalised the mapping files.
Copied from the other thread:

It is not a code difference.
The code just makes the exe read the mapping files and loads the transparencies listed.
The difference is in the mapping files. The 160 versions have additional mappings based on Ray's suggestions
This is an extract from the 1.28 mapping files.

#1
pp38hpex.tpc
pp38hsex.tpc
pp38htex.tpc
pp38hv.tpc
pp38hy.tpc
pp38h01mx.tpc
pp38h01tx.tpc
pp38h01vx.tpc
pp38h02mx.tpc
pp38h02tx.tpc
pp38h02vx.tpc

#2
pp38hpra.tpc
pp38hsra.tpc
pp38htra.tpc
pp38hvtr.tpc
pp38hytr.tpc
pp38h01mra.tpc
pp38h01tra.tpc
pp38h01vra.tpc
pp38h02mra.tpc
pp38h02tra.tpc
pp38h02vra.tpc

These files were originally made from an extract of a hard coded tables in the 1.2x exe. Then multiskin links were added, and It is the same for each one of the 30 planes.
Only three of the multiskin files are mapped, (01mx->01mra, 01tx->01tra, 01vx->01vra)
It is interesting that there is no mapping for pp38hmex.tpc,

In the slot free version "pp38h"..."pv1v1" all became "plane" so there was just one set and not 30.

I am going to go back to the original version of the 1.60 mapping files, and then add any additional mapping needed to get Ray's B-26 working.


Update:
I have it working by mapping the "plane01-15sx.tpc" to the "plane01-15sra.tpc"
I made and edited BMP files for plane01 to test that the BMPs were working.
You can see the transparent turrets.



What is not mapped is the "planemex.tpc" to the "planemra.tpc" because it never was originally.
This fixes the file not found error which occurred when they were mapped and a skin had a "mex" but no "mra".
As a test, and because they were never used, even though they were present, I have removed all of the "planemra.tpc" files from my working folder.

Jel

As reported in another thread I have fixed the B17 multiskin problem, and we now see the correct colours on the wings in cockpit view

Hi ,

Interesting thread though way over my head in terms of the coding etc. Ray's comments re prop colours is a bit of an over-simplification but under the circumstances not a real problem - for example Luftwaffe props were officially RLM70 Schwartzgrun not black but I guess black is close enough. Japanese props are somewhat problematic and there is some debate in the plastic modelling community as to whether the twin 3cm red stripes near the tip of the silver early props and the single yellow stripes near the top and either middle or bottom of the red/brown "tea coloured" late props (both with black rear surfaces normally although some early silver ones used the same "tea colour".) were on the front only. Some sources say that they were also on the back but I have not bothered with the ones I have built, presuming that Hasegawa, Fujimi and Tamiya have more accurate knowledge than I have. The Ki-84 of course often had greyish green props and some Ki 61 had full yellow tips just to confuse the issue. The early silver US props with the tri-coloured bands look good but can be a pain to paint in 1/72 scale when you have arthritic hands and decal strips are ruddy fiddly! I believe that French a/c imported from the US (Hawk 75, DB-7 and Martin 167) would have had yellow tips, unlike the "indigenous" French made planes. As far as I am aware all props were treated the same irrespective of the number of engines.

Rivet counting as ever but I am impressed with the progress you are making. Given the age and variety of the "models" you are dealing with, I suppose it is inevitable that some will not easily conform to the upgrades Jelly has made but you seem to be getting there.

Peter

Good to hear from you Peter. It's been a while.

Your comments highlight the never ending debate over rivet counting vs game play.

Rivet counters look for absolute accuracy, well, at least as accurate as possible in a 20 year old flight sim. There's certainly a place digital model making in the EAW world and those who practice that trade are to be commended for their dogged efforts to get things just right. I'm amazed at what they can do.

But then there's the rest of us.

The guys who are more interested in accurate flight models, a vast array of planes to fly in a large number of scenarios, who don't give a hoot if the Jap planes have stripes on the front and back of the props.

Fortunately for all of us, EAW is adaptable to both worlds.

You should check in more often, your observations are sorely missed.

Don't forget those who like immaculate and fully cleaned up 3D models with a working R/S,

VonBeerhofen

I’m glad that everyone has been showing good behavior about all the differing preferences. Room for everyone in the pool.

Just no peeing in our happy pool.

There are those of us who do care about the colors that props have, correct camos and colors. The list also includes the correct codes and markings for the aircraft we fly and shoot down. These little things add to the atmosphere that EAW has come to represent. Without these bits we might as well go back to Microprose "Spitfire" with its' limited views and stick figure aircraft. Good EAW is like a well prepared meal. It is the sum of the parts, not the turkey that makes it great. Good models cry out for good skins and accurate flight models. Come on, let's eat!

Eh, 1995's Microprose "Spitfire"?

That puts a lot of players, those not too interested in super accuracy, in the cockpit of a 1st generation flight sim.

If accuracy of models and historical scenarios are important to a player, EAW can be set up to do that.

If a player is more inclined to flights of fancy EAW can be set up to do that too without any loss of the feel of aerial combat which in the end is what the game is all about.

How about we just agree that there's plenty of atmosphere in EAW no matter personal preferences?

This should end the debate. No winners, no losers.......................................except if you forget to check your six.

They are also rivet counters. Rivet counting is another phrase for desiring accuracy.


Well said. It is my opinion that EAW still survives because she can be the mistress you want if you spend a little time with her. And that she is lucky to have so many suitors, willing to share there vision of her beauty.

Wish all of you a Merry Christmas

Brit,

What you wrote is technically true but the discussion was really about the graphics and wireframes.

What comes to mind is the old saw "The enemy of good is perfect".

I prefer the "good" for a couple of reasons.

1 - I can turn out good models probably 10X faster than perfect models which goes along with my personal opinion that variety is what keeps players coming back to the game.

2 - The average player spends very little time outside the cockpit, admiring his plane AND he sure doesn't spend ANY time admiring the accuracy of a plane in his gunsight.

That's said, I think it's great that other members use EAW as a digital model making program to produce some outstanding products.

What better thrill for an aircraft junkie than to see your personal creation flying and fighting in a flight sim?

The thing that makes EAW stand out in the flight sim world is that it can accommodate both types of modders.

Well said Ray.