Spooner

As I say, you don't need the whole core directory, just the ui directory from it. I've tested it and it does work (assumption that things work is my greatest downfall!). Sorry about the earlier, misleading, information. I'm working on Sickboy regarding ACE, but he is a tough nut to crack, and not everyone has the clear vision that you have :P Incidentally, I am classed as a "contributer" in the ACE team (not a full or lead dev, or I might have had more success subverting them ;) ). I would do more for them, but I have too many fingers in too many pies...

Ah, I see what the problem is. The problem is that SPON Map (and all my dialog-based components, in fact) uses several files from Core directly. It won't be able to find the files inside the addon (ArmA only allows #including from subdirectories, so I can't see them!), but you can just keep a copy of the files you need in SPON/Core and there should be no problems. First leave this at the start of your description.ext: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #include "SPON\Core\ui\core.hpp" And just keep a copy of the dialog config files you actually need from Core in your mission (you still need a lot of scripts from Core, but they can be used from the addon version): SPON\Core\ui\*.hpp (about 25k in total). You don't need the Core stringtable stuff or the call to initialise initCore in the init.sqf though. Alternatively, leave the whole of Core in, which would work too, but that seems a bit of a waste (though it would mean that you could run your mission with or without the Core addon, but since I imagine you are making an ACE-specific mission, there would be no issues with this dependency). This should work for all of the dialog-based SPON Components inside missions when used with the Core addon. Ack, I don't think I like that workaround at all. I may have to re-release my components including those files to overcome this issue, but that isn't ideal and would be a waste of 25k per component for every one in a mission. Sorry about that, I had assumed things would be fine and had only tested that addon+mission script versions of the same component worked fine together. Thanks for bringing it to my attention; I'll see what I can do about a more robust solution for this.

No problem at all. Just run SPON Map from the mission (pure scripts) and it will happily use SPON Core where-ever it is found (addon or mission script). Note that if you have the same SPON component in the mission and as an addon, then only the addon version will run, so you don't have to worry about that. However, should the user have an older version of the component than the mission does then that could potentially cause problems if the mission relies on newer features than the addon has. It is a lot easier to update your addons though, than it is to update all of your missions, so I think this way around makes most sense (players have no excuse for not having the latest addon version, but missions shouldn't need to be continually updated unless they need the new features of a newer script version). EDIT: If you use a component that requires Core in the form of an addon, your mission will not work if the player doesn't have the Core addon. To enforce a dependency, just place the appropriate object in the editor: * Game Logics/SPON/SPON Core: Require

We can already do this perfectly well with the standard intersect command. The only issue is in fact that intersect only "collides" with named selections and only infantry have named selections covering their whole body (buildings and things don't have any names; vehicles have a small number of parts named). Thus we could have this entire functionality in ArmA 1 if BIS had named the selections of objects they put in the game. I'm hopeful that they remember to do this for A2

I'm committed to having the drawing lines scaled by zoom, since most of the time you want a line-thickness appropriate to your current zoom. If I'm making a small drawing, I will zoom in and thus thin lines are most appropriate. If I'm making a large drawing I'll zoom out and thick lines are appropriate. I don't want to be fiddling around with controls before every line I draw. I'm also not someone who likes sliders generally, since they are fiddly and often are not the right tool for the job compared to offering a selection of choices. I have always intended to add a thin/normal/thick option when drawing, but it isn't high priority right now. A temporary workaround for your particular problem is this: 1) Draw your shape at high zoom, so you have full control (do not release mouse button). 2) Zoom out. 3) Release the LMB. (When you draw, the line thickness of the whole line that is actually broadcast is based on the zoom level you are in when you release the button).

Great to hear from people exploring what you can do with the Map (e.g. never thought of specifically marking AA danger zones with circles). Using SPON Map while unconscious [ACE mod]: Oops, that was an issue I was aware of, but I'd forgotten to find out how to know if the player is unconscious. Using SPON Map while not carrying a map object [ACE mod]: I wasn't aware of this, but I thought I had covered this issue (SPON Map should already be disabled when the regular map is disabled). I'll have to look into this... JIP updating: will require quite a bit of reworking of the way I've implemented network transfers. Thus it will need to wait at least for 0.7.0 (because the alternate data wouldn't be compatible with 0.6.x). I'd love to see it too, but it really is messy to do (and a nightmare to do efficiently). There are also a lot of other privacy issues, for example, if you join 1-1-A group on a persistent server for the first time, do you get updated with the markers/drawings made by someone in the same group sending a group message two days earlier? Same if you log in with the same name as another player that was on earlier. Well, I suppose that isn't too critical as long as people are made aware of it (and I definitely don't plan to resync IM text, which is where privacy matters more than if you've drawn offensive things on the map ;P).

New version: v0.3.0 - Modified * Default maximum range to identify infantry increased to 40m (was 20m). * Recognition now follows the line of your current weapon, if armed and on foot (still aims at the centre of the screen when in a vehicle, when unarmed or not actively using your weapon, such as when in medic or reload actions). - Added * SPON_Recog_showBackground variable to allow user to disable the solid background behind the pop-up text (defaults to false). Text is now shown with a shadow if background is not shown, so it is still visible regardless of the background colour. - Fixed * Recognises own vehicle, preventing recognition of other vehicles and infantry outside.

SPON HoloMap v0.4.0 Hmm, SPON Map and SPON Radar might seem interesting, but aren't they a bit flat? We deserve better! Well, you need to know what is going on all over the island and vehicle blips are the best way to show that! Well, I know I said blips are best, but why not have little miniatures instead? Oh, the humanity of it all! One HoloMap isn't good enough for you? SPON HoloMap v0.3.0 @ YouTube (Thanks to DeanosBeano for making the movie!) - Released: 2008-12-18 - Install size: 45k (mission version) or 108k (addon version) + 1.7MB (optional DBO Miniatures) + SPON Core (Core v0.5.3 used in demo) - (mission script version) 100% scripts with no addon dependencies - Requires: ArmA 1.09 (or higher) and SPON Core (v0.5.3 or higher) - See attached README.html for full details Downloads * OFPEC (guaranteed latest version) * ArmAholic (mirror) Overview HoloMap creates a 3D holographic representation of the game world, showing friendly (blue) and non-friendly (red) vehicles, as well as missiles fired, as blips. Alternatively, using the @DBO_miniatures addon (included), show vehicles using scale models! Features   * Creates a 3D holographic representation of the game world, showing friendly (blue) and non-friendly (red) vehicles, as well as missiles fired (white), as blips.   * Friendly and/or enemy infantry can be shown on the map if required, assuming they have radios and GPS, rather than using radar to detect them. This can be limited to just showing roup leaders, to reduce clutter.   * Automatically renders a 3D map of any island, including ground textures (grass, urban, rock, sand, etc). Higher ground is given a lighter shade, in order to improve terrain shape recognition.   * Each HoloMap projector is associated with a nearby or remote sensor object (such as a radar tower or AWACS plane) and will show a HoloMap centred on that sensor's position, at least until the sensor is destroyed.   * Any vehicle or object can be made into a jamming device, with a specific range of effect. If a HoloMap projector or sensor is inside a jamming zone, then the projector will not show anything. A jamming zone is clearly marked on any HoloMap that is outside the jamming zone, but it will hide all blips within the zone. Jammer vehicles only cause interference when their engine is turned on, but other jamming objects, such as towers, are always on until they are destroyed.   * Any vehicle can be given a stealth factor, which reduces the range at which it can be detected.   * 100% client-side scripts with no broadcasts, so absolutely no effect on network traffic or server load.   * Optional: By installing Deanosbeano's DBO Miniatures addons, you will see tiny representations of vehicles, including missile trails and burning vehicle effects! Limitations and Known Issues   *  (With DBO_miniatures) Only a small number of vehicle miniatures will be shown (currently only the RHIB, Cobra, HMMWV, KA50 and Harrier are implemented). All other vehicles will default to one of these models.   * (With DBO_miniatures) Vehicle miniatures will only be shown on a single HoloMap at a time [Just make sure your displays are more than 10m apart if their areas overlap or make sure that they don't overlap if you want more than one].   * (With DBO_miniatures) The current version of vehicle miniatures uses a unnecessarily high LOD, so if you have more than a few miniatures visible at a time, then FPS will be very badly affected.   * All vehicles and missiles within range are shown on the map, regardless of line-of-sight from the HoloMap sensor [Not sure I can do decent LOS calculations for a large number of objects, especially when using long-range sensors].   * FPS is affected most by the amount of terrain drawn on the HoloMap (or HoloMaps). The best FPS will be for HoloMaps that show a lot of sea [e.g. Ramadi range of 2000+ and Sahrani range of 10000+ are quite fast].   * Can't manually control jamming devices (other than to turn a vehicle's engine on or off).   * Sensors actually detect in cubes, not spheres, so they have up to 1.41 times greater range in the corners! Jammers operate in a vertical cylinder rather than a sphere [both simplifications are to make the map easier to understand, since neither are realistic].   * Sensors can detect objects directly behind a jammer [true line-of-sight calculations for this special case are probably not worth the effort]. Compatibility   * SP: Yes.   * Teamswitch: Yes.   * MP: Yes.   * MP JIP: Yes. Plans   * Deployable/Stowable HoloMap inside mobile HQ.   * Manually turn on/off jamming.   * Simple dialog to switch sensors (rather than action list).   * Size of target to affect detection (rather than just to affect size of blip). Design Aims   * Improve command and control by giving commanders a shared 3D representation of the battlefield.   * Create a reasonably realistic radar system, in order to add new tactical dimensions to the game.   * Avoid reliance on addons, in favour of scripting, as far as possible. Addon and 100% mission-scripts versions available! Credits   * BIG THANKS go out to Deanosbeano for resizing and configuring the miniature vehicles (@DBO_miniatures).   * BIS for the original models that were used to create the miniatures.   * Q for testing and feedback.   * Demo mission and addon pbo files created with cpbo by Keygetys.   * 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.4.0 Added   * Ground textures shown on terrain (grass, urban, rock, sand, etc).   * Ranging rings shown on terrain.   * Infantry can now be detected if required.   * Any projector can be associated with any nearby or remote sensor (such as a radar tower, mobile HQ or AWACS plane) and will show a HoloMap centred on that sensor's position, at least until the sensor is destroyed.   * A projector's sensor can be switched in-game, for example using an action.   * Any vehicle or object can be made into a jamming device, with a specific range.   * Any vehicle can be given a stealth factor, which reduces the range at which it can be detected. Modified   * Demo mission moved to Sahrani, so as to better showcase the script.   * (With Miniatures) All vehicles now shown as a tiny model. However, most will default to a generic vehicle type rather than being representative (e.g. all land vehicles, regardless of side, size or type, default to a humvee miniature!) Removed   * No longer uses the Blue Box from DBO_miniatures. Fixed   * Only those players who start within 10m of the HoloMap will EVER be able to see anything on it (this allows for staff officers to see it, but not to unnecessarily update it for the regular army soldiers).   * If a vehicle exists beyond the edge of the zone covered by the HoloMap, it will still be represented on the map, though placed outside the "projector area", floating in mid-air.   * There can only EVER be one HoloMap in the mission.   * FPS spike when redrawing terrain.   * HoloMap rendered regardless of player's proximity to the projector unit.   * The information displayed is appropriate to the observer, not to the projector (thus, you can't look at an enemy projector and get any different information from it than you could from your own). (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>

Well, you've had a month to play around with this, and yet, not a single comment about it after actually using it in-game. Hard to tell whether people are using it, or if they just played with it once and shelved it. Really wondering if it is worth continuing to work on this. * Is anyone actually using this in missions, or is it just considered a proof-of-concept piece, that is, not really practically useful. * Do people use, or want to use it, with blips or with vehicle models? * Would anyone use it in a modern mission, as opposed to an SciFi mission, or would you not be able to get over the fact it is supposed to be a hologram? If this is really a problem, then I could just do exactly the same thing that you can only see inside a computer screen and it would be entirely realistic (essentially an ArmA-type simulation running on a PC in-game). * How do people feel about the implementation of radar/jammers/stealth? Realistic or gamey (considering that even semi-realistic jammers/stealth are better than none if you actually want those functions). * Would addition of LOS calculations for all radar contacts be a significant improvement (that is, would it allow people to use it?)? Just worried how much slower this would be. * The next version will have an option to show infantry/light/heavy/air icons on the map (addon version only, I'm afraid), to offer a compromise between vague dots and fully detailed models. Would this make a difference for people? * Planning to offer IFF system in future version. This would mean that friendly units would be shown with icons/models, but the enemy would be unidentified blips. * What features are critical to this system being used, that it doesn't already have? * If this was merged with SPON Sensor (so everyone had simple map markers for contacts, but you got the nice 3d map if you were physically next to the holomap) would that be more useful?

Always good to hear that someone is using my stuff! Thanks! Something I'd really like to ask for, from you, as well as other users of the SPON Map, is for more feedback. Although I've tried to streamline the GUI as much as possible, for example, there really are a lot of complex features in SPON Map, so I'm sure I've taken some suboptimal design decisions. The more feedback I get on usability, the better the system will become. The same goes for the general features list, which really could be expanded indefinitely, but unless I know what people actually want, I won't necessarily develop the features the community will use! No idea what the German language issue is. I can only suspect that your game wasn't working for another reason, but do tell me if the issue reoccurs. I'm pretty sure that the key names, rather than descriptions, are universal. SPON Map 0.6.0 defaults to using keys, but you can enable the action again using a function call in the mission. Really, the action menu gets too cluttered up and people, including me, prefer the key shortcut. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> [] call SPON_Map_useAction; // Adds action as well as keys. I would like to replace the BIS map, but the big issue is that you don't have access to the radio except via 0-0-1, etc (I'd like to create a more dynamic SPONised radio inside SPON Map), map textures (Working on fixing that, but I'm not sure it is really workable done manually), the notepad (SPON Map notepad is better than this in some ways, since it is totally dynamic, but its lack of links is a critical problem) and onmapclicks (something I'll tackle at some point, probably when I redesign the radio). Thus, it is definitely not appropriate as a default, though it might be appropriate to your clan missions. You can use a function call in the mission to directly replace the map though (so you open SPON Map with M, not shift-M). <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> [false] call SPON_Map_enableBISMap; // Can't access regular map any more. Open SPON Map with M, rather than shift-M.

How does it affect NVGoggles though? HDR pretty much blinds you every time you see a light at the moment, although there are other fixes for this annoying effect.

New release v0.6.0 Finally got around to releasing this to the public and not a moment too soon! Since 0.5.x, I have added a literal raft-load of new features as well as fixed a lot of the features it already had that weren't quite right (too many changes to list, but if you are bored, the readme is extremely verbose about those sorts of things). Thanks to all those that tested the private betas (v0.6.0RC1-7) for me and, hopefully, allowed this public release to be a lot less buggy than it might otherwise have been!

New release: v0.4.0! Lots of changes, fixes and improvements (see changelog, above) and quite a few new screenshots in the zip. @DBO_miniatures hasn't changed since v0.3.0.

Well, always good to get some feedback! Thanks! @Q: Yes, the 2nd image, with the black "water" and simple coloured blips is the version when used with the DBO_miniatures addons (I can see all 5 images, so not sure what the problem is with you). @Manzilla: Thanks for telling people where to find the download files; I'd forget my own head if it weren't screwed on! @Miles Teg: As I said, this version is more of a proof-of-concept, so it isn't as polished as my usual releases. There is absolutely no technical reason why there couldn't be 10 HoloMaps in a mission, all showing different areas and at different scales. However, the current implementation isn't fully hacked into shape so it doesn't allow more than one HoloMap, as well as having several other limitations which I could overcome with more work Regarding gaining "magical" information, you are absolutely right. In its current state it is a vast oversimplification, but without going to a lot of effort in setting up configuration options and polishing the rough edges, I feel this was the best overall "setting" to release with so people could play about with it! @Mr Burns: Actually, it is possible to create a camera attached to a miniature vehicle and fly around over the holoMap, looking up at the people looking down at you! Quite unnerving, I can tell you! If you want to control them, then just run out and find the full-sized version :P @lecholas: Ah, they do come as classless p3ds? Not really ideal, but better than nothing. Hmm, as you say it would need to be a single pass, not done on each map update (as it is, I should probably cache the height info, but I wanted something that worked first, not that was super-optimised). I'll maybe experiment with your idea, but I'm making no promises. @TankbusterSPAFF & DMarkwick: The demo and video are set on Rahmadi, but I've overemphasised the bumpiness of the terrain for effect, so it won't look entirely as you'd expect! But anyway, the script should work on any map at all, since it reads in the terrain automatically (I've only personally tested it on Rahmadi and Sahrani though). The range of the map is also entirely dynamic, so you can show 100m or 100km of world on the map's surface! You may also need to damp down the vertical scale on very bumpy maps, otherwise you won't be able to see over the tops of the mountains! Experiment with the parameters to the SPON_Holo_map function... @zGuba: A wireframe view would be nice, of course, but I'm not sure if I'll go that way! I must admint that I do keep wanting to see the Death Star spinning around, zooming in, then my X-wings travelling down the trench...;)

Yeah, Sickboy has asked for that too. Roads are difficult because you can't find them with a command in-game, but buildings are a distinct possibility (or at least, urban areas). I remembered the surfaceType command just after I released, so expect properly coloured terrain in the next release (yellow sand & green grass, at least; currently defaults to green everywhere).

Oops, no it doesn't, but it should! Thanks for pointing that out to me! It would indeed be a bit confusing on a deathMessages enabled server getting two copies of each message! It was made originally for IC (but they didn't want to use it) and now since I expanded it for ATOW (who do want to use it) I thought I'd make it a bit more configurable. Obviously, in those situations the server is under control of the mod team, so it wasn't an issue (that is, needing to turn of my messages when the game was producing the default ones). (Original updated to v0.2.1: now disables SPON DeathMessages when server has BIS deathMessages on).

Another minor script released at OFPEC (not worthy of its own topic): Â Â - SPON_deathMesssages v0.2.0 (Configurable death notifications to replace the default ones).

SPON Scuba v0.1.0 Swim freely under the surface of the water (the other swimmers are AI, blowing out bubbles as they go; sadly the bubble-effect looks pretty naff in a static screenshot): Setting satchel charges underwater: - Released: 2008-10-23 (at OFPEC) - Install size: 38k (mission scripts) / 92k (addon version) - (mission version) 100% scripts with no addon dependencies - (addon version) Requires XEH (1.9 or higher), but a copy of the latest version 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 Overview Explore the vast undersea kingdom at last...and blow it up! Underwater swimming and demolitions. Requires that the SPON Core be installed in the mission (v0.5.1 or higher). Both SPON Scuba 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. Recommended for use with the ADO Combat Diver model (From ADO compagnie addon which requires ADO armes). I am not in any way affiliated with the ADO mod. Features   * Swim upwards or downwards in water (Uses <Helicopter Up> and <Helicopter Down>, which defaults to 'Q' and 'Z' keys).   * All equipment, that would otherwise be lost, is preserved while swimming and re-equipped when getting out of the water.   * Player can hold breath when swimming underwater, for a certain time, then starts taking damage. Resurfacing replenishes breath.   * A player with air-supply equipment will use that when swimming underwater, rather than holding breath, until it runs out (AI are considered to have an infinite air-supply).   * Accelerated swimming speed for players, at about 2x normal (pretending we are wearing a wetsuit and flippers).   * AI can be made to scuba too, though they won't do it normally (using SPON_Scuba_swimAtDepth function).   * AI breathe when underwater, producing bubble effect (particles).   * Compatibility:      o SP: Yes (not team-switch), but see limitations, below.      o MP: No      o Missions or addons that don't share key event handlers: No. Limitations   * When equipment is re-equipped after swimming, all large magazines will be refilled and primary/secondary weapons reloaded!   * As far as the engine is concerned, you are really floating on the surface of the water, so AI can still see and shoot at you at that surface position and you can't swim under boats.   * AI have infinite air-supplies.   * Can't touch off underwater satchel charges when inside a vehicle (not implemented yet).   * Satchels are placed instantly, when they should take a couple of seconds (not implemented yet).   * When using SPON_Scuba_swimAtDepth, the AI will instantly move to that depth. They won't smoothy swim to it (not implemented yet).   * When taking suffocation damage, there is no aural or visual indicator (not implemented yet).   * No limitation of depth that can be dived to. Should take damage below about 50m due to pressure (not implemented yet). Known Issues   * In MP, other players flicker quite badly and appear both in their actual submerged position and on the surface at once! This also means you can be shot by other people firing at your "surface-image", even if you are swimming far below the surface.   * When swimming very near the sea bed, movement for the local player can be a bit jerky.   * You can still take equipment out of the cargo of a boat while swimming, even though you already have gear preserved (when you get out, you can be carrying too much gear).   * AI getting reequipped when they get out of the water always equip their pistol, if they have one, rather than correctly going back to their primary weapon. Plans   * Harpoon gun!   * A lot more configuration options.   * A better display than using a hint.   * Fire pistol when treading water on surface (not firing when underwater or through water). Design Aims   * Explore an entirely new dimension of the game!   * Avoid addons, in favour of scripting, as far as possible. 100% mission-scripts version available! Credits   * Inspired by an underwater swim script at the start of a mission by Goons.   * Thanks to everyone at BIS and OFPEC forums for public testing, feedback and suggestions.   * Dyson, Loki, et al, for private testing.   * 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.1.0   * First release. (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>

It is most likely that you are using an addon or mission script that uses key-handling, which is not able to share key events with other addons. In this case, some addons will just not get notified when a key is pressed. Some addons are made to be compatible with others, such as all of the SPON components. Some have been fixed or patched and some just won't work in their current state. * S_NVG (manually adjustable night vision goggles) then you need to use the fixed version[/url] of it from Shole. * GMJ_sightAdjustment, then you have to use it along with the fix for it from Shole. In both cases you also need to use Shole's DEH (the release also includes the fixes and updates I've mentioned above).

Update v0.5.3 - Fixed   * Using the debug log can reset the value of nil.   * Adding multiple key event handlers to one key will cause only the first to be run [Reported by i0n0s].   * SPON_isMP is incorrectly set to true in SP missions (unless you are playing from the SP editor without saving the mission). EDIT: There was a silly mistake in v0.5.2, which I discovered just after uploading it, so I re-released it as v0.5.3. Sorry to anyone who downloaded the original update!

Seems the YouTube video for SPON Map has disappeared. I couldn't contact Woolridge, so I uploaded a copy I'd made to my own account. I'll take it down again if requested, of course. SPON Map v0.3.0 @ Youtube

@arye_r: You are right about the transition that you undergo when leaving the water. It is pretty kludgy, but I can see why BIS left it like that. When you enter the water, you start swimming when the water is at your waist, so the transition from walking to swimming is a natural one. When you get out again, the water is up to your knees, so there is a jump from swim to standing. Maybe someone could be persuaded to make a specific animation for it, otherwise I could try and find something a bit better than jumping from virtually lying down to standing up... --- I think I've solved the problem of dropping gear to a reasonable degree, but I need to do some more testing on that *fingers crossed* You still reload your weapons when getting out of the water, but you should be able to preserve magazine ammo counts as long as you don't fear a hideous workaround ;P I've tried unsuccessfully to enable the player to fire their pistol in the water. Like the fact that swimmers are automatically teleported to the surface, they are also automatically switched to swimming animation so I can't just switch to a shooting posture. If I continually spam animations on the diver then he will keep in firing stance, but he can't aim up or down *sighs* The other problem is that it seems weapons can't even be fired if you are in the water. If Z > 0 then firing works fine. If Z <= 0 then fire button just doesn't work at all! Sooo, unless anyone has a bright idea, no luck with that! An issue I am having in my WIP version is quite random crashes of the mission (core dumps, so no idea what is the cause). Loki has tested this version a bit too, but not had any problems. I assume it is something I changed since the original release. Anyway, just checking if anyone has had unexplained hard crashes with v0.1.0, because in my testing it seemed fine? Once I clear that particular problem satisfactorily, the new and improved version will be released. Sorry for the delay...and no, there definitely won't be global diving in that version. Maybe in a couple of versions...

ocramweb posted a screenshot of his minisub model in my SPON Scuba thread and I know other people are working on full-sized subs. No doubt Gnat is too, but he can answer for himself ;P

Yes, I was really impressed with the look of the water from below. I'm a bit disappointed by the way the whole sea is transparent until you get about 0.5m underwater though. Â Well, I suppose that is when your eyes go below sea level (height 0) as opposed to the water surface level (higher or lower than 0 based on wave height). That is why the flashlight is not visible until you get a wee bit underwater... For those interested in Gnat's work on making an addon-based scuba model which doesn't have the same MP limitations as this simple script-based system (Still very much a proof-of-concept though), he has started a discussion elsewhere.

I have already added scripts to allow a given number of air tanks to be stored in a vehicle or ammo box, to be picked up by player or AI (they are action-based, since I'm not working with real objects). If you are offering to donate models and images, then I could configure them as dummy magazines for use in the addon version, but since I'm a pure scripter this isn't something I'd bother with on my own steam, as well as liking to keep things addon-free if I possibly can (well, I have some config knowledge and absolutely no 2d/3d skills, so I have to play to my strengths). Well, you two aren't the only people to hassle me about globalising this. Although I'm softening a bit, I still have the fundamental problem: my system has people beneath 1m depth being setCaptived. That does rather change the way things work. Nevertheless, your suggestions seem reasonable and I suppose I should consider them some more... If I eventually cave on this issue, I might as well just have a single SPON Scuba and just give the "simple dive" functionality automatically and make the mission add a logic or call a function to enable full combat-diving functionality. I don't think it is worthwhile maintaining two code-sets, even if one of them was simpler (it would just be a sub-set, after all). The MP issues are only really in the setPossing...and that is common to simple and complex diving! Everything else isn't a problem in MP really! I like the idea of breath-times based on man types, too. Really, I hadn't got as far as worrying about individual configuration like that; just getting it playable was all I was worried about for first release.