Que sera, sera, whatever will be, will be.

Why don't you just say what's on your mind, Mr. Jelly, instead of showing mystifying pictures which make no sense to anyone.
I'm willing to adress anyone's issues with EAWPRO, as long as the conversation remains civilised, stays away from personal attacks or abuse, and doesn't try to force me to do things differently if there's no need for that.

VonBeerhofen

Fair enough

The public release of EAWPro is far from professional. It is a dogs breakfast.
You often mention the many hours you spend on your work, and I am showing is what might have been if you had taken a bit more time to repack the CDF and FXE files to include in the order of 350 files that you left in the root folder.
That's what I did and it runs perfectly

There is also a lot of space in the root folder to test new or replacement files without overwriting existing ones.

Well I already contemplated that issue as one of the possibillities. There are several reasons for that, one is that you took it when it was in that state and as such the release was kept in the same state too.

Another reason is that the CDF's have been repacked about 100 times since the beginning of the FXEXE, it's a very timeconsuming thing to do, lends itself to errors which take the same time to fix, and it takes up a lot of drivespace to keep the files in an unpacked state so you don't have to unpack it every time it's being repacked. Besides that it's not only unfinished but was meant as a constant dynamic addon which is changing almost every week.

There is no real difference in overwriting complete .CDF's or a few files, other then that it takes longer to download and that the CDF's take much more time to recreate for just a few files, each time something changes. I know it's not easy for average pilots to keep track of these changes, after all it's not any different for me. A single file or CDF is easily overwritten but chances are that within weeks another file gets replaced, such is the nature of a dynamic approach. But players can not afford to miss a single download, since that will screw everything up since they're no longer in step with the master version.

Like in the past there will be releases which packs everything nicely into the CDF's again but when that happens the loose files aren't removed and will keep priority over what's in the CDF. A whole philosophy was constructed on the problems of switching files, the ALLFILES.BAT was created to allow users to send me their folder contents in text so I could tell em what to do when things went sauer.

It was all carefully planned with the thought in mind that EAW wouldn't use any leftover garbage as long as the file wasn't called but inspite of the ease I envisioned my players, like so many other players, regularly did things wrong or simply forgot to do it. The standard solution was to tell them to do it again, after all this system doesn't care how many times you try or how many times you do it wrong.

Ofcourse what to overwrite had to be carefully planned but even I make mistakes because I'm only human. Funnily enough, inspite of their messy gamefolders their games are working as it should be, so that part works great. Not so great is the mess it leaves behind and finding ways to get rid of that mess.

It was thought at some point that a cleanup.bat would sort things out easily, giving me remote control over someone's folder, sadly the batch file didn't work at all anymore from XP onwards. If it wasn't for what's happening inhere I might have had the energy to clean things up, because that's what I did on a regular basis, but when operating systems no longer allowed remote controll the effort became futile and the weight shifted more towards, for God's sake let's hope these poor buggers overwrite the necessary files and lets forget about all eventualities, because it's not going to work according to the carefully planned strategy.

And that's where you caught me, everyone's folder was a mess and sometimes mine is too. You see, another plan was to use my website as an online OAW, hence the alphabetic order of downloads. My pilots wouldn't know how to use it but perhaps none members might see the use of it and perhaps use it for OAW downloads but in 2007 OAW was abandoned because there were no more pilots, and the 3 new players I managed to acquire didn't care for it, so the project was abandoned. You can't teach a Csechoslovakian who's English is barely enough to communicate, who is 75 year old and has no knowledge about computers, how to use stuff like that and that goes more or less for the others too.

As I said, EAWPRO would have been regularly cleaned up if I'd have had the incentive and energy to do so, but it would change within weeks again and the problem would start all over. making complete downloads a necessity. At some point I just no longer cared and it all stopped because someone stabbed me in the back and as I later found out with my own knife.

That's where I am now, I no longer work on EAWPRO or the website and only do things which give me pleasure to do, there's no incentive or energy for anything else. I hope you understand. It's already hard enough to keep my pilots interested and if something interesting may evolve and works, some of it may trickle inhere as a few loose files which can be added to EAWPRO or OAW without having to do anything much, untill that no longer works.

You can not expect anyone to keep changing CDF's just because you like it nice and tidy so that it will allow you to make better use of it in OAW. It is a severe restriction to have to take that into account as well on top of all the problems I was already facing. It is simmilar to changing UAW v1.60 weekly and expect modders to adapt their creations so it will still work, only to suit your needs. Some of these changes have a dramatic impact on their work and may render it obsolete, draining their energy to keep going. Well at least that's what it would do to me. So no rigid rules, I can only tackle problems as they happen because I don't know what will happen, but there won't be much coming anyway, so who cares, except you.

I just dumped EAWPRO into an OAW folder of my choice, if it's loaded on top of a clean OAW it will work, for me that means OAW ready enough, but that was an unnecesary test as we both knew that that will work, well it does with my dusty version.from 2007. The last thing I'm looking for is to have to explain how to do things, like you did every week, 5 years of trying that was more then enough for me.

VonBeerhofen

Accepted.
I will not make a public release without your permission, but I would be happy make a 7-zip self installer, upload it and provide you with a private link in a PM.

Your comment about UAW1.60 is misinformed. The only major change was to the naming system for slot free planes, which came in in 2010, and in any case most modders make their planes in the old way and use the converter software if they want the slot-free version. Minor changes came in when we needed three digit numbers for TMods, but that was ages ago. The models are the same, but their names are different.

There's no need to contact me personally Mr. Jelly, I no longer host EAWPRO remember? You have to talk to Mark EAW if you want that download to be available to the community and it's up to him wether he hosts it or not.

I'm sorry if I'm misinformed, I've only been aware of what people were writing in the Zeus forum led by Col. Gibbon. It appeared to me that the entire modding community was there and I took their words for indicative of the problems everyone was complaining about. But it's gone dead since a year or so, only Mark and I use it occasionally to swap ideas and as a kind of archive of our thoughts.

Anyway, what's important to know is that certain changes can and will have a detremental effect on some people who have spend years on develloping their own views on how to make the best use of what EAW, OAW or UAW has to offer. It is why I choose to keep EAWPRO as a standalone because, even when I provide a new theatre, further devellopment can continue for that version and devellopment for the old version would halt. To me there's no use in even trying to keep multiple theatres on par, since the ammount of work would be staggering and probably kill me.

VonBeerhofen

Col G became a real PITA.
Because of the slot free naming system you cannot drop skin files into the root folder of 1.3....1.6
He was told quite clearly not to bother, but to use 1.29 and drop the files in the root folder to test them.
Once a skin was finished we could convert it for him.
Unfortunately he ignored this advice and ranted against the slot free versions at every opportunity.
There is a complete 1.29 download available, with several theatres and planesets, but he asked me to make him a private bare-bones version just for testing.
So I did, and the next thing he is offering it at MediaFire via a link in his signature.
Anyone getting it could only fly default ETO and would be blissfully unaware that they were missing out on all the stuff we had put into the 1.29 system and made available in our download.
I am saddened by his illness, and nobody can be certain whether it may have already been affecting his behaviour at the time.

Obviously multiple theatres are what we do, but it is made easier by the "Dir.set" system.
It started in the early days of 1.28 with the "CDF.set" file which listed the CDFs to use in stead of the hard coded table in the exe. It was used in the original releases of both SAW and SPAW.
Then we went to "dir.set" files for theatres which the exe reads to find the paths to the files it needs. Theatre files remain in folders referenced by the "Dir.set" file, so there is no copying/pasting/deleting process with files in the root folder.

I have an installer ready to go if Mark wants it
It is 165MB in size and needs no previous installation.
The ini file included is 1024x768, but set up for a Logitech Extreme 3DPRO joystick

I don't want your help

I was not offering help, but simply responding to what you wrote. As Mark will have read all this I have left it up to him to contact me if he wants to host it.
I do not care either way

Good, as long as people realise that EAWPRO is a WIP and a dynamic package which is bound to change often.

VonBeerhofen

Understood, but by the same token each time a major 1.28 series public release was made it included updated CDFs so that the package could run in default mode without any addons.
That is no longer a problem because we do not use CDFs, and any updated or new default files just go into the "GameData" folder.

Aha, so that's where all that stuff goes, and users can still add individual files to mess up those folders like I do, or is that right reserved for you? I mean wouldn't that lend itself for mistakes in the various folders that people may have, or is it simmilar to OAW so people better not tamper with folder contents unless they know how it works?

VonBeerhofen

There is no right reserved for the programmer. It is an open Windows based folder/ file system with no "black magic" involved.

Heck, I wouldn't know one end of a source code from another, yet I make additions and deletions to the 1.6 file system all the time. You just have to know where stuff goes.

There is no doubt that it is a different system and it takes a while to get used to it but once understood it is logical and easy to work with.

In addition, the slotless naming convention is a God send for model makers but again, you have to have an open mind and be ready to abandon old ways of doing things.

Just to clarify.
The slot free naming system meant that a heap of files in the CDFs were useless
The entire "FLT.CDF" and "Cockpits.CDF" files were useless.
All of the aircraft graphics files in the "3d.CDF" and hangar screens in the "PIC.CDF" were useless, along with a number of data files, minipics and string files in other CDFs.

So the files in the "useful" CDFs were extracted and put into "GameData". Then the useless files in it were deleted.
Simultaneously the exe was re-programmed to look into the "GameData" folder if it had not found a needed file in the root folder, or in folders referenced by the "Dir.set" file. All reference to CDF files was removed from the code.

Users of the slot free exes do not mess with the "GameData" folder. If they want to use an alternative file to the default one they can put it in the root folder, just as people can with the older systems.



Absolutely correct. A modder makes one skin using the old system, puts it in the root folder and flies the plane in the designated slot to test it. Once it is ready then he converts it to the slot free format, and it can be used in any of the 30 slots.
This is much better than having to make multiple versions of the same plane to go in different slots.

Jel

And it requires installation of VB runtimes as well I presume, and a wrapper or windower ofcourse or is that automattically done?

VonBeerhofen

Actually, I've got a different way of doing it that works well for modding the aircraft.

I identify the folder where the plane is already set up with the new naming convention.

First, of course, is to make sure that plane is listed in the planeset that has been loaded with the plane picker program.

Then I copy the whole folder for backup.

Next I begin working directly in the original folder. When I make a change I just run the game so the change can be checked.

I continue in this fashion until the model is finished.

The big advantage is that if I screw something up ( a regular thing for me when working with 3dz files ) I just go up one step, over to the backup folder copy the original file and paste to the working folder.

If I get REALLY screwed up I can delete the working folder and copy/rename the backup to start fresh.

When it's all completed I do some house keeping to remove extraneous files and I'm DONE.

But it gets better.

See, I like Col. Gibbons props as opposed to the originals so I made a library of 2,3,4 and 5 bladed props with hubs and spinners based on his design plus inside props of the same configurations.

I also made US/Brit textures with the yellow tips, German/Italian all black textures and three different Japanese prop textures, Red, Yellow and Black. Took a while but the advantage was clear.

Since every plane has the same set of 3dz names ( PLANE*.3dz) now I can drop props into a folder and I'm DONE. See, on top of the naming convention change, the props have their own texture/transparancy sets. No more connection to the TEX/TRA files where the props used to be mapped because we only had the one set of transparencies.

Additionally, since my updated models of multi-engine planes have completely independent props I did have to edit the Col's props to assign new action codes based on which engine i was attaching the prop to. Again, fairly tedious stuff........but I only had to do it a couple of times and then I can just grab the appropriate props and dump them in the new folder and I'm DONE.

Some of you might not follow what I'm trying to explain so in layman's terms................1.6 is a huge time saver which gives me more time to build more planes or go fishing.

Here's how I do it Ray,

I have multiple spinners in my 3DZ folder, with or without hubs in various shapes, since there are only a few of those. I look at the plane, search what spinner it needs and pick the right one for the planetype I'm working on. They all have proper R/S, because there isn't a spnner I have seen which doesn't, and I attach it, either as a seperate spinner in it's own standalone slot or as an incorporated part of the model (like the windmill).

Both types have their own problems but the standalone prop will always work, since it's controlled by the PSHELL. With multiple 3DZ's visible in the editor you move it to the right position with the wingview visible, it makes no difference if the wingview is a complete model or not, and you check it. It should be fine at all times if it's in it's proper slot.

Experiments have shown that you can use the P.3dz for either bombers as well as fightermodels, even with the stock planes. Ofcourse bombers need 2 to 4 props in the same slot and there are plenty of models around that you can pick. Each prop is moved into position of it's cowling and the entire model is moved to it's relative position and just like the single prop that's all you do. The R/S of the original stock planes can be used for any model, just a matter of capy/paste and running the calculator which will always spew out the proper R/S because they're simple models.

Further experiments have shown that the same prop is viewable in the cockpitview, it just needs to be moved into the right position again, it's R/S doesn't change. The P.3DZ uses it's own transparency link, there's no difference if it's a PLANESTRA or a P47DPTRA. All planes can use that method.

The problem you describe is not related to props but to the wing and or fuselage. If their design changes it will need a new R/S and that's where the problems begin. The props are always fine. When the calulater doesn't give an R/S, it's design is flawed and it will cause problems. If it's not flawed and has a proper R/S you also move the combined wing/prop into position related to the fuselage and you're done. You don't go back and forth between models, if the calculator says it's not good then there's no need for further testing because it's simply not good.

If a design is complicated, for instance when the props and wings are in the same model, the props have to be treated the way they are treated in the fighterplanes and windmill. Having both in the same model saves a lot of nodes and frees other 3DZ's to be used elsewhere. It's more timeconsuming and not easy to do either, but it can have it's advantages. Such a combined wing/prop models also only needs to be moved into it's proper location and the wing doesn't care if it uses a TRA. Still texture space have to be divided since it now has to have two parts drawn in a single texture.

I know the last method isn't what you prefer but what I'm saying is that testing is the last step after everything else is done in 3D Studio and you know it will work unless you've made a mistake. There's no need to check a flawed R/S, it needs a redesign. Mind you this is not an attack on the slot free system, I know it's fine, but there's no difference in how to do it with the slot system. If you think there is then perhaps I'm not fully grasping what you're saying.

Anyone who creates the textures as well, is wise to stick with a single design, that goes for groundobjects too, so you can simply move a texture into the game without changing the model. My designs use a single texture for 1/3, 1/4 or 1/5 th of the disc, which has as many polygons, with the hub in the corners, just outside the disc area and will show as perfectly round. Can't think of a better layout then that as it uses 99.9% of the texture. But there are other designs possible.

VonBeerhofen

Curious as to what TRA files you use for these independent props because I assumed without 1.6 you are limited to TEX/TRA, Y/YTR and Z/ZTR.

You are free to use any of those, the textures are not slotspecific. Cockpits have hardly any use for transparency but if your windows are transparent then a small spot in the texture will do the job. You do not paint cockpits like you do a house, you draw a set of materials that you'll use, as it's done in CFS2, and you repeat the use of those materials by using a few more polygons. That saves space and still allows panels to be drawn and results in a much higher resolution.

Obviously a PTRA is a posibillity too, should such meed arise but it has to be hardcoded if you want one. I'm not limited in how I will do things, the way to go depends on what I find and usually I try to stick to the originator's idea as it saves time, unless I think it's inferior to what I want to accomplish. Most of the time I'm not happy with the layout since it often leaves large gaps open in the texture that can be given a use. I've not done many planes, only the one's which were the testing ground to see what was possible.
The pilosophy is you use everything and if there's something free you give it a purpose. I've build radiosets behind the pilot into C.G.'s 109's for JG51, without the calculator, just because there was room for it. I don't know if the model was publicised or shared. It was a challenge to get it to work but inspite of it's beautifull skin by Rauch is nolonger something I'd use.

It would take too much time to clean up these models and recalculate the R/S and as with nearly all models you're bound to run into hidden obstacles which need fixing first. The Col. had a tendency to just try and stick a polygon behind a problematic one and fiddle around to make it work. A lot of people used that method if they couldn't get a proper R/S and the result can sometimes be quite messy. It's easier to rebuild things like that from the ground up and stay in control of what you're doing, probably saves time too. A clean model allows others to reuse it's parts and for the R/S means it's 1/2 the job done.

VonBeerhofen