gmJamez

Hi again, just a few comments/tips: - First of all thanks for the offer to get me a graphics card - much appreciated It's not a money issue though... - Don't put the pbo into ArmA's Addon directory but instead either always keep the directory structure as it is within the zip file or put the files wherever you like and adjust the paths within SightAdjustmentConfig.h and possibly also within config.cpp (if you don't you'll get errors like sound file not found, file too short,...). Best just keep it as it is within the zip - If the supplied keycodes don't work for you or you wish to use different ones -> see page 12 of this thread for an explanation on how to get this mod to report the codes for every key pressed. - Regarding the "mind of it's own" feature Are you sure you got only one copy of the mod installed? It sure sounds like there's two instances running... eg. don't install the standalone version of the SighAdjustment mod if it's already included within another one. regards, Oliver.

Hi all, in case you were wondering why there haven't been any updates anymore: I fried my graphics card - a 8800 GTS - and used the current situation of not having a decent graphics card to quit gaming altogether. To all modders, you may use this code in any way you want - go crazy Also, many thanks to Solus for the extended init handler! greets, Oliver.

I've added the version 0.4beta to the first post - now featuring an ingame range card Two sample range cards (M24, M4SPR) are included, however keep in mind that the setup will vary depending on the kind of mods you've loaded. An explanation on how to create your own range card can be found within the first post as well (no modding skills required - all you need is notepad). Also, since 0.3beta seems to work well, it's linked as latest stable version. Enjoy! PS: Unfortunately I've had no luck with the XAM incompatibility yet - it seems the init function just isn't being called

Preview of the range card: The data is loaded dynamically, ie. it's loaded from files outside of the pbo, so the data can be edited easily (all you need is notepad) and will be reloaded even without restarting the game.

First of all - you're using an outdated version of this mod. Secondly - it seems you're trying to switch to a WASD layout. If so, get the latest version and change the key-configuration within "SightAdjustmentConfig.h". If the provided keycodes don't work, just uncomment the line... //player sideChat (format ["%1, %2, %3, %4", _v0, _key, _v2, _v3]); ... within "SightAdjustmentOnKeyDown.sqf", build the pbo, run the game and you'll see a message for every key pressed, including the number assigned to it (second parameter). Once you got your keycodes, you can comment the line above once again and change the lines within "SightAdjustmentConfig.h" according to the keycodes you got using your keyboard.

The next version will include a range card that'll show you the proper adjustments for certain ranges. However I won't add the necessary code to load these settings automatically. As I've said before - I'll provide the tools to set up good shots but it needs to be a challenge still. That challenge will be, that you'll at least need to look up the values on your range card and dial them in manually. Regarding the incompatibility with XAM - I'm already looking into that. Seems odd that it doesn't work though...

I've added a link to a new version to the first post - 0.3beta. It's considered beta mainly because the ingame-range card feature is about halfway done and I'd like to include that into 0.3 later on. enjoy

Right, seems to be initSpeed... Btw. since reading the config.cpp values is possible, modders could also add parameters like sightadjustment[] = { 140, 100 }; where min windage would be -140/2, max windage 140/2, min elevation -100/2 and max elevation 100/2 into the config.cpp. Or add a sightadjustmentMode = "MOA" to override the mode for a certain weapon or add sightadjustmentAdj[] = { 0.5, 0.25 }; where the adjustment applied by the script would be 1/2 MOA/mil for windage and 0.25 MOA/mil for elevation. Think this is goin' to the wishlist

I just remembered a function I found a while ago while reading the COMREF, tried it out just now and it's a promising one. It's possible to read class values from within scripts, so e.g. I can get the players weapon and then query the config.cpp to answer to "is it scoped" question: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">getNumber (configFile >> "cfgWeapons" >> (primaryWeapon player) >> "optics") returns 1 for guns with optics, 0 for those without. I can also get the scope used... <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">getText (configFile >> "cfgWeapons" >> (primaryWeapon player) >> "modelOptics") ... which returns e.g. "\ca\weapons\optika_sniperw" for an M24. It's also possible to get the speed of the ammo used... <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">getNumber (configFile >> "cfgAmmo" >> "B_762x54_Ball" >> "typicalSpeed") returns 900. All of this should for example allow for selection of MOA/mil settings based on some very general assumption and lot's of other stuff

next release should fix the windage adjustment and then there's mp and vehicle behavior to check. Once that's done, it's functionally complete in the sense that it does what's promised. Of course, after that's done, there's the wishlist to implement of which I really want the range card to work so that sniper missions can be prepared for properly Alright, off to work...

primaryWeapon returns the vehicles primary weapon, regardless of whether that weapon is currently in use or not. So even while you run around with your handgun, primaryWeapon will always return your main gun. Oh ffs! How could this go unnoticed so far? I restarted some of the missions I used for testing an lo and behold, they start with the player facing north... unbelievable... Fix will be included in next release - thanks NonWonderDog! This was a good one to find The problem is that, if i switch to the enemy side, i still got the Sight Adjustment. So i have to remake something that "_This Call or exec ...\SightAdjustmentInit.sqf" The script "SightAdjustmentInit.sqf" only initializes the mod, the functions that control the adjustments are attached to the player by the script "SightAdjustmentLoop.sqf" which checks every 0.25s whether the player or weapons have changed. So all changes must be made within the loop and not the config.cpp. If you want to the script to become active only for one side, you could do something like this: 1) Within the loop, catch the first time a unit is added to the unitlist and store it's side somewhere. 2) Whenever the script detects a unit-change, determine the side of the current player and allow the script to attach only when the side of the current player matches the side of the original player. Hmm. This means that a) we really need a range card feature soon and b) it can only be shared amongst users of the same gun with the same zoom... Can't image how this mod should correct that behavior... That number "100" it's mean 100 yards, correct? Well...ArmA don't operate in yards, so that should be around 91.44 meters.(or 109.36 yards for 100 meters) Nope, this is done just for rounding purposes Mulitply with a number 100 too big, round and finally divide by 100 to scale it back to the correct value. Could be that this also alerts the guys since it probably activates the "someone's shootin at me" trigger... LOL, I've been trying the same method yesterday It's a troubled approach though, since the values all vary during animations. The assumptions regarding the static values for weapons-on-back hold true only while the unit isn't moving. It might be possible though to fix it still though... I'm guessing the unit movement is added to the weapon's direction and it might be possible to subtract it to get the weapons relative direction to the unit. I also tried the animDone event handler - looks promising although I bet just watching for the switch-weapon anim won't suffice and there will be countless exceptions to take care of... Next release with a couple of bugfixes (including the big one ) will happen later today or tomorrow...

Correct, this is exactly what the script uses - a "fired" event handler where I can get the weapon and ammo used. However I'd like to know whether the player is actually using the scope, so that the e.g. cursor keys would only work if I'm actually looking through the scope or down the sights. Bloody hell - that's what happens when you test a script with the sound turned off Fixed in next version (had to code it differently though, since otherwise the event handler would pass the key back to the game once the adjustment limits have been reached and the player would suddenly start moving... now we don't want to move once we've set up or shot, right? ) Regarding the adjustment limits: The idea was, that a max elevation would set the max e. to e.g. 70mil when in mil-mode and to 70MOA when in MOA-mode, not to 70°. And regarding mil/MOA and conversion to deg: Yup, the code isn't quite right... will work on that after work. PS: This is turning into some nice teamwork

I've just uploaded a new version with quite a few improvements. See the first post for a list of what changed. @Maximus-Sniper: The max/min values are now set to 70 and can be changed without editing the scripts but by simply changing the values in the config file

Unfortunately no. All that's contained within _this passed by the init event handler is the unit itself and no weapons. Furthermore the primaryWeapon command always returns the primary weapon, regardless of whether the unit has selected it or not. Same goes for the weapons command which contains all weapons attached to the unit but no indicator of which one it's currently using. Heck, even the fired event handler passes only a string with the weapon name and no reference to the actual weapon object. Pretty unbelievable that this isn't possible and unfortunately not the only shortcoming of the ofp/arma engine... By the way, I've rewritten quite a large portion of the code to enable the detection of primary-weapon switches so that the adjustments set for a rifle won't be used once the player switches to e.g. a SAW. Unfortunately it's a bit buggy yet and I have to leave for a couple of days, so the next release will probably happen late next week or more likely (work's crazy right now) next weekend.

Not sure I understand... When you adjust for bullet rise/drop you need to aim lower/higher. Depending on the distance to your target, that'll translate into a certain amount of meters/yards/whatever above or below the point you actually wish to hit. Suppose the script adjusted for "+1m elevation" - at a distance of 100m, that's 0.57° above your target, but at 1000m it's only 0.057°. Since the script can't possibly know what your trying to hit it can't possibly know the distance either and wouldn't know where to send those bullets... Both mil and MOA are angular measurements, not distance.