Gents,

Perhaps a long post but bear with me if you can;

Only personal comments, but perhaps you could give consideration and post your personal thoughts..

I am looking at this as a long term project, the end results are largely unknown, but the immediate goal, that of producing a flyable simulation, is, and has been stated by many, is of prime importance. Once that is attained, individuals may carry development on within their area of interest, but until that has been attained to some degree, all further development is moot. Experiments here have indicated, that major changes to aircraft specs or flight abilities will necessarily throw off all prescripted missions and campaigns. Bottom line then, we need standardize as quickly as feasable.

If I could make one observation on group dynamics; (dont bother to flame, I make no critisicm, just general observation based on experience)

What has been stated by Mitch and others is correct. One generalized .ini file must be used as the basis for development. There is absolutely no value in people putting forward hex code alterations without having some standard by which to evaluate the changes. We need all start from the same ground zero. It matters not what that basis is, so long as developers agree that, that will be the basis on which development will use as the median.

Should someone put forward a desirable change based on another .ini, there is no guarantee that it will pertain to other versions, therefore, in order to eliminate time expended on work that may need to be ammended later, it is desirable that we agree up front on a basis on which to start serious work.

A proposal that I would put forward for development will certainly seem conservative by some, but I think from experience in real world as well as simulation experience, would be as follows;

1. That an .ini file be accepted as the basis for all development work.

2. Developers agree that work concieved that is not based on the agreed .ini will be considered, but only after conversion to the agreed upon median and proven by that developer. The bulk of testing must not be in fault finding when off the mainstream.

3. That progress be co-ordinated through an individual capable of devoting some little time to assigning and tracking development numbers so that versions of the .ini file can be kept strait and approved as necessary.

What I am inferring is that someone may make a change that can be promulgated using a version number through the co-ordination person. After a couple of days testing, it can be approved and issued a formal version number. Once integrated into the current .ini file number, this would then become the official version number for further development. At that time, everyone can then update their .ini file so that further development can continue.

You can see then, that with a more positive control, things can begin to move forward in a concerted effort rather than a hit and miss affair as is the current state.

My personal experience in military/fisheries/marine fields I think bears this concept out. In order to produce results with the resources at hand ,my personal feeling is that we need focus those resources as best we can.

That being said, the co-ordination role cannot be performed by myself due to real world committments that would be unfair to the group if concept is accepted. Not wanting to put you Gambler on the spot, but you have somewhat gone front and center already, with a little help, can you or another volunteer to focus the development effort?

Would be willing to assist as best I can but someone able to make decision and implement in timely fashion is really required.

Dont mean to tread on any toes, and only my personal impressions, but if things need move forward in a timely fashion, we need someone out front and some testing in timely fashion.

Could I suggest that we not disregard work already done. Begin with the .ini "vanilla" version and enable all ac. Pass file around. Test and once given go ahead that we can fly additional ac, authorize, developers enable new file as the basis for development and then on to next stage.

regards to all,

dave
halifax, canada

I agree wholeheartedly with you. And I am considering this as a long term project.

There has to be a baseline that we use to evaluate any/all changes. And a central starting point. That is paramount to any/all changes, mods and enhancements that are made.

Suggestion: Why don't we post an admin.ini file with all aircraft flyable as Dave has suggested that people have available for a starting point? And strongly suggest that any changes that are made be accompanied by documentation explaining the method/purpose? While I know that this will take a little longer to accomplish, it will greatly help in the standardization of a common admin.ini file for ALL to use .

I myself am open to any and all ideas in improving USAF.

Gambler

Well, preaching to the already converted. Fully agree on all points. Further opinions invited.

regards,

Am reloading for complete clean install. Will e mail the default .ini to the address on your web page for you to have a look at. It is important to know if changes are made in the international version for future reference.

regards

once again then, have you allready tried the p3d plug in i send to you!

what about it?

groet,

Now...

Hiya folks, I'm reading this at work at a not-so-good time, so I'll make this brief.

During my work I've made some notes regarding the possible standartization of the "Admin.ini" file. Unfortunately they're at home, and I'll be there in a matter of 5-10 hours.

Basically, I agree that there can't be a too-rigid framework that restricts people because then there'll be a wild hopping between different personal modifications (that's what's happening now) that will only confuse players and make mission-creation a very heavy burdon.

This means that theoretically only the original .ini file should serve as the basis for DEVGRU mods (or any other organized effort).

However!

This original file from Pixel contains errors which I've documented thoroughly. All of those which are agreed-upon should be fixed first on the original file, and this new file should in my opinion serve as the basis for future work - according to the guidelines specified above by stdfmar.

I'm terribly sorry for not being really available as much as I wanted to be for this project in the past couple of weeks, but I'll do my best to wrap up with my "vanilla" this weekend and publish it.

I'm not expecting any wows or applause for the file itself - this is just a poorly-written implementation of my suggestions for the wide-scope 3rd-party development of USAF. For me, one of the most important things is the README file which specifies all the proposed basic developer guidelines, all the info on exactly what was changed in the current version, past versions, etc, (up to the game's original files), and how.
(as well as future plans, allocation of resources, anmd what-have-you).

Again, I'll do my best to finish this in the weekend.

Arnold:
I have many Erros with this Plugin,
I have Read this is a Plugin for "Descent".
I can nothing p3d import.
When i make a cube and export it as P3D file,
and load it on the UME i have many problems.

Today i will download the IAF Demo to look the filestructure.
I hope i can import a I.A.F Plane in U.S.A.F.
Have anyone speek or E-mailed with the Boys of Pixel Multimedia ?

2000 gmt
Still trying to get that .ini file across, having major difficulty getting the sucker out.

regards,

I have considered this idea before; I even went as far as looking at other .ini files to play around with, to make some sort of unified admin.ini.

But i failed, cos i suck.

However, here is the gist of what I was trying to do:

Import IAF planes and texture (I almost got this to work.)

Create extra entries for the F-4E, and MiG-29, to make flyable Luftwaffe planes (you ARE defending Germany in one of the campaigns).

Somehow get the Mirage III shape from IAF, and make it into a Mirage 2000 for USAF. (you'd have to cheat for the Cockpit, though).

I wanted to (it did work, if memory serves) make a J-11 entry... to create another Su-27, with a PLA-AF camo on it.

The idea was to use the Vietnam map to make a NATO vs China campaign, set in Vietnam, in the near future.

Gavin

How did you manage to use the aircraft models from IAF? They are all in .X format (some sort of DirectX format I think), which is not P3D.