SPON Core v0.5.3 (incl. debug log) (ACCEPTED)

[Spooner]

SPON Core v0.5.3
- Released: 2008-10-04
- Install size: 114k (mission scripts) / 183k (addon version)
- (mission version) 100% scripts with no addon dependencies
- (addon version) Requires XEH (1.9 or higher), but is included in the release.
- Requires ArmA 1.09 or higher
- See attached README.html for full details

SPON components@YouTube

SPON Core is required by:
    - SPON Attachments v0.3.0 (Attach/detatch ACOG and other accessories to weapons in-game).
    - SPON CrewNotify v0.1.0 (Notification of mount/dismount).
    - SPON HoloMap v0.3.0 (3D holographic representation of the game world)
    - SPON Map v0.7.0 (Freehand drawing and improved marker placement interface)
    - SPON Money v0.1.2 (Shopping and banking)
    - SPON Radar v0.1.0 ("Old-school" long-range radar with a sweeping beam revealing "blips")
    - SPON Rangefinder v0.3.0 (Shows range, azimuth and elevation overlayed on the SOFLAM/laser designator view)
    - SPON RearView v0.2.1 (Rear-view mirrors for most vanilla and QG vehicles).
    - SPON Recognise v0.3.0 (Recognise friends standing next to you, even if friendly tags are off).
    - SPON Scuba v0.1.0 (Underwater swimming and demolitions)
    - 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).
    
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).
    - SPON_deathMesssages v0.2.1 (Configurable death notifications to replace the default ones).

My functions (no dependency on SPON Core or use of debugging):
    - SPON_deepEquals v0.2.0 (Compare 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 LOS v0.1.0 (Calculating line of sight)
    - SPON_viewVector v0.1.1 (direction the player's screen is "looking", rather than body or weapon facings)

My scripts used by third parties:
    - SPON Sensor - Vehicles detected by radar appear on everyone's map (Included in PRACS Beriev Be-32k addon).

Overview
Core components required by most of the other SPON script packs (the README for each package will say whether it actually requires SPON Core and what minimum version is required). Many of the features provided here might be of use in creating your own mission scripts.

SPON Core is avilable in two versions. One is an addon and the other is mission-script-based which does not require any addons to be installed on client or server. It requires ArmA 1.09 or higher.

Features
- Standard
    * Provides common features used by other SPON components, such as SPON VBIED, SPON Recognise and SPON Map.
    * User event handling: Any player or server can broadcast local or global events. Those that have previously registered for the event will have their code run (Used very similarly to standard ArmA events).
    * Broadcasting object variables with SPON_publicObjectVariable.
    * Key event handling: Allows de-coupled key event handlers to be set up (normally a new key event handler deletes any existing handler).
    * Some global variables (read-only) to complement the built-in "isServer".
    * SPON_formatTime function is available: Formats an elapsed time, in seconds, as 0:00:00 or 0:00:00.000, which is appropriate for formatting elapsed time ("time" command), but not time of day.

- Optional
    * Debug log:
          o Makes a permanent record of all debug messages, viewable in a window, thus not cluttering up the chat window with debug messages.
          o Allows the client to view all debug messages that have been generated on the client or the server at any time (JIP clients can only see server messages generated after they joined)!
    * Automatic monitoring of in-game men and vehicles:
          o Lists of player, men and vehicle objects in the mission are kept updated.
          o SPON events are published whenever any of these is found on the server for the first time and when a player is first or last found on the server. These events can be used to perform init actions on the objects, without the need of addons (Although init might be slightly delayed after the object has been created).

Limitations

Compatibility
    * Addons and Scripts:
          o If SPON mission-script is used with SPON addon, only the addon version will be run (so ensure your addons are up to date).
          o (Mission-version only) If SPON Core debug log is used with keys, rather than action to open the map, it is not compatible with any other script or addon that detects key-presses (unless it uses SPON Core or Shole's DEH key-press handlers, of course).

Known bugs
   * Variables updated with SPON_publicObjectVariable are not automatically updated for JIP players (though JIP players will get any new values sent after they have joined).
   * Debug message logging on dedicated servers is currently broken.

Plans
    * Ensure that SPON_players_* arrays are synchronised across all machines and updated immediately on join/leave in progress by another player.
    * Allow registering global event names, so that they can be published using less bandwidth.
    * Expand USAGE section in README.txt, to make the systems more usable by third parties

Credits
    *  Provide a common set of scripts to minimise the repetition of scripts within the other SPON components.
    * To provide a strong base for anyone developing SP, and especially MP, missions.
    * Consistent GUI across all SPON GUI-based components. Font/colour schema can be chosen from a selection of standard schema.
    * Avoid addons, in favour of scripting, as far as possible. Addon version and 100% mission-scripts versions are available!

Change Log
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).

(See readme.html for full details of changes before current version).

Download SPON Core v0.5.3

[Spooner]

Something I forgot to mention, but which would be critical if you wanted to develop your own SPON events: event names must follow OFPEC global variable naming conventions. Although not strictly covered by OFPEC naming conventions, since they are just handled as strings, it is important that if third parties create new events that they do so in their own namespaces (e.g. All events I create will be prepended with "SPON_").

[Spooner]

Uploaded a new version (v0.1.2) which is just a bit of tweaking and bug-fixing; See the changelog in the original post for a list of changes. Also released first version of SPON Rangefinder and updated SPON VBIED.

[hellop]

In line 201 of recordVehicles.sqf I see:

if (not SPON_recordVehiclesRunBefore) then
{
   SPON_recordVehiclesRunBefore = false;  //this does the same thing


So, if SPON_recordVehiclesRunBefore is false, this if statement runs, then it sets it to false again, redundantly.  Maybe it should be set to true or the assignment omitted?

-hellop

[Spooner]

Crap, people are reading my code ;P

You are right; that code is indeed redundant, but all it does is run a few unnecessary lines which do no harm. Still, thanks for pointing it out to me!

I'm actually in the process of rewriting SPON Core, so most of the object monitoring system will be going in the bin soon anyway. Although I feel that there are a lot of great things in Core, a lot of the things are quite naive in execution and a lot of things got left out because I couldn't get them working. I won't be re-releasing, however, until ArmA 1.09 is released as a final version, since I will be making heavy usage of the great new command addPublicVariableEventHandler.

[Spooner]

Although I've been out of the game for quite a while, I have updated SPON Core for ArmA 1.14 (basically, it now uses publicVariable events rather than init-commands for all of its internal communications). All existing SPON components should still work and some of them I'll re-release to take advantage of the improvements in the Core. The main advantage, to you lot, is that now I've finally released SPON Map which was easier to get working with the newer functionality.

[Mr.Peanut]

Spooner,
Did you come up with that "any name for a recursive function" trick in deep equals? It is great!

[Spooner]

I can only say that I think that I did work that out myself, since I realised that people might want to name the function themselves. Quite a while since I wrote it though, and I've been "away" from ArmA scripting for quite a long time, so apologies if I forgot that I "borrowed" the idea ;P

EDIT: Oops, just realised I removed SPON Core v0.1.2 files and failed to add the SPON Core v0.2.0 ones. There is a copy of SPON Core v0.2.0 included inside the demo of SPON Map in case you are desparate. I'll try to correct this error ASAP.

EDIT-2: CORRECT v0.2.0 FILES UPLOADED.

[Spooner]

New release
v0.5.0 - This is the first version available as an addon as well as a mission-script.
- Added
    * Assertion macros for design by contract (SPON_ASSERT(), SPON_ASSERT_FALSE(), SPON_ASSERT_OP() and SPON_ASSERT_DEFINED())
    * Error dialog with SPON_ERROR() macro provided to raise errors.
    * SPON_addPermanentAction implemented.
    * Added stringtable.csv to allow for internationalisation.
    * Now available as an addon as well as a mission script.
    * Lots of new utility scripts which might get documented one day.

- Modified
    * Simplification: You now just #include "SPON\Core\ui\core.hpp" (before you included common.hpp and, optionally, debug.hpp)
    * Merged debug.inc.sqf with macros.inc.sqf
    * Debug log now opened via an action by default

- Fixed
    * SPON_isMP is false on the hosting player's machine in non-dedicated MP games.
    * Debug mode parameter is case dependent.

[U104]

i have a problem with the download i get the zip but the is nothing in it. 

[Spooner]

What exactly are you trying to download? There is an attached zip for SPON Core, but that has been fine for 130+ people before, including myself and Bedges today. All the links in the release post (To SPON Attachments, etc) are links to other release threads, they aren't "right-click and save" links.

[i0n0s]

Hi,
I have a little problem with the license you use: It's too viral.
I understand why you have implemented that license and support this reason.
But the GPL prevents me to use these scripts with any foreign scripts because the GPL forces me to put these under GPL too.
Since they are foreign scripts I simple don't have to right to put that script under GPL and I can't use any foreign scripts.

So I ask you to change the license to a less or non viral one (for example MPL) so it can use with other scripts easily.

[Spooner]

Amazing! I'm sure you are the third person to notice I have applied a licence to my SPON releases and, no doubt, the first one take notice of it ;P

I did think about this issue when I originally released my code, and consciously chose the GPL over less restrictive licences (such as the LGPL and MPL). However, it was never my intention to restrict the community from being able to use the functionality of the SPON suite.

This whole thing rather depends on your interpretation of both the GPL and ArmA/modding in general. I'm no expert on licensing, so I might be completely out of whack from the very beginning. I was seeing ArmA as an interpreter, so that separate scripts were effectively separate programs running within separate virtual machines. Therefore, as long as there wasn't direct interaction between these scripts, the licensing wouldn't come into play. Now once those scripts start interacting, such as a third-party script utilising functionality from SPON Core, then that would in fact require GPLing that third-party script (which would mean that you wouldn't have to worry about "foreign" scripts that didn't require SPON components to work). On further consideration, this all falls down once my scripts are packaged into a 3rd party mission or my addons are packaged in a 3rd party mod, rather than simply being used together by the end-user, which I suppose would invoke the viral nature of the GPL. It all seemed simpler when I actually decided to use the GPL about a year ago ;P

Anyway, too early in the morning for me to make a considered decision, so I'll leave off that for today. What you are saying does seem reasonable though and I'll see what I can do about it for the next release (probably in about a week). If you have any further thoughts on the matter, I'll certainly bear them in mind.

[i0n0s]

Thanks for your reply.

Waiting for your decision.

[U104]

What exactly are you trying to download?

* SPON_Core_v0.5.0.zip when I click on the link, and tell it to download to my main ArmA directory, two seconds later it says it's done. the file says 0 Kb and when I try to open it, it is empty.

[Spooner]

I've passed the issue on to our web monkeys. Until that gets sorted, I'd be happy to email you a copy if you put your address in a PM.

EDIT: Saw you have public email address in you profile. Just sent you SPON Core directly.

[Planck]

I just downloaded this without a single problem.   


Planck

[U104]

ty for the help but it was my PC my dads PC downloaded it fine.

[i0n0s]

Anything new on the licence?
My interpretation of ArmA would be that ArmA would be the operation system, missions will be the binaries and addons libraries.

[Spooner]

That seems a reasonable interpretation. Addons, however, are sometimes just "binaries" in and of themselves, for example when started by XEH as mine are (well, only the components, such as Map, since Core is most definitely a "library" in any case). But regardless of the addons issue, I think we can both agree that there are definitely licensing problems as soon as you include my mission-based scripts in your mission release unless the mission as a whole is GPLed. I think I am going to move everything over to LGPL in the next release, unless you can point out a glaring problem with this particular license. As far as I can make out, it is essentially a non-viral GPL, so could be packaged and used with proprietary scripts. I feel like a bit of an idiot for not thinking this through more thoroughly last year; good job virtually no-one cares about licensing

[i0n0s]

Don't looks like a problem.§4 allows a combined work when you don't restrict modifications of your code.
The only think may be that mission developer has to put the licence to their work (just include the text file into their mission).
Maybe you include an exception to LGPL so that it will be just enough if the mission developer credit your work.

[Killswitch]

Neat stuff, this SPON Core 

According to the documentation, the event named "SPON_playerConnected" is said to be "(local / Player has joined the game)". Disambiguate "local", please.

Is it part of a general callback extension mechanism for the single-callback-only BIS implementation of onPlayerConnected?

What I need: a way to add server-side onPlayerConnected handlers. Is "SPON_playerConnected" the solution?

[Spooner]

The SPON event SPON_playerConnected is not using onPlayerConnected at all. It is actually just when the local machine recognises a player object with a name that it hasn't seen before (read from large trigger). When it does that, Core updates the SPON_player_* arrays and then fires off the event. Thus, I can even use it in client-side addons or when a third-party script uses the onPlayerConnected handler, though it does mean that there can be a little delay before you are told about a new player (up to 15s when someone JIPs, though no delay at init).

You'll notice that it will always give you a living player object rather than just the name of the new player, so in most ways, it is more useful than the BIS onPlayerConnected (e.g. I generally use it to add event handlers), unless you really need the player ID. There are also SPON_manFound and SPON_vehicleFound events that do the same sort of thing. In the mission-script version, these are a way to have object init code run, albeit not immediately on object creation (in an addon, of course, you could use XEH for this)...

I will be incorporating XEH init handlers in the addon version soon, to avoid the delay on player JIP or script-based soldier/vehicle creation. The mission-script version will continue to be delayed, of course, but as far as a 3rd party script is concerned, the two versions are interchangeable.

(Ironically, I originally planned to hook up with onPlayerConnected for this event, but I was using object inits for broadcasting SPON events and I couldn't work out why they were crashing my game all the time; it was actually recursive use of vehicleInits, but I just couldn't work it out at the time. Now, however, with the advantage that I can use these SPON events in client-side addons, give an object reference and avoid a bit of bandwidth usage, I can't see a reason to go back to using onPlayerConnected with all the compatibility issues that would bring me; I already have enough problems with the SPON Core key event handlers being corrupted by other scripts using the single-callback-only 46-onKey handlers!).

[Killswitch]

Aha - I stand enlightened. Thanks for the clarification.

[Mr.Peanut]

Could you explain why you need to use XEH for your addon version?

[Spooner]

Well, otherwise I couldn't start the scripts unless they were specifically called from the mission. I think most people appreciate the fact that SPON Map can be used as a client-side addon, not required by the mission.

The other reason is so that I will be able to use init handlers to pick up new men and vehicles in the addon version (while keeping this transparent to users). At the moment, both script and addon version use a large trigger to detect created objects; in a script, I have no choice, but in the addon, I will be able to replace this trigger entirely by using init handlers, which will both reduce load and the delay before the trigger contents are checked.

[Spooner]

SPON Core v0.5.1 released

Modified
    * Replaced GNU Public Licence (GPL) with the less restrictive Lesser GPL (LGPL).

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

[Dwarden]

btw i use this to detect adddon versions as i use mission scripts

Code: [Select]

if (isNil 'SPON_Core_isAddon') then
 {
SPON_Core_isAddon = false;
};

if (not(SPON_Core_isAddon)) then
{
[] call compile preprocessFileLineNumbers "SPON\Core\initCore.sqf";
};

// should prevent the script running while clients use SPONr addon version

if (isNil 'SPON_Recognise_isAddon') then
 {
 SPON_Recognise_isAddon = false;
 };

if (not(SPON_Recognise_isAddon)) then
{
call compile preprocessFileLineNumbers "SPON\Recognise\initRecognise.sqf";
};
do i need this still ?

[Spooner]

Yeah, that would do it fine (And leaving it in won't cause any harm). I only left out doing that very thing since I had a more complicated system of registering and comparing version numbers and running either the mission or addon version of the scripts, based on which one was newer, but I didn't get it working properly and just left it out (and then forgot about it ). Should have, at least, used the simpler system in the mean time, rather than leaving the scripts to bomb out on each other as I did.

Anyway, this manual checking is no longer needed for SPON Core, or future releases of the other SPON components (Map and Recognise should get updated very soon anyway, so I've not made a specific hotfix for them on this issue).

Thanks for using the scripts and I appreciate the feedback on these issues you are giving me!

[Dwarden]

ah configname/getnumber etc. yeah that's more complicated and i decided it's easier just on/off

[Mr.Peanut]

So Spooner, when are you going include an addGlobalEventHandler?

[Spooner]

SPON_addEventHandler catches all SPON events. However, you raise SPON events using SPON_publishLocalEvent, SPON_publishRemoteEvent and SPON_publishGlobalEvent, which is what determines which SPON event handlers fire.

[Mr.Peanut]

Yes, but looking at your code it seems to me that you can only add event handlers locally. Am I mistaken?

[Spooner]

Yes, the whole SPON event system isjust an improved wrapper for publicVariable events (though my events system predates publicVariable events and used to use object-init for messaging). Just like PV events, you register handlers locally, then publish the events whereever you want.

[Killswitch]

If you use SPON_Core as an addon, how would you go about getting SPON Core into "debug mode", ie the equivalent of calling

Code: [Select]

["DEBUG_CLIENT_SERVER", nil, true] call compile preprocessFileLineNumbers "SPON\Core\initCore.sqf";in a mission using the script based SPON Core?

[Spooner]

This is something I need to address properly at some point, but right now, you could use a fudge. You could either edit the config.cpp in the addon to start core up the way you want or you'd call, in the mission init:

Code: [Select]

_debugOnServer = true; // Perform server debugging (actually broken at the moment, but no harm in enabling it).
_useActionForDebugLog = true; // To add a universal action to open the log, rather than using key-press to open it.
[_debugOnServer, _useActionForDebugLog] call SPON_initDebugLog;
(though, as I say, the server debugging is broken currently ). You'd not get debugging for any addon init if you used the latter method though...

EDIT: ...But you would get debugging for addons after init time.

[Killswitch]

Roger on the fudging. Thanks!

[Mr.Peanut]

I have a suggestion for the next version. It would be a server side SPON local event wrapper for the ArmA onPlayer(Dis)Connected.

Just like PV events, you register handlers locally, then publish the events whereever you want.

But being able to PV code means one could register handlers remotely.

[Spooner]

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

[Spooner]

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).

[Spooner]

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).

Download SPON Core v0.5.3

EDIT: 0.5.2 had a silly bug in it I saw as soon as I'd released it, so I quickly updated it!

[Dr Eyeball]

Suggestion for future version.
To make the formatTime.sqf function more useful and in preparation for Arma2, alter your parameters to accept the format string to use, instead of using a boolean.

See fn_vbs_timeToString for recommended format.
I have adopted the same technique now, but slightly different formats. See source fn_TimeToStr.sqf.

There's no true format parsing required, so it's very simple to do since the format permutations are limited.
An invalid parameter simply defaults to the default format.
It also makes it more readable, since you don't need to lookup your function to know the format used by the boolean parameter.

[Spooner]

The SPON Core/Rangefinder inside ACE is exactly the same as the only released separately, so it can be used in exactly the same way. Thus when you play ACE, there is no difference to having SPON Core and SPON Rangefinder loaded separately.

Your situation depends on what exact combination of addons and mission scripts you have running:
* SPON Core addon or mission script: OK.
* SPON Core addon + any SPON component addons: OK.
* SPON Core mission script + any SPON component mission scripts: OK.

* SPON Core, or any SPON component, running as both addon and mission script at the same time: OK (Addon takes precedence, but will still be configured by the settings meant to affect the mission).

* SPON Core mission script + any SPON component addons: Not OK (SPON component addons always require SPON Core addon).

* SPON Core addon + any SPON non-GUI component mission scripts (does not have a ui directory, such as SPON Scuba or HoloMap): OK

* SPON Core addon + any SPON GUI-based component mission scripts (i.e. has a ui directory, such as SPON Map or Recognise): OK, but needs a workaround.

The workaround is to just to add a small part of Core to your mission (25k, so a lot smaller than whole of SPON Core):
* Place a "Game Logics\SPON\SPON Core: Requre" logic object in the mission editor, to ensure that it can't be played without having the SPON Core addon loaded.
* Include the SPON\Core\ui folder (just hpp files), leaving out all the scripts and other bits of SPON Core.
* At the top of the description.ext:
Code:

#include "SPON\Core\ui\core.hpp"

Remember that you can just leave SPON Core mission scripts in your mission and you have no problems at all (all you are doing is wasting some space). This is the simplest option and does not require that the mission be played with SPON Core addon, so is the one I recommend really.

Sorry that this issue is relatively complicated, but you have to remember that virtually no other ArmA modder releases addons and script versions of the same items, let alone ones that are so cross-compatible and simple to use

[awotter]

Hi Spooner,

I can't seem to get SPON debug to work with ACE. I have no problem running your demo and I set up a mission using your SPON instructions and I can get that to work in regular ArmA (QG), what am I missing?

I've been working with Doomguy's WACO trying to port it over to Avgani and in the course of trying out some new things I've run into a bug that I can't track down via ArmA.rpt.

[Spooner]

Well, please ensure you are using a proper ACE edition of WACO. The latest SPON Core would be in the latest ACE, so that can't be an issue. Can't really think of other issues, but have you tried getting SPON debug to work with ACE with a simple (non-Warfare) mission?

[Spooner]

Ah, you need to refer up a few posts to where I posted a solution to this issue.

[alef]

README says there is a debug.inc.sqf, which should be SPON/Core/macros/macros.inc.sqf instead.
DEBUG_OFF instead of DEBUG_NONE.
( I'm reporting, being my 1st time using this resource )

[Spooner]

Ack, thanks for that! It was debug.inc.sqf and macros.inc.sqf originally, but I merged the two include files into one a while ago I'll fix it when I move the last bits of the readme onto the Core wiki.

I'm terrible at keeping my readme's consistent with code changes and most people don't point out these sort of things (and I imagine most people use the addon versions anyway, where there isn't a need to mess about so much).

[Spooner]

Information regarding SPON components in Arma 2.