I'm cool OG no offense taken, the time needed for new creations is an interesting topic which I think may interest a lot of people, especially since we're not doing things the same way and have different objectives.

I remember now, flat polygons at regular distances in a single 3DZ. It still needs manual placement on all 150 airfields and reduces the edits to some 500, not even mentioning the ones in other addons. I know Rotton is pretty skilled in placing such things, but after placing 5 or 6 of those I'm pretty sure he'd like to move on to something else. Haven't heard any further news about them since then, are things progressing well or have you stopped after doing one for proof of concept, like the searchlights?

Not particularly a timesaver and with only 256 nodes available in each 3DZ only 64 square lights go into one strip. So it will still need some 10 or more for each field, a massive job, even if you have an airfield shape tool to trace it's outlines and place the lights correctly. I think my advice still stands but if you think it's good enough then it's probably good enough for others too. There is however a huge advantage with the airfields in EAWPRO, inspite of it's hundreds of lights per airfield, they're much lighter to render as each field doesn't even come close to the filesize of a 64 polygon 3DZ using all 256 nodes.

These airfields can be copied and pasted into ANY EAWPRO addon and require no further work, unless people want to create new shapes or new textures for them. By now I've created around 50 new ones, using templates from real existing airfields in WWII, 1/2 of which were incorporated into PTIV, with appropiate runway textures ofcourse. Creating them is a fun relaxing hobby and not really hard. BTW, I liked Pobs's and Col. Gibbons versions too but they were just too expensive in rendering time, just like my first highly detailed 64 tile airfield of Pearl Harbor, which was never released. It may still find a use though in the Pearl Harbor addon, which only uses a couple of airfields anyway.

Simple lightweight solutions are still the best I think.

VonBeerhofen

Eh, no.

Placing multiples of ANY TMOD is a snap using Jel's excellent target editor. Wouldn't take 30 seconds to add as many flares as the exec would accept at any one target.

In fact, with the target editor you could place an unused target right on top of an airfield and then add 255 flares to that target.

I'm very much aware of Jelly's target editor but it doesn't display airfield outlines. Placing the centre runways only will do I guess. Are you sure the tardata.dat can hold that many objects per target location and in it's entirety? Still seems an expensive way in terms of sacrificing valuable targets for a few runway lights. I seem to recall there's a definate limit on nearly everything in EAW, planes, bullets, bridges, airfields, explosions, smokestacks and so on. But as I said, you'd probably only need some 10 per airfield to get a reasonable effect, but that's just one and only 149 to go for one single addon. If it's that easy and fast I'll keep an eye open for any pictures of your efforts, Good luck with it and have fun!

VonBeerhofen

You should look at some of my work in the ETO2015 target set before making one of your "fake news" declarations. OK, you aren’t getting the message. I just cautioned everyone (including you) about starting the ball rolling. If you have a problem with what someone says don’t respond in kind. Let me know and I’ll make the call. If you take it upon yourself to respond you lose any high ground you may have had.

This is a warning to you. Next time it won’t be a warning.

You see, I worked out a fairly simple way to see the outlines of the various airfield models. So I have all sorts of ground objects lines up perfectly around the edges of the airfields. Hangars perfectly aligned with tarmacs, airplanes lined up next to runways, fuel trucks running down the perimeter roads and loads of other stuff.

You'll just have to take my word for the ease of adding TMODs because I have no plans to add flares. I don't like the effect but I'd be happy to coach anyone who would like to get involved in such a project.

Using the term "fake news"seems a bit over the top to me, As I said don’t respond in kind. Let me know and I’ll be the referee unless you claim that the target editor in fact can show the outlines of airfields. I can't take into consideration the personal methods you have deviced and such was never part of the discussion. I have portrayed the issues fair and honoustly but I'm glad that inspite of the ease you''ll not be incorporating the runway lights, in which case they will remain only obtainable in EAWPRO. When people don't want them, I can easily design a set which doesn't have them, they switch off at distance anyway.

VonBeerhofen

Why can't you ladies just play nice and advance or girl,,Your differences are killing our hobby and serve no purpose Grow up and leave the egos behind..guess I'll get banned now

No, but don’t stoke the fires. Notify me and let me referee. What you did was no help in deescalating the issue. You had a good point to make, but used a sledgehammer.

For the record, you said "I'm very much aware of Jelly's target editor but it doesn't display airfield outlines. Placing the centre runways only will do I guess."

My response was "I worked out a fairly simple way to see the outlines of the various airfield models. So I have all sorts of ground objects lines up perfectly around the edges of the airfields."

So you introduced the issue into the conversation and now that I've pointed out that your comment was "fake news" you want to declare that it's not part of the discussion.

Once again we end up in a dumpster fire because you have not "portrayed the issues fair and honoustly".

If you look for offense you can either find it or create it. Don’t let the past overwhelm the present. I’m not judging on the past. You could have made a clear factual statement without dragging it down in the gutter. And that’s what you did.

I'd be happy to, Russ, but once again Jel and I are forced to refute incorrect declarations.

How that's considered an ego thing I just do not understand. Heck I don't even see how using facts to destroy false info can even be considered inflammatory. When did we become so thin skinned that we can't stand to accept facts? Delivery, it’s in the delivery. You delivered poorly.

There is no falseness in that statement, it's a mere fact that the target editor doesn't portray the outlines of airfields and as such I draw the conlusion from that. I understand you may have designed methods to show the outlines but I've not been aware that you did. A response that you had designed such method would have sufficed, without the fake news bit, as that portrays me as a liar, which I'm not.

I repeat myself.


VonBeerhofen

Egos Ray are the assumption every modder as the right approach to what is best for EAW I respect both Mr Jellys work and VB's and have gotten tired of the sniping .but now there are two camps competing on who's version is the best approach.Get your crap together and advance our hobby..Iv'e flown both and each has it's merits it's merits and it's best to decide what we fly

Good points, but improve your delivery. Use less of a sledgehammer.

Understood OG and i will step aside and not fan the flames

No need to step aside. You had good input and valid observations. The delivery was a bit heavy handed.

Because of past grievances, slights, hard feeling, etc there is a tension here that makes things go Nova quickly. Add to that the two somewhat divergent development paths and the disagreements as to which is better and where they can/cannot overlap, coexist, or conflict creates conditions where techniques of modifying make for contentious discussions. Everyone is rightfully proud of their work and since they did it painstakingly step by step they know what they did and why. That often makes for misunderstandings of why and what can be done with each way.

Very talented men whose skills and knowledge I can’t even get started on with understanding.

I would like to take this opportunity to explain that my runway flares (which appear to have brought up the comments about the use of my target editor) are not TMods, and they are not placed by the target editor.

They appear when the 160 exe reads the special "AIRFLDxy.3DZ" files which contain flags which trigger their display during hours of darkness.

The flares themselves are small triangles placed in straight lines at the runway edges. However, the exe places a small random offset to each one so that there is a bit of an irregularity, as with "FIDO" in WW2.

Jel

So it's using a regular .3DZ with a special name, using all 256 nodes with 85 flat illuminated polygons, of which a certain number are automattically placed on top of an airfield.3dz, using the appropiate orientation of any airfield in the game? You use that 3DZ, how many times, 2 on each side of the main runway? That makes 340 lights (polygons) using 1024 nodes when only 4 of these are placed, plus the nodes and polygons in the airfield.3dz. In total it's a lot of stuff to render, plus an extra routine to make it work.

That's still not far from my previous estimation and app. 5 times heavier then the ones in EAWPRO which use even less then the stock versions and have around 10 times more lights. Not that the number of lights is important to me, but the freedom to place them and where is, as is the weight of the models in terms of FPS. The automation is a decent way to place them but still unnecessary as EAWPRO shows, as it only uses what's been there all along. Besides that the EAWPRO versions can handle any number of landing strips on an airfield, irrespective of their direction, placement and orientation and won't cost anything extra in terms of nodes or polygons.

Such things are important on any computer, but even more important on legacy machines with 32MB videocards, 256MB memory @ 200Mhz and Pentium IV's @ around 1.5 Ghz. That's what EAWPRO is all about, to gain speed where ever possible, to improve AI reactions and compensate for the loss of the 10 times heavier graphics and other extra events. It just shows that v1.60 is NOT superior in every way, as Rotton claims, and that EAWPRO has quite a number of advantages over it and is rapidly gaining ground too.

BTW, EAWPRO is nearing 50.000 changed bytes, of which app. 10.000 bytes were removed from the game loop! With that the game loop is faster then any 1.1 version, which was known for it's notoriously agressive AI, just because of the size of it's EXE. Comparing screenshots, shows more colorfull and more complex explosions, UHR skies and horizons, more realistic people running around in many more events and it has more sound effects then ANY other version and is more user friendly, because it still uses the default user interface from v1.2 which needs no extra explanations for most veteran players. It can use nearly any .3DZ model ever created for EAW in history and was made to be compattible with the early UHR plane models from Col. Gibbon, which I personally think have a tendency to screw up the game because of R/S issues and are therefore not included untill I can fix them.

Still people have a choice to use them if they like, and with a few minor adaptations the old campaigns can also be made to work. Don't be fooled by framerate counters, which may be influenced by the newer operating systems, or believe that someone can actually distinguish AI behaviour between versions in terms of offensive or defensive moves or agressiveness by playing the game a few times. Fact is that since both versions aren't exact copies the AI will simply not behave the same as there are millions of different situations where AI have millions of choices to make. Framerates depend on the gameloop length and the ammount of graphics you throw at the GPU and CPU and it must be clear to anyone that there's a huge difference between EAWPRO and v1.60. I'm not claiming superiority, as that depends on what you're looking for in the game, but I think it should be made clear to players that you won't find what EAWPRO has to offer in ANY OTHER version, except for what was copied from it.

VonBeerhofen

No it is not so we have another post based on a false assumption

Wether it's a .3DB or other file which places polygons or sprites requires nodes in 3D space. Your polygon uses 3 nodes and you place a number of those on top of an airfield, so the number of polygons you place is the ammount of lights visible and the number of nodes is the number of lights times 3. There are no other ways to portray polygons in any game, no polygons or sprites, no lights or objects. You can't make something appear without them.

Whether the polygons were incorporated in the airfield.3dz itself makes no difference on the extra weight they will have, they're still extra polygons and extra nodes. I respect you not wanting to reveal the approach you've taken but how programs and computers work is not based on assumptions but on facts, they're just sophisticated calculators.

Using flags in an airfield 3DZ will only take more extra time to read wether they're present and on or off and require more programming to create something which wasn't there from the start already. In that repect using regular .3DZ's is undoubtedly faster as it's illuminated polygons have been present since 1998. Switching these polygons on or off during day or night time requires more work and is totally unnecessary, since the illumination of polygons only happens at night already and the flags for that have always been present, as can be seen with the earliest illuminated hangars.

And with that knowledge I can safely say that it's not as lightweight as EAWPRO which required no programming at all, only a small adaptation in the airfield.3DZ's drawing and redirection of the illumination pointer from the standard .3DZ's. That difference in approach is clearly visible in the filesize of the EAW.EXE, where v1.60 uses multiple EXE's which are nearly twice as large as EAWPRO's single EXE minus 10.000 bytes. I told you assembly language is much more powerfull and efficient then any compiler.

VonBeerhofen