VonBeerhofen

Here's an idea, I'll take the shadows, waves and seaweed out of the CDF and put them into the gamefolder again. I'll add a list of the 3D slots and write an instruction on how to erase them and how to add new models. I think everyone already knows but it's easy enough for me to do. That way people can experiment as much as they like (or not) and have fun again building their own EAWPRO world and be happy. It's a bit of a shame really because after your initial complaint of a messed up folder and finally cleaning it all up, it's going to be a bit of a mess again but maybe some people will find it easier this way after all. VonBeerhofen

Yes it's true, I have better stuff then what you portray, better waves, better trees and forrest, runways, ground objects etc. etc. but I've not heard anyone complain about models which are in nearly every addon I've seen and which anyone can replace with what ever is available. The procedure is quite simple, if you want to replace the pillboxes you download a .ZIP with for instance Per Von Oben's version and you extract it into the folder and voila. Per has the Supertrees mod on his website, which works exactly the same. There's a huge range of objects available, to add them to EAWPRO would only unnecessarily increase the package and eat my time which I need for other things. I only added a few things because there were no objects in EAW for the new slots, and it was done in the same way as described above and anyone can do it. These objects came from various sources, when not there EAWPRO may not work properly. It's been done like that for ages. Whatever I have is not important, as I explained several times before, the good stuff is for the Final Cut addon and other addons I'm working on since I do not want to use the same things that everyone else uses. The Basic version can be dressed up just like we did with EAW in the past and as you're doing with v1.60 VonBeerhofen

It's perhaps not an important detail but in EAWPRO you can jump from plane to plane and you will notice the shadows when you're 3rd or 4th on the runway or all the way at the back of the group. They're also noticable when you're diving towards ground targets or low flying enemy planes. From higher up they're practically indistinguishable from the stock shadows. Not that I care how they look or which ones are used, but they're just not ''Buggy''. VonBeerhofen

EAWPRO has no problems with transparent shadows, in fact the 3D shadows can have both transparent and none transparent parts. That way the cockpit glass can be portrayed tranparent while the fuselage is none transparent. However those who prefer transparent or none transparent 2D shadows have a choice. Even groundobjects can have transparent shadows in EAWPRO. VonBeerhofen

The only place where the stock shadows are realistic are on the equator at exactly 12 noon, all other times and locations they're wrong in my opinion. Still, there's no reason to call either ''buggy'' if you'd leave the opinion to the reader. 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

I've talked it over with the Launchpad members and the only person who I think has an interest would be Russ Watson, since his machine is way more advanced then ours. He would gladly like to see a hires planepack to test out and there may be others who have an interest too. His current framerate with EAWPRO and the Windower program is between 55 and 60 in all situations, with heavy activity and low to the ground with all settings high. 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

You or anyone else are welcome to undertake any tests you can think of in order to verify the accuracy of my claims. I've been doing them for around 18 years in on- and offline games and these tests are not likely to stop, since only the best experience is good enough for the Launchpad pilots. Good framerate is very important in our games. VonBeerhofen

I didn't say you're in doubt either but ''when you're in doubt''. Science is not computing or vice versa. Computing is nothing more then playing with a complicated calculator in which 2 + 2 is still 4 but the resulting value can be interpreted in any way by other calculations when they encounter that specific value, but no matter what you do to the value of the result is always predictable. I've done a lot of testing with the AI routines when I improved them, when I understand what I'm doing the resulting change will be known even before testing it in the game and I will know what to look for. In C++ things are just as predictable, when the AI routine states that it will check the loop timer untill it reaches a certain value and then carries out the routine, then there's no question that that's what it will do. No science is needed to know, just knowledge about programming. When players are not aware of what to look for when it comes to AI skill then all I can do is point out what the indicators are and how to test it. No science is needed for that either, observation is enough. When you can fly around with 16 enemies around you and you need not even look over your shoulder to kill each one, one at the time, or when you're in that same situation and you're getting hammered from all sides then it's pretty clear which AI are the smarter ones. Let's face it, AI just aren't getting any smarter or more accurate when framerates go down nor will it lead to improvements in the accuracy of human pilots. VonBeerhofen

Current Launchpad members have any aspiration to join any forum, the only member available would be Russ Watson but I doubt wether he has any interest in the subject. His main interest is more directed to playing a stable game of which he can understand the workings, hence he choose EAWPRO. When you're in doubt of the above facts why don't you ask Sydbod or Brit 44'Aldo, they seemed pretty knowledgable on the subject of computing, any programmer can verify the above and most players will understand how it works. Wether they can measure the difference or not depends on their awareness of their kill ratio going down. In our online games the kill ratio of all players is permanently visible for all and there's definately been a drop. VonBeerhofen

Well, the easy answer is, because that's what the source code says but I guess that's not a satisfactory answer for you. Let's look at it from another angle. What do you think causes choppyness in games. Choppyness is a welknown computer phenominum in games which is directly related to framerates. When framerates are low the game jumps several pixels at the time by skipping the pixels in between. This means that your bullet aim also can't cover those pixels, but also that the game will use larger steps for displaying the objects in the EAW world, trying to maintain a reasonable feel of the speed inherent to airplanes flying at 250+ Km/h when updating the EAW world. Simmilarly, any calculation which tries to predict an enemy's position becomes less accurate when it's extra polating the previous postions where the plane has been. Those temporary stored locations are wider apart because the loop has to wait untill it's that routine's time to execute. The gameloop attributes a timer to nearly every action in the game, to make sure that inspite of low FPS all the routines get sufficient time to fully execute but also to keep reasobale behaviour between different machines when it's a network game. This timer thus divides the available CPU and GPU power to each routine. It's not hard to imagine that when there is more time for each routine everything will run smoother because each routine can now execute multiple times in the time available to perform the loop, in other words, the entire loop executes more times in real time. The code also specifies that when the loop executes over 60 times per second a switch will invoke AI to start using human flightmodels. So you see, when the AI routine executes more times, the more often there's time to make decisions and check the situation more often as to the decision to make. Hence they become more dangerous and more precise. This is true for all games which use artificial intelligence in their design but the used algorythms aren't always the same as there are more ways to skin a cat, but essentially this is how it works in EAW. Nothing in CPU and GPU power is anecdotal, when one game shows twice the framerate then another game on the same computer, you can expect the same on whatever other computer, no matter what hardware, wrapper or OS is in use. Deviations from this general rule can be attributed to code which is better adapted to use certain versions of DirectX or code could be written to make better use of certain GPU's. The used programming language.is also of influence, C++ is notoriously slow when compared to code written in a macro assembler. The code I write is getting further away from the C++ compiled code, as the changes are directly written in assembly and not using a compiler to generate code which usually is highly repetitive in it's macros. It's these repetitions I have removed from the code, a programmer may understand that you do not need to specify the same variable and redeclare it when it's value still resides in memory, but that's exacctly what the C++ compiler does. The same variable is often declared 100 times in a single routine where one time is more then enough. When cleaned up in assembly the routine can shrink some 50% without changing what it's doing. There are programs which can do this too, but they're very expensive. Since they're based on algorythms it may not always do the job properly, only a human being can really understand what the code is doing The solution for optimisation is always different for each individual routine and requires full understanding to get the most out of it. The freed up space is then used to add new code which usually doesn't require much room in assembly language. VonBeerhofen

Complete planepacks including flightmodels may be interesting to some as an addon for EAWPRO and you're welcome to create them and publicise your work. Tests in the Launchpad has shown that with the current groundobjects and stock planes framerates are decent, but with 256MB memory on all our machines, except Russ Watson's, the entire addon should not exceed 50MB and that's where we are now. The group feels they do not want to enter into a race for the latest technological improvements in computers, our rigs do the job and that's all we need. Besides that none of them wants to learn a new operating system, especially not those who're in the final stage of their lives. Besides this there's the hassle for the players who've already expressed they're totally happy with what they have and adding plane packs, no matter how simple you make it, is bound to cause severe problems with our oldest player, partially because he's 76 I believe, but also because he doesn't understand much of computers and addon, and his English is terrible (Sorry FranK). The only thing I'm currently considering is to create one final FXEXE, which, like previously, can be added to any 1.2 addon and upgrade it to EAWPRO standards without having to make further changes. I just can't say if I can make it work, time will tell. I realise that people may want to change the stock aircraft and they're welcome to give it a try, it's not any different then it was in v1.2 and personally I've done it many times. Still it does require some extra knowledge and that knowledge is disappearing fast. Besides that there aren't many helpers like in the past and although I'm gladly willing to help it shouldn't turn into a dayjob of creating personal addons. If people want to mess with things they should learn the ropes, just like I had to. Whatever is thrown into EAWPRO may make it graphically better, just like what the Final Cut already is, but will not improve AI behaviour when the combined files exceed the combined size of embedded files in the CDF's. I can't prevent tampering with EAWPRO or the Final Cut, but people must understand that neither fully works as v1.2, if you want to do it right you'll need to understand the differences. As such you may find that some of your planes will need extra work if you want to incorporate them into EAWPRO. Such changes relate to line objects and gear(well) codes, amongst other thing. Also, the code for flaps isn't the same as Col. Gibbon's code. Quite a few animation codes were added to EAWPRO which may conflict with the one's you use. VonBeerhofen

Agreed, it IS a flightsim, and the better the AI are the more realistic the fights, which is why EAWPRO keeps the polygon and nodecount as low as possible in it's models and has a drastically shortened gameloop inspite of it's many enhancemets. The rule of thumb is that the faster the gameloop and framerate the smarter the AI, and this is only possible because the models are not flawed. A selection of 300+ planes doesn't really make much difference though when it comes to exciting fights, nor do 300+ flightmodels. People can use any plane they like in EAWPRO or any flightmodel created for v1.2 but it won't lead to more ballanced fights or more interesting ones then what the stock game provides, especially not when these planes aren't matched against each other. It's not how many objects I can provide or how many planes you can, or how many of each have been created in the past. It's about allowing people to have fun with EAW and the freedom to select what they like. In that EAWPRO can provide a new experience which is different from anything else previously created, in the exact same way as campaigns used to entertain pilots. EAWPRO isn't like 1.60 and doesn't pretend to be, it's much closer to the original game and is meant to be used simmilarly, It's user interface is as people remember from the 1.2 version but with many extras, but when they get bored with it, or don't likeit, just as may happen with any game then you're free to erase it. EAW has held my interest for over 18 years and I hope EAWPRO will capture people's interest for another 18 years, I hope the same goes for v1.60. It's getting a bit off topic now, I'm just saying that the models can work flawlessly if sufficient time and energy is spend on them and it could be the next step in keeping EAW alive, well that's what I strive for. VonBeerhofen

In another forum I checked a fair ammount of your planes randomly choosen Rotton, the results of this are in that forum, but it won't hurt to make the same statement as I made there, each one tested was flawed, some were seriously flawed, others less so but still flawed. I understand your German saying, it's principally saying that you find em good enough, but that doesn't refute my statement. As I wrote for me personally only perfect is good enough. Your welcome to disagree with me and you're entitled to your opinion but you won't change mine. Improvement to EAW comes with wanting to achieve perfection, if that incentive is missing then things aren't any different then before 2003. Surely you're treating your skins simmilarly, as everyone who has tried to build these models, making them as good as you possibly can. People who've build campaigns also strived for perfection, placing the right objects, figuring out frontlines, drawing maps, reticules etc. I'm not telling you to achieve that perfection, that's up to you. I however am striving for such perfection because I want to do things right, so I learned how to do it. I bet even Moggy is striving for perfection for his carrier, wether he achieves it or not depends on the determination he has to reach that goal. When he achieves it I'm sure it will be very rewarding to him as there's no better feeling then solving a model's R/S and get a flawless model VonBeerhofen

Hey Stratos, long time no see eh? Good to see you're still up and about. Always nice to see some acquintances from the past, makes one feel less alone. VonBeerhofen

Mark, EAW will use Bilinear and Anisotropic filering, mipmapping and a few other things I've never heard of for both Glide and D3D, depending on finding the capabillities for it in the hardware. These features are again linked with poly types and texture types, which the hardware must also be capable of doing if the above features are to be used. Effectively both the polygons and textures are under control of modders, so these features can be turned off by using polygontypes or textures which will not trigger these features. Obviously in software mode none of it will work and it's also not in anyone's interest to force the game to do a lower level graphics mode then what the hardware is capable of. I've played with some of these features to try and force it to turn on, if my card couldn't do it. Bilinear filtering only switched off thin lines in the 3D models as well as all single line polys in the structures when you'd get close to the object, the information simply vanished. So I guess my card can't do it. I think my gForce FX5500 could do it but I can't say if it would do the same thing by forcing the polygon type which was said not to use these features. I removed the forced entry a few days ago as it seemed useless in that the game will use different types of polygons if the hardware can do it. The switch to these polygon types is automatic so if my card can do it forcing it for polygons which aren't meant to do it is useless. I couldn't find any evidence of post processing features, but I recall my FX5500 could be switched to force mipmapping, and I guess that goes for all other features that card could do. I've played around with most settings but in the end just opted for good quality and speed. Whatever features the game has build in is not going to evolve with my knowledge, I rely on the features modern videocards are capable of, if it can do post trilinear filtering, great, when it can't, too bad. I recall I could set tripple buffering which doubled my poor FPS, having an 8 times AGP card in a 4 times AGP slot. Without it I wouldn't have been able to play the game, so that was great but the effect of the switch was unknown on forehand. People just will have to experiment with ingame settings and videocard settings to find the best results. For me that's where my interest faded, experiments didn't have any advantageous effect and it was already dangerous to do those experiments in the first place, I may even have destroyed my videocard with it. So I definately am not going to tamper any further with stuff I have no idea on how it's programmed, I stick to what I know/understand and have done for 35 years. Searching for this stuff is a waste of time, I just wait untill I find something I understand and then start work on it, it's much more productive and perhaps at a later stage things will become clearer so I can try with less of a gamble. A little bit of risk is always involved but I intend to keep it to a minimum. If this or my other computer fails I'm out of business for good. VonBeerhofen

What's important to understand Mark, is that the Source Code will remain in the hands of those who have no clue on how to tackle these issues other then the way it's currently being done. As for the .DLL, updating it is useless when no additional routines are programmed to call on the extra entries. Simmilarly previous efforts had no effect whatsoever but the file got bigger and being bigger means that it takes more time to link the entries with the hardware in use. I've tried all available versions for longer periods of time and didn't notice any difference. You can implement vertex graphics to the .DLL but you'll have to write a routine to make use of it. The smallest .DLL was incorporated in the code, it's smaller then the released version if I remember correctly, but it worked just as good on my machines and I haven't received any negative feedback from players about the other versions I may have incorporated at times to see if others would have a problem with them. A change to the .DLL is ineffective untill certain things in the game routines are changed, this means that even when the problem is one or more entries in the .DLL, changing the .DLL alone will not solve the problem. The fact that some people tried nonetheless is only indicative of the amount of knowledge people had on the subject in those days. VonBeerhofen

I've done some more tests with PicPac, the converter for PCX files (amongst others) but nothing came out usefull. Tried 8 and 16 bit screens, think I've done that before on another videocard, and tried the various available switches to see what would happen. Anything other then the default -8 or -p switch resulted in a black screen but the game ran and when I blindly hit a menu item the game progressed. Exiting out again the main screen became visible but with weird desertlike palette colors, shown in a screenshot I took (you can view the palette in that shot as it's in 8 bit). There's a -raw option and two bitmapped switches in the GUI that someone wrote, the -raw produced an empty .PIC and the bitmpped switches produced the still operational black screen. I didn't have my notes as they were still on my broken WinME machine but according to the GUI PicPac can handle various picture formats, including .GIF and it makes me wonder if those can be packed and work the same as a .PCX. An 8 bit .GIF is app. 30 - 40% smaller then an 8 bit PCX and would safe a lot of space on my computer. Sadly I can't start converting 1000ds of files but if that works I might start using it instead. Furthermore output can be clipped to a fixed size but I have no idea how to set it in a .BAT, I tried a few things but got no result. The good news however is that I got my WinME drive out and hooked up to my docking station and successfully transferred the code, my assembly translations, my notes and lots of other goodies, so I'm back in business, horray! The search continues, VonBeerhofen

I do support it and I wish I could figure out how to make it work. I've been led to believe that the solution was in the larger sized .BMP screens, it just needs to be something that all modern videocards and monitors can work with. If .BMP isn't doing it then I don't know what will. All I can do is keep experimenting and hope for the best. It may not be feasable to change it for EAWPRO at the moment but if it can be fixed for 1.60 then I'm happy for Jelly & Co and the EAW community. Sadly I still can't do much here, perhaps when winter comes. I've not had any such issues, it needs a computer with the screen problem and I don't have that problem, neither do the Launchpad pilots. It's just why I'm spending very little time on it. VonBeerhofen

Mark, I'm afraid the code isn't open source which is why it can not be shared. That only leaves programmers to share their knowledge with the people who have copies and have been working on improvements. Since EAWPRO and v1.60 are already actively competing there's no real chance that any hardware programmer would share his time to teach others how to change/upgrade it the way you would want. You can't work on the code if you don't have a full copy of it, especially not when it comes to understanding which hardware features have been used. I would really like to see these improvements in EAW but my personal view is that I do not want it to be turned into something entirely different. EAW has stolen my heart right from the start and I would even still have played it without v1.60 or EAWPRO. If the result would be that only small theatres can be played, like I've seen in many other much more graphically enhanced games, then for me it's no longer EAW. Don't forget that this game can have up to 256 planes fighting eachother with you or me in one of em and that in a massive theatre of entire Europe ,or whatever other continent has been created for it. I'd rather see even more planes in an even larger theatre then seeing a graphical enhancement take place which will probably only limit such furballs. I agree that it's cumbersome sometimes to get the game to work and with decent FPS too, but it can be done. To turn this game into an equal of a modern flightsim will take years, even with a group of dedicated people. It's too massive and there's so incredibly much to be done to create even the smallest improvements. FAW for v1.2 took Per roughly 5 years to build and he nearly gave up before he finished it. Imagine having to create all new file formats to take advantage of modern hardware and then adapt everything that has been created up till now. What has been accomplished has taken the codegroup and me 13 years. I think only a commercially interested owner may have the resources to do it, with professionals who know what they're doing, not a bunch of hobbyists like us. No matter how much we would like to help, it would mean the end of a hobby as I don't think anything we create would be able to compete. It's not that it would stop me from doing what I do, I'm too old to do anything else and I will still play EAW when they put me into a home for the elderly and work further on it, after all every person should have a hobby and this is mine. VonBeerhofen

I think that the downloads aren't meant for jelly's latest versions but rather for a 1.29 version instead. These models can be incorporated into EAWPRO as well but they lack the appropiate theatre. VonBeerhofen

EAW is still going strong online at the EAW Launchpad inspite of being a bit low on active pilots. The FXEXE (minimal requirements 800MHz PIV + 32 MB Video) and it's addons have been further devellopped and can be viewed here (picture index list): http://rabartel.home.xs4all.nl/test/Gallery/image/ This is the latest screenshot which will weekly be updated for those who may still have an interest in the game. Our group is still flying online dayly and our chatroom (membership not required) is monitored most of the time incase people need some advice or just like to chat about flight sims and everything related. You can find us here when we're not asleep, flying, or otherwise engaged: http://www.chatzy.com/251310437564 A bit of patience may be required in order to meet one of our regulars, there's just not many around nowadays. Hope to see you over the Channel some day, =S!= VonBeerhofen http://www.europeanairwar.net/