Written and Edited by: MarkEAW

[ GOTO THE MAIN EAWHS PAGE ]

CONTENTS

INTRO

• The EAW Error Num: 7217.
  
• Tearing Map Selection Screens.
• Minimum ALT Of Viewposition.
• Terrain Shimmer.
• Campaign Crashes / Movies Play.
  
• Glide Mode Issues.

• The Sun Doesn't Blind Enough.
• Missing A Rearview Graphic.
• Missing Horizon Distance Fog.
• Gunsight Flips.
• Instrument Gauges Fuzzy / Blurry.
• Models Seen Through Terrain.

• AI Rarely Use Cannons.
  
• AI Behave Horrible.
  
• Escorting AI Return To Base.
  
• AI Reduce power.
• Damaged Leading Bomber.
  
• Wingman/flight Hardly Will.
  
• AI Drops On Target From The Side.
• Night Does Not Effect AI.
  

• Pausing
• No Kill Credit
• No Bombs
• Host Can Not Hear.
  
• Host Doesn't Have.
  
• Respawn Groundstarted Missions.
  
• No Join In Progress.
  
• MSNxy.DAT And Multiplayer.

• Memory Allocation Slow Downs.
  
• Rocket Freeze.
  
• Garbled Cockpit.
  
• Color Palette Corruption.

• Every Bullet Shows A Tracer.
  
• 'Blast Damage' Effect From Bombs.
• Luftwaffe Guns Jam.
  

• Engine Temperature.
  
• Limited Gear Animation.
  
• Spins And Stalls.
• Wrong Wing.
• Degraded Performance Effects
• Jump Into AI Plane Issues.
  

• Default Rudder Keys.
  
• Independent Engine Management.
• Repeated Control Lines in the EAW.INI
• Fast Computers and Mouse Clicks On Parameter Windows.

• Positional Sound For Engines.
  
• Positional Sound For Other Sounds.
  
• A.I. Throttle Sound.
  
• Wrong Radio Chatter.
• Sound of Engine Keeps Playing.
  

The bugs listed here are from the MPS Official released v1.0, 1.1, and v1.2, they are connected with the original code of EAW. Most of the problematic issues where tested and verified a few times each. Some of these need to be re verified before correcting source code. Not all are listed, so if you know of any and want it listed here. Post at CombatACE EAW Forums to contact me.

The idea about listing bugs back to v1.0 of the game is that it tells us how far back the bug started. Making it easier to know where to look, such as in game code or game data issues.

Some of these bugs where squashed or worked around in the unofficial Code-Groups EAWv1.28 game. Code examples from there can be used for comparison.

THE EAW Error Num: 7217

This section is to explain the Video Card Hardware / Driver Check in EAW, Video error: 7217.

The Issue Described:
In short answer, the 7217 error is caused by video drivers which no longer support 8 bit graphics displayed at low resolution.

When EAW was originally being written, hard drive space was at a premium (mid 1990's). So MicroProse EAW Team came up with ways to save space, one of which included using selection screens such as "Main2.pic" (it used their own form of compressed 8-bit PCX files). Routines in the game exe decompress and display them. Knowing that the game requires 8-bit 256 colored 640x480 selection screen support to run properly, the EAW Team at MicroProse added a routine that checks if the user's graphics card and driver can handle 8-bit graphics in 2D DirectDraw. If it cannot the exe exits with the self generated "Error 7217" message. This is because the game can not properly display the Menu Screens with-out color palette issues or tearing in most cases. To truly fix this, the games front end needs to be re-coded in at least 32 bit. See the Workarounds Topic further below.

How It Effected The EAW Users:
This became a real problem for EAW users back in the year 1999-2000 as these original users, the ones that have been playing the game since the relase in 1998 had started to leave the game behind because of this incompatibility issue. When they updated their systems and found that many of the newer video cards/and new drivers only supported 16-bit graphics and Windows itself didn't support 8-bit either at the time, they where stuck without a real solution (or a long lasting workaround).

These problems years shortly after would turn away many would be new EAW players. There are a number of people who are still having a hard time (in the year 2009 and above) to run this 1998 game on WindowsXP (even Win98SE) with their Nvidia video cards because of lack of 8-bit support in the drivers. Early ATI cards at the time had similar problems, however that company re-introduced proper 8-bit support and possibly support for EAW directly, Therefore ATI has the support for EAW that NVIDIA users don't have on those earlier OS systems.

The Cards Effected:
The series Nvidia 6 and 7 cards supported the 8 bit SVGA 640x480 mode. However it disappeared after the 66.93 (6.14.10.6693) driver version. One solution that worked for Nvidia users for a short while was for EAW gamers to roll back to this older driver version, if the card was able to. (series 8 and later cards cannot use the old drivers, so the 66.93 option was no longer available). Earlier ATI cards have had the same problem, until the company responded and updated their driver support, as I mentioned in previous topics).

Intels 810/815/830/845 chip sets with Integrated Video or their 82810 on-board video controllers unfortunately are incompatible with European Air War, due to a lack of any type of support for 8-bit rendering in the year 2001. Even years after, Intel had not added 8-bit support for those older chips, not even in newer Intel on-board 82845G/GL or Intel 965. (Nvidia on board chips, 6100/6150 have similar problems as the Intel counter parts do).

What Happened With WinXP:
In WinXP the windows vga.sys file took over most if not all the 8-bit resolutions and support, but it handles them poorly. So when the Video card makers dropped SVGA support from their drivers this resulted in this error. On top of that; The video cards also started to lack proper SVGA support in their VBios(VBE) which the Windows vga.sys file requires, but sometimes overlooks.

Later on, some of the card makers actually moved over from hardware VBE instructions directly into their drivers to maintain some support, but that didn't last long.

So a poorly supported VGA.SYS file and poorly made VBios/VBE drivers, makes for a dual hit trying to run the EAW flight sim since it starts up with VGA 8-bit (256 color) 640x480 fixed screens. Once the game got passed the menu screens and into the flight screens where the game uses a 16-bit graphics engine, all was fine.

Modern Windows:
Its not known if older video cards and on-board video chips have newer drivers available for them when using more modern Windows versions such as Vista/7/8/8.1/10, sometimes Microsoft will support some of the old hardware directly where the company's stop producing drivers, but not too old of hardware.

See my 'Troubleshoot Help Document' for more information on the Compatibility (REG) fixes produced by MS and the DD color reg fix by 3rd party's.

Note: The EAW game does not require a special video card connection type; a PCI , AGP , PCIe , Intergraded or On-board video etc....will work given that there drivers support 8 bit screens. See the Workarounds Topic further below.

Method's Researched:
The EAW community of coders, tried several methods of trying to improve the 8-bit menu interface, to not only prevent the 7217 error, but to also prevent the color and garbled (tearing) screens.

What has been researched so far: (by Sydbod posted 5-09-2008)

1) A study was made to totally separate into different executable files the flight part of EAW, from the front end part of EAW. This has lead to the "JIM" project. Most people by now know about this line of research. (This is a workaround external frontend and special menu screens made by MrJelly in the year 2007. This workaround was only for single play and didn't always seem to work for all computers.)

2) Another study was made to keep the menu part of the code as it currently is, but to intercept the screen writing routine and make it translate the 8Bit screen data into 32Bit screen data, as each pixel is being written to the screen.
This has also had some limited success, but has lead to a massive slowdown in the menu operation area for some people with slower machines. It has also shown up some deficiencies in the way EAW was writhing material to the screen by highlighting a screen tearing problem with some later drivers (this is a separate problem to the 7217 error).
Some of you have also tried the odd test version of the game with this modification in it.

3)A third study was made to integrate one of the many different graphics libraries into the EAW game, and use the capabilities of these libraries to relatively quickly rewrite the front end menu code in the game to 32 Bit mode.
This came to a very quick halt, because most members realized that they were now faced with not only having to learn the "C" language that the game is written in, ......but also to learn a new code library and how to integrate it into the code. This was felt to be too much, too soon, for the skill level of most of the code members, so it also came to a very quick halt.

4) The latest study is to rewrite the menu front end but use nothing other than the "C" language, and whatever the current EAW game environment allows us to use. This has lead to a few tests being made to actually use the Windows API functions..... these can be created directly within the game and have produced some working results.
The big problem with this approach is that it is a complex way of doing things and requires members to learn new skills that are not well documented on the internet. A person can easily spend days researching some small insignificant problem to sort it out. (remember ... we are all novices in programming, and the Windows API is a real bastard to work with).

For those that may be interested, ...what has been achieved with this 4th approach to date (was impressive). Yes it was integrated into the game, and the game ran using this menu to start a Quick mission...And another retro attempt at a different looking type of screen that may be more in style with the era of EAW.

As should be now evident, a lot of work has gone into the 7217 error research. We are a very small group of people that are trying to tackle a huge problem that is almost beyond our resources in skill level and manpower level.
Some of us are getting a bit burnt out, as we have all had to start with no knowledge of programming, no knowledge of game structures, no knowledge of the tools required to debug problems, .....etc. Trying to get the 1.28 update for EAW debugged and ready has almost killed many of us, without even looking at the 7217 problem.

Should there be others out there with some programming knowledge who would like to get involved in this nightmare, then please let one of the members of the Code Group know about yourself.

The Workarounds:
-To get around the EAW graphical 7217 error on older Windows (XP and before) you want to use a program called a Wrapper, for an example; the D3DWindower v1.88 Wrapper program. It allows the game to be run in a window without this error. It translates older DX games to a slightly newer DX version with some compatibility tricks.

Sound and 7217:
There is one instance that a 7217 error can also be generated when some DirectX sound routines mess up...but its unclear what that is...??

This map tearing was a troublesome for ATI/AMD Video Card Users with WinXP. (Nvidia GeForce video cards where effected as well, as far back as Win98, but later a registry fix was discovered by a virtual pilot of the game, read further below). Also later, back somewhere in Dec 2007 to the beginning of the year 2008 the then newly released ATI/AMD Catalyst 7.12 driver fixed the Menu tearing problems on WinXP, among other issues with the game.

However this tearing is now effecting Windows Vista and Win7 for ATI Video Card users. (Note: the 2D DirectDraw function in DirectX has been replaced under Win Vista and 7, and above). (When using Windows 8/10 , EAW does not have this problem, even when the game is run with no wrappers or registry fixes and at normal full screen because of the built in Compatibility fix layer). (Note: this issued fix in Win8/10 maybe why the game runs so much slower than it does in Win7).

Faulty Screen Update Rates:
The problem with EAW seems to be that the screen scan rates and video card memory map area are not solidly set when the game switches from one menu screen to the next. The tearing seems to be a 2D image sync problem within the video driver and written game code. Basically the menu screens are updated at such a high non standard rate but they should preferably only update when there is actually a change to be applied to the menu display (eg: mouse moves etc), the same way its implemented in all other normal Windows applications, but it's not. If you have a CRT display that shows the horizontal and vertical scan frequencies, you can try while you are switching between screens in the game, simply by making a selection. There is also a problem with the TARGET MAP screen when it comes up as a change in the video mode and frequencies occurs again.

If you happen to get the mouse over a menu hotspot on a tearing screen and click the mouse button, then the menu screen suddenly displays perfectly (it will be clearly visible) for that screen until the next menu screen loads (about 0.1 seconds). Basically that screen stops being updated while the computer is preprocessing the next menu screen and the tearing stops because the screen stops being updated at the non standard rate.

Interestingly, when in-flight pressing [Alt m] does reveal the PILOT MAP correctly.

Registry Fix (Win98 and XP):
The "NoAdjustedPitch" registry fixes for Win95/98/ME and WinXP are for Nvidia GeForce Video Cards (there is no ATI Radeon WinXP fix) which corrects the garbled map selection screen problem on those windows versions. It works by making sure that the video mode does not change unless there is a proper command sent to the video card to do so. This fix is apparently safe for all other games. This fix is by Ogdens_105 and Max188.

If you use the Win 9x line OS and have old hardware giving you this garbled issue, you will find there is a download able file which will make the correction to the registry automatically for you when you run it. However, if you run either Win 2K or Win XP, you must edit the registry manually yourself by way of text instructions.This is due to the fact that the Win 9x registries all show the relevant Nvidia keys the same way regardless of what computer its on, but under the NT kernel, the relevant keys have different hashes for each system so no automated batch .reg file could be written for this OS.

So, if you run Win2k or Win XP, download the proper text instructions for your OS and save the text file so you can copy and paste the relevant data once you locate the exact spot in your registry where you will be placing your new DWORD value. Insure you follow the instructions exactly; the placement, spelling, punctuation and spacing must be exact for this value or it will not work. It's reasonably easy to place something in the wrong place, so compare your location with the location in the downloaded document to be certain that you are placing it in the correct location. If it is in the wrong place, it won't work--it won't hurt anything, but it just won't work. You should, create a Restore Point prior to performing the regedit, in case an error is made. This is good to do when you are fooling with the registry at any time. While this particular edit is a safe one, something could go wrong, so protect yourself.

You can use a Wrapper if one is available to run on your Win2k and WinXP systems, see below.

No Registry Fix (WinVista and Win7):
The old "NoAdjustedPitch" registry fixes which corrected the garbled TARGET MAP selection screen problem on those older windows versions does not share the same registry settings on Vista and Win7, they are somewhat similar in XP and Vista, but the subtle differences mean an equivalent solution for Vista or Win7 has not been found. You'll want to use a wrapper program to correct the tearing, read below.

Wrapper Program Solution:
The solution currently is to use a Wrapper program that runs the game in a Window (not full screen) such as with nGlide or D3DWindower 1.88, the tearing will not occur. This seems to be the only fix for Windows Vista/Win7 and ATI/AMD Video Card users. It will work also for Nvidia cards if they have the same tearing issue.

MINIMUM ALT OF VIEWPOSTION

From a parked Plane, the height from the cockpit view are too high. Therefore the planes on the ground look strangely small from another's cockpit.

The problem when looking out your cockpit while lined up on the runway, and you are way higher than the rest of the Aircraft. You feel HUGE next to the other planes. But once in the air, the scaling seems perfect.

TERRAIN SHIMMER

The distant terrain shimmering is highly noticeable about the last one or two quarters of the way looking out your cockpit window, heading towards the horizon, it's even more noticeable if you don't have Horizon Fog covering the real distant terrain.

EAW uses two "picture" sizes (lores and hires) for everything but sometimes only one is used depending on your detail settings in game and your video card/driver capability's. As one picture size has 4 times more detailed then the other it can lead to shimmering effects, especially in the distance when the high res textures are used.

This makes it difficult anytime there are aircraft below the horizon as you can't see them due to the fuzziness. Other objects on the ground are known to shimmer as well, like Trees, Buildings and Fences. This problem existed way back when the game was first released on Win9x/ME, and later (year 2000), on other Window systems.

As noted above, EAW has almost always had a problem with displaying the distant terrain and objects. It could be an old D3D issue that doesn't translate well with modern cards, or video cards made sometime after the game was released, as early as the year 2000.

Shimmering and Screen Resolution:
Shimmering also depends on the selected screen resolution for the game as well as the video driver used, EAW supports resolutions up to 1600*1200 (In DX) and sometimes even higher. You must upgrade to at least the official EAW1.1 version for these resolutions to become available, (you can set them only in your EAW.INI with notepad manually).

Installing one of the available custom terrain sets may improve things even further, but its a hit and miss type of chance.  (There was attempt to do a partial terrain shimmering fix via ?graphically? in the EAW v1.28a update, but that partial fix has no apparent results on today's hardware)...

Old Solution:
The solution for older Windows and older Video Cards was to turn on Anisotropic filtering, (An increased MipMap setting was also used to eliminate shimmering back in the day). This was via a tweaking tool such for the very old Nvidia drivers, 40.72 or below; (RivaTuner, GeForce Tweak Utility or NVMax.) or if your video driver control panel supports it directly, you can enable it there, perhaps setting it to 8x. This would reduce or eliminate the terrain shimmering back in the late 1990's and early 2000's. This wasn't just a Nvidia problem as a issue for ATI video card users as well, and the same setting needed to be applied, if possible.

On Win7/8/10 this Anisotropic filtering setting is present in the Nvidia control panel, however it has no effect on the shimmer what so ever, same is true for modern ATI cards....Read the next section named 'VIDEO CARD CONTROL PANEL' for more information.

CAMPAIGN CRASH / MOVIES PLAY

The in game movies force a Crash To Desktop. This is most annoying issue when flying the stock career campaigns, none of the videos can play on modern systems without a CTD, like on WinXP and the other NT based WindowOS. Most often this is noticed just as a movie is supposed to launch, it will CTD.

The video clips within the game are all in Smacker format. This particular code in the eaw.exe is apparently for 8-bit playback only. It was developed for older systems like Win95 and 98.

RAD, the makers of the older Smacker Format have also made the newer BINK format for NT systems. There is a free substitute online however, for the 8-bit Smacker Playback called libsmacker - Its C library for Win32 that decodes Smacker videos. It should cure this problem if the code is replaced and updated in the eaw.exe, its untested as there are no Hardware programmers in the EAW community.

Another thing that maybe the real problem is it might be an old DirectDraw or DX issue on these modern systems. Sometimes a Wrapper Program can be found to play these videos once the Wrapper is configured correctly.... Note: The GOG/Steam types of the game include a GoG made DirectDraw Wrapper that seems for most, plays the intro and in game videos with varying success. The videos could stutter or they may playback fine.

There is also the quick workaround so the game can be played by skipping the movies. You replace the current MOVIE.CDF file in the games folder with a empty movie CDF file. You download (from my file archives) and copy the replacement file, the empty Movies CDF file into your EAW directory and overwrite the existing 284MB Movie CDF file. The resulting effect will be that the movies will not be shown in game, they are skipped since they are really not present anymore. This will help in the event that your getting a CTD or other problems when they try to play in game.

GLIDE MODE ISSUES

Broken Display Text:
This occurs when using 3Dfx GLIDE Mode in EAW at higher resolutions. Testing resulted in the stock v1.2 game defaulting down to 640x480 with a res higher than 1280x1024 but less than 1600x1200.

Plane Rendering:
It appears that Glide is more sensitive to Plane Model errors, specifically the Rendering Sequence errors that a modeler might run into. The default stock planes will display okay, but quite a few of the communities add-on planes have visual problems such as corrupted skins, holes, vanishing plane pieces and upside down or backward elements (Ex: The top of the wing displays on the underside and vice versa) caused by Glide that are not there for the exact same add-on when flown in D3D. So if the model looks good in Glide, it will look good in D3D.

Skin colors (with Glide API v2.43):
When in glide mode (using the old Glide API v2.43 found in EAWv1.2), the game gets all it's colors from a single 8bit fixed single palette of 256 colors rather than from the palettes associated with each image like found in D3D Mode. This mode can display many more (24bit) colors. That is why in Glide Mode you can get funky colors on some Plane Skins. A Rule of thumb is that If colors show up correctly in Glide, they should work normally in D3D, but not always the other way around.

Note the HUD Colored text:
is taken from the first 12 colors and appear to be the same regardless of video API, because they are the same in all standard palettes...

BMP in old Glide API:
It cannot use the 512x512 24 bit BMP graphics files found in source modified versions of EAW used in many multi-skin plane sets. These display only properly during gameplay.

Note View Objects Display:
Sometimes an add-on skin will not look right in the pre-game "View Objects" screen but will appear perfectly normal when you actually fly the sim. This is due to the fact that EAW loads all of its color palettes for gameplay, but apparently only one specific palette for the View Objects screen. If your skin uses a color or colors not contained in the View Objects palette, then the airplane in the View Objects screen display will not likely appear properly. So don't worry if the plane doesn't look right in View Objects; it's the gameplay that counts!

Note Glide API 3.0:
See the section GLIDE NOTES in my CodeGroup Know Bugs and Features Ideas Help Document for information regarding Glide 3.0 introduced in source modifications by Zeus, and transplanted by MrJelly into older versions.

NOTE: EAW uses what is called 'pixel fog' or also called 'Table Fog' in D3D. The old video cards; RIVA 128, RIVA128ZX and the RIVA TNT all emulate table fog using vertex based fog. The GeForce 256 supports table fog in hardware. (EAW can use by detection, either hardware or emulation) Windows Vista, Windows 7 and Windows 8/10 do NOT support 'fog tables' under DirectX 9c,10,11, directly.

Video Mode and Card:
The lack of fog occurs in D3D with the NVIDIA cards using Windows Vista and above. (ATI had the same issue back in the year 2005 - 2006 or so, but then AMD/ATI video cards added back into their video drivers, support for such fog. This was back somewhere in Dec 2007 to 2008 (ATI driver 10-07) / (Catalyst 7.12 driver)). The updated drivers not only worked for the modern cards, but works on old ATI XPRESS 200 , Radeon x1300 and Radeon x1600 pro video cards as well. NVIDIA never have added back support for the old fog effect that is in EAW, It was and has been requested by gamers back then in 2005. Nvidia did have an "enable fog-table emulation" option in there video control panel to help for awhile (I'm not sure when), but that ability was later dropped (not sure when) from support in their drivers and since has not returned. the next paragraph is what was in their control panel:

"Enable Fog Table Emulation: This option is used to turn fog table emulation on or off. Direct3D specifies that a display adapter capable of Direct3D hardware acceleration should be able to implement either vertex fog or table fog. Note: Some games do not correctly query the Direct3D hardware capabilities and expect table fog support. Enabling this option ensures that such games run properly with your NVIDIA graphics processor." -(Quote from a Nvidia very old Manual and no longer in Nvidia drivers.)

Shaders and DirectX:
'Table (pixel) fog' could be emulated through Pixel Shaders in DirectX 10. However this appears to require that the EAW FOG code be updated to utilize these newer specific calls. For the quick fix; backwards legacy/emulation at the display driver level should be done first with NVIDIA devices, such as ATI has accomplished back in 2007.

Another option is, D3D to support the Fog again directly, or even a Windows OS Compatibility Fix. None of the special DirectX wrapper programs seem to help either (they don't produce Fog). However, GOG's release of EAW's super patched eaw.exe and wrapper combo produces Fog...how, is a mystery to us, its speculated they updated the DX code in places from 5/6 to 7 with hacking; brute force in the eaw.exe. (as apparently they did not use the src).

Wrapper Solution:
The DXWnd Wrapper has a force fog function now that allows the fog to be present in DX mode. Also the GoG wrapper or eaw.exe applies fog correctly. This is on all video cards.

Glide Solution:
Another solution is to use a glide wrapper such as nGlide or dgVoodoo (or other Glide Wrappers) and run EAW in Glide Mode which will produce the Horizon Fog regardless of your video hardware or Windows / DirectX version. See the section in this help doc named 'GLIDE NOTES' for details about Glide and EAW.

(Started with v1.2)

Resolution settings Flip the gunsight drawing upside down when lower or above the 1024 x 768 pixels resolution. Then the gunsight will be even more off centre in the other direction when a custom g.s. offset drawing is used.
PapaRomeo custom gunsights has two versions, One corrects the flipped G.S. However with two files one can be wrong in one resolution and the other one might not be right in another resolution. It's just a workaround of the problem. When people don't know which files is in effect or what resolution should be set to get it right then it can only become problematic for users. This needs to be corrected in the source code.

(Started at least as low as v1.0)

Graphically I find the gauges un-readable, I tend to use the compass, rpm's and temperature the most, but I'm sure I'd use some others if I could read them. I even tried zooming in and zooming out on the gauges and they where all fuzzy both ways and normal view. Now this is not true with all planes but most of them. Some have very clean looking words, markers and numbers. There are the "Sharpened" instruments that you can download which where done by some of the EAW community back in the early 2000's, they are an improvement but not enough of one.

I'm uncertain what the maximum DPI the game can load and use? But It uses a very small 256x256 pcx image resolution to place all the working AND non-working dials onto. The way the past community members "sharpened" the dials where they used larger dials on the same location of the old dial, and kept the center of the new larger dial in the same place. This would give the artist a few more pixels to work with and they relatively came out clearer. The markings on the dials stayed in focus for the most part. They also use Fonts to draw/add to the dials themselves. They even went as far as placing unneeded gauges on other pcx files and just remapped them to give more space on the default pcx image. An option they used to start with clean and clear dials is to borrow from another WWII flight sim and use their gauges, either by ripping them or by getting screenshots and doing some scaling and re-sampling then some cut and pasting.

To truly get the gauges upto a worth wild image quality is to use a 512x512 pcx table image to work with. At that resolution the dials stay fully intact cause there typically double in size. Remember your only using a portion of the pcx image for each dial, but they will be clear.

RESULT:
Here's what it comes down to: It's a fault in EAW that's been there from the beginning...

The gauges right out of the box were never very good. (Some where readable at 640x480). Most guys only needed the digital display in the lower corners to fly and fight successfully. About the only gauges that were important were the fuel and attitude gauges. Both of which are good enough as is.

Sure a few aficionados watched their temp gauges but I'd hazard a guess that the average offline player turned off engine overheating in the difficulty settings. Seems like a good compromise as all you could do was throttle back to reduce temps. EAW doesn't have a full engine management set of controls so there aren't any cowl flaps to fiddle with. (Not sure but I think the online players do have to watch engine management a bit more.)

At this point, 14 years later there isn't anyone around to upgrade a couple of hundred different cockpits. (There is no central bank of gauges/dials that the game can load from, each plane has its own dials even if they are the same on another plane.)

Resolutions higher than 640x480 automatically force you to use the less detailed virtual cockpit structure. However the gauges that come from the static cockpits remain the same poor quality, possibly even looking worse at such un-heard of resolutions for this game.

Note:
Upscaling via a Wrapper program by setting 640x480 in game and doubling the resolution in the Wrapper program works pretty well to see the gauges a bit clearer.

MODELS SEEN THROUGH TERRAIN

Doesn't leave the formation early enough, it 'drags' the whole formation down (lose altitude) and slowed in speed. (Unfortunately the leader is the primary target of the AI´s attack).

(Started since v1.0?)

The MSNxy.dat files (found in DATA.CDF) contain probabilities of certain AI planes appearing. They caused a problem in multiplayer work because they often generated different AIs on different players' PCs.EX: One player could be shooting down an AI plane seen as a P47C and on another computer it would be a P38H. Also another example is if the mission is an Intercept of allied planes one axis pilot might see B17s escorted by P47Cs and another might see B24s escorted by P38Hs.

The probability needs to be transferred / passed from Host to all players, rather than each computer generating there own.

Mod tool authors back when a frontend known as OAW unified was designed, made is so the files were edited by the OAW selector and gave certain aircraft a 100% chance of appearing which guaranteed that all players saw the same AIs.

That method became redundant in the CodeGroups EAWv1.28 when in that version they where able to set the friendly and enemy primary and secondary aircraft and bases from within the games newly expanded Host Parameter Screen.

(Started since v1.0)

...and Crashes to Desktop. The amount of RAM in your machine is of no help here really as EAW uses fixed allocation addresses and between the arrays there isn't much free space for any additions and the allowed sizes aren't really known, it's touch and go there, the only use would be a bigger swap file which should result in a smoother operation of the game...The file allocation problem is inherent to the game, it hampers additional textures, terrain, objects, sky tiles and planes. Add-ons which cross the +/- 50MB boundary (minus the default files replaced) will often result in problems, usually leading to weird colored textures, messed up terrain, objects appearing in space and Lord knows what else...It's not your system, there's just a limit to what this game can do...

ROCKET FREEZE

This information is old and is obsolete methods for when playing EAW on modern computers, even when in Wrapper Programs that can enhance memory management. Read on if you need to know more cause you have a low spec machine and a very old OS.

The garbled cockpits are merely caused by too many objects and drawings in the game. Its a problem that can happen on some video card / computer combinations when there are a lot of custom textures for Terrains and/or Ground Objects that use a large amount of PC memory and possibly caused by too many loaded files...which doesn't leave enough memory for the game itself to run properly. This can happen with large sound files as well; When for instance texture memory only leaves a small space for playing sound files, then even a large sound file can cause problems.

....Some believe nobody should have problems with the likes of "garbled cockpits" or "rocket freezing" on modern windows or if running in Glide mode with texture memory limited to 2 or 4 MB: EAW was written when graphic cards had no more than 4 MB memory, as a consequence its code simply can't manage more...??

It can cause palette information to be overwritten and with certain cards cause the so called rocket freeze. Some graphic corruptions noticed where the external plane skin could get 'mapped' all over the cockpit models interiors of the aircraft or other disasters.
Note: Not to be confused with the memory issue; Some of the garbled cockpits aren't caused by a memory issue or file count at all, but merely by someone using a wrong image/skin or 3D model for the plane they witness the so called garbled effect in.. The problem can be cured by adding the proper cockpit to the plane.

Workarounds:
.....There where three known garbled cockpit workaround options by hex editing the eaw.exe, one for the Glide cards, one for the D3D cards, and one for the early TNT cards. The fixes for each where not the same, and one fix would work against the other fix, so it was not possible to include a universal garbled cockpit workaround.....you may find these avalable in the HEX Editted eaw.exe Downloads on my site..I seem to recall one at least having the workaround. Its a mean memory hack and is considered obsolete now on modern computers....keep reading below.

Effective Workarounds:
One of the effective implementations from idea's from VBH's texture and memory handling findings and Col. Gibbon had in November and  December of the year 2003 would require hex editing the exe to prevent the low resolution terrain tiles and "***s.TPC" files from loading (replaced it with '.tpc' without the s). Forcing the game not to load LR textures could possibly save 75% memory...So you can use more high resolution objects before the garbled cockpits reappear...the game can still Crash to desktop if the workaround doesn't apply to a given video card that doesn't handle textures the same way as the fix was designed for...from what I understand Andy placed this fix in his hex modified eaw12c4 exe (and the 1.1 equivalent)...Its for most but not all machines...works with Glide and TNT cards more often then it does for early Geforce cards(FX5000 series seems to work with it)....

This section discusses one of the issues when getting passed the above Video Card Error check.

In Windows7 (in the year 2015) the menu screens run properly without tearing and without using any wrapper programs (they wouldn't run on Win7 in previous years, before Microsoft Updates...), however the palette is all weird, resulting in the wrong colors being present on the majority of the menu screens, making it hard to view and read.

In Windows 10 this problem doesn't occur anymore. Windows10 supports this older DirectDraw/Direct3D combo game through a self set compatibility fix. (Although the speed of the game has slowed down).

See my ' Troubleshoot Help Document' for more information on this 'fix'.

What Happened:
What is happening is color palette corruption in old games, this occurs when some other program modifies the global Windows color palette while the game is running. Most often this program is Explorer.exe. Some people use to end the task of the Windows program Explorer.exe during the launching of there games. But that's not nearly the safest or best way to get the color fix. In Windows7 there is also a incompatibility between graphical interface Windows Aero and games intended to work with DirectX 7 2D DirectDraw or an older DirectX version (EAW uses DX6). The menu screens/animated menu screens all use 2D DirectDraw. However the game itself once in flight runs without the corrupt color because it uses hardware accelerated Direct3D.

Solutions:
One solution is to use a DirectDraw wrapper to color fix those screens, such as the DDWrapper program. Even if the game doesn't need a wrapper in your Windows OS version to play the game, it can correct the colors in the menu.

For Win7, I recommend you forgo the wrapper program and just use one of the two available Compatibility Registry Fixes which is a lighter option (less CPU power required). The registry programs worth mentioning are the "DirectDraw Compatibility Tool" by Galogen and "w7ddpatcher" by Mudlord. These create automated registry entries to correct EAWs Menu Screen colors, it's a fix without requiring a Wrapper program and is a faster game performance solution; Its considered a 'light' alternative, and works well with minimal overall overhead. See my Troubleshoot Help Document for more information...

How it Works:
The EAW game suffers from a "rainbow color glitch", when some other program modifies the global Windows color palette while the game is running, causing some screens to be rendered with the wrong colors, most often this program is Windows Explorer.exe. Windows 7 (and Vista) has a registry setting for enabling backward compatible DirectDraw behavior for a given application which fixes this glitch. So these programs read your eaw.exe that you select, then the program runs the game, gathers info, like the process ID information, closes the game, and saves the information.

Next it writes to your registry directly (Galogen's program creates a reg file you must install separately if you choose that option). This new Registry Fix entry will only effect the specific eaw.exe you apply it too; you should not move that particular game folder or exe as they are determined by the exact eaw.exe used, location included. It won't affect other parts of your registry or other programs. For instance, a EAW v1.0 exe and a EAW v1.2 exe are determined by the programs to be different specifically by various attributes of the exe, and Windows reads those differences when launching the EAW Game.)

These programs do not patch the eaw.exe directly, no modification is made to it. Once the new Registry entries are made, Windows Vista and Win7 (32 or 64 bit) will use them to run the DirectDraw 8-bit 256 color EAW Menu Screens under a compatibility profile without effecting the actual Direct3D 16-bit in-flight action game screens.

Note: This could be an issue with single game folders having swappable eaw.exe's like the CodeGroup's versions...

Important; Do NOT double up on the DirectDraw color menus problem workarounds. Meaning don't set one of these Registry fixes and then run a Wrapper program with DirectDraw(DD) 'color correction' setting as well, this will cause problems... You only need one or the other.

If you made a mistake and need to delete these entries in the registry file, here are there locations written by each Reg Fix program, pick which ever one you used (The first entry in each set is for 64bit WindowsOS, the other is used for 32bit WindowsOS):

The win7ddpatcher Tool writes here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DirectDraw\Compatibility\European Air War
or
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectDraw\Compatibility\European Air War

(Started at least as low as v1.2)

For some reason the MPS programmers changed or accidentally modified the default Rudder key assignments, as reversed from prevous versions. They are currently assigned like this:

RUDDER RIGHT=COMMA
RUDDER LEFT=SLASH

RUDDER FULL RIGHT=SHIFT COMMA
RUDDER FULL LEFT=SHIFT SLASH

But they Should Read like this:
----------------------------
RUDDER RIGHT=SLASH
RUDDER LEFT=COMMA

RUDDER FULL RIGHT=SHIFT SLASH
RUDDER FULL LEFT=SHIFT COMMA

Not really a big concern as these can be manually changed by editing the eaw.ini or changing them in game, but a bug none the less.

INDEPENDENT ENGINE MANAGEMENT

(Started at least as low as v1.1)

...is gone. The game was originally designed to have two engines max and for an example a pilot of a P-38 could control each engines power independent of each other with

THROTTLE ENGINE 1 UP=LBRACKET
THROTTLE ENGINE 1 DOWN=SEMICOLON

THROTTLE ENGINE 2 UP=RBRACKET
THROTTLE ENGINE 2 DOWN=APOSTROPHE

The Throttle for Engine 1 Down = ; Seems to work correctly, But Engine 2 Down doesn't work when tested on a P-38 and that's lacking in engine management area.

REPEATED CONTROL LINES IN THE EAW.INI

(Started at least as low as perhaps v1.0)

Regarding Win 2k/WinXP and other Windows NT OS (Vista,Win7/8/10) in the eaw.ini there will be once in awhile, repeated and unwanted lines at the end of the file: After what should be the last command line (ScreenCapture =) there are other duplicate control lines that you may never have seen there before, repeating several times:

NEXT ENEMY TARGET = T.
PREVIOUS ENEMY TARGET = SHIFT T
NEAREST ENEMY TARGET = CTRL T
FRIENDLY NEXT TARGET = Y
FRIENDLY PREVIOUS TARGET = SHIFT Y
NEXT TARGET EARTH = E
etc....

These lines may become problematic eventually as they keep being added and repeated over and over again (You may loose function of those keys and your Joystick one day), so it's recommend that you remove them manually every now and then. Note: This issue is not present if using a Wrapper Program to run the game. :)

The Fix:
XP does not handle some of the text errors in the original "Text_eng.cdf" file well, the few corrupted characters in one of the internal text files can be corrected. (This would solve the corruption problem which causes certain lines of the .ini file to become mis-stated and results in the loss of joystick settings, programmed button assignments and keyboard assignments as well as repetition of these lines at the end of the eaw.ini file.), and the community made replacement (included with the unofficial EAWv1.26) is considered to be essential for the Win NT user.

Target Assignment Bug (WinNT): The bug of TARGET CLOSEST ENEMY or TARGET NEXT ENEMY. Whenever you go to Configure Game, Control, Controller Setup and check the setting, it will always be set back to the default and ignores the assignment you previously set with Notepad. However, You should be-able too for an example, assign "target next enemy" (Default `T`) to a joystick button now with the fix.

FAST COMPUTERS AND MOUSE CLICKS ON PARAMETER WINDOWS

(Started with v1.0)

If you run the stock EAW (Including v1.26e) you will find that Vista and newer WindowsOS (fast machines) are too quick for the Multi and Single Player Mission Parameter selections menu line. By this I mean when clicking your mouse to make a selection change on those parameter screens, the selection will jump erratically / cycle fast.

I suspect this is due to hardware (or actually software) acceleration for DirectDraw.

There has been a workaround applied to EAWPRO by disabling the key repeat/loop. The unofficial versions by the code group used a extended delay. For those un fixed or no workaround, you'll have to keep clicking more often until you get what you want from the fast display of the selection that can pass by. Or try the two options below.

Vsync Workaround:
If your using a version or type of game that does not have a workaround (like the stock game versions), you could try to enable Vsync in your video control panel to slow those selections down, however this may effect your overall performance of the game.


Wrapper Solution:
In the DXWnd Wrapper program for an example, there is a setting in the TIMING Tab:

CPU Optimization, Slow Down Mouse Polling, checked (This will normalize the speed at which selections appear on the changing mission menus parameter screen)

(Started at least at v1.2 maybe even back to v1.0)

Positional Sound for two or more engine planes is in-correct. In the P-38 for an example, when the pilot turns his head left, you will hear the left engine in your right speaker, just like if you had One Engine center body mounted. You should hear the engine in BOTH speakers since the pilots head is turned toward the engine.

When the pilots head is forward, the game switches to the sound of a non-existent center nose engine. If one engine is off and the other engine is running, sound is heard from the nose...this is wrong. The only time there's indication from the left or right engine when the pilots view is forward is when the engines are starting or stopping, when they sputter there heard in the appropriate speaker.

(Started at least at v1.2 maybe even back to v1.0)

Buffeting sound, just before a stall it seems to come from the nose of the planes as well rather than from the mid section of the plane. Wind rushing in is wrong when you turn your head.

Also Gun sounds from within the cockpit come from the wrong direction with head turned.

(Started at least at v1.2 maybe even back to v1.0)

...,Setting RPM Sound. There is a difference in throttle sound between the AI aircraft and the pilot's aircraft. For an example; You are leading a squad in formation and cruising along at slow speed so some of the others can catch up.....your rpm's are low and your engine 'sounds' slow, like it's suppose too, but your Wingman right next to you, although he is going as slow as you, 'sounds' like he is at full throttle. The only time his engine sounds like he's working the throttle is when he's RTB and he is in a landing pattern.

To further notice this bug, If you jump (ALT-J) from your lead plane to your Wingman's aircraft while in slow flight, the Wingman's engine immediately slows down to match the throttle on your original.

(Started perhaps with v1.0, thought to be fixed in v1.1 and v1.2, but its not)

British radio chatter coming from American bombers. Seems every three bomber escorts you fly you get a British voice from the big bear flight. "This is WIZARD flight!" coming from B17's in a good ol' English accent.

(In v1.2)

Engine sound won't turn off when the propellers had stopped after an engine blows up.

[END]