Base Building - Revision history

Muqsit at 08:42, 17 July 2025

2025-07-17T08:42:34Z

@@ Line 54: / Line 54: @@
 <!-- ==Derps== -->
 <!-- Talk about how to setup derps, like the layout and stuff. Stuff to watch out for, like creeper eggs. -->
 ==Tips & Tricks==

Muqsit: /* Faction Shield */

2025-07-17T08:15:11Z

Faction Shield

← Older revision		Revision as of 08:15, 17 July 2025
Line 59:		Line 59:
	===Faction Shield===		===Faction Shield===
	[[File:Faction_shield.png\|thumb\|Status of the faction's shield is visible to all members by running <code>/f shield</code>.]]		[[File:Faction_shield.png\|thumb\|Status of the faction's shield is visible to all members by running <code>/f shield</code>.]]
	Every faction is entitled to a daily 8-hour shield window. During this period, base claims (including the core claim) are protected from explosive damage~~. Base claims created during an active shield are not protected~~. Custom blocks and spawners cannot be mined or exploded in protected claims 1 hour before until 1 hour after the window. Base claims can neither be unclaimed nor overclaimed during the shield window.		Every faction is entitled to a daily 8-hour shield window. During this period, base claims (including the core claim) are protected from explosive damage. Custom blocks and spawners cannot be mined or exploded in protected claims 1 hour before until 1 hour after the window. Base claims can neither be unclaimed nor overclaimed during the shield window.

	A shield can be configured to begin at any minute of the day. Once configured, the shield automatically commences daily. Timings and status are visible to all members by running <code>/f shield</code>. Timings cannot be reconfigured from 1 hour before until 1 hour after the shield window.		A shield can be configured to begin at any minute of the day. Once configured, the shield automatically commences daily. Timings and status are visible to all members by running <code>/f shield</code>. Timings cannot be reconfigured from 1 hour before until 1 hour after the shield window.

	Shield is intended as a basic protection to cover hours of low member availability when live counter defense is not feasible. It does not protected against insiders. Raid claims and premium claims are not protected by shield.		Shield is intended as a basic protection to cover hours of low member availability when live counter defense is not feasible. It does not protected against insiders. Raid claims and premium claims are not protected by shield. Base claims created during an active shield are not protected.

	==Tips & Tricks==		==Tips & Tricks==

Muqsit: /* Faction Shield */

2025-07-17T08:13:49Z

Faction Shield

← Older revision		Revision as of 08:13, 17 July 2025
Line 61:		Line 61:
	Every faction is entitled to a daily 8-hour shield window. During this period, base claims (including the core claim) are protected from explosive damage. Base claims created during an active shield are not protected. Custom blocks and spawners cannot be mined or exploded in protected claims 1 hour before until 1 hour after the window. Base claims can neither be unclaimed nor overclaimed during the shield window.		Every faction is entitled to a daily 8-hour shield window. During this period, base claims (including the core claim) are protected from explosive damage. Base claims created during an active shield are not protected. Custom blocks and spawners cannot be mined or exploded in protected claims 1 hour before until 1 hour after the window. Base claims can neither be unclaimed nor overclaimed during the shield window.

	A shield can be configured to begin ~~from~~ any minute of the day. Once configured, the shield automatically commences daily. Timings and status are visible to all members by running <code>/f shield</code>. Timings cannot be reconfigured ~~between~~ 1 hour before until 1 hour after the shield window.		A shield can be configured to begin at any minute of the day. Once configured, the shield automatically commences daily. Timings and status are visible to all members by running <code>/f shield</code>. Timings cannot be reconfigured from 1 hour before until 1 hour after the shield window.

	Shield is ~~meant to be~~ a basic protection to cover hours of low member availability when live counter defense is not feasible. It does not protected against insiders. Raid claims and premium claims are not protected by shield.		Shield is intended as a basic protection to cover hours of low member availability when live counter defense is not feasible. It does not protected against insiders. Raid claims and premium claims are not protected by shield.

	==Tips & Tricks==		==Tips & Tricks==

Muqsit: /* Defense */

2025-07-17T08:12:05Z

Defense

← Older revision		Revision as of 08:12, 17 July 2025
Line 56:		Line 56:

	==Defense==		==Defense==
	A ~~base~~ defense is a countermeasure ~~you put~~ in place to deter ~~and~~ delay [[Raiding\|raiders]] with the goal to buy ~~yourself~~ some time.		A defense is a countermeasure a faction puts in place to deter or delay [[Raiding\|raiders]] with the goal to buy themself some time.
	===Faction Shield===		===Faction Shield===
	[[File:Faction_shield.png\|thumb\|Status of the faction's shield is visible to all members by running <code>/f shield</code>.]]		[[File:Faction_shield.png\|thumb\|Status of the faction's shield is visible to all members by running <code>/f shield</code>.]]

Muqsit at 08:11, 17 July 2025

2025-07-17T08:11:22Z

← Older revision		Revision as of 08:11, 17 July 2025
Line 49:		Line 49:
	\| column widths=,,7em		\| column widths=,,7em
	}}</div>		}}</div>
			<!-- TODO -->
			<!-- ==Base== -->
			<!-- Talk about the blocks to use for main base, for buffers aka. walls -->
			<!-- ==Derps== -->
			<!-- Talk about how to setup derps, like the layout and stuff. Stuff to watch out for, like creeper eggs. -->

	==~~Base~~==		==Defense==
	<!-~~- Talk about~~ the blocks to ~~use for main base~~, ~~for buffers aka~~. ~~walls --~~>		A base defense is a countermeasure you put in place to deter and delay [[Raiding\|raiders]] with the goal to buy yourself some time.
			===Faction Shield===
			[[File:Faction_shield.png\|thumb\|Status of the faction's shield is visible to all members by running <code>/f shield</code>.]]
			Every faction is entitled to a daily 8-hour shield window. During this period, base claims (including the core claim) are protected from explosive damage. Base claims created during an active shield are not protected. Custom blocks and spawners cannot be mined or exploded in protected claims 1 hour before until 1 hour after the window. Base claims can neither be unclaimed nor overclaimed during the shield window.

			A shield can be configured to begin from any minute of the day. Once configured, the shield automatically commences daily. Timings and status are visible to all members by running <code>/f shield</code>. Timings cannot be reconfigured between 1 hour before until 1 hour after the shield window.

	~~==Derps==~~		Shield is meant to be a basic protection to cover hours of low member availability when live counter defense is not feasible. It does not protected against insiders. Raid claims and premium claims are not protected by shield.
	~~<!-- Talk about how~~ to ~~setup derps, like the layout~~ and ~~stuff. Stuff to watch out for, like creeper eggs~~. ~~-->~~

	==Tips & Tricks==		==Tips & Tricks==
	<!-- Talk about "Show chunk coordinates" cosmic settings, sponges, chunk ~~busteres~~, gen buckets, ice blocks for watering walls fast -->		<!-- Talk about "Show chunk coordinates" cosmic settings, sponges, chunk busters, gen buckets, ice blocks for watering walls fast -->

	==Timeline==		==Timeline==
	{{Changelog:Timeline_Base_building}}		{{Changelog:Timeline_Base_building}}

Muqsit at 01:37, 18 March 2025

2025-03-18T01:37:02Z

← Older revision		Revision as of 01:37, 18 March 2025
Line 36:		Line 36:
	Permission collections are also known as <em>permission groups</em>. The 3 permission groups are: player · role · faction. When a player is applicable to multiple permission groups within a label, the <em>player</em> permission group takes priority, followed by <em>role</em> permissions, and lastly <em>faction</em> permissions.		Permission collections are also known as <em>permission groups</em>. The 3 permission groups are: player · role · faction. When a player is applicable to multiple permission groups within a label, the <em>player</em> permission group takes priority, followed by <em>role</em> permissions, and lastly <em>faction</em> permissions.

			[[File:FactionLabelTest.png\|thumb\|Output from running <code>/f label test</code> to evaluate permissions of a player for a given chunk.]]
	Running <code>/f label create mylabel</code> creates a label named <em>mylabel</em>. This label is ineffective by default. The label can be assigned to a specific chunk, to all chunks touching a chunk, or to all claimed chunks through <code>/f label edit mylabel</code> and heading to the <code>Manage Claims</code> section. The same panel also offers ways to rename, change priority, and set permissions for different players, roles, and factions. Permissions in a given chunk for a given player (whether online or offline) can be tested by standing in the chunk and running <code>/f label test <player></code>.		Running <code>/f label create mylabel</code> creates a label named <em>mylabel</em>. This label is ineffective by default. The label can be assigned to a specific chunk, to all chunks touching a chunk, or to all claimed chunks through <code>/f label edit mylabel</code> and heading to the <code>Manage Claims</code> section. The same panel also offers ways to rename, change priority, and set permissions for different players, roles, and factions. Permissions in a given chunk for a given player (whether online or offline) can be tested by standing in the chunk and running <code>/f label test <player></code>.
	~~[[File:FactionLabelTest.png\|thumb\|Output from running <code>/f label test</code> to evaluate permissions of a player for a given chunk.]]~~

	A permission can be given one of 3 values—<em>allow</em>, <em>deny</em>, and <em>default</em>. If a permission is set to <em>default</em>, the label is effectively ignored and the next label is evaluated. If a label with a non-default value (i.e., <em>allow</em> or <em>deny</em>) is not found, then default (i.e., hardcoded) role permission are used as fallback, and apply only to members of the faction.		A permission can be given one of 3 values—<em>allow</em>, <em>deny</em>, and <em>default</em>. If a permission is set to <em>default</em>, the label is effectively ignored and the next label is evaluated. If a label with a non-default value (i.e., <em>allow</em> or <em>deny</em>) is not found, then default (i.e., hardcoded) role permission are used as fallback, and apply only to members of the faction.

Muqsit: /* Permission labels */

2025-03-18T01:36:39Z

Permission labels

← Older revision		Revision as of 01:36, 18 March 2025
Line 34:		Line 34:
	Labels consist of 6 properties—a name (unique), a priority value (default: 0), an ''auto-set'' toggle (default: false), a collection of player permissions, a collection of role permissions, and a collection of faction permissions. Multiple labels can be assigned to one claim, in which case the label with the highest priority is evaluated first. Labels with auto-set toggle enabled are automatically applied to any new claims.		Labels consist of 6 properties—a name (unique), a priority value (default: 0), an ''auto-set'' toggle (default: false), a collection of player permissions, a collection of role permissions, and a collection of faction permissions. Multiple labels can be assigned to one claim, in which case the label with the highest priority is evaluated first. Labels with auto-set toggle enabled are automatically applied to any new claims.

	Permission collections are also known as <em>permission groups</em>. The 3 permission groups are: player · role · faction. When a player is applicable to multiple permission groups within a label, the <em>player</em> permission group takes priority, followed by <em>role</em> permissions, and lastly <em>faction</em> permissions. Permissions in a given chunk for a given player can be tested by standing in the chunk and running <code>/f label test <player></code>.		Permission collections are also known as <em>permission groups</em>. The 3 permission groups are: player · role · faction. When a player is applicable to multiple permission groups within a label, the <em>player</em> permission group takes priority, followed by <em>role</em> permissions, and lastly <em>faction</em> permissions.

			Running <code>/f label create mylabel</code> creates a label named <em>mylabel</em>. This label is ineffective by default. The label can be assigned to a specific chunk, to all chunks touching a chunk, or to all claimed chunks through <code>/f label edit mylabel</code> and heading to the <code>Manage Claims</code> section. The same panel also offers ways to rename, change priority, and set permissions for different players, roles, and factions. Permissions in a given chunk for a given player (whether online or offline) can be tested by standing in the chunk and running <code>/f label test <player></code>.
	[[File:FactionLabelTest.png\|thumb\|Output from running <code>/f label test</code> to evaluate permissions of a player for a given chunk.]]		[[File:FactionLabelTest.png\|thumb\|Output from running <code>/f label test</code> to evaluate permissions of a player for a given chunk.]]

Muqsit at 01:31, 18 March 2025

2025-03-18T01:31:30Z

← Older revision		Revision as of 01:31, 18 March 2025
Line 34:		Line 34:
	Labels consist of 6 properties—a name (unique), a priority value (default: 0), an ''auto-set'' toggle (default: false), a collection of player permissions, a collection of role permissions, and a collection of faction permissions. Multiple labels can be assigned to one claim, in which case the label with the highest priority is evaluated first. Labels with auto-set toggle enabled are automatically applied to any new claims.		Labels consist of 6 properties—a name (unique), a priority value (default: 0), an ''auto-set'' toggle (default: false), a collection of player permissions, a collection of role permissions, and a collection of faction permissions. Multiple labels can be assigned to one claim, in which case the label with the highest priority is evaluated first. Labels with auto-set toggle enabled are automatically applied to any new claims.

	Permission collections are also known as <em>permission groups</em>. The 3 permission groups are: player · role · faction. When a player is applicable to multiple permission groups within a label, the <em>player</em> permission group takes priority, followed by <em>role</em> permissions, and lastly <em>faction</em> permissions.		Permission collections are also known as <em>permission groups</em>. The 3 permission groups are: player · role · faction. When a player is applicable to multiple permission groups within a label, the <em>player</em> permission group takes priority, followed by <em>role</em> permissions, and lastly <em>faction</em> permissions. Permissions in a given chunk for a given player can be tested by standing in the chunk and running <code>/f label test <player></code>.
			[[File:FactionLabelTest.png\|thumb\|Output from running <code>/f label test</code> to evaluate permissions of a player for a given chunk.]]

	A permission can be given one of 3 values—<em>allow</em>, <em>deny</em>, and <em>default</em>. If a permission is set to <em>default</em>, the label is effectively ignored and the next label is evaluated. If a label with a non-default value (i.e., <em>allow</em> or <em>deny</em>) is not found, then default (i.e., hardcoded) role permission are used as fallback, and apply only to members of the faction.		A permission can be given one of 3 values—<em>allow</em>, <em>deny</em>, and <em>default</em>. If a permission is set to <em>default</em>, the label is effectively ignored and the next label is evaluated. If a label with a non-default value (i.e., <em>allow</em> or <em>deny</em>) is not found, then default (i.e., hardcoded) role permission are used as fallback, and apply only to members of the faction.
Line 46:		Line 47:
	\| column widths=,,7em		\| column widths=,,7em
	}}</div>		}}</div>

	~~Permissions in a given chunk for a given player can be tested by standing in the chunk and running <code>/f label test <player></code>.~~
	~~[[File:FactionLabelTest.png\|thumb\|Output from running <code>/f label test</code> to evaluate permissions of a player for a given chunk.]]~~

	==Base==		==Base==

Muqsit: /* Permission labels */

2025-03-18T01:31:03Z

Permission labels

← Older revision		Revision as of 01:31, 18 March 2025
Line 46:		Line 46:
	\| column widths=,,7em		\| column widths=,,7em
	}}</div>		}}</div>

			Permissions in a given chunk for a given player can be tested by standing in the chunk and running <code>/f label test <player></code>.
			[[File:FactionLabelTest.png\|thumb\|Output from running <code>/f label test</code> to evaluate permissions of a player for a given chunk.]]

	==Base==		==Base==

Muqsit: /* Permission labels */

2025-03-17T20:00:04Z

Permission labels

← Older revision		Revision as of 20:00, 17 March 2025
Line 39:		Line 39:
	<div class="va-top">{{#cargo_query:		<div class="va-top">{{#cargo_query:
	tables=FactionLabel		tables=FactionLabel
	\| fields=name=~~Name~~,description=Description,roles=Default Roles		\| fields=name=Permission,description=Description,roles=Default Roles
	\| format=dynamic table		\| format=dynamic table
	\| default=No permissions found.		\| default=No permissions found.