Adding Script Events to sys - Revision history

Zbyl: Added more detailed info about adding events.

2013-02-01T11:19:13Z

Added more detailed info about adding events.

← Older revision		Revision as of 11:19, 1 February 2013
Line 5:		Line 5:
	/src/game/script/script_thread.cpp (and .h)		/src/game/script/script_thread.cpp (and .h)

	Just add them there as you would add any other script events ~~(see~~ iddevnet.com for a guide to adding script events, ~~there are~~ a ~~lot of steps~~).		Just add them there as you would add any other script events. See [http://www.iddevnet.com/doom3/ iddevnet.com] under "11/11/04 Adding a new event" for a guide to adding script events. Here is a quick overview of how to add new event to "sys":
			* in ''script_thread.cpp'' add: <code>const idEventDef EV_Thread_Print( "print", EventArgs('s', "text", ""), EV_RETURNS_VOID, "Prints the given string to the console.");</code>
			* in ''script_thread.cpp'' under <code>CLASS_DECLARATION( idClass, idThread )</code> add: <code>EVENT( EV_Thread_Print, idThread::Event_Print )</code>
			* add a method to <code>idThread</code> class: <code>void idThread::Event_Print( const char *text )</code>
			* add an entry to ''tdm_events.script'' (''doom_events.script'' in DOOM 3): <code>scriptEvent void print( string text );</code>

	This way you can add events that are global, for example as a frontend for accessing a global object contained in game_local.		This way you can add events that are global, for example as a frontend for accessing a global object contained in game_local.

	The "sys" object is an artificial "global object" within the scripting language. The scripting language only sees actual spawned entities, and the global object. So you can't have abstract objects (like container classes contained within an entity or something). Therefore if you want an object to call functions on without spawning an entity, the "sys" object is a good choice. (It's not a real object in the sdk either, it's just seen that way by scripting, and it can only call methods/events on the idThread class).		The "sys" object is an artificial "global object" within the scripting language. The scripting language only sees actual spawned entities, and the global object. So you can't have abstract objects (like container classes contained within an entity or something). Therefore if you want an object to call functions without spawning an entity, the "sys" object is a good choice. (It's not a real object in the sdk either, it's just seen that way by scripting, and it can only call methods/events on the idThread class).

			For an example of a script event attached to an entity other than "sys" see "wasDamaged" event on <code>idPlayer</code>.

	{{sdk}}		{{sdk}}

Greebo: categorised

2008-06-30T08:06:28Z

categorised

← Older revision		Revision as of 08:06, 30 June 2008
Line 5:		Line 5:
	/src/game/script/script_thread.cpp (and .h)		/src/game/script/script_thread.cpp (and .h)

	Just add them there as you would add any other script events (see iddevnet.com for a guide to adding script events, there are a lot of steps)		Just add them there as you would add any other script events (see iddevnet.com for a guide to adding script events, there are a lot of steps).

	~~I'm compiling my changes now and still have to test them, but hopefully it'll work.~~ This way you can add events that are global, for example as a frontend for accessing a global object contained in game_local.		This way you can add events that are global, for example as a frontend for accessing a global object contained in game_local.

	The "sys" object is an artificial "global object" within the scripting language. The scripting language only sees actual spawned entities, and the global object. So you can't have abstract objects (like container classes contained within an entity or something). Therefore if you want an object to call functions on without spawning an entity, the "sys" object is a good choice. (It's not a real object in the sdk either, it's just seen that way by scripting, and it can only call methods/events on the idThread class)		The "sys" object is an artificial "global object" within the scripting language. The scripting language only sees actual spawned entities, and the global object. So you can't have abstract objects (like container classes contained within an entity or something). Therefore if you want an object to call functions on without spawning an entity, the "sys" object is a good choice. (It's not a real object in the sdk either, it's just seen that way by scripting, and it can only call methods/events on the idThread class).

	~~[[Category:SDK]]~~		{{sdk}}

Greebo at 13:58, 13 September 2006

2006-09-13T13:58:58Z

New page

{{Original_Reference|Ishtvan|1582}}

Btw, if anyone's curious how to add new "sys" events, i.e., events you call with $sys.<eventname> from the script, they're located here:

/src/game/script/script_thread.cpp (and .h)

Just add them there as you would add any other script events (see iddevnet.com for a guide to adding script events, there are a lot of steps)

I'm compiling my changes now and still have to test them, but hopefully it'll work. This way you can add events that are global, for example as a frontend for accessing a global object contained in game_local.

The "sys" object is an artificial "global object" within the scripting language. The scripting language only sees actual spawned entities, and the global object. So you can't have abstract objects (like container classes contained within an entity or something). Therefore if you want an object to call functions on without spawning an entity, the "sys" object is a good choice. (It's not a real object in the sdk either, it's just seen that way by scripting, and it can only call methods/events on the idThread class)

[[Category:SDK]]