EEvent - Revision history

Cadillac at 02:35, 23 August 2021

2021-08-23T02:35:16Z

← Older revision		Revision as of 22:35, 22 August 2021
Line 38:		Line 38:
	==Arguments passed to events==		==Arguments passed to events==
	==eEventHandler==		==eEventHandler==

			[[Category:Development]]

Epsy: /* Arguments passed to events */ burp..err, yeah next time I'll work a little more

2008-12-14T00:25:02Z

Arguments passed to events: burp..err, yeah next time I'll work a little more

← Older revision		Revision as of 20:25, 13 December 2008
Line 34:		Line 34:

	As spoiled by the precedent list, and by the Goals section, users will be able so set their own handlers. User-defined stuff means user interface. User interface means different format. This format is going to be an XML resource type, and needs it's own specification.		As spoiled by the precedent list, and by the Goals section, users will be able so set their own handlers. User-defined stuff means user interface. User interface means different format. This format is going to be an XML resource type, and needs it's own specification.

			=Detailed Concept Points=
			==Arguments passed to events==
			==eEventHandler==

Epsy: /* General Concept Overview */ missed a word here

2008-12-02T22:55:59Z

General Concept Overview: missed a word here

← Older revision		Revision as of 18:55, 2 December 2008
Line 30:		Line 30:
	On top of that, there are '''eEventHandlerSet'''s. It inherits ''eEventHandler'' so you can use an ''eEventHandlerSet'' instead of an ''eEventHandler''. This allows making different 'layers' for:		On top of that, there are '''eEventHandlerSet'''s. It inherits ''eEventHandler'' so you can use an ''eEventHandlerSet'' instead of an ''eEventHandler''. This allows making different 'layers' for:
	* actions that would break the entire game logic if not called, but which can be replaced by a module/gameplay's code.		* actions that would break the entire game logic if not called, but which can be replaced by a module/gameplay's code.
	* actions that the server/gamemode recommends, but which can be fully, and only removed		* actions that the server/gamemode recommends, but which can be fully, and only fully removed
	* actions that are set by the user itself, which works on an incremental basis		* actions that are set by the user itself, which works on an incremental basis

	As spoiled by the precedent list, and by the Goals section, users will be able so set their own handlers. User-defined stuff means user interface. User interface means different format. This format is going to be an XML resource type, and needs it's own specification.		As spoiled by the precedent list, and by the Goals section, users will be able so set their own handlers. User-defined stuff means user interface. User interface means different format. This format is going to be an XML resource type, and needs it's own specification.

Epsy: this doesnt belong to this bp

2008-10-20T17:25:00Z

this doesnt belong to this bp

← Older revision		Revision as of 13:25, 20 October 2008
Line 9:		Line 9:
	* Future-Proof, as in, you can make up new kinds of event types		* Future-Proof, as in, you can make up new kinds of event types
	* Event description resources		* Event description resources
	* Client/Server ~~AND Server/External service~~ communication		* Client/Server communication

	=Milestones=		=Milestones=
Line 15:		Line 15:
	* Event resources		* Event resources
	* Text events fully done via eEvents		* Text events fully done via eEvents
	* External communication (not very important for now)

	=General Concept Overview=		=General Concept Overview=

Epsy: whoops, fixed the fucked up titling

2008-10-19T19:08:17Z

whoops, fixed the fucked up titling

← Older revision		Revision as of 15:08, 19 October 2008
Line 4:		Line 4:
	So here's my solution to this, having, the same way we separate content and presentation in webdesign, we'll separate the actual event and what to do when it happens. So at one side we have the server telling the client that event X happened, on the other side an event resource describing what to do when event X or Y is received.		So here's my solution to this, having, the same way we separate content and presentation in webdesign, we'll separate the actual event and what to do when it happens. So at one side we have the server telling the client that event X happened, on the other side an event resource describing what to do when event X or Y is received.

	==Goals==		=Goals=
	* Get a working sound engine :)		* Get a working sound engine :)
	* Modular approach, especially needed for event resources		* Modular approach, especially needed for event resources
Line 11:		Line 11:
	* Client/Server AND Server/External service communication		* Client/Server AND Server/External service communication

	==Milestones==		=Milestones=
	* Working sound		* Working sound
	* Event resources		* Event resources
Line 17:		Line 17:
	* External communication (not very important for now)		* External communication (not very important for now)

	==General Concept Overview==		=General Concept Overview=
	You got 3 main classes:		You got 3 main classes:
	* eEvent		* eEvent

Epsy: /* General Concept Overview */ completeted that part

2008-09-11T18:18:07Z

General Concept Overview: completeted that part

← Older revision		Revision as of 14:18, 11 September 2008
Line 23:		Line 23:
	* eEventHandler		* eEventHandler

	The '''eEvent''' object is what is sent over the network. It's lifetime is short, it's used from the moment when the event is known to happen to the moment when we send it to everyone(or not). It wields an ''eEventType'' and a list of arguments, a bit like ''tOutput''s ~~that~~ have a name string and a list of arguments.		The '''eEvent''' object is what is sent over the network. It's lifetime is short, it's used from the moment when the event is known to happen to the moment when we send it to everyone(or not). It wields an ''eEventType'' and a list of arguments, a bit like ''tOutput''s which have a name string, the context we caught/created this event from and a list of arguments.

	The '''eEventType''' class defines an event type. Really. There is a big list of all ''eEventType''s so that you can name an ''eEventType'' using a string, but you don't have to worry about it anyway, the contructor's main role is to do that for you. So, an eEventType comports: a name string, which is used for transmission via ''eEvent''s and for naming; it also has serval ''eEventHandler''s, which will be used when the event is received.		The '''eEventType''' class defines an event type. Really. There is a big list of all ''eEventType''s so that you can name an ''eEventType'' using a string, but you don't have to worry about it anyway, the contructor's main role is to do that for you. So, an eEventType comports: a name string, which is used for transmission via ''eEvent''s and for naming; it also has serval ''eEventHandler''s, which will be used when the event is received.

	The '''eEventHandler''' ~~class defines an~~ action to ~~be done when an event is received~~. It'~~s some sort~~ of ~~strange class~~ that ~~wasn~~'~~t designed properly~~. ~~Uhm~~, ~~not at all :) Main planned features include argument handling/wrapping~~, ~~net state dependence~~ and ~~such~~. ~~FIXME: do this~~		The '''eEventHandler''' is some kind of wrapper from the argument list transmitted with the event to the called action's arguments. There is room for predefined general purpose handlers, eg, one that takes <''player id''> <''number''>, or one that takes all the argument and turns it into a console message. Their job is also to catch bogus actions, then to either ignore them or report them( by disconnecting or showing a warning to the user )

			On top of that, there are '''eEventHandlerSet'''s. It inherits ''eEventHandler'' so you can use an ''eEventHandlerSet'' instead of an ''eEventHandler''. This allows making different 'layers' for:
			* actions that would break the entire game logic if not called, but which can be replaced by a module/gameplay's code.
			* actions that the server/gamemode recommends, but which can be fully, and only removed
			* actions that are set by the user itself, which works on an incremental basis

			As spoiled by the precedent list, and by the Goals section, users will be able so set their own handlers. User-defined stuff means user interface. User interface means different format. This format is going to be an XML resource type, and needs it's own specification.

Epsy: /* General Concept Overview */ humanizatored. have a brief description of the main classes instead of the copy of a header file

2008-09-10T20:58:26Z

General Concept Overview: humanizatored. have a brief description of the main classes instead of the copy of a header file

← Older revision		Revision as of 16:58, 10 September 2008
Line 16:		Line 16:
	* Text events fully done via eEvents		* Text events fully done via eEvents
	* External communication (not very important for now)		* External communication (not very important for now)

			==General Concept Overview==
			You got 3 main classes:
			* eEvent
			* eEventType
			* eEventHandler

			The '''eEvent''' object is what is sent over the network. It's lifetime is short, it's used from the moment when the event is known to happen to the moment when we send it to everyone(or not). It wields an ''eEventType'' and a list of arguments, a bit like ''tOutput''s that have a name string and a list of arguments.

			The '''eEventType''' class defines an event type. Really. There is a big list of all ''eEventType''s so that you can name an ''eEventType'' using a string, but you don't have to worry about it anyway, the contructor's main role is to do that for you. So, an eEventType comports: a name string, which is used for transmission via ''eEvent''s and for naming; it also has serval ''eEventHandler''s, which will be used when the event is received.

			The '''eEventHandler''' class defines an action to be done when an event is received. It's some sort of strange class that wasn't designed properly. Uhm, not at all :) Main planned features include argument handling/wrapping, net state dependence and such. FIXME: do this

Epsy: fuck that, the header file and doxy just does that fine

2008-09-10T20:35:22Z

fuck that, the header file and doxy just does that fine

← Older revision		Revision as of 16:35, 10 September 2008
Line 16:		Line 16:
	* Text events fully done via eEvents		* Text events fully done via eEvents
	* External communication (not very important for now)		* External communication (not very important for now)

	~~==Implementation==~~
	~~===eEvent class===~~
	~~That's the object that will the thrown all the way, it doesn't collect a lot of info, but it collects all which is necessary to execute it(triggering what it is supposed to trigger) or to transmit it.~~

	~~=====Friends=====~~
	* eEventType

	~~=====[protected] eEventContext context=====~~
	Describes the network context the eEvent is found in. An eEventContext is a simple struct, detailled later. Think about this as IE's security zones(or whatever they call it), but keep positive about it :)

	~~=====[private] eEventType type=====~~
	~~That's the eEvent's type, what makes it different from another eEvent. An eEventType is what contains the event's type string (ie. zone_conquered) and what actions it triggers.~~

	~~=====[private] eEventArgumentList args=====~~
	~~List of the eEvent's arguments :)~~
	~~typedef eEventArgumentList std::map< int, vValue >;~~

	~~=====[public] void Execute( void )=====~~
	~~Executes the event.~~

	~~=====[public] Broadcast ( void )=====~~
	~~Broadcasts the event.~~

	~~That's about it. That's not much is it? :)~~

	~~===eEventContext struct===~~

	~~enum eEventContextComponent~~
	{
	~~eEventContext_me = 0,~~
	~~eEventContext_server = 1,~~
	~~eEventContext_client = 2,~~
	~~eEventContext_external = 3,~~
	}

	~~=====[public] eEventContextComponent sender=====~~
	~~The sender.~~

	~~=====[public] eEventContextComponent receiver=====~~
	~~The receiver.~~

	~~===eEventType===~~

Epsy: /* Milestones */

2008-09-10T20:34:39Z

Milestones

← Older revision		Revision as of 16:34, 10 September 2008
Line 14:		Line 14:
	* Working sound		* Working sound
	* Event resources		* Event resources
	* External communication		* Text events fully done via eEvents
			* External communication (not very important for now)

	==Implementation==		==Implementation==

Epsy: /* [protected] eEventContext context */

2008-07-30T16:48:53Z

[protected] eEventContext context

← Older revision		Revision as of 12:48, 30 July 2008
Line 24:		Line 24:

	=====[protected] eEventContext context=====		=====[protected] eEventContext context=====
	Describes the network context the eEvent is found in. An eEventContext is a simple struct, detailled later. ~~This~~ about this as IE's security zones(or whatever they call it), but keep positive about it :)		Describes the network context the eEvent is found in. An eEventContext is a simple struct, detailled later. Think about this as IE's security zones(or whatever they call it), but keep positive about it :)

	=====[private] eEventType type=====		=====[private] eEventType type=====