Make @ sign compulsory for MODS

[walker 0]

Hi all

This is directed to BIS but placed open to all to discuss.

The "@" sign is a convention for MOD folders in ArmA to delineate them from ArmA folders, that has grown up from experience and time. I think the convention is now worthy of becoming compulsory.

I think that for ArmA II BIS should make the "@" sign mod Folder convention compulsory, I presume the mod switch can be filtered to include the "@" sign.

I make this suggestion after seeing similar things to this that Matt Rochelle Notes

Quote[/b] ]Matt Rochelle

Posted: June 15 2008,14:32  

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

Ive seen people joining with Mod servers which look like this:  

DBE1;BETA;XYZMod1;Mod2;Mod3;Keys;DTA;Missions;MPMissions;Battleye;Templates

etc etc and its like OMG.. you dont add every folder in your dir.. just the mod folders. lol  

http://www.flashpoint1985.com/cgi-bin....1258260

Kind Regards walker

[baddo 0]

The example from Matt Rochelle is someone not understanding. The @ doesn't solve that "not understanding" problem in any way as I see it. If you will be using the command line arguments to load mods, people will always be able to mess it up no matter what kind of names the folders have.

Instead of forcing some mysterious character into the folder names, I would put a "Mods" folder into the ArmA folder and only allow loading of 3rd-party content from there. The game would check the contents of the "Mods" folder during start-up and would recognize which of the sub-folders are valid mod folders. There could be some specific file required in each mod folder which would briefly tell the game what the folder contains (maybe config.bin does that already sufficiently, but maybe we need another step before going into that). This system would not use any command line arguments at all.

I think that the user should be able to, after installing the game and the mods, forget messing with the command line arguments. The game could have a settings menu to enable/disable mods as the user wishes. The game could initialize and load mods when a mission tells it that "these are required, do you have them in the Mods folder? If yes then please initialize and load them asap". The game could unload and uninitialize mods when the mission started doesn't require them. Actually, I do think that the content is loaded on-demand, but there is some initializing phase which is done with the help of the command line parameters. Why? I don't buy the loading speed argument because if the actual content shown to the user is loaded on demand, why not also configuration. Surely with big islands for example, it could be good to load them on startup so the user gets a little bit fooled about the time it took to start a mission. But that would then be a job for the settings enable/disable mod menu.

Get rid of the whole command line argument way of initializing mods.

[NoRailgunner 0]

What if Addon2 overwrites config/settings of Addon1 or even standard ArmA ones? How the game should "know" what people like to play with? Better to have an launcher with options and custom preferences (UI, HUD, parameters etc).

[baddo 0]

Well didn't I say that you could choose from inside the game what you want loaded and what not.

Also, regarding the individual missions. You are only playing one single mission at a time. So if that mission uses only some particular addon, it only loads that. So what goes wrong here? Nothing. If you want to have some extra addons loaded, you could say in the settings menu that have this loaded now and then go start your mission.

You could have control in the settings menu over what are by default not loaded but which can be auto-loaded and what are always loaded no matter what the missions request.

In multiplayer it should be so that the server always dictates what addons you can have loaded. No problem here, if the user tried to force some addon to be loaded via the settings menu, then the game just unloads it when going into a server that doesn't allow it.

The 3rd-party launcher way is the lazy way to solve it. It is an anti-solution!  

[Synide 0]

Hi all

This is directed to BIS but placed open to all to discuss.

The "@" sign is a convention for MOD folders in ArmA to delineate them from ArmA folders, that has grown up from experience and time. I think the convention is now worthy of becoming compulsory.

I think that for ArmA II BIS should make the "@" sign mod Folder convention compulsory, I presume the mod switch can be filtered to include the "@" sign.

It was always a silly misguided community convention imo and I've personally never subscribed to it or implemented it.

I think that for ArmA II BIS should not make the "@" sign compulsory. It's unnessary.

I'd prefer it if they spent time on a 'pbo dereferencing' mechanism or 'pbo delayed load' scheme.

The reason you are seeing numbers of people connecting to servers with silly additional unnessary folders appended to their "-mod=" commandline switch is based on education not on the naming convention for a folder.

That is, the people in question obviously either have not had access to quality setup & implementation information or they have and they lack the mental capacity to understand it.

baddo's comments are pretty close to the mark... imo.

[walker 0]

Hi all

Particularly in reply to Baddo

The reason I suggest compulsory delineating MOD Folders with the "@" is because then you can take the whole question of what is a MOD out of the hands of the user. The plane fact is most users are not interested in the gubbins; they just want to play the game with all the neat stuff.

In reply to Synide:

Users should not be prevented from playing a game because they do not wish to be a geek. Among other things it makes no business or economic sense.

This is basic interface design; limit the user to permitted options to prevent them making an error. This is the whole point of modern development paradigms whether it be: a finite state machine or black box programing or the object model; control imputs and outputs to those permitted, it is about reducing the possibility of error and making the system transparent to the user.

By using compulsory delineating of MOD Folders with the "@" it then becomes a simple matter to take the whole -mod switch out of the equation.

An ArmA loader or ArmA itself can then just spot any MOD folders and add them to a library. The user then ticks what they want and or server can request certain folders. Without signifying the folder in some fashion you have no way short of being a developer or geek of understanding what is going on. Using a human visible bit makes things easier for the non geek user.

Synide and Baddo

I am sorry but using ArmA is not a substitute for a basic computer user course. And the archaic complexities of  ArmA addons and mods can never teach it.

The "@" sign became a convention in OFP/ArmA for a reason; to make it easier for people to play ArmA with different MODS.

Kind Regards walker

[Synide 0]

It's just my opinion Walker... you really don't need to justify you're point of view regarding wanting @modfolders as compulsory... I understand completely every point you made and I do have a little experience with computers besides using ArmA/OFP and modding it... but even that aside...

In a ideal software development lifecycle you would design software that caters for all contengencies... however, in this particular case currently the software is working just fine if one uses it as prescribed - you do not have to be a geek to use ArmA modfolder functionality as is...

Currently the functionality affords a degree of flexibility... what you are suggesting removes that flexibility.

When you are developing software you look at things that 'will do' as is and things that 'need' working on given your time constraints... and you make a decision based on this and a whole swag of other criteria as to whether one spends the time to alter the software as you describe or spend the time on something else that actually may not currently be working or has a higher architectural priority. Ofcourse as a development team you try damn hard to get as much userfriendily features into your apps. as possible and still give adequate flexibilty. The current method is sufficient - not ideal I grant you, but sufficient.

I'm simply saying that you're request for an alteration to a currently working feature simply to make it a little more robust to prevent numpties adding unnecessary extra folders to the commandline or a community contrived launcher tools' job a little easier is unnecessary imo.

What you suggest might be quick for the BIS team to implement and may even have some benefit to the end user and they may even have decided already that your suggestion is worth persuing... just saying that I don't think it is and I hope they spend they're time on something else that really needs attention.

Just accept that although you & possibly many others think your suggestion has merit and should be made compulsory by the BIS dev team... I personally do not. And, that's cool too, right?  

[.kju 3245]

whats the benefit?

[walker 0]

Hi Q

It makes it a simple process for ArmA itself or an ArmA loader to spot which are the mod folders and then add their content to a Library thus automating addon use.

Since the vast majority of users are not developers or geeks it allows them to play ArmA with addons.

It also allows Push technology on the server to request addons/MODs thus reducing the times when a user attempts to log on to server without addons. To some extent equal MOD does this but it is not a formal solution and requires human intervention to create. It is also mission specific requiring all missions on the server to be set to that MOD line thus preventing missions that do not use the MODS from loading; a headache for server admins as we know.

Essentially what I am calling for is an addon down-loader and manager internal to and approved for ArmA II, and a method for developers to help index those addons.

ACE addons all belong to the ACE index, ESP addons all belong to the ESP index, Lost Brothers addons all belong to the Lost Brothers index. As humans some of us but by no means all can fathom this for a computer and for the none geeks among us understanding this is harder.

Putting the "@" sign on there speeds up the process and reduces the amount of time spent looking through redundant folders. It could be a computer visible BIT but commonsense and experience tell us that human intervention may at times be required; making the bit human readable is obviously sensible.

Kind Regards walker

[.kju 3245]

I think ArmA might have an exception list of folders it does not

load by default or/and (more likely) it scans for

someFolder(s)InsideArmAWithAddonsOrDtaAsSubfolder

like

\ArmA\@ACE\addons

\ArmA\@ACE\dta

\ArmA\ACE\addons

\ArmA\ACE\dta

And 'stacked' folders for MF.

\ArmA\MF\@ACE\addons

\ArmA\MF\@ACE\dta

So for the engine itself it doesn't matter I think.

In the end common users will need to use an addon manager

tool like kegs, goArmA or YomaTools anyway.

MF should organize addons, as you should only load what you

currently need - even more sometimes different addons may not

run at the same time.

No idea what the naming restriction should help for these general problems.

People normally get the someFolder\addons\INHERE stuff wrong.

Loading -mod=missions etc does not harm I believe.