Multiplayer scripting - Revision history

Lou Montana: Redirect to Multiplayer Scripting

2019-01-31T20:17:09Z

R3vo: Undo revision 113531 by R3vo (talk)

2018-12-14T08:49:21Z

Undo revision 113531 by R3vo (talk)

← Older revision		Revision as of 10:49, 14 December 2018
Line 168:		Line 168:
	-[[publicVariable]]		-[[publicVariable]]
	-CoC Network services		-CoC Network services
			-...

			=Addon Scripting=

			(todo)

			{{Stub}}


			[[Category:Scripting Topics]]

R3vo: removed category

2018-12-14T08:45:01Z

removed category

← Older revision		Revision as of 10:45, 14 December 2018
Line 168:		Line 168:
	-[[publicVariable]]		-[[publicVariable]]
	-CoC Network services		-CoC Network services
	~~-...~~

	~~=Addon Scripting=~~

	~~(todo)~~

	~~{{Stub}}~~


	~~[[Category:Scripting Topics]]~~

Miika Jarvinen at 16:12, 28 July 2010

2010-07-28T16:12:01Z

← Older revision		Revision as of 18:12, 28 July 2010
Line 175:		Line 175:

	{{Stub}}		{{Stub}}


			[[Category:Scripting Topics]]

Alef: /* Testing Environment */

2009-01-29T13:36:55Z

Testing Environment

← Older revision		Revision as of 15:36, 29 January 2009
Line 159:		Line 159:
	Some people will try and test their scripts by hosting a server in game, and while this might work it can sometimes produce inaccurate results when you transfer the missions over to a dedicated server.		Some people will try and test their scripts by hosting a server in game, and while this might work it can sometimes produce inaccurate results when you transfer the missions over to a dedicated server.

	A faster testing environment is described in the ~~alef's "nocdkey" page~~ [~~http://community.bistudio.com/wiki/User:Alef/nocdkey~~ User:Alef/~~nocdkey~~]. You need to work disconnected from the Internet, or using the trick described there.		A faster testing environment is described in the article [[User:Alef/MP_testenv\|here]]. You need to work disconnected from the Internet, or using the trick described there.

	=JIP=		=JIP=

Alef: /* faster testing */

2009-01-29T11:51:43Z

faster testing

← Older revision		Revision as of 13:51, 29 January 2009
Line 158:		Line 158:

	Some people will try and test their scripts by hosting a server in game, and while this might work it can sometimes produce inaccurate results when you transfer the missions over to a dedicated server.		Some people will try and test their scripts by hosting a server in game, and while this might work it can sometimes produce inaccurate results when you transfer the missions over to a dedicated server.

			A faster testing environment is described in the alef's "nocdkey" page [http://community.bistudio.com/wiki/User:Alef/nocdkey User:Alef/nocdkey]. You need to work disconnected from the Internet, or using the trick described there.

	=JIP=		=JIP=

Alef: /* game logic link */

2008-03-28T11:07:29Z

game logic link

← Older revision		Revision as of 13:07, 28 March 2008
Line 33:		Line 33:
	?(isServer): call _fnSendMsg		?(isServer): call _fnSendMsg

	; OFP example: all game logic objects are local to the server at all times,		; OFP example: all [[Game_Logic\|game logic]] objects are local to the server at all times,
	; so by placing a reference game logic we get the equivalent of [[isServer]]		; so by placing a reference game logic we get the equivalent of [[isServer]]
	; this code is deprecated in ArmA		; this code is deprecated in ArmA

Tactii_bi_wiki: reordering

2007-07-11T02:43:01Z

reordering

← Older revision		Revision as of 04:43, 11 July 2007
Line 16:		Line 16:

	Another reason for scripts failing in a multiplayer environment is failure to account for global scripting commands. For example, a simple script that respawns a vehicle using [[createVehicle]] may work perfectly in the mission editor, but when run on a dedicated server, a new vehicle is created for every client. That means on a full 64 player server, 65 new vehicles will be created when a vehicle respawns (one for each client and one for the server entity). This kind of error will make a mission unplayable very quickly (especially when someone gets the bright idea of destroying all the extra vehicles, causing them to reproduce exponentially).		Another reason for scripts failing in a multiplayer environment is failure to account for global scripting commands. For example, a simple script that respawns a vehicle using [[createVehicle]] may work perfectly in the mission editor, but when run on a dedicated server, a new vehicle is created for every client. That means on a full 64 player server, 65 new vehicles will be created when a vehicle respawns (one for each client and one for the server entity). This kind of error will make a mission unplayable very quickly (especially when someone gets the bright idea of destroying all the extra vehicles, causing them to reproduce exponentially).

			=Local and Global Scripting Commands=

			Each scripting command can be described as either local or global. (more on this)

	=Server-Side Scripting=		=Server-Side Scripting=
Line 148:		Line 152:

	This is an example of using a single variable to trigger multiple exclusive events repeatedly. This time, the variable and a series of status constants (think of it like an enumerated list in C) must be declared in init.sqs before the monitor scripts begin. When a unit takes the flag, the server changes SectorStatus to the appropriate numerical value and broadcasts it. When the client sees that SectorStatus is no longer in the null state (NO_CAPTURE), it interprets the message and resets SectorStatus to prepare for the next message.		This is an example of using a single variable to trigger multiple exclusive events repeatedly. This time, the variable and a series of status constants (think of it like an enumerated list in C) must be declared in init.sqs before the monitor scripts begin. When a unit takes the flag, the server changes SectorStatus to the appropriate numerical value and broadcasts it. When the client sees that SectorStatus is no longer in the null state (NO_CAPTURE), it interprets the message and resets SectorStatus to prepare for the next message.

	~~=Local and Global Scripting Commands=~~

	~~Each scripting command can be described as either local or global. (more on this)~~

	=Testing Environment=		=Testing Environment=

Tactii_bi_wiki at 02:28, 11 July 2007

2007-07-11T02:28:40Z

Show changes

Hoz: /* Introduction */

2007-02-15T19:09:17Z

Introduction

← Older revision		Revision as of 21:09, 15 February 2007
Line 2:		Line 2:


			Basically, when scripting for a multiplayer mission, you're making a script that will run on several computers concurrently. The game engine itself will, to a great extent, automatically transmit changes in object positions and similar, and some commands will have their effects spread to the other computers. Everything else only matters on the computer the code is executing.

			=The Environment=

			Most scripter's will use a dedicated server for testing their scripts in multi player and 2 client machines. This is generally the most ideal setup as you can make sure that what your seeing on one client is the same on the other client. This is done because in reality when its time to run the mission on public servers, almost every server is dedicated.

	~~Basically, when scripting for~~ a ~~multiplayer mission,~~ you~~'re making~~ a ~~script that will run on several computers concurrently~~. ~~The game engine itself~~ will~~, to~~ a ~~great extent, automatically transmit changes~~ in ~~object positions and similar~~, and ~~some commands will have their effects spread~~ to ~~the other computers. Everything else only matters on the computer the code is executing~~.		Some will run a copy of ArmA in -server mode on the same machine as the client. This is ok if you have a decent machine and not a lot of money. It works but not as nice as a dedicated server.

			Some people will try and test their scripts by hosting a server in game, and while this might work it can sometimes produce inaccurate results when you transfer the missions over to a dedicated server.

	=Launching Scripts=		=Launching Scripts=