Spooner

New release: - SPON Kits v0.1.0 (Standardised equipment kits). Updated: - SPON Status v0.2.0 (Informational display clearly showing order-of-battle, group members and vehicle crew). Added mission score information area and some fixes.

Just in case you were getting bored of the same old scripts, some more releases and updates for you! Please wake up and make some comments on the OFPEC threads so I can see what people like and/or want improving too. Released: - SPON Status v0.1.0 (Informational display clearly showing order-of-battle, group members and vehicle crew). Updated: - SPON Rangefinder v0.2.0 (Shows range, azimuth and elevation overlayed on the SOFLAM view) - SPON_deepEquals v0.2.0 (Compares nested arrays for equivalency)

Thanks very much! I've added the mirror link in this thread and the OFPEC SPON Core one. I'm more than happy if some or all of my scripts get mirrored elsewhere, as long as you include a link to the original OFPEC beta thread for that script (or to SPON Core beta thread if you are hosting a compilation).

Updated: - SPON Attachments v0.3.0 Sorry about the very buggy last release of this pack. Should now have fixed all the animation issues and the other bugs from the last version. Additionally made it fully compatible with teamswitch and, to a limited extent, MP. Thanks to Wolfrug for the bug report or I wouldn't have sorted it! NOTE: This version and future versions require SPON Core to be installed (up to now, SPON Core was just included in the demo for the debug log, but you could run SPON Attachments on its own). This should also help in making the script even more MP-friendly in the future. EDIT: I thought I'd make a SPON Scripts logo (in the original post) in case anyone wants something to use it. Well, it certainly shouldn't be appreciated for its artistic merits ;(

I appreciate the exposure, Foxhound! OFPEC and BIS forums only get so far, but plenty of people scan your site every day. While I think of it, feel free to not report the WIP scipts like SPON Map; Seems silly that the fact I still haven't finished something is news ;P Released: - SPON_deepEquals v0.1.0 (Compares nested arrays for equivalency) Updated: - SPON Attachments v0.2.0 (Attach/detatch ACOG and/or other accessories on weapons in-game). EDIT: This new version of Attachments is totally broken! I'll update it ASAP.

Released: - SPON Attachments v0.1.0 (Attach/detatch ACOG and/or suppressors on weapons in-game). (by the way, thanks to the fella, Foxhound, who put my scripts on ArmAholic.com, though I certainly don't expect a full re-post there every time I make a small release/update. Perhaps I shouldn't complain ;P).

That is a common mistake. There is no need to remove the "player" slot to replace with a "playable" slot when making MP missions. When in MP, the "player" slot just acts exactly like "playable" (and it makes it easier to test it from the editor without having to change slot types). You probably do want to remove extra playable slots in SP versions though, since otherwise the game would allow teamswitching.

I agree that bank-robberies seem rather too central to the game. Perhaps have each bank robbery take 10% of the money so that there are both more robberies (fun) and less people becoming paupers (not fun). Most "real" bank robberies empty the cashier drawers of money anyway; they don't empty the entire vault! Alternatively, you could scale the amount taken based on how much individuals have, which "taxes" the rich, reducing inflation, but doesn't cripple the poor. Thus, someone with $1,000,000 might loose 50% in a robbery, but someone with $10,000 might only lose 5%. Imagine a rich player, that stands to lose a lot in a robbery, hiring poor players, who stand to lose little, to guard the bank for them! The problems with the enter key on menus is often overlooked, since most people use the middle-mouse-button to select actions, not the enter key (which is another of the ArmA default keybinds for activation of actions). I'm sure that most developers aren't even aware that their dialogs are causing problems for people using the enter key. The easy workaround for this, that I commonly use, is to add a "dummy" button that is off-screen (y = -3;), has no action (action = "";) and also is the default button on the dialog (default = 1;). This way, when people use enter to select the action, they end up clicking this dummy button which doesn't cause them to do something they might not intend to do. Ideally, it would be better if ArmA hadn't mapped the keys like this, because even though the player can alter the binding, you really have to assume that people will be using the default keys.

I was also told that I couldn't play/edit the mission because content had been deleted: cawheeled3_tt650 \ca\wheeled3.pbo is one of the built-in ArmA addons and it has the both versions of the TT650 motorbike in it (TT650C and TT650G). I can't see why we should be having problems with that, since it is an integral part of ArmA itself. Perhaps, by not having a bike (or anything else from \ca\wheeled3.pbo, which only has the other motobike, the M1030) in the mission, then the addon hasn't been added automatically to the mission so it isn't being loaded up when the mission starts. If that is the case, all that would be needed would be to manually put ""CAWheeled3_M1030" and "CAWheeled3_TT650"" in the addOns and addOnsAuto arrays in the mission.sqm. Alternatively, just place one of each type of bike on Ramadi with 0% chance of appearance, which will force the pbo to be loaded properly at startup.

Well, I played around with this and had some fun. At least I couldn't find any error messages, which is always a good sign! I'm also very glad that the mission doesn't require addons, which will really help in making it accessible to a wider audience. A few suggestions (take them or leave them, as always): - I was a bit confused that the police base got ammo-crates full of every possible weapon (including exotic weapons like Javelins), but that there were still weapon shops. - When you open the bank dialog, you should start off selecting yourself in the deposit combo box. Otherwise, the default is to give money to civ1 (who I see getting rich when people are careless and forget to specifically deposit to their own accounts). - Although the intro is nice, I felt it was a bit long for one that I couldn't skip (fine the first time, but grating if I have to watch it all every time I log in). - Just a personal preference, but I like the independent officer model as a policeman, rather than the sniper. I prefer the idea of cops in berets rather than in fishing hats ;P - I'd rather have the jail camera close on "escape" or pressing a "close" button, rather than being on a set timer. You could do the same with the civ-cams but just charge the $500 every 5 seconds. - You seem to scale up a lot, for example giving players Javalins at the start and eventually being able to buy an Abrams tanks. Just because you are making an open ArmA mission doesn't mean you have to use absolutely every weapon and vehicle available, especially if you have only 16 players in the game (pistols vs an Abrams gets dull quickly). It would be quite reasonable to limit the cops and civilians so that equipment advancement is slow and that hardcore military hardware (tanks, etc) is never actually available. As soon as the players escalate to the heavy hardware, then it immediately stops being a cops and robbers game and becomes like every other military mission... - Although you have your own shops and banks, you might find my SPON Money script has some improvements over what you have (though my bank doesn't allow transfer to other players yet, it is something I'm planning to add along with other features). Still, your dialogs are perfectly adequate; I just thought since I'd written my dialogs for just this purpose, I might as well let you know about them, in case you'd missed them (and they were only released a couple of days ago, so that is likely). Good luck!

Released: - SPON_formatNumber v0.1.0 (Proper number formatting, e.g. 1234.567, to two decimal places with 1000s seperators => "1,234.57") Updated: - SPON Money v0.1.2 (Shopping and banking via dialogs) Hopefully, SPON Map will be the next thing ready to release (I hate testing complex MP scripts! ).

Thanks to everyone who is looking at these scripts. I do hope they live up to your expectations (and that you complain a lot if they don't, because otherwise they'll not get better ;P ) @Dr_Eyeball Ironically, I actually saw that you released that debug log just before I finished my version, perhaps a few days before I was initially going to release it. Since yours "worked" at that point, I didn't rush to release mine (I actually felt I'd missed the boat ;P ). Never mind, I learned a lot writing mine and it integrates much better with my own code, so... It is a great shame that people over here miss out on some of the stuff at OFPEC, but what can we do? @Commando84 "Movie-type radar" is certainly the right description! Everyone keeps telling me that that type of radar went out in the 50s, but I can't think of another type of radar that has ever been in a film that I've seen (even including the motion-sensor in Aliens - hehe!. Hopefully I'll eventually be able to keep both the film-buffs and reality-buffs happy when I extend the script a little (as described in my Plans in the OP).

Hmm, there really shouldn't be an issue with the links since they are just linking to forum entries at OFPEC. You can see them whether you are registered at that site or not, though you'd need to register to comment on them, of course. One possibility is that if you were attempting to right-click and save these links, you wouldn't get anywhere since they aren't file links, but rather links to other web-pages. Other than that, I can't see a problem (other than that the OFPEC forum can be slow to load; in which case, just give it time). "No spoon"; You could be on to something there

File paths (for execVM and the like) in scripts seem to be absolute (from root dir). #include paths in scripts/config seem to be relative rather than absolute. Sadly, since the pre-processor seems to not understand something like "..\my.cpp", you can be limited in what files you can #include (if the file that is #including is in a subdirectory). Nothing like consistency, eh?

You should probably start the "money script" in the init.sqf which would make it local to the player. You'd just have to check that you weren't running it on the server in that case. By having a editor-placed (global) trigger check alive at the spawn-in point (I assume this is what you meant), you are running the script on every client and the server. You would also be having problems with any player manually returning to the spawn-in location. At least, that is assuming I'm understanding you properly. Alternatively, you might want to look at my SPON Scripts, which deals with both cash and bank balances for every player, as well as shopping. Yes, I know there is a lot there, but the money/shopping/banking is what you might like to use. I'm currently working further on this part of the pack and will re-release it as SPON Money in the very near future, so that could make things simpler for you if that suits you at all.

Well, as this is the single thing that most often causes me bugs, specifically by mistyping a variable name and it just defaulting to nil, I'm really happy to have this appear in SQF, even if I have to wait for ArmA II. Many thanks! Any chance of getting this patched into ArmA, where use of a keyword in a script turned ON this functionality? This was how it was done in Perl: if "use strict" was in a script then Perl would raise an error on an unrecognised variable, the default behaviour would be to just assume that it was nil (or the equivalent in Perl). OK, not seriously expecting you to do this, but it would be great if you could. A question for clarification: If you private a variable, but don't assign to it, does it default to nil or would dereferencing such a variable also be an error?

Thanks for leaving it clear ! I already had a rangefinder overlay script that I made up the layout for, so I thought I'd modify it to fit over your nice optics. I've taken some liberties with the layout to make it look nicer with a non-proportial font (Specifically, by centre justifying the numerals), and used degrees rather than mils (I'll add a mils config option when I get around to it, but any sane/non-military person would probably prefer degrees anyway). Still, I'm torn between clarity and realism. Any comments? SPON rangefinder overlay WIP screenshot EDIT: Oooops, I didn't realise you were making a rangefinder overlay too, though I've pretended that azimuth and elevation are calculated and displayed by my rangefinder and there are a few more differences in implementation

Your points make sense. Here are some ideas I came up with, but never implemented: <ul>[*]Only spawn the invisible target near a real target when someone on its opposing side knowsAbout it above a set level (say 1.0 or higher). [*]If the real target is known about, use nearTargets to find out where the AI thinks it is. Spawn invisible target (or, say, 2 targets if knowsAbout is is greater than 2, 3 if greater than 3) in a random place near this perceived position. Prefer to place it above or to the sides of the target rather than below it (which would make the bullets very likely to hit the ground). Ideally, you'd not place the invisible target directly in front of the real target, but since a real target may be being engaged from multiple directions, this would be impossible to avoid. [*]Destroy and recreate the invisible target every few seconds so that the enemies do not continuously fire. Each time the invisible target is spawned, place it in a different place near the real target. [*]Monitor the enemy ammo levels and remove the invisible targets if all nearby enemies were low on ammo.

This is what I had assumed from what I'd read, but so far I've only defined dialogs in description.ext. I'd supposed that a dialog would be what I'd usually call a "modal window" and a display would be a "widget/component"? I would also very much like to see if it is possible to create displays that don't interfere with normal play as you've described. Please do keep us informed of your progress. I'll be moving onto looking at displays themselves soon, since I've been considering if it was feasible to create a window manager API by creating widgets on the fly with createDisplay. What I'd like to make is some of the normal GUI API components such as widget spacers and widget packers. Hopefully, this would make dialogs a lot easier to lay out for everyone and allow for more dynamic creation and alteration of dialogs and dialog components. I'm assuming, of course, that such an API hasn't already been created and I just don't know about it!

Don't think you can tell if someone has a specific action added, but what I do is to use setVariable to attach the action number to the object. That way, I can tell if something has an action attached and be able to know the index when I want to remove it at a later date. I set the variable to -1 when I remove the action again.

OK, I had a test mission open and saw this behaviour while I was writing this post. Since you denied this would work, I rechecked and I can't replicate getting the AI to fire over "fence" at all! Unfortunately, I didn't save the mission that I originally used for the test. I'm going to try to replicate the situation later, but until I've done that and saved the mission for posterity, I have to concede that I must be mistaken. Very sorry to have got anyone's hopes up! Talking out of my hat on my first post. Bodes well

Yes, this script is not modelling the effects of suppression in any way, rather it is encouraging the AI to fire supressively (specifically by being forced to fire, even when they don't think they have a killshot). The AI will only fire at a target within a mapper-placed trigger zone and it assumes the firer is unable to move and that there is no possibiliy of friendlies being between the firer and its target. There is a pretty severe bug in the 1.01 version of the script, acknowledged in the source code, which means that it only works for some hand or vehicular weapons. The example mission utilises the static machine-gun, which is not greatly affected by this problem, which causes the weapon to point directly upwards just before it is fired. To fix this, change in MDXSuppGunner.sqf (line 28): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_gun fire (weapons (_gun) select 0); to <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">proxyActor action ["useWeapon", vehicle _gun, _gun, 0]; Note: "proxyActor" is a GameLogic you've placed in the mission. Code also assumes that the primary (#0) weapon is the one being used for laying down suppressive fire (in both versions). Inspired by this example, I have invested a little time creating a (very slightly) improved script, using a slightly different methodology, since I want to have a more generic script, rather than having a static firer firing on a known area. I'm hoping that 1.08 with its nearestTargets function will make life a little easier to move forward. The big benefit of using this function is that the scripter has access to the perceived, as well as actual, locations of enemies, so that the target location can be less arbitarily determined (so far, both my and maddog's scripts fire at a random position near the true position of the target). Another big issue is to check the line of sight between the firer and target. Although it is reasonable to fire suppressively if the target is directly behind hard cover (either hitting the cover or just missing it), it isn't reasonable to fire if the target is blocked by an obstacle closer to the firer. I've seen some discussion about line-of-sight on this forum which seems to think that checking every couple of meters with nearestObjects (and then checking bounding boxes) is the best way to do this and maybe I'll look into that. Also need some heuristics to decide when to fire suppressively and perhaps to encourage half of a squad to suppress while the rest advances/outflanks/retreats. This is a bit more advanced than I can get my head around for now, but without it, suppression doesn't really have much practical use. Perhaps a compromise could be that the AI could be commanded to suppress while the played members of a squad maneuver? Don't know if MadDogX is still working on his script? Since I'm new here, I don't know what the unwritten rules about grabbing someone else's base idea and running with it are, so I won't post any code other than the above bugfix for now. Hoping to at least reopen discussion on this investigation...

There are actually lots of scenery items that the AI won't fire over, even with line-of-sight. This includes the standard "wooden fence" sandbags and even such things as fireplaces and traffic cones! I've also discovered that they won't shoot between the legs of the watertower *sighs* As far as sandbags go, they can't fire over "wood fence" (straight section of sandbags) or "wood fence palet" (same as wood fence, but with a wooden pallet leaning against it), but they can shoot over "fence" (this is a sandbag corner-piece of a slightly different style than the previous two). You are a bit limited in terms of what you can build with corners, but at least you can have some AI-friendly sandbag emplacements. [Note that I'm speaking here about 1.5 & 1.7 (both versions). I have my fingers crossed that the impending 1.8 might fix this, but who knows?]