Spooner

Overall, a very useful tool, which has progressed a long way since I last looked at it (version 3, I think). When compiling functions, please use "compile preprocessFileLineNumbers" rather than "compile preprocessFile". Doing this will give file and line-number information in the error window when it goes wrong (i.e. full information, as shown when there is an error in execVMed sqf). The same goes for your in-line functions. Use <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> myFunction = { ... }; rather than <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> myFunction = compile " ... "; in order to get more detailed error reports (assuming the script in which you are defining the function is preprocessFileLineNumbered, of course). I realise that doing this will make your stuff incompatible with OFP, but I don't believe you are trying parallel development for OFP/ArmA. Ignore me if this is the case (though you could always search-and-replace the preprocess* commands). Hopefully these changes would accelerate your development and allow users, like myself, to give more meaningful bug reports. Here is an error I got after selecting a dead man and opening the edit window (F1 mode, double-click): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> } else { _color = _civil; }; drop ["\Ca\data\kouleSvetlo", "", "Billb> Â Error position: <drop ["\Ca\data\kouleSvetlo", "", "Billb> Â Error Generic error in expression EDIT: I found it quite difficult to select things in the editor, until I'd worked out where the "sweet-spots" where. Consider using boundingBox and modelToWorld to work out the actual space used by the models (even if it is a bit rough). You can even use intersect to tell exactly what you've clicked on, at least with infantry. I can't get intersect to work with vehicles properly though.

The only network traffic is when you have server logging turned on (the data is currently being sent if that option is enabled, but for some reason it isn't coming up in the server debug log in this version. Need to fix that...). On both client and server, a lot of functions will be pre-compiled at startup, but there are no continual scripts started by Core itself. The only continual script in Core is run to generate the player list, publish SPON events, etc, and is run only if requested, either by calling SPON_monitorVehicles or by running one of the SPON components that needs this information, such as SPON Map or SPON Status. SPON_addPermanentAction also uses this, so that it can add GETIN/OUT handlers to all vehicles. This object monitoring script does a far bit of processing, but only does it every 15 seconds (by default), so shouldn't cause much of an issue.

Right, I thought it was that. I've added the semicolon for backwards compatibility, but I don't think it is worth a release just for that, since people should always try to use the newest versions of addons like XEH anyway. Future SPON releases will be compatible though.

(sorry for double-posting, but I need people to be notified of this bug-fix release) New Release - v0.5.1 - Modified * Should have significantly reduced slowdown in query mode. - Fixed * Error raised at start of mission, when playing on independent/resistance side (reported by SickBoy). * Two identical icon markers are drawn whenever one is placed, except in "self" mode. * When querying an item that has been sent by someone else to a specific target (tell/group/vehicle) the text for the target is either "0" or "true" (Actually fixed in v0.5.0, but not documented).

I don't want to discuss the details of how to hack such files on a public forum, but suffice to say that I can see how it would work and Sickboy was the one that explained it to me. I haven't actually tried it out myself. I assumed that the signature was on the pbo as a whole and not on the code after it had run through the pre-processor. Thus, anything in a /dta file would be outside signature protection. For a start, DSSignfile is only fed a pbo file, not any dta files, so it couldn't possibly know anything about them when signing. Thus, ArmA couldn't know anything about any dta file at the time it checks sigs.

Well, SPON Core and SPON Map both use XEH to start up, using the init handlers specifically. XEH init code for SPON Core: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> SPON_Core_init = "if ((time == 0) and (isNil ""SPON_Core_isAddon"")) then { SPON_Core_isAddon = true; [] call compile preprocessFileLineNumbers ""\SPON_Core\SPON\Core\initCore.sqf""; }"; The init for SPON Map is identical, but with "Map" replacing "Core". These inits run fine, but you'll notice that I didn't put on a semicolon at the end of the line (this is option in the syntax). You can see that the error you are getting is actually the end of the SPON Core init line running into the beginning of the SPON Map init line. Everyone else who's tried SPON Map/Core have had no problems, so I wonder if you are actually using an older version of XEH that didn't add a semi-colon to make the concatenation of the init lines safe? Please try using the newest version of XEH, which is, at this time, 1.7 (it is included in the SPON releases).

Well, I realise that having the addon only work with actions is not universally popular, since it is a bit cumbersome, but it maximises compatibility (except in the Warfare mission, but that isn't my fault ;P). Since I don't want to have two versions released simultanously, the only other option, of forcing keys to be used, would have caused more problems for more people, both breaking with missions and other addons that used key handlers and with anyone who had changed from default key bindings. I did consider using a /dta/SPON_Map.hpp file, but that is just an invitation for hackers to get around the whole signatures system, so I won't ever be doing that. The other issue is that to ask players to edit a file that will crash ArmA if there is the slightest mistake in it is not something I want to deal with. I was always intending to add a config system, specifically using a YAML formatted file in /dta folder that will: a) not crash your game if introduce an error into it b) not allow hackers a back door into signature protected servers c) have a format that is simpler and easier to understand than the hpp or sqf format config files that have been used before. I know people have been very confused configuring some of my scripts, such as SPON Money that required multi-dimensional arrays filled with config data, so this parser will be generally useful for me, too. Ultimately, I decided to release now, with maximum compatibility, rather than wait for a player-configurable version to be completed (or to develop the configuration system and leave out some actual map functionality like the grid overlays). I hope you can manage for now with an action ;P EDIT: Yes, it is my intention to replace everything on the normal map, but the only thing I don't see how I can replace is the notepad. Well, without writing an HTML parser, which seems like too much effort really ;P

SPON Map now uses actions (in addon and, by default, in the script version). This is to improve compatibility with other scripts/addons that grab the key event handler.

No-one except myself has attempted to use anything in SPON Core as far as I'm aware (I'd extremely doubt it). Probably because a lot of the features are not documented and...I haven't documented them outside of the files themselves because no-one has shown any interest ;P Be wary that several things in SPON Core, that have not been used in any SPON Component yet, may not actually work ;P The most important thing for third parties, I think, is the key event handlers, which allow everyone to share the one key event handler we have in the game.

Warfare is incompatible with my SPON Map addon, since SPON Map adds actions to the player and vehicles in order to allow the player to view an alternative map interface. My map is ideally suited to enhancing any COOP or MP mission with a vastly improved map GUI and inter-player communications. It works great with Evolution, for example ;P I might not have assuming it was the fault of your mission, but Warfare uses removeAction with hardcoded indexes in several places (though I couldn't find the actual place in a script that was deleting my action), rather than recording the indexes given when addAction is used and deleting those. This means that if other people add actions before Warfare does, then these third-party actions could be deleted by warfare while Warfare actions could be being left behind: warfare\MPMissions\Warfare.SaraLite\Client\Client_Killed.sqs: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> Line 3 : player RemoveAction 0 Line 4 : player RemoveAction 1 Line 5 : player RemoveAction 2 Line 6 : player RemoveAction 3 It also seems to prevent the trigger I use to compile a list of players. Again, couldn't find evidence of this in the code, but it could be something in Warfare deleting things. Lot less convinced this is the fault of the mission though, but thought I'd mention it anyway, in case anyone could see an obvious reason for this. @Warfare authors: Thanks in advance for looking into this matter for me. Please ask if you need any further information.

New release v0.5.0 - This is the first version available as an addon as well as a mission-script. - Added   * Now available as an addon, by popular demand!   * Grid measurement overlays added (suggested by TheDog).   * Mils are displayed, as well as degrees, when measuring angles.   * GPS, which can show grid coordinates (with 2-8 digit map reference), height ASL (on ground) or height AGL (in air), centre map on player (air only) or auto-track player (air only).   * Tools window, compass and GPS can now be dragged around the screen.   * When placing markers, you can click a "Send" button, rather than having to press the <enter> key (suggested by Q.Proper).   * When in an aircraft and looking at the map, an "EJECT" button is available.   * Markers are sorted alphabetically in the list and can be filtered with Alt + letter (suggested by Q.Proper). - Modified   * Compass made transparent to make it useful as a protractor (suggested by TheDog). - Fixed   * SPON Map and vanilla map aren't synchronised properly.   * Compass is shown even if it is disabled in the mission.   * Compass direction marker goes over the edge of the compass.   * Current time, and time of sending a message, are shown even if watch is disabled in the mission.   * When querying tell, group and vehicle markers that you have sent, the target is shown as a nil error.

It is good to know that the SPON Money shop FPS bug is particular to having the SLX mod running. I've had a quick look at the features of the mod and I can't see anything that would obviously cause a slowdown (but not tested it or looked inside the PBOs yet). Presumably other people have had the same problem before, but did they have the same cause or was another addon causing the problem in their cases?

Yes, using keys is always going to be a problem with compatibility, but actions are rather cumbersome. I'll release the action-based version soon, but so many other things are broken in that build that I want to get the other things fixed first. It should be obvious which addon is causing the problem, since it will be activated by key presses in some way. If you can't think what needs key-presses, then you probably don't use it any more and could live without it ;P If you give me details of what is causing the problem I'll be able to look into it, but I can't promise that it can be fixed as easily as Norrin's Revive script was.

Rather than set up another dozen threads on these forums, mirroring releases and discussions elsewhere, I thought I'd just keep a thread with links to all my releases over at OFPEC. I'll just update this post/thread when I release or update something. Please comment on the individual scripts in their appropriate threads, since I can't guarantee to reply very quickly if you reply to this thread (and comments on so many disparate scripts in a single thread would get very messy, very fast). Feel free to discuss my WIP projects here though (marked as coming soon). Note: Everything I have released is 100% mission-based scripts and has no add-on dependencies at all! SPON Core v0.5.0 - A suite of common scripts used by most SPON script packs. This includes a GUI-based debugging log. SPON Core is required by: - SPON Attachments v0.3.0 (Attach/detatch ACOG and/or other accessories on weapons in-game). - SPON Conversation (Discussion dialog with AI - coming soon) - SPON Helocasting (Water insertions from helicopter - coming soon) - SPON Map v0.5.1 (Freehand drawing and improved marker placement interface) - Now released at BIS forums - SPON Money v0.1.2 (Shopping and banking via dialogs) - SPON Radar v0.1.0 ("Old-school" long-range radar with a sweeping beam revealing "blips") - SPON Rangefinder v0.2.0 (Shows range, azimuth and elevation overlayed on the SOFLAM view) - SPON RearView v0.1.1 (Rear-view mirrors for most vanilla vehicles). - SPON Recognise v0.1.0 (Recognise friends standing next to you, even if friendly tags are off). - SPON Status v0.3.0 (Informational display clearly showing order-of-battle, group members and vehicle crew). - SPON VBIED v0.2.0 (Place car-bombs on vehicles). - SPON VehicleBinocs (Use binocs from within vehicles, including when turned out - coming soon) Other scripts of mine that don't need SPON Core, but that include debugging messages that can be seen if SPON Core debug-log is used: - SPON Kits v0.1.1 (Standardised equipment kits). My functions (no dependency on SPON Core or use of debugging): - SPON_deepEquals v0.2.0 (Compares nested arrays for equivalency) - SPON_directionName v0.1.1 (Convert numeric vector or direction into name, e.g. [1, 1, 0] => "North-East") - SPON_getWeaponType v0.1.0 (Find out the general type of a weapon, based on its name, e.g. "M9" => "PISTOL"). - SPON_formatNumber v0.1.0 (Proper number formatting, e.g. 1234.567, to two decimal places with 1000s seperators => "1,234.57") - SPON_viewVector v0.1.1 (direction the player's screen is "looking", rather than body or weapon facings) - Released at OFPEC Mirrors The above links are all direct to the OFPEC beta threads, so are guaranteed to get you the very latest version. No other mirrors currently (that are anything like up to date).

I'm extremely keen to avoid adding an in-game key-setting menu, since you'd need to alter the key settings (for this and the other SPON components that use keys) each time you played. This would only get worse as I make more SPON components (and hopefully if others decide to share SPON key handlers once the addon version is released). I have seriously considered a config file in \dta that could be edited by the player (even considering writing a very simple YAML parser to make the format a bit more easily editable and to remove the exploits possible if you just #include a \dta file directly into config.cpp or run it as SQF. I'd also be able to use the parser for all the player-config in my scripts, such as prices in SPON Money, since asking people to make complex config from arrays or in "valid" cpp format requires people to understand rather a lot and put up with ArmA crashing if they make the slightest mistake). Not sure if this still wouldn't just be a lot of work to serve the tiny proportion of the community that are prepared to open notepad... Ultimately, pleasing most of the people most of the time will have to do for now. My own fault for having so many scripts released at once (and not so many of them being "finished"). So, choose the best ArmA key actions I can and hope that people can edit their key settings within ArmA to change if they are completely incompatible (Yes, I know SPON key handlers don't update with changes in player config during a game, but that is something that I do need to sort out).

New version: v0.3.1 A couple of bug-fixes, a few tweaks requested by users and a shiny new compass. - Added * Added simple compass. - Modified * Resized SPON Map control to be the same size as the vanilla map (i.e. slightly wider in widescreen modes). * Doubled width of line drawn to aid visibility when fully zoomed out. - Fixed * SPON Map and vanilla map are not synchonised (that is, if one changes, the other does not update). * If another user dialog opens over the SPON map in the middle of you drawing something, future drawing is corrupted. * When more than one person has placed markers in MP, one player can have a situation where when placing new markers, one of the markers previously placed gains the colour of this new marker! [Reported by Claesson].

Absolutely, if you've reconfigured all the keys then you could still be stuffed. But any other options I've considered stuff you if using standard keys as well as slightly or greatly reconfigured the keys

No, by "rotate", I mean the rotate on the spot action for helos (X or C by default). This has little effect if you are moving and no effect if you are moving at any speed. Moving the mouse right or left banks you in those directions, not rotates you around your central vertical axis. Thus, by picking an action that is not used in vehicles (Well, X/C are used to turn in, but freelook+X/C isn't a key combination you'd normally use) and has limited use in helos, I thought it might be the safest from the options available (and the player can change the keys anyway). EDIT: The keys proposed are actually called "Left Pedal" (default: X or delete), "Right Pedal" (default: C or End) in ArmA. Sorry for confusing you by using the wrong terms. As you say, it is probably best I try it out and people can tell me how they feel then. I just wanted to see if anyone had obvious reasons why I really shouldn't try this combination.

I haven't stopped thinking about the RearView keys, but nothing seems to be perfect. My proposed keys are: <look> + <rotate-right> / <rotate-left (defaults to Left-alt + X/C, which is what I'll refer to them as for this post). In land vehicles, the rotation buttons have no other keys assigned by default, except "turn in", but there is always the possibility that they have been reused manually by the player for something else. In air vehicles, you would therefore be no longer to "look" while rotating in a helo, unless you turned on free-look (double-click L-alt) , but I think that wouldn't be a massive loss (compared to not being able to "look" while turning in any vehicle if I made it "look" + A/D). I am also planning to "lock" rear-view on with just one key, so it is easier to maneuver when using this view with less fingers than before ;P alt down C down (starts to look through right mirror). C up (rear-view stays on) use WASD to maneuver alt up (stops rear-view) Alternatively, alt+x/c to turn on mirror then alt+c again to turn it off. Or double-click x/c to toggle on and double-click x/c to turn it off again (could be easy to do by mistake?)? Or alt + double-click x/c to toggle on and alt + double-click x/c to turn it off again (with the option of holding the keeps for a temporary view of course)? Either of these have some consistency with leaning and other toggling commands. Any comments on this before I implement it? (only Mi17 has mirrors on the model, but I think it might be reasonable to give them on Blackhawk as well, if not on attack helos?) --- I've also decided to implement binocs inside vehicles, both when inside a vehicle that has windows (e.g. Humvee) and when turned out (e.g. T72 or Stryker). Would mean assuming the player hadn't redefined their binoc key (default B) as something used in operating the vehicle, but I think people can probably cope with that. There wouldn't be a pretty animation and no-one else would see the binocs, as they would just be scripted in, but I'd rather have the functionality without the graphics than not have it at all. I'm a bit busy at the mo, so this will be on the back-burner for a while. Any comments welcome though!

Not a problem. At least it is resolved to everyone's satisfaction now.

I installed SPON Map into the newest version of Norrin's script demo mission (1.49e) and I can still use the map after re-spawning (I double-checked by unpatching Norrin's script and yes, the Map was disabled on respawn). So not sure what the issue is. If there was a third script in the mission that used key handlers, then it would already be interfering with Norrin's old script or vica versa, so it can't be that or you would have noticed already. I can look into this again, but not right now. If you get anywhere in the meantime, tell me.

As you are using SPON Core anyway if you are using SPON Money, you could just (Assuming you use SPON Core v0.2.0 or higher): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ["Frog", { do this code on ALL machines }] call SPON_addEventHandler; ["Frog", [12, 24]] call SPON_publishGlobalEvent; This just wraps the PVEH and runs the code on all machines, including the sender (In older versions, it wrapped around setvehicleInit, so it had all the limitations of that method). Using Sickboy's general method is possibly better for most people though, since it doesn't rely on external stuff.

I went on the GOL server to try that mission out, then found I didn't have QG ;/ Oh well, hope you enjoy it (just don't spend forever converting all your missions over if you think you'll find the addon version more practical)! Incidentally, I've found a new bug in v0.3.0: If another window opens over the SPON map in the middle of you drawing something, future lines are corrupted (so don't open the SPON Core debug window, or any other window, while you are in the middle of something!. EDIT: I looked at the mission that i0n0s was having problems with. Apparently, SPON Core key handling is being overwritten by Norrin's revive script when you die, specifically when you run around in deathcam mode. It would be relatively easy to fix, since SPON Core conveniently has a special SPON_addKeyEventHandler function that allows multiple scripts to share the single available key event. However, in actual fact, it is actually an easily fixable bug in Norrin's script, since he doesn't actually need to get key events that way, so I'll get on at him to fix it ASAP. Thanks again for the bug report.

That does seem odd. Is there any chance that an addon or script is interfering with SPON Map, for example by taking over the key event handler (something else which reads the keyboard)? I don't see why this would happen at a respawn, though. I've tested this in the v0.3.0 demo on a dedicated server (no addons) and I have no problems using the map after I respawn. If you also have problems in the demo then it is probably an addon at fault; if you can work out which one is causing the issue, I can check to see which of us is the cause and see about resolving the issue. If you can't isolate the problem then I would be able to test your mission if you send it to me (my email is in every released file ;P) Future versions will default to using an action rather than a keypress to open my map, since that will ensure as much compatibility with other scripts as possible (suggested by Mandoble). Well, until SPON Core key event handling becomes a standard like XEH is ;P (By the way, converting this to an addon is well on the way. It will always be developed as both an addon, which suits mods, and a mission-script, which suits those that don't want their missions to have a unnecessary requirements which will exclude a lot of casual players).

Great to see someone using my range-finder in a released mission! I've added a link to your mission in my SPON Rangefinder thread.