Spooner

No problems with you doing this, Gnat. I released mine because I'd hit a technical brick wall, but I had added enough features that it was actually quite playable. If nothing else, better the bird in the hand rather than the two in the bush and all that...People can start making diving missions right now, at least in SP, and hook in a better implementation when it is sorted out. Hell, people could even use it in MP now if they don't mind ignoring the graphical inaccuracy (in this case, perhaps best for just the flavour of water insertion/extraction rather than diving-centred missions; could even just use it in intro/outros if people wanted). If nothing else, I have a fair bit of code that would be useful for any system, so even abandoning much of the movement aspects of SPON Scuba would leave a lot of re-usable stuff (e.g. air tank scripting, which is now a lot more complex; reading up about consumption rates based on depth and exertion right now ;P ). Oh, did you consider trying to just set the diver to not float, rather than the invisible boat solution? Would prevent the surface-glitching I have, but you'd still have setPos stutter (Personally, I'd be happy enough with setPos stutter; people are happy with stuff like Mando Hitch after all). I think yours might be the best solution overall though, but we'll see what goes on.

Well, I believe that this technique, or something similar (invisible vehicle) was used for the CoC Combat Divers in OFP. Never used them myself, but you might be able to convert the scripts that came with them to move forwards with this version. This method has a lot of advantages and disadvantages over my script-based solution (In spite of what Gnat said, I have no "units", just scripts that work without addons). The killer advantage for this though, is the potential for better MP compatibility really... Well, at least even if my version is forgotten by next month, I can say I've encouraged a lot of people to jump in the water and get very, very wet ;P Actually, I'm pretty sure that the animations wouldn't be MP compatible (anims are local-only), but with a bit of work, you could broadcast the changes for everyone to sync up at the right depth (and without any of the stutter of setPos solutions).

Hmm, I just need to work out how to draw the laser-vision beams with particles and make it MP compatible, then we can get started... ;P

Thanks again Stavanger! Added link in OP for you.

Yes, it is the WIP Huntir addon causing you problems (thanks for Norrin working out where the problem was; yay for people that use TAGS so we could track that down). The problem specifically causes this error in any mission where the player isn't given a var-name in the editor and gives the message each time the player dies. I've given Norrin a possible fix for the problem and hopefully they will be able to release a fixed version soon. I only watched the video, but it looked real nice! Back to Scuba: The AI just swim at the height they are told to with SPON_Scuba_swimAtDepth and don't care beyond that (so they won't dive or surface on their own initiative). They definitely do have infinite air-supplies (in fact, only the player has an air-supply defined and the line to drown you starts with "player setDamage..."), so it must have been another issue causing him to die. Not denying he died, but it wasn't from lack of air ;P Any more details of the situation that ran up to this happening? AI in your group will hopefully dive and surface with you in future versions, and, for that matter, already have individual air supplies in my WIP version. They should indeed automatically surface if they know they are running out of air, so thanks for that suggestion! As far as Scuba becoming a global change to the mission, I really don't think I can do that. I know some of my other addon releases have changed gameplay a bit (Rearview and Rangefinder come to mind), they haven't really redefined it to the extent that Scuba can. When you create new weapons, you have to include those weapons in the mission or the players can't use them. People could reconfigure the Makarov to fire as much as the miniguns, but that would be considered cheating if you used it in missions that weren't designed to have super-Makarovs. The abstract flippers, air-supply, mask, flashlight, depth gauge, underwater placement of satchels, fast-move flippers, etc. are just like new weapons, but you get them automatically if Scuba is enabled. At the very best, you'd just have 1 minute of breath (not a trained combat swimmer) and no air tanks or other "equipment" if it was available globally. Also I wouldn't allow you to store equipment since you don't have big waterproof bags to keep them in if you are playing as a regular soldier rather than a combat diver. Oh, and you couldn't see as well underwater without having the "virtual" face-mask implied by this addon. And...even then it could only be reasonable to add the functionality in SP, since in MP it could be used to seriously gain advantage over the other side (and some aspects of the script would work even worse if everyone wasn't using it). Would you ask the same if I released SPON Superman (player can fly and impervious to damage)? Sorry, not a serious analogy, but anyway. I know yours was a serious request, so maybe I overextended the explanation to a degree, but anyway this is something I have a strong opinion about.

NORRN_ is Norrin's tag as far as I'm aware, so possibly nothing to do with me at all, though it could be that my script is bringing to bear some broken code in Norrin's addon (revive?) that wouldn't otherwise be performed (missing ; should be causing a problem more than with me). I'll ask him about that error you get... The addon version is not supposed to work on all maps. If it did, it would significantly change the game-play of missions that weren't designed to use scuba diving (and it would mess up badly in MP missions, which is also not good). Instead, you need to put this in the init.sqf of the specific mission to enable scuba (whether addon or mission-based Scuba is being used): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> [] call SPON_Scuba_enableForPlayer; Unless you are playing missions that are written for the Scuba addon (in which case they should put the SPON Scuba gamelogic in the mission so you HAVE to have the addon loaded) there is absolutely no point in running the game with Scuba loaded. On the other hand, it should do no harm doing that.

Well, actually, Recognise uses the TeamSwitch key, not specifically T, so whatever you configure your key to, it will always disable the team-switching dialog (I considered it an MP addon, so didn't worry too much about that). You can still use Y/U to cycle through your team-switchable AI though. (er, can we move this discussion to the Recognise thread if you want to continue it further...thanks!.

Maybe a better description of it would be helpful to others: Basically, it is a variation on the standard "unit tracker" scripts. It draws dots on the standard map for vehicles, not men, within a given distance of your AWACS vehicle (handles multiple AWACS vehicles too). If IFF is enabled, then it indicates whether contacts are friend or not-friend (doesn't differentiate enemy from neutral), but otherwise they are all shown the same. The size of the dot indicates the size of the vehicle and for vehicles in the air, their height is shown too. The script can also be configured to only detect vehicles over a given size, so, for example, it might show planes and tanks but not littlebirds or motorbikes. Although the script is included in the Be32K addon specifically to be used with the AWACS variant of that plane, it could be used to make any land-, sea- or air- vehicle into an AWACS radar. Fully MP (COOP and PVP) compatible. I might release it separately at some point, but for now, I'll leave it just available from that addon.

Actually, no. Screenshots don't really capture the script compared to other "tracker" scripts (just looks like some dots on the map ;P) and making movies that aren't terrible is beyond my skill. Just try it out and see for yourself...

Oh, well, I'll have to work harder to get into the top 3 then ;P (thanks though!. Erm, not at all sure why Recognise would only work inside vehicles. You are aware that it works on the object centre-of-screen, not weapon-direction (the latter is how regular tags work)? It also requires a lot more precision to select infantry (which is intentional).

We can have working submarines in ArmA, because I know several groups are working on them, even if we haven't seen any released yet. Just have to wait... If you are lucky, I'll make a mock driver-propulsion vehicle or manned torpedo, but it would just be a barrel "stuck" to you that made you go faster (as it is, you swim faster in my script anyway, so that wouldn't be too hard to implement). I don't make models, textures, config or that sort of thing; Although limited in some ways, at least my stuff will work without addons if you include the scripts in your mission.

A few points into the stew-pot: 1) General Barron states to the effect that the engine recognises "compile preprocessFile" as a compound entity and pre-cashes the result of loading, preprocessing and compiling the result, so future calls cost nothing. From my knowledge of the compilation process and guesses about the parser that ArmA uses, though, I would interpret that as preprocessFile caching either the last, or the last few files, loaded. File access is a relatively slow process compared to scanning and parsing any script, so it might just be that compile takes negligible time. It might even be Windows itself caching regularly accessed files for ArmA, which would make it unpredictable (though predictable in an artificially tight loop)... I can't believe that if the ArmA parser doesn't cache the files called by execVM or actions (single commands that load, process and run a file), then it would be busy looking for the pairing of compile and preprocessFile and caching the result of that. What if I do this? <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _frog = preprocessFileLineNumbers "fish.sqf"; _fish = compile _frog; Also, you are saying that I can delete compiled code stored in a function (_function = nil), but that doesn't mark it for the garbage collector and it will be kept in memory forever even if not ever used again? I don't think that would be good design for BIS at all (though, perhaps, it IS cached for a while, at least until it is collected, which might mean that later runs would be more costly again). Anyway, what I'm saying is that if any caching occurs it probably is at the loading level, possibly even outside ArmA, not anything at the compile/preprocess level. 2) Assuming that the compiled code is automatically stored somewhere, adding a global will do no more than add that string into the variable hash table (so, 10-20 bytes on average, perhaps) and add a pointer (4 bytes; well 8 on 64bit, I suppose) to the cached compiled code. There is no reason to believe that the cached compiled code would need to be copied if you "stored" it in a variable any more than an array would be (not sure if you were implying that). 3) preprocessFile is completely obsolete. You should always be using preprocessFileLineNumbers in ArmA. preprocessFileLineNumbers does everything that preprocessFile does, but additionally, the user will be given file and line-number information in any error reports when running the function created. Yes, it blatantly wastes a couple more bytes, but if you write code that never gives errors, then I want to hire you at $1000/hour and I know I'd do well out of the deal ;P

Thought I'd tell people about the AWACS script I wrote for Project RACS: Â Â - SPON Sensor - Vehicles detected by radar appear on everyone's map (Included in PRACS Beriev Be-32k addon).

I think people might appreciate this also being released in script form, just not having the fade effects (fade effects need addon-defined colours).

Er, yeah, I can't tell you how much I got confused by 7z showing me the wrong files there! Very, very sorry about getting my knickers in a twist about that before thinking with my brain! Yes, the sensor.sqf file that wld427 is talking about is in fact mine and you can blame me when it goes FUBAR ;P Nice plane and good luck with it and the rest of your mod!

yes there is a reeally cool sensor script included int the pack with instructions on how to impliment it in your game. thanks again SPON for that one <s>I thought I would make clear that I was in no way involved in making the included scripts (My release tag is SPON), which are actually just [GLT]Myke's AWACS scripts that were released a couple of weeks ago.</s>

SPON Rangefinder v0.3.0 Compatible with NWD_scopeFix 2.2: 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): - Released: 2008-09-05 - Install size: 44k (mission scripts) / 104k (addon version) - (mission version) 100% scripts with no addon dependencies - (addon version) Requires XEH (1.7 or higher), but this is included in the release. - Requires ArmA 1.09 (or higher) and SPON Core (v0.5.1 or higher). - See attached README.html for full details Download OFPEC (guaranteed up to date) ArmAholic Overview Adds an overlay to the standard ArmA SOFLAM laser designator. It will show range while the designator is turned on. Azimuth and elevation are also shown, even if the laser is turned off. Requires that the SPON Core be installed in the mission (v0.5.1 or higher). Both SPON Rangefinder and SPON Core are available in two versions: One is a client-side addon and the other is mission-script-based, which does not require any addons to be installed on client or server. SPON Rangefinder requires ArmA 1.14 or higher.   * Rangefinder overlay shown when looking through the SOFLAM (a.k.a. Laser marker or laser designator).   * Shows range to the laser-targetting point and, optionally, azimuth and elevation of the SOFLAM itself.   * The display is accurate to 1m range or 1 unit (by default milliradians) for azimuth & elevation.   * If the SOFLAM laser is turned off, then the last range value is shown for reference (only kept until the player stops looking through the SOFLAM).   * Standard SOFLAM operation as a laser designator is completely unaffected.   * Player can switch between showing the azimuth and elevation displays with 6000, 6283, 6300, 6400 mils, or in degrees, by pressing the reload button (defaults to 'R' when looking through the laser designator.   * Compatible with the NWD optics addon, if it is installed. NOTE: NWD has his own rangefinder addon available. It additionally requires the Extended Init Eventhandler addon be installed and it doesn't look as good without the NWD optics addon being installed.   * Compatibility: SP/SP teamswitch - OK; MP - OK; MP JIP - see limitations, below. As used in   * CO-10 Bleeding Skies by Igor Drukov. Limitations   * While looking through a rangefinder, with the laser off, there is a significant hit to frames-per-second. This is in order to ensure that multiple range-finder users don't pick up the wrong laser dot. When the laser is on, or the rangefinder is not being used, then the CPU load is negligible.   * If you turn the laser on while looking at the sky (or at the ground, beyond the maximum range), then the "laser-on" LED will not light (and the target will not be visible to those that can see laser targets) until you look at the ground within range (BLAME BIS!.   * If you turn the laser on at a viable target, then move to look at the sky (or at the ground, beyond your view range), then the "laser-on" LED will stay alight and the range will be shown to the last position the laser-marker pointed at that was viable. As far as the game is concerned, the marker is actually still in this "last position" and it can still be targetted by bombers (BLAME BIS!. Known Bugs   * (Very unlikely, but possible) If two players on the same side turn on their rangefinders within a fraction of a second of each other, while looking at the same target (or at least in a similar direction), then one of them could incorrectly detect the wrong target. If this happens, they would only need to turn the rangefinder off and on again to get the correct reading. Plans None. Credits   * Thanks to Blanco for pointing out the full range of binocular animations.   * Testing by The Regiment of Grenadier Guards [RGG] squad (http://www.rggsquad.co.uk). Thanks fellas!   * Thanks to everyone at BIS and OFPEC forums for testing, feedback and suggestions.   * Thanks to Solus for allowing me to include the XEH addon in the release (and, of course, for making the great addon in the first place! Change Log v0.3.0 - First version available as an addon. - Added   * SPON_RF_targets array, which contains a list of all current laser target objects.   * Can configure the type of rangefinder class used.   * Player can switch between showing the azimuth and elevation displays with 6000, 6283, 6300, 6400 mils, or in degrees, by pressing the reload button (defaults to 'R' when looking through the laser designator..   * New function, SPON_RF_setMilsPer360Degrees, so that mils displayed can be altered via script if needed.   * New function, SPON_RF_enableMapMarker, so that you can enable fire mission marker shown on map at laser position [suggested by Sickboy]. - Modified   * "SPON_laserTargetFound" event renamed as "SPON_RF_targetFound"   * Variable, "SPON_laserTargetOwner", added to each laser target object, renamed to "SPON_RF_owner".   * Azimuth and elevation are now always shown, even if laser is not on (and even without batteries). - Fixed   * If two players on the same side turn on their rangefinders within a fraction of a second of each other, while looking at the same target (or at least in a similar direction), then one of them could incorrectly detect the wrong target. If this happens, they would only need to turn the rangefinder off and on again to get the correct reading.   * Battery LED is still lit if the player isn't carrying any laser batteries. (See readme.html for full details of changes before current version). <a href="http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?act=ST;f=70;t=74601" target="_blank"> </a>

Sorry, the problem is actually in XEH and/or SPON Core, rather than in the Rangefinder itself. The cause and solution are different depending which version you are using. Addon version: It is because every soldier in the mission starts out inside a vehicle (not a single player or AI on foot). This isn't a problem any more though, as long as you use XEH 1.9 or higher (the zip includes XEH 1.7). Mission version: This means you are running initCore.sqf after the mission has started. Run it at the top of your init.sqf rather than after any waituntil/sleep.

SPON RearView v0.3.0 Civilian cars have central mirror as well as side mirrors: Military vehicles and trucks just have side mirrors: Stryker and M1 Abrams now have extra camera views when turned in (The Stryker also has mirrors when turned out): - Released 2008-09-20 - Install size: 32k (mission scripts) / 87k (addon version) - (mission version) 100% scripts with no addon dependencies - (addon version) Requires XEH (1.7 or higher), but this is included in the release. - Requires ArmA 1.09 (or higher) and SPON Core (v0.5.1 or higher). - See attached README.html for full details Downloads OFPEC ArmAholic (mirror) ePrison.de (mirror) SPON RearView@YouTube (By SpetsNazCU) Overview Gives the driver/pilot of most vehicles working rear-view mirrors and/or remote cameras. Requires that the SPON Core be installed in the mission (v0.5.1 or higher). Both SPON RearView and SPON Core are available in two versions: One is a client-side addon and the other is mission-script-based, which does not require any addons to be installed on client or server. Both require ArmA 1.09 or higher. To remove the annoying 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! Features  * Pressing <vehicle-turbo> with <turn-out>, <heli-rudder-left> or +<heli-rudder-right> (defaults to LEFT SHIFT + Z/X/C) will change view to looking back through the left, central or right-hand mirror. For the turned in driver of the M1 Abrams and Stryker, you get a remote camera view (left, rear or right) instead. This view will be held until <vehicle-turbo> is released.   * Implemented for all vanilla ArmA and Queen's Gambit vehicles that have mirrors on the model (including the Mi17 helocopter). Stryker mirrors are available, but only when turned out (turned in, they get remote camera view instead). Also implemented for many vehicles that lack actual mirrors on the model (military and heavy vehicles just get left/right mirrors. Civilian vehicles get central mirror as well).   * Automatically allows mirrors in all vehicles in mission at start, or that are created during the game (each vehicle is checked the first time that the player tries to look out the mirror).   * Mirrors become disabled when a vehicle is badly damaged (at > 60% damage taken).   * NOTE: For demonstration and testing purposes, the demo shows the exact mirror positions it has defined with green or red dots - this doesn't happen in the normal execution of the script! Limitations   * View is not actually mirror reversed, but rather the player sees from the position of the mirror looking backwards. Just pretend you are sticking your head out the window if this worries you!   * Vehicles not present in vanilla ArmA or Queen's Gambit won't have mirrors defined (they don't inherit from standard vehicles) or may have mirrors in the wrong positions (they inherit from standard vehicles and change the model significantly).   * Cannot use vehicle turbo or the helicopter rudders while in mirror view.   * While using the mirror, you will hear what you would hear if you were in the position of the mirror itself, not what you would hear inside the vehicle.   * While using mirrors, you have access to standard movement controls, but not to actions or non-movement keys.   * Motorbike mirrors are set a bit back and always face directly backwards. This is because it isn't possible to work out the rotation of the front wheel of the bike relative to its body, and therefore the actual positions of the mirrors. Known Issues   * While looking in the mirror, vehicle turbo will still be engaged if moving forward (unless you use slow-forward, which defaults to Q) [Reported by USM-CPT.Dyson] Plans - Definite   * Allow for "strict" mode, which disables mirrors on vehicles whose models don't show an actual mirror.   * Allow third-party (non-BIS) vehicles to record mirror positions in config. - Possible   * Give gunners/passengers ability to look backwards   * Add "look down" or "look out" view for helicopters. Credits   * Loki the Test-monkey!   * Testing and feedback by members of the Regiment of Grenadier Guards [RGG] squad (http://www.rggsquad.co.uk). Thanks fellas!   * Thanks to those who helped me out on the OFPEC forums or gave feedback on the BIS forums.   * Thanks to Solus for allowing me to include the XEH addon in the release (and, of course, for making the great addon in the first place! Change Log v0.3.0 - Added   * External cameras for turned in M1 Abrams and Stryker drivers (left, right and rear).   * Addition of third mirror position (central) for several civilian vehicles. - Fixed   * View continually switches if left/right mirror keys are held down (Sorry, introduced in v0.2.1).   * Rearview doesn't have night vision, even if the player is using it (to get NV in mirror requires ArmALib. However, in this case, you get lots of HDR effects whenever you change view, unless you use something like Shole's S_NVG to get a controlled aperture size). (See readme.html for full details of changes before current version). <a href="http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?act=ST;f=70;t=74601" target="_blank"> </a>

By upgrading to the new XEH 1.9, you should avoid those occassional "time == 0" error windows that SPON Core spits up.

Thanks for making those improvements! I only suggested the pre-init system to avoid the issue with late-init on crews, but you did both (well, I think someone else suggested pre-init before, but it is definitely a nice feature)! Yay! EDIT: SPON Core, and therefore the SPON components that run off it, now works properly with 1.9 due to the early execution of crew inits (it failed in missions where every human was in a vehicle - never considered that). I should have just changed it to be run on AllVehicles rather than Man, but now I don't have to *cough*. I'll be using the preinit in the future releases.

v0.3.0 released! - Added   * External cameras for turned in M1 Abrams and Stryker drivers (left, right and rear).   * Addition of third mirror position (central) for several civilian vehicles. - Fixed   * View continually switches if left/right mirror keys are held down (Sorry, introduced in v0.2.1).   * Rearview doesn't have night vision, even if the player is using it (to get NV in mirror requires ArmALib. However, in this case, you get lots of HDR effects whenever you change view, unless you use something like Shole's S_NVG to get a controlled aperture size). EDIT: forgot to mention that you now look left with shift+Z, centre with shift+X, right with shift+C (assuming default key layout).

I have separately released the SPON_LOS function at OFPEC, since I thought people might find it useful (but, I think as of now, the separately released version is older than the one included in Recognise - just use the one in Recognise). However, SPON_LOS works out the line from centre of player's screen and tells you what you are looking at, which isn't quite what you want. You might find it useful to see how you might do what you want though.

I have specifically avoided doing that, otherwise this would be a way to have an easy-mode crosshair for your weapon, even if that was disabled on the server (only if you didn't have a floating zone though). The reason I added the dot was so you could easily work out what you were looking at. For example, if you are looking at two infantry standing close to each other, it would otherwise be next to impossible to work out which one you were getting information about. However, something does need to be done to improve this situation though, because as you say, it is extremely difficult to use the addon when you have a floating zone set up. Not sure what exactly needs to be done, just yet.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> _type = getNumber (configFile >> "CfgWeapons" >> _weaponClass >> "type"); Type 0 are slotless weapons like put and throw and do not appear in inventory. Type 4096 are optical "weapons", like NV-goggles, laser designator and binoculars (I'd count NVG and LD as military equipment though).