Archive:Server development - Revision history

Jaxad0127: Jaxad0127 moved page Server development to Archive:Server development without leaving a redirect

2013-06-18T13:45:08Z

Jaxad0127 moved page Server development to Archive:Server development without leaving a redirect

← Older revision	Revision as of 13:45, 18 June 2013
(No difference)

2009-01-08T16:41:13Z

Undo revision 11389 by CaalrOlzel (Talk)

← Older revision		Revision as of 16:41, 8 January 2009
Line 1:		Line 1:
	[http://releltl.0lx.net/20081114-eminem-guilty-conscious.html eminem guilty conscious video] [http://zelgetgo.0lx.net/sitemap.htm index] [http://hencnac4t.is-the-boss.com/news-art-child-pirate-2008-12-23.html art child pirate work] [http://zelfibu.strefa.pl/sitbasra-1910.html ice age 2 movie poster] [http://baslozaro.is-the-boss.com/article36.html recoil demo crack]
	{{Category_programming}}		{{Category_programming}}
	{{Status_yellow}}		{{Status_yellow}}

2009-01-08T16:14:57Z

http://releltl.0lx.net/20081114-eminem-guilty-conscious.html

← Older revision		Revision as of 16:14, 8 January 2009
Line 1:		Line 1:
			[http://releltl.0lx.net/20081114-eminem-guilty-conscious.html eminem guilty conscious video] [http://zelgetgo.0lx.net/sitemap.htm index] [http://hencnac4t.is-the-boss.com/news-art-child-pirate-2008-12-23.html art child pirate work] [http://zelfibu.strefa.pl/sitbasra-1910.html ice age 2 movie poster] [http://baslozaro.is-the-boss.com/article36.html recoil demo crack]
	{{Category_programming}}		{{Category_programming}}
	{{Status_yellow}}		{{Status_yellow}}

2008-12-20T20:53:57Z

revert: spambot

2008-12-20T06:25:42Z

vicoeltla

2007-10-09T21:45:57Z

Scripting

← Older revision		Revision as of 21:45, 9 October 2007
Line 74:		Line 74:
	* [http://www.ruby-lang.org/ Ruby]		* [http://www.ruby-lang.org/ Ruby]

	~~UPDATE~~: ~~Ruby~~ has been ~~chosen as the language~~ for ~~use in TMW~~ server.		Note: Lua has been implemented for server-side scripting. --Oct. 9, 2007

	Suitable uses of scripting:		Suitable uses of scripting:
	* Enemy behaviour		* Enemy behaviour
	* Dynamic NPC behaviour		* Dynamic NPC behaviour

2007-03-24T21:13:11Z

->programming

2006-07-26T12:03:16Z

← Older revision		Revision as of 12:03, 26 July 2006
Line 3:		Line 3:

	* [[Being movement system]]		* [[Being movement system]]
			* [[Communication protocol]]
	* [[Pixel based players in a tile based world]]		* [[Pixel based players in a tile based world]]
	* [[Realtime action combat protocol]]		* [[Realtime action combat protocol]]

2006-07-24T22:42:43Z

Remove references to outdated pages, added replacing article

← Older revision		Revision as of 22:42, 24 July 2006
Line 2:		Line 2:
	== Related subtopics ==		== Related subtopics ==

	* [[~~Player control]]~~		* [[Being movement system]]
	* [[Client-server message list]]
	* [[Pixel based players in a tile based world]]		* [[Pixel based players in a tile based world]]
	* [[Realtime action combat protocol]]		* [[Realtime action combat protocol]]

2006-05-04T15:52:56Z

Connection Handler: TCP->ENet.

← Older revision		Revision as of 15:52, 4 May 2006
Line 19:		Line 19:
	=== Connection Handler ===		=== Connection Handler ===

	The connection handler has one thread to listen for incoming connections, and one thread for each connected client. ~~I think it's best~~ to use TCP as the ~~basis~~ of ~~our protocol, because I'd like~~ the reliability ~~which saves a lot~~ of ~~trouble~~.		The connection handler has one thread to listen for incoming connections, and one thread for each connected client. We decided to use the [http://enet.bespin.org/ ENet library] which uses UDP with some additional TCP-like control mechanisms. We believe that this is the best compromise between the realtime capabilities of UDP and the reliability of TCP.

	The listening threads will drop incoming messages in a message queue, which is processed in the main thread. The incoming messages are then dispatched to a message handler (described below), which won't have to deal with the threading issues.		The listening threads will drop incoming messages in a message queue, which is processed in the main thread. The incoming messages are then dispatched to a message handler (described below), which won't have to deal with the threading issues.