Factions - Revision history

Dcurrent at 04:18, 3 August 2026

2026-08-03T04:18:38Z

← Older revision		Revision as of 00:18, 3 August 2026
Line 3:		Line 3:
	Faction properties are divided into two systems, each comprised of supporting properties:		Faction properties are divided into two systems, each comprised of supporting properties:

	* '''Group factions''' ~~comprise~~ 52 ~~available~~ faction group flags.		* '''Group factions''' act on a set of 52 predefined faction group flags.
	** '''Membership -''' Which factions the entity belongs to.		** '''Membership -''' Which factions the entity belongs to.
	** '''Hostility -''' Which factions the AI and targeting functions consider enemies.		** '''Hostility -''' Which factions the AI and targeting functions consider enemies.

Dcurrent at 17:33, 28 July 2026

2026-07-28T17:33:13Z

← Older revision		Revision as of 13:33, 28 July 2026
Line 10:		Line 10:
	* '''Type factions''' use legacy entity types such as <code>player</code>, <code>enemy</code>, and <code>npc</code>.		* '''Type factions''' use legacy entity types such as <code>player</code>, <code>enemy</code>, and <code>npc</code>.
	** '''Hostility -''' Which types the AI ad targeting functions consider enemies.		** '''Hostility -''' Which types the AI ad targeting functions consider enemies.
	** '''Damage -''' Which types the the entity ca damage with attacks.		** '''Damage -''' Which types the the entity can damage with attacks.
	** '''Indirect Damage -''' Which types the entity can damage collaterally (ex. thrown by another entity).		** '''Indirect Damage -''' Which types the entity can damage collaterally (ex. thrown by another entity).
	Both systems may be combined for highly specific interaction rules.		Both systems may be combined for highly specific interaction rules.

Dcurrent at 17:02, 28 July 2026

2026-07-28T17:02:59Z

← Older revision		Revision as of 13:02, 28 July 2026
Line 1:		Line 1:
	Factions control how entities interact with each other. Faction settings independently determine which groups an entity belongs to, which entities it considers hostile, and which entities it can damage.		Factions control how entities interact with each other. Faction settings independently determine which groups an entity belongs to, which entities it considers hostile, and which entities it can damage.

	Faction properties are divided into two systems:		Faction properties are divided into two systems, each comprised of supporting properties:

	* '''Group factions''' comprise 52 available group flags.		* '''Group factions''' comprise 52 available faction group flags.
			** '''Membership -''' Which factions the entity belongs to.
			** '''Hostility -''' Which factions the AI and targeting functions consider enemies.
			** '''Damage -''' Which factions the entity can damage with attacks.
			** '''Indirect Damage -''' Which factions the entity can damage collaterally (ex. thrown by another entity).
	* '''Type factions''' use legacy entity types such as <code>player</code>, <code>enemy</code>, and <code>npc</code>.		* '''Type factions''' use legacy entity types such as <code>player</code>, <code>enemy</code>, and <code>npc</code>.
	~~In turn, Groups and Type are each made up of four properties that may contain one or more assignments:~~		** '''Hostility -''' Which types the AI ad targeting functions consider enemies.
			** '''Damage -''' Which types the the entity ca damage with attacks.
	* ~~'''Membership -''' Which factions the entity belongs to.~~		** '''Indirect Damage -''' Which types the entity can damage collaterally (ex. thrown by another entity).
	* '''Hostility -''' Which ~~factions~~ the AI ~~and~~ targeting functions ~~considers an enemy~~.
	* '''Damage -''' Which ~~factions~~ the entity ~~can~~ damage with attacks.
	* '''Indirect Damage -''' Which ~~factions~~ the entity can damage collaterally (ex. thrown by another entity).

	Both systems may be combined for highly specific interaction rules.		Both systems may be combined for highly specific interaction rules.

	Note this means that by design, hostility and damage permissions are separate. An entity may consider another entity hostile without being able to damage it, or damage an entity it does not consider hostile.		Note this means that by design, hostility and damage permissions are separate. An entity may consider another entity hostile without being able to damage it, or damage an entity it does not consider hostile.

	~~Group factions~~ are script accessible and stored in both [[entity]] and [[model]] structures - meaning faction data exists at three levels - template, starting default, and current condition. This in turn enables on the fly swapping and restoration. For example, an entity might be affected with mind control by modifying its group flags for a limited time, then restored from its starting defaults when the effect wears off.		Factions properties are script accessible and stored in both [[entity]] and [[model]] structures - meaning faction data exists at three levels - template, starting default, and current condition. This in turn enables on the fly swapping and restoration. For example, an entity might be affected with mind control by modifying its group flags for a limited time, then restored from its starting defaults when the effect wears off.

	== Design ==		== Design ==

Dcurrent: /* Damage indirect */

2026-07-28T15:41:48Z

Damage indirect

← Older revision		Revision as of 11:41, 28 July 2026
Line 97:		Line 97:
	Faction names are case-insensitive. For example, <code>a1</code> and <code>A1</code> identify the same faction.		Faction names are case-insensitive. For example, <code>a1</code> and <code>A1</code> identify the same faction.

	An entity may belong to multiple factions and may target multiple factions with each property. For example, an entity belonging to factions <code>a</code> and <code>b1</code> matches any faction check containing either group.		An entity may belong to multiple factions and may target multiple factions with each property. For example, an entity belonging to factions <code>a</code> and <code>b1</code> matches any faction check containing either group. There is no additional CPU or memory cost for number of faction groups in use by an object.

	=== Group values ===		=== Group values ===
Line 171:		Line 171:
	\| <code>a1</code> through <code>z1</code>		\| <code>a1</code> through <code>z1</code>
	\| Permits direct damage against members of the selected additional faction groups.		\| Permits direct damage against members of the selected additional faction groups.
			\|-
			\|<code>all0</code>
			\|Permits direct damage against members of every normal group from A-Z.
			\|-
			\|<code>all1</code>
			\|Permits direct damage against members of every normal group from A1-Z1.
	\|-		\|-
	\| <code>all</code>		\| <code>all</code>
Line 206:		Line 212:
	\|-		\|-
	\| <code>a</code> through <code>z</code>		\| <code>a</code> through <code>z</code>
	\| Permits indirect damage against members of the selected ~~original~~ faction groups.		\| Permits indirect damage against members of the selected first 26 faction groups.
	\|-		\|-
	\| <code>a1</code> through <code>z1</code>		\| <code>a1</code> through <code>z1</code>
	\| Permits indirect damage against members of the selected ~~additional~~ faction groups.		\| Permits indirect damage against members of the selected second 26 faction groups.
			\|-
			\|<code>all0</code>
			\|Permits indirect damage against members of every normal group from A-Z.
			\|-
			\|<code>all1</code>
			\|Permits indirect damage against members of every normal group from A1-Z1.
	\|-		\|-
	\| <code>all</code>		\| <code>all</code>
Line 246:		Line 258:
	\|-		\|-
	\| <code>a</code> through <code>z</code>		\| <code>a</code> through <code>z</code>
	\| Marks members of the selected ~~original~~ faction groups as hostile.		\| Marks members of the selected first 26 faction groups as hostile.
	\|-		\|-
	\| <code>a1</code> through <code>z1</code>		\| <code>a1</code> through <code>z1</code>
	\| Marks members of the selected ~~additional~~ faction groups as hostile.		\| Marks members of the selected second 26 faction groups as hostile.
			\|-
			\|<code>all0</code>
			\|Marks members of every normal faction group from A-Z as hostile.
			\|-
			\|<code>all1</code>
			\|Marks members of every normal faction group from A1-Z1 as hostile.
	\|-		\|-
	\| <code>all</code>		\| <code>all</code>

Dcurrent: /* Group values */

2026-07-28T15:33:21Z

Group values

← Older revision		Revision as of 11:33, 28 July 2026
Line 106:		Line 106:
	\|-		\|-
	\| <code>a</code> through <code>z</code>		\| <code>a</code> through <code>z</code>
	\| Selects one of the ~~original~~ 26 normal faction groups.		\| Selects one of the first 26 normal faction groups.
	\|-		\|-
	\| <code>a1</code> through <code>z1</code>		\| <code>a1</code> through <code>z1</code>
	\| Selects one of the ~~additional~~ 26 normal faction groups.		\| Selects one of the second 26 normal faction groups.
	\|-		\|-
	\|<code>all0</code>		\|<code>all0</code>
Line 118:		Line 118:
	\|-		\|-
	\| <code>all</code>		\| <code>all</code>
	\| Selects every normal faction group ~~from <code>a</code> through <code>z</code> and <code>a1</code> through <code>z1</code>~~.		\| Selects every normal faction group.
	\|-		\|-
	\| <code>neutral</code>		\| <code>neutral</code>

Dcurrent: /* Group factions */

2026-07-28T15:26:33Z

Group factions

← Older revision		Revision as of 11:26, 28 July 2026
Line 110:		Line 110:
	\| <code>a1</code> through <code>z1</code>		\| <code>a1</code> through <code>z1</code>
	\| Selects one of the additional 26 normal faction groups.		\| Selects one of the additional 26 normal faction groups.
			\|-
			\|<code>all0</code>
			\|Selects every normal faction group from <code>a</code> through <code>z</code>.
			\|-
			\|<code>all1</code>
			\|Selects every normal faction group from <code>a1</code> through <code>z1</code>.
	\|-		\|-
	\| <code>all</code>		\| <code>all</code>
Line 513:		Line 519:
	\| <code>FACTION_GROUP_TYPE_INCLUSIVE</code>		\| <code>FACTION_GROUP_TYPE_INCLUSIVE</code>
	\| Requires both group and type checks.		\| Requires both group and type checks.
			\|-
			\|<code>FACTION_GROUP_ALL_NORMAL_0</code>
			\|Contains every normal faction from A-Z.
			\|-
			\|<code>FACTION_GROUP_ALL_NORMAL_1</code>
			\|Contains every normal faction from A1-Z1.
	\|-		\|-
	\| <code>FACTION_GROUP_ALL_NORMAL</code>		\| <code>FACTION_GROUP_ALL_NORMAL</code>

Dcurrent: /* Design */

2026-07-28T15:04:17Z

Design

← Older revision		Revision as of 11:04, 28 July 2026
Line 24:		Line 24:
	Groups may represent geography, allegiance, species, political status, temporary conditions, or any other distinction useful to the project. The resulting combinations are expressed through four hardware-native masks: membership, hostility, direct damage, and indirect damage.		Groups may represent geography, allegiance, species, political status, temporary conditions, or any other distinction useful to the project. The resulting combinations are expressed through four hardware-native masks: membership, hostility, direct damage, and indirect damage.

	Each property supports 2<sup>52</sup> possible group arrangements, not merely a choice among 52 factions. Together, the four faction properties provide approximately 4.11 × 10<sup>62</sup> possible configurations - roughly 4 × 10<sup>38</sup> configurations for every star in the observable universe, using [https://science.nasa.gov/universe/stars/ NASA's upper estimate].		Each property supports 2<sup>52</sup> possible group arrangements, not merely a choice among 52 factions. Together, the four faction properties provide approximately 4.11 * 10<sup>62</sup> possible configurations. That's roughly 4 * 10<sup>38</sup> configurations for every star in the observable universe, using [https://science.nasa.gov/universe/stars/ NASA's upper estimate].

	=== Higher-Level Example ===		=== Higher-Level Example ===

Dcurrent: /* Design */

2026-07-28T15:02:15Z

Design

← Older revision		Revision as of 11:02, 28 July 2026
Line 20:		Line 20:
	== Design ==		== Design ==

	OpenBOR's faction ~~system~~ is intentionally designed as a hardware-speed primitive for complex higher-level relationships. ~~Creators may use the~~ 52 native ~~flags directly as ready-made~~ factions, or arrange them as behavioral flags for any number of custom factions. Creator-defined factions may use several flags, share flags with other factions, change their assignments during play, or use no native group at all.		OpenBOR's faction API is intentionally designed to function either as a standalone faction system or as a hardware-speed primitive for complex higher-level relationships. Its 52 native factions are obviously more than most projects will ever approach. Even so, creators may instead arrange them as behavioral flags for any number of custom factions. Creator-defined factions may use several flags, share flags with other factions, change their assignments during play, or use no native group at all.

	Groups may represent geography, allegiance, species, political status, temporary conditions, or any other distinction useful to the project. The resulting combinations are expressed through four hardware-native masks: membership, hostility, direct damage, and indirect damage.		Groups may represent geography, allegiance, species, political status, temporary conditions, or any other distinction useful to the project. The resulting combinations are expressed through four hardware-native masks: membership, hostility, direct damage, and indirect damage.

	Each property supports 2<sup>52</sup> possible group arrangements, not merely 52 factions. Together, the four faction properties provide approximately ~~'''~~4.11 * 10<sup>62</sup>~~'''~~ possible configurations - roughly ~~'''~~4 * 10<sup>38</sup>~~'''~~ configurations for every star in the observable universe, using [https://science.nasa.gov/universe/stars/ NASA's upper estimate].		Each property supports 2<sup>52</sup> possible group arrangements, not merely a choice among 52 factions. Together, the four faction properties provide approximately 4.11 × 10<sup>62</sup> possible configurations - roughly 4 × 10<sup>38</sup> configurations for every star in the observable universe, using [https://science.nasa.gov/universe/stars/ NASA's upper estimate].

	=== Higher-Level Example ===		=== Higher-Level Example ===

Dcurrent at 14:54, 28 July 2026

2026-07-28T14:54:15Z

← Older revision		Revision as of 10:54, 28 July 2026
Line 28:		Line 28:
	=== Higher-Level Example ===		=== Higher-Level Example ===

	Suppose a project tracks ''Game of Thrones'' (or Song of Fire ~~and Ice~~ if you prefer) houses in its own relationship table. For a Stark-aligned entity, the table might resolve the current political state as follows:		Suppose a project tracks ''Game of Thrones'' (or A Song of Ice and Fire if you prefer) houses in its own relationship table. For a Stark-aligned entity, the table might resolve the current political state as follows:
	{\| class="wikitable"		{\| class="wikitable"
	\|+		\|+
Line 48:		Line 48:
	\|House Greyjoy		\|House Greyjoy
	\|In rebellion		\|In rebellion
	\|~~Neutral~~		\|Unaligned with the North
	\|B G		\|B G
	\|-		\|-
Line 95:		Line 95:
	</syntaxhighlight>		</syntaxhighlight>

	Faction names are case-insensitive. For example, <code>a1</code>, <code>A1~~</code>, and <code>a1~~</code> identify the same faction.		Faction names are case-insensitive. For example, <code>a1</code> and <code>A1</code> identify the same faction.

	An entity may belong to multiple factions and may target multiple factions with each property. For example, an entity belonging to factions <code>a</code> and <code>b1</code> matches any faction check containing either group.		An entity may belong to multiple factions and may target multiple factions with each property. For example, an entity belonging to factions <code>a</code> and <code>b1</code> matches any faction check containing either group.

Dcurrent at 14:41, 28 July 2026

2026-07-28T14:41:48Z

← Older revision		Revision as of 10:41, 28 July 2026
Line 14:		Line 14:
	Both systems may be combined for highly specific interaction rules.		Both systems may be combined for highly specific interaction rules.

	Note this means hostility and damage ~~permission~~ are separate. An entity may consider another entity hostile without being able to damage it, or damage an entity it does not consider hostile. Group factions are script accessible and stored in both [[entity]] and [[model]] structures - meaning ~~effectively~~ three levels - template, starting default, and current condition. This in turn enables on the fly swapping and restoration. For example, an entity might be affected by mind control by modifying its group flags for a limited time, then ~~restore~~ from its starting defaults when the effect wears off.		Note this means that by design, hostility and damage permissions are separate. An entity may consider another entity hostile without being able to damage it, or damage an entity it does not consider hostile.

			Group factions are script accessible and stored in both [[entity]] and [[model]] structures - meaning faction data exists at three levels - template, starting default, and current condition. This in turn enables on the fly swapping and restoration. For example, an entity might be affected with mind control by modifying its group flags for a limited time, then restored from its starting defaults when the effect wears off.

	== Design ==		== Design ==