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

[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