Locke@Germany

Still those ugly soundbugs, got an audigy with the latest official drivers for XP installed the updated OpenAL blablabla... If i'm running with or without HW Acc. or EAX makes no difference. Upgrading from V1.02 to V1.05 even introduced new sound bugs, like having no weapon sounds from my own gun after respawn or gunshots that sound if they are playing repeatedly in very small inervals out of all speakers at once   I'm very disapointed, i really hoped BIS would fix the sound problems, as these are the biggest atmosphere killers for me. Â

Kinetic energy of bullets has relation with bullets speed. But bullets in ArmA loose its kinetic energy over distance without loosing their speed? I know that BIS has told us that there would be "kinetic energy" but you can easily try it out yourself, i've made a little addon i used for testing. It's simply a soldier with a little script that attaches a camera to the bullet's he fires and gives you the speed of the bullet in m/s and distance from shooter. As you can see, if you try the Addon or already made some similar experiments youself, the bullets don't decelerate, if the flightpath is clear it fly's for 3 sec. with it's v0 and then diapears, i haven't tryed if the timetolive value works for bullets or if it's still hardcoded for simulation = "shotBullet"; like it was in OFP. Locke Test Soldier - Rapidshare Locke Test Soldier - MegaUploads

When comparing OFP's and ArmA's ballistic the only differences i can see are the richochet's and the slight change in trajectory when a bullet has passed through an object. There is no wind that influences long range shoots. Bullets don't loose speed over distance, they don't even loose speed when penetrating an object or richochet of the ground. Apart from the slight change in bullet trajectory the penetration system seem's to be the same as in OFP, objects either let a bullet pass or not, regardless of caliber, material thickness or bullet speed. Â I would have atleast expected that bullet's loose speed over distance, but seeing how little has changed in the physic's department i don't expect any miracles to happen with the next patches. Locke.

Hi, yes i'am aware of this, but you would be still able to click your mouse button faster than you would be able to sqeeze the trigger of a real gun. The two values in the line sound[]={}; are only representing the volume and pitch the sound effect should be played ingame. In current ArmA it is simply not possible to have multiple firingmodes on a weapon and have different reloadtimes for each of them. You can easily try it for yourself by setting the reloadtime of the Single-Mode on your MP5 to a rather high value like 1 sec. or more for testing and you will see that also the burst and full-auto-mode are using this value, regardless of what sound effect or reloadtime settings are used for the other modes. As i said above a good example is the original M134 Minigun mounted on the UH-60. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class M134 : MGun { scope = 2; displayName = $STR_DN_M134; cursor = "\ca\Weapons\Data\w_weapon_mg"; cursorAim = "\ca\Weapons\Data\w_weapon_mg"; showAimCursorInternal = 1; magazines[] = {"2000Rnd_762x51_M134", "4000Rnd_762x51_M134"}; modes[] = {"LowROF", "HighROF"}; canLock = 0; class LowROF : Mode_FullAuto { displayName = $STR_DN_M134_2000; burst = 5; multiplier = 5; reloadTime = 0.022; sound[] = {"\ca\Weapons\Data\Sound\m134loop4_end", 10.0, 1}; soundContinuous = 0; flash = "gunfire"; flashSize = 0.1; recoil = "Empty"; maxLeadSpeed = 600; aiDispersionCoefX = 5; ffMagnitude = 0.5; ffFrequency = 11; ffCount = 6; dispersion = 0.015; minRange = 1; minRangeProbab = 0.1; midRange = 300; midRangeProbab = 0.58; maxRange = 400; maxRangeProbab = 0.04; }; class HighROF : LowROF { displayName = $STR_DN_M134_4000; reloadTime = 0.005; sound[] = {"\ca\Weapons\Data\Sound\m134loop3_end", 10.0, 1}; soundContinuous = 0; showToPlayer = 1; minRange = 1; minRangeProbab = 0.1; midRange = 200; midRangeProbab = 0.58; maxRange = 300; maxRangeProbab = 0.04; }; }; While both modes got different sounds and reloadtimes the first reloadtime is used for both modes, resulting in the same ROF for the "HighROF" and "LowROF". This can be tryed by anyone with a clock, just take the time it takes to fire all ammo in both modes and compare them. As for the MP5 i would like to add that a silenced MP5 with retractable stock but without the burst-mode is called a MP5SD3. While BIS calls the weapon ingame MP5SD6 it could be seen as a realism issue that they did not configured it with a 3-Round burst. Source: Heckler & Koch Website Locke.

Hi, there seems to be a problem in ArmA (V1.01 and V1.02) regarding the weapon configs. If the weapon has multiple firing modes like Single,Burst & Full Auto the reloadtime set in the first firing mode is also used in all other modes. Regardles if there is an entry reloadtime defined for the other modes. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> class Locke_TestM16 : Rifle { scope = 2; value = 0; model = "\ca\weapons\m16_proxy"; optics = 1; displayName = "Test Weapon"; picture = "\CA\weapons\data\equip\w_m16_ca.paa"; UiPicture = "\CA\weapons\data\Ico\i_regular_CA.paa"; drySound[] = {"\ca\Weapons\Data\Sound\M16_cock_v1", 0.000316228, 1}; reloadMagazineSound[] = {"\ca\Weapons\Data\Sound\M16_reload_v1", 0.01, 1}; magazines[] = {"Locke_30Rnd_556x45_Stanag"}; modes[] = {"Locke_Single","Locke_Burst","Locke_FullAuto"}; class Locke_Single : Locke_Mode_SemiAuto { sound[] = {"\ca\Weapons\Data\Sound\AK74_1_SS_A", 10.0, 1}; reloadTime = 0.1; // this is used for all other firing modes, but why ? recoil = "AK74Recoil"; recoilProne = "AK74Recoil"; dispersion = 0.0025; minRange = 2; minRangeProbab = 0.1; midRange = 250; midRangeProbab = 0.7; maxRange = 400; maxRangeProbab = 0.04; }; class Locke_Burst : Locke_Mode_Burst { sound[] = {"\ca\Weapons\Data\Sound\AK74_1_BS_A", 10.0, 1}; reloadTime = 4; // testing only - gets totaly ignored by ArmA ffCount = 3; recoil = "AK74Recoil"; recoilProne = "AK74Recoil"; dispersion = 0.007; minRange = 2; minRangeProbab = 0.1; midRange = 60; midRangeProbab = 0.7; maxRange = 100; maxRangeProbab = 0.05; }; class Locke_FullAuto : Locke_Mode_FullAuto { sound[] = {"\ca\Weapons\Data\Sound\AK74_1_SS_A", 10.0, 1}; reloadTime = 8; // testing only - gets totaly ignored by ArmA ffCount = 30; recoil = "AK74Recoil"; recoilProne = "AK74Recoil"; dispersion = 0.005; minRange = 2; minRangeProbab = 0.1; midRange = 30; midRangeProbab = 0.7; maxRange = 60; maxRangeProbab = 0.05; }; class Library { libTextDesc = $STR_LIB_M16; }; I've come across this bug while working on a weapons & Sound MOD i intend to release in the near future. While most weapons achieve very high rates of fire when set to fully automatic (normaly ranging from 600 up to 800 rounds per minute) a human being in reality is not able to reproduce those high rates by pressing the trigger repeatedly in single fire mode. While limiting the single mode to around 350-400 rpm i noticed that this also influenced the other firing modes aswell, even if they had a different reloadtime defined in their part of the config and where not based on the single fire mode. Furthermore not only Addons seem to be effected but also the original weapons from the game show this strange bug, just try the minigun on the blachhawk and you will notice that the time it takes to empty the 2000 rounds of ammo is the same (around 12sec.) for both firing modes. I've also made a little test addon to showcase this strange effect, the code-sample is from this test addon. Test Addon Download - MEGAUPLOAD Test Addon Download - Rapidshare Sorry if this has already been reported somewhere but for me this is a new entry in the steady growing list of Bug's in ArmA. Locke.

Hi, having a little problem here. In order to not have a giant modfolder I've been trying to make one big Config.cpp and up till now it worked just like in OFP where most info was stored in the main Config. I can assign new recoils & sounds to weapons just fine but i can't change the rate of fire. The value i set in my main Config has no influence at all, it seems to get overwriten by the default reloadtime that is defined in Weapons.pbo. As if there is no access-restriction at all. Â Comming straight from OFP config editing this doesn't seem right and makes me also believe that there is something wrong with "access=x". Locke. Edit: even after not using the predifined firing modes in my weapon-cfg i'am not able to change the rate of fire. AK-74 in main config: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">class AK74 : Rifle { scope = 2; value = 0; dexterity=1.18288; model = "\ca\weapons\AK_74_proxy"; displayName = $STR_DN_AK74; picture = "\CA\weapons\data\equip\w_ak74_ca.paa"; UiPicture = "\CA\weapons\data\Ico\i_regular_CA.paa"; optics = 1; drySound[] = {"\ca\Weapons\Data\Sound\AK47_dry_v1", 0.000316228, 1}; reloadMagazineSound[] = {"\ca\Weapons\Data\Sound\AK47_fill_v3", 0.00562341, 1}; modes[] = {"Single", "Burst", "FullAuto"}; magazines[] = {"30Rnd_545x39_AK"}; class Single { ammo = "Bullet"; recoil = "Locke_RifleRecoil_AK74"; recoilProne = "Locke_RifleRecoil_AK74"; reloadTime = 0.1; dispersion = 0.00075815; multiplier = 1; burst = 1; autoFire=0; displayName = "Single"; sound[] = {"\Locke_ModernSFX\SmallArms\Fire_Rifle_545x39_AK74.wss", 10.0, 1}; soundContinuous=0; ffCount=1; aiRateOfFire=3.32; aiRateOfFireDistance=500; useAction=0; useActionTitle=""; minRange = 2; minRangeProbab = 0.1; midRange = 250; midRangeProbab = 0.7; maxRange = 400; maxRangeProbab = 0.04; showToPlayer = 1; }; class Burst { ammo = "Bullet"; recoil = "Locke_RifleRecoil_AK74"; recoilProne = "Locke_RifleRecoil_AK74"; reloadTime = 2.0; Â Â //Testing dispersion = 0.00112577; multiplier = 1; burst = 3; autoFire=0; displayName = "Burst"; sound[] = {"\Locke_ModernSFX\SmallArms\Fire_Rifle_545x39_AK74_Burst.wss", 10.0, 1}; soundContinuous=0; ffCount = 3; aiRateOfFire=5.000000; aiRateOfFireDistance=500; useAction=0; useActionTitle=""; minRange = 2; minRangeProbab = 0.1; midRange = 60; midRangeProbab = 0.7; maxRange = 100; maxRangeProbab = 0.05; showToPlayer = 0; }; class FullAuto { ammo = "Bullet"; recoil = "Locke_RifleRecoil_AK74"; recoilProne = "Locke_RifleRecoil_AK74"; reloadTime = 2.0; Â //Testing dispersion = 0.00225154; multiplier = 1; burst = 1; autoFire=1; displayName = "Full Auto"; sound[] = {"\Locke_ModernSFX\SmallArms\Fire_Rifle_545x39_AK74.wss", 10.0, 1}; soundContinuous=0; ffCount = 30; aiRateOfFire=0; aiRateOfFireDistance=500; useAction=0; useActionTitle=""; minRange = 2; minRangeProbab = 0.1; midRange = 30; midRangeProbab = 0.7; maxRange = 60; maxRangeProbab = 0.05; showToPlayer = 1; }; class Library { libTextDesc = $STR_LIB_AK74; }; }; everything else works as it should without any error-messages when i start the game with my MOD. My Sound-FX is beeing used, my dispersion values and the custom recoils work ,only firingrate seems to be somehow not changeable or being overwriten by something else. Â Maybe i'm thinking too OFP'ish about the Problem. But how can values in the main config that are access=readonlyverified get overwritten by an addon config ?

the performance impact should be zero ? As i don't have the tools to test i can't say if all these duplicate textures and *.rvmat file's are even used. But if they are used wouldn't this result in a lot of wasted VRAM too and not only wasted Diskspace ? For example: a 3d-Model uses 3 textures A,B and C. Another model uses the textures A,D & E. Let's assume texture D is identical to texture B, just a different name. If these two models are used ingame the VRAM has to load and contain texture A,B,C,D & E instead of A,B,C & E. Wouldn't this result in longer loading times and higher memory consumption ? Locke

Hi, after playing a little bit around with the ArmA pbo's i've noticed that many files seemed to be identical. I've extracted all pbo's in the Addon folder and started comparing the files with doublekiller for their size and CRC. The result is that almost 4000 file's with about 314 MB apear to be totally useles.  A few examples: Air.pbo\AIM9xSidewinder.p3d identical with Air.pbo\Sidewinder_proxy.p3d Air.pbo\Data\Anim\Mi17_Cargo02_V2.rtm identical with  Air.pbo\Data\Anim\Mi17_Cargo02_V6.rtm The file Sara.pbo\Data\Layers\m_000_000_lco.paa has almost 1200 copy's in the same folder, from m_000_001_lco.paa to m_042_042_lco.paa, resulting in 1171 file's with a total size of 195 MB that ALL HAVE THE SAME CONTENT. I would be happy if BIS would remove the identical file's in future Updates, as i don't think it helps the performance of a game that already is very hardware demanding. Locke.

I think it's only a Config error. In OFP there where two entry's in the Ammo-Class that defined the Tracers. Example: tracerColor[]={0.700000,0.700000,0.500000,0.040000}; tracerColorR[]={0,0,0,0}; The second one was being used when tracer's where switched off. Â Wanna bet these two lines (if still there) contain the same values in ArmA. So to answer your question: either wait for an official patch or use the do it yourself method and change the config.bin. If the syntax is still the same as in OFP you just need to change the tracerColorR entry. btw: I can't believe such thing's (and many others) where not recognized while beta testing the game ( Somehow i'm beginning to doubt if it was tested at all) Locke.

ArmA release is more and more becomming a big disapointment. Makes me sad and angry to read about bugs in ArmA that i know from OFP for years.

Bullet's still don't loose speed over distance ? Makes me wonder how a bullet in ArmA looses it's kinetic energy. Locke.

Hi, just saw the four small clip's and instantly fell in love with the swimming possibility  . However the building destruction could be improved alot, i remember the old Comanche series of Arcade-Helo-Games from Novalogic and Delta Force had something wich looked quite good for the time it was released. If i remeber correctly the building started to collaps more slowly and there was alot of smoke and dust, so you couldn't see that the building actually was slowly sinking into the ground and was then replaced with some destructed model. In comparision to this the destruction-sequence of the building in the video seem's much to fast, as if it had no mass at all. While not really great it's still a very huge gameplay improvement over OFP. Hope the AI will also be able to use this to their advantage, meaning: If an enemy (squad) is hidden in a building ,the building itself does not represent any tactical important installation and heavy weapons that could destroy the building are available, instead of cleaning the building room by room they just destroy the whole building. Bye, Locke.

AFAIK they are allready binarized.

Hi, nice campaign so far. But it seems i've got some problems in the "Last Stand" - Mission, orders are simple: defend the evac zone until all NATO personal has left the island... . I've fought of the first wave and began retreating to the minefield, under heavy fire from advancing enemy units i made my way down to Modrava. Once reaching the outer limits of the city i'm getting told that there are only 10 minutes left until the last evac leaves, shortly before i reach the evac-zone another message tells me that i should go to the evac-zone now or it would be too late. Â But once i've reached that spot i can wait for ever and no damn chopper comes to pick me up, there's also no other message that it is already to late and they left without me, i could just wait there forever. Â Â

Thanks for this great surprise.