General Barron

I had another idea: what if you put a non-existent addon in the "requiredAddons" field? It would throw an error message, but I *think* the addon still loads. In this case, I would assume the engine would have to wait until the very end in order to load it? It would be dirty, but it could work. ----- Okay, I'm about to go off of andersson's original topic and start pursuing UNN's topic: Can you please expand on this? Do you mean, you can get values back from the game in real-time? Can you give some examples? Then this test would return true, even though it's been passed a nil value from a script. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#IfDef MYVALUE Okay, you seem to have a misunderstanding of what #define is. #define does a find and replace operation in your config. Nothing more. It does not do any sort of code evaluation, any sort of config evaluation, or anything. All it does is a find/replace operation. #ifdef only checks if something has been #defined, it doesn't care what it has been defined as. Even this will still result in #ifdef evaluating as true: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">#define SOMETHING #ifdef SOMETHING //this point will be reached #endif Preprocessor directives can NOT be used to do any form of runtime evaluation, they are ONLY used for find, replace, and paste operations. What exactly are you after? Are you trying to change addonA's config depending on whether addonB is loaded? In that case, why not just overwrite / modify addonA's classes, inside of the config of addonB? If this is for scripting purposes, then there are many easy solutions. For my handsignals system in OFP, I had checks to see if the voices pbo was loaded or not. I'm sure you can think of many ways to do this as well.

You also need a config for your ruins model, otherwise the engine doesn't know what to do with the model. The class MUST be land_(modelname). So, in your case, the classname MUST be "land_OWP_CB_b1_ruins". Just configure the ruins like any other building, but it MUST use the classname above!

I came across this in the biki: Anyway, I guess all I'm pointing out here is that a different process handles EXEC macros vs handling #include #define / etc. I don't know if that is in any way relevant to the discussion here.

Hmm... I have no idea, I've never seen your debugging methods. I didn't even know you could use __EXEC in un-RAPified configs. I do see a possible flaw in your assumptions though. You are assuming that the config is preprocessed--meaning, all defines and macros are expanded--at the same time that it is merged into memory. I don't see how this could be possible. The defines and macros can change things such as the requiredAddons, for example, so I'd think they MUST be parsed in a step BEFORE addon load order is determined. For example, if I write: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #define MYADDONS {CA_core} class cfgPatches { class myaddon { requiredAddons[] = MYADDONS; ..... Then in this case, the preprocessor MUST be run over the config to process that #define, BEFORE the engine can read the requiredAddons[] section, so that it can determine whether or not to merge the config into memory.

Hmm... no I must not have been clear. What I'm saying, is that the engine won't load an addon (i.e. read it's config into memory) until all its requiredAddons have been loaded. So if addonA requires addonZ, then addonA will ALWAYS be loaded AFTER addonZ, no matter what the order of modfolders or pbo names for the addons are. Now, in the above example, addonZ might require addonX and addonY. So before addonZ loads, it needs to wait for addonX and addonY to load. But those addons will require other addons, which require other addons, etc etc. If all the above addons are trying to overwrite the same property in the same class, then addon load order makes a HUGE difference. If mod folders determined addon load order, then you would be able to force addonA to load BEFORE addonX, Y, and Z, simply by putting them in different folders. But this is not the case, as seen in andersson's example. His addon was trying to overwrite the same properties as NWD's addon, but no matter where his addon was in a mod folder, NWD's always was loaded after his. That is what I mean when I say: The only time when other factors come into play (mod folder order and pbo name) is when the requiredAddons[] section holds the same addons (doesn't have to be the same order though). In this case, both addons can be loaded at the same time, because their requiredAddons are all loaded at the same time, because they are identical. When this happens, *something* has to determine the order, which could be mod folder ordering, pbo name, or something "random" relating to the name/ordering of pbos in your addon folder. Basically, if both addons have the same requiredAddons, then load order is just determined by which addons the engine runs into next after it has loaded all the requiredAddons. This depends on where the engine is in the addons folder when it finishes loading the required addons.

I didn't say this! It influences the order, but does not set it 100%. Here is the easiest way for me to explain it. I don'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\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'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'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'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'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'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't have all the requiredAddons[] loaded yet. raedor was correct in the thread you linked to. ONLY if two pbo'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'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't HAVE to put them in "requiredAddons"; everything will still work fine IF you have those addons installed. However, if you DON'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'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'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'S addon? Well, obviously you can't. Everyone else has access to the same tools you do, so you aren't special and you can't do that. The best you can do is fill your requiredAddons[] with all of the BIS addons, and hope that everyone else doesn't start doing the same thing.

The mk19 and the AGS both fire ammunition with simulation="shotShell". So this means they use the tank firing effect when they fire. The tank firing effect is controlled by two things: -the property "fireEffect" in the vehicle config controls the shock-dust effect (set it to "" to disable it) -the "GunFire" class in the vehicle's turret controls the muzzle particle effects. Try changing this to be the same as the "MGunClouds" class from other vehicles ("MGunClouds" is used when firing bullets, or weapons with shotFromTurret=false) A better solution would be to change the ammunition instead of the vehicles. You need to change the weapons so that they use ammo which has simulation="shotBullet", instead of "shotShell". I'd recommend making new ammo instead of changing the existing ammo. The existing ammo is also used by hand-held grenade launchers like the m203, so changing it will mess up those weapons.

I'm not trying to be rude, but I have to ask: what makes you think you are controlling the load order? What if "people's" assumptions about this are incorrect? Addon load order is PRIMARILY determined by the requiredAddons[] field of the addon'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'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'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'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[] = {"CAweapons", "CAweapons3", "AA10"}; 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[] = {"CAWeapons"}; 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.

Common practice is to write define values all uppercase. 2) Assign the new config value a value with your define in your external config file. 3) You can read the config values with these: http://community.bistudio.com/wiki/getText_config - See also part. Like No no no! You don't need to do that! You can use #defines in scripts, just like you can in configs. So, all you have to do, is move your #defines to a different file from your config and scripts. Then you #include that file in BOTH your config, and your scripts. So now all files get the same defines. This way, you only have to edit one file, rather than many. This also means you don't have to have the script read from configs, which makes it faster and also can reduce bugs. I use this all the time with dialogs. You can use #defines for the IDCs, and use those same defines in your scripts. That way you don't have a bunch of hard-coded numbers in your scripts where you don't really know what they refer to. I'll give you an example: myheader.hpp: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #define SOMETHING 1 #define SOMETHINGELSE 2 //...and so on config.cpp: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #include "myheader.hpp" //continue with your config, using the #defines from "myheader.hpp" myscript.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #include "myheader.hpp" //continue with your script, using the #defines from "myheader.hpp" ---------------------------- In your case, you want the #include file to be external to your pbo, which holds the config and the scripts. To do this, put a \ in front of your path. For example: #include "\myheader.hpp" This will look for "myheader.hpp" in the SAME FOLDER as your arma.exe. #include "\somefolder\myheader.hpp" This will start in your arma.exe directory, then go into the folder "somefolder", then look for the file "myheader.hpp" ----------------------- Unfortunately, this is not so easy. If you try to #include a file that doesn't exist, the game will crash. And there is no way to test for the presence of a file before issuing the #include statement. As far as configs go, there is no way to make 'dynamic configs' that I know about. The values are "set in stone" the moment arma is loaded. Scripts are obviously much different and can easily be changed on the fly, but I'm not sure if you can check for a file's existence (via loadfile / preprocessfile) without an error popping up. ------------------- If you are feeling experimental, I do know that it is possible to use variables in description.ext resources. The same might be true for configs. An example line in description.ext: height = @myvar; In this case, the game will read the value of the global variable "myvar" and use it as the height. In this way you can change cut resources dynamically. I do not know if this works for configs as well.

#defines, #includes, and other stuff with # in front of it is what is called a "preprocessor instruction". The preprocessor is run over your config before it is loaded into the game (either by the cfgConvert tool when making the pbo, or else by the engine when loading the pbo). Basically, the preprocessor takes your file, does some stuff to it, then hands the modified file to the game. So the game has no idea about any of those preprocessor instructions, as they aren't saved anywhere. Think of the preprocessor as a big find/replace/cut/paste program that runs on your file, before the file is handed to the game. In your case, it first finds the #include, and pastes the file "\dta\DMSmokeEffects_config.hpp" into your config where the #include is. For #defines, the preprocessor just does a find/replace in the file. In your example, the preprocessor finds "DMSmoke_Lifetime_Particle" and replaces it with "0.3". You can also use the preprocessor on scripts. So you can #include that exact same file into your scripts that you are #including into your config. Then all the #defines will work in your scripts as well. Note that the #included file MUST BE PRESENT in your pbo for this to work! Note this only works if you use the "preprocessfile" or "execVM" instructions (NOT with exec or loadfile). You already have been using the preprocessor in your scripts if you have any comments (// or /*) in them.

The footstep sounds must be pointed to in the cfgSurfaces for the map. So, CWR Winter Kolgujev must use "snow" and "forest" in the configs for their surfaces, or else the engine won't know when to use your footstep sounds.

I doubt it. It isn't a problem of communication, it's a problem of fire and maneuver. A single fireteam simply cannot do much on its own compared to a squad or really a platoon. A platoon can have one squad lay down fire to suppress the enemy, have one squad maneuver around the flanks to assault thru, and have one squad in reserve providing rear security. A fireteam can't really separate like that because then they'd be breaking down into individuals, or "lone wolfs". That brings us back to the topic at hand, why lone wolfs in video games, but not reality? I think there are many reasons for this, many of which have been covered. In short, I think the problems are: 1) Goals of gamers are not the same as goals of RL combatants ("fun" in relatively short time vs mission accomplishment / survival; unrealistic / "gamey" situations & objectives (eg, CTF, "kill everyone") vs complex, real world ones (eg: large amounts of combatants, strategic objectives other than "kill everyone") 2) Rules of game are not the same as in RL (due to limitations of the program and of modern computers in general) 3) Individuals connecting on public servers often do not have the desire or ability to act as a team These 3 points cover a whole lot of ground but I won't elaborate on them.

IIRC, string comparison like this should be case INsensitive: "blah" == "BLAH" -> result is true String comparison inside of arrays should be case SENSITIVE: "blah" in ["BLAH"] -> result is false Another trick you might try is to compare class data types, instead of strings. For example: (configFile >> "cfgMagazines" >> "blah") == (configFile >> "cfgMagazines" >> "BLAH") -> result should be true? Hope that helps, GB

Interesting... this is starting to make more sense. reloadtime | fps | rpm | sec/rnd | sec/frame | frames/rnd 0.075 | 80 | 800 | 0.075 | 0.0125 | 6 0.075 | 50 | 750 | 0.08 | 0.02 | 4 It looks to me like the end result is that the engine works with frames per round (the number of frames to skip between firing each round), but it can't work with fractions of a frame. So in this example, the reason why at 50 fps, you only get 750 rpm, is because if it skipped one less frame between rounds, then the rate of fire would be above the desired 800rpm. It doesn't seem to be able to work with something like "4.5 frames / round", which would mean: "skip 5 frames, fire, skip 4 frames, fire, etc". ------ This is basically what NWD was getting at, only with data to back it up. So basically, it seems that you can only set a specific rate of fire for a specific frame rate. Meaning, your mod would only work 100% for people with ~80fps; anything below that and the rates of fire begin slowing. At ~17fps you only get ~60% of the desired rate of fire. I've used some data modeling to get an equation that sets the rate of fire for weapons, but it was based on my ~20fps machine. So that means, people running higher FPS would end up getting rates of fire HIGHER than intended. It seems to stay accurate at 30-40 fps, but I suspect it would break down badly at 50-80 fps. Hopefully the engine will get fixed so that the ROF no longer depends on frame rate!

Okay, now I'm really interested. NWD, what you are saying would make sense. I'd still be interested in hearing what results other people are getting, and especially knowing what their frame rates were. I just ran a quick test on another machine, which gets higher fps than mine. I used a couple specially configured weapons. The second one I fired into the air, resulting in a higher framerate. Here were my results: FPS | reloadtime | theoretical rpm | actual rpm ~38 0.070876 846 ~650 ~45 0.064811 925 ~750 So, even at ~45 fps, I was still getting only 80% of the theoretical rate of fire. The funny thing is, with other weapons on the same machine, it IS possible for me to get 925+rpm. Basically, I'm wondering: how many FPS do you need in order to get the theoretical / maximum RPM? I guess it isn't a simple answer, since it might depend on both the frame rate, and the intended rof of your weapon, and whether they divide evenly into each other. But I would be curious to know what kind of frame rates get accurate rates of fire for which weapons. Q1184, what is your frame rate?

Yeah, to adjust the rate of fire on the m240, you have to take it apart and move the gas regulator to a different hole. --- My system is getting 17 fps, and my m240 is shooting at ~500rpm. What FPS do you have, Q1184? Theoretically my max rate of fire should be 17*60=1020rpm, well below the 750 rpm that Q1184 is getting. So the correlation between FPS and ROF isn't quite so simple... I'd be very interested to see others post their ROF and FPS.

Is this a fact, or an assumption? My observations are that the rates of fire for the weapons on my computer are NOT the same as what Q1184 gets on his. Maybe I made a mistake collecting my data. Or maybe it depends on the user's system, and mine just gives me lower rates of fire. It would be interesting for others to follow the steps I gave above, and to post their results.

1) Shoot entire magazine 2) Count how many seconds it takes 3) Divide 60 by the result of #2 4) Multiply result of #3 by the number of rounds in the magazine For example: It takes me 12 seconds to fire the full 100 round magazine of the m240. 60/12*100 = 500 rounds per minute I do realize ROF is limited by the framerate of the machine, however. I would be interested to see the rates of fire that others got, as well as their framerates.

Are you sure your rates of fire are accurate? I'm getting ~500 rpm for the m240, when it should be 650-750 or 950-1000 (depending on the position of the gas regulator) from the data I see. For the m249, I'm getting ~600 rpm when it should be 750 or 1000. For the M4, I'm getting ~515 rpm when it should be 700-950. Perhaps it is due to my low framerate? What rates of fire are others getting?

I think this should be made into a sticky.

Thanks for the heads-up, however, I'm not sure exactly what the definition of "initialized" is here. Will there be new scripting commands to declare/initialize a variable? Or do you just have to store a value in a variable first, as in _variable = 1? I would assume the latter, but I just want to be 100% sure I understand.

Okay, this is getting out of hand. bis forum == players forum players != developers You do not have to be a programmer in order to critique a game. The point of a game is entertainment. Anyone can critique whether something is entertaining to them or not. OPINION: I find it entertaining to fight opponents that take cover and use suppressing fire. I do not think the ArmA AI does that very well or at all. That is what this thread is about. As a player, I don't care whether it would be hard or easy to implement (just like I don't care how easy/hard normal-mapping, or hdr, or whatever was to implement), I just think it would make the game better. If others do NOT find that entertaining, or if they think the AI really DOES do that, then that is a worthwhile comment to make. But to put someone down because of their opinion, or to say "let's see you do better", is not very constructive.

I love OFP/ArmA/BIS as much as the next guy, but I do sense a bit of blind-loyalty to them here. I think liljb15 makes excellent points, which of course have also been raised by other ArmA/OFP players in the past. I completely agree with what he, and others supporting him, have been saying. Why did someone have to write a *script* so that the "unscripted AI" would use suppressive fire (a fundamental component of warfare)? It isn't a heresy to criticize the AI.

WinPBO for OFP had a pbo patching utility. I never used it though so I don't know how it works. I believe there is a newer utility for ArmA pbo's that has the same capability. If you wanna get really tricky, perhaps you could try using the #include statement to reference a file outside of the pbo? You'd have to leave the config as a .cpp though, if that is possible. I do remember that one mod for OFP left all their configs/sounds/etc in external files so that you could easily edit/patch them (was a WWII mod... can't remember which one).

#1 is the answer to #2. The "56..." is the "db" level of the sound. It doesn't adjust how loud the sound file is played. Instead, it adjusts how FAR AWAY the sound is heard, and if you can hear it compared to other sounds. For example, you are standing next to a truck. It's engine sound is DB+10. You fire your rifle. It's fire sound id DB+50. You will hear the rifle because it's DB is louder. So, in short: to make the sound louder thru your speakers, change the volume of the sound file. To make the sound heard from farther away, or louder compared to other sounds, change the DB value ("56...").