Talk:BIS fnc addStackedEventHandler - Revision history

Lou Montana: Text replacement - "\[https\:\/\/community\.bistudio\.com\/wiki\/(.) (.)\]" to "$2"

2023-02-21T14:15:26Z

Text replacement - "\[https\:\/\/community\.bistudio\.com\/wiki\/(.*) (.*)\]" to "$2"

← Older revision		Revision as of 16:15, 21 February 2023
Line 66:		Line 66:
	'''_return;'''		'''_return;'''
	</code>		</code>
	Can't get this post formatted correctly. I'm just going to leave it like it is. - [~~https://community.bistudio.com/wiki/~~User_talk:DreadedEntity DreadedEntity]		Can't get this post formatted correctly. I'm just going to leave it like it is. - [[User_talk:DreadedEntity\|DreadedEntity]]
	::According to this post http://forums.bistudio.com/showthread.php?167822-Stacked-event-handlers-OnEachFrame-OnPlayerConnected-etc the intention of these functions is for community/official content compatibility, thus the need for consistent functionality - I don't think you'll see them change this (although its easy enough for you to implement yourself for a specific need).		::According to this post http://forums.bistudio.com/showthread.php?167822-Stacked-event-handlers-OnEachFrame-OnPlayerConnected-etc the intention of these functions is for community/official content compatibility, thus the need for consistent functionality - I don't think you'll see them change this (although its easy enough for you to implement yourself for a specific need).
	::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.--[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 11:18, 9 December 2014 (CET)		::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.--[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 11:18, 9 December 2014 (CET)

	::::"In addition, your code will only return the bool of the last iterated _data." This is incorrect. My edit functions as intended. I think you mixed up _trash and _return. _trash is redefined on every iteration. _return can only be redefined if _trash = true, and it can only be redefined to true. It's basically a one-way road. Then the function ends with _return, which is false by default.		::::"In addition, your code will only return the bool of the last iterated _data." This is incorrect. My edit functions as intended. I think you mixed up _trash and _return. _trash is redefined on every iteration. _return can only be redefined if _trash = true, and it can only be redefined to true. It's basically a one-way road. Then the function ends with _return, which is false by default.
	::::Although, returning true in any of your SEH's will force the entire statement to return true. Which most likely '''will''' cause problems with compatibility. I knew, but I hadn't really considered quite what that meant, you're right, this edit will probably never been seen anywhere other than this page. But what else are we supposed to do? I read that the community has been fighting for SEH's for years. I consider this BIS's failure to add a real way to stack EH's, although Duarte's functions are quite clever in my opinion. Don't consider my edit to be acceptance, I'm still unhappy with how any true returns will override all default behavior for that particular event, but with the current system, it is completely impossible to get it any better. I'm still thinking though...maybe I'll have a breakthrough. - [~~https://community.bistudio.com/wiki/~~User_talk:DreadedEntity DreadedEntity]		::::Although, returning true in any of your SEH's will force the entire statement to return true. Which most likely '''will''' cause problems with compatibility. I knew, but I hadn't really considered quite what that meant, you're right, this edit will probably never been seen anywhere other than this page. But what else are we supposed to do? I read that the community has been fighting for SEH's for years. I consider this BIS's failure to add a real way to stack EH's, although Duarte's functions are quite clever in my opinion. Don't consider my edit to be acceptance, I'm still unhappy with how any true returns will override all default behavior for that particular event, but with the current system, it is completely impossible to get it any better. I'm still thinking though...maybe I'll have a breakthrough. - [[User_talk:DreadedEntity\|DreadedEntity]]
	:::::You are right, my mistake - sleepy eyes. "But what are we supposed to do" - Write one from the ground-up that works like you expect; luckily all the commands necessary are public, so it is possible. But what you have here would work if all parties using it knew the other party will/could be overridding default behavior (this could be perfectly acceptable for certain situations). What else do you expect the SEH to do that it doesn't (other than overriding default)		:::::You are right, my mistake - sleepy eyes. "But what are we supposed to do" - Write one from the ground-up that works like you expect; luckily all the commands necessary are public, so it is possible. But what you have here would work if all parties using it knew the other party will/could be overridding default behavior (this could be perfectly acceptable for certain situations). What else do you expect the SEH to do that it doesn't (other than overriding default)

	:::::Another thought, you could have the return value always a global variable instead, ''BIS_overrideSEH = false'' for example. I see this as doing 2 things - allows scripts to check if default engine behavior will be overridden or not (compatibility), and would allow for changing the behavior on the fly during a mission (sometimes you want the default behavior, sometimes maybe not?) --[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 11:18, 9 December 2014 (CET)		:::::Another thought, you could have the return value always a global variable instead, ''BIS_overrideSEH = false'' for example. I see this as doing 2 things - allows scripts to check if default engine behavior will be overridden or not (compatibility), and would allow for changing the behavior on the fly during a mission (sometimes you want the default behavior, sometimes maybe not?) --[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 11:18, 9 December 2014 (CET)

Lou Montana: Text replacement - "`" to ""`


2023-01-11T10:52:47Z
Text replacement - "<code>" to "<code style="display: block">"

				
				
				
				
				
				← Older revision
				Revision as of 12:52, 11 January 2023
				
Line 1:
Line 1:
Not being able to override default engine behavior was really bumming me out, so I took a look at [[BIS_fnc_executeStackedEventHandler]]. By adding 2 variables, I was able to make the function perform as intended (as I see it). Please push this fix to the next hotfix, BIS! Not being able to override default engine behavior was really bumming me out, so I took a look at [[BIS_fnc_executeStackedEventHandler]]. By adding 2 variables, I was able to make the function perform as intended (as I see it). Please push this fix to the next hotfix, BIS!



<code><nowiki>/* <code style="display: block"><nowiki>/*
	Author: Nelson Duarte 	Author: Nelson Duarte
	Edit by: Dread </nowiki>'''(in bold)'''<nowiki> 	Edit by: Dread </nowiki>'''(in bold)'''<nowiki>



Dr StrangePete: thoughts
2014-12-09T10:18:00Z
thoughts

				
				
				
				
				
				← Older revision
				Revision as of 12:18, 9 December 2014
				
Line 68:
Line 68:
Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity] Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]
::According to this post http://forums.bistudio.com/showthread.php?167822-Stacked-event-handlers-OnEachFrame-OnPlayerConnected-etc the intention of these functions is for community/official content compatibility, thus the need for consistent functionality - I don't think you'll see them change this (although its easy enough for you to implement yourself for a specific need). ::According to this post http://forums.bistudio.com/showthread.php?167822-Stacked-event-handlers-OnEachFrame-OnPlayerConnected-etc the intention of these functions is for community/official content compatibility, thus the need for consistent functionality - I don't think you'll see them change this (although its easy enough for you to implement yourself for a specific need).
  ::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.--[[User:Strangepete|Strangepete]] ([[User talk:Strangepete|talk]]) 11:18, 9 December 2014 (CET)
::In addition, your code will only return the bool of the last iterated _data. Perhaps this should be run through the forums first --[[User:Strangepete|Strangepete]] ([[User talk:Strangepete|talk]]) 03:46, 9 December 2014 (CET) 
  
::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players. 



::::"In addition, your code will only return the bool of the last iterated _data." This is incorrect. My edit functions as intended. I think you mixed up _trash and _return. _trash is redefined on every iteration. _return can only be redefined if _trash = true, and it can only be redefined to true. It's basically a one-way road. Then the function ends with _return, which is false by default. ::::"In addition, your code will only return the bool of the last iterated _data." This is incorrect. My edit functions as intended. I think you mixed up _trash and _return. _trash is redefined on every iteration. _return can only be redefined if _trash = true, and it can only be redefined to true. It's basically a one-way road. Then the function ends with _return, which is false by default.
::::Although, returning true in any of your SEH's will force the entire statement to return true. Which most likely '''will''' cause problems with compatibility. I knew, but I hadn't really considered quite what that meant, you're right, this edit will probably never been seen anywhere other than this page. But what else are we supposed to do? I read that the community has been fighting for SEH's for years. I consider this BIS's failure to add a real way to stack EH's, although Duarte's functions are quite clever in my opinion. Don't consider my edit to be acceptance, I'm still unhappy with how any true returns will override all default behavior for that particular event, but with the current system, it is completely impossible to get it any better. I'm still thinking though...maybe I'll have a breakthrough. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity] ::::Although, returning true in any of your SEH's will force the entire statement to return true. Which most likely '''will''' cause problems with compatibility. I knew, but I hadn't really considered quite what that meant, you're right, this edit will probably never been seen anywhere other than this page. But what else are we supposed to do? I read that the community has been fighting for SEH's for years. I consider this BIS's failure to add a real way to stack EH's, although Duarte's functions are quite clever in my opinion. Don't consider my edit to be acceptance, I'm still unhappy with how any true returns will override all default behavior for that particular event, but with the current system, it is completely impossible to get it any better. I'm still thinking though...maybe I'll have a breakthrough. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]
:::::You are right, my mistake - sleepy eyes. "But what are we supposed to do" - Write one from the ground-up that works like you expect; luckily all the commands necessary are public, so it is possible. But what you have here would work if all parties using it knew the other party will/could be overridding default behavior (this could be perfectly acceptable for certain situations). What else do you expect the SEH to do that it doesn't (other than overriding default)

:::::Another thought, you could have the return value always a global variable instead, ''BIS_overrideSEH = false'' for example. I see this as doing 2 things - allows scripts to check if default engine behavior will be overridden or not (compatibility), and would allow for changing the behavior on the fly during a mission (sometimes you want the default behavior, sometimes maybe not?) --[[User:Strangepete|Strangepete]] ([[User talk:Strangepete|talk]]) 11:18, 9 December 2014 (CET)



DreadedEntity: response to a comment
2014-12-09T05:09:14Z
response to a comment

				
				
				
				
				
				← Older revision
				Revision as of 07:09, 9 December 2014
				
Line 72:
Line 72:



::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players. ::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.

::::"In addition, your code will only return the bool of the last iterated _data." This is incorrect. My edit functions as intended. I think you mixed up _trash and _return. _trash is redefined on every iteration. _return can only be redefined if _trash = true, and it can only be redefined to true. It's basically a one-way road. Then the function ends with _return, which is false by default.
::::Although, returning true in any of your SEH's will force the entire statement to return true. Which most likely '''will''' cause problems with compatibility. I knew, but I hadn't really considered quite what that meant, you're right, this edit will probably never been seen anywhere other than this page. But what else are we supposed to do? I read that the community has been fighting for SEH's for years. I consider this BIS's failure to add a real way to stack EH's, although Duarte's functions are quite clever in my opinion. Don't consider my edit to be acceptance, I'm still unhappy with how any true returns will override all default behavior for that particular event, but with the current system, it is completely impossible to get it any better. I'm still thinking though...maybe I'll have a breakthrough. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]



Dr StrangePete: addl note
2014-12-09T02:52:34Z
addl note

				
				
				
				
				
				← Older revision
				Revision as of 04:52, 9 December 2014
				
Line 70:
Line 70:



::In addition, your code will only return the bool of the last iterated _data. Perhaps this should be run through the forums first --[[User:Strangepete|Strangepete]] ([[User talk:Strangepete|talk]]) 03:46, 9 December 2014 (CET) ::In addition, your code will only return the bool of the last iterated _data. Perhaps this should be run through the forums first --[[User:Strangepete|Strangepete]] ([[User talk:Strangepete|talk]]) 03:46, 9 December 2014 (CET)

::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.



Dr StrangePete at 02:46, 9 December 2014
2014-12-09T02:46:20Z


				
				
				
				
				
				← Older revision
				Revision as of 04:46, 9 December 2014
				
Line 67:
Line 67:
</code> </code>
Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity] Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]
::According to this post http://forums.bistudio.com/showthread.php?167822-Stacked-event-handlers-OnEachFrame-OnPlayerConnected-etc the intention of these functions is for community/official content compatibility, thus the need for consistent functionality - I don't think you'll see them change this (although its easy enough for you to implement yourself for a specific need).

::In addition, your code will only return the bool of the last iterated _data. Perhaps this should be run through the forums first --[[User:Strangepete|Strangepete]] ([[User talk:Strangepete|talk]]) 03:46, 9 December 2014 (CET)



Heeeere's johnny!: Corrected the look of the code
2014-12-09T02:20:44Z
Corrected the look of the code

				
				
				
				
				
				← Older revision
				Revision as of 04:20, 9 December 2014
				
Line 1:
Line 1:
Not being able to override default engine behavior was really bumming me out, so I took a look at [[BIS_fnc_executeStackedEventHandler]]. By adding 2 variables, I was able to make the function perform as intended (as I see it). Please push this fix to the next hotfix, BIS! Not being able to override default engine behavior was really bumming me out, so I took a look at [[BIS_fnc_executeStackedEventHandler]]. By adding 2 variables, I was able to make the function perform as intended (as I see it). Please push this fix to the next hotfix, BIS!



<code>/* <code><nowiki>/*
	Author: Nelson Duarte 	Author: Nelson Duarte
	Edit by: Dread '''(in bold)''' 	Edit by: Dread </nowiki>'''(in bold)'''<nowiki>
	 	
	Description: 	Description:
Line 11:
Line 11:
	_this select 0:	STRING	- The onXxx event handler 	_this select 0:	STRING	- The onXxx event handler
	 	
	Returns: 	Returns:</nowiki>
	'''BOOL -''' 	'''BOOL -'''
		'''True if executed code returns true''' 		'''True if executed code returns true'''
		'''False if executed code returns anything else''' 		'''False if executed code returns anything else'''
  	<nowiki>
*/Parameters */
//Parameters
private ["_event"]; private ["_event"];
_event = [_this, 0, "", [""]] call BIS_fnc_param; _event = [_this, 0, "", [""]] call BIS_fnc_param;
Line 31:
Line 32:
private "_data"; private "_data";
_data = missionNameSpace getVariable [_namespaceEvent, []]; _data = missionNameSpace getVariable [_namespaceEvent, []];
  </nowiki>
'''//Add 2 new variables and define '''//Add 2 new variables and define
'''private ["_return","_trash"];''' '''private ["_return","_trash"];'''
'''_return = false;''' '''_return = false;'''
'''_trash = false;''' '''_trash = false;'''
  <nowiki>
//Process data //Process data
{ {
Line 46:
Line 47:
	if (typeName _code != typeName "") then { 	if (typeName _code != typeName "") then {
		//Execute code 		//Execute code
		</nowiki>
		'''_trash =''' _arguments call _code; '''//call can return, why waste?''' 		'''_trash =''' _arguments call _code; '''//call can return, why waste?'''
	} else { 	} else {
Line 58:
Line 60:
		'''};''' 		'''};'''
	'''};''' 	'''};'''
	<nowiki>
} forEach _data; } forEach _data;



//Return //Return</nowiki>
'''_return;''' '''_return;'''
</code> </code>
Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity] Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]



DreadedEntity at 02:05, 9 December 2014
2014-12-09T02:05:55Z


				
				
				
				
				
				← Older revision
				Revision as of 04:05, 9 December 2014
				
Line 61:
Line 61:



//Return //Return
_return; '''_return;'''
</code> </code>
Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity] Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]



DreadedEntity at 02:04, 9 December 2014
2014-12-09T02:04:45Z


				
				
				
				
				
				← Older revision
				Revision as of 04:04, 9 December 2014
				
Line 12:
Line 12:
	 	
	Returns: 	Returns:
	BOOL - 	'''BOOL -'''
		True if executed code returns true 		'''True if executed code returns true'''
		False if executed code returns anything else 		'''False if executed code returns anything else'''



*/Parameters */Parameters



DreadedEntity at 02:02, 9 December 2014
2014-12-09T02:02:44Z


				
				
				
				
				
				← Older revision
				Revision as of 04:02, 9 December 2014
				
Line 33:
Line 33:



'''//Add 2 new variables and define '''//Add 2 new variables and define
private ["_return","_trash"]; '''private ["_return","_trash"];'''
_return = false; '''_return = false;'''
_trash = false;''' '''_trash = false;'''



//Process data //Process data

← Older revision		Revision as of 12:52, 11 January 2023
Line 1:		Line 1:
	Not being able to override default engine behavior was really bumming me out, so I took a look at [[BIS_fnc_executeStackedEventHandler]]. By adding 2 variables, I was able to make the function perform as intended (as I see it). Please push this fix to the next hotfix, BIS!		Not being able to override default engine behavior was really bumming me out, so I took a look at [[BIS_fnc_executeStackedEventHandler]]. By adding 2 variables, I was able to make the function perform as intended (as I see it). Please push this fix to the next hotfix, BIS!

	<code><nowiki>/*		<code style="display: block"><nowiki>/*
	Author: Nelson Duarte		Author: Nelson Duarte
	Edit by: Dread </nowiki>'''(in bold)'''<nowiki>		Edit by: Dread </nowiki>'''(in bold)'''<nowiki>

← Older revision		Revision as of 12:18, 9 December 2014
Line 68:		Line 68:
	Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]		Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]
	::According to this post http://forums.bistudio.com/showthread.php?167822-Stacked-event-handlers-OnEachFrame-OnPlayerConnected-etc the intention of these functions is for community/official content compatibility, thus the need for consistent functionality - I don't think you'll see them change this (although its easy enough for you to implement yourself for a specific need).		::According to this post http://forums.bistudio.com/showthread.php?167822-Stacked-event-handlers-OnEachFrame-OnPlayerConnected-etc the intention of these functions is for community/official content compatibility, thus the need for consistent functionality - I don't think you'll see them change this (although its easy enough for you to implement yourself for a specific need).
			::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.--[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 11:18, 9 December 2014 (CET)
	::In addition, your code will only return the bool of the last iterated _data. Perhaps this should be run through the forums first --[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 03:46, 9 December 2014 (CET)

	::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.

	::::"In addition, your code will only return the bool of the last iterated _data." This is incorrect. My edit functions as intended. I think you mixed up _trash and _return. _trash is redefined on every iteration. _return can only be redefined if _trash = true, and it can only be redefined to true. It's basically a one-way road. Then the function ends with _return, which is false by default.		::::"In addition, your code will only return the bool of the last iterated _data." This is incorrect. My edit functions as intended. I think you mixed up _trash and _return. _trash is redefined on every iteration. _return can only be redefined if _trash = true, and it can only be redefined to true. It's basically a one-way road. Then the function ends with _return, which is false by default.
	::::Although, returning true in any of your SEH's will force the entire statement to return true. Which most likely '''will''' cause problems with compatibility. I knew, but I hadn't really considered quite what that meant, you're right, this edit will probably never been seen anywhere other than this page. But what else are we supposed to do? I read that the community has been fighting for SEH's for years. I consider this BIS's failure to add a real way to stack EH's, although Duarte's functions are quite clever in my opinion. Don't consider my edit to be acceptance, I'm still unhappy with how any true returns will override all default behavior for that particular event, but with the current system, it is completely impossible to get it any better. I'm still thinking though...maybe I'll have a breakthrough. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]		::::Although, returning true in any of your SEH's will force the entire statement to return true. Which most likely '''will''' cause problems with compatibility. I knew, but I hadn't really considered quite what that meant, you're right, this edit will probably never been seen anywhere other than this page. But what else are we supposed to do? I read that the community has been fighting for SEH's for years. I consider this BIS's failure to add a real way to stack EH's, although Duarte's functions are quite clever in my opinion. Don't consider my edit to be acceptance, I'm still unhappy with how any true returns will override all default behavior for that particular event, but with the current system, it is completely impossible to get it any better. I'm still thinking though...maybe I'll have a breakthrough. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]
			:::::You are right, my mistake - sleepy eyes. "But what are we supposed to do" - Write one from the ground-up that works like you expect; luckily all the commands necessary are public, so it is possible. But what you have here would work if all parties using it knew the other party will/could be overridding default behavior (this could be perfectly acceptable for certain situations). What else do you expect the SEH to do that it doesn't (other than overriding default)

			:::::Another thought, you could have the return value always a global variable instead, ''BIS_overrideSEH = false'' for example. I see this as doing 2 things - allows scripts to check if default engine behavior will be overridden or not (compatibility), and would allow for changing the behavior on the fly during a mission (sometimes you want the default behavior, sometimes maybe not?) --[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 11:18, 9 December 2014 (CET)

← Older revision		Revision as of 07:09, 9 December 2014
Line 72:		Line 72:

	::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.		::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.

			::::"In addition, your code will only return the bool of the last iterated _data." This is incorrect. My edit functions as intended. I think you mixed up _trash and _return. _trash is redefined on every iteration. _return can only be redefined if _trash = true, and it can only be redefined to true. It's basically a one-way road. Then the function ends with _return, which is false by default.
			::::Although, returning true in any of your SEH's will force the entire statement to return true. Which most likely '''will''' cause problems with compatibility. I knew, but I hadn't really considered quite what that meant, you're right, this edit will probably never been seen anywhere other than this page. But what else are we supposed to do? I read that the community has been fighting for SEH's for years. I consider this BIS's failure to add a real way to stack EH's, although Duarte's functions are quite clever in my opinion. Don't consider my edit to be acceptance, I'm still unhappy with how any true returns will override all default behavior for that particular event, but with the current system, it is completely impossible to get it any better. I'm still thinking though...maybe I'll have a breakthrough. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]

← Older revision		Revision as of 04:52, 9 December 2014
Line 70:		Line 70:

	::In addition, your code will only return the bool of the last iterated _data. Perhaps this should be run through the forums first --[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 03:46, 9 December 2014 (CET)		::In addition, your code will only return the bool of the last iterated _data. Perhaps this should be run through the forums first --[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 03:46, 9 December 2014 (CET)

			::Infact, further down that page is an example of how returning true can break functionality; KK's reply points out that executeStackedEventHandlers used to return true by default, which broke onMapSingleClick for players.

← Older revision		Revision as of 04:46, 9 December 2014
Line 67:		Line 67:
	</code>		</code>
	Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]		Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]
			::According to this post http://forums.bistudio.com/showthread.php?167822-Stacked-event-handlers-OnEachFrame-OnPlayerConnected-etc the intention of these functions is for community/official content compatibility, thus the need for consistent functionality - I don't think you'll see them change this (although its easy enough for you to implement yourself for a specific need).

			::In addition, your code will only return the bool of the last iterated _data. Perhaps this should be run through the forums first --[[User:Strangepete\|Strangepete]] ([[User talk:Strangepete\|talk]]) 03:46, 9 December 2014 (CET)

← Older revision		Revision as of 04:20, 9 December 2014
Line 1:		Line 1:
	Not being able to override default engine behavior was really bumming me out, so I took a look at [[BIS_fnc_executeStackedEventHandler]]. By adding 2 variables, I was able to make the function perform as intended (as I see it). Please push this fix to the next hotfix, BIS!		Not being able to override default engine behavior was really bumming me out, so I took a look at [[BIS_fnc_executeStackedEventHandler]]. By adding 2 variables, I was able to make the function perform as intended (as I see it). Please push this fix to the next hotfix, BIS!

	<code>/*		<code><nowiki>/*
	Author: Nelson Duarte		Author: Nelson Duarte
	Edit by: Dread '''(in bold)'''		Edit by: Dread </nowiki>'''(in bold)'''<nowiki>

	Description:		Description:
Line 11:		Line 11:
	_this select 0: STRING - The onXxx event handler		_this select 0: STRING - The onXxx event handler

	Returns:		Returns:</nowiki>
	'''BOOL -'''		'''BOOL -'''
	'''True if executed code returns true'''		'''True if executed code returns true'''
	'''False if executed code returns anything else'''		'''False if executed code returns anything else'''
			<nowiki>
	*/Parameters		*/
			//Parameters
	private ["_event"];		private ["_event"];
	_event = [_this, 0, "", [""]] call BIS_fnc_param;		_event = [_this, 0, "", [""]] call BIS_fnc_param;
Line 31:		Line 32:
	private "_data";		private "_data";
	_data = missionNameSpace getVariable [_namespaceEvent, []];		_data = missionNameSpace getVariable [_namespaceEvent, []];
			</nowiki>
	'''//Add 2 new variables and define		'''//Add 2 new variables and define
	'''private ["_return","_trash"];'''		'''private ["_return","_trash"];'''
	'''_return = false;'''		'''_return = false;'''
	'''_trash = false;'''		'''_trash = false;'''
			<nowiki>
	//Process data		//Process data
	{		{
Line 46:		Line 47:
	if (typeName _code != typeName "") then {		if (typeName _code != typeName "") then {
	//Execute code		//Execute code
			</nowiki>
	'''_trash =''' _arguments call _code; '''//call can return, why waste?'''		'''_trash =''' _arguments call _code; '''//call can return, why waste?'''
	} else {		} else {
Line 58:		Line 60:
	'''};'''		'''};'''
	'''};'''		'''};'''
			<nowiki>
	} forEach _data;		} forEach _data;

	//Return		//Return</nowiki>
	'''_return;'''		'''_return;'''
	</code>		</code>
	Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]		Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]

← Older revision		Revision as of 04:05, 9 December 2014
Line 61:		Line 61:

	//Return		//Return
	_return;		'''_return;'''
	</code>		</code>
	Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]		Can't get this post formatted correctly. I'm just going to leave it like it is. - [https://community.bistudio.com/wiki/User_talk:DreadedEntity DreadedEntity]

← Older revision		Revision as of 04:04, 9 December 2014
Line 12:		Line 12:

	Returns:		Returns:
	BOOL -		'''BOOL -'''
	True if executed code returns true		'''True if executed code returns true'''
	False if executed code returns anything else		'''False if executed code returns anything else'''

	*/Parameters		*/Parameters

← Older revision		Revision as of 04:02, 9 December 2014
Line 33:		Line 33:

	'''//Add 2 new variables and define		'''//Add 2 new variables and define
	private ["_return","_trash"];		'''private ["_return","_trash"];'''
	_return = false;		'''_return = false;'''
	_trash = false;'''		'''_trash = false;'''

	//Process data		//Process data

Talk:BIS fnc addStackedEventHandler - Revision history

Lou Montana: Text replacement - "\[https\:\/\/community\.bistudio\.com\/wiki\/(.*) (.*)\]" to "$2"

Lou Montana: Text replacement - "" to ""

Dr StrangePete: thoughts

DreadedEntity: response to a comment

Dr StrangePete: addl note

Dr StrangePete at 02:46, 9 December 2014

Heeeere's johnny!: Corrected the look of the code

DreadedEntity at 02:05, 9 December 2014

DreadedEntity at 02:04, 9 December 2014

DreadedEntity at 02:02, 9 December 2014

Lou Montana: Text replacement - "\[https\:\/\/community\.bistudio\.com\/wiki\/(.) (.)\]" to "$2"

Lou Montana: Text replacement - "`" to ""`