Search the Community

EAW has got a number of user options in the .INI file relating to AI behaviour which are obviously quite usefull for beginners, intermediate or advanced players. To improve the game further and make the game harder and the AI tougher, there's obviously a choice to add more options to the .INI or to change how the game deals with these entries in the AI routines themselves. As a diehard player I'm ofcourse more interested in more skilled AI and more dangerous events have researched and changed both options. I find it however near impossible to change all level choices and have therefore concentrated on changing the highest selections only. Fact is that as these choices are used in real time, it's not a great idea to add more choices and decisions for the AI, as well as users, which will slow down the game considerably. However there are jump tables which won't cost anything extra, since they simply load an offset value and then jump to the routine in question. It's mainly these tables I'm targetting when adding more options and where an .INI might have an extra useer choice I prefer to implement multiple choices which are automattically made by the game itself. The clarify this, a user can select skill level 1 or 2 but I for instance will give that choice to the game where possible. What I've done however doesn't relate to skill level 1 and 2 but to level 2 (expert) only, giving the game an extra level 3 choice in real time. This affects AI behaviour throughout the game without having to change any of the AI routines themselves. Ofcourse I did mess around in those routines too but those are just minor changes, like the aim moment or the moment to fire weapons or when to start moving etc. which are usually based on enemy distance and position. I hope you will understand that taking away the benefit of an extra user choice in the .INI gamespeed is not hampered in any way but the AI are more unpredictable in their choices and responses. I also noticed that some routines didn't handle all .INI skill levels, in that they for instance set skill 0 and 1 being the same for certain decisions. Where possible I changed this to make the so called dumbest AI pilots in the squadron a little dumber then level 1 or in other words, I gave em their own level as should be. Now since the introduction of the ACE level in the parameter selection screen activates the extra skill levels but also allows the lower skill levels to use the skills of one level higher it should essentially compensate for this extra dumbness of the lowest level and make level 1 sometimes as skilled as a level 2 AI, in real time ofcourse. As I wrote previously, this elevated level has no influence on the decision making speed of the default AI's skill level, meaning they will make better choices at times but not as quick as the higher skill level it's temproraily using. I hope you can still bare with me but the Betatests have shown that occasionally the slower reaction time, while performing a higher skilled action, is sometimes not fast enough to perform the move successfully, causing more areal accidents, like the one's I usually make myself when flying online, like misjudging approach speed or not noticing another plane by my side going for the same target. Planes may accidentally fly into a bombergroup and collide with one of em, because they're usually large planes flying at low speed. Such accidents can trigger adjacent planes in the group to explode too, sometimes killing 3 or 4 planes at once. The chances for this are set pretty low so it doesn't happen too often, perhaps one plane in 100, exact numbers are hard to give as it's subject to a randomness calculation, so sometimes it may not happen for weeks and sometimes you get 5 in one mission. I haven't seen any fighter collisions but they have an equal chance if it wasn't for the fact that they occupy less 3D space and are usually chasing eachother, but with intercepts planes may come from all sides. Since the skill levels also control the speeds at which the AI are flying (dumb AI usually fly slower) there's the same possibillity with ground impacts, however previous changes prevent AI to start new moves when under 500 feet and start pulling out of any dive they're in to avoid ground collisions. Now this has worked beautifully well, even in very mountainous areas, but this new behaviour will change things, I just don't know by how much. Thusfar I haven't seen any abnormal ammount of ground collisions but one is not always aware of these happenings when the battle area is app. 100 KM2. I hope this will give you an idea as to what to expect with the next release of EAWPRO in terms of more visble AI changes. VonBeerhofen

This screen's horizon has always been a problem and was showing black areas on the left and right. The screen became pretty important to me to quickly check objects from all sides to identify any R/S issues and fix them, without having to fly the game, altough that would work as well but you'd have to concentrate on not getting shot down. The introduction of EAWPRO's HiRes skysets and UHR horizon posed yet another problem in this screen, but have already been partially fixed a long time ago. However the horizon problem stayed and always kind of atracted attention away from the object or plane I was watching. I finally found a solution which fixes this problem in D3D mode (Glide is still incapable of using my UHR Horizons) and the fix was tested with various resolutions on two different machines using different monitors and was verified to work with both traditional monitors as well as HDMI. I couldn't check any other monitor types but my HDMI monitor accepts nearly all possible resolutions up to 1920 x 1280 and they all worked fine, with standard skysets as well as EAWPRO's HiRes sets. I can't test XVGA mode, just don't have the dosh to buy one, and besides that I'm very happy with what I have already and have no room for anything more anyway. These screens were taken in my most commonly used resolutions on either machine, not very important but educational. VonBeerhofen HDMI in 1280 x 768 SVGA in 1024 x 768

It's come to my attention that some people do not understand how to select the previously none flyable planes which are not directly accessible through the plane selection screen. They can be selected and edited from from within any hangar by selecting the MISSION PARAMETER editor that sits on each desk in any hangar. When in the Parameter Selection Screen you then select the LOAD option at the bottom of the screen and a list of MISSION (.MSN) files will be displayed. You can select any of them, no matter which hangar you're in. The Default** ones contain your last flown mission for each plane, sadly they don't give much information about which number corresponds to which plane but they're sequentially American, British, German. The ones which display their name were SAVED from within the parameterscreen, very usefull to setup planecombinations and targets that you like but can still edit after it's loaded. I could give you a list of the default numbers but I think you can also write each number down after selecting each and note the plane you've selected. If you want to fly Mosquitos you select Mosquito vs ******. You can also save the Default missions with a name yourself. To do this you start with loading Default00 and you save it under the name P38J vs WHATEVER. Having all planes there you can quickly navigate between planes and load any on the fly without having to go back to the plane selection screens. When a mission is SAVED it'll store all your selections and you can store up to 256 mission files yourself, either before or after the mission is flown. It's more convenient to do things this way and has become a real timesafer when testing all possible combinations. The saved missions remain unchanged untill they're overwritten with a new one but every time you load one it will randomise the target location as part of a new airfield and target check to prevent CTD's when .MSN files are corrupt, don't work, or aren't at all present (which is the case in nearly all old addons). When a certain plane's selection has become corrupt you can still get to it's Mission file via any other Hangar and set it right again by editing the corrupt plane's mission parameters, provided you understand which one to select. Flying the mission will overwrite the old Default**.MSN file and things will work normal from there on. Note that when you reselect the same target and/or airfield already present in a corrupt .MSN file, the selection can't be set since either of the two is an illegal choice. Just select another one which displays the target number on mouse over and the file should be fine from then on as the editor only allows legal targets to be selected. Illegal target locations are greyed out in the editor, an indication of a corrupt .MSN file. Sometimes they can still be flown and will allow take off from enemy bases or attacks on friendly ones, but being corrupt you may not be able to enter these plane's hangars on startup directly, except with this method. VBH

the original Microprose NoCD version from the Source Code is now implemented, making the the old NoCD hack redundant. It allows the game to run on newer operating systems, even when a CD drive isn't present. This change will be in the next release. VonBeerhofen

intended for higher operating systems then XP. I managed to fix the lightning speed selection without compromising how it works on older systems, the only downside to it is that you need repeated mouseclicks to change the selections, holding down the mouse button will no longer incite the next successive selection. It applies to all keyboard input which uses this routine, possibly keyboard throttle and such too, but who's still using that option anyway? (retoric question) A big thx to Mark EAW who was so kind to test it's functionality! VonBeerhofen

A new filter was programmed which allows more diverse maneuvering for the lower AI skill levels. Expert planes remain unaltered by the new filter. The lower skills now have a 10% chance to do expert moves when the enemy is within 2000 feet. Expert planes are programmed to enter this phase when the enemy is closer then 1000 feet, simply because they react faster then lower skills. Additionally, the lower skills can still optionally follow the original game's maneuvering phases when not selected by the random routine. This essentially seperates rookie pilots from the more skilled and asigns them to their own maneuvering phases with a newly added phase for the greenest, which wasn't there previously. In short, the lowest skill, which in v1.2 was set the same as medium, now has it's own maneuvering phases and criteria for carrying them out and with the medium skilled they have an additional random option to do expert moves if the enemy is closer then 2000 feet. An additional benefit of this is that planes are less likely to get stuck in a repetitive or endless loop, like endlessly flying circles around each other because the game only allows that one option for a particular skill level under certain circumstances. The random expert moves will make em do something entirely different. Another benefit is that these lower skill levels are more likely to react sooner when an enemy gets close, i.e. within 2000 feet. This behaviour changes real time and makes it much less predictable as to when the none expert planes will start using expert maneuvering or when they stop doing that. The routine doesn't influence the preprogrammed reaction times for each skill level, so inspite of being able to detect the enemy sooner their moves will remain as sluggish as in v1.2. You can't become an ace pilot in a single battle but you can occasionally do the right thing either by accident or by learning from mistakes. Furthermore the criteria calculation now also allows higher skill levels to be introduced (Advanced Criterium Emulation or ACE for short, :D), EAWPRO already has many provisions for this but it's only partially active due to a limitation in the cofiguartion screen to select only 3 skill levels. I hope full implementation will follow. How this will play out in the end is beyond my prediction but anyone with advanced knowledge on AI behaviour is welcome to write an essay about it, :) VonBeerhofen

Some planes just don't have landing gear, like float planes and the Reichenberg, or fixed gear like the Stuka. V1.2 had no provisions for these, hence the gearswitch was always active. The gearsound would play and a gear message would display on screen. That problem is now solved and the keys for this action are no longer active for such planes. VonBeerhofen

It has always bothered me that several twin engined planes performing in a bomber role were sitting ducks, so some pretty observable changes were made to this behaviour. They will now be more evasive and may actually even start fighting back, after all they're heavily armed and why not use this feature for a more challenging fight. Ofcourse their main objective is to bomb the target and they're still pretty successfull at that, even when under heavy attack. Their behaviour was enhanced without compromising the original routines, in other words they will still do as was programmed but with an additional chance to do something new. In most situations they will try to regroup but it may not always be possible when for instance these planes are under constant attack or suffer from target fixation, which is not abnormal in the game. Planes with extra (dorsal/tail/turret) gunners may try to bring down the enemy or at least try and slow them down so the rest of the group can make it out of the battle area safely, even when they have no primary weapons or these ran out of bullets. I programmed a distinct difference between Axis and Allied aircraft, in that the Axis planes tend to be more agressive, which I think is in line with reality and since I think there are more Allied pilots still flying it also serves as a purpose to make it a bit tougher for them, but it will also not be easy when you fly the other side. These changes will be in the next release of EAWPRO! VonBeerhofen

The code was already there, it just had to be found and implemented. Took me a while though, :) Texture may still change. VonBeerhofen

For those who have kept track of EAWPRO devellopment there is a new EXE for download. Just overwrite your current EAW.EXE with the new one. All others need to download the full EAWPRO addon at Mark EAW's website and when installed and working you can add the new EXE by overwriting the old one. Main changes: rewritten fire routine to get rid of the sky fires and incorporated more fires into various effects new elevation calculation with additional offset for raised hitbubbles (no objects programmed sofar) damage model fix on twin engined various other minor fixes improved FPS by optimising the code and removing some 500+ extra bytes from the gameloop Some other improvements The file is available here: https://rabartel.home.xs4all.nl/ProUpdate.zip Hope you guys like, :) VonBeerhofen

Since the work on EAWPRO is a continuous effort I've decided an interim upgrade would be nice. Those who've kept their game updated can simply extract the upgrade into their EAWPRO gamefolder, allow overwrites and it should be good to go. Older installs will require the latest release version on top of an official Microprose version 1.x after which the new upgrade can be added the same way as above. The upgrade is available here: https://rabartel.home.xs4all.nl/Members/FXEXE.zip Some appetizing pics: Enjoy and have a nice X-Mas VonBeerhofen

It's come to my attention that the parachutist's 3D model was inadvertently removed from it's 3D.FXE archive, hence I've uploaded the model to my FTP site so it can be easily extracted into your EAWPRO folder (where the EAW.EXE resides) to fix the problem. The file is available here: https://rabartel.home.xs4all.nl/Parachutist.zip Sorry for any inconveniences, VonBeerhofen

A small example of the differences between the stock effects and the ones used in EAWPRO. This drawing shows the stock effects in the left picture and one of EAWPRO's effects in the right one. As you can see there are 9 different animations in the stock drawing, the bright colored squares are used for the tracers, one square for each calibre, and only 4 frames are available for fires. All other animations use 8 frames. EAWPRO uses an entire texture for it's 16 frames per effect and besides the longer and hires animations another advantage is that the drawing's color palette is individual to each effect drawing and is therefore much more realistic, whereas the 8 stock effects have to share those colors in a single texture. EAWPRO also uses 8 calibre colors with the option to use 16, as apposed to just 4, I just can't think of any weapons to use the remaining 8 colors. Furthermore EAWPRO uses 16+ of such Hires effects drawings but each effect can also borrow frames from the other effects drawings, which with certain animations allows a selection out of 16 x 16 = 256 frames. I hope you understand that this approach allows all effects to be swapped freely with another by simply renaming the texture file or .SPT filename. The same goes for their TRA (transparency) counterparts. I hope this explains why swapping Sprite Tables or changing them isn't as usefull as one thinks, after all each animation is linked to some action in the game and the routines for these had to be completely rewritten in order to make this work and it's not just a swap in the Sprite Table, that won't work at all since the used animations are defined in their own specific routines which control their actions. VonBeerhofen

I made a few minor changes to EAWPRO's contrails which will benefit framerates, especially when large numbers of planes are battling it out. A Glide issue with the trails was also fixed and will be available with the next release of EAWPRO. A temporary fix has been uploaded to my FTP which restores full functionality but doesn't yet use the new improved version. Just overwrite your EAW.EXE in your EAWPRO gamefolder with this version: https://rabartel.home.xs4all.nl/EAWPRO_FIX.zip Mark if possible you can do the same thing with the download version at Mediafire, it would save me from having to construct a new .ZIP. These are how it will look with the next release: VonBeerhofen

With the added 5 gun calibres came the need to display their tracers differently and this is how they look now: VonBeerhofen

Visit the EAW Launchpad for online games with EAWPRO, have a chat with like minded or for help and guidance relating to v1.2 derivatives! Teamspeak server details can be obtained via our (admission free) chatroom as it may change: http://www.chatzy.com/251310437564 Just leave a message or e-mail adress in our chatroom and we'll get back to you ASAP. Open all day ,no membership required, professional help or just a chat. And you can also have a look at my latest creations or just visit our screenshot gallery to get an impression of our games! https://rabartel.home.xs4all.nl/test/Gallery/image/ VonBeerhofen http://www.europeanairwar.net

A new feature was added to EAWPRO which changes the flightmodel's behaviour to allow for a wider range of aircraft. The feature was added to the EAW.INI entry FlightModel=X which now can use 4 values: 0 = off 1 = pre WWII planes 2 = WWII planes (default) 3 = post WWII planes There's probably a bit more to do but the switches are working. VonBeerhofen

Since stock v1.2's gunvalues don't allow the gun's full ranges to be used and the weapon names don't work when values are in between two callibres the routine was rewritten. It will allow deviations from the standard hitpower without loosing the weapon names and adds the possibillity of a 50mm weapon or higher. The stock values are 2, 4, 12, 24, however any single byte value can be used, so the maximum hitpower value can be 255. That would probably be a callibre the size of a medieval canonball or so, which is obviously not very usefull but it can be set. I've choosen 36 for the 50mm, since the value is the same when the 20 and 30 mm hitpower values are added up which I think will be a reasonable representation of the weapon. Ofcourse the ME262's nosemounted .88 is also a feasable option and I should have it's value somewhere when we tested it with an RAF pilot and friend, may he rest in peace, who flew Meteors in the Korean war and who also described the weapon's devastation It principally means that there's more room to precisely modify the PLANES.DAT's weapon's values to more historical accurate hitpower of weapons, which by default aren't incorporated. Another advantage is that in combination with the plane's armour values planes can be better ballanced against each other in terms of matching the planes advantages/disadvantages vs the other planes. Ofcourse the routine was optimised to run much faster, :) VonBeerhofen

Many more dangerous situations were incorporated into EAWPRO. One is the possibillity of AAA and flack capabillity on ANY groundobject, target or none target, static or moving. When a target location has a single AAA or Flack position, the maximum number of flack and AAA will be divided between all the objects which were given attack/defense capabillity. When one of the positions gets destroyed another one will take it's place untill there are no more objects available which were asigned this capabillity. In other words, the destroyed position simply moves to a new location and becomes active again. A new routine also gives the watersplash destructive capabillity when planes are directly over it and within 100 feet. Because of this effect belly landing on water has become much more dangerous as the splash is generated multiple times each time the plane hits the water. Exploding ground objects were given a simmilar but slightly different capabillity and even exploding planes can destroy your plane when you're within it's explosion radius, so it's prudent to stay at a respectfull distance when shooting up stuff. The explosion radius is linked to the exploding object's size, the larger the object the larger the blast radius. Planes in tight formation may actually cause a chain reaction with other planes and cause damage to an entire group. They will not immediately explode but damage points are given as with bullet impacts. Here's two pictures which show what happened to a low flying bomber which just came too close to an explosion, notice that there are no fighters around or any tracers visible, the explosion happened as the lead plane crashed into the ground. VonBeerhofen

Converted and adapted from v1.60 and can be used in Pacific Tide III The screen is available here: https://rabartel.home.xs4all.nl/DownLoad/MAIN_Corsair.zip VonBeerhofen

With the reorganisation of the sprite table I was able to introduce 4 new animations when bullet hits objects. The animation takes calibre and object armour into acount for the animation selection. These animations may also be randomly used elswhere, for instance in explosions or as debris flying off planes or objects. Other animations have also been activated to mix randomly with the selections. VonBeerhofen

With the help of Russ Watson I was able to fix a none transparent Glide trails issue which slipped through the net when effects detail is set to high. Here's a few screenies which depict the current status of effects in EAWPRO on both Russ's machine using a wrapper and my own machine without the wrapper using D3D mode. VonBeerhofen https://rabartel.home.xs4all.nl/FX06.jpg https://rabartel.home.xs4all.nl/FX07.jpg https://rabartel.home.xs4all.nl/FX08.jpg https://rabartel.home.xs4all.nl/FX09.jpg https://rabartel.home.xs4all.nl/FX00.jpg

Let me assure you that there's nothing ''buggy'' about them, but I guess that some people just lack the skill to create them as they're not easy to create and require quite a bit of time. Sure enough they're different then the flat shadows which simply don't have a perspective view. Ofcourse they're not true shadows, just as the default shadows also aren't true shadows and are lacking certain aspects we all associate with shadows. For instance 2D shadows are incapable of showing the tailfin because it has none, nor is it capable of showing a sideway view of the fuselage and a topdown view depemding on the viewangle, as opposed to the 3D shadow. They're just flat and boring, at least that's my view, and I wouldn't call them buggy for that reason, they're just one solution to add shadow to a game which is incapable of doing the real calculations we see in more modern games. The 3D shadows are another solution which I and many others feel is much more interesting and possibly can be properly animated one day with the roll or dive of airplanes showing the model at appropiate angles, something which is impossible with the 2D shadows. So that leaves the question which is more buggy? Ofcourse the shadows can easily be replaced by their 2D counterparts, which are still in the game's 3D CDF, I mean you don't have to like them just because I like them but calling them ''buggy'' seems a bit over the top. VonBeerhofen

It may be a silly question but some people just don't understand the link between AI intelligence and framerates. Let's start with a simple comparable example, imagine a truck carrying 4000 KG and the same truck carrying 40.000 KG. When both start off from the same location and drive to the same destiny, which do you think arrives there first? Ofcourse the lighter truck will arrive first and the difference in arrival time only increase with distance. It's simmilar with computer framerates, The carried weight can be compared to the graphics a coputer is rendering on screen, the distance is comparable to the power of the graphics card, i.e. the older and less capable the card the longer the road to travel, or better the slower the rendering. Now here's another comparison, When the EAW gameloop requires a longer time to be carried out, i.e when it is more bytes, the framerate will obviously drop. The difference was particularly noticable with the 1.x versions of EAW, which is why a fair ammount of people weren't interested in the 1.2 upgrade. Sure enough they missed out on a few things but the air battles were more ferocious and tougher because of higher FPS as the AI were much quicker to react and as a result more precise in aiming too. Let's have a quick look at the EXE's I have on my drive, There's for instance the first 1.28 recompiled version with 1.21MB Next are the early recompilations of the EXE with 1.22MB then there's the 1.0 and 1.1 versions which both have 1.30MB then you have the 1.2 version with 1.36MB EAWPRO with 15KB freed memory from v1.2 by optimising the code 1.21MB The EXE filesizes aren't entirely indicative of the speeds these versions can devellop, after all other processes were activated which also take a bite out of FPS but it gives you a rough idea what to expect. However most versions allow user control over the graphics by means of the EAW.INI Detail settings. Addons also can have quite an influence on FPS and what to expect can easily be determined by calculating the modified filesize totals and compare it to the original filesize totals of the stock files. If the filesize count is lower the game becomes faster, when it's higher the game slows down. Ofcourse framerate counters are simple tools to easily determine what's happening and when, for instance when a lot of action is going on, explosions, tracers, flack, clouds and groundobjects all visible, birds flying and all detail settings to high (= 2) you will get a reading which will portray the lower end of the FPS spectrum. When however hardly anything is visible, except perhaps a blue sky and a single bird the reading will display the higher end of the spectrum and you may find a huge difference in the values. You can ask yourself a question here, is it better to try and maintain overall decent to good FPS throughout, or is it better to have high FPS with hardly anything visible and much lower FPS with a lot going on? I know where I want to be but do you? VonBeerhofen

ALL eaw 3D models are flawed, except, for a few simple shapes and those which came from other Microprose games and remained unaltered. Now this statement is NOT an attack on anyone's endeavors in 3D modelling, it's just a simple fact. All modified planes are stuck together with spit and string, as Moggy so aptly described in another forum. In 18 years of flying EAW I haven't encountered one single 3D model which wasn't stuck together like that. As a result of lack of knowledge on the subject of calculating and understanding the rendering sequence, nearly all models show bits and pieces randomly switching on/off at certain viewing angles or distances or 3D parts being visible when none should be visible. Perhaps I'm spoiled but this fact has always annoyed me, simmilar to the viewdistance switch which happens between lores and hires model when aproaching an object. I find it distracting and it takes away much of the immersion EAW provides. For this reason I've visited many websites dealing with the subject and read whatever I could find on the topic. It's taken me 10+ years to understand, plus I spend a lot of time dabbling with other commercial 3D packages used for other flightsims but most of these are not comparable to how EAW deals with a 3D world. I had to revert to a more hands on approach using the tools made available by some more knowledgable people then me. I learned that there are no shortcuts and very stringent rules for creating 3D models and that not a single 3D model will allow the same approach in order to get it to work. However, more important was that after very slow progress I verified that Gurney's R/S calculator is working 100%, as long as you stick to the rules of 3DZ modelling. This again means that there is no need for flawed 3D models, they can all be fixed provided that someone will spend enough time on figuring out why some polygons cause the calculator to screw up. It is a painstaking process which requires a lot of ingame testing, but there's always a solution even though the solution to the problem is different for each model. Often there are multiple solutions, which is where decisions have to be taken as to which one is the best. Now the sad part is that a solution may remain illusive for months or even years and it's useless to stare yourself blind on it, it's like finding the right pieces of a puzzle or like Rubic's cube, where a single polygon change can cause a cascade of errors in the model which will always cause Gurney's R/S calculator to get stuck. I want to reitterate, that the calculator is fine and when it locks up there's something not right in the model. When it's not right it can cause the game to crash, which is obviously another indicator that it's not right. I can't teach people how to solve such issues, it would take too much of my time, only trial and error will bring this understanding. I also hope you will understand that fixing every flawed 3D model from the past, that's nearly all of them, is a herculean task which I'm not going to take on. It's more fun to create your own models, as you're in charge of what you're doing when you build it, then it is trying to spot where others have gone wrong in their endeavours and you can only use the current tools available for doing so. On a personal level there are some simple good working models which are flawless because of their simple design, but everything flawed is total failure in my eyes and proof of not understanding of how it works. I know it's a harsh judgement but in doing things right there simply is no compromise. Even I do have models I have been unable to fix up till now, which started 10 years ago. They just didn't make it because I can't see what's wrong, and untill I find the solution it stays under the heade of total failure and will not see release untill it's been fixed. I know there is always a solution so I come back to it to see if I can solve it that time. Any other approach is useless, wether you can see the model in game or not. I hope some people will rise to the challenge and have the determination required to truely become a 3DZ modeller, it's about not giving up or trying to take shortcuts, no matter how much time it takes. Start small and work your way up, study the Microprose models as some of the answers are in there. Its the only advice I can give. VonBeerhofen