Page 1 of 3 123 LastLast
Results 1 to 10 of 30

  Click here to go to the first Developer post in this thread.  

Thread: Overwriting configs.

  1. #1
    Can someone explain this?

    I'm trying to change some small bits here and there. F.ex I tried to change the magasines for the AKS74U and the AKS74UN.

    For some reason I couldnt change the mags for AKS74UN. AKS74U's magasines changed to whatever I wanted, I could change whatever I wanted for the AKS74UN except the magasines...
    So I started digging in my addonfolders, disabling and activating until I found the problem. It was NWD_Ballistics.pbo.

    I opened up that config and this is the part:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">...more code
    class AKS74U &#58; AK74
    {
    distanceZoomMin = 228; // Real gun has flip-up sights for 200 or 400 m.
    distanceZoomMax = 228; // Model has sights set to 400 m, but that&#39;s stupid.
    };
    class AKS74UN &#58; AKS74U
    {
    magazines&#91;&#93; = {
    &#34;30Rnd_545x39_AKSD&#34;, &#34;30Rnd_545x39_AK&#34;
    };
    distanceZoomMin = 110;
    distanceZoomMax = 110;
    };
    class G36a &#58; Rifle
    {
    distanceZoomMin = 236; // adjusted for 2.5 inch &#40;?&#41; scope height
    distanceZoomMax = 236; // zeroed to 200 m
    };
    ...more code[/QUOTE]

    I cant see any wrong with that..

    My config:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgPatches
    {
    class andy_fixes
    {
    units&#91;&#93; = {};
    weapons&#91;&#93; = {};
    requiredVersion = 1.09.5208;
    requiredAddons&#91;&#93; = {&#34;CAWeapons&#34;};
    };
    };
    class CfgWeapons
    {
    class ak74;
    class AKS74U &#58; AK74
    {
    magazines&#91;&#93; = {&#34;30Rnd_545x39_AK&#34;};
    };
    class AKS74UN &#58; AKS74U
    {
    magazines&#91;&#93; = {&#34;30Rnd_545x39_AKSD&#34;};
    };
    };
    [/QUOTE]

    I cant see any wrong with that either.. And my addon works when I disable NWD_Ballistics.pbo.

    Now to the point, why isnt my addon overwriting his? My addon is in a modfolder after NWD_Ballistics.pbo.
    And it doesnt matter if I load mine before or after..

    How can another addon make all attempts to change the same values no-go? I can change whatever I want for the AKS74UN except the magasines..
    \"Det är bara att placera den ena foten framför den andra och upprepa det tills man har kommit fram\"
    Ltn Vuorensola

  2. #2
    This is indeed strange.

    Try to add "NWD_Ballistics" to your requiredAddons definition.
    Makes your addon defendant to _Ballistics.pbo, it should be a
    problem in your case.

  3. #3
    Yes, thank you. It did solve my problem.

    But this is not good... It work for me as I am fixing my arma because of small errors/compability-issues in addons here and there, so its ok that my addon is dependant.

    There must be some logic behind this, if not its very nasty. Making addons behave different depending on what addons are used no matter loadorder.
    This can explain people having doubt in loadorder.

    I hope I missed something somewhere, but I doubt it.

    I also found another addon, TrueInGameUI v1.1.pbo, that I cant change with another, later loaded, addon.


    (An explanation on what I&#39;m doing maybe. I&#39;m fixing small bugs and making all addons compatible with each other in my addon-collection by making an addon that are loaded at the end that will overwrite some values. This works very good, except for those two cases.. One example; RHS-weapons now uses FDF-sounds (or whatever soundpack active) and six_tracers and the AWM recoil is also fixed. This is without changing the original addons. This is for my own private SP-game)


    edit: It didnt help to add "TrueInGameUI" to make my change overwrite TrueInGameUI v1.1.pbo... It worked with NWD_Ballistics..

    From TrueInGameUI:
    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">more code...
    class Ammo &#58; RscIGText {
    style = 0x01 + 0x100;
    y = 0.001;
    idc = 0;
    text = &#34;&#34;;
    };
    more code...[/QUOTE]

    My config loaded after:<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class CfgPatches
    {
    class andy_fixes
    {
    units&#91;&#93; = {};
    weapons&#91;&#93; = {};
    requiredVersion = 1.09.5208;
    requiredAddons&#91;&#93; = {&#34;CAWeapons&#34;,&#34;NWD_Ballistics&#34;,&#34 ;CAUI&#34;, &#34;CAFonts&#34;, &#34;CAData&#34;, &#34;CA_Anims_Char&#34;,&#34;TrueInGameUI&#34;} ;
    };
    };
    class CfgWeapons
    {
    class ak74;
    class AKS74U &#58; AK74
    {
    magazines&#91;&#93; = {&#34;30Rnd_545x39_AK&#34;};
    };
    class AKS74UN &#58; AKS74U
    {
    magazines&#91;&#93; = {&#34;30Rnd_545x39_AKSD&#34;};
    };
    };
    class RscIGText;
    class RscInGameUI
    {
    class RscUnitInfoSoldier
    {
    class Ammo &#58; RscIGText
    {
    style = 0x01 + 0x100;
    y = 0.001;
    // idc = 0;
    // text = &#34;&#34;;
    };
    };
    };[/QUOTE]

    If I do that small change in TrueInGameUI I can see my ammocounter. If I try to load over that setting from my, later loaded, addon nothing happens even if I add that addon into required addons (you can also see that I put all that addons dependencies into my addon just to make sure. I tried with only "TrueInGameUI" and "CAUI" first)


    I must be doing something wrong here....




  4. #4
    This one is a fault on your side.
    By commenting code, you don&#39;t make that change undone
    somewhere else.
    You have to overwrite the value again with the desired (default)
    values.

    The first example is strange indeed.

    You can try to add the weapon classes you modify to the
    weapons[]. However as far as I know, you only need to add cfgWeapon classes in there, if you create new classes and want
    the editor detect these correctly and write the cfgPatches class
    in the addons(Auto) array of the mission.sqm.

  5. #5
    Quote Originally Posted by (Q @ Feb. 24 2008,17:59)
    This one is a fault on your side.
    Haha
    Stupid me.. I see that now

    But yes, the other example is strange..

  6. #6
    Quote Originally Posted by [b
    Quote[/b] ]There must be some logic behind this, if not its very nasty. Making addons behave different depending on what addons are used no matter loadorder.
    This can explain people having doubt in loadorder.
    I&#39;m not trying to be rude, but I have to ask: what makes you think you are controlling the load order? What if "people&#39;s" assumptions about this are incorrect?

    Addon load order is PRIMARILY determined by the requiredAddons[] field of the addon&#39;s cfgPatches section, regardless of the "order" of modfolders or addon names.

    If there are two addons with exactly the same requiredAddons[], then this is really the only time when addon name determines the order of loading. I&#39;m not sure if modfolder order in the shortcut have any effect on this as well.

    One simple way to check the order of addons modifying the same class is by looking into your arma.rpt file after loading the game.


    If this weren&#39;t true, you would have a hell of a time using mod folders, because you would have to know the dependencies of every single addon, plus their dependencies, and you&#39;d have to make sure they are all put in the correct mod folders, loaded in the correct order, etc etc. The whole point of requiredAddons[] is so this load order is done automatically for you, by the engine.


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


    I have v1.16 of nwd_ballistics.pbo here, and this is the requiredAddons section:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">requiredAddons&#91;&#93; = {&#34;CAweapons&#34;, &#34;CAweapons3&#34;, &#34;AA10&#34;};[/QUOTE]

    Here is your requiredAddons section:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">requiredAddons&#91;&#93; = {&#34;CAWeapons&#34;};[/QUOTE]

    NWD_ballistics.pbo requires more addons than yours does. So, after CAWeapons is loaded, your addon loads, while NWD_ballistics.pbo is still waiting for CAweapons3 and AA10 to be loaded. So yours is always loaded before his.



    HANDSIGNALS COMMAND SYSTEM-- A realistic squad-control modification for OFP

  7. #7
    Quote Originally Posted by [b
    Quote[/b] ]Addon load order is PRIMARILY determined by the requiredAddons[] field of the addon&#39;s cfgPatches section, regardless of the "order" of modfolders or addon names.
    I&#39;m not sure thats correct, at least in some cases. I tested the idea out using some config debug techniques.

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">__EXEC &#40;LoadFile &#34;Addon A&#34;&#41;;[/QUOTE]

    It&#39;s just a simple test, so it only reports the first addon config to be compiled. To determine the order of all the addons you would have to expand the code.

    I made three addons, AddonOrderA.pbo,AddonOrderB.pbo and AddonOrderC.pbo. Each one reporting a message. Initially there were no required addons, the load order was by pbo name. So AddonOrderA.pbo was the first to display the message. When I renamed the pbo to AddonOrderD.pbo, B became the first to report back.

    Using this assumption I removed the debug message from AddonOrderA.pbo and added this to the required addons entry:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">RequiredAddons&#91;&#93;={&#34;AddonOrde rC&#34;,&#34;AddonOrderB&#34;};[/QUOTE]

    Despite C taking precedent, addon B was the first to display the message.

    I must admit I was surprised when you said requiredAddons field sets the order. I would have imagined that Arma reads all the available configs into memory first, before processing them? The required addons part falls under processing and is only checked once all the configs are in memory e.t.c If that is the case, then it’s down to the order configs are initially loaded into memory.

    Like I said it was a quick test and may not apply to andersson&#39;s problem. But how the configs are compiled is still an interesting topic on it&#39;s own.

  8. #8
    As I understand this the general assumption is that Modfolder priority is what matters. But I guess thats not the whole thruth after General Barron&#39;s input.

    Quote Originally Posted by (General Barron @ Feb. 25 2008,01:05)
    Addon load order is PRIMARILY determined by the requiredAddons[] field of the addon&#39;s cfgPatches section, regardless of the "order" of modfolders or addon names.

    If there are two addons with exactly the same requiredAddons[], then this is really the only time when addon name determines the order of loading. I&#39;m not sure if modfolder order in the shortcut have any effect on this as well.
    I&#39;m not 100% sure of this, but I believe I experience different result depending on which order I load my modfolders (same way as in Oblivion). But I have to do some testing to take it as a truth..
    But if I understand you right there is no way to change addons loadorder except from altering them? So all addons I download have a loadorder that is totally dependent on what the authors put into requiredAddons[], and the modfolders is only used to have order and to more easilly load/not load certain addons?
    If so then thats really bad news for me..

    If load order is PRIMARILY determined by the requiredAddons[], what is the secondary?

    Quote Originally Posted by (General Barron @ Feb. 25 2008,01:05)
    The whole point of requiredAddons[] is so this load order is done automatically for you, by the engine.
    I thought that the reason for that was, in some way, tell the engine what earlier loaded configs is relevant to the config loaded right now. But I dont know, thats what I thought.

    If what you say is true then if I put all BI addons into requiredAddons[] I make sure my addon is loaded last and will overwrite all other configs?

    Quote Originally Posted by (UNN @ Feb. 25 2008,08:36)
    Like I said it was a quick test and may not apply to andersson&#39;s problem. But how the configs are compiled is still an interesting topic on it&#39;s own.
    My problem is not that interesting anymore as that will be solved when I understand how the config works. The compilation is a very interesting AND important topic. All the badly done configs that are in addons.. Addonmakers need to know more about this.

    Quote Originally Posted by (General Barron @ Feb. 25 2008,01:05)
    I&#39;m not trying to be rude, ..
    I dont take you as rude, I&#39;m glad for your input. I hope you dont take me as rude/negative as I try to understand this. Its a discussion I hope will shed some light over this.


    edit: did a quick test with loadorder. I put the modfolder that I have my addon in to load before the modfolder with NWD_Ballistic.pbo. IF the loadorder matters NWD_Ballistic.pbo should overwrite my config and I would be able to load the AKS74UN with non-SD mags.
    Result, I couldnt. The loadorder in this case didnt matter.

    For information; My requiredAddons[] isnt like the example above, I have more addons there now. But this still shows that only loadorder (a&#39;la Oblivion) isnt enough.




  9. #9
    Quote Originally Posted by [b
    Quote[/b] ]I must admit I was surprised when you said requiredAddons field sets the order.
    I didn&#39;t say this&#33; It influences the order, but does not set it 100%.

    Here is the easiest way for me to explain it. I don&#39;t know if this is how the engine handles things internally, but the end result is the same:

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

    Take a simple example, where all addons are in one folder.

    1) When loading, the engine first loads the config from dta&#92;bin.

    2) Next, the engine grabs the first addon (in alphabetical order) from the addons folder.

    3) The engine checks the requiredAddons[] section of that addon&#39;s cfgPatches.

    4) IF all the addons listed in requiredAddons[] have already been loaded,

    5) THEN the engine adds the cfgPatches classname to its list of addons that have been loaded, and merges the addon&#39;s config into memory. If this addon uses classes that already exist in memory, they are modified/overwritten in memory at this stage. Also, if the addon relies on an external class that doesn&#39;t yet exist in memory, problems can arise at this stage.

    6) ELSE the engine ignores the addon, moves on to the next addon (in alphabetical order), and goes back to step #3.

    7) Once the engine hits the end of the addons folder, it loops back to the top of the addons folder and repeats the process, ignoring addons that have already been loaded.

    8) The engine keeps looping thru the folder until all pbo&#39;s have been loaded.

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

    This process will always load every addon, unless you have two addons that require each other. In this case, the engine throws you an error and won&#39;t load ("circular dependency").

    If you want to throw mod folders into the mix,, use the same process but assume that the engine loops thru the default addon folder first, then the first mod folder, then the second mod folder, etc.

    Basically, this means that you can force the engine to look at addon ZZZ.pbo before it looks at addon AAA.pbo, by putting them in different mod folders. It will still skip over an addon, regardless of folder, if it doesn&#39;t have all the requiredAddons[] loaded yet.

    raedor was correct in the thread you linked to. ONLY if two pbo&#39;s have the SAME requiredAddons[] section will the mod folder order (and/or alphabetical order) matter. The LAST loaded pbo takes priority in this case.

    Notice that the ORDER of requiredAddons[] doesn&#39;t matter, only the CONTENT.

    Also, notice that the requiredAddons[] only "has" to be used for configs. What I mean is, if your addon requires models or sounds or scripts from another addon, you don&#39;t HAVE to put them in "requiredAddons"; everything will still work fine IF you have those addons installed. However, if you DON&#39;T have those addons, your game will crash, so it is best practice to put them in requiredAddons[] as well, to prevent such errors.

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

    This may sound like a complicated process, but it is really quite simple. You are right though, most addon makers don&#39;t use the system properly, or even understand it. Really the only rule you need is this:

    In your requiredAddons[] section, put the cfgPatches class of EVERY PBO that you use ANY resource from. This includes classes, textures, sounds, models, and anything else.

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

    The only problem arises when you are trying to cater for 3rd party content.

    How do you handle things when you have 5 addons all trying to modify the same class? Easily if you know what those addons are.

    But how do you handle it when you can&#39;t predict what those addons will be, because they may not exist yet or be created by you?

    Basically, how do you make YOUR addon take priority over EVERYBODY ELSE&#39;S addon?

    Well, obviously you can&#39;t. Everyone else has access to the same tools you do, so you aren&#39;t special and you can&#39;t do that.

    The best you can do is fill your requiredAddons[] with all of the BIS addons, and hope that everyone else doesn&#39;t start doing the same thing.




  10. #10
    Thank you very much, that indeed explained alot and put all the bits and pieces together&#33;

    So modfolders do affect the end-result in a limited way, but requiredaddons[] is the clue.

    Quote Originally Posted by (General Barron @ Feb. 26 2008,00:14)
    -----------------

    The only problem arises when you are trying to cater for 3rd party content.

    How do you handle things when you have 5 addons all trying to modify the same class? Easily if you know what those addons are.

    But how do you handle it when you can&#39;t predict what those addons will be, because they may not exist yet or be created by you?

    Basically, how do you make YOUR addon take priority over EVERYBODY ELSE&#39;S addon?

    Well, obviously you can&#39;t. Everyone else has access to the same tools you do, so you aren&#39;t special and you can&#39;t do that.

    The best you can do is fill your requiredAddons[] with all of the BIS addons, and hope that everyone else doesn&#39;t start doing the same thing.
    This is a problem yes.. Not for me with my "fix-it-addon" as I can open up and do whatever necessary. But from a community perspective this can be a problem..

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •