CODE/OOC/IC Caste Mechanic Bug:

Slave players don't have a standardized, defined path to release their characters from slavery, creating potential for an open loop.

Denizens/Citizens/Master and Mistress players are capable of changing class (mostly) at-will every three months.
The Master/Mistress promotion is dependent on
------------------
Expected function:

Experienced players, or players that started in a different caste, should be able to escape slavery without the required assistance from other players. Additionally, players choosing to start a slave character but are unfamiliar with the game should have a mechanism in place to start the three-month wait period to Denizen on the same day as chargen.

--------------------
Further explanation:


>Clarifications:
1. Currently, slave players must find an ICly and OOCly amenable second party to purchase, hold, and then free their characters after three months in order to achieve Denizen.

We don't want to change this.


2. This can generate a situation where the player is unable to find an amenable second party, or the slave-owning player becomes unavailable to release the slave character through no fault of the slave player's own.
	Result:
		1. The slave player must then repeat this process from the beginning in order to advance their characters.

ICly, the situation of a character being shuffled between owners makes perfect sense and is thematically true to the nature of the world.

We don't want to change this, and should encourage demotions from Denizen, Citizen, and Master/Mistress to Slave in order to allow all players to play each caste without OOC interruption to their narrative.

OOCly, it can generate a situation where slave players must contact +staff to resolve this issue.
We want to reduce instances of player/staff interaction and increase the amount of available
IC resources 	to resolve that situation.



3. This can create a situation where the slave-owning player quits, and forces the slave player to make IC choices based on OOC influences, rather than the slave character's natural progression.
	Result:
	a. Player deletes and then re-creates character as Denizen (OOC interruption of IC narrative)
	b. Player is thematically forced into Hydra (OOC interruption of IC narrative)
	c. Player has slave character roaming the grid (out of theme)
	d. Player gets bored of grid and sandboxes (out of theme)
		*This isn't confined to slave players. <-Does this issue account for some of that?


4. While there are some routes in game that are based on a collective pool of other players for advancement (Example: The Academy of Sensual Arts), there are none staffed by characters which can be removed and replaced for inactivity except by group majority, and all have arbitrary rules and time periods for achievement that are not in line with the minimum wait time.

We need to ensure that the players wishing to change class are doing so for legitimate IC purposes,
and not because of an arbitrary or transitory reason, otherwise this is pointless. <-What mechanics can we
introduce to gate this behavior and redirect players to active groups of players?


>OOC Restrictions
0. We must include players that chargen slave characters.
	1. We must exclude players that are not slaves.
Code:
&dat.applicant.name calculator=[lit(%#)]
&dat.applicant.class calculator=[u(%#/class)]
&fun.classcheck calculator=[if([strmatch([u(dat.applicant.class)],Slave)]

This is so that we can prevent non-slaves from applying.
We want to store as much information as possible so that we know how to reference it later.


1. We can't outlaw or triviliaze slavery.
	a. An ideal solution will reinforce the current theme.
		*Require 3/5 Ducal approval
				We can do this with 1
				a. But this introduces abuse
		*Require Overseer or Preceptor approval of initial packet
			1. *Include designated representatives to act on behalf in the event of absence
		*Provide enough oversight to ensure guidance of players to their goal
		*Automate the application process for Day 0 characters
	b. An ideal solution will give players a rewarding experience and encourage them to continue playing
		1. and will encourage players to share that experience with others. <-We can't force this, only incentivize.
	c. An ideal solution encourages and rewards players to play as each caste and creates a mechanism by which to achieve that
		1. and encourages the use of that experience to drive further roleplay
2. We can't change any +laws. <- Adressed in IC Restrictions
	a. We can add to existing +laws.
		1. An ideal solution creates accountability and responsibility
			a. and sets examples for other players in lower leadership positions
			b. and encourages players to share positive experiences with others.
	b. An ideal solution is bound to, by, or cited as a restricted exclusion from +laws.
3. We can't change any code
	a. But we can introduce new code or use existing systems
		1. and should minimize +staff involvement where possible.
4. We can't add new +groups.
	a. but we can repurpose existing bboards.
5. We can't add new +buildings.
	a. but we can repurpose existing buildings.
6. We must adhere to $cash
	1. but include a mechanism to ignore it
	2. and track the use of $cash to prevent OOC abuse.


>IC Restrictions
0. The Principality does not engage in the practice of Imminent Domain
	a. and we can't free slaves
		1. But we can award titles and monetary benefits
1. We can't force demotion once players are Citizens
	a. But we can prevent advancement to Master/Mistress
		*Prevents abuse

>Staff Restrictions
1. Proposed +laws should
	a. Be beneficial to the game <- This is an arbitrary requirement and needs to be further defined
		1. And create positive RP opportunities. <- This is an arbitrary requirement and needs to be further defined
	b. Fill a necessary gap or inconsistency in IC environment
		1. and will justify the cost of complexity.
	c. Apply to more than one player over the course of a year.
	d. Not affect the long-term future of the game. <-This is can only be predicted and measures taken to prevent it.
		1. and prevent large groups of players from abusing the mechanic
			a. and preserve anti-slavery position.
		2. and prevent future abuse from future governments.
	e. Increase RP in Houses
		1. but not detract from them
	f. Allow for private corruption




[lt(and([u(P)],[u(c)]),[u(f)])]=1,{@pemit %#=Yes},0,{@pemit %#=No}

&cmd calculator=$+release *?:@switch [lt(and([u(P)],[u(c)]),[u(f)])]=1,{@pemit %#=Yes},0,{@pemit %#=No}
&cmd apply=$+apply:@switch [u(fun.release)]

S= slave
P= purchase price+cost of living during three-month period
c= arbitrary value of slave's current projected life earnings
	*This is either the slave character's owner's player, a member of a representative house, the player themselves, or
		1. We can include an option to allow Overseer/Ducal intervention
	*We can make this function include self-registering groups which can donate funds
		1. and use this to publicly show amenable player groupings
			*Allows for Day 0 Chargen players to contact these groups
			*Allows for the dynamic creation of like-minded groups
				a. Player-formed groups may abuse mechanic
					1.but we can limit proposed groups to Council approval.
					*Allows flexibility on the grid so that as different groups grow and wane, there is an easy mechanic which is usable by new House heads to bring on players desiring to help drive RP within the house.
					*Allows for unlimited negotiation potential by allowing different groups to fund the purchase of a slave.

f= arbitrary value of slave's projected life earnings in self-defined function
	*Player-entered, determines the duration of Denizenry
		1. We can include an option for deferred payment over time by including a function that auto-Slaves the player.

*encourages donations to fund the government/principality
*increases Hydra/Merchant caravans to find slaves of value (Negative: Artificial inflation of price - how is this resolved/is this an issue?)
*account for 3/5 ducal vote
*We need to send @mail out at the one-month mark to Overseer's office
*We can shuffle players to the Preceptor position by requiring at least one monthly meeting
*This would allow for the Preceptor to track attendance of free people