Addon Serial Database Idea

[Spinor]

I think there are some issues that are being confused here. bnÂ's suggestion is only concerned with retrieving addons and other resources on which a mission depends on as easily and reliably as possible. Tagging and reviewing are both concerned with the quality of a mission, addon, etc. and are a different matter and should be separated. This is not only about mission makers being too lazy to include links, its also about links in old missions becoming obsolete, etc.

The optimum would be if BIS would support such a unique addon serial number in AA and subsequent games, i.e.
- The serial number is contained within the addon/mission/etc. file along with serial numbers of all dependencies.
- When starting the mission, AA tries to automatically download the missing dependencies.

The next best thing is separate application that does the downloading as suggested by tug2000, here: http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=8701147ae3e77362af87406e03249ffb;act=ST;f=62;t=50038;&#top

Whatever solution, I would find a central database if not file server (or server mirrors) to be desirable to ensure retrival of a resource. Island solutions via community sites will always result in holes where a given addon can be found at site A but not site B.

As an analogy, this is how its done in the scientific community (physics):
1. Publications can be uploaded at a central server (actually multiple servers, but all are mirrored, e.g. www.arxiv.org), and you get a unique ID for it. This number has become the standard way for references and citations.
There is no quality control for uploading at this server, everybody can upload, only formal/technical editing such as checking file consistency, and removing fake stuff.
2. For quality assurance, you can send your publication to one of a series of journal, where your work is reviewed by one or more referees. If found suitable, your work is published in that journal. This is where all the funny stuff happens, e.g. one journal is more 'elitist' than the other and harder to get your publication through...if you fail, you can send it to a less prestigious journal, etc.
Reviewer can also demand changes before the journal publishes the work.

Applying this idea to the AA+ community (for OFP, I think all this discussion is too late):
1. The big community sites agree to host mirrors of a central mission/addon database where anybody can easily upload resources.
2. Addons/Missions can be sent to community sites such as OFPEC for reviewing. Each community site can apply its own rules/requirements such as on variable tagging or quality. Make your rules strict, you will have few but high quality addons and missions. If a mission/addon does not reach the required quality level, reject it. I would even be inclined to suggest to get rid of the rating system: if you have enough of such 'reviewing journals' the quality will automatically adjust, e.g. the best mission makers publish at the best community sites and vice versa. In the end this might even reduce the reviewing work.

Just a thought, nothing more...

[Mikero]

@Barron

Barron, I wont fill up space quoting you, because I agree with all of it.

Short of Bis enforcing rules within the engine of ofp1 or 2, there is never going to be a centralised repository and enforcing anything is a failure garanteed for all the reasons you point out. I'd add one other, bugger it. It's senseless and analy retentitve to *need* to have such a thing.

What ofpect can do (and does currently do quite well with missions) is make it attractive to player and author alike to follow some guidelines. Tags are one example that took off, mission ratings are (to my uncertain knowledge) appreciated by the community as a minimum garantee that the 14 meg download is worth the effort.

We can make it attractive to user and addon author alike to use whatever system we put in place, a sort of too good to avoid thing. One issue you raise is the #@_)*_$@_ interdependent addons needing addons needing addons. As you know, I wrote an addon scanner that largely solves this issue by sniffing at the contents of addons to see what (other) addons are needed (urrrgh). It takes a few seconds to scan, and could/ should? be part of the description that we at ofpec publish when we release that addon for general consumption.

I guess what I'm saying here is gimmickry. You add the 'giimmick' of highly needed info like what addons addons need, and hey presto, you gain an audience for the way you want to arrange things. This doesn't need to be done, and much worse, trusted by, the submitter. It's a two second scan for the guys in our back rooms, releasing the submitted addon.

If ofpec have the reputation for quality information, then the cart will follow the horse. There's an awful lot of people out there who simply will not use addons, period, because of these difficulties, if we introduce any system that works painlessly, they'll start using it, and authors will follow, because they'd have to, to get the audience they don't have now.

[Spinor]

Short of Bis enforcing rules within the engine of ofp1 or 2, there is never going to be a centralised repository and enforcing anything is a failure garanteed for all the reasons you point out.

Quite right, a centralized solution can only be done by BIS. In a way they already have somethin like this for Addons At Ease. For the community, there is the possibility for mirrored servers at the big community sites, and I can see no objective reasons why this should not work. Connect the three biggest sites and you should have 90% of all addons listed.

It's senseless and analy retentitve to *need* to have such a thing.

I fail to realize how this should be. Whats so strange about the wish to play a mission as quickly and painlessly as possible. I dont want to read readme's, download half a dozen files (trying a dozen links) and unzip everything...I want to select the mission and be done. Without BIS this will not be possible but why not try to get as close as possible to that. You mention a scanner to automatically determine the needed addons...this is a good thing, but only half way to the optimum.

We can make it attractive to user and addon author alike to use whatever system we put in place, a sort of too good to avoid thing.

If ofpec have the reputation for quality information, then the cart will follow the horse. There's an awful lot of people out there who simply will not use addons, period, because of these difficulties, if we introduce any system that works painlessly, they'll start using it, and authors will follow, because they'd have to, to get the audience they don't have now.

Sorry, but I probably misunderstand/read too much into that but are you suggesting to put a system in place only on the grounds of the good reputation of OFPEC rather than objective value of the system? If thats the case you should start thinking about the community rather than OFPEC alone, or otherwise it will bite you in the ass sometime.

[Sui]

I think Spinors view on a centralized solution is correct... I reckon to cover the whole community we'd need to get BIS involved.

Ideally, by submitting an addon to one of the top sites, it would automatically get registered in the 'master' database.

As you said, the whole centralized system fails as no-one uses it. What I think would be necessary to offer as much features to any mod or addon maker, so that he gets interested in offering and distributing his addons on a certain site like ofp.info. And once people are attracted and want to use your site, you can force them to follow some minor rules, as using tags or IDs.

I'd definitely be keen to work together with ofp.info and the community at large to come up with a viable system to get something like that off the ground. We're also planning for changes and improvements to OFPEC. Maybe now would be a good time to discuss how we can work together and come up with a more united system of how addons are handled around the major sites?

[Mikero]

I've had an interesting IM discussion with bn880 that we should share with you. For me it's an excellent example of what we could do if addons were centralised and 'registered', and it will surprise me greatly if Bis have not already thought this thru for OFP2.

My program, AddonScanner, does a fair job of detecting required addons (plural) in both missions, campaigns, and, addons themselves. There's some smallest of wrinkles in that it doesn't look for (addons within scripts eg), but on the whole it does a damn good job. There have been no complaints (so far) that it doesn't work !

What it does not do, and can not do is check dependencies within dependencies. Eg this addon needs that addon needs another addon to function.

The reason for this is as follows (and bare with me because it illustrates *why* registered addons would be so helpful)

The ofp engine works strictly and only with the classname of the addon, not the filename.pbo. You can quite literally call the filename.pbo anything that gives you a thrill. The engine, *only* looks inside the content for the classname.

It is the classname as declared in cfgPatches inside the pbo that is the source of the infamous "missing addon blah". What the filename[/] is, is anyone's guess.

One small wrinkle to this, in a (as it turns out in hindsight) poor design decision of addons, is that the addon itself, must know it's own filename to access it's own pictures, sounds. icons. Eg \filename\sound\thing.wss

Extrapolating this, some stub addons are strictly and only referenced by other addons via this \mechanisim inside the other addon(s). A popular recent move is to put all the piccies in a stub addon, and let other addons (of the family) reference these pictures (or sounds) via \filename mechanism. AddonScanner deals with these incidentally because it can. BAS soar pilots is an example of this.

But stricly speaking the ofp engine doesn't give a rats. It's only knows about the classname.

So, ideally, for AddonScanner to be a truly useful tool rather than just a sniffer, everone would love it if it it could list ALL addons including dependent ones. Presumably listed in a sexy tree-file listing.
Extrapolate that just a little, and it would be easy to 'see' how a thing like AddonScanner could automatically pull in all the requried addons for any given mission. Easy, and logical.

It can't because there is no correlation between the classname, and whatever the filename.pbo might be called. They are rarely the same name and the author is free to choose any filename that gives him a thrill (and trust me, they do just that)

To further clarify this, what I do have, as a modified copy of AddonScanner on my own system is a link to my OWN database. I have approx 500 classname - > filename.pbo links.

For my own personal use, i can, indeed, pull in 'automatically' most missions since I can build a list of dependencies based on my own scribblings.

PinkGiraffes.pbo == Bas_Repairh

What we need for tools like AddonScanner to work as nature intended is a registered database that Bas_RepairH (classname) actually == Bas_Repair.pbo (note the dropped H)

It needs to be registered and official, so that every one who uses a copy of addonscanner does NOT need to then go and create their own database !!

You can take this furhter and start adding common sense like Classname Tags automatically lead in to the start (at least) of the name of the pbo, but that's the general principle of *why*, such a registered database would be so incredibly good for mankind.

I'd be surprised if Bis haven't given this some thought, perhaps we can push it along a little.

[hardrock]

I'm not sure if I understood you correctly, but why don't you just create another small utility, that checks the ofp directory plus subdirectories for any pbo-files and checks any included config.cpps / config.bins for CfgPatches entries and creates the database based on its research? Doesn't sound too difficult for me, if you know how to handle pbo files and config.bins.

[Mikero]

@hardrock

fair comment, and that *is* the way i do it on MY hard drive.

however, what about the addon(s) i do not have on MY hard drive (to play that mission), and, every time I download a new addon or three under that system, I have to use that utility you mention to update myself. Yes, ok, easy to do, but it isn't plain simple and painless and is not universal. Only I can use it. Ok, so I supply a the tool so others can use 'it' too with their own peculiar disk setups.

that's the easy bit. The hard bit is, if you recall from your own pain, and the one item that drove me mad with frustration with addons is not knowing beforehand that I needed seven more to go with the one i didn't currently have. As you have described it, and indeed, as I have implemented it , it cannot resolve this major major bugbear.  It canot know, beforehand, what, if any, depencencies are involved until it finds the #*@$*_$@_ pbo filename. By the time i'd hunted down via google the umpteenth addon required I'd long forgotten why i wanted to.

we need an official registry. one that states that the bas_repair classname, will be found in blah.pbo.

It's only via Bis that the actual name of blah, can be sanctioned. We can help that process along by providing some reasonable blah sounding logical naming conventions and, perhaps some tools such as above to push it along.

Whether as this topic's first post suggested, it's serial number based, might not be the point. The issue is to create registered addon names, perhaps based on serial numbers, perhaps not.

edit: one thing to point out here is lack of overhead. There isn't any particular reason why Bis in this instance would have to register or hold a copy of, THE addon, it merely needs the pbo filename registered so that people and auto-utilities have a half fighting chance of discovering it on a site somewhere.

[Spinor]

we need an official registry. one that states that the bas_repair classname, will be found in blah.pbo.

I would suggest a slightly different way. There are two separate problems here:
1) Determination of all dependencies of a given addon/mission.
2) Downloading the dependencies from the web.

Ideally, both should be as automated as possible.

1) is probably best done locally by the addon/mission creator with the help of mikeros AddonScanner. As I understand it the outstanding problem is that we actually have to deal with two kind of dependencies, namely class dependencies and file depencies (such as in scripted modules). The AddonScanner should be able to sniff out all class depencies and transform them to file depencies by matching class names. Direct file depencies are probably hard to do automatically. E.g. a scanner would have to search all script files in a mission looking for patterns like <loadFile"\*\*.sqs">. Whatever the method, at the end should be a list of all files necessary to run the respective mission/addon.

When registering the addon at the server, the addon maker would then have to supply this list. A good way to do this seems to be via md5 hashes as suggested by tug2000 in the BIS forum, as they uniquely identify a file. The registration database would not store class<->file dependencies but only file<->file dependencies.

tug2000 apparently is working on a solution of number 2) using this md5 hash method.

[General Barron]

We need an official registry. one that states that the bas_repair classname, will be found in blah.pbo.

With all due respect, I think this is completely wrong. All the 'tools' are already in OFP to solve the problem you described; they just aren't being used by addonmakers.

Unless I'm mistaken, whenever you place an object/weapon/etc that is defined in a cfgPatches class, then OFP will automatically put that cfgPatches class in the "required addons" field of the mission.

As you pointed out, often the name of this cfgPatches class is completely different than that of the actual .pbo file. Since the cfgPatches class name is what appears in the "missing addon xxx" dialog, this can often lead to confusion.

The solution seems brainless to me: addonmakers need to simply make ONE cfgPatches class per .pbo, and they need to give it the same name as their .pbo file.

This way there is no need to map individual classnames (of which there could be hundreds per addon) to .pbo file names: it is already done for you by OFP.

Then, as long as addonmakers properly list the addons required by THEIR addons, then OFP should also automatically take care of that in the same manner (not entirely sure about this).

The final part of the puzzle lies in proper readmes. If addonmakers would create useful readmes that include information such as required addons + links, then there would be no problem.

There are two separate problems here:
1) Determination of all dependencies of a given addon/mission.
2) Downloading the dependencies from the web.

I quite honestly believe that both of these problems would be better solved by increasing the standards of the community; not by of continuing to tolerate incomplete/shoddy work, and instead working on a system to compensate for it.

[Mikero]

The solution seems brainless to me: addonmakers need to simply make ONE cfgPatches class per .pbo, and they need to give it the same name as their .pbo file.

voila. I agree with that.

I'm a bit hazy on one aspect of this and that is I believe that putting more than one class in cfgpatches is in fact an error. It's not meant to be used in that fashion (more than one classname). The only time i've seen it 'working' is when the other classnames are simply references to older version names of the same addon.

>auto dependencies.

yes. And unfortunately not. requiredAddons[]= in the config.cpp is a good thing (tm) but it doesn't have (of course) anything to do with those addons listed in mission.sqm's or sqs files of the \filename.pbo type. The pc editor does not auto insert the addon classname in addons[]= for this type of thing (it can't because it's human generated). _However_ it's a non issue in terms of locating the filename.pbo (the thrust of what I've been saying above) because it already is the filename.pbo !

You're dead right Barron, if classname = pboname was rigidly enforced, a swag of gotha's would dissapear.

Again, Bis could enforce this on ofp2 (eg), it then leaves legacy addons (for want of a better term), and they could either be renamed.pbo's to their 'correct' name with some additional work inside each config.cpp, or, some sort of legacy dbase could be generated to support them.

But, all in all, I think your very much on the money, if this one thing became the 'official standard' the world would be a better place.

[Mikero]

nearly deleted what I wrote above because I had a 'scary thought' that revised addons would be difficult. Eg you could no longer change the name of the pbo to whatever versioning system you like. (you cannot change tbe classname period, because changing it makes it a totally separate addon, unusable by missions using the older 'version') But it's a non issue afaik since a version = label should be plunked inside the config.cpp (even if it aint used by anything), and presumbalby the zip filename would reflect a difference.

[Spinor]

There are two separate problems here:
1) Determination of all dependencies of a given addon/mission.
2) Downloading the dependencies from the web.

I quite honestly believe that both of these problems would be better solved by increasing the standards of the community; not by of continuing to tolerate incomplete/shoddy work, and instead working on a system to compensate for it.

Yes, problem 1) would be solved trivially, but also not completely. Think about pure file dependencies as in pure script .pbo's...or the ambiguity due to different versions of an addon: Two versions v1 and v2 would have the same file and class name (v2 is back-compatible to v1) but a given mission might require v2.

And I admit it, number 2) is just a comfort thing. Taken to the extreme, a tool can be devised that, with one click, automatically downloads all missing addons in your setup ... no need to look at any readme. I know, some people do not like such a degree of automatization (especially the more computer-savvy ones) but I am a lazy bastard and love it.