Module tutorial - Revision history

Hornet666: /* Creating our areas */

2016-09-04T20:00:17Z

‎Creating our areas

Ladyofpayne: /* Naming conventions */

2013-11-29T06:34:45Z

‎Naming conventions

Sunjammer: /* Giving the player an item */ Adding link

2012-04-30T09:02:00Z

‎Giving the player an item: Adding link

Sunjammer: /* Using a placeable to call a script */ Adding link

2012-04-30T09:00:53Z

‎Using a placeable to call a script: Adding link

Sunjammer: /* Using a trigger to initiate conversation */ Adding links

2012-04-30T08:58:57Z

‎Using a trigger to initiate conversation: Adding links

Sunjammer: /* Introductory cutscene */ Adding links

2012-04-30T08:57:46Z

‎Introductory cutscene: Adding links

Sunjammer: /* Placing area transitions and setting up the world map */ Adding links

2012-04-30T08:56:41Z

‎Placing area transitions and setting up the world map: Adding links

Sunjammer at 08:49, 30 April 2012

2012-04-30T08:49:45Z

Sunjammer: Fixing markup

2012-04-30T08:47:09Z

Fixing markup

JasonMel: /* Naming conventions */

2011-01-28T07:14:35Z

‎Naming conventions

@@ Line 49: / Line 49: @@
 == Creating our areas ==
-This module will be very simple, consisting of only three areas - only two of which will have any signficiant amount of detail. They will be named:
+This module will be very simple, consisting of only three areas - only two of which will have any significant amount of detail. They will be named:
 * demo100ar_wilderness

← Older revision		Revision as of 06:34, 29 November 2013
Line 25:		Line 25:

	Here's a preview of what we're going to put into the demo module, to illustrate how this naming convention looks in practice. We'll be using the four-letter prefix "demo" instead of the usual three-letter one for clarity.		Here's a preview of what we're going to put into the demo module, to illustrate how this naming convention looks in practice. We'll be using the four-letter prefix "demo" instead of the usual three-letter one for clarity.
		+
		+	'''NOTE:''' when you create new items, it's best to stick to unique naming, specially if items belongs to your module. For example: your module UID is "asar" so item, createre, area or any other file should begin with asar_ (asar_mysword).

	== Setting up character generation in a new module ==		== Setting up character generation in a new module ==

@@ Line 173: / Line 173: @@
 The first thing that happens if the player talks to the barkeep and accepts the quest is that the barkeep will give him a key. The key is a "plot item", meaning it will be shown in a separate section of the player's inventory and can't be given away or destroyed by the player, but the mechanism used here can give the player non-plot items as well.
-The function UT_AddItemToInventory takes a resource variable as its parameter. It causes a new instance of the item to be created and added. If you call it multiple times with the same resource, earlier copies won't be affected - multiple copies of the item will be created. You'll see one way of removing an object from the player's inventory at the end of the quest when the innkeeper takes back his sword.
+The function [[UT_AddItemToInventory]] takes a resource variable as its parameter. It causes a new instance of the item to be created and added. If you call it multiple times with the same resource, earlier copies won't be affected - multiple copies of the item will be created. You'll see one way of removing an object from the player's inventory at the end of the quest when the innkeeper takes back his sword.
 == Using a trigger to initiate conversation ==

@@ Line 195: / Line 195: @@
 == Using a placeable to call a script ==
-The lever placeable has a "use" option that allows the player to flip it from one state to the other. When this happens an EVENT_TYPE_USE event is sent to the placeable's event script. We've added a custom event script to the lever to intercept this event and do something special; demo200pl_security_lever.nss.
+The lever placeable has a "use" option that allows the player to flip it from one state to the other. When this happens an [[EVENT_TYPE_USE]] event is sent to the placeable's event script. We've added a custom event script to the lever to intercept this event and do something special; demo200pl_security_lever.nss.
 Rather than handling all the details of what should happen when the lever is pulled right in this script, though, we've instead put them into the main plot file's script. The custom placeable script serves only to set the appropriate main plot file flag.

@@ Line 179: / Line 179: @@
 We want the bandit and his loyal patrons to attack the player before the lever can be pulled. A trigger has been placed in such a manner that the player will have to pass through it before reaching the lever; the trick is now to use that trigger to make the things we want to have happen, happen.
-When a trigger is entered by any entity the trigger's event script is sent an EVENT_TYPE_ENTER event. Note that this is sent ''every'' time the trigger is entered, by ''any'' entity, so the first thing we'll need to do in the event script is a test to ensure that the triggering entity is the player or one of his party members.
+When a trigger is entered by any entity the trigger's event script is sent an [[EVENT_TYPE_ENTER]] event. Note that this is sent ''every'' time the trigger is entered, by ''any'' entity, so the first thing we'll need to do in the event script is a test to ensure that the triggering entity is the player or one of his party members.
 The IsPartyMember function tests to see whether an object is player-controllable, which is true for the player's character and for any creature currently in the player's party. We call it on the event's creator to check if this is the right person; if it's not the event script does nothing.
-If we wanted the bandit and patrons to simply charge and attack the player, we'd have the trigger call UT_TeamGoesHostile(BANDIT_TEAM); directly (the bandit and patrons' creature templates are all set to the same team so that we don't need to set each one hostile individually). In this case an unexplained attack would be strange, so instead a conversation has been set up that has the bandit and patrons explain themselves before attacking. So we've set the trigger script to call UT_Talk instead.
+If we wanted the bandit and patrons to simply charge and attack the player, we'd have the trigger call [[UT_TeamGoesHostile]](BANDIT_TEAM); directly (the bandit and patrons' creature templates are all set to the same team so that we don't need to set each one hostile individually). In this case an unexplained attack would be strange, so instead a conversation has been set up that has the bandit and patrons explain themselves before attacking. So we've set the trigger script to call [[UT_Talk]] instead.
 Once this has been called, we never want the trigger to fire again for anyone. It is important to note that setting a trigger to "inactive" will ''not'' work; an inactive trigger still fires EVENT_TYPE_ENTER whenever an entity enters it. There are several approaches that can be used here:
@@ Line 189: / Line 189: @@
 *Set the event script to check the trigger's active status and not perform any action if it's inactive
 *Use a plot flag to make the code only fire once
-*call Safe_Destroy_Object(OBJECT_SELF, 0); to destroy the trigger entirely
+*Call [[Safe_Destroy_Object]](OBJECT_SELF, 0); to destroy the trigger entirely
 Since there will be no circumstances where we'll need the trigger to become active again in the future, destroying the trigger is the simplest and most foolproof way of accomplishing this.

@@ Line 139: / Line 139: @@
 The cutscene itself is quite simple, consisting of a few camera movements and an actor (substituted by the player) playing a walking animation. See [[cutscene tutorial]] for how to create a cutscene.
-To make it play when the game begins we need to call it at the appropriate time with the CS_LoadCutscene function. The appropriate time has to be after the area that the cutscene is located in as loaded, otherwise the cutscene won't be able to play. The event that's best suited for this is EVENT_TYPE_AREALOAD_SPECIAL, which is called on an area's event script after the area has loaded but before any of the other game systems (AI and so forth) have been enabled. So in this case we want to insert the function call into the area script for the starting area, demo100ar_wilderness. We only want the cutscene to play the first time we enter this area so we've wrapped the function call in a plot flag check;
+To make it play when the game begins we need to call it at the appropriate time with the [[CS_LoadCutscene]] function. The appropriate time has to be after the area that the cutscene is located in as loaded, otherwise the cutscene won't be able to play. The event that's best suited for this is [[EVENT_TYPE_AREALOAD_SPECIAL]], which is called on an area's event script after the area has loaded but before any of the other game systems (AI and so forth) have been enabled. So in this case we want to insert the function call into the area script for the starting area, demo100ar_wilderness. We only want the cutscene to play the first time we enter this area so we've wrapped the function call in a plot flag check;
 <dascript>

@@ Line 65: / Line 65: @@
 The transition between demo100ar_wilderness and demo300ar_road, however, is going to be handled via the world [[map]] instead. The demo's map is a resource named demo000mp_world.
-To create an area transition that sends the player to the world map, set the PLC_AT_DEST_AREA_TAG to the string "world_map". The placeable_core script recognizes this string as a special override that triggers a map transition by sending the module script an EVENT_TYPE_BEGIN_TRAVEL event.
+To create an area transition that sends the player to the world map, set the PLC_AT_DEST_AREA_TAG to the string "world_map". The placeable_core script recognizes this string as a special override that triggers a map transition by sending the module script an [[EVENT_TYPE_BEGIN_TRAVEL]] event.
-Note that you can have multiple world maps in a module, but under the default code you can't directly specify which one an area transition will send the player to. Instead, you will need to call the script function [[WR_SetWorldMapPrimary]] to specify which world map is the currently active "primary" one. In this demo the code that performs this is also in the EVENT_TYPE_MODULE_START event of the module script, since we only have one map and it only needs to be set as primary once. If you have multiple maps in your module you'll need to call this function again later from some other scripted event to change it.
+Note that you can have multiple world maps in a module, but under the default code you can't directly specify which one an area transition will send the player to. Instead, you will need to call the script function [[WR_SetWorldMapPrimary]] to specify which world map is the currently active "primary" one. In this demo the code that performs this is also in the [[EVENT_TYPE_MODULE_START]] event of the module script, since we only have one map and it only needs to be set as primary once. If you have multiple maps in your module you'll need to call this function again later from some other scripted event to change it.
 Here, then, is the complete code for the demo module's EVENT_TYPE_MODULE_START event:
@@ Line 89: / Line 89: @@
 * In EVENT_TYPE_BEGIN_TRAVEL you'll be able to get the target area and waypoint tags from the event object, and then call the [[WorldMapStartTravelling]] function to cause the map to start animating the map trail path the player is following.
-* While the map trail animation is playing, the EVENT_TYPE_WORLDMAP_PRETRANSITION event is called. This is the event where you'll want to call the [[UT_DoAreaTransition]] function to start the loading process of the destination area. The area will load at the same time that the map trail animation is playing, making the transition seem more seamless for the player. Note, however, that EVENT_TYPE_WORLDMAP_PRETRANSITION's event object ''doesn't'' contain the destination area and waypoint tags as members; you'll need to use local variables in the module's variable table to preserve these strings and pass them on from EVENT_TYPE_BEGIN_TRAVEL.
+* While the map trail animation is playing, the [[EVENT_TYPE_WORLDMAP_PRETRANSITION]] event is called. This is the event where you'll want to call the [[UT_DoAreaTransition]] function to start the loading process of the destination area. The area will load at the same time that the map trail animation is playing, making the transition seem more seamless for the player. Note, however, that EVENT_TYPE_WORLDMAP_PRETRANSITION's event object ''doesn't'' contain the destination area and waypoint tags as members; you'll need to use local variables in the module's variable table to preserve these strings and pass them on from EVENT_TYPE_BEGIN_TRAVEL.
 The basic code to handle map travel, then, is:

@@ Line 38: / Line 38: @@
 To call the default character generation system, simply have this event call the following functions:
-<pre>
+<dascript>
              PreloadCharGen();
              StartCharGen(GetHero(),0);
-</pre>
+</dascript>
 PreloadCharGen causes the game to load up various resources that will be used in character generation, and StartCharGen causes the game to show the character generation GUI to the player.
@@ Line 71: / Line 71: @@
 Here, then, is the complete code for the demo module's EVENT_TYPE_MODULE_START event:
-<pre>
+<dascript>
-      case EVENT_TYPE_MODULE_START:
+        case EVENT_TYPE_MODULE_START:
+         {
              object oMapId = GetObjectByTag("demo000mp_world");
@@ Line 81: / Line 81: @@
              break;
+         }
+</dascript>
-</pre>
 Although the default placeable_core script has code in it to recognize that the "world_map" string should lead to a world transition and generates an EVENT_TYPE_BEGIN_TRAVEL event, the default module_core script doesn't actually do anything with this event. This is because the map transition code used in Dragon Age's single player world map transitions is rather complex and has to handle many special cases that depend on plot elements specific to the single player campaign, so BioWare never implemented a basic default - it would have had to be overridden completely anyway.
@@ Line 94: / Line 93: @@
 The basic code to handle map travel, then, is:
-<pre>
+<dascript>
          ////////////////////////////////////////////////////////////////////////
          // Sent by: The engine
@@ Line 130: / Line 129: @@
              break;
+         }
-</pre>
+</dascript>
 We'll need to come back to the module script later on to add some plot-specific code, but for now this is all that's needed to enable a basic adventure to stand on its own.
@@ Line 142: / Line 141: @@
 To make it play when the game begins we need to call it at the appropriate time with the CS_LoadCutscene function. The appropriate time has to be after the area that the cutscene is located in as loaded, otherwise the cutscene won't be able to play. The event that's best suited for this is EVENT_TYPE_AREALOAD_SPECIAL, which is called on an area's event script after the area has loaded but before any of the other game systems (AI and so forth) have been enabled. So in this case we want to insert the function call into the area script for the starting area, demo100ar_wilderness. We only want the cutscene to play the first time we enter this area so we've wrapped the function call in a plot flag check;
-<pre>
+<dascript>
-case EVENT_TYPE_AREALOAD_SPECIAL:
+        case EVENT_TYPE_AREALOAD_SPECIAL:
+         {
              if (!WR_GetPlotFlag(PLT_DEMO000PL_MAIN, DEMO_INTRO_COMPLETE))
@@ Line 152: / Line 151: @@
              break;
+         }
-</pre>
+</dascript>
 == The main plot file ==

← Older revision		Revision as of 07:14, 28 January 2011
Line 25:		Line 25:

	Here's a preview of what we're going to put into the demo module, to illustrate how this naming convention looks in practice. We'll be using the four-letter prefix "demo" instead of the usual three-letter one for clarity.		Here's a preview of what we're going to put into the demo module, to illustrate how this naming convention looks in practice. We'll be using the four-letter prefix "demo" instead of the usual three-letter one for clarity.
−
−	~~[[screenshot of demo resource palette]]~~

	== Setting up character generation in a new module ==		== Setting up character generation in a new module ==