Tribe Rework - Revision history

Zee: Blanked the page

2011-09-22T14:19:50Z

Blanked the page

Zee: /* Provisional Functions */

2011-08-10T12:00:15Z

Provisional Functions

← Older revision		Revision as of 12:00, 10 August 2011
Line 214:		Line 214:
	\|x is an item name		\|x is an item name
	\|requires a memory containing the position of another npc trading items of type x		\|requires a memory containing the position of another npc trading items of type x
			\|-
			\|memory(x)
			\|requirement
			\|x is a memory name
			\|requires a memory. Especially used when looking for resources... if no memory is available explore for it.
	\|-		\|-
	\|alterResource(x,y)		\|alterResource(x,y)

Zee: /* Provisional Functions */ added mate() function

2011-08-07T14:40:08Z

Provisional Functions: added mate() function

← Older revision		Revision as of 14:40, 7 August 2011
Line 264:		Line 264:
	\|none		\|none
	\|sends all selected members to mine a previous selected resource		\|sends all selected members to mine a previous selected resource
			\|-
			\|mate()
			\|algorithm step
			\|none
			\|sends all selected members a 'tribe:breed' perception
	\|-		\|-
	\|select(x,y)		\|select(x,y)

Zee: /* Provisional Functions */

2011-08-05T20:03:26Z

Provisional Functions

← Older revision		Revision as of 20:03, 5 August 2011
Line 179:		Line 179:
	\|x is a recipe name		\|x is a recipe name
	\|loads a recipe at the initialization of the tribe		\|loads a recipe at the initialization of the tribe
			\|-
			\|sleepPeriod(x)
			\|tribe info
			\|{ diurnal, nocturnal, nosleep }
			\|decides when tribe members should go to sleep... if they should at all
	\|-		\|-
	\|tribesman(x,y)		\|tribesman(x,y)

Zee: /* Provisional Functions */

2011-08-05T19:00:19Z

Provisional Functions

← Older revision		Revision as of 19:00, 5 August 2011
Line 289:		Line 289:
	\|x is any value		\|x is any value
	\|sets the tribe secondary buffer (recipeAmountBuffer) to the given value		\|sets the tribe secondary buffer (recipeAmountBuffer) to the given value
			\|-
			\|addMember(x)
			\|algorithm step
			\|x is a member type
			\|adds a new member of type 'x' to the tribe
	\|-		\|-
	\|}		\|}

Zee: added Assets information

2011-08-03T22:05:37Z

added Assets information

← Older revision		Revision as of 22:05, 3 August 2011
Line 24:		Line 24:
	*npc's are loaded by the psNPCClient and assigned to the tribe		*npc's are loaded by the psNPCClient and assigned to the tribe

	Further on, each Tribal Object is linked to in the Recipe Manager. (a pointer is sent and loaded into a csArray)		Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
	For each tribe loaded, the Recipe Manager does the following:		For each tribe loaded, the Recipe Manager does the following:
	* assembles a data structure named 'TribeData'		* assembles a data structure named 'TribeData'
Line 38:		Line 38:

	The Recipe Manager parses the contents of the recipe:		The Recipe Manager parses the contents of the recipe:
	*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes ~~with~~ achieves the requirement on top of the tribe's recipe list		*checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list


Line 378:		Line 378:
	<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />		<react event="target out of chase" behavior="Chase" absolute="0" only_interrupt="chase" />
	</npctype>		</npctype>

			== Assets ==

			Assets are items and buildings that belong to the tribe. They are held in the 'assets' array (which acts like a bank) in the tribal object.

			An Asset data structure contains the following:
			*name
			item - a gemNPCItem that will hold how the item/building looks
			*quantity - an int which will hold how many items of a kind the tribe has (used only for items)
			*pos - a csVector3 holding the position of the item (used only for buildings)
			*building - a boolean value (flagged as true for building entries)

			I found that keeping positions & multiple entries for items would prove quite useless... and thought of a better practice to remove all tribal items from the world and keeping them as numbers.

	== Pros & Cons ==		== Pros & Cons ==

Zee: /* Tribal Object */

2011-08-03T21:57:37Z

Tribal Object

← Older revision		Revision as of 21:57, 3 August 2011
Line 55:		Line 55:
	*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.		*an array of Recipe pointers which acts more as a priority queue for keeping recipes. Initially, only the tribal recipe will be there. After initialization, persistent recipes (which will never expire) will be pushed there and act as goals for the tribe. Based on the goals, normal recipes will be pushed there... and if requirements are not met... recipes to meet the requirements... and the list can go on forever.
	*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.		*some memory entries which act as registers for sending data to tribe members. (E.g.: the memory named activeLocation, in which the tribal object will place location data for the tribe members to locateOp on them... as the place of the new building, or the place of a resource, or the place of a nearby tribe) Using this we can load data in the register, and fire a reaction to send members to work on "tribe:memory:activeLocation", for example.
			*an array of Assets (see below)

	==Recipe Manager==		==Recipe Manager==

Zee: /* Provisional Functions */

2011-08-02T16:59:58Z

Provisional Functions

← Older revision		Revision as of 16:59, 2 August 2011
Line 271:		Line 271:
	\|trade(x,y)		\|trade(x,y)
	\|algorithm step		\|algorithm step
	\|x is the item/tria quantity given by the tribesman, y is the item/tria quantity ~~received~~ by the other npc		\|x is the item/tria quantity given by the tribesman, y is the item/tria quantity given by the other npc
	\|Performs a trade between the tribesman and the npc.		\|Performs a trade between the tribesman and the npc.
	\|-		\|-

Zee: /* Provisional Functions */

2011-08-02T16:59:16Z

Provisional Functions

@@ Line 203: / Line 203: @@
 |x is a recipe's name, y is the number of recipes
 |require a recipe
 |-
 |alterResource(x,y)
@@ Line 263: / Line 268: @@
 |none
 |Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
 |-
 |}
-Much more algorithm steps will be added soon.
+More algorithm steps might be added.
 == AbstractTribesman npctype ==

Zee: /* Provisional Functions */

2011-08-02T14:15:10Z

Provisional Functions

← Older revision		Revision as of 14:15, 2 August 2011
Line 258:		Line 258:
	\|x is the type of npcs, y is the number		\|x is the type of npcs, y is the number
	\|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.		\|Important: Selects the npcs on which to sends the following commands. It should always be used as a first command.
			\|-
			\|guard()
			\|algorithm step
			\|none
			\|Makes the previous selected NPCs guard the previous selected Location. (using select(x,y) and locateMemory(z))
	\|-		\|-
	\|}		\|}