Please BIS << addon management >>

[S-M 10]

Personally, i am hoping the new addon management will allow me to not have to use a 3rd party updater program.

I suspect i will be asking for a bit to much though, never like the updater thing, although i will admit it is a bit easier now to use, than it was upon the first time i used it.

FWIW i only use the ACE addons because my favorite server (and what seams most of the populated ones) use it none stop.

I dont play A2 every single day, so what tends to happen in my case is i have to update the whole bloody thing every single time before i play MP, i tried to find a decent vannila game only yesterday, and failed, hence why i added the ACE mod back in.

As people have said above me, a lot of people seam to know what to do regarding mods, mod folders, shortcut options, probably because they have been doing it for a while due to the earlier games.

Me personally, A2 was my first game in the series, and the way the whole mod thing was presented to me in the beginning, just utterly baffled me.

I joined a server yesterday and was instantly kicked from the game, with a nice message telling me so on the screen, why was i kicked? i had no idea, when i retried to join, it then told me i had an unsigned file and that i should remove it, if i had of never retried to enter i would have just walked away, no different from some meathead bouncer telling you to fack off when you get to the front of a nightclub que.

[Iroquois Pliskin 0]

W0lle! I apologize.

People, Wait until you launch Arma Op Arrowhead... The addon management is there! :D:D:D

I'm orgasming at this very moment. You can enable/disable addons without exiting the game.

P.S. It doesn't solve the delivery option if you're lacking a particular mod, though, and I don't know how the notifications implemented in the multiplayer, since I can't access Multi at the moment.

And when you Enable an Addon through in-game Expansions menu, game gives you an option to Enable & Restart automatically or cancel or Restart Later.

Edited June 27, 2010 by Iroquois Pliskin

[S-M 10]

Sounds good, hopefully my preorder arrives on tuesday....

[ryguy 10]

I have a pretty simple solution: The hardest part about add-ons is the fact that you need to make the mod folders, whereas the Arma 2\Addons folder is completely unused due to the fact that if you connect to a server not running that mod, you will get a message saying "Nuke.pbo is a file not signed by this server...". What would solve this is Arma 2 automatically shutting off the files that don't work, and turning them back off when you disconnect. This way you could connect with unsigned files and still play on any server fine. What do you think?

[terox 316]

I have a pretty simple solution: The hardest part about add-ons is the fact that you need to make the mod folders, whereas the Arma 2\Addons folder is completely unused due to the fact that if you connect to a server not running that mod, you will get a message saying "Nuke.pbo is a file not signed by this server...". What would solve this is Arma 2 automatically shutting off the files that don't work, and turning them back off when you disconnect. This way you could connect with unsigned files and still play on any server fine. What do you think?

I believe 3rd party content needs to be kept away from BIS content. Custom named mod folders are the easiest way to seperate this 3rd party content and load what is required.

Here is some food for thought.

For example, lets say we have 2 servers both running the same "Full conversion mod" but both servers use a different island pack

I'll use the "@" character as a global tag for a mod folder

Your root installation would then contain 3 mod folders

• @Full_Conversion_Mod
  
• @Server1_IslandPack
  
• @Server2_IslandPack
  

1) How would you manage both island packs (the download and storage of the .pbo), if for example, they both contain Island_A

Would you have the Island_A.pbo in both mod folders, would you download it twice, or could you automatically copy the file from @Server1_IslandPack to @Server2_IslandPack during the automated download phase

*****************************************************

2) If Server1 uses a later version of @Full_Conversion_Mod than Server2 how do you upgrade/downgrade the version on the client

*****************************************************

At this point, I think it would be sensible to define the 2 different types of 3rd party content as it stands today

1) An addon pack (This contains various 3rd party content that are independant from one another) for example a selection of islands

2) A Mod (This contains a series of addons that are designed to work together and are dependant on each other's configs) for example ACE

Mods tend to be available from a central repository, or mirrors therefof and updated by the MOD developers

Whereas an addon pack for example Server1_Islandpack would be created by and updated by the server admin after they had downloaded the individual addons from various locations, normally Armaholics or .info and then offered as a downloadable .rar, 7z file from their web site, which when extracted created the @Server1_Islandpack mod folder.

Any system that is implemented needs to take this into consideration

An ideal situation is to have one central repository with mirror sites, where all addons are stored, maybe stored in sub folder that were the same as the ofpec tag system

If the addons required are a mod, then maybe the mod should contain a file which lists the location and files required for the mod. this would be defined by the mod developer

whereas if the content was an addonpack, the server admin would somehow define this list and the name of the mod folder it needed to be stored in

In both cases something similar to the below example, which uses a format we are alkready familar with

class Modfolder
{
    name = @Server1_IslandPack
    class folder1
    {
         name = addons;
         type = folder;
         files[]=
         {
              www.centralrepository/OFPECTAG_1/addon1.pbo
              www.centralrepository/OFPECTAG_1/addon2.pbo,
              www.centralrepository/OFPECTAG_2/addon3.pbo
         };
    };

    class folder2
    {
         name = userconfig
         type = folder;
         files[]=
         {
              www.centralrepository/OFPECTAG_1/options.hpp
         };
    };

    class folder3
    {
         name = docs;
         type = folder;
         files[]=
         {
              www.centralrepository/OFPECTAG_1/classnames.txt,
              www.centralrepository/OFPECTAG_1/readme.txt,
              www.centralrepository/OFPECTAG_2/classnames.txt,
              www.centralrepository/OFPECTAG_3/readme.txt,
         };
    };
};

Either way the list of files would then automatically be , downloaded an saved into the required mod folder structure

The client would not need to be aware of any of this, they would simply see the "Download Required addons" button that I mentioned in my first post which when clicked would then read this config file and automate the version checking, download installation and loading process

The server itself could also read the same file and check for any updates, and then update automatically or warn the server admin that updates are available.

I'm not technically proficient at any of this, these are just thoughts on the front end side of managing this system

Edited June 28, 2010 by Terox

[Yoma 0]

A question on the internal mod manager: how does it handle mods in subfolders?

Stuff like

c:\ARMA2\MyReallyGoodMods\MOD1\Addons

c:\ARMA2\MyReallyGoodMods\MOD2\Addons

---------- Post added at 09:44 AM ---------- Previous post was at 09:17 AM ----------

Terox: what i would personally do if I were BIS is something like

-Create an addons-cache folder that simply has all addons but not listed by name, but by some sort of unique filecheck, something like

#UNIQUECHECKSUM#.pbo

-Then the server could publish a list of it's unique checksums and the client could try to load up the checksummed files and give a resume of the lacking files...

Also this could be a base for synchronising addons...

The biggest problem this system would have is "when to purge the cache".

A suggestion there would be to keep track of the last time a cached file got used and on what server. If you've only used a file on server x and server x changes the file the cache can get purged.

This system would move away from "modfolderbased" loading of addons, but more towards "checksumbased" loading of addons.

The beauty of this kind of system is that it would allow everything we have today without being intrusive at all, versioning included!

The biggest drawback would be diskspace.

Edited June 28, 2010 by Yoma

[[frl]myke 14]

You can enable/disable addons without exiting the game.

Did you realize that you have to restart the game so the changes take effect? It is a good start, now add a launcher which will let you chose addons before the game starts, and it will be a huge step ahead.

[Zipper5 74]

Did you realize that you have to restart the game so the changes take effect?

Note the banned avatar, Myke. :p

[SWAT_BigBear 0]

Did you realize that you have to restart the game so the changes take effect? It is a good start, now add a launcher which will let you chose addons before the game starts, and it will be a huge step ahead.

An auto restart of the game is a must, it worked well for BF2+expansions.

I would prefer to see:

@islands,

@infantry,

@vehicles,

@effects, and so on.

Having a "paragraph" as a target line is ridiculous.

[Dwarden 1125]

unique check filename is best usually was used md5 or sha1 of whole file

some games were wiser and used only first and last N kB from each file

which is enough and is way faster

anyway like Marek said we know about this and are working on solution(s) to this and many similar problems (missions URL forwarding etc)

[terox 316]

]Terox: what i would personally do if I were BIS is something like

-Create an addons-cache folder that simply has all addons but not listed by name, but by some sort of unique filecheck, something like

#UNIQUECHECKSUM#.pbo

-Then the server could publish a list of it's unique checksums and the client could try to load up the checksummed files and give a resume of the lacking files...

Also this could be a base for synchronising addons...

The biggest problem this system would have is "when to purge the cache".

A suggestion there would be to keep track of the last time a cached file got used and on what server. If you've only used a file on server x and server x changes the file the cache can get purged.

This system would move away from "modfolderbased" loading of addons, but more towards "checksumbased" loading of addons.

The beauty of this kind of system is that it would allow everything we have today without being intrusive at all, versioning included!

The biggest drawback would be diskspace.

I dont see diskspace as being an issue these days. Hard drives are inexpensive and will reduce in price more as SSD's become more widely available and cheaper.

The checksum based system (which i know very little about) is outside of my limited technical ability. You have more than proven yourself with your extremely useful "Addon sync" tool, whiuch has made my job as a server admin oh so much easier, so I have to bow down to your expertise on the functional side of the backend

anyway like Marek said we know about this and are working on solution(s) to this and many similar problems (missions URL forwarding etc)

Thats all great Dwarden, but isnt this thread a great opportunity for bringing in ideas and expanding on possible solutions especially from people like Yoma, Sickboy and others out there within the community with technical knowhow.

Maruk and myself seem to have the same view on what is required at the front end, others may have different opinions or offer a better technical solution. I was happy to start the thread and maybe we should continue with it allowing more constructive feedback

[gossamersolid 155]

I do like the fact that BIS has acknowledged this and is working on a solution... especially for missions URL fowarding. To me, that is one I want to see implemented ASAP. For addon synchronization, I'd definetly like to see an integrated one... but it's not the end of the world right now as we have people like Yoma and sickboy with tools out to do it.

[Defunkt 431]

Well I think this thread is a great place for people to realise the problem/solution is much more complex than they tend to assume when they quip "BIS should be fixing this" (remember most studios have solved it by simply dropping support for modding). You're messing around with peoples' file system and making guesses and assumptions about how much bandwidth and disk space they want devoted to differing versions of the same, often very large, mods.

+1 for mission URL forwarding first which will be a lot simpler to add quickly as it's just changing source and protocol for an existing capability.

[Yoma 0]

Thats all great Dwarden, but isnt this thread a great opportunity for bringing in ideas and expanding on possible solutions especially from people like Yoma, Sickboy and others out there within the community with technical knowhow.

I don't think people like Dwarden, Maruk, Suma or pretty much any developer/ex-developer of the OFP/Arma/Arma2 games will have much to learn from a simple bloke like me.

Addonsync is pretty much the idiot's approach to a complex problem.

A lot stands or falls with how deep/complex you want to make the solution.

For example BIS could take a "managed" approach where they set up a network that allows to download verified and tested full mods. (Stable ACE releases for example) Somewhat like Apples appstore but for Arma mods.

The big benefit this would have for BIS is that they would get less hammered for problems that aren't theirs but have a source in buggy addons/scripts/blabla. The big downer with this approach is that it would reduce addonmakers' freedom a lot and would require extensive resources for testing, reviewing, serving files...

Another approach could be a more liberal "dump whatever you use somewhere and we'll make sure you can easily get to it".

For this system the local filecache I was talking about would be more suitable as at least it would restrict the number of local copies of a file to 1. However it would probably mean extensive changing of the way Arma processes addons. Diskspace might be an issue when people use smallish SSD's for optimal streaming performance...

The great thing is that it would greatly enhance overall stability as you could make sure everyone is loading the exact same files and have the exact same game.

If they could tightly integrate this kind of stuff with a torrentlike protocol that has several http mirrors for ensured performance they could make a network where every single addon is "up in the cloud" somewhere and the game can fetch whatever it needs, if needed.

The big benefit of a torrentlike approach is that managing the actual network could be a breeze. Upon starting the server it could check if every addon loaded is on the network, and if not ask to upload the files to the network.

When downloading clients could simply ask the cache for a list of files to use or download the missing files from the network.

[gossamersolid 155]

For example BIS could take a "managed" approach where they set up a network that allows to download verified and tested full mods. (Stable ACE releases for example) Somewhat like Apples appstore but for Arma mods.

The big benefit this would have for BIS is that they would get less hammered for problems that aren't theirs but have a source in buggy addons/scripts/blabla. The big downer with this approach is that it would reduce addonmakers' freedom a lot and would require extensive resources for testing, reviewing, serving files...

While this is a really cool idea and I tip my hat to you for thinking of it... I'd prefer to manage these things myself. Since I do have a server box (and many others here do I believe), it'd be great for us to simply designate a mod folder and then have a compressed version somewhere on an FTP or HTTP server... if you think about it, kind of like how the source engine deals with custom content:

Maps Folder:

mapname.bsp

mapname.bzip2

remote folder (where people actually download from)

mapname.bzip2

Then when clients recieve the way smaller file at a faster rate, their game handles the file and extracts it accordingly.

[terox 316]

While this is a really cool idea and I tip my hat to you for thinking of it... I'd prefer to manage these things myself. Since I do have a server box (and many others here do I believe), it'd be great for us to simply designate a mod folder and then have a compressed version somewhere on an FTP or HTTP server... if you think about it, kind of like how the source engine deals with custom content:

Maps Folder:

mapname.bsp

mapname.bzip2

remote folder (where people actually download from)

mapname.bzip2

Then when clients recieve the way smaller file at a faster rate, their game handles the file and extracts it accordingly.

I think the ability to use either a central repository for the files or a more localised hosting solution should be what is sought after

Our own specific set up uses CBA, Ace etc and a custom addon pack which contains islands, some client side addons etc.

We host everything through a Yoma repository and advise the folks who play on our server to only use Yoma's so that they have exactly the addons and the versions of those addons that the server runs.

However we do suffer from issues with folks who then decide to use 6-updater or another Yoma repository to grab the latest version of say ACE, or download an updated version of an island direct from Armaholics.

So, 2 arguments here

1) A localised repository created by the server admin would ensure that the clients joining the server have their addons synced to the server

2) Whereas a central repository would ensure the clients have the most up to date version of a specific addon.

I suppose the ideal situation is for the system to check the file on the server, compare that to the client file. If a mismatch occurs, then first look for a localised repository and if none are defined, then look at a central repository.

Or allow the server admin to define, how the client should proceed in syncing with the server.

*********************************************************

Would the following summary be correct, at this point ?

1. Client needs
   
   1. 
      
   2. A message to inform the player, that the server runs content that the client does not have
      
   3. Then be presented with a simple button that states "Download and install required content"
      
   4. Automated loading of required addons using a silent engine reset (Possibly showing a loading screen of some form)
      

[*]Server needs

• to be able to offer this content locally or use a central repository
  
• Maybe to auto update hosted addons in some way
  

[*]Common requirements

• File verification system to check and synchronise files
  
• A way of storing the files on the client that does not require duplicates in different folders
  
• Possibly a way of dealing with "Full Mods" where the files are addon dependant of one n other (E.g ACE) in a slightly different way than individual addons that can be compiled into a custom addon pack, for example a selection of islands.
  

Reasoning behind summary points

1) Client

Clients are not all tecnically adept so the most simplistic "Click this botton, and let an automated system do the rest" is required to allow them to grab the required content (addons) to play on a selected server

2) Server

Servers dont always use the latest version of an addon/mod or a publicly available addon and therefore require a system that will allow them to define what the client needs and where to get it from

They also dont want to be forced to use the game server to host the content being downloaded. A seperate website machine would in many cases be preferable.

There may be instances where a server side addon should not be offered to the client, for example Zaphod's Berserk server addon

3) Commonly

Storage space for addons, both serverside and clientside may become a priority issue especially with the advent of SSD's, therefore duplication of stored files in multi folder systems should be avoided

However there should be an ability to store the same named files so that different versions of files can be loaded

Edited June 30, 2010 by Terox

[Yoma 0]

While this is a really cool idea and I tip my hat to you for thinking of it... I'd prefer to manage these things myself. Since I do have a server box (and many others here do I believe), it'd be great for us to simply designate a mod folder and then have a compressed version somewhere on an FTP or HTTP server... if you think about it, kind of like how the source engine deals with custom content:

Maps Folder:

mapname.bsp

mapname.bzip2

remote folder (where people actually download from)

mapname.bzip2

Then when clients recieve the way smaller file at a faster rate, their game handles the file and extracts it accordingly.

The problem with this approach occurs when playing on multiple servers using different version of the same filenames.

No one wants people to download files over and over again...

Edited June 29, 2010 by Yoma

[mr.g-c 6]

unique check filename is best usually was used md5 or sha1 of whole file

some games were wiser and used only first and last N kB from each file

which is enough and is way faster

anyway like Marek said we know about this and are working on solution(s) to this and many similar problems (missions URL forwarding etc)

Excellent! Any chance there could be a way to activate/deactive the addons without needing a full restart, but rather some sort of a "internal engine reset" ? So just show the player a "Reloading" Screen while the engine reloads/reset itself?

....Seems like i have to recommend the game to even more guys then that i know - mostly people not the very brightest with PCs but still military kind of fans/enthusiast :p

[gossamersolid 155]

The problem with this approach occurs when playing on multiple servers using different version of the same filenames.

No one wants people to download files over and over again...

but the thing is that in some cases you do. Say a server's gamemode is running a 400mb addon pack and it has an addon that might have the same name as an addon the client has, but it has been modified in the addon pack... then the client will skip the file and be out of sync with the others.

[sbsmac 0]

I think Yoma understands the versioning problem quite well. The issue really is that filenames are actually very poor identifiers when you start taking versioning into account so the current mechanism that only allows users (on both client and server) to specify addons by directory doesn't really work for a distributed system. (Actually it would work quite well if a unique directory name was used for each addon version but that clearly isn't the case currently.)

What you really need on the client side is a cache of addons which are keyed by hash (md5 or alternative) and then a mechanism on the server to share a list of 'active' hashes with the clients. Directory (and even filenames) become irrelevant in identifying the correct addon.

So you're client-side algorithm looks a bit like (in pseudo c#) ...

foreach (Hash h in ListOfServerSideHashes)

{

if (!Cache.Keys.Contains(h))

SomehowLocateAndDownloadRequiredFileToCache(h);

Load(Cache[h]) ;

}

One of the wrinkles here is that this works best if clients are restricted to just the list of addons that the server is currently using. As soon as you allow clients to use mod 'X' even though the server treats it as optional, the hash is insufficient to disambiguate between the cases where:-

1) The server does not use X at all but the client does.

2) The server uses version A of X but the client uses version B.

At that point you need to fall back on some other mechanism such as filenames, contents or run-time overides of duplicate content to ensure that matching versions are used on client and server.

As people have observed, there are several issues including how to expunge stale versions from the cache, how to obtain 'missing' addons and building in dynamic loading of addons. It sounds like BIS have thought this through so I look forward to developments. :)

Edited June 30, 2010 by sbsmac

[terox 316]

Comments about the readability of the gamespy browser have also been made in other threads, so to reiterate it here

GAMESPY BROWSER ISSUES

There is a need to be able to distinguish the various reasons why one may not be able to play on an individual server

1) Passworded

2) Locked

3) Equalmodrequired

4) Signature verification enabled and

• You are running addons that the server does not run a key for

5) Addons loaded by the server that you are not running

6) Game version Mismatch between client and server

There are currently only 2 colour buttons in use Red and Green

and also 3 icons used

X, ? and a "key"

Red should define that the client cannot play on the server. At the moment this is not necessarily the case. If the client has loaded the same addons as the server but used a different -mod param, then dependant on serverside config settings, the server may have a red dot next to it.

Alternatively a green dot does not necessarily indicate that the client can play on that server. This can be very confusing and should be idiot proof

Possibly display a number code inside the button to define any issues that the client may have when trying to connect to the server

Also have a small popup window when the mouse hovers over these buttons, which explains the issue in more detail

The "key" icon doesn't distinguish between a temporarily locked server and a passworded one

For some reason many clients never read the detailed information field at the bottom, so possibly when a server is highlighted, have a pop up window display detailing the specific server info or make the area set aside for this info more prominent. I know some will still not see it even if the biggest most glowing arrow pointed to it, but more would

Basically redesign the gamespy browser to be more self intuitive and not misleading

Edited July 17, 2010 by Terox

[mr.g-c 6]

Very good suggestion Terrox, as always!

I hope BIS is listening and writing that down + consindering it for future updates/expansions.

Regards, Christian

[CarlGustaffa 4]

What is idiot proof with an error number code? Everytime my system throws one of these in my face, I feel like an idiot, but I don't think that is what you want to accomplish :p

[terox 316]

What is idiot proof with an error number code? Everytime my system throws one of these in my face, I feel like an idiot, but I don't think that is what you want to accomplish :p

Well the number code would only be seen in the red box, because the green button in the ideal world would mean you can play on the server.

The only icon/s that could be enabled in a green box, is one to state it's password protected and one to state its temporarily locked.

Or alternatively, show these buttons as orange, which would indicate your client is set up correctly to play on the server but the server is either locked or passworded

and then throw a key icon or some such icon do reiterate that.

Like a traffic light.

Green: Go

Orange: wait/get ready

Red: Stop

and then hovering over the red button or even the server listing in general would then pop up a little dialog box explaining what the number means and how it effects you as a client.

It may not be totally idiot proof, but its much better than the present state

Green can mean go or stop

Red can mean go or stop

Edited July 17, 2010 by Terox

[76 0]

Armed Assault 1 was dead by the time ACE 1 was released - lo & behold you had full servers 24/7 with every mission imaginable from Road Rage to CTF and CTI, COOP...

Well thats a load of mumbo jumbo except the word 'COOP' cause I cant remember f'all CTI or CTF that used ace and if you could please direct me to the link where I can download Raod Rage the ace version?

Full servers.... hardly, only PvP pulls the big numbers, simply because you cant play with 50+ ppl all with AI under their control and the server not lay down and have a seizure.