Addon Serial Database Idea

[bn880]

Hello all, I don't post here much as a force of habit, however I think OFPEC is the perfect place to consider an idea I had just recently:

We have a lot of people playing a lot of missions or trying to, where they get missing addon warnings and error messages. This is followed by them not knowing where to get the addon and which version it might be etc.

Auto Addon Server resolves this slightly, honestly not much more than that.

Now, here is my idea;  if we could have a central addon database, maintained preferrably here at OFPEC, where each addon, each variation of an addon, and each mod, has a unique numeric serial number or index assigned to it.

The serial number would function like a MAC address does for NIC's, no duplicates allowed ever, everyone must sign up for it at the same place.

Now, in the cfgPatches section of a config, people could type in that serial number at the end of the name of the addon, so that people can write this number down, type it in to the OFPEC addon cross reference, find it, click on the link and DL the addon from a server.

This is how I think each row for each addon may look like:

Code: [Select]

<index/serial>, <name>, <version>, <maker/team> , <date>, <released>,<relaced by index>,<DL locations>
unique integer, string, string, string, date, boolean, unique integer, string(s)

0000001, "Bn Tracers", "1.24", "bn880", 08/09/2005, true, 0000000, "http:\\blah blah"

^ this is all a rough draft and idea.  Now, if each addon and mod has a seperate and unique serial, we can fairly easily decentralize the download locations to dozens or hundreds of servers.  SQL queries can easily be run on the entries to search for addons.

I do not have any of the web server for this written, nor do I plan to work on this personally.  However I think it is a valuable thing to consider, to have ONE central place to find every addon ALL the time.

The addon makers could apply for their addon serial number before they publish the addon, so that they have time to insert the serial in the cfgPatches section.  Each entry in the DB would need to be administered by someone, as with most other submissions.  An admin could take in a request for a serial, create the entry, and send back to the addon maker the number.

This can extend to Armed Assault, and probably as far as Game2...     Thoughts?

[bn880]

Also I forgot, a place like OFPInfo, or BIS even could be running the centralized database (with links or offloaded DL sites).

The main thing I am concerned with is that this be kept without any requirements for registration besides: author or valid team member submits their addon/mod, it is not an exact duplicate

This is not about requiring things of addon makers, for approval, this is to give them a tool to identify their addon globally, to make it easier for lazy users such as ourselves.   ;D

[Terox]

An automated Registration Site

Addon maker registering would be required to fill out a simple form

Registration Form
NAME:
VERSION:
Previous versions avail: (YES/NO)
MAKERS NAME:
EMAIL: (With option to hide it)
TYPE: Pull down list  eg (MOD / Air / Armour / Weapon / Units / Combination / Misc / Island / Objects)
DESCRIPTION: simple text entry field
LINK: (Verified as a working link  during registration Process)
FILESIZE:
ADDITIONAL ADDONS REQ:
......................................... Serial No
......................................... Name
......................................... Version

__________________________________________________________________

something simple but time consuming enough to deter timewasters and spammers
Some form of anti spam protection, only 1 entry per IP per XXXX amount of time

Emailed Registration Number and requiring validation something on those lines


As an OFP user searching for the addon, they would log onto the site and be able to search either by

Serial Number
OFPEC tag, (which ideally would be in the addon name anyway)
Name of addon
Type

this will then pull up a simple window, with the content filled out in the registration form and the link highlighted to them



An automated link checking system, would monitor the condition of the link and inform an admin, if it went down
(A highlighted message box in the search process would inform the user that the link was down)

But as BN stated, only thing an addon maker has to do to the addon is add a serial number to the Required addons field nothing more than that, or it just simply starts to create unescessary complications

and as we all know, the more complicated it is, the more likely it is to fail



I think its a great idea, and if those technically able to do such a thing, get it together, this could be running before Arma is released, which will be great for the community

[remcen]

a good idea, but too late i'm afraid...
how would you handle already released addons which most missions rely on? would you want the addonmakers to re-release their addons with such a  serial, or would you wanna assign the serials to addons ex post?
anyway, this would be a hell lot of work given the sheer number of addons. and what about the addonmakers that have disappeared - or are out of reach for the english-speaking community?

if realized right from the start then it's a good idea for ArmA i think; in close cooperation with BIS preferably.

[Terox]

Its never too late
From the outset of the OFP Release, of course it would have been better, however thats hindsight.
A good addon making tutorial would have also been welcomed, but that didnt happen either

I am sure that when the OFPEC tag system entered  its initial discussion phase, the same was said

just because previously made addons may not be upgraded by their makers to utilise any such system, does not detract from the fact that overall it would be a worthwhile system

And better a system like this too late, than never at all

The OFP community still flourishes, even in OFP1's twighlight days, and it will continue to grow, so please dont think about the past, think about the next 5 years and the hundreds more addons that will be created that could utilise such a system


MANPOWER REQUIREMENTS
For the web based scripting system, i have no idea, but from a registration point of view, nothing more than a minute or so, and to add the serial to the addon config, even less

Once the system was incorporated, it would i imagine be fairly easy tro manage, as most of it will be automated


ARMA RELEASE

I would also expect, that when Arma is released, that a lot of existing addons may be upgraded to utilise any new entries in the comref or new engine attributes

so preparing such a system in advance would be a very sensible approach

[bn880]

Yes there would be the majority of the old addons which would not be on this database.  But if an addon maker wanted to, they could add the serial in about 20 minutes per addon.

Looking forward is defenately the idea here.  We have two more games coming from BIS in the future at least (we hope), and this would just knock down 90% of the addon searching issues.

[General Barron]

Hmm... interesting idea, although I have serious doubts about the effectiveness of any centralized system like this. In short: it won't work because most addonmakers won't use it.

Perhaps some, or even most, popular/large addon teams will use it properly. But the hundreds of small, single-man addons that are released every damn month will NOT, in general. And, as mentioned, the non-english speaking community will likely be out of reach as well.

OFPEC tags are a great example. Been around since 2002, yet we still see addons released without any sort of tag at all. Or we see addons that have improper/unregistered OFPEC tags, such as bn880's tracers (uses 2-letter, unregistered OFPEC tag).


However, even more revealing is the OFPEC tags listing. This is a single, already existing, centralized location for addonmakers to list their addons. Yet few, if any, addonmakers bother to update the information here. Check out the Finnish Defence Forces tag listing, which says they haven't released anything at all. (For the record,  my listing, which has at least been updated in the past, isn't current either)


I'd say that OFPEC tags are still successful, however. The reason: most addonmakers are aware of the reason why they exist, and so they include something like the tag system in their addons (your improper 2-letter tag is a good example; it gets the job done, even if it isn't 'according to standard' or 'registered').

Basically, the 'spirit' of the tags is alive and kicking, even if the centralized database is cold and dead. The problem I see with your idea, is that there is NOTHING to live on if the database part doesn't end up working.

---------------

The answer, as I see it, lies in the sites that distribute addons. OFP.info has got to be the largest and most popular of these sites. Yet, in some ways it is a nightmare of organization. There are no descriptions for addons... addons are sometimes contained in their 'news archives', and sometimes in their addons section... their addons section is a pain to navigate thru... etc etc ad nauseam.

Contrast this to the OFPEC addons depot, which in many ways is much better organized. Addons are organized into more catagories... you can see how many are contained in each catagory... you can change the display of each catagory (according to release date, author, etc)... addons have both author descriptions, and reviews... each entry has info like author website/email, links to other addons by that author, date released, version, and so on...

In short, it is much easier to find the right addon on OFPEC then on ofp.info. The only problem, obviously, is that OFPEC's addon collection is small and outdated, whereas ofp.info is about the largest and up-to-date there is.

So I think effort would be best spent getting ofp.info to organize their addons better, while getting OFPEC to update their addon depot. Perhaps other sites will follow suit.

Just my 2 cents.

------------

APPENDUM

Part of the problem, obviously, also lies on the addonmaker's shoulders themselves. Terrible readme's are possibly the biggest problem. Many don't include the version of the addon, for example. Often there is no reason to save the readme after downloading, since it contains no useful info. (Later on, if I download a mission that uses that addon, I would have no way of knowing if I already have the proper version.)

If the community as a whole would be critical about the readme (as they are about the rest of the addon), then the quality of readmes WOULD improve, as a whole.

The same goes for mission readmes. Authors need to include the required version of the addon, multiple links to the addon, the filesize, etc, so that players can be sure they downloaded the right one.

[bn880]

Wrong.

Tags require a lot of work to implement.  A serial does not.   Tags are for conflict resolution where as a serial and a central database is what makes someone's addon easily accessible.

People will use it if people know about it, much more so than the IMO complicated requirements of OFPEC tagging.

Please do not confuse this topic.  I'm talking about a serial number for any addon.  Not 20 million things you'd like addon makers to do, that is exactly the point, I don't want them to be bothered with anything beyond a serial number, so that people can get their addon from wherever it is hosted.  

There is a single purpose here, if it fails it fails, this is not a mission for compromise, it's a goal for making addon searching easy and centralized, which should have been done by BIS since day 1.

[macguba]

There is no such thing as OFPEC tagging.    The tag system was invented by OFPEC its true, but it was officially adopted by BIS.   The system is called "OFP Tags".    OFPEC is simply the place where tags are registered.   They are essential to prevent conflicts between addons, and if they are implemented as the addon is created cause little or no work.  (Changing an existing addon to use a tag is tedious:  however it is not complicated.)

However, what we are talking about here are two different questions.  Firstly, addon recognition, and secondly finding the wretched thing.    

Recognition does not require a new serial system.   If an addon uses its OFP tag correctly, and in addition incorporates a version number in it the approprate places, then by definition that constitutes a unique reference.   In other words perhaps the tag system should be extended to require the inclusion of version number.

Finding addons is always going to be a problem.    Having a central registry is a nice idea, but the difficulty is always these obscure addons which are unlikely to have been registered in the first place.   There have been a couple of attempts at creating such a registry, but they fizzled out as soon as the protagonists realised the size of the job.   There are a lot of addons out there.

However, these problems largely go away if mission makers include correct addon details in their mission readmes.    The underlying problem is that too many mission makers, and too many addon makers, are committed to producing rubbishy work.   Until the community as a whole decides not to use substandard material, these problems will continue to arise whatever solutions we attempt.

Nevertheless, this is an interesting and valuable idea.  It's probably too late for widespread use in OFP (although we could perhaps get it up and running for OFP if only as a testbed), but it would be nice to get all these things decided and appropriate arrangements ready for ArmA.  

[General Barron]

...it's a goal for making addon searching easy and centralized, which should have been done by BIS since day 1.

I know that is the goal, and I'm saying that it just will not work.

The problem is that the community is so large, so diverse, and so de-centralized. Therefore any centralized solution is bound to fail. The solution has to also be de-centralized. Macguba said it perfectly:

The underlying problem is that too many mission makers, and too many addon makers, are committed to producing rubbishy work.  Until the community as a whole decides not to use substandard material, these problems will continue to arise whatever solutions we attempt.

Increasing the standards of the community is what we should work on. This is a huge task, of course, but not impossible, as the OFP tag system (corrected myself) has proven.

[Planck]

I don't have much to add to what has already been said.

The idea is nice, but I can't see anyone wanting to take on a mamoth task like this, this late in the game.

We have a lot of people playing a lot of missions or trying to, where they get missing addon warnings and error messages. This is followed by them not knowing where to get the addon and which version it might be etc.

My view is that the mission makers should provide links to any addons that they have used in the readme that comes with the mission.
If people don't read the readmes then they only have themselves to blame if they come up against this problem.

If a used addon introduces an addon dependancy then this would have been discovered during beta testing, unless of course there was no beta testing for said mission.

The problem, in many cases comes from laziness basically. Too lazy to read a readme, too lazy or can't be bothered to beta test, too lazy to write a readme.

The idea is a good one, but it would involve a huge amount of work for very little gain and you would still be relying on the people who make addons etc to change their lazy ways.

Of course for future games AA or OFP2 it might be worth considering and encouraging the community to adopt something along these lines.



Planck

[Mikero]

I'm following this thread with considerable interest.

First off, I dont agree with GenBarron's experience that TAGS aren't succesful or widely used (that's my paraphasing, GBarron did not say that exactly)

I have, for reasons of my own, created a database of what is now around 500 addons, that's a big number in anyone's language, with admittedly many more than that 'out there'. The database was a horse before the cart kind of thing, an addon went into the database if it was used in a mssion, not, because it had pink snowflakes. There's any number of addons out there as re-badged BMP's with someone's country logo on it, and have NEVER been used in a mission.

My experience based on above is that TAGS are in fact *heavily* used. Much less than 10% of the dbase contains non-tag addons, and there's nothing I did or tweaked or crippled or discarded, that biased it. If an addon was used in a mission I played, I included it. Period.

There are instead, some popluar addons out their not using tags, which in the ordinary course of events would simply be ignored. My experience here is similar to everyone else's, without tags, you get multiple conflicts and almost invetibly stop using non-tag addons. BUT, the very few that are used, are used becuase they're too good to ignore.

Addon makers use the tag system because it is, convenient to them. A rose by any other name smells the same, but they very quickly learn that two identical roses having different perfumes aren't the same. So it's better to name THEIR addon something sensible so that THEY can use it.

The TAG system in it's current form, works, in my opinion, as best as it's ever going to get, short of Bis enforcing new rules in the engine to make it work 'better'.

So, on to serialisation. The principle purpose here is to always be able to grab latest 'n greatest. A secondary issue is to allow backward compatibilty. Eg some addons are less equal than others and some missions won't work with the 'improved' ones.

As I see it working....

An addon maker supplies us the addon. He can called it pink girraffes.zip for all we care.

The addon maker MUST have an  'official' bis/ofpec tag.

He 'registers' an addon name at the time of submission of THAT addon.

eg MIK (mikero)

addon OZSAS  (australian sas)

hit the submit button.

We tag the addon with a serial number. And one of the better 'serial numbers' are date based. 020205 eg

Our, Ofpec's filing system knows this addon (and it's consequent url) as

MIK_OZSAS_020205.zip

along with

SNY_OZSAS_xxxxxx
HYK_OZSAS_xxxxxx

ie. addon makers do not have to 'wurri' their names are in conflict

The submission form itself auto-replaces sumbissions same name / earlier vintage, or has a checkbox to preserve both.

This way, we aren't interested in how / why the addon is revised, or worse, what strange naming convention the maker gives his stuff.

This way, a searcher doesn't have to worry either. They scan the base, if the serial number's 'bigger' than what they already have, well .....

And, the addon maker doesn't have to fuss either. (S)he has a minimum of things than have to be filled in and has no opportunity TO GET IT WRONG!

[Fragorl]

Was going to reply to this, but ran out of time yesterday :/

Basically, what Mikero just said sums it up brilliantly. I think that the more awareness there is about the tagging system (especially if it's enforced as a necessity when submitting an addon to one of the larger sites, eg OFP.info, or even ofpec.com, where prospective addon makers want their work to end up after all) AND the simpler it is to navigate the submission interface (Author name. Addon name. Submit new Addon OR Update existing Addon.), the more successful the idea will be.

[General Barron]

Perhaps I should illustrate my point. What problem are you trying to solve? The problem of tracking down an addon, with the correct version, right?

A serial number system would require that all addonmakers, following a few guidelines, submit something to one central location. If they did that, the system would work, and the problem would be solved.

However, the problem could be solved today, no work required, if all addonmakers would submit something they already have to one central location: That is, if everyone would submit their addons to OFPEC, following proper guidelines, then the problem would no longer exist from that day forward.

---------------------

Obviously that isn't happening. Nor do I think it would happen if we 'asked nicely' around the official forums and other sites. Nor do I think a serial database would happen either, no matter how nicely we asked.

Addons get 'published' all the time, in many different ways. Sometimes they are released on the official forums, with DL links on rapidshare or other temporary hosting. Sometimes they are submitted to established websites, like ofpec. Sometimes they are posted on personal websites, without mention elsewhere. Sometimes they are released on non-english sites/forums. Often addons are found by websites like ofp.info, and then published on that site, independent of the author. The list goes on and on.

This system would require that everyone 'publish' their addon in one specific way, in addition to however else they publish it. I just don't see how that will happen.

--------------

My point about OFP tags wasn't that they didn't work. Rather, my point is that the centralized database of tags is a failure; just like I think any centralized solution to this problem is bound to fail.

The tags idea itself has been successful, not because a central location like OFPEC registers them, but because the community as a whole recognizes the need for them, and doesn't much tolerate addons that don't use them.

If we could get the community to also recognize the need to have proper readmes, including the version of an addon, dependencies, etc, then we would be another step towards the solution. If we could get websites like ofp.info to recognize the need for better organization and description of addon collections, then we would be taking a step in the right direction. If we could get mission makers to realize the need for completely and properly describing required addons (including version, links, etc), then we would be taking a step in the right direction.

The list goes on and on, and I'd be happy to share my thoughts on this subject, including how to 'spread the gospel' to the community.

[hardrock]

If we could get the community to also recognize the need to have proper readmes, including the version of an addon, dependencies, etc, then we would be another step towards the solution. If we could get websites like ofp.info to recognize the need for better organization and description of addon collections, then we would be taking a step in the right direction. If we could get mission makers to realize the need for completely and properly describing required addons (including version, links, etc), then we would be taking a step in the right direction.

Well, that's not really necessary, as exactly this weak point is planned to be removed on the planned successor of ofp.info for ArmA.

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.

The problem with OPFEC's tag repository is IMO that it's the only thing many addon makers use this site for (not all, of course). Thus it's wasted time for many of them to come here just to register a tag or update the entry later.

These people need to be attracted by other features, so they visit the site regularly and also update their profiles.

Much of it is planned for the new ofp.info site and the idea about addon IDs fits in perfectly. The last problem is that such a system requires time to make it. And time is expensive, nowadays.

[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.