Jump to content
Sign in to follow this  
Yoma

Addonmakers Please Don't Use Default BIS folders!

Recommended Posts

Before i start this: my word of deepest respect to all guys and girls out there making Arma a better world.

Here is goes:

Some addons use for example the default DTA folder in the arma directory. (sixth tracers springs to mind, i love it, but i hate the config file that resides in /DTA)

The problem with this is it introduces potentially bad situations where config files mess up stuff for other mods AND maybe even more dangerous, people will be tempted to put default folders on a yomasync server.

I think we can all imagine what kind of trouble this could create...

Therefor I BEG to all addon makers: keep your config files INSIDE a separate folder INSIDE your addonfolder. Stop messing up the default folders! To me this hasn't create big problems yet, however everyone realises these are accidents waiting to happen.

Share this post


Link to post
Share on other sites

Sorry?

But how should I find out which is my addon-folder?

Your suggestion requires that no user is allowed to change the addon-folder-name.

Share this post


Link to post
Share on other sites
Sorry?

But how should I find out which is my addon-folder?

Your suggestion requires that no user is allowed to change the addon-folder-name.

I'm not sure I follow. He's saying that we shouldn't put stuff in the default folders. He suggests that mod developers should instead put stuff that would normally go into ArmA\Dta into ArmA\@mod\Dta. Is it that if stuff is pathed to ArmA\Dta that you have the flexibility to change @mod to anything you want at any time? What is the benefit of doing that? Is there a limit to the number of seperate mods you can load? Also, If you had all your files in @zomgzorzmods, but left the dta stuff in @mods\dta, would the stuff that's pathed there not be read if the mod folder is not loaded?

Share this post


Link to post
Share on other sites

Personally this is common practise, and have been doing it with any addon/mod I download or edit for years in OFP smile_o.gif

Share this post


Link to post
Share on other sites

A mod can have his Dta-folder. But it won't get redirected to the ArmA/Dta-folder. Only bin.pbo and core.pbo will get used.

Quote[/b] ]Also, If you had all your files in @zomgzorzmods, but left the dta stuff in @mods\dta, would the stuff that's pathed there not be read if the mod folder is not loaded?

That would be possible. But the @mod-folder has still remain and is messing your ArmA-folder.

But whats his problem with the dta-folder?

Sixth tracers are using their namespace. So no other will overwrite or use this file. And if the user has to edit the file, so Yoma Addon Synchronisier can prompt for it.

Share this post


Link to post
Share on other sites
Sorry?

But how should I find out which is my addon-folder?

Your suggestion requires that no user is allowed to change the addon-folder-name.

I'm not sure I follow.  He's saying that we shouldn't put stuff in the default folders.  He suggests that mod developers should instead put stuff that would normally go into ArmA\Dta into ArmA\@mod\Dta.  Is it that if stuff is pathed to ArmA\Dta that you have the flexibility to change @mod to anything you want at any time?  What is the benefit of doing that?  Is there a limit to the number of seperate mods you can load?  Also, If you had all your files in @zomgzorzmods, but left the dta stuff in @mods\dta, would the stuff that's pathed there not be read if the mod folder is not loaded?

1) I'm trying to find out if there is a solution to this.

   Something like a relative path for config files for example.

2) I personally wouldn't mind if you where obliged to use a fixed non-default path for your addon config file e.g. #ARMADIR#\@MYMODNAME_CFG\configfile.hpp

  That would still be A LOT less dirty that dumping stuff in /DTA

3) What these addons cause is that server admins using my (or any other sync tool, if there is any) have that tool access a default arma folder.

   For example my tool has a function "delete extra files" which is handy as modpacks change all the time, so you can clean up old, unwanted files. I added a patch that avoids deleting in default arma folders, but still it's an accident waiting to happen. The result is that some modservers will just say "and you have to download this config file and stuff it in /dta" which disables true synching possibilities. This is one of the reasons why i call to use some sence in this. Of course this kind of problems only occur with mods that stuff things in default arma folders.

4)If stuffing configfiles in separate folders like modfolders would be a bad practice, then why even bother to use modfolders at all, it's basicly the same problem.

5)I honestly dont know if stuffing it in a separate folder would work without any further changes, i just want to bring the basic problem to the attention of all addonmakers, so they don't deploy files to arma default folders.

Share this post


Link to post
Share on other sites

I agree with Yoma. It's much easier to "clean up" after a mod/addon if all it's contents is in 1 folder.

..\ArmA\@youraddon\ and what you have in this folder is up to addon creator.

I know most of the addon / mod creators do a great job in doing so, but some still don't.

Last one I saw was the Dynamic Viewdistance addon, which is a great addon for the clients, but uses ..\ArmA\Dta\ folder to store its *.hpp file.

It's not easy to keep track of what every addons installs, when you have tried out 15 different addons and most of those addons have updated serveral times. We had big problems with beta patch 1.11 and 1.12 with figuring out what to delete from ..\ArmA\Addons and ..\ArmA\Dta, but we managed to clean things up and then we would have a stable servere again.

If addon / mod creators just follow the general guidelines on this forum, this would not be an issue.

Best retard NoBrainer

Share this post


Link to post
Share on other sites

Indeed, a good point Yoma gives to discussion and i see the problems that can arise when accessing default arma folders.

As i am not such a experienced addonmaker (just starting) for me one question rises:

How is the file path handled for files that are now in the arma Dta folder if i put them in a mod/dta folder?

Right now \Dta\my_config_file.hpp is the path i'm using as default. How would i refer to the .hpp file by using modfolders which may differ from user to user?

Or might it be a solution to create a new standard folder in the arma root directory, explicitly for such .hpp files? Kind of defining a new standard procedure for these cases?

:EDIT:

I'm working on a new version of the Dynamic viewdistance and i will surely keep in mind this problem. What i need is a solution now.

Share this post


Link to post
Share on other sites
Indeed, a good point Yoma gives to discussion and i see the problems that can arise when accessing default arma folders.

As i am not such a experienced addonmaker (just starting) for me one question rises:

How is the file path handled for files that are now in the arma Dta folder if i put them in a mod/dta folder?

Right now \Dta\my_config_file.hpp is the path i'm using as default. How would i refer to the .hpp file by using modfolders which may differ from user to user?

Or might it be a solution to create a new standard folder in the arma root directory, explicitly for such .hpp files? Kind of defining a new standard procedure for these cases?

:EDIT:

I'm working on a new version of the Dynamic viewdistance and i will surely keep in mind this problem. What i need is a solution now.

This is also part of why i made this thread: experienced modmakers can answer this question, I however cannot.

(I only make nice tools, never even tried making an addon myself) I personally think that if you make a @MODNAME_CFG directory and put it in there it's at least a lot cleaner. If people could reach some kind of standard for this (like a @CFG folder for example that holds all config files), that would be absolutely great to me too.

All i want to avoid is simply putting stuff in default folders, which is and will allways be DIRTY

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×