Spooner

@mrcash2009: I can ;P

Regarding running or precompiling sqf files, always, always use preprocessFileLineNumbers! loadFile -> No preprocessing of macros or comments; vague error information. preprocessFile -> Macro preprocessing; vague error information. preprocessFileLineNumbers -> Macro preprocessing; full error information. (full error information means you are told the file and line number of the error, just like you get with execVM!. --- A problem I'm having with XEH at the moment is that if men are inside vehicles, then their init is not run until after the mission starts (time > 0). This is because you spawn these inits, rather than calling them (I know you have to because of the sleep you have in there, but I'm not sure why you need to sleep; it isn't as though those men's inits wouldn't all be run at time == 0 if they were on foot). It is important that SPON Core is run at time == 0 and I'm currently starting it using the camanbase init. If you can't avoid that spawn, I'll just have to add init to vehicles as well, since it isn't guaranteed that a mission will have men on foot at the start. To save this messing about, I have an alternative suggestion: Would it not be possible to have a single pre_init handler that was run once before all object inits (by running it on the first object that is created, before that object's init was run)? This would save all the addons, such as mine, that just want to start a single script up at the start of the mission, from having code run in every object's init. This would have the added benefit of allowing us to precompile functions and actually use them inside object inits, saving a lot of unnecessary use of execVM.

Thanks for that! Feel free to mirror anything else of mine (And that goes for anyone else wanting to mirror it, as long as you include a link to BIS and/or OFPEC release threads). EDIT: By the way, to remove the crosshairs on the RearView, you can use TrueCrosshair-Veteran which is part of the TRUE mods. This will also disable name tags, but you could consider SPON Recognise to give you better tags anyway!

v0.2.1 released! - Added   * Gamelogic, "SPON RearView (Require)" added to allow you to force SPON_RearView.pbo to be loaded before playing the mission. - Fixed   * You need Queen's Gambit addon to try out the demo mission (there were no QG vehicles in the demo, but I'd added them temporarily in order to set their mirrors correctly).   * Mirror view can mess up in cutscenes or with other remote camera usage. SpetsNazCU has made me a truely awesome video; I never knew mirrors were so exciting! Thanks! SPON RearView@YouTube

Yeah, sure, though it wasn't immediately apparent what list you were referring to! I only really follow the OFPEC forums; just taking advantage of this one for publicity ;P Ironically, none of my stuff works well with Warfare, since it both uses non-shared key events (could use shole's Display Event Handler to multiplex key events) and removes any actions you add to player (bad use of removeAction). Can't get around that...

Glad to be helping you kick-start Sahrani Radio again! Hope you'll have some more interesting people on than me soon so I can listen in, because I already know about me ;P

Fixed the issue, but it requires ArmALib being used client-side. This will be optional, so if you don't have ArmAlib but use Andy or SLX laser designators with my script, you'll still get the overlay problems. Expect an update in the next few days (want to put a few other little things in the new release).

Well, not really! I just tested it, and weaponDirection for binocs is always exactly the same as that for the currently used weapon (rifle, pistol, etc)! Thus, you can turn on the rangefinder by using any weapon if it is aimed at the centre of the screen ;( Also, when panning while using the rangefinder, the two values diverge until you hold it steady again, same as when you get a slight lag when panning a rifle. Another interesting thing I discovered is that when you aim/zoom with any weapon, both SPON_vectorDir and weaponDirection are not affected at all, so the movement must be considered to be while keeping both of those values constant! I had assumed that the weapon's direction would converge with the viewed direction when aiming with scoped/binocs. Assumption is a deadly thing, especially in ArmA! Back to trying out the ArmALib solution. Alternatively, I could force the player into zoom mode with the LD if SPON Rangefinder is used in order to keep it working properly, which rather defeats the object of your addon EDIT: On another note, it is a pity you can't start the binocs/LD zoomed when you pick them. Bit annoying having to select them and then zoom as well (which is what you want when you start...you want to unzoom later, not when you first move to binocs).

Actually, you aren't missing anything! I just confused myself, since a couple of days ago I was thinking about trying to work out if the current weapon, regardless of type, was being aimed, but couldn't get that info without using ArmALib FOV, since weaponDirection and SPON_viewVector would not be the same, even if aiming, with most weapons. On the other hand, for weapons that change to a zoomed view when aimed, such as scoped weapons and binoculars, this method would work fine.

Absolutely! The use of the marker makes things very easy, but I included it because I can't see that it wouldn't be realistic and some people might like it. I didn't think that it was a reasonable feature to add to a mission from a client-side addon though, which is why it is off by default, unless manually enabled in the mission. To use map marker effect, map markers must be enabled in the mission and: * Everyone that wants to see the laser map markers has to have Core/Rangefinder addon. Anyone without will not have errors; they will just not see the markers on their copy of the map. OR * Core/Rangefinder scripts are in the mission itself, which will obviously give everyone access to all the Rangefinder functionality. If you want to force SPON Rangefinder to be loaded before playing the mission, then add "SPON_Rangefinder" to the list of addons in your mission.sqm. Alternatively, something I keep forgetting to add to the addon is a "Require SPON Rangefinder" gamelogic, so you can just drop that into the mission to force players to have the addon without touching the sqm. I need to update anyway with a few minor fixes and features, so hopefully I'll remember it this time ;P

Well, this is a nice little addon which I will certainly consider using, but yes, it will go fubar with SPON Rangefinder, since the overlay will still be available while not aiming with the LD. If you use SPON Rangefinder to get the angles, not range, superimposed on normal binoculars you'd get the same problem. The reason for this is that SPON Rangefinder uses your current animation in order to work out if you are looking through a "binocs-like" weapon. The animation is exactly the same, regardless of whether you are aiming or free-looking, but normally that doesn't matter for aim-only weapons like binoculars ;P The only way I can think of to always tell which state you are in is by checking the FOV via ArmALib, which is obviously not universally useful (I would do this only if ArmALib was being used, so if you weren't using that, then you would just get the overlay error as you do now; still, better than nothing). The other way, by comparing weaponDirection with SPON_viewVector would only work if you had the floating zone turned off ;( If someone can tell me another way to tell if the player is zoomed or not, then I'll definitely be fixing my script (checking keys/buttons wouldn't work, as someone has already said). There are a couple of other projects I could do with that information for too! EDIT: I'll see what I can do with the optional ArmALib-based fix when I get a moment. Since I do use ArmALib client-side, when I apply that fix, I'd definitely start using these addons.

Yay for compatibility! I forgot to post this image in my first release: Automatic fire mission marker placed at position of laser dot if the user of SPON Rangefinder has GPS. It is visible to everyone on your side (Off by default, but can be enabled in mission):

The bus uses left mirror and centre mirror (which replaces the right mirror), since there isn't a right mirror on the bus model and it is nice looking down the aisle. No plans to add centre mirror for other vehicles, since the two side ones cover it really (already struggling to find enough keys that are likely to be unused ;P ). It is either switchCamera or nothing, since you are normally looking out of a player proxy, not the player entity (try switching to player camera when in a vehicle and you'll see something odd!. Using a "real" camera view works even worse, since you have no control while using it, so you couldn't drive at the same time.

@sandzibar: The issue isn't with XEH, but rather with key event handlers, as was the question about SightAdjustment. Have you tried the version that shole fixed for use with his DEH?

Well, since an LD is just "special" binocs, I'd doubt that individuals would be issued with both. Since the game model is the SOFLAM, rather than the tripod-mounted GLTD II, it isn't really much more cumbersome than using binocs (well, not enough that I'd want to lug around binocs as well, but that is just a guess, since I know the military isn't always logical). The in-game model is the SOFLAM, which strictly just has a simple rangefinder display, without the angles displayed, whereas the GTLD 2 does have those values shown (the SPON and NWD displays are laid out based on GTLD 2). Looking at those documents again, I realise that in both devices, the LEDs should all be in red, not green. Hmm, not sure about whether to change that to be correct.

It isn't entirely a mistake that you get the angles in binocs, since I knew if you set the laser designator class to binocs you'd just get the angle values overlay on the binocs. I didn't consider that you would get it on both binocs and LD if either of them were set as SPON Rangefinders (but as you can only carry both by addweaponing, this isn't a real bug ;P). I'd like to make the LD work on the B key, but although I can allow you to change to LD, I can't un-select LD and go back to previous weapon (impossible to know weapon you are using with absolute certainly and can't know or re-select current firing mode anyway - oh for "currentWeapon", "currentFireMode" and "selectFireMode" in ArmA 2 ). Not sure whether to allow this switch-to-LD one-way, if I can't take it back again. This would mess up things if you did have both LD and binocs, but that shouldn't happen normally, so I don't think anyone can complain. Yes, several people have asked me to re-release this old script as an addon, since they weren't happy with NWDs. Sorry that I dragged my feet on that...

Interesting bugs you bring up here. The only time I can imagine that you'd see the overlay on binocs would be if you were carrying both binocs and designator, which you can't do by picking things up naturally, but you can with addWeapon (just as you can carry 400 rifles with addWeapon if you really want to ;P). Actually something I can fix quite easily, but since it can't happen naturally, it isn't something I'm going to rush to work on (though since the method I'd use to fix it would be more elegant than the method I use right now, it think I should fix it anyway). On the other hand, you can give people access to the azimuth/elevation readings inside the regular binocs if you want (though, of course, you won't be able to use it as a rangefinder or designator). You'd just add to init.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ["binocular"] call SPON_RF_setLaserDesignatorClass; You can also just give a player the designator without a battery, to allow azimuth/elevation readings with that device, without the rangefinder or designator functionality being available. My scripts do nothing more invasive than hasWeapon, so I can't see how they could remove your binocs. That is an odd one...Perhaps double check that and email me a simple test mission that shows this happening if you can't sort that out?

v0.2.1 released - Modified * SPON Recognise now required SPON Core v0.5.1, in order to be compatible with other key event handlers. - Added * New corpse icon (skull). * AI icon for living AI, but only in MP games. - Fixed * If SPON Recognise addon is loaded and SPON Recognise mission-scripts are run in the mission, then everythings gets in a mess.

New version of SPON Core released (v0.5.1), which addresses issues of compatibility between SPON Key Event handlers and Shole's DEH, which can cause problems with SPON Recognise.

SPON Core v0.5.1 released Modified   * Replaced GNU Public Licence (GPL) with the less restrictive Lesser GPL (LGPL). Fixed   * If SPON Core addon is loaded and SPON Core mission-scripts are run in the mission, then "things" get in a mess.   * SPON Core key event handlers incompatible with Shole's Display Event Handlers (If both are used, DEH's key events will always work, while SPON's won't).   * Some errors in macros.inc.sqf

Not sure what you mean by turning names on/off at distance. You can set the max distances in the mission regardless of which version you use, but I feel the defaults given are fine if you are using the addon version just on the client-side. Names appear only when you press the recognise key and you are looking at something that can be recognised. Defaults: Allied infantry are recognised up to 20m, vehicle crews to 1m, corpses (all sides) to 2m.

Well, actually, it is a "weaker" friend-or-foe recognition than having friendly tags on (e.g. can't see through buildings or at long ranges), but I hope it should encourage more servers to turn off friendly tags, since I know a lot are keeping friendly tags on, in spite of its drawbacks, because having no recognition at all makes the game very cumbersome (or give those with friendly tags already turned off, because they are so exploitable and intrusive, a way to identify someone standing right next to you). Oh, the usual caveat applies: Using the addon on public servers where other players don't agree to its use might be considered cheating (Server admins, you need to enable addon signatures if you don't want people to cheat). However, most public servers have friendly tags on anyway, so I don't think this should be a major issue.

@i0n0s: I didn't mean that you needed to recreate the units to do it, since, as you say, you would need that to reapply the mode. I meant, * unit changes to "FLYING" mode, you also set Z=50 (or whatever the standard flying height is). * unit changes to "NONE", then you also set Z=0. * unit Z set to 0, then you also change to "NONE" mode. * unit Z set > 0, then you also change to "FLYING" mode.

Glad I could be helpful! Have you considered having the selected air unit have a line of particles in a line betwen it and the ground? Something like the bounding-box lines I show in my LOS demo. It would make it even more obvious how high it was (e.g. having a smaller particle every 10m and a larger one every 100m). Might even get away with not having the ground-level spinner then. Alternatively, keep the spinner on the ground and have the line going up. Not sure either suggestion would look better, but maybe worth a try to prevent spinner-overload ;P BUG: If you create an air vehicle as "NONE", then it is on the ground, if "FLYING", then it is flying. If you create an air vehicle in position "NONE", then edit it to be "FLYING", it stays on the ground, and vica versa. If you manually set the Z-coordinate, then it doesn't automatically switch between "NONE" and "FLYING" depending on the new value. Or maybe this is intended *ponders*

I'll save you the effort of asking me ;P Maybe look at my LOS function... EDIT: You aren't the only person to not realise the difference between preprocessFile and preprocessFileLineNumbers. I realised that both BIKI and OFPEC COMREF described the commands as being the same, so I updated the COMREF versions with a useful description. No wonder people were continuing to use the "obsolete" version!