Jump to content
igneous01

IGN Events Framework v1.1 - Global MP Events / Remote Execution Added!

Recommended Posts

o109w8.png
I am proud to present a new framework for mission makers to use.

 

Thanks to the initial feedback, the framework was rewritten to utilize the latest scripting commands added for improved performance, as well as proper MP support with broadcasting / global events. Global events can be raised from any machine, and handlers registered to on client machines are remote executed when an event is raised. JIP is still being looked into for integration.

 

IGN Event Framework gives mission makers custom event support, being able to define events, add handlers, and raising events. 

 

The framework was originally developed back in 2014 when I released Tiger Shark on the steam workshop (which heavily used it for updating tasks and controlling mission flow). Most of the 'pilot xxx' missions on Steam Workshop also use this framework.

 

Download: http://www.mediafire.com/file/6c5o9louso1583o/IGN_EH_v1_1.zip

 

The download comes with demo missions, documentation, and in 2 flavors - the typical scripted approach, and CfgFunctions approach, with instructions on how to install using both. There is also debug mode support,

 

Documentation is included with a list of all calls and explanations for each in the Docs folder.

There is a manual.pdf included, but it's not complete by any means.

 

There are also some functions for creating functors/function objects, but this is still work in progress.

 

Changelog:

 

v 1.1:

- added path parameter to IGN_EH_INIT.sqf, which lets you specify the path where IGN will compile scripts from. Useful if you wish to move the folder to a different directory.

- compileFinal used instead of compile

- rewrite of all functions to utilize new scripting commands (push, params, etc)

- added proper MP support with global events and remote handlers

- added new demo mission IGN_EH_MPDemo1_DedicatedServer.VR which showcases using events on dedicated server with clients

- updated documentation

 

v 1.0 - Initial Release

 

Demo Missions:

IGN_EH_SPDemo1.VR - a mission with 3 tasks using the traditional scripted approach

IGN_EH_SPDemo2.VR - same mission, this time using the CfgFunctions approach

IGN_EH_MPDemo1_DedicatedServer.VR - same mission, tweaked to use both Global and Local events

 

Please feel free to leave feedback and any bugs encountered using this.

  • Like 3

Share this post


Link to post
Share on other sites

looks interesting. i've been using something similar for both addon and mission stuff. your stuff looks real organised. i will probably learn some new stuff from looking through it. thank you for sharing.

 

i was wondering since i couldn't find it yet. what method do you use to cycle through your EHs? like what kind of loop. addstacked frame EH? BIS_fnc_loop? just curious.

 

sorry if you're not lookign to answer specific questions. np. i'll eventually find it :dummy:

Share this post


Link to post
Share on other sites
  On 2/9/2017 at 2:03 PM, bad benson said:

looks interesting. i've been using something similar for both addon and mission stuff. your stuff looks real organised. i will probably learn some new stuff from looking through it. thank you for sharing.

 

i was wondering since i couldn't find it yet. what method do you use to cycle through your EHs? like what kind of loop. addstacked frame EH? BIS_fnc_loop? just curious.

 

sorry if you're not lookign to answer specific questions. np. i'll eventually find it :dummy:

 

As far as I can see these are not Events based on Code Conditions checked every Frame. You basically Add an Event and then raise it manually in a Trigger or something. It's basically a Signal-Slot system.

See this from the functions_docs

// thread 1 only tracks player death
_thread_1 = spawn {
	waitUntil {!alive player};
	[eventUnitDead, player] call IGN_fnc_raiseEvent;
	// this can be called at the same time as the other one!
};

 

After a short look at the code my conclusion: Practical for some missionmakers. Code looks like its 2 years old. Performance very much not optimal. (call compile string in a couple places :/ and very old not using new engine possibilities)  But probably not seriously bad. I wouldn't use it. If i need to execute a function at an event I would just call that function. If i need to execute multiple functions I would just call these functions.

Share this post


Link to post
Share on other sites

ah i see. didn't have time to look deeper.

 

  On 2/9/2017 at 4:41 PM, dedmen said:

 (call compile string in a couple places :/ and very old not using new engine possibilities)

 

who would do such a horrible thing?! :don9: btw. i think he mentioned he wrote it a while back so tha would explain that.

 

i think i'll go check it out and play with it a little. seems like a cool concept.

 

EDIT: ok dedmen explained it to me. interesting. i will definately go check out your mission. i hope it's on the workshop

 

 

Share this post


Link to post
Share on other sites

From a quick look it does not seem that different from BIS_fnc_addScriptedEventHandler other than for each different handle you create it adds a invisible helipad to your mission rather than using a namespace or existing object. It also does not handle returns from the events like the BI version can.

TBH i doubt id use it over the BI version.

Share this post


Link to post
Share on other sites
  On 2/9/2017 at 5:46 PM, killzone_kid said:

IGN? http://uk.ign.com/ IGN?

Igneous01 IGNeous01 IGN

 

  On 2/9/2017 at 5:31 PM, Larrow said:

From a quick look it does not seem that different from BIS_fnc_addScriptedEventHandler other than for each different handle you create it adds a invisible helipad to your mission rather than using a namespace or existing object. It also does not handle returns from the events like the BI version can.

TBH i doubt id use it over the BI version.

 

It really looks like it's the same just with slightly worse performance and that you have to include extra scripts instead of using the Game provided ones. BUT! the IGN system is MP compatible. From what i can see from the wiki the BIS scriptedEH's don't support remoteExec and stuff Scratch that. The IGN System has functions for Server and Client handlers but I couldn't find any remoteExec or BIS_fnc_mp or publicVariable EH. From what i can see it only executes the handlers locally no matter what you do. Well you can run a spawn loop on every client to wait for the event to have the raised variable set to true.

Also I didn't know about spawning the Helipads.. If he just want's to store variables he can use a Location instead which should have lower performance impact.

This Framework seems pretty useless to me.

 

But after rewriting most of it and cleaning everything up and adding MP functionality it may be very useful to some people.

Share this post


Link to post
Share on other sites

man. now i feel like i opened a can of worms with my initial question. sorry igneous01.

 

sorry for making everyone shit on your script. i'm sure it's just their assburgers way of giving you tipps how to improve it :down:

  • Like 1

Share this post


Link to post
Share on other sites
  On 2/9/2017 at 6:15 PM, dedmen said:

Igneous01 IGNeous01 IGN


The fact that it was capitalised made me look into this thread assuming IGN network had ventured into Arma with some games related stuff ;)

Share this post


Link to post
Share on other sites
  On 2/9/2017 at 4:41 PM, dedmen said:

 

As far as I can see these are not Events based on Code Conditions checked every Frame. You basically Add an Event and then raise it manually in a Trigger or something. It's basically a Signal-Slot system.

See this from the functions_docs

// thread 1 only tracks player death
_thread_1 = spawn {
	waitUntil {!alive player};
	[eventUnitDead, player] call IGN_fnc_raiseEvent;
	// this can be called at the same time as the other one!
};

 

After a short look at the code my conclusion: Practical for some missionmakers. Code looks like its 2 years old. Performance very much not optimal. (call compile string in a couple places :/ and very old not using new engine possibilities)  But probably not seriously bad. I wouldn't use it. If i need to execute a function at an event I would just call that function. If i need to execute multiple functions I would just call these functions.

 

Yes, it uses some old scripting commands (I'm getting up to speed on all the new ones they added, especially the collection commands for pushback and sort).

  On 2/9/2017 at 6:15 PM, dedmen said:

Igneous01 IGNeous01 IGN

 

 

It really looks like it's the same just with slightly worse performance and that you have to include extra scripts instead of using the Game provided ones. BUT! the IGN system is MP compatible. From what i can see from the wiki the BIS scriptedEH's don't support remoteExec and stuff Scratch that. The IGN System has functions for Server and Client handlers but I couldn't find any remoteExec or BIS_fnc_mp or publicVariable EH. From what i can see it only executes the handlers locally no matter what you do. Well you can run a spawn loop on every client to wait for the event to have the raised variable set to true.

Also I didn't know about spawning the Helipads.. If he just want's to store variables he can use a Location instead which should have lower performance impact.

This Framework seems pretty useless to me.

 

But after rewriting most of it and cleaning everything up and adding MP functionality it may be very useful to some people.



This library will be maintained, so I'm glad dedmen is being honest here, because that's what I was looking for if this is to be something widely accepted by the community.

Dedman:

I'm glad you mentioned location - but how would one associate new instances with locations (which I believe are static)?

 

I'm also glad you mentioned MP - you're right that remote exec is not here (yet), so far just some local based event creations. IGN_fnc_createEventServer is the most well defined because it does a setVehicleVarInit and publicVariable so that it broadcasts across mp. The local ones with remote exec is still something to be done.

 

This is still in its infancy, however I will be releasing some updates to this (adding support for routed events for UI) when I release my dialog framework script (which relies on this).


Dedman, if you have any other concerns please voice them, so that I can properly address them.

Share this post


Link to post
Share on other sites
  On 2/9/2017 at 5:31 PM, Larrow said:

From a quick look it does not seem that different from BIS_fnc_addScriptedEventHandler other than for each different handle you create it adds a invisible helipad to your mission rather than using a namespace or existing object. It also does not handle returns from the events like the BI version can.

TBH i doubt id use it over the BI version.

 

BIS_fnc_addScriptedEventHandler only lets you register to predefined events. If you needed to define your own event, it will not work. Think of this as more than just Event Handling - this is signal and slots / observer pattern support for missions. If you need to notify multiple entities that something has happened, it makes sense using this lib.

Share this post


Link to post
Share on other sites
  On 2/9/2017 at 6:34 PM, bad benson said:

man. now i feel like i opened a can of worms with my initial question. sorry igneous01.

 

sorry for making everyone shit on your script. i'm sure it's just their assburgers way of giving you tipps how to improve it :down:

don't worry about it, if people are willing to criticize it this much, that means that there is a need to have a robust library for doing these sorts of things. :)

Share this post


Link to post
Share on other sites

yea i was half joking. just trying to lighten the mood a little :don15:. dedmen has been pretty helpful to me and others in the past. i'm sure with some pointers this could be optimised and even expanded to something beyond what BIS_fnc provide.

Share this post


Link to post
Share on other sites
  On 2/9/2017 at 7:16 PM, igneous01 said:

BIS_fnc_addScriptedEventHandler only lets you register to predefined events. If you needed to define your own event, it will not work. Think of this as more than just Event Handling - this is signal and slots / observer pattern support for missions. If you need to notify multiple entities that something has happened, it makes sense using this lib.

No you are incorrect a signal and slots / observer pattern is exactly what the BI functions are and you can definitely create your own as I have made use of it quite a lot when I need feedback from a selection of objects and you can just add the event and fire it off when needed.

{
    [ missionNamespace, "MyEvent", compile format[ "
        params[ '_namePlayer' ];
        systemChat format [ 'Hello %1 my names %2', _namePlayer ];
    ", "%1", name _x ] ] call BIS_fnc_addScriptedEventHandler;
}forEach allUnits;

 

player addAction[ "Say Hello", {
    systemChat format[ "Hello my names %1", name player ];
    [ missionNamespace, "MyEvent", [ name player ] ] call BIS_fnc_callScriptedEventHandler;
}];

Place this in init.sqf, when the player uses the action he says hello and all units will say hello back and state their name, its like a virtual armaholic meeting. :D

  • Like 2

Share this post


Link to post
Share on other sites
  On 2/9/2017 at 11:40 PM, Larrow said:

No you are incorrect a signal and slots / observer pattern is exactly what the BI functions are and you can definitely create your own as I have made use of it quite a lot when I need feedback from a selection of objects and you can just add the event and fire it off when needed.

 

{
    [ missionNamespace, "MyEvent", compile format[ "
        params[ '_namePlayer' ];
        systemChat format [ 'Hello %1 my names %2', _namePlayer ];
    ", "%1", name _x ] ] call BIS_fnc_addScriptedEventHandler;
}forEach allUnits;

 

player addAction[ "Say Hello", {
    systemChat format[ "Hello my names %1", name player ];
    [ missionNamespace, "MyEvent", [ name player ] ] call BIS_fnc_callScriptedEventHandler;
}];

Place this in init.sqf, when the player uses the action he says hello and all units will say hello back and state their name, its like a virtual armaholic meeting. :D

you're right, sorry my mistake.

Well, initially it looks like I've duplicated existing code that BIS created, so I'm in the process of rewriting it (and add proper MP support).

I do have a few questions for the mp scripters out there:

1. What happens if you have a function (that returns a value with call) that has checks for (isServer)? If you call the function, then all client machines will call it as well (assuming you are not doing if(isServer) call fnc) but in this case, only the server will return a proper value? I want to say that this should probably be avoided if someone forgets to wrap a call with isServer.

fnc =
{
	private _obj = locationNull;
	if (isServer)
	{
		_obj = createLocation[...];
	};
	_obj;	// client will get locationNull?
};

2. is createLocation global, or local? There's no mention of this on the biki.

 

3. would this invoke a broadcast? 

_event getVariable "handlers" pushback [clientOwner, _handle];
publicVariable _event;

4. Is there a need to be able to register a handler from a client machine to a server event?

5. Is there a need for a client to be able to raise a server event?

6. Is there a need for a client to be able to raise another clients event?

 

So far I have a broadcasting event, and a normal local event, but I'm wondering if there's more that's needed?

Share this post


Link to post
Share on other sites
  On 2/10/2017 at 1:45 AM, igneous01 said:

 is createLocation global, or local? There's no mention of this on the biki.


you can test it and update wiki

EDIT: Actually it says it right there https://community.bistudio.com/wiki/createLocation

However you can still test it if not sure.

Edited by killzone_kid
biki link

Share this post


Link to post
Share on other sites

To your Mp questions

 

1. Exactly. Only the server will get a correct return Value.

 

2. Check CBA's code for namespaces https://github.com/CBATeam/CBA_A3/blob/master/addons/common/fnc_createNamespace.sqf

So apparently Localtions are really only local. They are using an empty vehicle for Globals.

3. I'm not sure. Test it. But I think this will onl... This will not even work but I guess you mean publicVariable "_event"; and no.. you can't publicVar local variables.

But I guess you just meant publicVariabling the object. I don't think that broadcasting the variable bound to an object will broadcast the objects variable. Just setVariable ["",value,true] for that.

4. Possible. But better have features that not everyone needs than missing some features

5. yes

6. Event probably not... Maybe. But Clients may want to register handlers to other clients events.

  • Like 1

Share this post


Link to post
Share on other sites

Updated to 1.1

I was looking into locations, but they are seriously hindered by the fact that publicVariable wont support them. In fact to use locations on a global event each client would need to have it's own local copy of the same event with manual updating each time, which is what publicVariable helps address.

 

The call compile format was removed, but it had its uses:

 

Reasoning for using call compile format ["%1 = _this", _name];
This allows you to create an event, without having to specify a global variable AND the string name to match.

With it, you can do the following:

[[], "SAMPLE_EVENT"] call IGN_fnc_createEvent;
hint SAMPLE_EVENT;    // this variable is now available

In my opinion this keeps things more consistent rather than having the variable and the string match exactly.
Which introduces fewer bugs. But for now it's been removed for obvious reasons.

Thanks to everyone for the initial feedback, keep it coming!

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×