https://wiki.blognomic.com/api.php?action=feedcontributions&feedformat=atom&user=ZackBlogNomic Wiki - User contributions [en]2026-06-04T08:45:28ZUser contributionsMediaWiki 1.44.0https://wiki.blognomic.com/index.php?title=SNDT&diff=29662SNDT2025-04-06T16:16:01Z<p>Zack: Idling</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Standard Reward<br />
| 3<br />
|}<br />
<br />
{| class="wikitable sortable" style="text-align:center"<br />
|-<br />
! Nomicer !! Equity !! Spendables<br />
|-<br />
| ais523 || 27 ||<br />
|-<br />
| Clucky || 24 ||<br />
|-<br />
| Darknight || 20 || <br />
|-<br />
| DoomedIdeas || 22 || <br />
|-<br />
| JonathanDark || 32 || <br />
|-<br />
| Kevan || 23 || ⚪⚪⚪<br />
|-<br />
| Lulu || 22 || <br />
|-<br />
| Raven1207 || 17 || <br />
|-<br />
| SingularByte|| 29 || ⚪⚪⚪<br />
|}<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|-<br />
! Sins<br />
|-<br />
| that<br />
|-<br />
| rule<br />
|-<br />
| proposal<br />
|-<br />
| revenge<br />
|-<br />
| action<br />
|-<br />
| utility<br />
|-<br />
| revert<br />
|-<br />
| equal<br />
|-<br />
| each<br />
|-<br />
| replace<br />
|-<br />
| equity<br />
|}<br />
<br />
[[Category:Gamestate Tracking]]</div>Zackhttps://wiki.blognomic.com/index.php?title=SNDT&diff=29644SNDT2025-04-05T04:33:01Z<p>Zack: Reinitialising</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Standard Reward<br />
| 3<br />
|}<br />
<br />
{| class="wikitable sortable" style="text-align:center"<br />
|-<br />
! Nomicer !! Equity !! Spendables<br />
|-<br />
| ais523 || 33 ||<br />
|-<br />
| Clucky || 21 ||<br />
|-<br />
| Darknight || 20 || <br />
|-<br />
| DoomedIdeas || 22 || <br />
|-<br />
| JonathanDark || 32 || <br />
|-<br />
| Kevan || 23 || ⚪⚪⚪<br />
|-<br />
| Lulu || 22 || <br />
|-<br />
| Raven1207 || 17 || <br />
|-<br />
| SingularByte|| 25 || ⚪⚪⚪<br />
|-<br />
| Zack || 22 ||<br />
|}<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|-<br />
! Sins<br />
|-<br />
| that<br />
|-<br />
| rule<br />
|-<br />
| proposal<br />
|-<br />
| revenge<br />
|-<br />
| action<br />
|-<br />
| utility<br />
|-<br />
| revert<br />
|-<br />
| equal<br />
|-<br />
| each<br />
|-<br />
| replace<br />
|-<br />
| equity<br />
|}<br />
<br />
[[Category:Gamestate Tracking]]</div>Zackhttps://wiki.blognomic.com/index.php?title=SNDT&diff=29640SNDT2025-04-05T01:45:01Z<p>Zack: I unidle</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Standard Reward<br />
| 3<br />
|}<br />
<br />
{| class="wikitable sortable" style="text-align:center"<br />
|-<br />
! Nomicer !! Equity !! Spendables<br />
|-<br />
| ais523 || 33 ||<br />
|-<br />
| Clucky || 21 ||<br />
|-<br />
| Darknight || 20 || <br />
|-<br />
| DoomedIdeas || 14 || ⚪⚪<br />
|-<br />
| JonathanDark || 32 || <br />
|-<br />
| Kevan || 23 || ⚪⚪⚪<br />
|-<br />
| Raven1207 || 17 || <br />
|-<br />
| SingularByte|| 25 || ⚪⚪⚪<br />
|-<br />
| Zack || 24 ||<br />
|}<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|-<br />
! Sins<br />
|-<br />
| that<br />
|-<br />
| rule<br />
|-<br />
| proposal<br />
|-<br />
| revenge<br />
|-<br />
| action<br />
|-<br />
| utility<br />
|-<br />
| revert<br />
|-<br />
| equal<br />
|-<br />
| each<br />
|-<br />
| replace<br />
|-<br />
| equity<br />
|}<br />
<br />
[[Category:Gamestate Tracking]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Laundry_list&diff=29626Laundry list2025-04-04T02:24:15Z<p>Zack: I integrated the new version of the vote counter script into the blog</p>
<hr />
<div>This is a page for players to note possible ruleset problems which should probably be fixed at some point, because we tend to forget otherwise. It's also the place for wiki/server/other issues which need addressing, or suggestions of things which would be nice to have.<br />
<br />
==Not yet resolved==<br />
<br />
{| class="wikitable sortable"<br />
! Issue !! Scope !! Priority<br />
|-<br />
| ''"Each Believer may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon. [...] A Believer’s Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter."'' - this is a little opaque/redundant when an idle player makes a vote-icon comment before unidling. || Ruleset || Low<br />
|-<br />
| ''"A keyword defined by a rule supersedes the normal English usage of the word."'' - what exactly counts as being "defined"?<br />
<br />
Relatedly, we should define what constitutes a 'keyword' in the first place.<br />
| Ruleset<br />
| Low<br />
|-<br />
| Sometimes proposals are timestamped "incorrectly" - if a player starts writing a proposal at 3pm and finishes at 6pm, the blog software will by default give its timestamp as 3pm (and players are explicitly barred from editing the Entry Date field, under Fair Play). But the ruleset blindly refers to "the oldest pending proposal" and how long it has been "open for voting" without referring to timestamps. We should probably find some way to make timestamps the authoritative age of a proposal, or allow them to be altered to match the time of submission, but in a way which can't be exploited. || Ruleset || High<br />
|-<br />
| When a rule says that a gamestate change just happens, we're usually implying that the person who initiated the action is responsible for making that change too - should probably codify that somewhere. || Ruleset || Low<br />
|-<br />
| LocalSettings.php for the wiki should be updated to number section headings by default. (Requires server access, <code>$wgDefaultUserOptions['numberheadings'] = 1;</code>.) Not ruleset critical as the numbers are still visible in the table of contents. || Server || Low<br />
|-<br />
| The rules for "must" and "should" imperatives could use an overhaul: see [[Imperative Rework]]. || Ruleset || Low<br />
|-<br />
| Add some (preferably mandatory) way of identifying users whose wiki account and EE account usernames are unrecognizable from each other. || Ruleset || Low<br />
|-<br />
| The "Players" core rule (which we rename each dynasty) should probably literally just be called "Players", otherwise it's easy to end up with a dynastic rule with the same title and potentially cause confusion and/or problems. (An [https://blognomic.com/archive/merely_players_core_special_case_appendix attempted fix in September 2020] reached quorum but was withdrawn for a technical issue.) || Ruleset || Low<br />
|-<br />
| What should happen when an atomic action is modified by a proposal, midway through somebody taking it? (This can easily happen if someone neglects to perform one step correctly, and somebody points it out hours later.) || Ruleset || ?<br />
|-<br />
| The concept of a "valid vote" is a bit erratically written. (Does ''"A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST."'' say that FOR and AGAINST are the only valid votes, or that any vote which is valid has to become one of those two? Why talk of "a valid Vote other than VETO" if the former?) || Ruleset || Low<br />
|-<br />
| This possibly got set aside in anticipation of [[The Second Switch]], but it'd be good if CfJs could be multiple choice, instead of always being "this specific fix or nothing happens". || Ruleset || Low<br />
|-<br />
| "If the Admin enacting a Proposal reaches a step which cannot be applied immediately" doesn't cover CfJs (yet they are implicitly covered by the "shall update the Gamestate and Ruleset" CfJ enactment process) || Ruleset || High<br />
|-<br />
| Rule, Proposal and Wiki page titles are classified as Flavour Text, which have no meaning, and are just strings of characters. But we still refer to them all the time by their titles. It's somewhat ambiguous whether we can do so, and whether using quotation marks ("") helps. || Ruleset || ?<br />
|-<br />
| What happens if we have two players with the exact same username? (Admins are, I think, prevented from creating new accounts with duplicate names, but it's possible for someone to sign up, change their ''display'' name, then request to join the game under that name. Also possible for a player to change their name by proposal, if nobody realises that the name is already in use.) || Ruleset || Medium<br />
|-<br />
| The glossary definition of "Core Proposal" is at odds with that of a Core-tagged proposal; it pre-dates it by at least six years. We could probably live without defining it, as it doesn't seem to have been used much (if ever). || Ruleset || Low<br />
|-<br />
| ''"If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers"'' regularly trips up non-mathematicians (and inattentive mathematicians) when a variable is casually defined as an integer, and then bugged or scammed to a surprisingly negative value. This was [https://blognomic.com/archive/zero_as_a_limit_appendix discussed but not fixed] in April 2023. || Ruleset || High<br />
|-<br />
| The Building Blocks might benefit from some flavour text to explain what situations they're for and how to use them - and whether they're considered to be fully functional out of the box, or works in progress that are still being tested. || Ruleset || Low<br />
|-<br />
| Unidling players get their "personal gamestate" back: that's clear for stats like "each player has a number of coins", but doesn't cover things like "one player is the mayor" or "each property is owned by a player" (in cases where the dynastic rules don't otherwise say how to handle that). [https://blognomic.com/archive/no_ghosts Some] [https://blognomic.com/archive/no_man_has_blinded_me_appendix proposals] were made to address this in 2022, but neither was enacted. || Ruleset || Low<br />
|-<br />
| Would be useful to have [https://www.mediawiki.org/wiki/Extension:ParserFunctions/String_functions String functions] available in ParserFunctions, to allow more complex - but human readable - gamestate templates. <code>$wgPFEnableStringFunctions = true;</code> in the LocalSettings.php. || Server || Low<br />
|-<br />
| Have a single "dynastic config" blog template somewhere which includes all the settings admins are likely to change and update (name of current dynasty, Emperor name, basic colour scheme, hiatus status, etc), which other templates can then read from. Not sure whether straight PHP would work there (setting $dynastyName in the config and using it in the index template, etc). At a minimum, moving the dynastic CSS to its own separate file would probably be a good idea. || Blog || Low<br />
|-<br />
| Change https://wiki.blognomic.com/images/blognomiclogo.png (the image used in the wiki sidebar, currently the name BlogNomic slightly angled over grey ruleset text) to be a 135x135 pixel version of the modern BlogNomic logo at [[:File:Favicon.png]]. || Server || Low<br />
|-<br />
| The ''"A person with administrative, moderation, or other heightened access to the software"'' item in Fair Play probably wasn't intended to apply to in-game Admins doing in-game Admin things, so should be reworded to avoid the implication that it does. || Ruleset || Low<br />
|-<br />
| It's currently against the rules for an idle player to edit an in-use wiki template (even if it's a change that doesn't visibly affect anything on screen in the current dynasty). The existing "may change the layout or design of a gamestate wiki page" clause should maybe extend to idle players. || Ruleset || Low<br />
|-<br />
| We should probably have a built-in rule that allows [[FAQ#Why_has_my_.22sticky.22_post_disappeared.3F|expired sticky posts]] to have their date refreshed, while respecting the original timestamp. || Ruleset || Low<br />
|-<br />
| Allow secrets to be tracked on the server, similar to the Dice Roller.<br />
* Idea 1: Input into the form is the secret (any string), output that is logged per user and timestamp is the SHA256 hash.<br />
* Idea 2: A less elegant version could be done with passwords - when you enter a message you also give it a password, and each message would have an “enter password to irrevocably reveal this message” form next to it. (And a player could just use the same browser-saved or easy-to-recall password for all of their messages.)<br />
| Server<br />
| Low<br />
|-<br />
| Install a MediaWiki extension like [https://www.mediawiki.org/wiki/Extension:Description2 Description2] or [https://www.mediawiki.org/wiki/Extension:OpenGraphMeta OpenGraphMeta] to allow metadata preview tags to be used by offsite links. || Server || Low<br />
|-<br />
| When [https://blognomic.com/archive/core_anyone_can_help_with_the_chores a July 2024 core change] was enacted, the copy and paste of its text overlooked the wikilink to the [[Imperial Styles]] page, and reduced it to plain unlinked text. This was upheld when the dynasty ended. The link should be restored. || Ruleset || Low<br />
|}<br />
<br />
==Fixed==<br />
<br />
{| class="wikitable sortable"<br />
! Issue !! Action<br />
|-<br />
| Idle players may still count as players for the purposes of proposals, as argued [http://blognomic.com/archive/automatic_for_the_people/ here]. (Rule 1.2.1 only excepts rules, not proposals.) || [http://blognomic.com/archive/out_of_mind/ Fixed]<br />
|-<br />
| What happens if we vote through a proposal that says "two days after this proposal passes, Player X gains 1 point" (or more dramatically, "two years after this proposal passes, Player X may declare victory in whatever dynasty is being played at that time")? Is such an "invisible rule" legal? || [http://blognomic.com/archive/a_distant_boomerang Fixed]<br />
|-<br />
| Dynasty #110 [http://blognomic.com/archive/no_silent_idles/ changed] admin idling so that if they fail to announce the idling, it's illegal. Given that not every admin rereads the core rules when unidling, this risks leaving dangerously quorum-changing ghosts if an admin idles themselves out without posting the required paperwork comment. || Update: [http://blognomic.com/archive/this_was_thought_up_earlier/ it is now a 'should' clause]<br />
|-<br />
| "When a DoV is failed, if it has a number of AGAINST Votes that exceed Quorum, the Apprentice who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was failed." - but DoVs can be failed when they reach a number of AGAINST votes that ''equal'' quorum. This should probably just lose the comma'd clause entirely.<br />
|-<br />
| "Random" decisions are required to be "taken from a uniform probability distribution over the entire range of possible values", but there's only an implicit requirement that the GNDT be used for this. Apart from secret Imperial rolls, it'd help to make the GNDT compulsory here.<br />
|-<br />
| "a wiki page shall be blanked when it becomes gamestate" ([http://blognomic.com/archive/fixes2/ enacted eluctantly in June 2013] as part of a wider fix) risks blanking the entire BlogNomic wiki if we accidentally do something to make all of it gamestate. || [http://blognomic.com/archive/greyer_than_white/ Fixed]<br />
|-<br />
| ''"If a game variable has no defined starting value for new Shuttles, or for existing Shuttles upon the variable’s creation, then that starting value is zero (for numerical variables) or blank (for a text string or list)."'' - what if zero or blank are illegal values?<br />
|-<br />
| ''“When the Mayor has a valid Vote other than VETO on a Proposal, then all votes of DEFERENTIAL are instead considered to be valid and the same as the Mayor’s Vote…”'' - this should have an "on that Proposal" in there. || [http://blognomic.com/archive/deferential_rain#comments fixed]<br />
|-<br />
| "If you make a GNDT dice roll, do you have to use it?" - if there's a rule of "a player may roll DICE4 once a week to gain that many victory points", can I roll DICE4 a few times in succession and use the last one for the action, explaining that the others were just for fun? || Addressed in Fair Play<br />
|-<br />
| "Invisible end numbers due to scientific notation in the GNDT"<br />
|-<br />
| "Can they interrupt those steps with other game actions?" || Fixed, they can as long as it's not an atomic action.<br />
|-<br />
| Re-implement Dormancy. It got emergency-removed in Axemabaro I, but it hasn't been returned yet. || It's back.<br />
|-<br />
| "Defaulting" could use further definition, when we say something like "players have Food, defaulting to 10". It's covered in the Idle Players rule, but nowhere else.<br />
<br />
(For anyone who doesn't know, this is Agora terminology (Rule 2126b) that people started using at BlogNomic out of Agoran habit, even though it wasn't defined over here; the default value gets set when the piece of gamestate is created, or if it would otherwise fail to have a determinate value (e.g. after being changed infinitely often in finite time). It probably works the way that people expect it to work even here, though.)<br />
| Under simple English, "default" with respect to computer terminology means a value used in absence of a choice made by a user. Since blognomic is computer based it stands to reason that this is the definition being used. Check a reputable online dictionary, it could be anywhere from the third to fifteenth definition for "default".<br />
|-<br />
| The ruleset doesn't explain dice very clearly, it just says ''"The DICEN command can be used"'' without explaining how to do that. || The new dice roller script displays its own documentation.<br />
|-<br />
| The ruleset doesn't give defaults to referring to a proposal name. If a proposal includes a reference to a proposal just by its name and without a link, some odd interactions can occur if another proposal with the same name appears later in the queue. || fixed [https://blognomic.com/archive/whats_in_a_name2 here]<br />
|-<br />
| The special case rule names of "No Collaboration" and "Alliances" seem to be giving some players the impression that in a No Collaboration dynasty with Alliances off, ''players are not allowed to have allies or exchange favours''. Clearer titles of "No Private Communication" and "Public Alliances" may make it clearer what these rules are actually doing.<br />
|-<br />
| If a player "must" perform a series of steps in sequence, is there an acceptable delay between steps? || Fair play now says a player may not "deliberately and unreasonably prolong" an action<br />
|-<br />
| Might be a good idea to change the "Older Core Game Documents" section of the front page to a more easily readable Category (by putting <nowiki>[[Category:Gamestate document]]</nowiki> or something at the end of all of the individual pages, and new ones as we create them). || This was done.<br />
|-<br />
| Incomplete atomic actions are an invisible tripwire: we moved away from having them time out because this was exploitable (if you make a bad roll in step 2, abandon the action and wait for it to time out), but invisibly trapping people in "cannot take dynastic actions" (even if they idle and come back) isn't great either. || Solved with a mix of timeouts and fair play "deliberately and unreasonably prolong"?<br />
|-<br />
| Mantle Limitations now being active by default in most dynasties suggests we should write that the other way around: remove all mention of it from Victory and Ascension, and have a Rare Special Case rule that ''allows'' the mantle to be passed if the Emperor wants to switch it on. || [https://blognomic.com/archive/mantle_shelf_core_building_blocks Done]<br />
|-<br />
| That a proposal's "stated effects are immediately applied in full" means that it's possible for proposals to do things beyond amending the gamestate and ruleset. (Prior to 2021 a proposal was enacted "by updating the Ruleset and/or Gamestate to include the specified effects".) We should probably go back to admins being able to ignore clauses which are outside the scope of the game like that. || This text no longer exists<br />
|-<br />
| The Ascension atomic shouldn't end on "Optionally specify their Imperial Style"; if an Emperor chooses to skip that without explicitly ''saying'' that they've skipped it, players can't be sure that the atomic is complete. Really the atomic should be restructured to reflect expectation: that the Emperor posts an AA blog entry saying what's changing and the ruleset is updated to match it (so that other players can step in under "completing incomplete actions on behalf of the original Player" if the Emperor fails to do so). || This was all changed.<br />
|-<br />
| As currently structured, the Dormancy rule counts idle players (being exempted by the previous rule), so can never be triggered. || [https://blognomic.com/archive/requeuesant Fixed]<br />
| The appendix rule about what variables default to should also say that simple true/false states default to being false. || [https://blognomic.com/archive/appendix_false_until_proven_true Fixed]<br />
|-<br />
| All Recusant Proposals are also Precondition Unidlings, and would cause their proposers to unidle. Precondition Unidlings should probably just become CfJs to avoid that ambiguity; would also mean that they could be made during Dormancy Hiatus, and would run at a queue-ignoring speed closer to a regular unidling. || [https://blognomic.com/archive/your_call_is_very_important_to_us_building_blocks Fixed]<br />
|-<br />
| Embed the vote-counting script into the actual blog, if that's possible. || [https://blognomic.com/archive/vote_counter_live_on_the_blog Done]<br />
|}</div>Zackhttps://wiki.blognomic.com/index.php?title=SNDT&diff=29461SNDT2025-03-29T02:36:46Z<p>Zack: Enacting Stepping in to assist</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Nomicer !! Equity<br />
|-<br />
| ais523 || 5<br />
|-<br />
| Darknight || 5<br />
|-<br />
| DoomedIdeas || 5<br />
|-<br />
| JonathanDark || 5<br />
|-<br />
| Josh || 5<br />
|-<br />
| Kevan || 5<br />
|-<br />
| Raven1207 || 5<br />
|-<br />
| SingularByte|| 5<br />
|}</div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=29460Ruleset2025-03-29T02:33:45Z<p>Zack: /* Dynastic Rules */ Enacting Stepping in to assist</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Nomicers shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Nomicer may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[Life Goal Progress]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Nomicers ==<br />
A human with access to the blog who is not already a Nomicer may make a blog post making clear their wish to be a Nomicer (plural form Nomicers); in response, an Admin shall add them to the roster in the sidebar, at which moment they become a Nomicer. (See the FAQ for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
Some Nomicers are Admins, responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Nomicers who wish to become Admins should submit a Proposal or CfJ to that effect. Existing Admins may be voluntarily resignation by making a post to the blog.<br />
<br />
A Nomicer may cease to be a Nomicer at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be a Nomicer in this way may not become a Nomicer again within the following two weeks.<br />
<br />
===Idle Nomicers ===<br />
A Nomicer may be either Active or Idle. A Nomicer is only Active if their name is on the list of currently active Nomicers in the Sidebar; otherwise they are Idle.<br />
<br />
A Nomicer may request to become Idle at any time by making a post or comment to that effect. An Admin may render a Nomicer Idle if that Nomicer has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Nomicer has not posted an entry or comment in the past 168 Hours (7 days). Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so.<br />
<br />
For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Nomicers”, “Dynasties”, “Fair Play”, “Imperial Tracking”, “Mentors” and any of those Rules’ subrules, Idle Nomicers are not counted as Nomicers. The combined term “Idle Nomicers” can be used to refer to Nomicers who are Idle even in Proposals or rules that do not treat them as Nomicers, and any votable matter that specifically refers to a named Idle Nomicer can affect them as if they were Active. Idle admins may act as Admins as if they were Active.<br />
<br />
An Admin may make a Nomicer Active if that Nomicer is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may make themselves Active at any time, unless the Nomicer who would become Active has become Idle within the past 96 hours (4 days), and within the current Dynasty. Admins who are making any Nomicer Active should highlight the changed status of the relevant Nomicer and any changes to Quorum to have come about as a result of it as a comment to the entry requesting the change, or as part of their next vote comment if making themselves Active.<br />
<br />
When a Nomicer is made Active, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Nomicer Idled in a different Dynasty), the Nomicer is given the default value for new Nomicers, if such a value exists.<br />
<br />
When a Nomicer becomes idle due to inactivity, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Nomicer during the current and subsequent dynasty.<br />
<br />
===Dormancy===<br />
If there are fewer than four Active Nomicers (not including the Imperator), then BlogNomic is on Hiatus.<br />
<br />
===Recusants===<br />
An Idle Nomicer may post or vote on a Votable Matter provided that its effect is entirely limited to amending the non-dynastic ruleset. An Idle Nomicer who makes or votes upon such a Votable Matter is, for the purposes of that Votable Matter, a Recusant. When resolving a Votable Matter, all Idle Nomicers who are Recusants on that matter are considered to be Active solely for the purposes of determining whether it was legally posted, and for determining Quorum on that matter; and all otherwise valid votes cast by Recusants are considered to be valid votes cast by Active Nomicers.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Nomicer, known as the Imperator. If there is no Imperator, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before a Dynastic Reset has been performed. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Nomicer may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out. Additionally, Proposals may be submitted and resolved as normal, provided that they only have the effect of amending the non-dynastic ruleset.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Imperator is not a Nomicer.<br />
<br />
Each Dynasty is tracked by a number. The current Dynasty Number is 234.<br />
<br />
The following Nomicer is the Imperator: "Josh".<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Nomicers may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Nomicer may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. A Nomicer‘s Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Nomicer never has a Vote, even if they were a Nomicer previously and had cast a valid Vote.<br />
<br />
If a Nomicer other than the Imperator casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Imperator. When the Imperator has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Imperator’s Vote for the purposes of other rules unless otherwise specified. When the Imperator themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Nomicers who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Nomicer may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Nomicer already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When a Nomicer casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Imperator may use VETO as a voting icon to cast a Vote on a Proposal; when the Imperator casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Imperator later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Nomicer A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Nomicers actively disagree as to the interpretation of the Ruleset, or if a Nomicer feels that an aspect of the game needs urgent attention, then any Nomicer may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It does not specify changes to the gamestate nor ruleset, does not specify that any attempt to perform an action should be upheld or rejected, and does not specify corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If a Nomicer (other than the Imperator) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
A Nomicer’s vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Nomicer may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Nomicers, it has been open for at least 12 hours, and either the Imperator has Voted FOR it or it has no AGAINST Votes.<br />
* It has been open for at least 24 hours and it has a number of FOR Votes that exceed or equal Quorum.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Nomicer who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Nomicer who posted the DoV becomes Imperator, and the game enters an Interregnum. The player who Enacted it updates the rule “Dynasties” as specified in “Imperial Tracking”. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Imperator must make an Ascension Address by posting an entry in the “Ascension Address” category. The Ascension Address may be altered by its author if it is less than 4 hours old and the Dynastic Reset action has not yet been performed since the initial posting of that Ascension Address. The Ascension Address should specify the Imperator’s chosen theme for the new Dynasty, and it may optionally specifiy one or more of the following:<br />
* New dynasty-specific terms as outline in the rule “Synonyms”<br />
* A number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed)<br />
* Any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section<br />
* The name of the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”<br />
* The Imperator’s Imperial Style, which if specified is a set of nonbinding guidelines that the Imperator is encouraged to follow, using the terms defined on the wiki page Imperial Styles.<br />
<br />
If it has not been done since the most recent posting of an Ascension Address, the Imperator or any Nomicer (if it’s the latter, they must wait until at least 4 hours after that Ascension Address has been posted) may perform a Dynastic Reset, which is an atomic action with the following steps:<br />
* Create a wiki page called “Ruleset X” where X is the current Dynasty Number (replacing its contents if it already exists)<br />
* Increase the current Dynasty Number by 1<br />
* Update the Ruleset to reflect any changed terms as outlined in the most recent Ascension Address.<br />
* Repeal any dynastic rules which were not listed to be kept in the most recent Ascension Address.<br />
* Update the gamestate tracking page referred to in the rule “Ruleset and Gamestate” with the name specified in the most recent Ascension Address, if any. If no name is specified, set the gamestate tracking page to be “Gamestate Tracking X” where X is the current dynasty number<br />
* Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Make any specified or automatic changes to the Building Blocks section of the ruleset as described in the most recent Ascension Address.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if a Nomicer’s behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Nomicers should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Nomicer within BlogNomic, and should announce publicly if they control both a non-Idle Nomicer and any Idle Nomicers. This extends to exerting full control over the actions of another Nomicer, defined here as the controlled Nomicer’s game behavior being functionally indistinguishable from if the controlling Nomicer was logged into their account and playing through it, over a period of more than a day.<br />
* A Nomicer should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* A Nomicer should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* A Nomicer should not edit their own blog comments once posted, nor those of any other Nomicer.<br />
* A Nomicer should not edit the “Entry Date” field of a blog post, except as permitted by the rule Date and Time Tracking in the Appendix.<br />
* A Nomicer should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* A Nomicer should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* A Nomicer should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. a Nomicer must use their own name in the Dice Roller, when rolling dice.<br />
* A Nomicer should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* A Nomicer should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause a Nomicer to achieve victory.<br />
* A Nomicer should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic, nor trade actions or favours in one Dynasty of Blognomic for actions or favours in another Dynasty of Blognomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Nomicer or Nomicers to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Nomicers and idle Nomicers should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Nomicers are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
== Equity ==<br />
Each Nomicer has a publicly-tracked score called Equity. Each Nomicer also has a derived statistic called Liability, which is the sum of all Equity held by Nomicers other than themselves, and which is not tracked but is calculated when needed. The median amount of Equity in the game, rounded down, is called the Float.<br />
<br />
A Nomicer’s Equity can have any integer value between -10 and twice their Liability, inclusive. The default starting Equity for a new Nomicer is their Libaility, divided by the number of Nomicers including themselves, rounded up to the nearest integer.<br />
<br />
No other publicly tracked dynastic variables held by individual Nomicers may be proposed in this dynasty.<br />
<br />
== Announcements of Attainment ==<br />
At any time, provided that they have an Equity that is at least 5 times greater than the Float, any Nomicer may make a post with a title that starts with “Announcement of Attainment” in the story post category. When a Nomicer has made such a post in this way, the game is placed into a state of Lacuna, in which the only dynastic actions that can be taken are Lacunaic Actions.<br />
<br />
When the game has been in Lacuna for 48 consecutive hours, as a Lacunaic Action, any Nomicer or the Imperator may perform the Roll Off atomic action, which has the following steps:<br />
* Make a post summarising the Equity held by each Nomicer. Include in the post description or table that plainly maps how the result of a dice roll will select a single Nomicer, such that each Nomicer has a chance of being selected equal to their Equity as a proportion of all Equity in the game.<br />
* Make the dice roll as described in the post made in the first step of this action;<br />
* Make a comment to that post announcing the Nomicer selected by the dice roll as determined by the heuristic described in the post. The Nomicer so selected has Achieved Victory.<br />
<br />
As a Weekly Communal Action, any Nomicer or the Imperator may reduce the numeral between the words “least” and “times” in the first sentence of this rule by one.<br />
<br />
== Actions ==<br />
=== Mill ===<br />
As a Daily Action, but no more than three times a week, a Nomicer may reduce the Equity of another Nomicer by 1; if they do so they may then immediately increase their own Equity by 1.<br />
<br />
=== Golden Rule ===<br />
Whenever a proposal is resolved the Nomicer who posted it gains 2 Equity, unless the Imperator’s EVC on that proposal contained the word ‘trash’, in which case the proposer loses 2 Equity. This Equity gain does not occur for proposals that were withdrawn with an arrow AGAINST icon (this does not prevent an Equity loss occurring).<br />
<br />
== Lacunaic Actions ==<br />
=== Heightened Mill ===<br />
As a Daily Action, but no more than three times in the dynasty, a Nomicer may reduce the Equity of another Nomicer other than the Nomicer who posted the Announcement of Attainment by 2; if they do so they may then immediately increase their own Equity by 2.<br />
<br />
== Bounties ==<br />
The Bounty Payout action for all Bounties is to increase the Equity of the Nomicer to whom it is applied by 2.<br />
<br />
== Wording Fixes ==<br />
This dynasty, the voting icons https://blognomic.com/images/vote/against.gif (the “cross” AGAINST icon) and https://blognomic.com/images/vote/arrow.gif (the “arrow” AGAINST icon) are both considered to be AGAINST voting icons. Nomicers are encouraged to use a cross AGAINST icon when voting against a proposal due to disagreement with the general idea behind the proposal; and to use an arrow AGAINST icon when voting against a proposal for which they agree with the general idea behind the proposal, but disagree with the details or with the exact wording.<br />
<br />
If a proposal’s author withdraws it using an arrow AGAINST icon, and there were at least as many arrow AGAINST icons as cross AGAINST icons among the other (non-author) Nomicers’ Votes on that proposal at the time, then the proposal ceases to count against that author’s limit of 2 pending proposals and can be failed by any Admin, even if it is not the oldest pending proposal. The author should submit a corrected version. (If a proposal’s author is planning to withdraw a proposal, but not to submit a corrected version, they should withdraw it using a cross rather than arrow AGAINST icon.) Proposal authors are encouraged to wait at least 8 hours before withdrawing them and submitting a corrected version, in case more mistakes that need correction are discovered (although this is not a requirement).<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page’s contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Imperator specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset. When a Dynastic Reset is performed, the Building Blocks rules selected in the most recent Ascension Address (if any) must be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named in that Ascension Address must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Imperator makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected.<br />
<br />
==Bounties==<br />
A Bounty Notice is a post in the Story Posts - Votable Matter category which broadly requests a single mechanical or ruleset change. Despite its category, it is not a votable matter and any votes on it are ignored. A Bounty Notice may be Open or Closed being Open by default and being Closed when set to the ‘Enacted’ or ‘Failed’ status in the post backend. The Enacted Status should be used for successfully completed Bounty Notices, while Failed should be used for ones that were closed for any other reason<br />
<br />
The Imperator may post a Bounty Notice, or close an open Bounty Notice, at any time.<br />
<br />
If a Bounty Payout action is not defined in the dynastic rules, then the Bounty Payout action is that nothing happens.<br />
<br />
If the Imperator believes that one or more enacted votable matters satisfy the demand of an open Bounty Notice, then they may apply the Bounty Payout action to each Nomicer (other than the Imperator) who authored at least one of those votable matters and set that Bounty Notice to closed. <br />
<br />
==Reinitialisation==<br />
If they have not already done so in the current dynasty, a Nomicer may make a post to the blog announcing that they are Reinitialising; if they do so then they must immediately set all of their gamestate tracked values to their defaults for new players, and if the Imperator is privately tracking any information about them then they should do likewise at their first opportunity. If a Nomicer has Reinitialised during the current dynasty, then, for the purposes of determining the validity of limited actions, they are considered to have undertaken no actions in this dynasty prior to their most recent Reinitialisation. <br />
<br />
==Precondition Unidling==<br />
Idle Nomicers may submit Proposals as if they were not idle; such proposals are known as Precondition Proposals, and should suggest terms (in the form of amendments to the ruleset and/or gamestate) on which the proposer would be willing to join the current dynasty. The proposer of a Precondition Proposal is not considered to have a vote on that Proposal while they remain idle.<br />
<br />
If a Precondition Proposal enacts, the enacting admin must unidle its proposer before applying the proposal’s effects. As an exception, this requirement does not apply where such an unidling would be impossible.<br />
<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Nomicer able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Nomicer per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Nomicer able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Nomicer per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Nomicers.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined only in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Dynastic Variable: A gamestate variable that exists only due to a dynastic rule and is not mentioned in a non-dynastic rule. (In particular, the identity of the Imperator is not a dynastic variable.)<br />
;Effective Vote Comment (EVC): A Nomicer's Effective Vote Comment with respect to a given Votable Matter is that Nomicer's Comment to that Votable Matter, if any, that contains that Nomicer's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, a Nomicer may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Nomicers , as well as people who are not Nomicers but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Nomicers who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Nomicers are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the rules and Building Blocks explicitly mention (except for the FAQ, the dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Nomicers is half the number of Nomicers in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Nomicers it is referring to, it is referring to a Quorum of all Nomicers.<br />
;Reject: To reject an attempt to take an action is to retroactively declare the attempt to have been unsuccessful, and to declare that all attempted game actions taken after that attempt were attempted as though the rejected attempt had been unsuccessful. An attempt to take an action can be rejected even if it were originally legal. The opposite of rejecting an attempt to take an action is upholding it.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Revert: To Revert an action or change is both to fully reverse the effects of that change having occurred, and also to consider that change to have not occurred at all. To Revert a document or piece of tracked gamestate to a specific prior state means to return that item to that state, considering the actions that may have changed it since the time of that state to have not occurred. Reverting the gamestate to a specific state does not imply upholding that state.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Imperator.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Nomicers” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To uphold an attempt to take an action is to retroactively declare the attempt to have been successful, and to declare that all attempted game actions taken after that attempt were attempted as though the upheld attempt had been successful. An attempt to take an action can be upheld even if it were originally illegal (in which case the retroactive change is made by pretending, for the purpose of calculating the results of that change, that the action was legal). The opposite of upholding an attempt to take an action is rejecting it.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Nomicer may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may only be altered by its author as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no voting icons in any of its comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Imperator to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Imperator may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
====Date and Time Tracking====<br />
<br />
A Nomicer may amend the Entry Date field of an Official Post that they have authored, or the Imperator may amend the Entry Date field of any Official Post, only under the following conditions and only in the following ways:<br />
<br />
* If the Official Post has been made visible on the blog within the preceding 15 minutes, but it has a timestamp that is greater than one hour old, then the Entry Date field may be amended to reflect the actual time of posting to within 15 minutes, in which case the revised time is considered to be the time at which it was posted;<br />
* If an Official Post is older than 7 days but needs to remain Sticky on the front page of the Blog then its Entry Date may be edited to the time of the edit, to within a minute, with the original date and time at which it was posted added to the Commentary or flavour text field of that post, in which case the original time of posting remains the time at which it was posted.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of a Nomicer’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Nomicer may correct the representations to comply with the Gamestate.<br />
<br />
If a Nomicer feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Nomicer, if doing so would not require the correcting Nomicer to make any decisions on behalf of the original Nomicer.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Nomicers are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
A Nomicer may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
===Imperial Tracking===<br />
<br />
The identity of the current dynasty’s Imperator is tracked in the last sentence of the Core Rule “Dynasties”. Whenever a Nomicer becomes the Imperator, that sentence changes to “The following Nomicer is the Imperator: ” followed by that Nomicer’s name in quotes. Whenever a Metadynasty starts, that sentence changes to “There is no Imperator this Dynasty.”.<br />
<br />
All names after the colon in the last sentence of “Dynasties” are considered to be references to Nomicers, and are flavour text for all purposes other than referencing Nomicers. If the Imperator changes their name by proposal, the sentence in question is updated to reflect the new name of the Imperator.<br />
<br />
The identity of the Imperator is considered to be a gamestate variable that belongs to the game of BlogNomic as a whole, rather than belonging to the Imperator personally.<br />
<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name a Nomicer with such access. Only a Nomicer with such access may Enact that Votable Matter. If that Votable Matter does not name a Nomicer with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Nomicer making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Nomicer making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When a Nomicer performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete or 72 hours have passed.<br />
* If a rule allows the Nomicer performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If a Nomicer arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Nomicer must redo the Atomic Action; for that purpose, the Nomicer uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Nomicer would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, a Nomicer can spend or pay from only their own values, and a rule that allows Nomicers to transfer or pay a numeric value to another Nomicer only allows them to transfer that value from themselves to that other Nomicer (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* A Nomicer who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Nomicers are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Imperator (including secretly random selections), then that information may only be revealed by the Imperator when the ruleset allows it. If a Nomicer should already know such a piece of information (in that the Imperator has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Imperator may repeat it to them.<br />
* A range of numerical values stated to be “between” one value and another value is treated as an inclusive range unless otherwise explicitly stated.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Nomicer may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Nomicers may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Imperator has voted DEFERENTIAL on a Proposal, they are not considered to be a Nomicer for the purposes of totaling quorum on that Proposal. Votes of DEFERENTIAL made by other Nomicers on the same Proposal are not considered to be valid, but the Nomicers who made them still contribute to quorum<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* A Nomicer may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Nomicers may correct obvious spelling, punctuation, typographical, and/or formatting mistakes in the Ruleset, the Building Blocks page, and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Nomicers with the corresponding forms of the singular ‘they’.<br />
* A Nomicer may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
* A Nomicer may change the layout or design of a gamestate wiki page if doing so would not change how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of a Nomicer if it is explicitly stated that it refers to a Nomicer's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, a Nomicer's (or prospective Nomicer's ) new name must be between 3 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes. A Nomicer’s name may only be changed as a result of a Proposal approving the change.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Nomicers may Kick each other” and “Nomicers may not Kick each other on Tuesdays” exist, and it is Tuesday, Nomicers may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Nomicers may Punch a Spaceman on Friday” and “Nomicers may not Punch Spacemen on Friday”, then Nomicers may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
A Nomicer may have another Nomicer as a Mentor. Nomicers who are willing to act as a Mentor, and who meet the criteria set out in the Tenured Players section of the aftermentioned page, are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of a Nomicer who has requested a change on their own behalf, or may remove the name of any Tenured Player who no longer meets the criteria set out in the Tenured Players section of the Mentorships page, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Nomicer requests a Mentor, or a new Nomicer has joined the game and has no Mentor, the Imperator should select a Tenured Nomicer and ask them to take that Nomicer on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Imperator should announce it in a blog post. The Imperator should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. A Nomicer may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Imperator, any Nomicer who has been active in at least three previous dynasties may act as Imperator for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Nomicer or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Nomicers .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Nomicer” and “Imperator”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Nomicer (Player)<br />
* Imperator (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=29459Ruleset2025-03-29T02:03:33Z<p>Zack: /* Dynastic Rules */ Enacting Instead of Edits</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Nomicers shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Nomicer may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[Life Goal Progress]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Nomicers ==<br />
A human with access to the blog who is not already a Nomicer may make a blog post making clear their wish to be a Nomicer (plural form Nomicers); in response, an Admin shall add them to the roster in the sidebar, at which moment they become a Nomicer. (See the FAQ for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
Some Nomicers are Admins, responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Nomicers who wish to become Admins should submit a Proposal or CfJ to that effect. Existing Admins may be voluntarily resignation by making a post to the blog.<br />
<br />
A Nomicer may cease to be a Nomicer at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be a Nomicer in this way may not become a Nomicer again within the following two weeks.<br />
<br />
===Idle Nomicers ===<br />
A Nomicer may be either Active or Idle. A Nomicer is only Active if their name is on the list of currently active Nomicers in the Sidebar; otherwise they are Idle.<br />
<br />
A Nomicer may request to become Idle at any time by making a post or comment to that effect. An Admin may render a Nomicer Idle if that Nomicer has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Nomicer has not posted an entry or comment in the past 168 Hours (7 days). Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so.<br />
<br />
For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Nomicers”, “Dynasties”, “Fair Play”, “Imperial Tracking”, “Mentors” and any of those Rules’ subrules, Idle Nomicers are not counted as Nomicers. The combined term “Idle Nomicers” can be used to refer to Nomicers who are Idle even in Proposals or rules that do not treat them as Nomicers, and any votable matter that specifically refers to a named Idle Nomicer can affect them as if they were Active. Idle admins may act as Admins as if they were Active.<br />
<br />
An Admin may make a Nomicer Active if that Nomicer is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may make themselves Active at any time, unless the Nomicer who would become Active has become Idle within the past 96 hours (4 days), and within the current Dynasty. Admins who are making any Nomicer Active should highlight the changed status of the relevant Nomicer and any changes to Quorum to have come about as a result of it as a comment to the entry requesting the change, or as part of their next vote comment if making themselves Active.<br />
<br />
When a Nomicer is made Active, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Nomicer Idled in a different Dynasty), the Nomicer is given the default value for new Nomicers, if such a value exists.<br />
<br />
When a Nomicer becomes idle due to inactivity, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Nomicer during the current and subsequent dynasty.<br />
<br />
===Dormancy===<br />
If there are fewer than four Active Nomicers (not including the Imperator), then BlogNomic is on Hiatus.<br />
<br />
===Recusants===<br />
An Idle Nomicer may post or vote on a Votable Matter provided that its effect is entirely limited to amending the non-dynastic ruleset. An Idle Nomicer who makes or votes upon such a Votable Matter is, for the purposes of that Votable Matter, a Recusant. When resolving a Votable Matter, all Idle Nomicers who are Recusants on that matter are considered to be Active solely for the purposes of determining whether it was legally posted, and for determining Quorum on that matter; and all otherwise valid votes cast by Recusants are considered to be valid votes cast by Active Nomicers.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Nomicer, known as the Imperator. If there is no Imperator, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before a Dynastic Reset has been performed. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Nomicer may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out. Additionally, Proposals may be submitted and resolved as normal, provided that they only have the effect of amending the non-dynastic ruleset.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Imperator is not a Nomicer.<br />
<br />
Each Dynasty is tracked by a number. The current Dynasty Number is 234.<br />
<br />
The following Nomicer is the Imperator: "Josh".<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Nomicers may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Nomicer may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. A Nomicer‘s Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Nomicer never has a Vote, even if they were a Nomicer previously and had cast a valid Vote.<br />
<br />
If a Nomicer other than the Imperator casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Imperator. When the Imperator has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Imperator’s Vote for the purposes of other rules unless otherwise specified. When the Imperator themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Nomicers who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Nomicer may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Nomicer already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When a Nomicer casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Imperator may use VETO as a voting icon to cast a Vote on a Proposal; when the Imperator casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Imperator later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Nomicer A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Nomicers actively disagree as to the interpretation of the Ruleset, or if a Nomicer feels that an aspect of the game needs urgent attention, then any Nomicer may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It does not specify changes to the gamestate nor ruleset, does not specify that any attempt to perform an action should be upheld or rejected, and does not specify corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If a Nomicer (other than the Imperator) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
A Nomicer’s vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Nomicer may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Nomicers, it has been open for at least 12 hours, and either the Imperator has Voted FOR it or it has no AGAINST Votes.<br />
* It has been open for at least 24 hours and it has a number of FOR Votes that exceed or equal Quorum.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Nomicer who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Nomicer who posted the DoV becomes Imperator, and the game enters an Interregnum. The player who Enacted it updates the rule “Dynasties” as specified in “Imperial Tracking”. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Imperator must make an Ascension Address by posting an entry in the “Ascension Address” category. The Ascension Address may be altered by its author if it is less than 4 hours old and the Dynastic Reset action has not yet been performed since the initial posting of that Ascension Address. The Ascension Address should specify the Imperator’s chosen theme for the new Dynasty, and it may optionally specifiy one or more of the following:<br />
* New dynasty-specific terms as outline in the rule “Synonyms”<br />
* A number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed)<br />
* Any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section<br />
* The name of the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”<br />
* The Imperator’s Imperial Style, which if specified is a set of nonbinding guidelines that the Imperator is encouraged to follow, using the terms defined on the wiki page Imperial Styles.<br />
<br />
If it has not been done since the most recent posting of an Ascension Address, the Imperator or any Nomicer (if it’s the latter, they must wait until at least 4 hours after that Ascension Address has been posted) may perform a Dynastic Reset, which is an atomic action with the following steps:<br />
* Create a wiki page called “Ruleset X” where X is the current Dynasty Number (replacing its contents if it already exists)<br />
* Increase the current Dynasty Number by 1<br />
* Update the Ruleset to reflect any changed terms as outlined in the most recent Ascension Address.<br />
* Repeal any dynastic rules which were not listed to be kept in the most recent Ascension Address.<br />
* Update the gamestate tracking page referred to in the rule “Ruleset and Gamestate” with the name specified in the most recent Ascension Address, if any. If no name is specified, set the gamestate tracking page to be “Gamestate Tracking X” where X is the current dynasty number<br />
* Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Make any specified or automatic changes to the Building Blocks section of the ruleset as described in the most recent Ascension Address.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if a Nomicer’s behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Nomicers should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Nomicer within BlogNomic, and should announce publicly if they control both a non-Idle Nomicer and any Idle Nomicers. This extends to exerting full control over the actions of another Nomicer, defined here as the controlled Nomicer’s game behavior being functionally indistinguishable from if the controlling Nomicer was logged into their account and playing through it, over a period of more than a day.<br />
* A Nomicer should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* A Nomicer should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* A Nomicer should not edit their own blog comments once posted, nor those of any other Nomicer.<br />
* A Nomicer should not edit the “Entry Date” field of a blog post, except as permitted by the rule Date and Time Tracking in the Appendix.<br />
* A Nomicer should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* A Nomicer should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* A Nomicer should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. a Nomicer must use their own name in the Dice Roller, when rolling dice.<br />
* A Nomicer should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* A Nomicer should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause a Nomicer to achieve victory.<br />
* A Nomicer should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic, nor trade actions or favours in one Dynasty of Blognomic for actions or favours in another Dynasty of Blognomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Nomicer or Nomicers to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Nomicers and idle Nomicers should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Nomicers are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
== Actions ==<br />
=== Mill ===<br />
As a Daily Action, but no more than three times a week, a Nomicer may reduce the Equity of another Nomicer by 1; if they do so they may then immediately increase their own Equity by 1.<br />
<br />
=== Golden Rule ===<br />
Whenever a proposal is resolved the Nomicer who posted it gains 2 Equity, unless the Imperator’s EVC on that proposal contained the word ‘trash’, in which case the proposer loses 2 Equity. This Equity gain does not occur for proposals that were withdrawn with an arrow AGAINST icon (this does not prevent an Equity loss occurring).<br />
<br />
== Lacunaic Actions ==<br />
=== Heightened Mill ===<br />
As a Daily Action, but no more than three times in the dynasty, a Nomicer may reduce the Equity of another Nomicer other than the Nomicer who posted the Announcement of Attainment by 2; if they do so they may then immediately increase their own Equity by 2.<br />
<br />
== Bounties ==<br />
The Bounty Payout action for all Bounties is to increase the Equity of the Nomicer to whom it is applied by 2.<br />
<br />
== Wording Fixes ==<br />
This dynasty, the voting icons https://blognomic.com/images/vote/against.gif (the “cross” AGAINST icon) and https://blognomic.com/images/vote/arrow.gif (the “arrow” AGAINST icon) are both considered to be AGAINST voting icons. Nomicers are encouraged to use a cross AGAINST icon when voting against a proposal due to disagreement with the general idea behind the proposal; and to use an arrow AGAINST icon when voting against a proposal for which they agree with the general idea behind the proposal, but disagree with the details or with the exact wording.<br />
<br />
If a proposal’s author withdraws it using an arrow AGAINST icon, and there were at least as many arrow AGAINST icons as cross AGAINST icons among the other (non-author) Nomicers’ Votes on that proposal at the time, then the proposal ceases to count against that author’s limit of 2 pending proposals and can be failed by any Admin, even if it is not the oldest pending proposal. The author should submit a corrected version. (If a proposal’s author is planning to withdraw a proposal, but not to submit a corrected version, they should withdraw it using a cross rather than arrow AGAINST icon.) Proposal authors are encouraged to wait at least 8 hours before withdrawing them and submitting a corrected version, in case more mistakes that need correction are discovered (although this is not a requirement).<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page’s contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Imperator specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset. When a Dynastic Reset is performed, the Building Blocks rules selected in the most recent Ascension Address (if any) must be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named in that Ascension Address must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Imperator makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected.<br />
<br />
==Bounties==<br />
A Bounty Notice is a post in the Story Posts - Votable Matter category which broadly requests a single mechanical or ruleset change. Despite its category, it is not a votable matter and any votes on it are ignored. A Bounty Notice may be Open or Closed being Open by default and being Closed when set to the ‘Enacted’ or ‘Failed’ status in the post backend. The Enacted Status should be used for successfully completed Bounty Notices, while Failed should be used for ones that were closed for any other reason<br />
<br />
The Imperator may post a Bounty Notice, or close an open Bounty Notice, at any time.<br />
<br />
If a Bounty Payout action is not defined in the dynastic rules, then the Bounty Payout action is that nothing happens.<br />
<br />
If the Imperator believes that one or more enacted votable matters satisfy the demand of an open Bounty Notice, then they may apply the Bounty Payout action to each Nomicer (other than the Imperator) who authored at least one of those votable matters and set that Bounty Notice to closed. <br />
<br />
==Reinitialisation==<br />
If they have not already done so in the current dynasty, a Nomicer may make a post to the blog announcing that they are Reinitialising; if they do so then they must immediately set all of their gamestate tracked values to their defaults for new players, and if the Imperator is privately tracking any information about them then they should do likewise at their first opportunity. If a Nomicer has Reinitialised during the current dynasty, then, for the purposes of determining the validity of limited actions, they are considered to have undertaken no actions in this dynasty prior to their most recent Reinitialisation. <br />
<br />
==Precondition Unidling==<br />
Idle Nomicers may submit Proposals as if they were not idle; such proposals are known as Precondition Proposals, and should suggest terms (in the form of amendments to the ruleset and/or gamestate) on which the proposer would be willing to join the current dynasty. The proposer of a Precondition Proposal is not considered to have a vote on that Proposal while they remain idle.<br />
<br />
If a Precondition Proposal enacts, the enacting admin must unidle its proposer before applying the proposal’s effects. As an exception, this requirement does not apply where such an unidling would be impossible.<br />
<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Nomicer able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Nomicer per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Nomicer able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Nomicer per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Nomicers.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined only in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Dynastic Variable: A gamestate variable that exists only due to a dynastic rule and is not mentioned in a non-dynastic rule. (In particular, the identity of the Imperator is not a dynastic variable.)<br />
;Effective Vote Comment (EVC): A Nomicer's Effective Vote Comment with respect to a given Votable Matter is that Nomicer's Comment to that Votable Matter, if any, that contains that Nomicer's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, a Nomicer may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Nomicers , as well as people who are not Nomicers but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Nomicers who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Nomicers are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the rules and Building Blocks explicitly mention (except for the FAQ, the dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Nomicers is half the number of Nomicers in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Nomicers it is referring to, it is referring to a Quorum of all Nomicers.<br />
;Reject: To reject an attempt to take an action is to retroactively declare the attempt to have been unsuccessful, and to declare that all attempted game actions taken after that attempt were attempted as though the rejected attempt had been unsuccessful. An attempt to take an action can be rejected even if it were originally legal. The opposite of rejecting an attempt to take an action is upholding it.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Revert: To Revert an action or change is both to fully reverse the effects of that change having occurred, and also to consider that change to have not occurred at all. To Revert a document or piece of tracked gamestate to a specific prior state means to return that item to that state, considering the actions that may have changed it since the time of that state to have not occurred. Reverting the gamestate to a specific state does not imply upholding that state.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Imperator.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Nomicers” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To uphold an attempt to take an action is to retroactively declare the attempt to have been successful, and to declare that all attempted game actions taken after that attempt were attempted as though the upheld attempt had been successful. An attempt to take an action can be upheld even if it were originally illegal (in which case the retroactive change is made by pretending, for the purpose of calculating the results of that change, that the action was legal). The opposite of upholding an attempt to take an action is rejecting it.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Nomicer may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may only be altered by its author as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no voting icons in any of its comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Imperator to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Imperator may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
====Date and Time Tracking====<br />
<br />
A Nomicer may amend the Entry Date field of an Official Post that they have authored, or the Imperator may amend the Entry Date field of any Official Post, only under the following conditions and only in the following ways:<br />
<br />
* If the Official Post has been made visible on the blog within the preceding 15 minutes, but it has a timestamp that is greater than one hour old, then the Entry Date field may be amended to reflect the actual time of posting to within 15 minutes, in which case the revised time is considered to be the time at which it was posted;<br />
* If an Official Post is older than 7 days but needs to remain Sticky on the front page of the Blog then its Entry Date may be edited to the time of the edit, to within a minute, with the original date and time at which it was posted added to the Commentary or flavour text field of that post, in which case the original time of posting remains the time at which it was posted.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of a Nomicer’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Nomicer may correct the representations to comply with the Gamestate.<br />
<br />
If a Nomicer feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Nomicer, if doing so would not require the correcting Nomicer to make any decisions on behalf of the original Nomicer.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Nomicers are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
A Nomicer may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
===Imperial Tracking===<br />
<br />
The identity of the current dynasty’s Imperator is tracked in the last sentence of the Core Rule “Dynasties”. Whenever a Nomicer becomes the Imperator, that sentence changes to “The following Nomicer is the Imperator: ” followed by that Nomicer’s name in quotes. Whenever a Metadynasty starts, that sentence changes to “There is no Imperator this Dynasty.”.<br />
<br />
All names after the colon in the last sentence of “Dynasties” are considered to be references to Nomicers, and are flavour text for all purposes other than referencing Nomicers. If the Imperator changes their name by proposal, the sentence in question is updated to reflect the new name of the Imperator.<br />
<br />
The identity of the Imperator is considered to be a gamestate variable that belongs to the game of BlogNomic as a whole, rather than belonging to the Imperator personally.<br />
<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name a Nomicer with such access. Only a Nomicer with such access may Enact that Votable Matter. If that Votable Matter does not name a Nomicer with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Nomicer making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Nomicer making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When a Nomicer performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete or 72 hours have passed.<br />
* If a rule allows the Nomicer performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If a Nomicer arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Nomicer must redo the Atomic Action; for that purpose, the Nomicer uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Nomicer would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, a Nomicer can spend or pay from only their own values, and a rule that allows Nomicers to transfer or pay a numeric value to another Nomicer only allows them to transfer that value from themselves to that other Nomicer (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* A Nomicer who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Nomicers are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Imperator (including secretly random selections), then that information may only be revealed by the Imperator when the ruleset allows it. If a Nomicer should already know such a piece of information (in that the Imperator has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Imperator may repeat it to them.<br />
* A range of numerical values stated to be “between” one value and another value is treated as an inclusive range unless otherwise explicitly stated.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Nomicer may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Nomicers may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Imperator has voted DEFERENTIAL on a Proposal, they are not considered to be a Nomicer for the purposes of totaling quorum on that Proposal. Votes of DEFERENTIAL made by other Nomicers on the same Proposal are not considered to be valid, but the Nomicers who made them still contribute to quorum<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* A Nomicer may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Nomicers may correct obvious spelling, punctuation, typographical, and/or formatting mistakes in the Ruleset, the Building Blocks page, and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Nomicers with the corresponding forms of the singular ‘they’.<br />
* A Nomicer may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
* A Nomicer may change the layout or design of a gamestate wiki page if doing so would not change how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of a Nomicer if it is explicitly stated that it refers to a Nomicer's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, a Nomicer's (or prospective Nomicer's ) new name must be between 3 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes. A Nomicer’s name may only be changed as a result of a Proposal approving the change.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Nomicers may Kick each other” and “Nomicers may not Kick each other on Tuesdays” exist, and it is Tuesday, Nomicers may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Nomicers may Punch a Spaceman on Friday” and “Nomicers may not Punch Spacemen on Friday”, then Nomicers may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
A Nomicer may have another Nomicer as a Mentor. Nomicers who are willing to act as a Mentor, and who meet the criteria set out in the Tenured Players section of the aftermentioned page, are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of a Nomicer who has requested a change on their own behalf, or may remove the name of any Tenured Player who no longer meets the criteria set out in the Tenured Players section of the Mentorships page, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Nomicer requests a Mentor, or a new Nomicer has joined the game and has no Mentor, the Imperator should select a Tenured Nomicer and ask them to take that Nomicer on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Imperator should announce it in a blog post. The Imperator should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. A Nomicer may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Imperator, any Nomicer who has been active in at least three previous dynasties may act as Imperator for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Nomicer or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Nomicers .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Nomicer” and “Imperator”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Nomicer (Player)<br />
* Imperator (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=29458Ruleset2025-03-29T01:58:30Z<p>Zack: /* Dynastic Rules */ Enacting First Steps</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Nomicers shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Nomicer may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[Life Goal Progress]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Nomicers ==<br />
A human with access to the blog who is not already a Nomicer may make a blog post making clear their wish to be a Nomicer (plural form Nomicers); in response, an Admin shall add them to the roster in the sidebar, at which moment they become a Nomicer. (See the FAQ for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
Some Nomicers are Admins, responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Nomicers who wish to become Admins should submit a Proposal or CfJ to that effect. Existing Admins may be voluntarily resignation by making a post to the blog.<br />
<br />
A Nomicer may cease to be a Nomicer at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be a Nomicer in this way may not become a Nomicer again within the following two weeks.<br />
<br />
===Idle Nomicers ===<br />
A Nomicer may be either Active or Idle. A Nomicer is only Active if their name is on the list of currently active Nomicers in the Sidebar; otherwise they are Idle.<br />
<br />
A Nomicer may request to become Idle at any time by making a post or comment to that effect. An Admin may render a Nomicer Idle if that Nomicer has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Nomicer has not posted an entry or comment in the past 168 Hours (7 days). Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so.<br />
<br />
For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Nomicers”, “Dynasties”, “Fair Play”, “Imperial Tracking”, “Mentors” and any of those Rules’ subrules, Idle Nomicers are not counted as Nomicers. The combined term “Idle Nomicers” can be used to refer to Nomicers who are Idle even in Proposals or rules that do not treat them as Nomicers, and any votable matter that specifically refers to a named Idle Nomicer can affect them as if they were Active. Idle admins may act as Admins as if they were Active.<br />
<br />
An Admin may make a Nomicer Active if that Nomicer is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may make themselves Active at any time, unless the Nomicer who would become Active has become Idle within the past 96 hours (4 days), and within the current Dynasty. Admins who are making any Nomicer Active should highlight the changed status of the relevant Nomicer and any changes to Quorum to have come about as a result of it as a comment to the entry requesting the change, or as part of their next vote comment if making themselves Active.<br />
<br />
When a Nomicer is made Active, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Nomicer Idled in a different Dynasty), the Nomicer is given the default value for new Nomicers, if such a value exists.<br />
<br />
When a Nomicer becomes idle due to inactivity, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Nomicer during the current and subsequent dynasty.<br />
<br />
===Dormancy===<br />
If there are fewer than four Active Nomicers (not including the Imperator), then BlogNomic is on Hiatus.<br />
<br />
===Recusants===<br />
An Idle Nomicer may post or vote on a Votable Matter provided that its effect is entirely limited to amending the non-dynastic ruleset. An Idle Nomicer who makes or votes upon such a Votable Matter is, for the purposes of that Votable Matter, a Recusant. When resolving a Votable Matter, all Idle Nomicers who are Recusants on that matter are considered to be Active solely for the purposes of determining whether it was legally posted, and for determining Quorum on that matter; and all otherwise valid votes cast by Recusants are considered to be valid votes cast by Active Nomicers.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Nomicer, known as the Imperator. If there is no Imperator, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before a Dynastic Reset has been performed. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Nomicer may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out. Additionally, Proposals may be submitted and resolved as normal, provided that they only have the effect of amending the non-dynastic ruleset.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Imperator is not a Nomicer.<br />
<br />
Each Dynasty is tracked by a number. The current Dynasty Number is 234.<br />
<br />
The following Nomicer is the Imperator: "Josh".<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Nomicers may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Nomicer may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. A Nomicer‘s Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Nomicer never has a Vote, even if they were a Nomicer previously and had cast a valid Vote.<br />
<br />
If a Nomicer other than the Imperator casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Imperator. When the Imperator has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Imperator’s Vote for the purposes of other rules unless otherwise specified. When the Imperator themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Nomicers who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Nomicer may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Nomicer already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When a Nomicer casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Imperator may use VETO as a voting icon to cast a Vote on a Proposal; when the Imperator casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Imperator later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Nomicer A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Nomicers actively disagree as to the interpretation of the Ruleset, or if a Nomicer feels that an aspect of the game needs urgent attention, then any Nomicer may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It does not specify changes to the gamestate nor ruleset, does not specify that any attempt to perform an action should be upheld or rejected, and does not specify corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If a Nomicer (other than the Imperator) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
A Nomicer’s vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Nomicer may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Nomicers, it has been open for at least 12 hours, and either the Imperator has Voted FOR it or it has no AGAINST Votes.<br />
* It has been open for at least 24 hours and it has a number of FOR Votes that exceed or equal Quorum.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Nomicer who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Nomicer who posted the DoV becomes Imperator, and the game enters an Interregnum. The player who Enacted it updates the rule “Dynasties” as specified in “Imperial Tracking”. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Imperator must make an Ascension Address by posting an entry in the “Ascension Address” category. The Ascension Address may be altered by its author if it is less than 4 hours old and the Dynastic Reset action has not yet been performed since the initial posting of that Ascension Address. The Ascension Address should specify the Imperator’s chosen theme for the new Dynasty, and it may optionally specifiy one or more of the following:<br />
* New dynasty-specific terms as outline in the rule “Synonyms”<br />
* A number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed)<br />
* Any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section<br />
* The name of the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”<br />
* The Imperator’s Imperial Style, which if specified is a set of nonbinding guidelines that the Imperator is encouraged to follow, using the terms defined on the wiki page Imperial Styles.<br />
<br />
If it has not been done since the most recent posting of an Ascension Address, the Imperator or any Nomicer (if it’s the latter, they must wait until at least 4 hours after that Ascension Address has been posted) may perform a Dynastic Reset, which is an atomic action with the following steps:<br />
* Create a wiki page called “Ruleset X” where X is the current Dynasty Number (replacing its contents if it already exists)<br />
* Increase the current Dynasty Number by 1<br />
* Update the Ruleset to reflect any changed terms as outlined in the most recent Ascension Address.<br />
* Repeal any dynastic rules which were not listed to be kept in the most recent Ascension Address.<br />
* Update the gamestate tracking page referred to in the rule “Ruleset and Gamestate” with the name specified in the most recent Ascension Address, if any. If no name is specified, set the gamestate tracking page to be “Gamestate Tracking X” where X is the current dynasty number<br />
* Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Make any specified or automatic changes to the Building Blocks section of the ruleset as described in the most recent Ascension Address.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if a Nomicer’s behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Nomicers should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Nomicer within BlogNomic, and should announce publicly if they control both a non-Idle Nomicer and any Idle Nomicers. This extends to exerting full control over the actions of another Nomicer, defined here as the controlled Nomicer’s game behavior being functionally indistinguishable from if the controlling Nomicer was logged into their account and playing through it, over a period of more than a day.<br />
* A Nomicer should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* A Nomicer should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* A Nomicer should not edit their own blog comments once posted, nor those of any other Nomicer.<br />
* A Nomicer should not edit the “Entry Date” field of a blog post, except as permitted by the rule Date and Time Tracking in the Appendix.<br />
* A Nomicer should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* A Nomicer should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* A Nomicer should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. a Nomicer must use their own name in the Dice Roller, when rolling dice.<br />
* A Nomicer should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* A Nomicer should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause a Nomicer to achieve victory.<br />
* A Nomicer should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic, nor trade actions or favours in one Dynasty of Blognomic for actions or favours in another Dynasty of Blognomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Nomicer or Nomicers to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Nomicers and idle Nomicers should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Nomicers are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
== Actions ==<br />
=== Mill ===<br />
As a Daily Action, but no more than three times a week, a Nomicer may reduce the Equity of another Nomicer by 1; if they do so they may then immediately increase their own Equity by 1.<br />
<br />
=== Golden Rule ===<br />
Whenever a proposal is resolved the Nomicer who posted it gains 2 Equity, unless the Imperator’s EVC on that proposal contained the word ‘trash’, in which case the proposer loses 2 Equity.<br />
<br />
== Lacunaic Actions ==<br />
=== Heightened Mill ===<br />
As a Daily Action, but no more than three times in the dynasty, a Nomicer may reduce the Equity of another Nomicer other than the Nomicer who posted the Announcement of Attainment by 2; if they do so they may then immediately increase their own Equity by 2.<br />
<br />
== Bounties ==<br />
The Bounty Payout action for all Bounties is to increase the Equity of the Nomicer to whom it is applied by 2.<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page’s contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Imperator specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset. When a Dynastic Reset is performed, the Building Blocks rules selected in the most recent Ascension Address (if any) must be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named in that Ascension Address must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Imperator makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected.<br />
<br />
==Bounties==<br />
A Bounty Notice is a post in the Story Posts - Votable Matter category which broadly requests a single mechanical or ruleset change. Despite its category, it is not a votable matter and any votes on it are ignored. A Bounty Notice may be Open or Closed being Open by default and being Closed when set to the ‘Enacted’ or ‘Failed’ status in the post backend. The Enacted Status should be used for successfully completed Bounty Notices, while Failed should be used for ones that were closed for any other reason<br />
<br />
The Imperator may post a Bounty Notice, or close an open Bounty Notice, at any time.<br />
<br />
If a Bounty Payout action is not defined in the dynastic rules, then the Bounty Payout action is that nothing happens.<br />
<br />
If the Imperator believes that one or more enacted votable matters satisfy the demand of an open Bounty Notice, then they may apply the Bounty Payout action to each Nomicer (other than the Imperator) who authored at least one of those votable matters and set that Bounty Notice to closed. <br />
<br />
==Reinitialisation==<br />
If they have not already done so in the current dynasty, a Nomicer may make a post to the blog announcing that they are Reinitialising; if they do so then they must immediately set all of their gamestate tracked values to their defaults for new players, and if the Imperator is privately tracking any information about them then they should do likewise at their first opportunity. If a Nomicer has Reinitialised during the current dynasty, then, for the purposes of determining the validity of limited actions, they are considered to have undertaken no actions in this dynasty prior to their most recent Reinitialisation. <br />
<br />
==Precondition Unidling==<br />
Idle Nomicers may submit Proposals as if they were not idle; such proposals are known as Precondition Proposals, and should suggest terms (in the form of amendments to the ruleset and/or gamestate) on which the proposer would be willing to join the current dynasty. The proposer of a Precondition Proposal is not considered to have a vote on that Proposal while they remain idle.<br />
<br />
If a Precondition Proposal enacts, the enacting admin must unidle its proposer before applying the proposal’s effects. As an exception, this requirement does not apply where such an unidling would be impossible.<br />
<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Nomicer able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Nomicer per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Nomicer able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Nomicer per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Nomicers.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined only in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Dynastic Variable: A gamestate variable that exists only due to a dynastic rule and is not mentioned in a non-dynastic rule. (In particular, the identity of the Imperator is not a dynastic variable.)<br />
;Effective Vote Comment (EVC): A Nomicer's Effective Vote Comment with respect to a given Votable Matter is that Nomicer's Comment to that Votable Matter, if any, that contains that Nomicer's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, a Nomicer may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Nomicers , as well as people who are not Nomicers but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Nomicers who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Nomicers are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the rules and Building Blocks explicitly mention (except for the FAQ, the dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Nomicers is half the number of Nomicers in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Nomicers it is referring to, it is referring to a Quorum of all Nomicers.<br />
;Reject: To reject an attempt to take an action is to retroactively declare the attempt to have been unsuccessful, and to declare that all attempted game actions taken after that attempt were attempted as though the rejected attempt had been unsuccessful. An attempt to take an action can be rejected even if it were originally legal. The opposite of rejecting an attempt to take an action is upholding it.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Revert: To Revert an action or change is both to fully reverse the effects of that change having occurred, and also to consider that change to have not occurred at all. To Revert a document or piece of tracked gamestate to a specific prior state means to return that item to that state, considering the actions that may have changed it since the time of that state to have not occurred. Reverting the gamestate to a specific state does not imply upholding that state.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Imperator.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Nomicers” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To uphold an attempt to take an action is to retroactively declare the attempt to have been successful, and to declare that all attempted game actions taken after that attempt were attempted as though the upheld attempt had been successful. An attempt to take an action can be upheld even if it were originally illegal (in which case the retroactive change is made by pretending, for the purpose of calculating the results of that change, that the action was legal). The opposite of upholding an attempt to take an action is rejecting it.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Nomicer may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may only be altered by its author as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no voting icons in any of its comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Imperator to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Imperator may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
====Date and Time Tracking====<br />
<br />
A Nomicer may amend the Entry Date field of an Official Post that they have authored, or the Imperator may amend the Entry Date field of any Official Post, only under the following conditions and only in the following ways:<br />
<br />
* If the Official Post has been made visible on the blog within the preceding 15 minutes, but it has a timestamp that is greater than one hour old, then the Entry Date field may be amended to reflect the actual time of posting to within 15 minutes, in which case the revised time is considered to be the time at which it was posted;<br />
* If an Official Post is older than 7 days but needs to remain Sticky on the front page of the Blog then its Entry Date may be edited to the time of the edit, to within a minute, with the original date and time at which it was posted added to the Commentary or flavour text field of that post, in which case the original time of posting remains the time at which it was posted.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of a Nomicer’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Nomicer may correct the representations to comply with the Gamestate.<br />
<br />
If a Nomicer feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Nomicer, if doing so would not require the correcting Nomicer to make any decisions on behalf of the original Nomicer.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Nomicers are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
A Nomicer may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
===Imperial Tracking===<br />
<br />
The identity of the current dynasty’s Imperator is tracked in the last sentence of the Core Rule “Dynasties”. Whenever a Nomicer becomes the Imperator, that sentence changes to “The following Nomicer is the Imperator: ” followed by that Nomicer’s name in quotes. Whenever a Metadynasty starts, that sentence changes to “There is no Imperator this Dynasty.”.<br />
<br />
All names after the colon in the last sentence of “Dynasties” are considered to be references to Nomicers, and are flavour text for all purposes other than referencing Nomicers. If the Imperator changes their name by proposal, the sentence in question is updated to reflect the new name of the Imperator.<br />
<br />
The identity of the Imperator is considered to be a gamestate variable that belongs to the game of BlogNomic as a whole, rather than belonging to the Imperator personally.<br />
<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name a Nomicer with such access. Only a Nomicer with such access may Enact that Votable Matter. If that Votable Matter does not name a Nomicer with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Nomicer making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Nomicer making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When a Nomicer performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete or 72 hours have passed.<br />
* If a rule allows the Nomicer performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If a Nomicer arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Nomicer must redo the Atomic Action; for that purpose, the Nomicer uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Nomicer would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, a Nomicer can spend or pay from only their own values, and a rule that allows Nomicers to transfer or pay a numeric value to another Nomicer only allows them to transfer that value from themselves to that other Nomicer (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* A Nomicer who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Nomicers are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Imperator (including secretly random selections), then that information may only be revealed by the Imperator when the ruleset allows it. If a Nomicer should already know such a piece of information (in that the Imperator has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Imperator may repeat it to them.<br />
* A range of numerical values stated to be “between” one value and another value is treated as an inclusive range unless otherwise explicitly stated.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Nomicer may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Nomicers may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Imperator has voted DEFERENTIAL on a Proposal, they are not considered to be a Nomicer for the purposes of totaling quorum on that Proposal. Votes of DEFERENTIAL made by other Nomicers on the same Proposal are not considered to be valid, but the Nomicers who made them still contribute to quorum<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* A Nomicer may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Nomicers may correct obvious spelling, punctuation, typographical, and/or formatting mistakes in the Ruleset, the Building Blocks page, and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Nomicers with the corresponding forms of the singular ‘they’.<br />
* A Nomicer may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
* A Nomicer may change the layout or design of a gamestate wiki page if doing so would not change how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of a Nomicer if it is explicitly stated that it refers to a Nomicer's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, a Nomicer's (or prospective Nomicer's ) new name must be between 3 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes. A Nomicer’s name may only be changed as a result of a Proposal approving the change.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Nomicers may Kick each other” and “Nomicers may not Kick each other on Tuesdays” exist, and it is Tuesday, Nomicers may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Nomicers may Punch a Spaceman on Friday” and “Nomicers may not Punch Spacemen on Friday”, then Nomicers may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
A Nomicer may have another Nomicer as a Mentor. Nomicers who are willing to act as a Mentor, and who meet the criteria set out in the Tenured Players section of the aftermentioned page, are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of a Nomicer who has requested a change on their own behalf, or may remove the name of any Tenured Player who no longer meets the criteria set out in the Tenured Players section of the Mentorships page, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Nomicer requests a Mentor, or a new Nomicer has joined the game and has no Mentor, the Imperator should select a Tenured Nomicer and ask them to take that Nomicer on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Imperator should announce it in a blog post. The Imperator should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. A Nomicer may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Imperator, any Nomicer who has been active in at least three previous dynasties may act as Imperator for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Nomicer or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Nomicers .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Nomicer” and “Imperator”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Nomicer (Player)<br />
* Imperator (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=Universe&diff=25703Universe2024-03-06T01:06:19Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The First Dynasty of Wakukee}}<br />
<br />
Earth's axis runs east to west instead of north and south. The new east and west poles are located in Padang, Indonesia (the East Pole) and Esmeraldas, Ecuador (the West Pole). The prime meridian does not exist.<br />
<br />
The following Locations contain Oracles:<br />
- Delphi, Greece<br />
- Great Sphinx of Giza<br />
- Mexico City Metropolitan Cathedral (thought to be constructed on the ruins of one of the principal Mesoamerican temples)<br />
<br />
Earth has shrunk to a single point, Funafuti (the capital of Tuvalu).</div>Zackhttps://wiki.blognomic.com/index.php?title=Quick_Reference&diff=25702Quick Reference2024-03-06T01:04:49Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The Second Dynasty of Chronos Phaenon}}<br />
<br />
{{TOCRight}}<br />
<br />
*The [[Commodities Market]]<br />
*The [[World]]<br />
*The [[Ruleset]]<br />
<br />
== Excalabur ==<br />
* Population: 993<br />
* Production Capacity ''plus Occupied territory production'':<br />
** Grain: 72 <br />
** Metal: 67 <br />
** Petroleum: 57 <br />
** Natural Beauty: 21<br />
<br />
* Territories '''Controlled''' and ''Occupied'': '''[[World#Excalabur Homeland|Excalabur Homeland]]''', '''[[World#Area 51|Area 51]]''', '''[[World#Devil's Hole|Devil's Hole]]''', '''[[World#Scotland|Scotland]]''', '''[[World#Shangri-La|Shangri-La]]''', '''[[World#Death's Valley|Death's Valley]]''', '''Castle Black''', '''Tekneek Homeland''', '''Chronos Phaenon Homeland''', '''ShadowClaw Homeland'''<br />
* Territories Disputed: None<br />
<br />
* Alliance: None<br />
* At War with: None<br />
<br />
== Gazebo Dude ==<br />
* Population: 208<br />
* Production Capacity ''minus 1 from war)'':<br />
** Grain: 4 ''-1''<br />
** Metal: 13 ''-1''<br />
** Petroleum: 14 ''-1''<br />
** Natural Beauty: -7 ''+7''<br />
<br />
* Territories '''Controlled''' and ''Occupied'': '''[[World#Gazebo Dude Homeland|Gazebo Dude Homeland]]'''<br />
* Territories Disputed: None.<br />
<br />
* Alliance: Underdog Free Trade Association (UFTA)<br />
* At War with: Purplebeard<br />
<br />
== Jamuraa ==<br />
* Population: 400<br />
* Production Capacity ''plus ocuppied terr. production'':<br />
** Grain: 26<br />
** Metal: 44<br />
** Petroleum: 19<br />
** Natural Beauty: -5<br />
<br />
* Territories '''Controlled''' and ''Occupied'': '''[[World#Jamuraa Homeland|Jamuraa Homeland]]''', '''[[World#Londinium|Londinium]]''', '''[[World#Somewhere over the Rainbow|Somewhere over the Rainbow]]''', '''[[World#Sinon|Sinon]]'''<br />
* Territories Disputed: None<br />
<br />
* Alliance: Overdog Free Trade Association (OFTA)<br />
* At War with: None<br />
<br />
== Purplebeard == <br />
* Population: 357<br />
* Production Capacity ''plus ocuppied terr. production, minus 1 because of war''<br />
** Grain: 38 ''-1''<br />
** Metal: 31 ''-1''<br />
** Petroleum: 30 ''-1''<br />
** Natural Beauty: 5 ''+11 (most of my production capacities are set to 0)''<br />
<br />
* Territories '''Controlled''' and ''Occupied'': '''[[World#Purplebeard Homeland|Purplebeard Homeland]]''', '''[[World#Bacon|Bacon]]''', '''[[World#Your mother|Your mother]]''', '''[[World#Munchkinland|Munchkinland]]''', '''[[World#Hundred Acre Woods|Hundred Acre Woods]]''', ''[[World#Botany Bay (Oceanic)|Botany Bay (Oceanic)]]'', ''[[World#Pervasive Sea (Oceanic)|Pervasive Sea (Oceanic)]]'', ''[[World#Doldrums (Oceanic)|Doldrums (Oceanic)]]'', ''[[World#Royal Hunting Ground|Royal Hunting Ground]]''<br />
* Territories Disputed: None.<br />
<br />
* Alliance: None<br />
* At War with: Underdog Free Trade Association (UFTA)<br />
<br />
== Rodney == <br />
* Population: 139<br />
* Production Capacity ''Minus one because of the war'':<br />
** Grain: 11 ''-1''<br />
** Metal: 15 ''-1''<br />
** Petroleum: 15 ''-1''<br />
** Natural Beauty: -17 ''+17''<br />
<br />
* Territories '''Controlled''' and ''Occupied'': '''[[World#Rodney Homeland|Rodney Homeland]]'''<br />
* Territories Disputed:<br />
<br />
* Alliance: Underdog Free Trade Association (UFTA)<br />
* At War with: Purplebeard<br />
<br />
== Smith ==<br />
* Population: 144<br />
* Production Capacity ''plus ocuppied terr. production, minus 1 because of the war'' <br />
** Grain: 8 ''+1'' <br />
** Metal: 9 ''+1'' <br />
** Petroleum: 4 ''+1''<br />
** Natural Beauty: 3 ''+1''<br />
<br />
* Territories '''Controlled''' and ''Occupied'': '''[[World#Smith Homeland|Smith Homeland]]''', ''[[World#Greater Erg|Greater Erg]]'','' [[World#Cul-de-Sac|Cul-de-Sac]]''<br />
* Territories Disputed: None<br />
<br />
* Alliance: Underdog Free Trade Association (UFTA)<br />
* At War with: Purplebeard<br />
<br />
== Lunaetic ==<br />
* Population: 27<br />
* Production Capacity <br />
** Grain: 4<br />
** Metal: 8<br />
** Petroleum: 14<br />
** Natural Beauty: -2<br />
<br />
* Territories '''Controlled''' and ''Occupied'': '''[[World#Lunaetic Homeland|Lunaetic Homeland]]'''<br />
*Territories Disputed: None<br />
<br />
* Alliance: None<br />
* At War with: None<br />
<br />
== Unoccupied Territories ==<br />
* [[World#Sea of Serenity (Oceanic)|Sea of Serenity (Oceanic)]]</div>Zackhttps://wiki.blognomic.com/index.php?title=QQQ&diff=25701QQQ2024-03-06T01:03:11Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The First Dynasty of arthexis}}<br />
<br />
[Hint] Guess what?<br />
<br />
This proposal is a contest. The purpose of the contest is to try and guess which of the following three statements is true:<br />
<br />
A: There is a third element to the Theme which arthexis has not mentioned (apart from cooking and racing).<br />
<br />
B: arthexis has, at some point or another during the dynasty, used the individual words that compose the theme.<br />
<br />
C: One of the hints that arthexis has given is false.<br />
<br />
With their vote to this Proposal, a Member may include a single “A”, “B” or “C” according to the statement that Member believes is true. After this proposal has passed, and within a period of time no larger than 48 hours, the Writer shall make a Story Post detailing which of the three options is the true statement. Members who included the correct answer (that is, the single letter representing the true statement) shall obtain 1 guess and 20 Credits. Only the last valid vote shall be considered when determining correctness.<br />
<br />
ANSWER: B<br />
<br />
<br />
<br />
<br />
The VW will probably not help people win. Definitely, you guys will need something faster for that.<br />
<br />
<br />
<br />
<br />
<br />
Anyways: Clarifying the hint, the word that appears in common in both guesses and that appears also on the theme is “ON”.<br />
<br />
Furthermore, other than that last typo, every other info I have given you guys is truthful. Guessing is hard enough as it is, and I don’t feel like I need to mislead you on top of that.<br />
<br />
LOL! Actually now that I think about it, there is another word that more or less matches too…<br />
<br />
<br />
<br />
<br />
<br />
No. Actually, all but 1 word from this guess appears on the Theme.<br />
<br />
Wait a sec. I just realized I got this backwards. What I meant was that only ONE word from this guess appears on the guess!!<br />
<br />
I guess that my english is not as good as I thought…<br />
<br />
<br />
<br />
<br />
<br />
<br />
[Hint] Before we get serious, we need to learn the basics<br />
<br />
On rule “Recipes” after the sentence “The first item is called the Recipe and the other items are called Ingredients.” add “A description of the recipe may also be added in italics after a recipe, yet it has no rules effect.”<br />
<br />
Create a sub-rule “Writing Recipes” under rule “Recipes”:<br />
<br />
As a daily action, the Writer may add a new Recipe to the Recipes wiki document. Each Recipe must have at least three ingredients and a description. This new recipe is added at the end of the document, and as long as there is no other recipe after it, it is known as the Goal Recipe.<br />
<br />
Create a sub-rule “Practice” under rule “The Table”:<br />
<br />
If a Member has a Recipe on eir table that is also the Goal Recipe, the Staff Member, thereby known as the Contestant, may start a Practice Session by creating a Story Post that starts with “[Taste]” and removing the Recipe from eir table. The Contestant is also expected to give a short description on the peculiarities of the prepared recipe. The Contestant then obtains 1 Guess. Afterwards, no more Practice Sessions can be created for the same Goal Recipe (if they do get created, their Contestant gains no Guesses).<br />
<br />
Add the following at the end of rule “Ingredients”:<br />
<br />
At no time shall there exist more that 50 Ingredients on the Ingredient List. If there are at least 20 Ingredients on the Ingredient List, as a weekly action, any Member may “Clean the Fridge” and remove up to 3 Ingredients from the Ingredients List.<br />
<br />
<br />
<br />
<br />
<br />
<br />
No. Morsel does not appear. And its not Mercury either.<br />
<br />
Oh, scratch that, I am now seeing that this would be unfair to DC, which also got close on a previous guess…<br />
<br />
So, I’ll give this clue publicly instead: One word from this guess does appear on the Theme, exactly, except for capitalization (don’t worry about that last part, capitalization does not matter when guessing, but that might also provide an extra hint to somebody).<br />
<br />
<br />
<br />
<br />
<br />
Actually, didn’t I say “Dinner” did not appear on the Theme? Neither do synonyms of it.<br />
<br />
In conclusion: No.<br />
<br />
<br />
<br />
<br />
<br />
[Hint] Contains Vitamins and Minerals<br />
<br />
Add a sub-rule called “Enhancements” to rule “Recipes”:<br />
<br />
Some Recipes may provide enhancements when eaten. An Enhancement is a non-italics text that follows a Recipe on the Recipes wiki document, and which can only be set, added and removed by the Writer, or through a successful Proposal or Call for Judgment. As a daily action, a non-Translocating Member may eat one of the Recipes on their table. Upon doing so, the Member shall follow the instructions laid on the Enhancement’s text. Enhancements are not allowed to change the ruleset, either directly or indirectly.<br />
<br />
If a Recipe has no Enhancement, the Writer may add an Enhancement to it at any time.<br />
<br />
<br />
<br />
<br />
<br />
[Hint] So, this story takes place in…<br />
<br />
Add a sub-rule to rule “Cosmology”, called “Victory Lane”:<br />
<br />
If the name of a Station that exists on the Solar Map appears on the Theme, Members of the Staff whose Station is not set to that Station may not achieve victory.<br />
<br />
If this doesn’t pass, you will have more trouble figuring out which station it was! *devious laughter*<br />
<br />
<br />
<br />
<br />
<br />
No. Only 1 word from this Guess appears on the theme! <-- got it right this time?<br />
<br />
<br />
<br />
<br />
<br />
No. The Moon does not appear on the Theme. Sorry for taking so long to respond.<br />
<br />
<br />
<br />
<br />
[Hint] Show me a map to the stars<br />
<br />
In sub-rule “The Highway” change sentence “Members that own a Vehicle may use this Road to, as a daily action, switch their Stations to any other valid value, without the need for Translocation.” for “Members that own a Vehicle may use this Road to, as a daily action, switch their Stations to any other Station adjacent to it on the Solar Map, without the need for Translocation.”<br />
<br />
Create a new sub-rule “Solar Map” under rule “Cosmology”:<br />
<br />
There exists a wiki document known as “Solar Map” which lists the possible routes between two stations. Two Stations are considered Adjacent in the Solar Map if one of them appears right before the other one. As a weekly action, a Member of the Staff may add a Station to the Solar Maps. A Station may be added even if it already appears in the Solar Map, as long as this doesn’t cause a Station to be Adjacent to itself.<br />
<br />
Erase all the contents of the Solar Map wiki document.<br />
<br />
Next, some spring cleaning of the ruleset, just to make it more readable (and satisfy my obsessive-compulsive disorder)<br />
<br />
If more than half of all comments containing counted votes also contain the text “Cleanup”, then:<br />
<br />
Make rule “Synonyms” a sub-rule to rule “Theme”.<br />
Make rule “Fuel” a sub-rule to rule “Vehicles”.<br />
Change the name of rule “We Will All Fry Together When We Fry” to “Countdown” and append the sentence “This rule is always the last Dynastic Rule in the Ruleset” to it.<br />
<br />
<br />
<br />
<br />
<br />
Nope. The food/cooking element is missing.<br />
<br />
<br />
<br />
<br />
<br />
No. You get three words right and Road is not one of them.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Does the theme involve racing?<br />
Yes.<br />
<br />
Including spaces, are there an even number of characters in your description of the Theme?<br />
Yes.<br />
<br />
Does the theme involve catering/delivery in some form or fashion?<br />
No.<br />
<br />
Does the theme contain the word “alien”?<br />
No.<br />
<br />
Does the theme contain the word “competition”?<br />
No.<br />
<br />
Is the word dinner in the theme?<br />
No.<br />
<br />
Does the theme have to do with TV or movies?<br />
No.<br />
<br />
Do you expect this dynasty to be over within ten days from the time this proposal is passed?<br />
No.<br />
<br />
Does the word Cook, or a variation thereof (Such as Cooking, or Cooked) appear in the theme?<br />
No.<br />
<br />
Does a common name for a planet or other celestial body appear in the theme name?<br />
Yes.<br />
<br />
Does the theme contain the word “super”?<br />
No.<br />
<br />
Arthexis should edit this post to include the answers to the questions.<br />
It’s done --arth<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
No. The Theme is not so long.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Hot.<br />
<br />
<br />
<br />
<br />
<br />
[Hint] Heartier, Tastier, Faster, Further<br />
<br />
Create a new sub-rule called ‘’The Bowl” under rule “The Table”:<br />
<br />
Members have a subsection under their Table known as the Bowl, where they may keep ingredients that they have aquired but have not been used. Members cannot keep more than five Ingredients in their Bowls. Any action that requires a Member to remove an Ingredient from the Ingredients List may instead be performed by removing that Ingredient from that Members Bowl. Members can only put or remove items from their own Bowl, and only as allowed by the rules. At any time, a Member may pay 1 Credit to select one ingredient from the Ingredients List and put a copy of it into that Member’s Bowl, but only if the Ingredient is not associated with a Station or if the Member’s Station is the same as the Ingredient’s Station.<br />
<br />
Create a new rule called, “Spaceport”:<br />
<br />
As a daily action, a Member may pay 10 Credits to set their Station to Jump. This is known as Commencing Translocation.<br />
<br />
If more than half of all comments containing counted votes also contain the text “MOAR RPM”,<br />
<br />
In sub-rule “The Highway” replace all occurrences of “as a daily action” with “at any time”.<br />
<br />
<br />
BTW: There is one more element for guessing the Theme, but I am not gonna make a direct Hint Proposal for it! You will have to deduct it… (This Proposal might contain a hidden hint about that somewhere)<br />
<br />
<br />
<br />
<br />
<br />
Warm. Still missing something, tho…<br />
<br />
<br />
<br />
<br />
Yoda has chosen letter ‘A’ (a very obvious choice): It appears 3 times on the Theme.<br />
<br />
<br />
<br />
<br />
[Hint] Cloning is Outlawed now, Guessing is Not.<br />
<br />
Cloned ingredients have been declared an illegal enhancement by the Association. Competitors that continue to use them will be disqualified.<br />
<br />
Repeal sub-rule “Cloning”. Remove all cloned Ingredients from the Ingredients List (but leave the originals if they still exist).<br />
<br />
At the end of sub-rule “Writing Recipes” add:<br />
<br />
When a new Recipe is created, the Writer shall add 1DICE10 Credits to the Members who created any of the Ingredients that are part of that Recipe. This shall apply only for items that existed prior to the creation of the Recipe. The Writer may also, within a period of 24 hours modify (this includes adding or removing) the value of the Station which is associated to that Ingredient if it appears on the Ingredients List.<br />
<br />
<br />
<br />
<br />
<br />
<br />
No. Not Galactic. Tasting might have to do with it though.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[Hint] We need MOAR speed, SRSLY. Its all about speed.<br />
<br />
Add a new sub-rule called “Turbo” under rule “Vehicles”:<br />
<br />
As a daily action, a Member with a vehicle may start Turbo Mode by making a GNDT comment of “TURBO”. When a Member is in Turbo Mode, they may perform daily actions that require spending fuel as if they where not daily actions, and may instead perform them as long as they can pay their fuel cost. However, they cannot perform more than X such actions, where X is their Vehicle’s Speed, until Turbo Mode is deactivated. Turbo Mode lasts 2 hours, then deactivates itself.<br />
<br />
On rule “Vehicles” change the sentence: “Vehicles may be added to the vehicles page by the writer, and the amount of fuel each vehicle can carry is described there.” to:<br />
<br />
Vehicles may be added to the vehicles page by the writer, and the amount of fuel each vehicle can carry, and their Speed is described there.<br />
<br />
On sub-rule fuel change the sentence “As a daily action, a Member of the Staff may purchase an amount of fuel by decreasing their credits by one per unit of fuel they wish to buy and adding that much fuel to their fuel in the GNDT” to:<br />
<br />
As a daily action, a Staff Member may purchase an amount of fuel equal to their Vehicle’s fuel rating by paying 10 Credits, then setting their Fuel in the GNDT to the fuel rating of their Vehicle.<br />
<br />
Remove sentence “As a daily action, a Staff Member may set their Station to any planet or moon that is located within the Solar System if they are currently Translocating or they may set their Station to Jump if they are not currently Translocating.” from rule Cosmology.<br />
<br />
<br />
<br />
<br />
<br />
No. You’re pretty close however, but you’re still missing something very crucial.<br />
<br />
<br />
<br />
<br />
<br />
<br />
No. Clucky got another word right, however. I feel he is getting close.<br />
<br />
<br />
<br />
<br />
<br />
<br />
[Hint] Zoom Zoom to Victory<br />
<br />
Create a new rule called “Events”:<br />
<br />
As long as there are no Ongoing Events, the Writer may create a new Event by making a story post whose subject starts with “[Event]”. The text of the post must contain an Itinerary and a Menu. An Itinerary is a list of Stations that appear on the Solar Map, and a Menu is a list of Recipes that appear on the Recipes document. When an Event is created, it is considered to be Ongoing.<br />
<br />
A Member who is not already Participating on that Event may get Signed Up for it by paying 5 Credits and owning a Vehicle, and thus become Participants on that Event. Members who Participate in an Event have an additional section on their Table called the Trace. Whenever a Participant changes location, they shall add the name of the new Station to their Trace. When another Event is created, the Traces for all previous Participants are deleted.<br />
<br />
At any time that a Participants meets every one of the Victory Conditions, that Participant becomes the First Place. Only the first Participant that meets all the Victory Conditions can be the First Place. The Victory Conditions are:<br />
<br />
* The Participant’s Trace must list the Stations for the Itinerary exactly once. (If other Stations appear on the Trace, it doesn’t matter)<br />
* The Participant’s Table must contain one of each of the Recipes on the Menu. (If other Recipes appear on the Table, it doesn’t matter)<br />
* The Participant must have not crashed more than 3 times since becoming a Participant for this Event.<br />
<br />
When there is a First Place on an Event, the Event is no longer ongoing and the First Place obtains 3 Guesses, 150 Credits and may set their Location to any valid value once within the next 48 hours.<br />
<br />
This is it. The final event is near!<br />
<br />
<br />
<br />
<br />
<br />
no.<br />
<br />
<br />
<br />
<br />
<br />
I just got in to see there has been a huge misunderstanding. Apparently, I made a typo and got everyone to believe they had already solved the riddle! What I meant in my comment was that there was ONE word from that guess that showed up in the Theme, but it seems I got it backwards!<br />
<br />
Back on to your question, there is indeed only one ‘S’ on the theme.<br />
<br />
HALO. I WIH TO NO WUT YOU PMed WAKKY.<br />
<br />
Did you say there was 1 s in the theme?<br />
<br />
I confirm this information.<br />
<br />
<br />
<br />
<br />
<br />
Clever, but no. Zero words right. This basically means, that Ceres is not the planet you’re looking for.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Heh. Nope. Zero. You fail at the internets.<br />
<br />
<br />
<br />
<br />
<br />
<br />
[Hint] Faster Traveling through better roads<br />
<br />
Create a sub-rule “The Highway” to rule “Cosmology”:<br />
<br />
There exists an super highway, known as Sol Road, that interconnects many cities from different planets and moons. Members that own a Vehicle may use this Road to, as a daily action, switch their Stations to any other valid value, without the need for Translocation. However, this requires the Member to Spend 1 unit of Fuel.<br />
<br />
Also, at any time, the Writer may announce that one or more Gates are under maintenance by making a Story Post with “[Maintenance]” in the subject and listing one or more Station values, as well as a date of when the Maintenance will end. Members may not use the Sol Road to switch their Stations to values that are under Maintenance, until the Maintenance ends.<br />
<br />
Of course, Fuel and Vehicles don’t currently exist… I’ll leave that up to you.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Cool. You are going too far into the cooking theme.<br />
<br />
<br />
<br />
<br />
<br />
I don’t know what Solarquest is. No.<br />
<br />
<br />
<br />
<br />
Actually, didn’t I say “Dinner” did not appear on the Theme? Neither do synonyms of it.<br />
<br />
In conclusion: No.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
No. Farming has nothing to do with it.<br />
<br />
<br />
<br />
<br />
<br />
<br />
You fail. You have to cook, but it’s not only about cooking. See my next proposal!<br />
<br />
<br />
<br />
<br />
<br />
Nope. No Service.<br />
<br />
No Catering either.<br />
<br />
No, not space even! :P<br />
<br />
<br />
<br />
<br />
<br />
<br />
No, not the solar system.<br />
<br />
<br />
<br />
<br />
<br />
<br />
[Hint] Time for a crash course<br />
<br />
Add a new sub-rule called, “Crash” under rule “Vehicles”:<br />
<br />
As a daily action, a Member with a Vehicle (known as the Attacker) may spend X Fuel in an attempt to crash into some other Member (knows as the Target) who has the same Location as the Attacker. The value for X must be at least 2. The attacker shall then add their vehicle’s Speed to X, and roll DICEX. If the result is equal to or greater than the Endurance of the Target’s Vehicle (for this special case, if the Target has no Vehicle, their endurance is considered 3) the Target has Crashed: their Bowl and Table are emptied and 1 of their Guesses is transfered to the Attacker.<br />
<br />
In rule “Vehicles” reword sentence “This is tracked in the GNDT. Vehicles may be added to the vehicles page by the writer, and the amount of fuel each vehicle can carry, and their Speed is described there.” so that instead it reads “This is tracked in the GNDT. Vehicles may be added to the vehicles page by the writer, and the amount of fuel each vehicle can carry, their Speed and Endurance is described there.”<br />
<br />
<br />
<br />
<br />
<br />
<br />
No, because you’re not students.<br />
<br />
<br />
<br />
<br />
<br />
Hot.<br />
<br />
<br />
<br />
<br />
<br />
No. You get Zero words right.<br />
<br />
<br />
<br />
<br />
<br />
Oh and Hot.<br />
<br />
<br />
<br />
<br />
<br />
<br />
[Hint] The fruitcake never dies<br />
<br />
Remove the following from rule “Recipes”:<br />
<br />
As a weekly action, if every ingredient for a given recipe appears on the ingredient document at least as many times at it does in a recipe, a Staff Member may remove one occurrence of each ingredient for each time it appears in the recipe and add the recipe to his section of the table. (He does not remove the recipe from the recipe document).<br />
<br />
Create a new sub-rule “Cooking” under rule “Recipes”:<br />
<br />
As a daily action, if every ingredient for a given recipe appears on a Member’s Bowl at least as many times at it does in a recipe, that Staff Member may remove one occurrence of each ingredient from eir Bowl for each time it appears in the recipe and add the recipe to his section of the table. (The recipe is not removed from the recipe document).<br />
<br />
Create a new sub-rule “Rejection” under rule “The Table”:<br />
<br />
If a Member doesn’t think that a Recipe on eir own table is good enough to be judged, e may Reject that Recipe by writing a bad review of it as a Story Post and removing it from eir Table. If a Member Rejects a Recipe in this manner, that Member cannot reject another one until 72 hours have elapsed. When a Recipe is Rejected, all Ingredients that make it up (according to the Recipes document) get removed from the Ingredients List.<br />
<br />
Now, making recipes does not normally remove Ingredients: you have to fetch them through rule “The Bowl”. However you can Reject them as an “offensive” move to acualy destroy ingredients other Members may need. Furthermore, I would like people to propose a way to get Credits, as I think they may see quite a lot of use, but we don’t have enough of them… just nothing too grindy please.<br />
<br />
<br />
<br />
<br />
<br />
<br />
No. You’re not a Chef.<br />
<br />
<br />
<br />
<br />
No. Not really a battle. It’s another kind of competition.</div>Zackhttps://wiki.blognomic.com/index.php?title=File:Zack1_banner.png&diff=25648File:Zack1 banner.png2024-02-27T03:03:03Z<p>Zack: Add category and desc</p>
<hr />
<div>[[The First Dynasty of Zack|The Box Company Dynasty]] banner<br />
[[Category:Banner]]</div>Zackhttps://wiki.blognomic.com/index.php?title=File:Zack2_banner_v2.jpg&diff=25647File:Zack2 banner v2.jpg2024-02-27T03:02:14Z<p>Zack: Add category</p>
<hr />
<div>== Summary ==<br />
Zack II Banner<br />
[[Category:Banner]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Alternative_Endings&diff=25646Alternative Endings2024-02-27T02:56:53Z<p>Zack: </p>
<hr />
<div>{{gamestate|The First Dynasty of Devenger}}<br />
<br />
In his invulnerable car, Stewart follows the ninjas back to their, and Man’s, secret base. <br />
<br />
== Tall Girl Returns ==<br />
<br />
* Script: Stewart enters the base, and runs through it, shooting many ninjas. Eventually, he finds Man. Man calls for backup, and a bunch of corrupt members of The New And Improved Explosive Amazing Super Ultra Powerful Stupendous Awesome Extreme Rodlenian DDA arrive. Stewart is outgunned and outnumbered. He shoots as many agents as he can, but runs out of ammo. Everything seems hopeless...until a tree flies into the room, killing the remaining agents. Tall Girl enters. Stewart takes a gun from one of the dead agents, and shoots Man. Man staggers. Tall Girl throws him at wall, killing him. Credits roll.<br />
<br />
* Body Count: 24<br />
<br />
== Revenge of the Mad King ==<br />
<br />
* Script: Stewart enters Man’s base. Man unmasks, revealing himself as Mad King Anthony. Anthony pulls out veto gun, and shoots Stewart several times. 25 ninjas appear and attack Stewart. Stewart takes one and throws it at another, and uses nuke on the rest. Anthony and Stewart have epic duel, but at the end Stewart loses and Anthony uses Kirby/Sonic-Taunt Japanese Torture Device on him, before charging up shot with veto gun. Stewart kicks gun out of Anthony’s hand and catches it, and vetoes anthony. Credits roll.<br />
<br />
* Body Count: 26 <br />
<br />
== Where Tentacles Don’t Belong ==<br />
<br />
* Script: Stewart runs through the entrance of the secret base, guns blazing, killing many. He is ambushed by an Ancient Break-Away Vase With Humongous Intelligent Slimy Tentacles. Tall Girl emerges from deeper within the base, picks up the vase and smashes it over Stewart’s head. Stewart wakes up in a dark room, Man enters. Stewart and Man fight to the death. Stewart emerges victorious, leaves room, Tall Girl shouts ‘What have you done?’ Ninjas fall from the ceiling, grab onto Tall Girl, throw smoke bombs and promptly disappear. Credits roll. <br />
<br />
* Body Count: 28 <br />
<br />
== Redemption ==<br />
<br />
* Script: Stewart strides confidently into the base, directly towards the waiting Man. Man snaps his finger, and 25 ninjas step from the shadows, throwing the bound Tall Girl at Stewart. As the ninjas descend upon them, Stewart tightly grasps A Magical Shiny Gold Monocle with a Very Shiny Gold Chain and recites the final words of Gandhi to the tearful girl: “I just wanna tell you how I’m feeling, gotta make you understand.” The power of the Monocle is unleashed, vaporizing the ninjas where they stand. Stewart punches the man in the face. As Man dies, Stewart and Tall Girl kiss. <br />
<br />
* Body Count: 26<br />
<br />
== Old Fashioned Epic Showdown ==<br />
<br />
* Script: Stewart fights whip wielding ninjas just inside, then sneaks through base, an active steel foundry, garroting ninjas with a stolen whip. He finds Man’s control room, kicks in door, discovers him watching the factory showdown scene of Forty Two Thousand Four Guys Kills Man Twice Again: Unrated. Man draws gun, Stewart disarms him with whip, tackles him through observation window. They land on a catwalk without guardrail above a vat of molten metal, fight, Man falls. Stewart flees as machinery explodes around them and escapes two seconds ahead of a massive explosion. Bodies fall around him as he drives away. <br />
<br />
* Body Count: 30<br />
<br />
== The Man Comes Around ==<br />
<br />
* Script: Thunder rolls. Stewart arrives at the old peanut factory, parking behind the White Horse Peanuts sign. He climbs onto the warehouse roof. Through skylights, Man can be seen overseeing ninja workmen as they prepare an army of bipedal earthquake machines. Alarms sound. Stewart turns to see six ninja approaching across the roof. He fights his way down through the building, to a final stand-off with Man, who threatens to send the earthquake robots out across the world. Thunder rolls, and a thorn tree crashes through a skylight, crushing Man. On the roof, Tall Girl’s hair blows in the wind. Fade. <br />
<br />
* Body Count: 36<br />
<br />
== Death of a Redshirt ==<br />
<br />
* Script: Stuart walks into Man’s lair, stopped by single guard (in red shirt). Guard says Man is busy, said Stuart would come, orders ninjas to attack.<br />
Stuart: “Ninjas??? I see no ninjas…”<br />
Voice: “Duh. We’re ninjas”<br />
[Fight scene. Stuart shoots 5 ninjas, kills the rest with katanas.]<br />
Start confronts Man. Man begins to tell life-story. Stuart shoots Man.<br />
Stuart: “Hah! All done, One bullet left.”<br />
Throws the gun on floor. Fade to black as Stuart exits.<br />
[Gunshot]<br />
Tall girl: “Zero.”<br />
Stuart begins to ask why, but falls to his knees bleeding. Tall girl exits as scene zooms out, fades to white. <br />
<br />
* Body Count: 26<br />
<br />
[[Category:Acts of Dynasty 64]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Final_Act&diff=25645Final Act2024-02-27T02:56:42Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The First Dynasty of Devenger}}<br />
<br />
In his invulnerable car, Stewart follows the ninjas back to their, and Man’s, secret base. <br />
<br />
== Revenge of the Earthquake Machine ==<br />
<br />
* Script: Stewart, following ten fleeing ‘ninjas’, realises they aren’t real ninjas; how could he follow them if they were? He blows up nine with a bazooka, following the last into a vast secret base disguised as an airport. Man is there, surrounded by 21 worshipping shadowy figures. The last ninja pulls Stewart’s remote control out of her pocket, and uses it to cause the Giant Disaster Averting Machine to rumble towards Stewart. Tall Girl suddenly appears and throws the machine at the ninja (splat!), and it shoots the shadowy figures dead with lightning. Stewart then throttles Man to death. <br />
<br />
* Body Count: 32<br />
<br />
[[Category:Acts of Dynasty 64]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Act_6_-_A_Plan_Comes_Together&diff=25644Act 6 - A Plan Comes Together2024-02-27T02:56:26Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The First Dynasty of Devenger}}<br />
<br />
Stewart snaps out of his narcotic haze with an inspired plan to save the day. <br />
<br />
Target Body Count: 50<br />
<br />
== Got it! ==<br />
<br />
* Script: “Its genius!” shouts Stewart, as he realises the true might of his new plan. Stewart goes into his underground lab, gets into a fast car and swings out of his drive and speeds down the highway. Meanwhile, Man emerges cackling, in the distance, a pipe bomb explodes killing 10. <br />
<br />
* Body Count: 10<br />
<br />
== Ahimsa ==<br />
<br />
* Script: Hero goes to Mahatma Gandhi (Tony Roberts) for advice on his new plan. Gandhi says to find Mr. Peanut (Mahatma Gandhi) and steal A Shiny Gold Monocle with a Very Shiny Gold Chain. Hero does so. Upon looking into the Monocle, he sees a strange music video. . . . <br />
<br />
* Body Count: 8<br />
<br />
== Dubiously Secret Emails ==<br />
<br />
* Script: Hero fast-forwards through the rest of the music video. The screen turns dark, and shows a shadowy figure at a computer (someone like Merian C. Cooper), evidently being filmed by a hidden camera. As he types in a large green font, his unbranded laptop reads out each word. <br />
<br />
* Body Count: 10<br />
<br />
== Untitled Scene of Death ==<br />
<br />
* Script: Laptop reads “I AM MR. PEANUT”. Hero jumps out of window and several buildings explode. Hero confronts Mr. Peanut… <br />
<br />
* Body Count: 4<br />
<br />
== Gearing up ==<br />
<br />
* Script: The hero returns to his car, which apparently still works, and speeds off, running over four ninjas, and driving into a secret lab. An old scientist gets out some weird devices for him, but is attacked by more ninjas; the hero shoots six, but the others escape with the devices. <br />
<br />
* Body Count: 10<br />
<br />
== They’re behind you ==<br />
<br />
* Script: Then the machine rises from the ground behind the agents and opens a crevasse which they all fall into. Man looks out and, seeing Stewart and Tall girl in front of him,starts driving the machine towards them. <br />
<br />
* Body Count: 8<br />
<br />
[[Category:Acts of Dynasty 64]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Act_5_-_Hallucination&diff=25643Act 5 - Hallucination2024-02-27T02:56:13Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The First Dynasty of Devenger}}<br />
<br />
Noxious fumes have overwhelmed Stewart. Stumbling through surreality, he experiences many things…<br />
<br />
Target Body Count: 67204 <br />
<br />
== Eerie ==<br />
<br />
* Script: It’s dark. Stewart sees a small squirrel, which shows off its vampiric teeth, and whispers Stewart a secret. Having ripped the Contradictory Sharp Icy Fire Bat From The Inquisitive Hearing Ear of the squirrel, he bowls it towards a herd of sheep people, who howl as it explodes with radiance. <br />
<br />
* Body Count: 5<br />
<br />
== What was that? ==<br />
<br />
* Script: The radiant shower of sparks flow into Stewart who grows in size and power. 5 Guardian statues attack and Stewart grinds them into dust. <br />
<br />
* Body Count: 5<br />
<br />
== Exploding Head ==<br />
<br />
* Script: And then Daniel Kountz’s head explodes gorily. And awesomely. <br />
<br />
* Body Count: 1<br />
<br />
== Nooooooo ==<br />
<br />
* Script: Mutant snake with legs (someone like Lillian Gish) enters hero’s ear. Hero goes insane and kills four hallucinated clones of Man. Mutant snake leaves ear. <br />
<br />
* Body Count: 4<br />
<br />
== Transform ==<br />
<br />
* Script: The snake transforms into a trio of lizardman like beings with machines stuck on autofire a few seconds and many bullets later there are three spreading pools of blood and gore on the floor. <br />
<br />
* Body Count: 3<br />
<br />
== Headless ==<br />
<br />
* Script: Stewart spins around, to see a man in a scruffy blonde wig (50 Cent) clutching an axe. Behind the man, six cleanly headless bodies collapse onto the featureless black floor. <br />
<br />
* Body Count: 4<br />
<br />
== Aerial Combo: 24 hits! ==<br />
<br />
* Script: After a small explosion, Hero is propelled into space, where he finds he can breath. He lands on a distant planet populated with one sandwich, one wrap, and one cream-cheese bagel. In an epic aerial fight, they are dispatched, and seem to bleed just fine. <br />
<br />
* Body Count: 3<br />
<br />
== Wait, GREEN? What? ==<br />
<br />
* Script: Three purple elphants mysteriously appear, and offer Hero a Ride. Suddenly, a mysterious figure in a black cloak (Isabel Jewell) waves a banana at the elphants, who turn green. Ahh! Then they start singing Celine Dion songs. AHHH! <br />
<br />
* Body Count: 3<br />
<br />
== Floating ==<br />
<br />
* Script: The hero floats through a bubbly green gas, with small fluffy pink fish swimming around. He turns into a metal shark and eats two of them, flicking a third into a large boulder with its tail (which ends up badly crushed and explodes), and shoots the fourth with a laser. <br />
<br />
* Body Count: 4<br />
<br />
[[Category:Acts of Dynasty 64]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Act_4_-_Depths&diff=25642Act 4 - Depths2024-02-27T02:55:56Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The First Dynasty of Devenger}}<br />
<br />
Hero goes into steel grate opening, descends into darkness down ladder.<br />
<br />
Target Body Count: 120<br />
<br />
==Eyes==<br />
* Script: Hero drops to the ground, wetness, he looks around and at first sees nothing. Then, shining eyes peer from the darkness, a boy (Nicholas Art) says: ‘Come with usss, join usss...’ Hero swiftly throws a grenade and hears moans as four pairs of eyes flicker out of existence.<br />
* Body Count: 4<br />
<br />
==A Pitt==<br />
* Script: Hero looks around. A pit. Deep one. And a Pitt. Annoying one. And 9 other targets. Also annoying. Hero pushes them all into the pit by bashing them with the Empire State. He then takes a note that fell out of Pitt’s pocket…<br />
* Body Count: 10<br />
<br />
==The Note==<br />
* Script: The Hero unfolds and reads the note, which is spoken in a voiceover (Angelina Jolie). It is addressed to Pitt, and tells him that “they” are looking for the underground settlement, and have now started to bomb any likely locations.<br />
* Body Count: 14 <br />
<br />
==Postscript==<br />
* Script: Hero discards the note, failing to notice the postscript, which is nonetheless voiced-over by Brad Pitt in a devilish voice: “This message will self-destruct. . . .” Explosion. 14 people extinguished in the shadows. Hero’s leg is mildly injured.<br />
* Body Count: 14<br />
<br />
==Rocks Fall, Everyone Dies==<br />
* Script: Two ninjas appear, similar to ones from van. Hero throws rocks at both ninjas, killing them. Nicholas Art can be seen in the background.<br />
* Body Count: 3<br />
<br />
==Underdeep==<br />
* Script: Traveling deeper underground our hero Stewart is ambushed by a squad of Molemen. Stewart guns them all down, yet pauses to listen to the Foreman’s (Brad Pitt) long and embittered death speech regarding the invasion of over-worlders into his subterranean home. A teary eyed Stewart trudges on.<br />
* Body Count: 15<br />
<br />
==Hallelucination!==<br />
* Script: As Stewart moves through the sewer, he begins to feel the effects of noxious sewer gases. Cue warping, flashing colors and odd chanting (James Palacio)in the background. He picks up a Contradictory Sharp Icy Hot Fang Of Inquisitive Fire, understanding its unrivaled power, and erases six telemarketers that appear inexplicably.<br />
* Body Count: 6<br />
<br />
==The Stars Below==<br />
* Script: Meanwhile, the Man is standing on a hill, impassively staring down at a small village in rural Nebraska. Coming behind him, Brigadier Unthank (Brad Pitt), Yellowstone’s perfect enforcer, perplexedly shouts “Inspector!” Confusion occurs locally as bombs drop on the village, killing many.<br />
* Body Count: 15<br />
<br />
==Strife==<br />
* Script: The view zooms up to and inside the plane that dropped the bombs. There’s a row on board; the co-pilot (Brad Pitt) seize the controls by breaking the pilot’s neck, and the rest of the crew join in the scuffle, twelve falling out of the bomb bay to their deaths. <br />
* Body Count: 13<br />
<br />
[[Category:Acts of Dynasty 64]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Act_3_-_Recovery&diff=25641Act 3 - Recovery2024-02-27T02:55:43Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The First Dynasty of Devenger}}<br />
<br />
After fade to black: Hero regains consciousness, to find himself lying in a wrecked wasteland.<br />
<br />
Target Body Count: 40<br />
<br />
==Rubble Trouble==<br />
* Script: Hero surveys the scene, he sees a rumbling among the wreckage, a cockroach scutters from the scene; noises of people struggling are heard from beneath brick rubble, and then nothing. Two lives snuffed. A squirrel pokes inquisitively from beneath a broken kitchen appliance, approaches the Hero tentatively sniffing his boots.<br />
* Body Count: 2<br />
<br />
==Tank!==<br />
* Script: Hero rises slowly as tank approaches in the distance. Hero finds grenade at his feet, tosses it at tank. Tank driver (Donald Foley) shouts “No!” as tank explodes. All 3 passengers die. Cockroach continues to sniff, unconcerned. <br />
* Body Count: 4<br />
<br />
==Jaws...er...Teeth==<br />
* Script: Hero looks at nearby pool. In it, a Mechano-Shark kills it’s first victim, like in Jaws, with Susan Backlinie as the victim.<br />
* Body Count: 1 <br />
<br />
==A Load Off==<br />
* Script: Our illustrious hero Stewart notices a camper parked nearby. The owner, a rugged man named Bo (Dennis Quaid) invites ‘Stew’ in for bacon and eggs. Waving away security concerns, Bo says the RV auto defenses are the best… and indeed it kills eleven fleeing refugees during the meal.<br />
* Body Count: 11<br />
<br />
==The Ruins of Tokyo 5==<br />
* Script: Bo pulls the camper into a ruined city, which he identifies as Old New Neo Tokyo Omega Five. The Hero looks out of the window. On the street outside, a lady (Marianne Muellerleile) succumbs to plague. Her child cries briefly, before dying from the plague as well. The Hero chokes back a tear.<br />
* Body Count: 2<br />
<br />
==The Home Stretch==<br />
* Script: The dashboard radio glows and crackles, and a voice (Mary Deese) tells Bo that he hasn’t got much time. Bo tells the Hero to buckle up. Accelerating, the camper van thumps four unseen pedestrians to the ground.<br />
* Body Count: 4<br />
<br />
==People Die==<br />
* Script: Camper van crashes after hitting Ella Mitchell. Driver dies, but hero survives. Hero tortures 5 ninjas who appear out of nowhere and attack him, using the Kirby-Taunt Japanese Torture Device, and then kills them.<br />
* Body Count: 5 <br />
<br />
==What’s This?==<br />
* Script: Hero exits van, van explodes. Uninjured Hero rummages through remains of van, acquires and equips Gold Rimmed Monocle with Chain. Glare blinds two ninjas. They fall on van which bursts into more flames, giving away two other ninjas. Hero eviscerates one bare-handedly and defenestrates other through van window.<br />
* Body Count: 4 <br />
<br />
==Tourists==<br />
* Script: Hero sees a crowd of people approach and begins to sprint towards them, carrying An Imported Rusty Scimitar. After dicing them to bits, he realizes they were in fact ten Canadian tourists and their tour guide (Thomas Gibson).<br />
* Body Count: 11<br />
<br />
==The Unknown==<br />
* Script: The hero, running through the wasteland, encounters a steel grate in the floor. As he bends to open it he is set upon by 5 masked assailants. He kills four using martial arts, and the fifth by using him as a lever to operate its locking mechanism.<br />
* Body Count: 5<br />
<br />
==Return to Shadow==<br />
* Script: The last ninja stands before a semi circle of beings in large dark cloaks. One draws a gun to shoot him for his failure. Before the bullet flies the ninja throws a pair of shuriken killing two of the cloaked beings. The ninja is then shot and dies.<br />
* Body Count: 3<br />
<br />
[[Category:Acts of Dynasty 64]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Act_1_-_Prologue&diff=25640Act 1 - Prologue2024-02-27T02:55:26Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The First Dynasty of Devenger}}<br />
<br />
Flashback: Man returns home to shocking discovery. Inevitably, gunfights ensue.<br />
<br />
Target Body Count: 100 though I expect a timeout. <br />
<br />
==Romantic drama ends here?==<br />
* Man finds home apparently empty. Hears gunshots, equips pistol. Guns down three goons in living room, disarms and breaks neck of fourth. Approaches bedroom door…<br />
* Body Count: 4<br />
<br />
==Bam!==<br />
* Man opens door, tosses in pocket protector-bomb, shuts door. Explosion. Through smoking former-door, man sees 7 dead bodies, 4 living ones.<br />
* Body Count: 7 <br />
<br />
==Going Down.==<br />
* Man throws another bomb into the room. Ceiling collapses, killing the four people inside. A family of six, around their table, falls—all die.<br />
* Body Count: 10<br />
<br />
==A small family.==<br />
* Man finds 1 surviving body, along with 6 other living ones. Man fires a bullet into all of their heads. Dead.<br />
* Body Count: 7<br />
<br />
==Useless cops==<br />
* Two cops arrive outside house, are shot by man. Hero points gun at man.<br />
* Body Count: 2<br />
<br />
==Crossfire==<br />
* Hero enters house. Sees 10 goons. Crouches. All goons shoot each other accidentally.<br />
* Body Count: 10<br />
<br />
==RODLAN WUZ HARE==<br />
* Hero is interrupted by eight thugs. Hero shoots thugs, writes “RODLAN WUZ HARE” on the wall in their blood.<br />
* Body Count: 8<br />
<br />
==Backup==<br />
* Hero calls for backup. A seven-man SWAT team turns up; all end up shot.<br />
* Body Count: 7<br />
<br />
==Too Quiet.==<br />
* House is quiet. 6 Police outside look anxious. Man is behind them and says: “What’s wrong, chief?” Close-up on dangerous grin. Man kills all 6.<br />
* Body Count: 6<br />
<br />
==Recurring Villain==<br />
* Hero somersaults off roof with monocle dramatically. Empties magazine into man, bullets pass through man killing nine innocents. Monocle falls out.<br />
* Body Count: 9<br />
<br />
==The Cops never win==<br />
* Hero and 10 SWAT members surround Man. Man smirks and fires both guns in a circle. Hero dives away, SWAT do not.<br />
* Body Count: 10<br />
<br />
==Grim Psycho Dance==<br />
* Hero sees movement in garage. Upon entering he sees Evil Ben who catches his eye and cooly throws grenade into car with hero’s family inside.<br />
* Body Count: 4<br />
<br />
==Meanwhile==<br />
* Mysterious man on a plane speaks something about the Hero’s past while his men hijack the plane shooting down 6 passengers.<br />
* Body Count: 6<br />
<br />
==Panic==<br />
* 5 Passengers make a run for the front of the plane! Gunned down by man and cohorts.<br />
* Body Count: 5<br />
<br />
==Politics Loses==<br />
* Politicians protest on national media. Someone from the wings guns down two, the other 7 get into a fight, setting off a bomb that kills them.<br />
* Body count: 9<br />
<br />
[[Category:Acts of Dynasty 64]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Act_2_-_Aftermath&diff=25639Act 2 - Aftermath2024-02-27T02:55:12Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The First Dynasty of Devenger}}<br />
<br />
After opening credits roll: Unidentified character is watching a news report about the plane incident.<br />
<br />
Target Body Count: 60<br />
<br />
==Quake==<br />
<br />
Script: Television begins to rattle, then falls and smashes. Ceiling caves in, worker on roof splats to the ground next to unidentified character. Camera pans out, showing said character’s eyes rolling back into head as she dies of fright. Building begins to collapse disastrously.<br />
<br />
Body Count: 2<br />
<br />
==Night out.==<br />
<br />
Script: Buildings nearby begin to collapse also. People run from their homes in fright. Walls tumble from the sheer force. Six friends stroll home after a night in the pub, a quaking giant oak tree topples, one survives, a tall girl with long dark hair, she screams.<br />
<br />
Body Count: 5<br />
<br />
Total Body Count: 7<br />
<br />
==Quake Machine==<br />
<br />
Script: Giant machine emerges from underground, killing one bystander. The man from the prologue is on the machine. Man announces evil plot to cause natural disasters with the machine. Tall girl interferes by throwing tree at man, misses, gets shot.<br />
<br />
Body Count: 2<br />
<br />
Total Body Count: 9<br />
<br />
==Love Hurts==<br />
<br />
Script: Man pushes yellow button causing machine to fire lightning from the sky. Lightning hits a nearby pool, frying two lovers during a tender moment.<br />
<br />
Body Count: 2<br />
<br />
Total body count: 10 (as darths scene was cut)<br />
<br />
==The Approach==<br />
<br />
Script: Machine sprouts treads and begins to roll towards nearby city. It rises over the horizon as a family of four in the foreground madly drives away. Man fires a rocket, causing their car to flip and explode. Close-up on man with a hint of a smile on his face.<br />
<br />
Body Count: 4<br />
<br />
Total body count: 14<br />
<br />
==The Farmhouse==<br />
<br />
Script: Cut to a dark farmhouse. An owl hoots. A light comes on in an upstairs window. Cut to front verandah, where a farmer is loading a shotgun and squinting out into the night. The ground begins to shake. With a roar, the machine flattens the farmhouse, killing its four occupants.<br />
<br />
Body Count: 4<br />
<br />
Total body count: 19 (if Darth’s scene was cut, the total just carries on from Rodlen’s)<br />
<br />
==Future Sidekick==<br />
<br />
Script: Seven lost Boy Scouts emerge from woods. Machine attacks. Hero appears with shovel, deflects projectile, saves spikey-haired boy. Boy charges machine, Hero restrains boy.<br />
<br />
Body Count: 6 (Rolled five + 1 for popularity)<br />
<br />
Total body count: 25<br />
<br />
==Tactical Retreat==<br />
<br />
Script: Hidden amidst some foliage the Hero introduces himself as Stewart to his newfound sidekick whom he calls Oliver even though that is not the boy’s name. Stewart fires a flare to signal the awaiting attack helicopters which force the machine back underground suffering one lost chopper and it’s four occupants.<br />
<br />
Body Count: 4<br />
<br />
Total Body Count: 29<br />
<br />
==Getting even==<br />
<br />
Oliver hears noises in nearby foliage but before Hero is informed, ten goons jump out. Oliver pushes hero over and gets hit with bullets. Hero gets angry at the loss of new friend. He flying kicks one goon, picks up gun and shoots three before hearing faint “Help!” from Oliver.<br />
<br />
Body count: 4 (Rolled 5, deducted 1)<br />
<br />
Total Body Count: 27 if Gnauga’s is invalid.<br />
<br />
==Establishing motivation==<br />
<br />
With his dying breath, Oliver tells the Hero about a shadowy government conspiracy he heard about from his scoutmaster. Oliver is shot by a government sniper in a helicopter, which the Hero destroys by throwing a brick at it, killing both occupants.<br />
<br />
Body count: 3<br />
<br />
Total body count: 30<br />
<br />
==Crash and burn==<br />
<br />
Script: The helicopter then procedes to crash on the blockade, incinerating the 2 soldiers standing thereupon. In the distance the machine crushes another innocent civilian<br />
<br />
body count 3<br />
<br />
total 33<br />
<br />
==Shadows==<br />
<br />
Script: A group of unknown shadowy characters are watching the machine on TV. There are some mumbled orders and a muffled argument; five of them storm out, but are shot in the back by the others on the way.<br />
<br />
Body Count: 5<br />
<br />
Total Body Count: 38<br />
<br />
[[Category:Acts of Dynasty 64]]</div>Zackhttps://wiki.blognomic.com/index.php?title=List_of_Flairs&diff=25638List of Flairs2024-02-27T02:51:07Z<p>Zack: Copyedits</p>
<hr />
<div>'''Flairs''' are wiki templates that can be used to style the [[Ruleset]] and representations of gamestate. Each section on this list is a flair, with the name of the section being the name of the flair.<br />
<br />
To use a flair on a wiki page, do the following:<br />
* For multi-line flairs, insert <nowiki>{{Flair top|Flair name}}</nowiki> before the first line, and <nowiki>{{Flair bottom}}</nowiki> after the last line.<br />
* For single-line flairs, insert <nowiki>{{Flair|Flair name}}</nowiki> between two lines.<br />
<br />
This list is not gamestate, and anyone may edit it to ensure it is an accurate and helpful list of flairs available for use.<br />
<br />
== Multi-line flairs ==<br />
<br />
=== Hazard box ===<br />
<br />
Adapted from [[Template:Zone rule]], which was used in [[The Twenty-Ninth Dynasty of Kevan]].<br />
<br />
{{Flair top|Hazard box}}<br />
Switch Control: Any Citizen occupying this Zone may Veto a Proposal which would modify the Powered/Unpowered status of a floor. This does not apply to Proposals which would cause such changes only by virtue of containing the phrase “Advance Time.”<br />
{{Flair bottom}}<br />
<br />
=== Antique box ===<br />
<br />
{{Flair top|Antique box}}<br />
Inputs: None<br />
<br />
Effect: If any Wizards other than this Wizard receives any Stars from one or more Spells, other than Siphon, randomly select one of those Wizards to lose 1 Star, then this Wizard gains 1 Star. This Wizard can also receive Stars from other Spells and still trigger this Effect.<br />
{{Flair bottom}}<br />
<br />
=== Cardboard box ===<br />
<br />
{{Flair top|Cardboard box}}<br />
<br />
As a Departmental Action, an Employee may research a new type of box material by performing the following atomic action:<br />
* Roll 1DICEN, where N is any positive integer smaller than or equal to the company budget. The result of this roll is the research cost.<br />
* Divide the result by 10 then add Research Inspiration to determine the value for the new material.<br />
* Choose a name for the new material (the name of a material is arbitrary and always flavor text).<br />
* Add the name/value pair to the materials table.<br />
* Decrease the company budget by the research cost.<br />
* Set Research Inspiration to 0.<br />
<br />
{{Flair bottom|Cardboard box}}<br />
<br />
=== Quote box ===<br />
{{Flair top|Quote box}}<br />
''To be, or not to be, that is the question:<br />
<br />
Whether 'tis nobler in the mind to suffer<br />
<br />
The slings and arrows of outrageous fortune,<br />
<br />
Or to take arms against a sea of troubles<br />
<br />
And by opposing end them.''<br />
{{Flair bottom}}<br />
<br />
=== Light blue bg ===<br />
<br />
{{Flair top|Light blue bg}}<br />
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.<br />
{{Flair bottom}}<br />
<br />
=== Light orange bg ===<br />
<br />
{{Flair top|Light orange bg}}<br />
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.<br />
{{Flair bottom}}<br />
<br />
=== Formula box ===<br />
<br />
Quadratic formula:<br />
{{Flair top|Formula box}}<br />
x = (-b ± √(b<sup>2</sup> - 4ac)) / (2a)<br />
{{Flair bottom}}<br />
<br />
Pythagorean Theorem:<br />
{{Flair top|Formula box}}<br />
c = √(a<sup>2</sup> + b<sup>2</sup>)<br />
{{Flair bottom}}<br />
<br />
=== Dark terminal ===<br />
<br />
{{Flair top|Dark terminal}}<br />
Your connection has been terminated.<br/><br />
Press any key to continue...<br />
{{Flair bottom}}<br />
<br />
=== Shell command ===<br />
<br />
{{Flair top|Shell command}}<br />
BNshell v1.0.0<br />
<br />
$ ./blog_nomic<br />
<br />
Initiating blog_nomic process...<br />
<br />
> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.<br />
<br />
$ _<br />
{{Flair bottom}}<br />
<br />
=== Stone tablet ===<br />
<br />
{{Flair top|Stone tablet}}<br />
I. B. Ded<br/><br />
August 7, 1883<br />
{{Flair bottom}}<br />
<br />
=== Highlight text ===<br />
<br />
{{Flair top|Highlight text}}<br />
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.<br />
{{Flair bottom}}<br />
<br />
=== Bold text ===<br />
<br />
{{Flair top|Bold text}}<br />
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.<br />
{{Flair bottom}}<br />
<br />
== Single-line flairs ==<br />
<br />
<!--<br />
=== Sky divider ===<br />
<br />
<div style="background: linear-gradient(to bottom, #0099cc 0%, #66ccff 100%); height: 15px; width: 95%; margin: 20px auto; border-radius: 6px"></div><br />
--><br />
<br />
=== Small divider ===<br />
<br />
{{Flair|Small divider}}<br />
<br />
=== Rainbow ===<br />
<br />
{{Flair|Rainbow}}</div>Zackhttps://wiki.blognomic.com/index.php?title=Zodiac_Wiki&diff=25637Zodiac Wiki2024-02-27T02:36:44Z<p>Zack: </p>
<hr />
<div>{{gamestate|The Second Dynasty of Rodney}}<br />
<br />
Aries (Fire,Cardinal) -- Saturn(T, Dec. 7)<br />
<br />
Taurus (Earth,Fixed) -- <br />
<br />
Gemini (Air,Mutable) -- <br />
<br />
Cancer (Water,Cardinal) -- <br />
<br />
Leo (Fire,Fixed) -- <br />
<br />
Virgo (Earth,Mutable) -- <br />
<br />
Libra (Air,Cardinal) -- Uranus(G, Dec.12), Mercury(P, Dec. 11)<br />
<br />
Scorpio (Water,Fixed) -- Mars(P, Dec. 6), Jupiter(T, Dec. 10 15:41:00), The Moon's Terrible Core (P, Dec. 9)<br />
<br />
Sagittarius (Fire,Mutable) -- Sun(P, Dec. 9), Pluto(G, Dec. 16)<br />
<br />
Capricorn (Earth,Cardinal) -- <br />
<br />
Aquarius (Air,Fixed) -- <br />
<br />
Pisces (Water,Mutable) -- Eris(G, Dec. 11), Neptune(G, Dec. 15),Venus(P, Dec. 10)<br />
<br />
(Dates and times following identification as P, T, or G indicate when that planet can be moved again.)</div>Zackhttps://wiki.blognomic.com/index.php?title=User:Zack&diff=25636User:Zack2024-02-27T02:33:45Z<p>Zack: Layout and content</p>
<hr />
<div>Hi, I'm Zack (AKA theonlyzac on Discord).<br />
<br />
[https://zacbox.app Zacbox.app]<br />
<br />
== Dynasties ==<br />
<br />
<gallery mode="nolines" widths="400px"><br />
File:Zack1_banner.png|200px|[[The First Dynasty of Zack|The Box Company Dynasty]]<br />
File:Zack2_banner_v2.jpg|400px|[[The Second Dynasty of Zack|The Hacker Dynasty]]<br />
</gallery><br />
<br />
== UserScripts/CSS ==<br />
<br />
* [[User:Zack/Collapsable posts userscript.js|Collapsable posts userscript]] — Auto-collapses posts on the blog's main page<br />
<br />
* [[User:Zack/Custom_blog_styles.css|Custom blog stylesheet]] — Color codes post-titles, changes the font, borders, padding, and other tweaks.<br />
<br />
== My Shortcuts ==<br />
<br />
* [[User:Zack/Sandbox]]<br />
* [[List of Flairs]]<br />
* [[Template:Flair]]</div>Zackhttps://wiki.blognomic.com/index.php?title=The_First_Dynasty_of_Zack&diff=25635The First Dynasty of Zack2024-02-27T02:31:17Z<p>Zack: Add banner image</p>
<hr />
<div>[[File:Zack1_banner.png|right|700px]]<br />
'''16 January - 11 February, 2022'''<br />
<br />
== [https://blognomic.com/archive/boring_box_company Ascension Address] ==<br />
<br />
<blockquote>Welcome to orientation, new recruits! The Boring Box Company™ is excited to see so many fresh faces joining our workforce. Now, I know you’ve all heard the rumors floating around, but our lawyers want me to assure you that everything we do here is strictly above board!<br />
<br />
What? You want to know what happened to the old employees? That’s not important right now. What’s important is getting you trained and ready to start selling boxes!<br />
<br />
Repeal all dynastic rules. Set the wiki page referred to in the rule Dynastic Tracking to Company Portal. Replace GPS with CEO and Tripper with Employee throughout the ruleset. Activate the Special Case Rule “Imperial Differentials”.</blockquote><br />
<br />
==Players==<br />
<br />
At the start of the dynasty, these players were active: {Brendan, Chiiika, Clucky, Josh, Jumble, Kevan, Raven1207, redtara, Silverwing, SupernovaStarbright, Tech, Trapdoorspyder, TyGuy6, Zack}<br />
<br />
And at the end: {ATMunn, Brendan, Clucky, Darknight, Josh, Jumble, lendunistus, Raven1207, SupernovaStarbright, TABBAT, TyGuy6, Zack}<br />
<br />
==Final Ruleset==<br />
<br />
* [[Ruleset 198]]<br />
<br />
==Gamestate==<br />
* [[Company Portal]]<br />
<br />
==Posts of Interest==<br />
<br />
{{to be completed}}<br />
<br />
[https://blognomic.com/archive/orientation1 Orientation] established the core mechanic of Employees belonging to Departments, which were assigned by the CEO. The Departments were Research & Development (RnD), Manufacturing (Mfg), and Sales. It also set up Weekday Actions, which were Daily Actions that could only be done on weekdays.<br />
<br />
[https://blognomic.com/archive/job_description Job Description] added actions for each Department. RnD would research box materials, Manufacturing would make the boxes, and Sales would... you get the idea.<br />
<br />
[https://blognomic.com/archive/flat_structure Flat Structure] assigned everyone a job title, ranking them from Intern to Vice President, with CEO at the top.<br />
<br />
[https://blognomic.com/archive/winklevi Winklevi] added Options, which Employees earned for doing Weekday Actions. Employees could cash in their options to increase their Vested Value by whatever the Company Budget was at the time.<br />
<br />
[https://blognomic.com/archive/options_on_options Options on Options] made it so the number of Options you gained was based on your job title, and made it so employees directly below you in rank got options when you did.<br />
<br />
[https://blognomic.com/archive/bad_customers Bad Customers] made some boxes defective, meaning they couldn't be sold. Some employee(s) in Manufacturing weaponized this to intentionally make defective boxes, thus forcing the CEO to comply with their demands. This backfired when said employee(s) were moved to the Sales department.<br />
<br />
[https://blognomic.com/archive/division_of_labor Division of Labor] added a way for employees to vote on the rank of other employees in their own department through Departmental Proposals. This, unsurprisingly, led to [https://blognomic.com/archive/sales_bros quite] [https://blognomic.com/archive/manufacturing_is_better a] [https://blognomic.com/archive/none_of_you_could_operate_without_rd few] [https://blognomic.com/archive/i_cannot_make_a_coherent_proposal proposals] trying to promote everyone to the rank of CEO, and [https://blognomic.com/archive/and_everything_is_going_fine_2010 one] that tried to make everyone an Intern (including the CEO). These were all vetoed and a [https://blognomic.com/archive/repartmental_fun patch] was made that limited Promotions and Demotions to moving employees up or down only one rank. <br />
<br />
[https://blognomic.com/archive/cash_infusion Cash Infusion] allowed the CEO to take out $100 loans to get the company out of bankruptcy. This was only used a couple times because the earnings gain from researching new materials with the seed money was exponential.<br />
<br />
[https://blognomic.com/archive/finances_and_bureaucracy Finances and Bureaucracy] failed, but it was notable for being the only proposal to try and introduce a fourth department to the company.<br />
<br />
<!--- TODO: More stuff happened here. ---><br />
<br />
[https://blognomic.com/archive/do_over Do Over] added the ability to transfer Options, Vested Value, or BCC Shares between employees.<br />
<br />
[https://blognomic.com/archive/al_in_this_together Al In This Together] added Alan, an NPC controlled by the CEO so he could perform dynastic actions. Due to unforeseen interactions with the Do Over (which was still pending when Alan was booted up), this quickly collapsed the economy since any vested value transferred to Alan immediately went into the Company Budget, meaning players could transfer money to Alan and then cash in their options for exponentially higher and higher gains. Soon, the company budget was in the trillions, and the $25,000 needed to buy BCC shares was pocket change. Everything rapidly came to an end not long after.<br />
<br />
==Ascension==<br />
<br />
Dynasty concluded with a roll-off weighted by how many "Shares of BCC" each player held (SupernovaStarbright = 29, Clucky = 25, TyGuy6 = 20, Brendan = 16, Lendunistus = 15, Jumble = 10, AtMunn = 5, Darknight = 5, Josh = 0, Raven1207 = 0, Tabbat = 0).<br />
<br />
The dice gave victory to Jumble.<br />
<br />
==Commentary==<br />
<br />
The theme was all about work, and a lot of the dynasty revolved around daily actions (though we had weekends off, which was nice). I'm usually quite good at the grind, and I was ahead the whole time until near to the end, when the victory condition was created. But the lead was tough to convert, and finally meant very little as far as winning went. I quite enjoyed the dynasty, all the same. [[User:TyGuy6|TyGuy6]] ([[User talk:TyGuy6|talk]]) 19:32, 11 February 2022 (UTC)<br />
<br />
[https://blognomic.com/archive/a_forgotten_machine Post Dynastic Discussion Thread]<br />
<br />
{{Dynastic Histories}}</div>Zackhttps://wiki.blognomic.com/index.php?title=File:Artboard_1@1x.png&diff=25634File:Artboard 1@1x.png2024-02-27T02:30:31Z<p>Zack: Zack moved page File:Artboard 1@1x.png to File:Zack1 banner.png: Correct name</p>
<hr />
<div>#REDIRECT [[File:Zack1 banner.png]]</div>Zackhttps://wiki.blognomic.com/index.php?title=File:Zack1_banner.png&diff=25633File:Zack1 banner.png2024-02-27T02:30:31Z<p>Zack: Zack moved page File:Artboard 1@1x.png to File:Zack1 banner.png: Correct name</p>
<hr />
<div></div>Zackhttps://wiki.blognomic.com/index.php?title=Agent_Codenames&diff=25632Agent Codenames2024-02-27T02:25:15Z<p>Zack: Tag dynasty</p>
<hr />
<div>{{gamestate|The Seventh Dynasty of Kevan}}<br />
<br />
Here's [[User:Kevan|Kevan]]'s raw and broken data dump, formatted by [[User:Ais523|CallForJudgement]]. The Impostors were Groucho, Harpo and Chico, and Ujalu's Codename was only his Interim one, as he never verified his identity.<br />
<br />
{| border=1 cellpadding=1 cellspacing=1<br />
! Player !! Codename !! Description !! Allegiance !! Location<br />
|-<br />
| Brendan || AIGRETTE || 6&#39;1" American journalist || Soviet || ESUFR<br />
|-<br />
| Lilomar || ALUDEL || 5&#39;9" American Diplomat || US || ESUMI<br />
|-<br />
| Thane Q || BROWBAND || 6&#39;4" British Diplomat || US || WUSNU<br />
|-<br />
| Purplebeard || BUTCHERBIRD || 5&#39;10" American Journalist || US || WUSST<br />
|-<br />
| Blacky || CANZONET || 5&#39;10" West German courier || Independent || WUKCH<br />
|-<br />
| Ienpw III || DUSTCLOTH || 5&#39;4" Russian Academic || Soviet || WFRWE<br />
|-<br />
| Josh || GROGRAM || 6&#39;2" Russian Tourist. || Independent || WFRWE<br />
|-<br />
| Roujo || HARUSPEX || 5&#39;7" French Tourist || Independent || ESULL<br />
|-<br />
| Bucky || HEADSMAN || 5&#39;0" West German diplomat || US || WFRWE<br />
|-<br />
| Undef || JUMBUCK || 6&#39;0" American Banker || Independent || WUSZE<br />
|- <br />
| Harpo || KALEYARD || 6&#39;2" French Tourist || Independent || ESUTW<br />
|- <br />
| Sysiphus || KVASS || 5&#39;8" West German banker || Independent || ESUKP<br />
|- <br />
| Mosby || NONILLION || 5&#39;6" French Banker || Independent || ESUKP<br />
|- <br />
| Darth Cliche || OLEASTER || 6&#39;2" East German diplomat || Soviet || WUKSP<br />
|- <br />
| Ujalu || PERUKE || 6&#39;4" East German banker || || ESUPR<br />
|- <br />
| Anonyman || SKIRL || 5&#39;5" American Journalist || Independent ||<br />
|- <br />
| Chico || VAPORETTO || 5&#39;3" West German Diplomat || US || ESUTW<br />
|- <br />
| FuzzyLogic || VIRGATE || 5&#39;0" East German courier || Independent || ESUHD<br />
|- <br />
| Darknight || WHITLOW || 6&#39;3" American journalist || Soviet || ESUWS<br />
|- <br />
| Groucho || YELLOWTAIL || 5&#39;11" West German Diplomat || Soviet || ESUMI<br />
|}</div>Zackhttps://wiki.blognomic.com/index.php?title=Gartenberg&diff=25547Gartenberg2024-02-18T16:52:00Z<p>Zack: Idle Zack</p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! Vassal !! Defense !! Wood !! Iron !! Stone !! Ore !! Serfs<br />
|-<br />
| Desertfrog || 0 || 2 || 0 || 0 || 1 || 5<br />
|-<br />
| Josh || 0 || 2 || 0 || 0 || 1 || 5<br />
|-<br />
| Vovix || 0 || 1 || 0 || 2 || 0 || 5<br />
|}<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2" style="text-align:center;" | Idle<br />
|-<br />
! Vassal !! Serfs<br />
|}<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2" style="text-align:center;" | Chop<br />
|-<br />
! Vassal !! Serfs<br />
|-<br />
| Desertfrog || 2<br />
|-<br />
| Josh || 2<br />
|-<br />
| Vovix || 1<br />
|}<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2" style="text-align:center;" | Dig<br />
|-<br />
! Vassal !! Serfs<br />
|-<br />
| Vovix || 4<br />
|}<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2" style="text-align:center;" | Mine<br />
|-<br />
! Vassal !! Serfs<br />
|-<br />
| Desertfrog || 3<br />
|-<br />
| Josh || 3<br />
|}<br />
<br />
{| class="wikitable"<br />
|-<br />
! colspan="2" style="text-align:center;" | Smelt<br />
|-<br />
! Vassal !! Serfs<br />
|-<br />
| - || -<br />
|}<br />
<br />
<br />
<!-- Stockpile<br />
| Zack || 0 || 0 || 0 || 0 || 0 || 5<br />
<br />
Serfs<br />
| Zack || 5<br />
--></div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25523The Database2024-02-13T14:47:53Z<p>Zack: Create client Aubergine</p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! Client || Connections || Power<br />
|-<br />
| The Gibson || 1 || 100<br />
|-<br />
| _Mel || 0 || 100<br />
|-<br />
| jumpbox || 0 || 100<br />
|-<br />
| Lilac || 1 || 100<br />
|-<br />
| monkey || 1 || 100<br />
|-<br />
| Dark Web || 3 || -<br />
|-<br />
| ERROR || 1 || 100<br />
|-<br />
| Hal9000 || 1 || 100<br />
|-<br />
| WHOPPER || 1 || 100<br />
|-<br />
| Gooseberry || 1 || 100<br />
|-<br />
| Herodotus || 1 || 100<br />
|- <br />
| EmanuelGoldstein || 1 || 65<br />
|-<br />
| Aubergine || 1 || 50<br />
|}<br />
<br />
There are '''25''' log entries.</div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25520The Database2024-02-13T04:53:10Z<p>Zack: Recharging</p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! Client || Connections || Power<br />
|-<br />
| The Gibson || 1 || 100<br />
|-<br />
| _Mel || 0 || 100<br />
|-<br />
| jumpbox || 0 || 100<br />
|-<br />
| Lilac || 1 || 100<br />
|-<br />
| monkey || 1 || 100<br />
|-<br />
| Dark Web || 3 || -<br />
|-<br />
| ERROR || 1 || 100<br />
|-<br />
| Hal9000 || 1 || 100<br />
|-<br />
| WHOPPER || 1 || 100<br />
|-<br />
| Gooseberry || 1 || 100<br />
|-<br />
| Herodotus || 1 || 100<br />
|- <br />
| EmanuelGoldstein || 1 || 65<br />
|}<br />
<br />
There are '''21''' log entries.</div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=25519Ruleset2024-02-12T17:56:46Z<p>Zack: /* Dynastic Rules */ Remove empty rule</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Agents shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Agent may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[The Database]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Agents ==<br />
A human with access to the blog who is not already an Agent may make a blog post making clear their wish to be an Agent (plural form Agents); in response, an Admin shall add them to the roster in the sidebar, at which moment they become an Agent. (See the [[FAQ#Can_I_join_in.3F|FAQ]] for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
An Agent may only change their name as a result of a Proposal approving the change.<br />
<br />
Some Agents are '''Admins''', responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. Agents may be made Admins through Proposal or CFJ.<br />
<br />
An Agent may cease to be an Agent at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be an Agent in this way may not become an Agent again within the following two weeks.<br />
<br />
===Idle Agents ===<br />
<br />
If an Agent is Idle, this is tracked by their name being removed or concealed in the list of currently active Agents in the Sidebar. For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Agents ”, “Dynasties”, “Fair Play”, "Mentors" and any of those Rules’ subrules, Idle Agents are not counted as Agents . The combined term “Idle Agent” can be used to refer to Agents who are Idle even in rules that do not treat them as Agents.<br />
<br />
If a Proposal contains a provision that targets a specifically named Idle Agent, then that Idle Agent is considered to be Unidle solely for the purposes of enacting that specific provision.<br />
<br />
When an Agent is unidled, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Agent Idled in a different Dynasty), the Agent is given the default value for new Agents, if such a value exists.<br />
<br />
An Admin may render an Agent Idle if that Agent has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Agent has not posted an entry or comment in the past 168 Hours (7 days). In the latter case, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Agent during the current and subsequent dynasty. Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so. An Admin may Unidle an Agent if that Agent is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may Unidle themselves at any time, unless the Agent who would be Unidled has become Idle within the past 96 hours (4 days), and within the current Dynasty.<br />
<br />
Admins who are unidling themselves should, in their first vote following each unidling, highlight their changed idle status and any changes to Quorum to have come about as a result of it.<br />
<br />
Idle admins can resolve Votable Matters as a non-idle admin would.<br />
<br />
===Dormancy===<br />
If there are fewer than four Agents (not including the Mainframe), then BlogNomic is on Hiatus.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Agent, known as the Mainframe. If there is no Mainframe, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before an Ascension Address has been posted. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Agent may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Mainframe is not an Agent.<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Agents may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Agent may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. An Agent's Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Agent never has a Vote, even if they were an Agent previously and had cast a valid Vote.<br />
<br />
If an Agent other than the Mainframe casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Mainframe. When the Mainframe has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Mainframe's Vote for the purposes of other rules unless otherwise specified. When the Mainframe themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Agents who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Agent may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Agent already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When an Agent casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Mainframe may use VETO as a voting icon to cast a Vote on a Proposal; when the Mainframe casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Mainframe later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Agent A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If an Agent (other than the Mainframe) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
An Agent's vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Agent may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, it has been open for at least 12 hours, and either the Mainframe has Voted FOR it or it has no AGAINST Votes.<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, and it has been open for at least 24 hours.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Agent who posted the DoV becomes Mainframe, and the game enters an Interregnum. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Mainframe must either Pass the Mantle (by making a post naming an Agent who was not the last dynasty’s Mainframe, in which case the passing Agent ceases to be the Mainframe and the Agent so named becomes the Mainframe) or start a new dynasty by completing the following Atomic Action:<br />
* Make an Ascension Address by posting an entry in the “Ascension Address” category. This should specify the Mainframe's chosen theme for the new Dynasty, and it may optionally specify new dynasty-specific terms as outline in the rule "Synonyms", and/or list a number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed).<br />
* Optionally specify any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section.<br />
* Update the Ruleset to reflect any changed terms, repeal any dynastic rules which were not listed to be kept, and make any specified or automatic changes to the Building Blocks section of the ruleset. Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Optionally change the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if an Agent's behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Agents should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Agent within BlogNomic, and should announce publicly if they control both a non-Idle Agent and any Idle Agents. This extends to exerting full control over the actions of another Agent, defined here as the controlled Agent's game behavior being functionally indistinguishable from if the controlling Agent was logged into their account and playing through it, over a period of more than a day.<br />
* An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* An Agent should not edit their own blog comments once posted, nor those of any other Agent.<br />
* An Agent should not edit the “Entry Date” field of a blog post.<br />
* An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* An Agent should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. an Agent must use their own name in the Dice Roller, when rolling dice.<br />
* An Agent should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* An Agent should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause an Agent to achieve victory.<br />
* An Agent should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Agent or Agents to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Agents and idle Agents should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Agents are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
<br />
==The Mainframe==<br />
'''The Mainframe''' is a strong AI with advanced natural language capabilities. All dynastic gamestate is secretly tracked by the Mainframe unless otherwise stated, or where it would be impossible. Wherever the Mainframe would refer to an Agent by name in places where gamestate is publicly tracked, the Mainframe should instead use their IP address.<br />
<br />
Communication between Agents that is facilitated by the Mainframe is exempt from the restrictions described in the rule “No Private Communications”.<br />
<br />
== The Agency ==<br />
<br />
The Agency is a darknet organization that rewards cyber operatives for acting in its interests. These operatives are known as Agents. The Mainframe may freely tell an Agent any of their own gamestate variables as defined in this rule and its subrules.<br />
<br />
Each Agent has Warez, which is a list of Files, defaulting to an empty list.<br />
<br />
The Mainframe shall assign each Agent an '''IP address''' in the form #.#.#.# where each # is a number from 1-255. If any Agent has not been assigned an IP, the Mainframe should secretly randomly assign them one before performing any dynastic actions.<br />
<br />
Each Agent has a number named '''CPU Cycles''' which defaults to 1.<br />
<br />
=== Reputation ===<br />
<br />
Each Agent has a reputation score which defaults to 50. A more positive representation represents a higher standing in the eyes of the Agency.<br />
<br />
The following actions impact an Agent’s reputation.<br />
{| class="wikitable sortable"<br />
! Action || Change<br />
|-<br />
| Creating a new Client || +5<br />
|-<br />
| Downloading a file || +5<br />
|-<br />
| Connecting to a Client for the first time || +10<br />
|-<br />
| Self-destructing a Client || -10<br />
|}<br />
<br />
As a Virtual Action, an Agent may spend reputation to redeem one of the following rewards:<br />
{| class="wikitable sortable"<br />
! Cost || Reward<br />
|-<br />
| 2^N || (Where N is the Agent's current CPU cycles) <br/> Increase the Agent's CPU cycles by 1<br />
|-<br />
| 50 || The Mainframe will secretly randomly reassign the Agent a new IP address<br />
|}<br />
<br />
==Clients==<br />
There may be any number of '''Clients'''. Each Client has a unique Name and a Passcode, which are strings of 4-16 characters containing only letters, numbers, and underscores. Names are not case-sensitive but Passcodes are. Client Names and their date of creation are publicly tracked in the Database.<br />
<br />
As a weekly virtual action, an Agent may '''create a new Client''' by specifying the desired Name and Passcode for the Client. This may be re-attempted if the action fails.<br />
<br />
Each Client has a list of Files, defaulting to an empty list.<br />
<br />
A '''Brute Force Attempt''' is a pairing of a number named Progress and the name of an Agent. Each Client has a list of Brute Force Attempts, defaulting to an empty list.<br />
<br />
A '''Passcode Complexity''' is a derived value that equals the number of characters a Client's Passcode has, multiplied by how many of the following criteria (which should be a number from 1 to 3) one or more of its characters meets: lowercase letters, uppercase letters, numbers.<br />
<br />
===Connections===<br />
An Agent may be '''connected''' to any number of Clients. A connection is a relationship between exactly one Agent and one Client. The number of connections a Client has is publicly tracked.<br />
<br />
As a virtual action, an Agent may '''connect to a Client''' by specifying exactly one Client Name and Passcode pair. If the Passcode is correct for the specified Client, the Agent becomes connected to that Client.<br />
<br />
As a virtual action, an Agent may '''disconnect from a Client''' by specifying a client they are connected to, at which point the Agent is no longer connected to that Client.<br />
<br />
===The Dark Web===<br />
There is a Client named Dark Web with the Passcode 1337 and the following Files (whose names are publicly tracked):<br />
<br />
* BackOrifice<br />
* MyDoom<br />
* Pegasus<br />
* CodeRed [Anti-malware]<br />
* CryptoLocker<br />
<br />
The Dark Web may not '''brute force'''.<br />
<br />
As a daily action, the Mainframe should '''refresh the Dark Web''', which is an atomic action with the following steps:<br />
* Remove three privately randomly chosen Files from the Dark Web<br />
* Add three new Files to the Dark Web’s Files and optionally give them any valid unique names<br />
* Privately randomly choose a File of the added Files and make its Program a privately random Program from the table “Programs”<br />
* Privately randomly choose a File of the added Files and make it corrupted by a privately random Malware from the table “Malwares” excluding Trojan horse.<br />
<br />
===Power===<br />
Each client except the Dark Web has '''Power''', which is an integer between 0 and 100 inclusive and defaults to 50. Every time a Client other than the Dark Web performs a successful '''Shell Command''' its Power is reduced by the '''Power Consumption''' of that Shell Command, to a minimum of 0.<br />
<br />
Every night at midnight each Client gains 15 power, to a maximum of 100.<br />
<br />
A Client’s power is publicly tracked.<br />
<br />
==Shell Commands==<br />
A '''Shell Command''' is a type of Virtual Action that the Mainframe performs as a Client on behalf of an Agent. For the purposes of resolving Shell Commands, a Client is considered an Agent; The Client serves as a proxy for the Agent who initiated the command.<br />
<br />
An Agent must be connected to a Client to perform Shell Commands as that Client. ''To perform a Shell Command, you must always specify exactly one Client that you are connected to, or the action fails.'' Each Shell Command has a '''Power Consumption''', which is a non-negative integer and by default 10. If a Client (other than the Dark Web) tries to perform a Shell Command whose Power Consumption is greater than that Client’s Power, it will fail.<br />
<br />
The definition of a Shell Command should be contained within the “Shell command” flair; If one is not, the Mainframe may edit the ruleset to make it so.<br />
<br />
===Logging===<br />
The Mainframe shall maintain a '''log''' of successful Shell Commands. Each new log entry shall include:<br />
* the time/date it occurred<br />
* the IP of the initiating Agent<br />
* the name of the Client<br />
* the type of command<br />
* any other data the command specifies to be logged<br />
<br />
The size of the log (i.e. the total number of log entries) is publicly tracked.<br />
<br />
{{Flair top|Shell command}}<br />
As a shell command, a Client may '''request a copy of logs''' within a particular scope (e.g. a certain timeframe, logs associated with a certain IP, etc). Each log entry will be accompanied by an MD5 hash of the entry by which it can be identified.<br />
<br />
If the Client does not have access to all of the logs in the desired scope, the action will fail. By default, a Client only has access to the logs of actions performed by that particular Client.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Downloading===<br />
{{Flair top|Shell command}}<br />
If a Client has one or more Files, as a Shell Command, that Client may '''download file''' with the name of the File to download. If the File does not already exist in that Agent's Warez, it is added to the Warez of the Agent performing this command, otherwise the command fails. This command may be re-attempted if it failed.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
===Brute Force===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client may brute force a Target, specifying the name of another Client. If the Target does not have a Brute Force Attempt which names the Agent performing the command, the Mainframe will create a new Brute Force Attempt on the Target Client with the Agent’s name and a Progress of 0.<br />
<br />
The Mainframe will increase the Progress of the Agent’s Brute Force Attempt on the Target Client by the Agent’s CPU Cycles.<br />
* If the entry’s Progress is greater than or equal to the Target’s Passcode Complexity, the Mainframe shall secretly communicate the Target’s Passcode to the Agent.<br />
* Otherwise, the Mainframe shall inform the Agent of the current Progress of their Brute Force Attempt on the Target.<br />
<br />
The Mainframe will include the name of the Target and the current Progress of the attempt in the log of the action.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
===Self-destruct===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client other than the Dark Web may '''self-destruct'''. All Agents are disconnected from that Client, and it ceases to exist.<br />
<br />
'''Power Consumption: 0'''<br />
{{Flair bottom}}<br />
<br />
===Ping===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client can '''ping''' the Mainframe. The Mainframe will respond to confirm that it is online.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Change Passcode===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a client may '''change passcode'''. The Client specifies a new valid Passcode and the Client's Passcode is changed to the new value. After this command executes, all Connections to the Client are removed. The Client's Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
==Files==<br />
A '''File''' consists of:<br />
* An unique '''name''', which is a string defaulting to “untitled”. If ever there would be two Files with the same name in the same list as a result of a virtual action, the Mainframe should add an arbitrary number to the end of either File’s name so that the names are unique.<br />
* Optionally one '''Program''' from the table “Programs”<br />
<br />
If a File contains a Program, the Type of the Program must be included in its name in brackets. Only Files with a Program may have brackets in their names, unless otherwise stated by the ruleset.<br />
<br />
{| class="wikitable"<br />
|+ Programs<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Anti-malware || When this File is executed, you may '''scan''' all files in your Warez. The Mainframe will respond with the number of corrupted Files in your Warez plus a privately randomly generated number between -2 and 2, inclusive, to a minimum of zero.<br />
|-<br />
| Firewall || Whenever you '''download''' a File, if the File is '''corrupted''', the Mainframe must privately randomly determine whether the File actually is downloaded or not, with both options being equally likely.<br />
|}<br />
<br />
The Effects of a Program only apply to Agents who have at least one File with that Program in their Warez. As a daily virtual action, an Agent may '''execute''' a File by specifying the name of exactly one File in their Warez. This may be re-attempted if the action fails.<br />
<br />
As a virtual action, an Agent may '''write a program''' by specifying the type of exactly one Program from the table “Programs” and the name of exactly one File in their Warez that doesn’t already have a Program. The Mainframe will set that File’s Program to be the specified Program, adding the Program’s type in brackets to the end of the File’s name.<br />
<br />
===Malware===<br />
An instance of a File in a list may be '''corrupted''' by none or more of the '''Malware''' described in the table below, defaulting to none. Whenever an Agent downloads a corrupted File, the File added to the Agent’s Warez will also be corrupted by the same Malware.<br />
<br />
{| class="wikitable"<br />
|+ Malware<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Virus || Whenever a Client performs a Shell Command, if the initiating Agent's Warez contains a File corrupted by a Virus, the Mainframe must make one of the Client's uncorrupted Files, if there are any, as well as one of the initiating Agent's Warez' uncorrupted Files, if there are any, corrupted by a Virus.<br />
|-<br />
| Trojan horse || If a file is corrupted by a Trojan horse, its name is allowed to contain brackets. However, such a File may not contain a Program.<br />
|}<br />
<br />
==Blackout==<br />
An Agent who is connected to all existing Clients may, as a virtual action, trigger a blackout. A blackout uses the remaining power of all Clients to send an electromagnetic pulse to the Mainframe, knocking it and all Clients offline. This effectively puts an end to the Agency’s operations.<br />
<br />
The Mainframe will make a Story Post on the blog naming the Agent who triggered the blackout; The agent so named has achieved victory.<br />
<br />
==Short Circuit==<br />
Throughout this rule, all uses of the terms “JonathanDark”, “Josh”, or “Vovix” should be taken to refer to the Agents with those names.<br />
<br />
On or after February 12 2024 00:00 UTC, the Mainframe should publicly randomly roll DICEX, where X is the sum of the Reputation of JonathanDark, Josh and Vovix, at the exact time of February 12 2024 00:00 UTC. The Mainframe should then use the result of this random roll, known as R, to determine which Agent achieves victory and post a Story Post declaring this fact using the following steps, where there is a number named RunningTotal which is set to 0 before starting these steps:<br />
<br />
* If R is less than or equal to JonathanDark’s Reputation, then JonathanDark achieves victory, and the remaining steps must be skipped. Otherwise, add JonathanDark’s Reputation to RunningTotal.<br />
* If R is greater than RunningTotal and less than or equal to (Josh’s Reputation + RunningTotal), then Josh achieves victory, and the remaining steps must be skipped. Otherwise, add Josh’s Reputation to RunningTotal.<br />
* If R is greater than RunningTotal, then Vovix achieves victory.<br />
<br />
==Clock Cycle==<br />
As a daily action, the Mainframe should perform the following atomic action called Clock Cycle:<br />
* Resolve all Shell Commands initiated since the last clock cycle.<br />
* Post a newsletter on the blog.<br />
<br />
===Newsletter===<br />
A ‘’‘newsletter” is a story post by the Mainframe whose title is in the format “Newsletter<br />
<br />
“. A newsletter post always contains:<br />
* A ranked list of Agents, sorted by reputation (not including the reputation itself)<br />
* A list of new clients created since the last clock cycle.<br />
* The number of shell commands resolved in the last clock cycle.<br />
<br />
The remaining contents of the newsletter are flavour text.<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page is gamestate and may not be altered except as specified by the ruleset or through the passage of a Proposal or CfJ; however, its contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Mainframe specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset; these rules must then be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Mainframe makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected. There are currently no Recommended Building Blocks.<br />
<br />
==No Private Communication==<br />
Agents may not privately communicate with each other about dynastic gameplay or votable matters that affect the dynastic ruleset or gamestate. Private communications are considered to be anything that any other Agent could not reasonably be privy to, perceive, or understand. Discussion conducted in plain English on the BlogNomic wiki and blog, and the #current-dynasty, #blognomic-general and #new-player-questions-and-mentorships Discord channels, are not considered to be private communication. Idle Agents (or people who are not yet Agents) also face the same restrictions if they intend to become an active Agent during the course of the dynasty. The use of creative strategies to circumvent this rule may be considered to be a scam for the purposes of determining whether an infraction of Fair Play has taken place.<br />
<br />
A mentor and mentee may still privately converse with each other, but should keep their conversations away from discussing specific gameplay strategy. This rule’s restrictions on communication do not apply during an Interregnum. The restrictions in this rule on communication in non-blognomic-related media shall not be construed as to cause those media to be gamestate.<br />
<br />
If information which was not allowed to be discussed is still privately discussed, the Agents who were part of the conversation should make a post to the blog disclosing what information was discussed as their earliest convenience.<br />
<br />
==Virtual Actions==<br />
A Virtual Action is a type of action that the Mainframe performs on behalf of an Agent. An Agent may initiate a virtual action by privately communicating to the Mainframe their request to do so, along with any additional information needed to carry it out. The Mainframe shall resolve the Virtual Action by performing the following Atomic Action:<br />
# Determine whether the Virtual Action fails (if it does not fail, it is successful).<br />
# If the action is successful, apply any specified effects on the gamestate and/or perform any specified actions on behalf of the Agent.<br />
<br />
If a Virtual Action fails, the Mainframe should tell the Agent why. A virtual action may fail for any of these reasons:<br />
* Some requirements/prerequisites to perform the action are not met.<br />
* The request does not contain all the information needed to resolve the action.<br />
* The request is unintelligible, or too vague to interpret unambiguously.<br />
* It would require the Mainframe to do something they cannot do.<br />
* Any other reason specified by the action itself.<br />
<br />
Except where otherwise stated by the ruleset, the Mainframe must resolve all virtual actions in the order that they are received. A virtual action is considered to have occurred at the time it was resolved.<br />
<br />
Until a virtual action is resolved, it is pending. An Agent may cancel a pending Virtual Action by privately communicating to the Mainframe their request to do so<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Agent per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Agent per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Agents.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Effective Vote Comment (EVC): An Agent's Effective Vote Comment with respect to a given Votable Matter is that Agent's Comment to that Votable Matter, if any, that contains that Agent's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Agents , as well as people who are not Agents but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Agents who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Agents are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the Dynastic Rules explicitly mention (except for dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Pass the Mantle: Passing the Mantle is a mechanism by which, during an Interregnum, a Mainframe may nominate another Agent to become the Mainframe in the upcoming dynasty. Unless a Core, Dynastic or Building Block rule explicitly states otherwise, Passing the Mantle is currently prohibited.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Mainframe.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Agents” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To Uphold an illegal action is to retroactively declare the attempt to take it to have been successful, and to declare that all attempted game actions taken after it were attempted as if the Upheld action had been successful.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Agent may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may be altered by its author if it is less than 4 hours old and either no Agent has commented on it or (if it is a Votable Matter) if all comments on it contain no voting icons; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Mainframe to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Mainframe may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of an Agent’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Agent may correct the representations to comply with the Gamestate.<br />
<br />
If an Agent feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Agent, if doing so would not require the correcting Agent to make any decisions on behalf of the original Agent.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Agents are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
An Agent may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name an Agent with such access. Only an Agent with such access may Enact that Votable Matter. If that Votable Matter does not name an Agent with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Agent making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Agent making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When an Agent performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete.<br />
* If a rule allows the Agent performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If an Agent arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Agent must redo the Atomic Action; for that purpose, the Agent uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Agent would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, an Agent can spend or pay from only their own values, and a rule that allows Agents to transfer or pay a numeric value to another Agent only allows them to transfer that value from themselves to that other Agent (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Agents are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Mainframe (including secretly random selections), then that information may only be revealed by the Mainframe when the ruleset allows it. If an Agent should already know such a piece of information (in that the Mainframe has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Mainframe may repeat it to them.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Agent may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Agents may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Mainframe has voted DEFERENTIAL on a Proposal, that vote is instead considered to be valid and either FOR (if more Agents have a valid FOR vote on that Proposal than have a valid AGAINST vote on it) or AGAINST (in all other cases). However, in either case, votes of DEFERENTIAL made by other Agents on the same Proposal are not considered to be valid. If there are six or fewer Agents, then the Mainframe’s vote of DEFERENTIAL on a proposal is only affected by this rule if all Agents who are not the Mainframe have cast a vote on that proposal.<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* An Agent may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Agents may correct obvious spelling, punctuation, and/or typographical mistakes in the Ruleset and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Agents with the corresponding forms of the singular “they”.<br />
* An Agent may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, an Agent's (or prospective Agent's ) new name must be between 4 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Agents may Kick each other” and “Agents may not Kick each other on Tuesdays” exist, and it is Tuesday, Agents may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Agents may Punch a Spaceman on Friday” and “Agents may not Punch Spacemen on Friday”, then Agents may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
An Agent may have another Agent as a Mentor. Agents who are willing to act as a Mentor are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of an Agent who has requested a change on their own behalf, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Agent requests a Mentor, or a new Agent has joined the game and has no Mentor, the Mainframe should select a Tenured Agent and ask them to take that Agent on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Mainframe should announce it in a blog post. The Mainframe should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. An Agent may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Mainframe, any Agent who has been active in at least three previous dynasties may act as Mainframe for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Agent or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Agents .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Agent” and “Mainframe”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Agent (Player)<br />
* Mainframe (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25518The Database2024-02-12T13:45:44Z<p>Zack: Create client EmanuelGoldstein</p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! Client || Connections || Power<br />
|-<br />
| The Gibson || 1 || 100<br />
|-<br />
| _Mel || 0 || 100<br />
|-<br />
| jumpbox || 0 || 100<br />
|-<br />
| Lilac || 1 || 100<br />
|-<br />
| monkey || 1 || 100<br />
|-<br />
| Dark Web || 3 || -<br />
|-<br />
| ERROR || 1 || 100<br />
|-<br />
| Hal9000 || 1 || 100<br />
|-<br />
| WHOPPER || 1 || 95<br />
|-<br />
| Gooseberry || 1 || 95<br />
|-<br />
| Herodotus || 1 || 95<br />
|- <br />
| EmanuelGoldstein || 1 || 50<br />
|}<br />
<br />
There are '''21''' log entries.</div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=25517Ruleset2024-02-12T00:14:33Z<p>Zack: /* The Dark Web */ Refresh dark web</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Agents shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Agent may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[The Database]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Agents ==<br />
A human with access to the blog who is not already an Agent may make a blog post making clear their wish to be an Agent (plural form Agents); in response, an Admin shall add them to the roster in the sidebar, at which moment they become an Agent. (See the [[FAQ#Can_I_join_in.3F|FAQ]] for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
An Agent may only change their name as a result of a Proposal approving the change.<br />
<br />
Some Agents are '''Admins''', responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. Agents may be made Admins through Proposal or CFJ.<br />
<br />
An Agent may cease to be an Agent at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be an Agent in this way may not become an Agent again within the following two weeks.<br />
<br />
===Idle Agents ===<br />
<br />
If an Agent is Idle, this is tracked by their name being removed or concealed in the list of currently active Agents in the Sidebar. For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Agents ”, “Dynasties”, “Fair Play”, "Mentors" and any of those Rules’ subrules, Idle Agents are not counted as Agents . The combined term “Idle Agent” can be used to refer to Agents who are Idle even in rules that do not treat them as Agents.<br />
<br />
If a Proposal contains a provision that targets a specifically named Idle Agent, then that Idle Agent is considered to be Unidle solely for the purposes of enacting that specific provision.<br />
<br />
When an Agent is unidled, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Agent Idled in a different Dynasty), the Agent is given the default value for new Agents, if such a value exists.<br />
<br />
An Admin may render an Agent Idle if that Agent has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Agent has not posted an entry or comment in the past 168 Hours (7 days). In the latter case, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Agent during the current and subsequent dynasty. Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so. An Admin may Unidle an Agent if that Agent is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may Unidle themselves at any time, unless the Agent who would be Unidled has become Idle within the past 96 hours (4 days), and within the current Dynasty.<br />
<br />
Admins who are unidling themselves should, in their first vote following each unidling, highlight their changed idle status and any changes to Quorum to have come about as a result of it.<br />
<br />
Idle admins can resolve Votable Matters as a non-idle admin would.<br />
<br />
===Dormancy===<br />
If there are fewer than four Agents (not including the Mainframe), then BlogNomic is on Hiatus.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Agent, known as the Mainframe. If there is no Mainframe, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before an Ascension Address has been posted. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Agent may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Mainframe is not an Agent.<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Agents may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Agent may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. An Agent's Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Agent never has a Vote, even if they were an Agent previously and had cast a valid Vote.<br />
<br />
If an Agent other than the Mainframe casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Mainframe. When the Mainframe has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Mainframe's Vote for the purposes of other rules unless otherwise specified. When the Mainframe themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Agents who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Agent may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Agent already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When an Agent casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Mainframe may use VETO as a voting icon to cast a Vote on a Proposal; when the Mainframe casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Mainframe later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Agent A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If an Agent (other than the Mainframe) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
An Agent's vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Agent may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, it has been open for at least 12 hours, and either the Mainframe has Voted FOR it or it has no AGAINST Votes.<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, and it has been open for at least 24 hours.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Agent who posted the DoV becomes Mainframe, and the game enters an Interregnum. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Mainframe must either Pass the Mantle (by making a post naming an Agent who was not the last dynasty’s Mainframe, in which case the passing Agent ceases to be the Mainframe and the Agent so named becomes the Mainframe) or start a new dynasty by completing the following Atomic Action:<br />
* Make an Ascension Address by posting an entry in the “Ascension Address” category. This should specify the Mainframe's chosen theme for the new Dynasty, and it may optionally specify new dynasty-specific terms as outline in the rule "Synonyms", and/or list a number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed).<br />
* Optionally specify any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section.<br />
* Update the Ruleset to reflect any changed terms, repeal any dynastic rules which were not listed to be kept, and make any specified or automatic changes to the Building Blocks section of the ruleset. Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Optionally change the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if an Agent's behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Agents should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Agent within BlogNomic, and should announce publicly if they control both a non-Idle Agent and any Idle Agents. This extends to exerting full control over the actions of another Agent, defined here as the controlled Agent's game behavior being functionally indistinguishable from if the controlling Agent was logged into their account and playing through it, over a period of more than a day.<br />
* An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* An Agent should not edit their own blog comments once posted, nor those of any other Agent.<br />
* An Agent should not edit the “Entry Date” field of a blog post.<br />
* An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* An Agent should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. an Agent must use their own name in the Dice Roller, when rolling dice.<br />
* An Agent should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* An Agent should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause an Agent to achieve victory.<br />
* An Agent should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Agent or Agents to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Agents and idle Agents should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Agents are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
<br />
==The Mainframe==<br />
'''The Mainframe''' is a strong AI with advanced natural language capabilities. All dynastic gamestate is secretly tracked by the Mainframe unless otherwise stated, or where it would be impossible. Wherever the Mainframe would refer to an Agent by name in places where gamestate is publicly tracked, the Mainframe should instead use their IP address.<br />
<br />
Communication between Agents that is facilitated by the Mainframe is exempt from the restrictions described in the rule “No Private Communications”.<br />
<br />
== The Agency ==<br />
<br />
The Agency is a darknet organization that rewards cyber operatives for acting in its interests. These operatives are known as Agents. The Mainframe may freely tell an Agent any of their own gamestate variables as defined in this rule and its subrules.<br />
<br />
Each Agent has Warez, which is a list of Files, defaulting to an empty list.<br />
<br />
The Mainframe shall assign each Agent an '''IP address''' in the form #.#.#.# where each # is a number from 1-255. If any Agent has not been assigned an IP, the Mainframe should secretly randomly assign them one before performing any dynastic actions.<br />
<br />
Each Agent has a number named '''CPU Cycles''' which defaults to 1.<br />
<br />
=== Reputation ===<br />
<br />
Each Agent has a reputation score which defaults to 50. A more positive representation represents a higher standing in the eyes of the Agency.<br />
<br />
The following actions impact an Agent’s reputation.<br />
{| class="wikitable sortable"<br />
! Action || Change<br />
|-<br />
| Creating a new Client || +5<br />
|-<br />
| Downloading a file || +5<br />
|-<br />
| Connecting to a Client for the first time || +10<br />
|-<br />
| Self-destructing a Client || -10<br />
|}<br />
<br />
As a Virtual Action, an Agent may spend reputation to redeem one of the following rewards:<br />
{| class="wikitable sortable"<br />
! Cost || Reward<br />
|-<br />
| 2^N || (Where N is the Agent's current CPU cycles) <br/> Increase the Agent's CPU cycles by 1<br />
|-<br />
| 50 || The Mainframe will secretly randomly reassign the Agent a new IP address<br />
|}<br />
<br />
==Clients==<br />
There may be any number of '''Clients'''. Each Client has a unique Name and a Passcode, which are strings of 4-16 characters containing only letters, numbers, and underscores. Names are not case-sensitive but Passcodes are. Client Names and their date of creation are publicly tracked in the Database.<br />
<br />
As a weekly virtual action, an Agent may '''create a new Client''' by specifying the desired Name and Passcode for the Client. This may be re-attempted if the action fails.<br />
<br />
Each Client has a list of Files, defaulting to an empty list.<br />
<br />
A '''Brute Force Attempt''' is a pairing of a number named Progress and the name of an Agent. Each Client has a list of Brute Force Attempts, defaulting to an empty list.<br />
<br />
A '''Passcode Complexity''' is a derived value that equals the number of characters a Client's Passcode has, multiplied by how many of the following criteria (which should be a number from 1 to 3) one or more of its characters meets: lowercase letters, uppercase letters, numbers.<br />
<br />
===Connections===<br />
An Agent may be '''connected''' to any number of Clients. A connection is a relationship between exactly one Agent and one Client. The number of connections a Client has is publicly tracked.<br />
<br />
As a virtual action, an Agent may '''connect to a Client''' by specifying exactly one Client Name and Passcode pair. If the Passcode is correct for the specified Client, the Agent becomes connected to that Client.<br />
<br />
As a virtual action, an Agent may '''disconnect from a Client''' by specifying a client they are connected to, at which point the Agent is no longer connected to that Client.<br />
<br />
===The Dark Web===<br />
There is a Client named Dark Web with the Passcode 1337 and the following Files (whose names are publicly tracked):<br />
<br />
* BackOrifice<br />
* MyDoom<br />
* Pegasus<br />
* CodeRed [Anti-malware]<br />
* CryptoLocker<br />
<br />
The Dark Web may not '''brute force'''.<br />
<br />
As a daily action, the Mainframe should '''refresh the Dark Web''', which is an atomic action with the following steps:<br />
* Remove three privately randomly chosen Files from the Dark Web<br />
* Add three new Files to the Dark Web’s Files and optionally give them any valid unique names<br />
* Privately randomly choose a File of the added Files and make its Program a privately random Program from the table “Programs”<br />
* Privately randomly choose a File of the added Files and make it corrupted by a privately random Malware from the table “Malwares” excluding Trojan horse.<br />
<br />
===Power===<br />
Each client except the Dark Web has '''Power''', which is an integer between 0 and 100 inclusive and defaults to 50. Every time a Client other than the Dark Web performs a successful '''Shell Command''' its Power is reduced by the '''Power Consumption''' of that Shell Command, to a minimum of 0.<br />
<br />
Every night at midnight each Client gains 15 power, to a maximum of 100.<br />
<br />
A Client’s power is publicly tracked.<br />
<br />
==Shell Commands==<br />
A '''Shell Command''' is a type of Virtual Action that the Mainframe performs as a Client on behalf of an Agent. For the purposes of resolving Shell Commands, a Client is considered an Agent; The Client serves as a proxy for the Agent who initiated the command.<br />
<br />
An Agent must be connected to a Client to perform Shell Commands as that Client. ''To perform a Shell Command, you must always specify exactly one Client that you are connected to, or the action fails.'' Each Shell Command has a '''Power Consumption''', which is a non-negative integer and by default 10. If a Client (other than the Dark Web) tries to perform a Shell Command whose Power Consumption is greater than that Client’s Power, it will fail.<br />
<br />
The definition of a Shell Command should be contained within the “Shell command” flair; If one is not, the Mainframe may edit the ruleset to make it so.<br />
<br />
===Logging===<br />
The Mainframe shall maintain a '''log''' of successful Shell Commands. Each new log entry shall include:<br />
* the time/date it occurred<br />
* the IP of the initiating Agent<br />
* the name of the Client<br />
* the type of command<br />
* any other data the command specifies to be logged<br />
<br />
The size of the log (i.e. the total number of log entries) is publicly tracked.<br />
<br />
{{Flair top|Shell command}}<br />
As a shell command, a Client may '''request a copy of logs''' within a particular scope (e.g. a certain timeframe, logs associated with a certain IP, etc). Each log entry will be accompanied by an MD5 hash of the entry by which it can be identified.<br />
<br />
If the Client does not have access to all of the logs in the desired scope, the action will fail. By default, a Client only has access to the logs of actions performed by that particular Client.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Downloading===<br />
{{Flair top|Shell command}}<br />
If a Client has one or more Files, as a Shell Command, that Client may '''download file''' with the name of the File to download. If the File does not already exist in that Agent's Warez, it is added to the Warez of the Agent performing this command, otherwise the command fails. This command may be re-attempted if it failed.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
===Brute Force===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client may brute force a Target, specifying the name of another Client. If the Target does not have a Brute Force Attempt which names the Agent performing the command, the Mainframe will create a new Brute Force Attempt on the Target Client with the Agent’s name and a Progress of 0.<br />
<br />
The Mainframe will increase the Progress of the Agent’s Brute Force Attempt on the Target Client by the Agent’s CPU Cycles.<br />
* If the entry’s Progress is greater than or equal to the Target’s Passcode Complexity, the Mainframe shall secretly communicate the Target’s Passcode to the Agent.<br />
* Otherwise, the Mainframe shall inform the Agent of the current Progress of their Brute Force Attempt on the Target.<br />
<br />
The Mainframe will include the name of the Target and the current Progress of the attempt in the log of the action.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
===Self-destruct===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client other than the Dark Web may '''self-destruct'''. All Agents are disconnected from that Client, and it ceases to exist.<br />
<br />
'''Power Consumption: 0'''<br />
{{Flair bottom}}<br />
<br />
===Ping===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client can '''ping''' the Mainframe. The Mainframe will respond to confirm that it is online.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Change Passcode===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a client may '''change passcode'''. The Client specifies a new valid Passcode and the Client's Passcode is changed to the new value. After this command executes, all Connections to the Client are removed. The Client's Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
==Best Practices==<br />
<br />
==Files==<br />
A '''File''' consists of:<br />
* An unique '''name''', which is a string defaulting to “untitled”. If ever there would be two Files with the same name in the same list as a result of a virtual action, the Mainframe should add an arbitrary number to the end of either File’s name so that the names are unique.<br />
* Optionally one '''Program''' from the table “Programs”<br />
<br />
If a File contains a Program, the Type of the Program must be included in its name in brackets. Only Files with a Program may have brackets in their names, unless otherwise stated by the ruleset.<br />
<br />
{| class="wikitable"<br />
|+ Programs<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Anti-malware || When this File is executed, you may '''scan''' all files in your Warez. The Mainframe will respond with the number of corrupted Files in your Warez plus a privately randomly generated number between -2 and 2, inclusive, to a minimum of zero.<br />
|-<br />
| Firewall || Whenever you '''download''' a File, if the File is '''corrupted''', the Mainframe must privately randomly determine whether the File actually is downloaded or not, with both options being equally likely.<br />
|}<br />
<br />
The Effects of a Program only apply to Agents who have at least one File with that Program in their Warez. As a daily virtual action, an Agent may '''execute''' a File by specifying the name of exactly one File in their Warez. This may be re-attempted if the action fails.<br />
<br />
As a virtual action, an Agent may '''write a program''' by specifying the type of exactly one Program from the table “Programs” and the name of exactly one File in their Warez that doesn’t already have a Program. The Mainframe will set that File’s Program to be the specified Program, adding the Program’s type in brackets to the end of the File’s name.<br />
<br />
===Malware===<br />
An instance of a File in a list may be '''corrupted''' by none or more of the '''Malware''' described in the table below, defaulting to none. Whenever an Agent downloads a corrupted File, the File added to the Agent’s Warez will also be corrupted by the same Malware.<br />
<br />
{| class="wikitable"<br />
|+ Malware<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Virus || Whenever a Client performs a Shell Command, if the initiating Agent's Warez contains a File corrupted by a Virus, the Mainframe must make one of the Client's uncorrupted Files, if there are any, as well as one of the initiating Agent's Warez' uncorrupted Files, if there are any, corrupted by a Virus.<br />
|-<br />
| Trojan horse || If a file is corrupted by a Trojan horse, its name is allowed to contain brackets. However, such a File may not contain a Program.<br />
|}<br />
<br />
==Blackout==<br />
An Agent who is connected to all existing Clients may, as a virtual action, trigger a blackout. A blackout uses the remaining power of all Clients to send an electromagnetic pulse to the Mainframe, knocking it and all Clients offline. This effectively puts an end to the Agency’s operations.<br />
<br />
The Mainframe will make a Story Post on the blog naming the Agent who triggered the blackout; The agent so named has achieved victory.<br />
<br />
==Short Circuit==<br />
Throughout this rule, all uses of the terms “JonathanDark”, “Josh”, or “Vovix” should be taken to refer to the Agents with those names.<br />
<br />
On or after February 12 2024 00:00 UTC, the Mainframe should publicly randomly roll DICEX, where X is the sum of the Reputation of JonathanDark, Josh and Vovix, at the exact time of February 12 2024 00:00 UTC. The Mainframe should then use the result of this random roll, known as R, to determine which Agent achieves victory and post a Story Post declaring this fact using the following steps, where there is a number named RunningTotal which is set to 0 before starting these steps:<br />
<br />
* If R is less than or equal to JonathanDark’s Reputation, then JonathanDark achieves victory, and the remaining steps must be skipped. Otherwise, add JonathanDark’s Reputation to RunningTotal.<br />
* If R is greater than RunningTotal and less than or equal to (Josh’s Reputation + RunningTotal), then Josh achieves victory, and the remaining steps must be skipped. Otherwise, add Josh’s Reputation to RunningTotal.<br />
* If R is greater than RunningTotal, then Vovix achieves victory.<br />
<br />
==Clock Cycle==<br />
As a daily action, the Mainframe should perform the following atomic action called Clock Cycle:<br />
* Resolve all Shell Commands initiated since the last clock cycle.<br />
* Post a newsletter on the blog.<br />
<br />
===Newsletter===<br />
A ‘’‘newsletter” is a story post by the Mainframe whose title is in the format “Newsletter<br />
<br />
“. A newsletter post always contains:<br />
* A ranked list of Agents, sorted by reputation (not including the reputation itself)<br />
* A list of new clients created since the last clock cycle.<br />
* The number of shell commands resolved in the last clock cycle.<br />
<br />
The remaining contents of the newsletter are flavour text.<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page is gamestate and may not be altered except as specified by the ruleset or through the passage of a Proposal or CfJ; however, its contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Mainframe specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset; these rules must then be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Mainframe makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected. There are currently no Recommended Building Blocks.<br />
<br />
==No Private Communication==<br />
Agents may not privately communicate with each other about dynastic gameplay or votable matters that affect the dynastic ruleset or gamestate. Private communications are considered to be anything that any other Agent could not reasonably be privy to, perceive, or understand. Discussion conducted in plain English on the BlogNomic wiki and blog, and the #current-dynasty, #blognomic-general and #new-player-questions-and-mentorships Discord channels, are not considered to be private communication. Idle Agents (or people who are not yet Agents) also face the same restrictions if they intend to become an active Agent during the course of the dynasty. The use of creative strategies to circumvent this rule may be considered to be a scam for the purposes of determining whether an infraction of Fair Play has taken place.<br />
<br />
A mentor and mentee may still privately converse with each other, but should keep their conversations away from discussing specific gameplay strategy. This rule’s restrictions on communication do not apply during an Interregnum. The restrictions in this rule on communication in non-blognomic-related media shall not be construed as to cause those media to be gamestate.<br />
<br />
If information which was not allowed to be discussed is still privately discussed, the Agents who were part of the conversation should make a post to the blog disclosing what information was discussed as their earliest convenience.<br />
<br />
==Virtual Actions==<br />
A Virtual Action is a type of action that the Mainframe performs on behalf of an Agent. An Agent may initiate a virtual action by privately communicating to the Mainframe their request to do so, along with any additional information needed to carry it out. The Mainframe shall resolve the Virtual Action by performing the following Atomic Action:<br />
# Determine whether the Virtual Action fails (if it does not fail, it is successful).<br />
# If the action is successful, apply any specified effects on the gamestate and/or perform any specified actions on behalf of the Agent.<br />
<br />
If a Virtual Action fails, the Mainframe should tell the Agent why. A virtual action may fail for any of these reasons:<br />
* Some requirements/prerequisites to perform the action are not met.<br />
* The request does not contain all the information needed to resolve the action.<br />
* The request is unintelligible, or too vague to interpret unambiguously.<br />
* It would require the Mainframe to do something they cannot do.<br />
* Any other reason specified by the action itself.<br />
<br />
Except where otherwise stated by the ruleset, the Mainframe must resolve all virtual actions in the order that they are received. A virtual action is considered to have occurred at the time it was resolved.<br />
<br />
Until a virtual action is resolved, it is pending. An Agent may cancel a pending Virtual Action by privately communicating to the Mainframe their request to do so<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Agent per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Agent per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Agents.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Effective Vote Comment (EVC): An Agent's Effective Vote Comment with respect to a given Votable Matter is that Agent's Comment to that Votable Matter, if any, that contains that Agent's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Agents , as well as people who are not Agents but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Agents who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Agents are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the Dynastic Rules explicitly mention (except for dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Pass the Mantle: Passing the Mantle is a mechanism by which, during an Interregnum, a Mainframe may nominate another Agent to become the Mainframe in the upcoming dynasty. Unless a Core, Dynastic or Building Block rule explicitly states otherwise, Passing the Mantle is currently prohibited.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Mainframe.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Agents” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To Uphold an illegal action is to retroactively declare the attempt to take it to have been successful, and to declare that all attempted game actions taken after it were attempted as if the Upheld action had been successful.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Agent may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may be altered by its author if it is less than 4 hours old and either no Agent has commented on it or (if it is a Votable Matter) if all comments on it contain no voting icons; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Mainframe to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Mainframe may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of an Agent’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Agent may correct the representations to comply with the Gamestate.<br />
<br />
If an Agent feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Agent, if doing so would not require the correcting Agent to make any decisions on behalf of the original Agent.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Agents are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
An Agent may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name an Agent with such access. Only an Agent with such access may Enact that Votable Matter. If that Votable Matter does not name an Agent with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Agent making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Agent making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When an Agent performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete.<br />
* If a rule allows the Agent performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If an Agent arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Agent must redo the Atomic Action; for that purpose, the Agent uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Agent would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, an Agent can spend or pay from only their own values, and a rule that allows Agents to transfer or pay a numeric value to another Agent only allows them to transfer that value from themselves to that other Agent (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Agents are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Mainframe (including secretly random selections), then that information may only be revealed by the Mainframe when the ruleset allows it. If an Agent should already know such a piece of information (in that the Mainframe has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Mainframe may repeat it to them.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Agent may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Agents may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Mainframe has voted DEFERENTIAL on a Proposal, that vote is instead considered to be valid and either FOR (if more Agents have a valid FOR vote on that Proposal than have a valid AGAINST vote on it) or AGAINST (in all other cases). However, in either case, votes of DEFERENTIAL made by other Agents on the same Proposal are not considered to be valid. If there are six or fewer Agents, then the Mainframe’s vote of DEFERENTIAL on a proposal is only affected by this rule if all Agents who are not the Mainframe have cast a vote on that proposal.<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* An Agent may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Agents may correct obvious spelling, punctuation, and/or typographical mistakes in the Ruleset and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Agents with the corresponding forms of the singular “they”.<br />
* An Agent may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, an Agent's (or prospective Agent's ) new name must be between 4 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Agents may Kick each other” and “Agents may not Kick each other on Tuesdays” exist, and it is Tuesday, Agents may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Agents may Punch a Spaceman on Friday” and “Agents may not Punch Spacemen on Friday”, then Agents may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
An Agent may have another Agent as a Mentor. Agents who are willing to act as a Mentor are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of an Agent who has requested a change on their own behalf, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Agent requests a Mentor, or a new Agent has joined the game and has no Mentor, the Mainframe should select a Tenured Agent and ask them to take that Agent on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Mainframe should announce it in a blog post. The Mainframe should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. An Agent may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Mainframe, any Agent who has been active in at least three previous dynasties may act as Mainframe for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Agent or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Agents .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Agent” and “Mainframe”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Agent (Player)<br />
* Mainframe (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25516The Database2024-02-12T00:11:42Z<p>Zack: Add publicly tracked values</p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! Client || Connections || Power<br />
|-<br />
| The Gibson || 1 || 100<br />
|-<br />
| _Mel || 0 || 100<br />
|-<br />
| jumpbox || 0 || 100<br />
|-<br />
| Lilac || 1 || 100<br />
|-<br />
| monkey || 1 || 100<br />
|-<br />
| Dark Web || 3 || -<br />
|-<br />
| ERROR || 1 || 100<br />
|-<br />
| Hal9000 || 1 || 100<br />
|-<br />
| WHOPPER || 1 || 95<br />
|-<br />
| Gooseberry || 1 || 95<br />
|-<br />
| Herodotus || 1 || 95<br />
|}<br />
<br />
There are '''21''' log entries.</div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25511The Database2024-02-09T14:09:35Z<p>Zack: New client</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Client Names<br />
|-<br />
| The Gibson<br />
|-<br />
| _Mel<br />
|-<br />
| jumpbox<br />
|-<br />
| Lilac<br />
|-<br />
| monkey<br />
|-<br />
| Dark Web<br />
|-<br />
| ERROR<br />
|-<br />
| Hal9000<br />
|-<br />
| WHOPPER<br />
|-<br />
| Gooseberry<br />
|-<br />
| Herodotus<br />
|}</div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25510The Database2024-02-09T14:02:40Z<p>Zack: New client</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Client Names<br />
|-<br />
| The Gibson<br />
|-<br />
| _Mel<br />
|-<br />
| jumpbox<br />
|-<br />
| Lilac<br />
|-<br />
| monkey<br />
|-<br />
| Dark Web<br />
|-<br />
| ERROR<br />
|-<br />
| Hal9000<br />
|-<br />
| WHOPPER<br />
|-<br />
| Gooseberry<br />
|}</div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25509The Database2024-02-09T13:50:48Z<p>Zack: New client</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Client Names<br />
|-<br />
| The Gibson<br />
|-<br />
| _Mel<br />
|-<br />
| jumpbox<br />
|-<br />
| Lilac<br />
|-<br />
| monkey<br />
|-<br />
| Dark Web<br />
|-<br />
| ERROR<br />
|-<br />
| Hal9000<br />
|-<br />
| WHOPPER<br />
|}</div>Zackhttps://wiki.blognomic.com/index.php?title=User:Zack&diff=25507User:Zack2024-02-05T22:08:58Z<p>Zack: Add quick links</p>
<hr />
<div>Hi, I'm Zack, or TheOnlyZac#0269 on Discord. Here are some helpful links.<br />
<br />
* [[User:Zack/Collapsable posts userscript.js|Collapsable posts userscript]] — Auto-collapses posts on the blog's main page<br />
<br />
* [[User:Zack/Custom_blog_styles.css|Custom blog stylesheet]] — Color codes post-titles, changes the font, borders, padding, and other tweaks.<br />
<br />
== My shortcuts ==<br />
<br />
* [[User:Zack/Sandbox]]<br />
* [[List of Flairs]]<br />
* [[Template:Flair]]</div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=25506Ruleset2024-02-04T18:22:40Z<p>Zack: /* Reputation */ Remove retro clause</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Agents shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Agent may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[The Database]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Agents ==<br />
A human with access to the blog who is not already an Agent may make a blog post making clear their wish to be an Agent (plural form Agents); in response, an Admin shall add them to the roster in the sidebar, at which moment they become an Agent. (See the [[FAQ#Can_I_join_in.3F|FAQ]] for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
An Agent may only change their name as a result of a Proposal approving the change.<br />
<br />
Some Agents are '''Admins''', responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. Agents may be made Admins through Proposal or CFJ.<br />
<br />
An Agent may cease to be an Agent at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be an Agent in this way may not become an Agent again within the following two weeks.<br />
<br />
===Idle Agents ===<br />
<br />
If an Agent is Idle, this is tracked by their name being removed or concealed in the list of currently active Agents in the Sidebar. For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Agents ”, “Dynasties”, “Fair Play”, "Mentors" and any of those Rules’ subrules, Idle Agents are not counted as Agents . The combined term “Idle Agent” can be used to refer to Agents who are Idle even in rules that do not treat them as Agents.<br />
<br />
If a Proposal contains a provision that targets a specifically named Idle Agent, then that Idle Agent is considered to be Unidle solely for the purposes of enacting that specific provision.<br />
<br />
When an Agent is unidled, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Agent Idled in a different Dynasty), the Agent is given the default value for new Agents, if such a value exists.<br />
<br />
An Admin may render an Agent Idle if that Agent has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Agent has not posted an entry or comment in the past 168 Hours (7 days). In the latter case, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Agent during the current and subsequent dynasty. Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so. An Admin may Unidle an Agent if that Agent is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may Unidle themselves at any time, unless the Agent who would be Unidled has become Idle within the past 96 hours (4 days), and within the current Dynasty.<br />
<br />
Admins who are unidling themselves should, in their first vote following each unidling, highlight their changed idle status and any changes to Quorum to have come about as a result of it.<br />
<br />
Idle admins can resolve Votable Matters as a non-idle admin would.<br />
<br />
===Dormancy===<br />
If there are fewer than four Agents (not including the Mainframe), then BlogNomic is on Hiatus.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Agent, known as the Mainframe. If there is no Mainframe, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before an Ascension Address has been posted. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Agent may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Mainframe is not an Agent.<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Agents may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Agent may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. An Agent's Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Agent never has a Vote, even if they were an Agent previously and had cast a valid Vote.<br />
<br />
If an Agent other than the Mainframe casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Mainframe. When the Mainframe has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Mainframe's Vote for the purposes of other rules unless otherwise specified. When the Mainframe themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Agents who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Agent may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Agent already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When an Agent casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Mainframe may use VETO as a voting icon to cast a Vote on a Proposal; when the Mainframe casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Mainframe later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Agent A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If an Agent (other than the Mainframe) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
An Agent's vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Agent may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, it has been open for at least 12 hours, and either the Mainframe has Voted FOR it or it has no AGAINST Votes.<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, and it has been open for at least 24 hours.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Agent who posted the DoV becomes Mainframe, and the game enters an Interregnum. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Mainframe must either Pass the Mantle (by making a post naming an Agent who was not the last dynasty’s Mainframe, in which case the passing Agent ceases to be the Mainframe and the Agent so named becomes the Mainframe) or start a new dynasty by completing the following Atomic Action:<br />
* Make an Ascension Address by posting an entry in the “Ascension Address” category. This should specify the Mainframe's chosen theme for the new Dynasty, and it may optionally specify new dynasty-specific terms as outline in the rule "Synonyms", and/or list a number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed).<br />
* Optionally specify any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section.<br />
* Update the Ruleset to reflect any changed terms, repeal any dynastic rules which were not listed to be kept, and make any specified or automatic changes to the Building Blocks section of the ruleset. Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Optionally change the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if an Agent's behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Agents should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Agent within BlogNomic, and should announce publicly if they control both a non-Idle Agent and any Idle Agents. This extends to exerting full control over the actions of another Agent, defined here as the controlled Agent's game behavior being functionally indistinguishable from if the controlling Agent was logged into their account and playing through it, over a period of more than a day.<br />
* An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* An Agent should not edit their own blog comments once posted, nor those of any other Agent.<br />
* An Agent should not edit the “Entry Date” field of a blog post.<br />
* An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* An Agent should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. an Agent must use their own name in the Dice Roller, when rolling dice.<br />
* An Agent should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* An Agent should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause an Agent to achieve victory.<br />
* An Agent should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Agent or Agents to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Agents and idle Agents should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Agents are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
<br />
==The Mainframe==<br />
'''The Mainframe''' is a strong AI with advanced natural language capabilities. All dynastic gamestate is secretly tracked by the Mainframe unless otherwise stated, or where it would be impossible.<br />
<br />
Communication between Agents that is facilitated by the Mainframe is exempt from the restrictions described in the rule “No Private Communications”.<br />
<br />
== The Agency ==<br />
<br />
The Agency is a darknet organization that rewards cyber operatives for acting in its interests. These operatives are known as Agents.<br />
<br />
The Mainframe shall assign each Agent an '''IP address''' in the form #.#.#.# where each # is a number from 1-255. If any Agent has not been assigned an IP, the Mainframe should secretly randomly assign them one before performing any dynastic actions.<br />
<br />
Each Agent has a number named '''CPU Cycles''' which defaults to 1.<br />
<br />
=== Reputation ===<br />
<br />
Each Agent has a reputation score which defaults to 50. A more positive representation represents a higher standing in the eyes of the Agency. The Mainframe may freely tell an Agent their own reputation score.<br />
<br />
The following actions impact an Agent’s reputation.<br />
{| class="wikitable sortable"<br />
! Action || Change<br />
|-<br />
| Creating a new Client || +5<br />
|-<br />
| Downloading a file || +5<br />
|-<br />
| Connecting to a Client for the first time || +10<br />
|}<br />
<br />
As a Virtual Action, an Agent may spend reputation to redeem one of the following rewards:<br />
{| class="wikitable sortable"<br />
! Cost || Reward<br />
|-<br />
| 2^N || (Where N is the Agent's current CPU cycles) <br/> Increase the Agent's CPU cycles by 1<br />
|-<br />
| 50 || The Mainframe will secretly randomly reassign the Agent a new IP address<br />
|}<br />
<br />
==Clients==<br />
There may be any number of '''Clients'''. Each Client has a unique Name and a Passcode, which are strings of 4-16 characters containing only letters, numbers, and underscores. Names are not case-sensitive but Passcodes are. Client Names are publicly tracked in the Database.<br />
<br />
As a weekly virtual action, an Agent may '''create a new Client''' by specifying the desired Name and Passcode for the Client. This may be re-attempted if the action fails.<br />
<br />
Each Client has a list of Files, defaulting to an empty list.<br />
<br />
A '''Brute Force Attempt''' is a pairing of a number named Progress and the name of an Agent. Each Client has a list of Brute Force Attempts, defaulting to an empty list.<br />
<br />
A '''Passcode Complexity''' is a derived value that equals the number of characters a Client's Passcode has, multiplied by how many of the following criteria (which should be a number from 1 to 3) one or more of its characters meets: lowercase letters, uppercase letters, numbers.<br />
<br />
===Connections===<br />
An Agent may be '''connected''' to any number of Clients. A connection is a relationship between exactly one Agent and one Client.<br />
<br />
As a virtual action, an Agent may '''connect to a Client''' by specifying exactly one Client Name and Passcode pair. If the Passcode is correct for the specified Client, the Agent becomes connected to that Client.<br />
<br />
As a virtual action, an Agent may '''disconnect from a Client''' by specifying a client they are connected to, at which point the Agent is no longer connected to that Client.<br />
<br />
===The Dark Web===<br />
There is a Client named '''Dark Web''' with the Passcode '''1337''' and the following '''Files''':<br />
<br />
* BackOrifice<br />
* MyDoom<br />
* Klex<br />
* StuxNet<br />
* WannaCry<br />
<br />
The Dark Web may not '''brute force'''.<br />
<br />
As a daily action, the Mainframe should '''refresh the Dark Web''', which is an atomic action with the following steps:<br />
* Remove three privately randomly chosen Files from the Dark Web<br />
* Add three new Files to the Dark Web’s Files and optionally give them any valid unique names<br />
* Privately randomly choose a File of the added Files and make its Program a privately random Program from the table “Programs”<br />
* Privately randomly choose a File of the added Files and make it corrupted by a privately random Malware from the table “Malwares” excluding Trojan horse.<br />
<br />
===Power===<br />
Each client except the Dark Web has '''Power''', which is an integer between 0 and 100 inclusive and defaults to 50. Every time a Client other than the Dark Web performs a successful '''Shell Command''' its Power is reduced by the '''Power Consumption''' of that Shell Command, to a minimum of 0.<br />
<br />
Every night at midnight each Client gains 15 power, to a maximum of 100.<br />
<br />
==Shell Commands==<br />
A '''Shell Command''' is a type of Virtual Action that the Mainframe performs as a Client on behalf of an Agent. For the purposes of resolving Shell Commands, a Client is considered an Agent; The Client serves as a proxy for the Agent who initiated the command.<br />
<br />
An Agent must be connected to a Client to perform Shell Commands as that Client. ''To perform a Shell Command, you must always specify exactly one Client that you are connected to, or the action fails.'' Each Shell Command has a '''Power Consumption''', which is a non-negative integer and by default 10. If a Client (other than the Dark Web) tries to perform a Shell Command whose Power Consumption is greater than that Client’s Power, it will fail.<br />
<br />
The definition of a Shell Command should be contained within the “Shell command” flair; If one is not, the Mainframe may edit the ruleset to make it so.<br />
<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client can '''ping''' the Mainframe. The Mainframe will respond to confirm that it is online.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Logging===<br />
The Mainframe shall maintain a '''log''' of successful Shell Commands. Each new log entry shall include:<br />
* the time/date it occurred<br />
* the IP of the initiating Agent<br />
* the name of the Client<br />
* the type of command<br />
* any other data the command specifies to be logged<br />
<br />
{{Flair top|Shell command}}<br />
As a shell command, a Client may '''request a copy of logs''' within a particular scope (e.g. a certain timeframe, logs associated with a certain IP, etc). Each log entry will be accompanied by an MD5 hash of the entry by which it can be identified.<br />
<br />
If the Client does not have access to all of the logs in the desired scope, the action will fail. By default, a Client only has access to the logs of actions performed by that particular Client.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Downloading===<br />
Each Agent has '''Warez''', which is a list of Files, defaulting to an empty list.<br />
<br />
{{Flair top|Shell command}}<br />
If a Client has one or more Files, as a Shell Command, that Client may '''download file''' with the name of the File to download. If the File does not already exist in that Agent's Warez, it is added to the Warez of the Agent performing this command, otherwise the command fails. This command may be re-attempted if it failed.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
===Brute Force===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client may brute force a Target, specifying the name of another Client. If the Target does not have a Brute Force Attempt which names the Agent performing the command, the Mainframe will create a new Brute Force Attempt on the Target Client with the Agent’s name and a Progress of 0.<br />
<br />
The Mainframe will increase the Progress of the Agent’s Brute Force Attempt on the Target Client by the Agent’s CPU Cycles.<br />
* If the entry’s Progress is greater than or equal to the Target’s Passcode Complexity, the Mainframe shall secretly communicate the Target’s Passcode to the Agent.<br />
* Otherwise, the Mainframe shall inform the Agent of the current Progress of their Brute Force Attempt on the Target.<br />
<br />
The Mainframe will include the name of the Target and the current Progress of the attempt in the log of the action.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
==Best Practices==<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a client may '''change passcode'''. The Client specifies a new valid Passcode and the Client's Passcode is changed to the new value. After this command executes, all Connections to the Client are removed. The Client's Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
==Files==<br />
A '''File''' consists of:<br />
* An unique '''name''', which is a string defaulting to “untitled”. If ever there would be two Files with the same name in the same list as a result of a virtual action, the Mainframe should add an arbitrary number to the end of either File’s name so that the names are unique.<br />
* Optionally one '''Program''' from the table “Programs”<br />
<br />
If a File contains a Program, the Type of the Program must be included in its name in brackets. Only Files with a Program may have brackets in their names, unless otherwise stated by the ruleset.<br />
<br />
{| class="wikitable"<br />
|+ Programs<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Anti-malware || When this File is executed, you may '''scan''' all files in your Warez. The Mainframe will respond with the number of corrupted Files in your Warez plus a privately randomly generated number between -2 and 2, inclusive, to a minimum of zero.<br />
|-<br />
| Firewall || Whenever you '''download''' a File, if the File is '''corrupted''', the Mainframe must privately randomly determine whether the File actually is downloaded or not, with both options being equally likely.<br />
|}<br />
<br />
The Effects of a Program only apply to Agents who have at least one File with that Program in their Warez. As a daily virtual action, an Agent may '''execute''' a File by specifying the name of exactly one File in their Warez. This may be re-attempted if the action fails.<br />
<br />
As a virtual action, an Agent may '''write a program''' by specifying the type of exactly one Program from the table “Programs” and the name of exactly one File in their Warez that doesn’t already have a Program. The Mainframe will set that File’s Program to be the specified Program, adding the Program’s type in brackets to the end of the File’s name.<br />
<br />
===Malware===<br />
An instance of a File in a list may be '''corrupted''' by none or more of the '''Malware''' described in the table below, defaulting to none. Whenever an Agent downloads a corrupted File, the File added to the Agent’s Warez will also be corrupted by the same Malware.<br />
<br />
{| class="wikitable"<br />
|+ Malware<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Virus || Whenever a Client performs a Shell Command, if the initiating Agent's Warez contains a File corrupted by a Virus, the Mainframe must make one of the Client's uncorrupted Files, if there are any, as well as one of the initiating Agent's Warez' uncorrupted Files, if there are any, corrupted by a Virus.<br />
|-<br />
| Trojan horse || If a file is corrupted by a Trojan horse, its name is allowed to contain brackets. However, such a File may not contain a Program.<br />
|}<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page is gamestate and may not be altered except as specified by the ruleset or through the passage of a Proposal or CfJ; however, its contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Mainframe specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset; these rules must then be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Mainframe makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected. There are currently no Recommended Building Blocks.<br />
<br />
==No Private Communication==<br />
Agents may not privately communicate with each other about dynastic gameplay or votable matters that affect the dynastic ruleset or gamestate. Private communications are considered to be anything that any other Agent could not reasonably be privy to, perceive, or understand. Discussion conducted in plain English on the BlogNomic wiki and blog, and the #current-dynasty, #blognomic-general and #new-player-questions-and-mentorships Discord channels, are not considered to be private communication. Idle Agents (or people who are not yet Agents) also face the same restrictions if they intend to become an active Agent during the course of the dynasty. The use of creative strategies to circumvent this rule may be considered to be a scam for the purposes of determining whether an infraction of Fair Play has taken place.<br />
<br />
A mentor and mentee may still privately converse with each other, but should keep their conversations away from discussing specific gameplay strategy. This rule’s restrictions on communication do not apply during an Interregnum. The restrictions in this rule on communication in non-blognomic-related media shall not be construed as to cause those media to be gamestate.<br />
<br />
If information which was not allowed to be discussed is still privately discussed, the Agents who were part of the conversation should make a post to the blog disclosing what information was discussed as their earliest convenience.<br />
<br />
==Virtual Actions==<br />
A Virtual Action is a type of action that the Mainframe performs on behalf of an Agent. An Agent may initiate a virtual action by privately communicating to the Mainframe their request to do so, along with any additional information needed to carry it out. The Mainframe shall resolve the Virtual Action by performing the following Atomic Action:<br />
# Determine whether the Virtual Action fails (if it does not fail, it is successful).<br />
# If the action is successful, apply any specified effects on the gamestate and/or perform any specified actions on behalf of the Agent.<br />
<br />
If a Virtual Action fails, the Mainframe should tell the Agent why. A virtual action may fail for any of these reasons:<br />
* Some requirements/prerequisites to perform the action are not met.<br />
* The request does not contain all the information needed to resolve the action.<br />
* The request is unintelligible, or too vague to interpret unambiguously.<br />
* It would require the Mainframe to do something they cannot do.<br />
* Any other reason specified by the action itself.<br />
<br />
Except where otherwise stated by the ruleset, the Mainframe must resolve all virtual actions in the order that they are received. A virtual action is considered to have occurred at the time it was resolved.<br />
<br />
Until a virtual action is resolved, it is pending. An Agent may cancel a pending Virtual Action by privately communicating to the Mainframe their request to do so<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Agent per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Agent per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Agents.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Effective Vote Comment (EVC): An Agent's Effective Vote Comment with respect to a given Votable Matter is that Agent's Comment to that Votable Matter, if any, that contains that Agent's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Agents , as well as people who are not Agents but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Agents who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Agents are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the Dynastic Rules explicitly mention (except for dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Pass the Mantle: Passing the Mantle is a mechanism by which, during an Interregnum, a Mainframe may nominate another Agent to become the Mainframe in the upcoming dynasty. Unless a Core, Dynastic or Building Block rule explicitly states otherwise, Passing the Mantle is currently prohibited.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Mainframe.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Agents” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To Uphold an illegal action is to retroactively declare the attempt to take it to have been successful, and to declare that all attempted game actions taken after it were attempted as if the Upheld action had been successful.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Agent may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may be altered by its author if it is less than 4 hours old and either no Agent has commented on it or (if it is a Votable Matter) if all comments on it contain no voting icons; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Mainframe to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Mainframe may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of an Agent’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Agent may correct the representations to comply with the Gamestate.<br />
<br />
If an Agent feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Agent, if doing so would not require the correcting Agent to make any decisions on behalf of the original Agent.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Agents are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
An Agent may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name an Agent with such access. Only an Agent with such access may Enact that Votable Matter. If that Votable Matter does not name an Agent with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Agent making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Agent making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When an Agent performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete.<br />
* If a rule allows the Agent performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If an Agent arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Agent must redo the Atomic Action; for that purpose, the Agent uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Agent would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, an Agent can spend or pay from only their own values, and a rule that allows Agents to transfer or pay a numeric value to another Agent only allows them to transfer that value from themselves to that other Agent (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Agents are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Mainframe (including secretly random selections), then that information may only be revealed by the Mainframe when the ruleset allows it. If an Agent should already know such a piece of information (in that the Mainframe has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Mainframe may repeat it to them.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Agent may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Agents may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Mainframe has voted DEFERENTIAL on a Proposal, that vote is instead considered to be valid and either FOR (if more Agents have a valid FOR vote on that Proposal than have a valid AGAINST vote on it) or AGAINST (in all other cases). However, in either case, votes of DEFERENTIAL made by other Agents on the same Proposal are not considered to be valid. If there are six or fewer Agents, then the Mainframe’s vote of DEFERENTIAL on a proposal is only affected by this rule if all Agents who are not the Mainframe have cast a vote on that proposal.<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* An Agent may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Agents may correct obvious spelling, punctuation, and/or typographical mistakes in the Ruleset and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Agents with the corresponding forms of the singular “they”.<br />
* An Agent may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, an Agent's (or prospective Agent's ) new name must be between 4 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Agents may Kick each other” and “Agents may not Kick each other on Tuesdays” exist, and it is Tuesday, Agents may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Agents may Punch a Spaceman on Friday” and “Agents may not Punch Spacemen on Friday”, then Agents may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
An Agent may have another Agent as a Mentor. Agents who are willing to act as a Mentor are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of an Agent who has requested a change on their own behalf, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Agent requests a Mentor, or a new Agent has joined the game and has no Mentor, the Mainframe should select a Tenured Agent and ask them to take that Agent on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Mainframe should announce it in a blog post. The Mainframe should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. An Agent may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Mainframe, any Agent who has been active in at least three previous dynasties may act as Mainframe for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Agent or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Agents .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Agent” and “Mainframe”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Agent (Player)<br />
* Mainframe (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=25505Ruleset2024-02-04T18:15:33Z<p>Zack: /* Dynastic Rules */ Enacting Risk & Reward</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Agents shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Agent may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[The Database]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Agents ==<br />
A human with access to the blog who is not already an Agent may make a blog post making clear their wish to be an Agent (plural form Agents); in response, an Admin shall add them to the roster in the sidebar, at which moment they become an Agent. (See the [[FAQ#Can_I_join_in.3F|FAQ]] for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
An Agent may only change their name as a result of a Proposal approving the change.<br />
<br />
Some Agents are '''Admins''', responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. Agents may be made Admins through Proposal or CFJ.<br />
<br />
An Agent may cease to be an Agent at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be an Agent in this way may not become an Agent again within the following two weeks.<br />
<br />
===Idle Agents ===<br />
<br />
If an Agent is Idle, this is tracked by their name being removed or concealed in the list of currently active Agents in the Sidebar. For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Agents ”, “Dynasties”, “Fair Play”, "Mentors" and any of those Rules’ subrules, Idle Agents are not counted as Agents . The combined term “Idle Agent” can be used to refer to Agents who are Idle even in rules that do not treat them as Agents.<br />
<br />
If a Proposal contains a provision that targets a specifically named Idle Agent, then that Idle Agent is considered to be Unidle solely for the purposes of enacting that specific provision.<br />
<br />
When an Agent is unidled, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Agent Idled in a different Dynasty), the Agent is given the default value for new Agents, if such a value exists.<br />
<br />
An Admin may render an Agent Idle if that Agent has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Agent has not posted an entry or comment in the past 168 Hours (7 days). In the latter case, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Agent during the current and subsequent dynasty. Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so. An Admin may Unidle an Agent if that Agent is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may Unidle themselves at any time, unless the Agent who would be Unidled has become Idle within the past 96 hours (4 days), and within the current Dynasty.<br />
<br />
Admins who are unidling themselves should, in their first vote following each unidling, highlight their changed idle status and any changes to Quorum to have come about as a result of it.<br />
<br />
Idle admins can resolve Votable Matters as a non-idle admin would.<br />
<br />
===Dormancy===<br />
If there are fewer than four Agents (not including the Mainframe), then BlogNomic is on Hiatus.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Agent, known as the Mainframe. If there is no Mainframe, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before an Ascension Address has been posted. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Agent may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Mainframe is not an Agent.<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Agents may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Agent may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. An Agent's Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Agent never has a Vote, even if they were an Agent previously and had cast a valid Vote.<br />
<br />
If an Agent other than the Mainframe casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Mainframe. When the Mainframe has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Mainframe's Vote for the purposes of other rules unless otherwise specified. When the Mainframe themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Agents who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Agent may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Agent already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When an Agent casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Mainframe may use VETO as a voting icon to cast a Vote on a Proposal; when the Mainframe casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Mainframe later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Agent A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If an Agent (other than the Mainframe) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
An Agent's vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Agent may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, it has been open for at least 12 hours, and either the Mainframe has Voted FOR it or it has no AGAINST Votes.<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, and it has been open for at least 24 hours.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Agent who posted the DoV becomes Mainframe, and the game enters an Interregnum. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Mainframe must either Pass the Mantle (by making a post naming an Agent who was not the last dynasty’s Mainframe, in which case the passing Agent ceases to be the Mainframe and the Agent so named becomes the Mainframe) or start a new dynasty by completing the following Atomic Action:<br />
* Make an Ascension Address by posting an entry in the “Ascension Address” category. This should specify the Mainframe's chosen theme for the new Dynasty, and it may optionally specify new dynasty-specific terms as outline in the rule "Synonyms", and/or list a number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed).<br />
* Optionally specify any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section.<br />
* Update the Ruleset to reflect any changed terms, repeal any dynastic rules which were not listed to be kept, and make any specified or automatic changes to the Building Blocks section of the ruleset. Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Optionally change the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if an Agent's behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Agents should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Agent within BlogNomic, and should announce publicly if they control both a non-Idle Agent and any Idle Agents. This extends to exerting full control over the actions of another Agent, defined here as the controlled Agent's game behavior being functionally indistinguishable from if the controlling Agent was logged into their account and playing through it, over a period of more than a day.<br />
* An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* An Agent should not edit their own blog comments once posted, nor those of any other Agent.<br />
* An Agent should not edit the “Entry Date” field of a blog post.<br />
* An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* An Agent should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. an Agent must use their own name in the Dice Roller, when rolling dice.<br />
* An Agent should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* An Agent should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause an Agent to achieve victory.<br />
* An Agent should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Agent or Agents to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Agents and idle Agents should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Agents are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
<br />
==The Mainframe==<br />
'''The Mainframe''' is a strong AI with advanced natural language capabilities. All dynastic gamestate is secretly tracked by the Mainframe unless otherwise stated, or where it would be impossible.<br />
<br />
Communication between Agents that is facilitated by the Mainframe is exempt from the restrictions described in the rule “No Private Communications”.<br />
<br />
== The Agency ==<br />
<br />
The Agency is a darknet organization that rewards cyber operatives for acting in its interests. These operatives are known as Agents.<br />
<br />
The Mainframe shall assign each Agent an '''IP address''' in the form #.#.#.# where each # is a number from 1-255. If any Agent has not been assigned an IP, the Mainframe should secretly randomly assign them one before performing any dynastic actions.<br />
<br />
Each Agent has a number named '''CPU Cycles''' which defaults to 1.<br />
<br />
=== Reputation ===<br />
<br />
Each Agent has a reputation score which defaults to 50. A more positive representation represents a higher standing in the eyes of the Agency. The Mainframe may freely tell an Agent their own reputation score.<br />
<br />
The following actions impact an Agent’s reputation.<br />
{| class="wikitable sortable"<br />
! Action || Change<br />
|-<br />
| Creating a new Client || +5<br />
|-<br />
| Downloading a file || +5<br />
|-<br />
| Connecting to a Client for the first time || +10<br />
|}<br />
<br />
As a Virtual Action, an Agent may spend reputation to redeem one of the following rewards:<br />
{| class="wikitable sortable"<br />
! Cost || Reward<br />
|-<br />
| 2^N || (Where N is the Agent's current CPU cycles) <br/> Increase the Agent's CPU cycles by 1<br />
|-<br />
| 50 || The Mainframe will secretly randomly reassign the Agent a new IP address<br />
|}<br />
<br />
If they have not done so since the start of the Dynasty, the Mainframe may retroactively apply any reputation changes that would have been applied between the start of the dynasty and the enactment of the proposal “Risk & Reward”, then remove this sentence from the ruleset.<br />
<br />
==Clients==<br />
There may be any number of '''Clients'''. Each Client has a unique Name and a Passcode, which are strings of 4-16 characters containing only letters, numbers, and underscores. Names are not case-sensitive but Passcodes are. Client Names are publicly tracked in the Database.<br />
<br />
As a weekly virtual action, an Agent may '''create a new Client''' by specifying the desired Name and Passcode for the Client. This may be re-attempted if the action fails.<br />
<br />
Each Client has a list of Files, defaulting to an empty list.<br />
<br />
A '''Brute Force Attempt''' is a pairing of a number named Progress and the name of an Agent. Each Client has a list of Brute Force Attempts, defaulting to an empty list.<br />
<br />
A '''Passcode Complexity''' is a derived value that equals the number of characters a Client's Passcode has, multiplied by how many of the following criteria (which should be a number from 1 to 3) one or more of its characters meets: lowercase letters, uppercase letters, numbers.<br />
<br />
===Connections===<br />
An Agent may be '''connected''' to any number of Clients. A connection is a relationship between exactly one Agent and one Client.<br />
<br />
As a virtual action, an Agent may '''connect to a Client''' by specifying exactly one Client Name and Passcode pair. If the Passcode is correct for the specified Client, the Agent becomes connected to that Client.<br />
<br />
As a virtual action, an Agent may '''disconnect from a Client''' by specifying a client they are connected to, at which point the Agent is no longer connected to that Client.<br />
<br />
===The Dark Web===<br />
There is a Client named '''Dark Web''' with the Passcode '''1337''' and the following '''Files''':<br />
<br />
* BackOrifice<br />
* MyDoom<br />
* Klex<br />
* StuxNet<br />
* WannaCry<br />
<br />
The Dark Web may not '''brute force'''.<br />
<br />
As a daily action, the Mainframe should '''refresh the Dark Web''', which is an atomic action with the following steps:<br />
* Remove three privately randomly chosen Files from the Dark Web<br />
* Add three new Files to the Dark Web’s Files and optionally give them any valid unique names<br />
* Privately randomly choose a File of the added Files and make its Program a privately random Program from the table “Programs”<br />
* Privately randomly choose a File of the added Files and make it corrupted by a privately random Malware from the table “Malwares” excluding Trojan horse.<br />
<br />
===Power===<br />
Each client except the Dark Web has '''Power''', which is an integer between 0 and 100 inclusive and defaults to 50. Every time a Client other than the Dark Web performs a successful '''Shell Command''' its Power is reduced by the '''Power Consumption''' of that Shell Command, to a minimum of 0.<br />
<br />
Every night at midnight each Client gains 15 power, to a maximum of 100.<br />
<br />
==Shell Commands==<br />
A '''Shell Command''' is a type of Virtual Action that the Mainframe performs as a Client on behalf of an Agent. For the purposes of resolving Shell Commands, a Client is considered an Agent; The Client serves as a proxy for the Agent who initiated the command.<br />
<br />
An Agent must be connected to a Client to perform Shell Commands as that Client. ''To perform a Shell Command, you must always specify exactly one Client that you are connected to, or the action fails.'' Each Shell Command has a '''Power Consumption''', which is a non-negative integer and by default 10. If a Client (other than the Dark Web) tries to perform a Shell Command whose Power Consumption is greater than that Client’s Power, it will fail.<br />
<br />
The definition of a Shell Command should be contained within the “Shell command” flair; If one is not, the Mainframe may edit the ruleset to make it so.<br />
<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client can '''ping''' the Mainframe. The Mainframe will respond to confirm that it is online.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Logging===<br />
The Mainframe shall maintain a '''log''' of successful Shell Commands. Each new log entry shall include:<br />
* the time/date it occurred<br />
* the IP of the initiating Agent<br />
* the name of the Client<br />
* the type of command<br />
* any other data the command specifies to be logged<br />
<br />
{{Flair top|Shell command}}<br />
As a shell command, a Client may '''request a copy of logs''' within a particular scope (e.g. a certain timeframe, logs associated with a certain IP, etc). Each log entry will be accompanied by an MD5 hash of the entry by which it can be identified.<br />
<br />
If the Client does not have access to all of the logs in the desired scope, the action will fail. By default, a Client only has access to the logs of actions performed by that particular Client.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Downloading===<br />
Each Agent has '''Warez''', which is a list of Files, defaulting to an empty list.<br />
<br />
{{Flair top|Shell command}}<br />
If a Client has one or more Files, as a Shell Command, that Client may '''download file''' with the name of the File to download. If the File does not already exist in that Agent's Warez, it is added to the Warez of the Agent performing this command, otherwise the command fails. This command may be re-attempted if it failed.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
===Brute Force===<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client may brute force a Target, specifying the name of another Client. If the Target does not have a Brute Force Attempt which names the Agent performing the command, the Mainframe will create a new Brute Force Attempt on the Target Client with the Agent’s name and a Progress of 0.<br />
<br />
The Mainframe will increase the Progress of the Agent’s Brute Force Attempt on the Target Client by the Agent’s CPU Cycles.<br />
* If the entry’s Progress is greater than or equal to the Target’s Passcode Complexity, the Mainframe shall secretly communicate the Target’s Passcode to the Agent.<br />
* Otherwise, the Mainframe shall inform the Agent of the current Progress of their Brute Force Attempt on the Target.<br />
<br />
The Mainframe will include the name of the Target and the current Progress of the attempt in the log of the action.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
==Best Practices==<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a client may '''change passcode'''. The Client specifies a new valid Passcode and the Client's Passcode is changed to the new value. After this command executes, all Connections to the Client are removed. The Client's Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
==Files==<br />
A '''File''' consists of:<br />
* An unique '''name''', which is a string defaulting to “untitled”. If ever there would be two Files with the same name in the same list as a result of a virtual action, the Mainframe should add an arbitrary number to the end of either File’s name so that the names are unique.<br />
* Optionally one '''Program''' from the table “Programs”<br />
<br />
If a File contains a Program, the Type of the Program must be included in its name in brackets. Only Files with a Program may have brackets in their names, unless otherwise stated by the ruleset.<br />
<br />
{| class="wikitable"<br />
|+ Programs<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Anti-malware || When this File is executed, you may '''scan''' all files in your Warez. The Mainframe will respond with the number of corrupted Files in your Warez plus a privately randomly generated number between -2 and 2, inclusive, to a minimum of zero.<br />
|-<br />
| Firewall || Whenever you '''download''' a File, if the File is '''corrupted''', the Mainframe must privately randomly determine whether the File actually is downloaded or not, with both options being equally likely.<br />
|}<br />
<br />
The Effects of a Program only apply to Agents who have at least one File with that Program in their Warez. As a daily virtual action, an Agent may '''execute''' a File by specifying the name of exactly one File in their Warez. This may be re-attempted if the action fails.<br />
<br />
As a virtual action, an Agent may '''write a program''' by specifying the type of exactly one Program from the table “Programs” and the name of exactly one File in their Warez that doesn’t already have a Program. The Mainframe will set that File’s Program to be the specified Program, adding the Program’s type in brackets to the end of the File’s name.<br />
<br />
===Malware===<br />
An instance of a File in a list may be '''corrupted''' by none or more of the '''Malware''' described in the table below, defaulting to none. Whenever an Agent downloads a corrupted File, the File added to the Agent’s Warez will also be corrupted by the same Malware.<br />
<br />
{| class="wikitable"<br />
|+ Malware<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Virus || Whenever a Client performs a Shell Command, if the initiating Agent's Warez contains a File corrupted by a Virus, the Mainframe must make one of the Client's uncorrupted Files, if there are any, as well as one of the initiating Agent's Warez' uncorrupted Files, if there are any, corrupted by a Virus.<br />
|-<br />
| Trojan horse || If a file is corrupted by a Trojan horse, its name is allowed to contain brackets. However, such a File may not contain a Program.<br />
|}<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page is gamestate and may not be altered except as specified by the ruleset or through the passage of a Proposal or CfJ; however, its contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Mainframe specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset; these rules must then be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Mainframe makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected. There are currently no Recommended Building Blocks.<br />
<br />
==No Private Communication==<br />
Agents may not privately communicate with each other about dynastic gameplay or votable matters that affect the dynastic ruleset or gamestate. Private communications are considered to be anything that any other Agent could not reasonably be privy to, perceive, or understand. Discussion conducted in plain English on the BlogNomic wiki and blog, and the #current-dynasty, #blognomic-general and #new-player-questions-and-mentorships Discord channels, are not considered to be private communication. Idle Agents (or people who are not yet Agents) also face the same restrictions if they intend to become an active Agent during the course of the dynasty. The use of creative strategies to circumvent this rule may be considered to be a scam for the purposes of determining whether an infraction of Fair Play has taken place.<br />
<br />
A mentor and mentee may still privately converse with each other, but should keep their conversations away from discussing specific gameplay strategy. This rule’s restrictions on communication do not apply during an Interregnum. The restrictions in this rule on communication in non-blognomic-related media shall not be construed as to cause those media to be gamestate.<br />
<br />
If information which was not allowed to be discussed is still privately discussed, the Agents who were part of the conversation should make a post to the blog disclosing what information was discussed as their earliest convenience.<br />
<br />
==Virtual Actions==<br />
A Virtual Action is a type of action that the Mainframe performs on behalf of an Agent. An Agent may initiate a virtual action by privately communicating to the Mainframe their request to do so, along with any additional information needed to carry it out. The Mainframe shall resolve the Virtual Action by performing the following Atomic Action:<br />
# Determine whether the Virtual Action fails (if it does not fail, it is successful).<br />
# If the action is successful, apply any specified effects on the gamestate and/or perform any specified actions on behalf of the Agent.<br />
<br />
If a Virtual Action fails, the Mainframe should tell the Agent why. A virtual action may fail for any of these reasons:<br />
* Some requirements/prerequisites to perform the action are not met.<br />
* The request does not contain all the information needed to resolve the action.<br />
* The request is unintelligible, or too vague to interpret unambiguously.<br />
* It would require the Mainframe to do something they cannot do.<br />
* Any other reason specified by the action itself.<br />
<br />
Except where otherwise stated by the ruleset, the Mainframe must resolve all virtual actions in the order that they are received. A virtual action is considered to have occurred at the time it was resolved.<br />
<br />
Until a virtual action is resolved, it is pending. An Agent may cancel a pending Virtual Action by privately communicating to the Mainframe their request to do so<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Agent per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Agent per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Agents.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Effective Vote Comment (EVC): An Agent's Effective Vote Comment with respect to a given Votable Matter is that Agent's Comment to that Votable Matter, if any, that contains that Agent's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Agents , as well as people who are not Agents but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Agents who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Agents are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the Dynastic Rules explicitly mention (except for dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Pass the Mantle: Passing the Mantle is a mechanism by which, during an Interregnum, a Mainframe may nominate another Agent to become the Mainframe in the upcoming dynasty. Unless a Core, Dynastic or Building Block rule explicitly states otherwise, Passing the Mantle is currently prohibited.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Mainframe.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Agents” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To Uphold an illegal action is to retroactively declare the attempt to take it to have been successful, and to declare that all attempted game actions taken after it were attempted as if the Upheld action had been successful.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Agent may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may be altered by its author if it is less than 4 hours old and either no Agent has commented on it or (if it is a Votable Matter) if all comments on it contain no voting icons; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Mainframe to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Mainframe may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of an Agent’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Agent may correct the representations to comply with the Gamestate.<br />
<br />
If an Agent feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Agent, if doing so would not require the correcting Agent to make any decisions on behalf of the original Agent.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Agents are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
An Agent may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name an Agent with such access. Only an Agent with such access may Enact that Votable Matter. If that Votable Matter does not name an Agent with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Agent making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Agent making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When an Agent performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete.<br />
* If a rule allows the Agent performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If an Agent arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Agent must redo the Atomic Action; for that purpose, the Agent uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Agent would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, an Agent can spend or pay from only their own values, and a rule that allows Agents to transfer or pay a numeric value to another Agent only allows them to transfer that value from themselves to that other Agent (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Agents are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Mainframe (including secretly random selections), then that information may only be revealed by the Mainframe when the ruleset allows it. If an Agent should already know such a piece of information (in that the Mainframe has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Mainframe may repeat it to them.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Agent may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Agents may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Mainframe has voted DEFERENTIAL on a Proposal, that vote is instead considered to be valid and either FOR (if more Agents have a valid FOR vote on that Proposal than have a valid AGAINST vote on it) or AGAINST (in all other cases). However, in either case, votes of DEFERENTIAL made by other Agents on the same Proposal are not considered to be valid. If there are six or fewer Agents, then the Mainframe’s vote of DEFERENTIAL on a proposal is only affected by this rule if all Agents who are not the Mainframe have cast a vote on that proposal.<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* An Agent may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Agents may correct obvious spelling, punctuation, and/or typographical mistakes in the Ruleset and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Agents with the corresponding forms of the singular “they”.<br />
* An Agent may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, an Agent's (or prospective Agent's ) new name must be between 4 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Agents may Kick each other” and “Agents may not Kick each other on Tuesdays” exist, and it is Tuesday, Agents may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Agents may Punch a Spaceman on Friday” and “Agents may not Punch Spacemen on Friday”, then Agents may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
An Agent may have another Agent as a Mentor. Agents who are willing to act as a Mentor are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of an Agent who has requested a change on their own behalf, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Agent requests a Mentor, or a new Agent has joined the game and has no Mentor, the Mainframe should select a Tenured Agent and ask them to take that Agent on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Mainframe should announce it in a blog post. The Mainframe should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. An Agent may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Mainframe, any Agent who has been active in at least three previous dynasties may act as Mainframe for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Agent or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Agents .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Agent” and “Mainframe”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Agent (Player)<br />
* Mainframe (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25504The Database2024-02-04T05:10:13Z<p>Zack: Create new client</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Client Names<br />
|-<br />
| The Gibson<br />
|-<br />
| _Mel<br />
|-<br />
| jumpbox<br />
|-<br />
| Lilac<br />
|-<br />
| monkey<br />
|-<br />
| Dark Web<br />
|-<br />
| ERROR<br />
|-<br />
| Hal9000<br />
|}</div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=25501Ruleset2024-01-31T18:51:28Z<p>Zack: /* Dynastic Rules */ Update shell commands with default power consumption</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Agents shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Agent may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[The Database]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Agents ==<br />
A human with access to the blog who is not already an Agent may make a blog post making clear their wish to be an Agent (plural form Agents); in response, an Admin shall add them to the roster in the sidebar, at which moment they become an Agent. (See the [[FAQ#Can_I_join_in.3F|FAQ]] for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
An Agent may only change their name as a result of a Proposal approving the change.<br />
<br />
Some Agents are '''Admins''', responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. Agents may be made Admins through Proposal or CFJ.<br />
<br />
An Agent may cease to be an Agent at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be an Agent in this way may not become an Agent again within the following two weeks.<br />
<br />
===Idle Agents ===<br />
<br />
If an Agent is Idle, this is tracked by their name being removed or concealed in the list of currently active Agents in the Sidebar. For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Agents ”, “Dynasties”, “Fair Play”, "Mentors" and any of those Rules’ subrules, Idle Agents are not counted as Agents . The combined term “Idle Agent” can be used to refer to Agents who are Idle even in rules that do not treat them as Agents.<br />
<br />
If a Proposal contains a provision that targets a specifically named Idle Agent, then that Idle Agent is considered to be Unidle solely for the purposes of enacting that specific provision.<br />
<br />
When an Agent is unidled, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Agent Idled in a different Dynasty), the Agent is given the default value for new Agents, if such a value exists.<br />
<br />
An Admin may render an Agent Idle if that Agent has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Agent has not posted an entry or comment in the past 168 Hours (7 days). In the latter case, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Agent during the current and subsequent dynasty. Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so. An Admin may Unidle an Agent if that Agent is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may Unidle themselves at any time, unless the Agent who would be Unidled has become Idle within the past 96 hours (4 days), and within the current Dynasty.<br />
<br />
Admins who are unidling themselves should, in their first vote following each unidling, highlight their changed idle status and any changes to Quorum to have come about as a result of it.<br />
<br />
Idle admins can resolve Votable Matters as a non-idle admin would.<br />
<br />
===Dormancy===<br />
If there are fewer than four Agents (not including the Mainframe), then BlogNomic is on Hiatus.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Agent, known as the Mainframe. If there is no Mainframe, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before an Ascension Address has been posted. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Agent may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Mainframe is not an Agent.<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Agents may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Agent may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. An Agent's Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Agent never has a Vote, even if they were an Agent previously and had cast a valid Vote.<br />
<br />
If an Agent other than the Mainframe casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Mainframe. When the Mainframe has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Mainframe's Vote for the purposes of other rules unless otherwise specified. When the Mainframe themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Agents who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Agent may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Agent already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When an Agent casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Mainframe may use VETO as a voting icon to cast a Vote on a Proposal; when the Mainframe casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Mainframe later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Agent A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If an Agent (other than the Mainframe) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
An Agent's vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Agent may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, it has been open for at least 12 hours, and either the Mainframe has Voted FOR it or it has no AGAINST Votes.<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, and it has been open for at least 24 hours.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Agent who posted the DoV becomes Mainframe, and the game enters an Interregnum. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Mainframe must either Pass the Mantle (by making a post naming an Agent who was not the last dynasty’s Mainframe, in which case the passing Agent ceases to be the Mainframe and the Agent so named becomes the Mainframe) or start a new dynasty by completing the following Atomic Action:<br />
* Make an Ascension Address by posting an entry in the “Ascension Address” category. This should specify the Mainframe's chosen theme for the new Dynasty, and it may optionally specify new dynasty-specific terms as outline in the rule "Synonyms", and/or list a number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed).<br />
* Optionally specify any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section.<br />
* Update the Ruleset to reflect any changed terms, repeal any dynastic rules which were not listed to be kept, and make any specified or automatic changes to the Building Blocks section of the ruleset. Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Optionally change the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if an Agent's behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Agents should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Agent within BlogNomic, and should announce publicly if they control both a non-Idle Agent and any Idle Agents. This extends to exerting full control over the actions of another Agent, defined here as the controlled Agent's game behavior being functionally indistinguishable from if the controlling Agent was logged into their account and playing through it, over a period of more than a day.<br />
* An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* An Agent should not edit their own blog comments once posted, nor those of any other Agent.<br />
* An Agent should not edit the “Entry Date” field of a blog post.<br />
* An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* An Agent should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. an Agent must use their own name in the Dice Roller, when rolling dice.<br />
* An Agent should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* An Agent should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause an Agent to achieve victory.<br />
* An Agent should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Agent or Agents to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Agents and idle Agents should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Agents are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
<br />
==The Mainframe==<br />
'''The Mainframe''' is a strong AI with advanced natural language capabilities. All dynastic gamestate is secretly tracked by the Mainframe unless otherwise stated, or where it would be impossible.<br />
<br />
The Mainframe shall assign each Agent an '''IP address''' in the form #.#.#.# where each # is a number from 1-255. If any Agent has not been assigned an IP, the Mainframe should secretly randomly assign them one before performing any dynastic actions.<br />
<br />
Each Agent has a number named '''CPU Cycles''' which defaults to 1.<br />
<br />
Communication between Agents that is facilitated by the Mainframe is exempt from the restrictions described in the rule “No Private Communications”.<br />
<br />
==Clients==<br />
There may be any number of '''Clients'''. Each Client has a unique Name and a Passcode, which are strings of 4-16 characters containing only letters, numbers, and underscores. Names are not case-sensitive but Passcodes are. Client Names are publicly tracked in the Database.<br />
<br />
As a weekly virtual action, an Agent may '''create a new Client''' by specifying the desired Name and Passcode for the Client. This may be re-attempted if the action fails.<br />
<br />
Each Client has a list of Files, defaulting to an empty list.<br />
<br />
A '''Brute Force Attempt''' is a pairing of a number named Progress and the name of an Agent. Each Client has a list of Brute Force Attempts, defaulting to an empty list.<br />
<br />
A '''Passcode Complexity''' is a derived value that equals the number of characters a Client's Passcode has, multiplied by how many of the following criteria (which should be a number from 1 to 3) one or more of its characters meets: lowercase letters, uppercase letters, numbers.<br />
<br />
===Connections===<br />
An Agent may be '''connected''' to any number of Clients. A connection is a relationship between exactly one Agent and one Client.<br />
<br />
As a virtual action, an Agent may '''connect to a Client''' by specifying exactly one Client Name and Passcode pair. If the Passcode is correct for the specified Client, the Agent becomes connected to that Client.<br />
<br />
As a virtual action, an Agent may '''disconnect from a Client''' by specifying a client they are connected to, at which point the Agent is no longer connected to that Client.<br />
<br />
===The Dark Web===<br />
There is a Client named '''Dark Web''' with the Passcode '''1337''' and the following '''Files''':<br />
<br />
* BackOrifice<br />
* MyDoom<br />
* Klex<br />
* StuxNet<br />
* WannaCry<br />
<br />
The Dark Web may not '''brute force'''.<br />
<br />
===Power===<br />
Each client except the Dark Web has '''Power''', which is an integer between 0 and 100 inclusive and defaults to 50. Every time a Client other than the Dark Web performs a successful '''Shell Command''' its Power is reduced by the '''Power Consumption''' of that Shell Command, to a minimum of 0.<br />
<br />
==Shell Commands==<br />
A '''Shell Command''' is a type of Virtual Action that the Mainframe performs as a Client on behalf of an Agent. For the purposes of resolving Shell Commands, a Client is considered an Agent; The Client serves as a proxy for the Agent who initiated the command.<br />
<br />
An Agent must be connected to a Client to perform Shell Commands as that Client. ''To perform a Shell Command, you must always specify exactly one Client that you are connected to, or the action fails.'' Each Shell Command has a '''Power Consumption''', which is a non-negative integer and by default 10. If a Client (other than the Dark Web) tries to perform a Shell Command whose Power Consumption is greater than that Client’s Power, it will fail.<br />
<br />
The definition of a Shell Command should be contained within the “Shell command” flair; If one is not, the Mainframe may edit the ruleset to make it so.<br />
<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client can '''ping''' the Mainframe. The Mainframe will respond to confirm that it is online.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Logging===<br />
The Mainframe shall maintain a '''log''' of successful Shell Commands. Each new log entry shall include:<br />
* the time/date it occurred<br />
* the IP of the initiating Agent<br />
* the name of the Client<br />
* the type of command<br />
* any other data the command specifies to be logged<br />
<br />
{{Flair top|Shell command}}<br />
As a shell command, a Client may '''request a copy of logs''' within a particular scope (e.g. a certain timeframe, logs associated with a certain IP, etc). Each log entry will be accompanied by an MD5 hash of the entry by which it can be identified.<br />
<br />
If the Client does not have access to all of the logs in the desired scope, the action will fail. By default, a Client only has access to the logs of actions performed by that particular Client.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Downloading===<br />
Each Agent has '''Warez''', which is a list of Files, defaulting to an empty list.<br />
<br />
{{Flair top|Shell command}}<br />
If a Client has one or more Files, as a Daily Shell Command, that Client may '''download file''' with the name of the File to download. If the File does not already exist in that Agent's Warez, it is added to the Warez of the Agent performing this command, otherwise the command fails. This command may be re-attempted if it failed.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
===Brute Force===<br />
{{Flair top|Shell command}}<br />
As a Daily Shell Command, a Client may brute force a Target, specifying the name of another Client. If the Target does not have a Brute Force Attempt which names the Agent performing the command, the Mainframe will create a new Brute Force Attempt on the Target Client with the Agent’s name and a Progress of 0.<br />
<br />
The Mainframe will increase the Progress of the Agent’s Brute Force Attempt on the Target Client by the Agent’s CPU Cycles.<br />
* If the entry’s Progress is greater than or equal to the Target’s Passcode Complexity, the Mainframe shall secretly communicate the Target’s Passcode to the Agent.<br />
* Otherwise, the Mainframe shall inform the Agent of the current Progress of their Brute Force Attempt on the Target.<br />
<br />
The Mainframe will include the name of the Target and the current Progress of the attempt in the log of the action.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
===Recharge===<br />
{{Flair top|Shell command}}<br />
As a weekly Shell Command, a Client may '''recharge'''. The Mainframe will set that Client’s Power to 100.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
==Best Practices==<br />
{{Flair top|Shell command}}<br />
As a weekly Shell Command, a client may '''change passcode'''. The Client specifies a new valid Passcode and the Client's Passcode is changed to the new value. After this command executes, all Connections to the Client are removed. The Client's Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.<br />
<br />
'''Power Consumption''': 10<br />
{{Flair bottom}}<br />
<br />
==Files==<br />
A '''File''' consists of:<br />
* A '''name''', which is a string defaulting to "untitled"<br />
* Optionally one '''Program''' from the table “Programs”<br />
<br />
If a File contains a Program, the Type of the Program must be included in its name in brackets. Only Files with a Program may have brackets in their names, unless otherwise stated by the ruleset.<br />
<br />
{| class="wikitable"<br />
|+ Programs<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Anti-malware || When this File is executed, you may '''scan''' all files in your Warez. The Mainframe will respond with the number of corrupted Files in your Warez plus a privately randomly generated number between -2 and 2, inclusive, to a minimum of zero.<br />
|-<br />
| Firewall || Whenever you '''download''' a File, if the File is '''corrupted''', the Mainframe must privately randomly determine whether the File actually is downloaded or not, with both options being equally likely.<br />
|}<br />
<br />
The Effects of a Program only apply to Agents who have at least one File with that Program in their Warez. As a daily virtual action, an Agent may '''execute''' a File by specifying the name of exactly one File in their Warez. This may be re-attempted if the action fails.<br />
<br />
===Malware===<br />
An instance of a File in a list may be '''corrupted''' by none or more of the '''Malware''' described in the table below, defaulting to none. Whenever an Agent downloads a corrupted File, the File added to the Agent’s Warez will also be corrupted by the same Malware.<br />
<br />
{| class="wikitable"<br />
|+ Malware<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Virus || Whenever a Client performs a Shell Command, if the initiating Agent's Warez contains a File corrupted by a Virus, the Mainframe must make one of the Client's uncorrupted Files, if there are any, as well as one of the initiating Agent's Warez' uncorrupted Files, if there are any, corrupted by a Virus.<br />
|-<br />
| Trojan horse || If a file is corrupted by a Trojan horse, its name is allowed to contain brackets. However, such a File may not contain a Program.<br />
|}<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page is gamestate and may not be altered except as specified by the ruleset or through the passage of a Proposal or CfJ; however, its contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Mainframe specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset; these rules must then be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Mainframe makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected. There are currently no Recommended Building Blocks.<br />
<br />
==No Private Communication==<br />
Agents may not privately communicate with each other about dynastic gameplay or votable matters that affect the dynastic ruleset or gamestate. Private communications are considered to be anything that any other Agent could not reasonably be privy to, perceive, or understand. Discussion conducted in plain English on the BlogNomic wiki and blog, and the #current-dynasty, #blognomic-general and #new-player-questions-and-mentorships Discord channels, are not considered to be private communication. Idle Agents (or people who are not yet Agents) also face the same restrictions if they intend to become an active Agent during the course of the dynasty. The use of creative strategies to circumvent this rule may be considered to be a scam for the purposes of determining whether an infraction of Fair Play has taken place.<br />
<br />
A mentor and mentee may still privately converse with each other, but should keep their conversations away from discussing specific gameplay strategy. This rule’s restrictions on communication do not apply during an Interregnum. The restrictions in this rule on communication in non-blognomic-related media shall not be construed as to cause those media to be gamestate.<br />
<br />
If information which was not allowed to be discussed is still privately discussed, the Agents who were part of the conversation should make a post to the blog disclosing what information was discussed as their earliest convenience.<br />
<br />
==Virtual Actions==<br />
A Virtual Action is a type of action that the Mainframe performs on behalf of an Agent. An Agent may initiate a virtual action by privately communicating to the Mainframe their request to do so, along with any additional information needed to carry it out. The Mainframe shall resolve the Virtual Action by performing the following Atomic Action:<br />
# Determine whether the Virtual Action fails (if it does not fail, it is successful).<br />
# If the action is successful, apply any specified effects on the gamestate and/or perform any specified actions on behalf of the Agent.<br />
<br />
If a Virtual Action fails, the Mainframe should tell the Agent why. A virtual action may fail for any of these reasons:<br />
* Some requirements/prerequisites to perform the action are not met.<br />
* The request does not contain all the information needed to resolve the action.<br />
* The request is unintelligible, or too vague to interpret unambiguously.<br />
* It would require the Mainframe to do something they cannot do.<br />
* Any other reason specified by the action itself.<br />
<br />
Except where otherwise stated by the ruleset, the Mainframe must resolve all virtual actions in the order that they are received. A virtual action is considered to have occurred at the time it was resolved.<br />
<br />
Until a virtual action is resolved, it is pending. An Agent may cancel a pending Virtual Action by privately communicating to the Mainframe their request to do so<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Agent per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Agent per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Agents.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Effective Vote Comment (EVC): An Agent's Effective Vote Comment with respect to a given Votable Matter is that Agent's Comment to that Votable Matter, if any, that contains that Agent's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Agents , as well as people who are not Agents but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Agents who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Agents are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the Dynastic Rules explicitly mention (except for dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Pass the Mantle: Passing the Mantle is a mechanism by which, during an Interregnum, a Mainframe may nominate another Agent to become the Mainframe in the upcoming dynasty. Unless a Core, Dynastic or Building Block rule explicitly states otherwise, Passing the Mantle is currently prohibited.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Mainframe.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Agents” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To Uphold an illegal action is to retroactively declare the attempt to take it to have been successful, and to declare that all attempted game actions taken after it were attempted as if the Upheld action had been successful.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Agent may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may be altered by its author if it is less than 4 hours old and either no Agent has commented on it or (if it is a Votable Matter) if all comments on it contain no voting icons; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Mainframe to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Mainframe may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of an Agent’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Agent may correct the representations to comply with the Gamestate.<br />
<br />
If an Agent feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Agent, if doing so would not require the correcting Agent to make any decisions on behalf of the original Agent.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Agents are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
An Agent may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name an Agent with such access. Only an Agent with such access may Enact that Votable Matter. If that Votable Matter does not name an Agent with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Agent making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Agent making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When an Agent performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete.<br />
* If a rule allows the Agent performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If an Agent arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Agent must redo the Atomic Action; for that purpose, the Agent uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Agent would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, an Agent can spend or pay from only their own values, and a rule that allows Agents to transfer or pay a numeric value to another Agent only allows them to transfer that value from themselves to that other Agent (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Agents are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Mainframe (including secretly random selections), then that information may only be revealed by the Mainframe when the ruleset allows it. If an Agent should already know such a piece of information (in that the Mainframe has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Mainframe may repeat it to them.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Agent may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Agents may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Mainframe has voted DEFERENTIAL on a Proposal, that vote is instead considered to be valid and either FOR (if more Agents have a valid FOR vote on that Proposal than have a valid AGAINST vote on it) or AGAINST (in all other cases). However, in either case, votes of DEFERENTIAL made by other Agents on the same Proposal are not considered to be valid. If there are six or fewer Agents, then the Mainframe’s vote of DEFERENTIAL on a proposal is only affected by this rule if all Agents who are not the Mainframe have cast a vote on that proposal.<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* An Agent may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Agents may correct obvious spelling, punctuation, and/or typographical mistakes in the Ruleset and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Agents with the corresponding forms of the singular “they”.<br />
* An Agent may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, an Agent's (or prospective Agent's ) new name must be between 4 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Agents may Kick each other” and “Agents may not Kick each other on Tuesdays” exist, and it is Tuesday, Agents may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Agents may Punch a Spaceman on Friday” and “Agents may not Punch Spacemen on Friday”, then Agents may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
An Agent may have another Agent as a Mentor. Agents who are willing to act as a Mentor are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of an Agent who has requested a change on their own behalf, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Agent requests a Mentor, or a new Agent has joined the game and has no Mentor, the Mainframe should select a Tenured Agent and ask them to take that Agent on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Mainframe should announce it in a blog post. The Mainframe should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. An Agent may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Mainframe, any Agent who has been active in at least three previous dynasties may act as Mainframe for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Agent or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Agents .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Agent” and “Mainframe”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Agent (Player)<br />
* Mainframe (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25500The Database2024-01-31T18:29:59Z<p>Zack: Create new client</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Client Names<br />
|-<br />
| The Gibson<br />
|-<br />
| _Mel<br />
|-<br />
| jumpbox<br />
|-<br />
| Lilac<br />
|-<br />
| monkey<br />
|-<br />
| Dark Web<br />
|-<br />
| ERROR<br />
|}</div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=25499Ruleset2024-01-31T18:00:15Z<p>Zack: /* Recharge */ Add flair</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Agents shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Agent may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[The Database]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Agents ==<br />
A human with access to the blog who is not already an Agent may make a blog post making clear their wish to be an Agent (plural form Agents); in response, an Admin shall add them to the roster in the sidebar, at which moment they become an Agent. (See the [[FAQ#Can_I_join_in.3F|FAQ]] for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
An Agent may only change their name as a result of a Proposal approving the change.<br />
<br />
Some Agents are '''Admins''', responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. Agents may be made Admins through Proposal or CFJ.<br />
<br />
An Agent may cease to be an Agent at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be an Agent in this way may not become an Agent again within the following two weeks.<br />
<br />
===Idle Agents ===<br />
<br />
If an Agent is Idle, this is tracked by their name being removed or concealed in the list of currently active Agents in the Sidebar. For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Agents ”, “Dynasties”, “Fair Play”, "Mentors" and any of those Rules’ subrules, Idle Agents are not counted as Agents . The combined term “Idle Agent” can be used to refer to Agents who are Idle even in rules that do not treat them as Agents.<br />
<br />
If a Proposal contains a provision that targets a specifically named Idle Agent, then that Idle Agent is considered to be Unidle solely for the purposes of enacting that specific provision.<br />
<br />
When an Agent is unidled, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Agent Idled in a different Dynasty), the Agent is given the default value for new Agents, if such a value exists.<br />
<br />
An Admin may render an Agent Idle if that Agent has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Agent has not posted an entry or comment in the past 168 Hours (7 days). In the latter case, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Agent during the current and subsequent dynasty. Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so. An Admin may Unidle an Agent if that Agent is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may Unidle themselves at any time, unless the Agent who would be Unidled has become Idle within the past 96 hours (4 days), and within the current Dynasty.<br />
<br />
Admins who are unidling themselves should, in their first vote following each unidling, highlight their changed idle status and any changes to Quorum to have come about as a result of it.<br />
<br />
Idle admins can resolve Votable Matters as a non-idle admin would.<br />
<br />
===Dormancy===<br />
If there are fewer than four Agents (not including the Mainframe), then BlogNomic is on Hiatus.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Agent, known as the Mainframe. If there is no Mainframe, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before an Ascension Address has been posted. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Agent may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Mainframe is not an Agent.<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Agents may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Agent may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. An Agent's Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Agent never has a Vote, even if they were an Agent previously and had cast a valid Vote.<br />
<br />
If an Agent other than the Mainframe casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Mainframe. When the Mainframe has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Mainframe's Vote for the purposes of other rules unless otherwise specified. When the Mainframe themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Agents who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Agent may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Agent already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When an Agent casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Mainframe may use VETO as a voting icon to cast a Vote on a Proposal; when the Mainframe casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Mainframe later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Agent A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If an Agent (other than the Mainframe) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
An Agent's vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Agent may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, it has been open for at least 12 hours, and either the Mainframe has Voted FOR it or it has no AGAINST Votes.<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, and it has been open for at least 24 hours.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Agent who posted the DoV becomes Mainframe, and the game enters an Interregnum. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Mainframe must either Pass the Mantle (by making a post naming an Agent who was not the last dynasty’s Mainframe, in which case the passing Agent ceases to be the Mainframe and the Agent so named becomes the Mainframe) or start a new dynasty by completing the following Atomic Action:<br />
* Make an Ascension Address by posting an entry in the “Ascension Address” category. This should specify the Mainframe's chosen theme for the new Dynasty, and it may optionally specify new dynasty-specific terms as outline in the rule "Synonyms", and/or list a number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed).<br />
* Optionally specify any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section.<br />
* Update the Ruleset to reflect any changed terms, repeal any dynastic rules which were not listed to be kept, and make any specified or automatic changes to the Building Blocks section of the ruleset. Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Optionally change the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if an Agent's behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Agents should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Agent within BlogNomic, and should announce publicly if they control both a non-Idle Agent and any Idle Agents. This extends to exerting full control over the actions of another Agent, defined here as the controlled Agent's game behavior being functionally indistinguishable from if the controlling Agent was logged into their account and playing through it, over a period of more than a day.<br />
* An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* An Agent should not edit their own blog comments once posted, nor those of any other Agent.<br />
* An Agent should not edit the “Entry Date” field of a blog post.<br />
* An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* An Agent should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. an Agent must use their own name in the Dice Roller, when rolling dice.<br />
* An Agent should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* An Agent should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause an Agent to achieve victory.<br />
* An Agent should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Agent or Agents to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Agents and idle Agents should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Agents are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
<br />
==The Mainframe==<br />
'''The Mainframe''' is a strong AI with advanced natural language capabilities. All dynastic gamestate is secretly tracked by the Mainframe unless otherwise stated, or where it would be impossible.<br />
<br />
The Mainframe shall assign each Agent an '''IP address''' in the form #.#.#.# where each # is a number from 1-255. If any Agent has not been assigned an IP, the Mainframe should secretly randomly assign them one before performing any dynastic actions.<br />
<br />
Each Agent has a number named '''CPU Cycles''' which defaults to 1.<br />
<br />
Communication between Agents that is facilitated by the Mainframe is exempt from the restrictions described in the rule “No Private Communications”.<br />
<br />
==Clients==<br />
There may be any number of '''Clients'''. Each Client has a unique Name and a Passcode, which are strings of 4-16 characters containing only letters, numbers, and underscores. Names are not case-sensitive but Passcodes are. Client Names are publicly tracked in the Database.<br />
<br />
As a weekly virtual action, an Agent may '''create a new Client''' by specifying the desired Name and Passcode for the Client. This may be re-attempted if the action fails.<br />
<br />
Each Client has a list of Files, defaulting to an empty list.<br />
<br />
A '''Brute Force Attempt''' is a pairing of a number named Progress and the name of an Agent. Each Client has a list of Brute Force Attempts, defaulting to an empty list.<br />
<br />
A '''Passcode Complexity''' is a derived value that equals the number of characters a Client's Passcode has, multiplied by how many of the following criteria (which should be a number from 1 to 3) one or more of its characters meets: lowercase letters, uppercase letters, numbers.<br />
<br />
===Connections===<br />
An Agent may be '''connected''' to any number of Clients. A connection is a relationship between exactly one Agent and one Client.<br />
<br />
As a virtual action, an Agent may '''connect to a Client''' by specifying exactly one Client Name and Passcode pair. If the Passcode is correct for the specified Client, the Agent becomes connected to that Client.<br />
<br />
As a virtual action, an Agent may '''disconnect from a Client''' by specifying a client they are connected to, at which point the Agent is no longer connected to that Client.<br />
<br />
===The Dark Web===<br />
There is a Client named '''Dark Web''' with the Passcode '''1337''' and the following '''Files''':<br />
<br />
* BackOrifice<br />
* MyDoom<br />
* Klex<br />
* StuxNet<br />
* WannaCry<br />
<br />
The Dark Web may not '''brute force'''.<br />
<br />
===Power===<br />
Each client except the Dark Web has '''Power''', which is an integer between 0 and 100 inclusive and defaults to 50. Every time a Client other than the Dark Web performs a successful '''Shell Command''' its Power is reduced by the '''Power Consumption''' of that Shell Command, to a minimum of 0.<br />
<br />
==Shell Commands==<br />
A '''Shell Command''' is a type of Virtual Action that the Mainframe performs as a Client on behalf of an Agent. For the purposes of resolving Shell Commands, a Client is considered an Agent; The Client serves as a proxy for the Agent who initiated the command.<br />
<br />
An Agent must be connected to a Client to perform Shell Commands as that Client. ''To perform a Shell Command, you must always specify exactly one Client that you are connected to, or the action fails.'' Each Shell Command has a '''Power Consumption''', which is a non-negative integer and by default 10. If a Client (other than the Dark Web) tries to perform a Shell Command whose Power Consumption is greater than that Client’s Power, it will fail.<br />
<br />
The definition of a Shell Command should be contained within the “Shell command” flair; If one is not, the Mainframe may edit the ruleset to make it so.<br />
<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client can '''ping''' the Mainframe. The Mainframe will respond to confirm that it is online.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Logging===<br />
The Mainframe shall maintain a '''log''' of successful Shell Commands. Each new log entry shall include:<br />
* the time/date it occurred<br />
* the IP of the initiating Agent<br />
* the name of the Client<br />
* the type of command<br />
* any other data the command specifies to be logged<br />
<br />
{{Flair top|Shell command}}<br />
As a shell command, a Client may '''request a copy of logs''' within a particular scope (e.g. a certain timeframe, logs associated with a certain IP, etc). Each log entry will be accompanied by an MD5 hash of the entry by which it can be identified.<br />
<br />
If the Client does not have access to all of the logs in the desired scope, the action will fail. By default, a Client only has access to the logs of actions performed by that particular Client.<br />
<br />
'''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
===Downloading===<br />
Each Agent has '''Warez''', which is a list of Files, defaulting to an empty list.<br />
<br />
{{Flair top|Shell command}}<br />
If a Client has one or more Files, as a Daily Shell Command, that Client may '''download file''' with the name of the File to download. If the File does not already exist in that Agent's Warez, it is added to the Warez of the Agent performing this command, otherwise the command fails. This command may be re-attempted if it failed.<br />
{{Flair bottom}}<br />
<br />
===Brute Force===<br />
{{Flair top|Shell command}}<br />
As a Daily Shell Command, a Client may brute force a Target, specifying the name of another Client. If the Target does not have a Brute Force Attempt which names the Agent performing the command, the Mainframe will create a new Brute Force Attempt on the Target Client with the Agent’s name and a Progress of 0.<br />
<br />
The Mainframe will increase the Progress of the Agent’s Brute Force Attempt on the Target Client by the Agent’s CPU Cycles.<br />
* If the entry’s Progress is greater than or equal to the Target’s Passcode Complexity, the Mainframe shall secretly communicate the Target’s Passcode to the Agent.<br />
* Otherwise, the Mainframe shall inform the Agent of the current Progress of their Brute Force Attempt on the Target.<br />
<br />
The Mainframe will include the name of the Target and the current Progress of the attempt in the log of the action.<br />
{{Flair bottom}}<br />
<br />
===Recharge===<br />
{{Flair top|Shell command}}<br />
As a weekly Shell Command, a Client may '''recharge'''. The Mainframe will set that Client’s Power to 100. '''Power Consumption''': 0<br />
{{Flair bottom}}<br />
<br />
==Best Practices==<br />
{{Flair top|Shell command}}<br />
As a weekly Shell Command, a client may '''change passcode'''. The Client specifies a new valid Passcode and the Client's Passcode is changed to the new value. After this command executes, all Connections to the Client are removed. The Client's Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.<br />
{{Flair bottom}}<br />
<br />
==Files==<br />
A '''File''' consists of:<br />
* A '''name''', which is a string defaulting to "untitled"<br />
* Optionally one '''Program''' from the table “Programs”<br />
<br />
If a File contains a Program, the Type of the Program must be included in its name in brackets. Only Files with a Program may have brackets in their names, unless otherwise stated by the ruleset.<br />
<br />
{| class="wikitable"<br />
|+ Programs<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Anti-malware || When this File is executed, you may '''scan''' all files in your Warez. The Mainframe will respond with the number of corrupted Files in your Warez plus a privately randomly generated number between -2 and 2, inclusive, to a minimum of zero.<br />
|-<br />
| Firewall || Whenever you '''download''' a File, if the File is '''corrupted''', the Mainframe must privately randomly determine whether the File actually is downloaded or not, with both options being equally likely.<br />
|}<br />
<br />
The Effects of a Program only apply to Agents who have at least one File with that Program in their Warez. As a daily virtual action, an Agent may '''execute''' a File by specifying the name of exactly one File in their Warez. This may be re-attempted if the action fails.<br />
<br />
===Malware===<br />
An instance of a File in a list may be '''corrupted''' by none or more of the '''Malware''' described in the table below, defaulting to none. Whenever an Agent downloads a corrupted File, the File added to the Agent’s Warez will also be corrupted by the same Malware.<br />
<br />
{| class="wikitable"<br />
|+ Malware<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Virus || Whenever a Client performs a Shell Command, if the initiating Agent's Warez contains a File corrupted by a Virus, the Mainframe must make one of the Client's uncorrupted Files, if there are any, as well as one of the initiating Agent's Warez' uncorrupted Files, if there are any, corrupted by a Virus.<br />
|-<br />
| Trojan horse || If a file is corrupted by a Trojan horse, its name is allowed to contain brackets. However, such a File may not contain a Program.<br />
|}<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page is gamestate and may not be altered except as specified by the ruleset or through the passage of a Proposal or CfJ; however, its contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Mainframe specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset; these rules must then be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Mainframe makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected. There are currently no Recommended Building Blocks.<br />
<br />
==No Private Communication==<br />
Agents may not privately communicate with each other about dynastic gameplay or votable matters that affect the dynastic ruleset or gamestate. Private communications are considered to be anything that any other Agent could not reasonably be privy to, perceive, or understand. Discussion conducted in plain English on the BlogNomic wiki and blog, and the #current-dynasty, #blognomic-general and #new-player-questions-and-mentorships Discord channels, are not considered to be private communication. Idle Agents (or people who are not yet Agents) also face the same restrictions if they intend to become an active Agent during the course of the dynasty. The use of creative strategies to circumvent this rule may be considered to be a scam for the purposes of determining whether an infraction of Fair Play has taken place.<br />
<br />
A mentor and mentee may still privately converse with each other, but should keep their conversations away from discussing specific gameplay strategy. This rule’s restrictions on communication do not apply during an Interregnum. The restrictions in this rule on communication in non-blognomic-related media shall not be construed as to cause those media to be gamestate.<br />
<br />
If information which was not allowed to be discussed is still privately discussed, the Agents who were part of the conversation should make a post to the blog disclosing what information was discussed as their earliest convenience.<br />
<br />
==Virtual Actions==<br />
A Virtual Action is a type of action that the Mainframe performs on behalf of an Agent. An Agent may initiate a virtual action by privately communicating to the Mainframe their request to do so, along with any additional information needed to carry it out. The Mainframe shall resolve the Virtual Action by performing the following Atomic Action:<br />
# Determine whether the Virtual Action fails (if it does not fail, it is successful).<br />
# If the action is successful, apply any specified effects on the gamestate and/or perform any specified actions on behalf of the Agent.<br />
<br />
If a Virtual Action fails, the Mainframe should tell the Agent why. A virtual action may fail for any of these reasons:<br />
* Some requirements/prerequisites to perform the action are not met.<br />
* The request does not contain all the information needed to resolve the action.<br />
* The request is unintelligible, or too vague to interpret unambiguously.<br />
* It would require the Mainframe to do something they cannot do.<br />
* Any other reason specified by the action itself.<br />
<br />
Except where otherwise stated by the ruleset, the Mainframe must resolve all virtual actions in the order that they are received. A virtual action is considered to have occurred at the time it was resolved.<br />
<br />
Until a virtual action is resolved, it is pending. An Agent may cancel a pending Virtual Action by privately communicating to the Mainframe their request to do so<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Agent per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Agent per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Agents.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Effective Vote Comment (EVC): An Agent's Effective Vote Comment with respect to a given Votable Matter is that Agent's Comment to that Votable Matter, if any, that contains that Agent's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Agents , as well as people who are not Agents but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Agents who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Agents are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the Dynastic Rules explicitly mention (except for dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Pass the Mantle: Passing the Mantle is a mechanism by which, during an Interregnum, a Mainframe may nominate another Agent to become the Mainframe in the upcoming dynasty. Unless a Core, Dynastic or Building Block rule explicitly states otherwise, Passing the Mantle is currently prohibited.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Mainframe.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Agents” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To Uphold an illegal action is to retroactively declare the attempt to take it to have been successful, and to declare that all attempted game actions taken after it were attempted as if the Upheld action had been successful.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Agent may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may be altered by its author if it is less than 4 hours old and either no Agent has commented on it or (if it is a Votable Matter) if all comments on it contain no voting icons; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Mainframe to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Mainframe may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of an Agent’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Agent may correct the representations to comply with the Gamestate.<br />
<br />
If an Agent feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Agent, if doing so would not require the correcting Agent to make any decisions on behalf of the original Agent.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Agents are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
An Agent may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name an Agent with such access. Only an Agent with such access may Enact that Votable Matter. If that Votable Matter does not name an Agent with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Agent making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Agent making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When an Agent performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete.<br />
* If a rule allows the Agent performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If an Agent arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Agent must redo the Atomic Action; for that purpose, the Agent uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Agent would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, an Agent can spend or pay from only their own values, and a rule that allows Agents to transfer or pay a numeric value to another Agent only allows them to transfer that value from themselves to that other Agent (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Agents are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Mainframe (including secretly random selections), then that information may only be revealed by the Mainframe when the ruleset allows it. If an Agent should already know such a piece of information (in that the Mainframe has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Mainframe may repeat it to them.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Agent may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Agents may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Mainframe has voted DEFERENTIAL on a Proposal, that vote is instead considered to be valid and either FOR (if more Agents have a valid FOR vote on that Proposal than have a valid AGAINST vote on it) or AGAINST (in all other cases). However, in either case, votes of DEFERENTIAL made by other Agents on the same Proposal are not considered to be valid. If there are six or fewer Agents, then the Mainframe’s vote of DEFERENTIAL on a proposal is only affected by this rule if all Agents who are not the Mainframe have cast a vote on that proposal.<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* An Agent may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Agents may correct obvious spelling, punctuation, and/or typographical mistakes in the Ruleset and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Agents with the corresponding forms of the singular “they”.<br />
* An Agent may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, an Agent's (or prospective Agent's ) new name must be between 4 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Agents may Kick each other” and “Agents may not Kick each other on Tuesdays” exist, and it is Tuesday, Agents may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Agents may Punch a Spaceman on Friday” and “Agents may not Punch Spacemen on Friday”, then Agents may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
An Agent may have another Agent as a Mentor. Agents who are willing to act as a Mentor are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of an Agent who has requested a change on their own behalf, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Agent requests a Mentor, or a new Agent has joined the game and has no Mentor, the Mainframe should select a Tenured Agent and ask them to take that Agent on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Mainframe should announce it in a blog post. The Mainframe should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. An Agent may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Mainframe, any Agent who has been active in at least three previous dynasties may act as Mainframe for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Agent or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Agents .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Agent” and “Mainframe”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Agent (Player)<br />
* Mainframe (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=25497Ruleset2024-01-30T20:56:35Z<p>Zack: /* Brute Force */ Enacting "Cracking Continued"</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Agents shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Agent may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[The Database]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Agents ==<br />
A human with access to the blog who is not already an Agent may make a blog post making clear their wish to be an Agent (plural form Agents); in response, an Admin shall add them to the roster in the sidebar, at which moment they become an Agent. (See the [[FAQ#Can_I_join_in.3F|FAQ]] for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
An Agent may only change their name as a result of a Proposal approving the change.<br />
<br />
Some Agents are '''Admins''', responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. Agents may be made Admins through Proposal or CFJ.<br />
<br />
An Agent may cease to be an Agent at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be an Agent in this way may not become an Agent again within the following two weeks.<br />
<br />
===Idle Agents ===<br />
<br />
If an Agent is Idle, this is tracked by their name being removed or concealed in the list of currently active Agents in the Sidebar. For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Agents ”, “Dynasties”, “Fair Play”, "Mentors" and any of those Rules’ subrules, Idle Agents are not counted as Agents . The combined term “Idle Agent” can be used to refer to Agents who are Idle even in rules that do not treat them as Agents.<br />
<br />
If a Proposal contains a provision that targets a specifically named Idle Agent, then that Idle Agent is considered to be Unidle solely for the purposes of enacting that specific provision.<br />
<br />
When an Agent is unidled, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Agent Idled in a different Dynasty), the Agent is given the default value for new Agents, if such a value exists.<br />
<br />
An Admin may render an Agent Idle if that Agent has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Agent has not posted an entry or comment in the past 168 Hours (7 days). In the latter case, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Agent during the current and subsequent dynasty. Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so. An Admin may Unidle an Agent if that Agent is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may Unidle themselves at any time, unless the Agent who would be Unidled has become Idle within the past 96 hours (4 days), and within the current Dynasty.<br />
<br />
Admins who are unidling themselves should, in their first vote following each unidling, highlight their changed idle status and any changes to Quorum to have come about as a result of it.<br />
<br />
Idle admins can resolve Votable Matters as a non-idle admin would.<br />
<br />
===Dormancy===<br />
If there are fewer than four Agents (not including the Mainframe), then BlogNomic is on Hiatus.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Agent, known as the Mainframe. If there is no Mainframe, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before an Ascension Address has been posted. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Agent may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Mainframe is not an Agent.<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Agents may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Agent may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. An Agent's Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Agent never has a Vote, even if they were an Agent previously and had cast a valid Vote.<br />
<br />
If an Agent other than the Mainframe casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Mainframe. When the Mainframe has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Mainframe's Vote for the purposes of other rules unless otherwise specified. When the Mainframe themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Agents who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Agent may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Agent already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When an Agent casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Mainframe may use VETO as a voting icon to cast a Vote on a Proposal; when the Mainframe casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Mainframe later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Agent A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If an Agent (other than the Mainframe) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
An Agent's vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Agent may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, it has been open for at least 12 hours, and either the Mainframe has Voted FOR it or it has no AGAINST Votes.<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, and it has been open for at least 24 hours.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Agent who posted the DoV becomes Mainframe, and the game enters an Interregnum. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Mainframe must either Pass the Mantle (by making a post naming an Agent who was not the last dynasty’s Mainframe, in which case the passing Agent ceases to be the Mainframe and the Agent so named becomes the Mainframe) or start a new dynasty by completing the following Atomic Action:<br />
* Make an Ascension Address by posting an entry in the “Ascension Address” category. This should specify the Mainframe's chosen theme for the new Dynasty, and it may optionally specify new dynasty-specific terms as outline in the rule "Synonyms", and/or list a number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed).<br />
* Optionally specify any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section.<br />
* Update the Ruleset to reflect any changed terms, repeal any dynastic rules which were not listed to be kept, and make any specified or automatic changes to the Building Blocks section of the ruleset. Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Optionally change the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if an Agent's behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Agents should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Agent within BlogNomic, and should announce publicly if they control both a non-Idle Agent and any Idle Agents. This extends to exerting full control over the actions of another Agent, defined here as the controlled Agent's game behavior being functionally indistinguishable from if the controlling Agent was logged into their account and playing through it, over a period of more than a day.<br />
* An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* An Agent should not edit their own blog comments once posted, nor those of any other Agent.<br />
* An Agent should not edit the “Entry Date” field of a blog post.<br />
* An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* An Agent should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. an Agent must use their own name in the Dice Roller, when rolling dice.<br />
* An Agent should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* An Agent should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause an Agent to achieve victory.<br />
* An Agent should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Agent or Agents to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Agents and idle Agents should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Agents are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
<br />
==The Mainframe==<br />
'''The Mainframe''' is a strong AI with advanced natural language capabilities. All dynastic gamestate is secretly tracked by the Mainframe unless otherwise stated, or where it would be impossible.<br />
<br />
The Mainframe shall assign each Agent an '''IP address''' in the form #.#.#.# where each # is a number from 1-255. If any Agent has not been assigned an IP, the Mainframe should secretly randomly assign them one before performing any dynastic actions.<br />
<br />
Each Agent has a number named '''CPU Cycles''' which defaults to 1.<br />
<br />
Communication between Agents that is facilitated by the Mainframe is exempt from the restrictions described in the rule “No Private Communications”.<br />
<br />
==Clients==<br />
There may be any number of '''Clients'''. Each Client has a unique Name and a Passcode, which are strings of 4-16 characters containing only letters, numbers, and underscores. Names are not case-sensitive but Passcodes are. Client Names are publicly tracked in the Database.<br />
<br />
As a weekly virtual action, an Agent may '''create a new Client''' by specifying the desired Name and Passcode for the Client. This may be re-attempted if the action fails.<br />
<br />
Each Client has a list of Files, defaulting to an empty list.<br />
<br />
A '''Brute Force Attempt''' is a pairing of a number named Progress and the name of an Agent. Each Client has a list of Brute Force Attempts, defaulting to an empty list.<br />
<br />
A '''Passcode Complexity''' is a derived value that equals the number of characters a Client's Passcode has, multiplied by how many of the following criteria (which should be a number from 1 to 3) one or more of its characters meets: lowercase letters, uppercase letters, numbers.<br />
<br />
===Connections===<br />
An Agent may be '''connected''' to any number of Clients. A connection is a relationship between exactly one Agent and one Client.<br />
<br />
As a virtual action, an Agent may '''connect to a Client''' by specifying exactly one Client Name and Passcode pair. If the Passcode is correct for the specified Client, the Agent becomes connected to that Client.<br />
<br />
As a virtual action, an Agent may '''disconnect from a Client''' by specifying a client they are connected to, at which point the Agent is no longer connected to that Client.<br />
<br />
===The Dark Web===<br />
There is a Client named '''Dark Web''' with the Passcode '''1337''' and the following '''Files''':<br />
<br />
* BackOrifice<br />
* MyDoom<br />
* Klex<br />
* StuxNet<br />
* WannaCry<br />
<br />
==Shell Commands==<br />
A '''Shell Command''' is a type of Virtual Action that the Mainframe performs as a Client on behalf of an Agent. For the purposes of resolving Shell Commands, a Client is considered an Agent; The Client serves as a proxy for the Agent who initiated the command.<br />
<br />
An Agent must be connected to a Client to perform Shell Commands as that Client. ''To perform a Shell Command, you must always specify exactly one Client that you are connected to, or the action fails.''<br />
<br />
The definition of a Shell Command should be contained within the “Shell command” flair; If one is not, the Mainframe may edit the ruleset to make it so.<br />
<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client can '''ping''' the Mainframe. The Mainframe will respond to confirm that it is online.<br />
{{Flair bottom}}<br />
<br />
===Logging===<br />
The Mainframe shall maintain a '''log''' of successful Shell Commands. Each new log entry shall include:<br />
* the time/date it occurred<br />
* the IP of the initiating Agent<br />
* the name of the Client<br />
* the type of command<br />
* any other data the command specifies to be logged<br />
<br />
{{Flair top|Shell command}}<br />
As a shell command, a Client may '''request a copy of logs''' within a particular scope (e.g. a certain timeframe, logs associated with a certain IP, etc). Each log entry will be accompanied by an MD5 hash of the entry by which it can be identified.<br />
<br />
If the Client does not have access to all of the logs in the desired scope, the action will fail. By default, a Client only has access to the logs of actions performed by that particular Client.<br />
{{Flair bottom}}<br />
<br />
===Downloading===<br />
Each Agent has '''Warez''', which is a list of Files, defaulting to an empty list.<br />
<br />
{{Flair top|Shell command}}<br />
If a Client has one or more Files, as a Daily Shell Command, that Client may '''download file''' with the name of the File to download. If the File does not already exist in that Agent's Warez, it is added to the Warez of the Agent performing this command, otherwise the command fails. This command may be re-attempted if it failed.<br />
{{Flair bottom}}<br />
<br />
===Brute Force===<br />
{{Flair top|Shell command}}<br />
As a Daily Shell Command, a Client may brute force a Target, specifying the name of another Client. If the Target does not have a Brute Force Attempt which names the Agent performing the command, the Mainframe will create a new Brute Force Attempt on the Target Client with the Agent’s name and a Progress of 0.<br />
<br />
The Mainframe will increase the Progress of the Agent’s Brute Force Attempt on the Target Client by the Agent’s CPU Cycles.<br />
* If the entry’s Progress is greater than or equal to the Target’s Passcode Complexity, the Mainframe shall secretly communicate the Target’s Passcode to the Agent.<br />
* Otherwise, the Mainframe shall inform the Agent of the current Progress of their Brute Force Attempt on the Target.<br />
<br />
The Mainframe will include the name of the Target and the current Progress of the attempt in the log of the action.<br />
{{Flair bottom}}<br />
<br />
==Best Practices==<br />
{{Flair top|Shell command}}<br />
As a weekly Shell Command, a client may '''change passcode'''. The Client specifies a new valid Passcode and the Client's Passcode is changed to the new value. After this command executes, all Connections to the Client are removed. The Client's Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.<br />
{{Flair bottom}}<br />
<br />
==Files==<br />
A '''File''' consists of:<br />
* A '''name''', which is a string defaulting to "untitled"<br />
* Optionally one '''Program''' from the table “Programs”<br />
<br />
If a File contains a Program, the Type of the Program must be included in its name in brackets. Only Files with a Program may have brackets in their names, unless otherwise stated by the ruleset.<br />
<br />
{| class="wikitable"<br />
|+ Programs<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Anti-malware || When this File is executed, you may '''scan''' all files in your Warez. The Mainframe will respond with the number of corrupted Files in your Warez plus a privately randomly generated number between -2 and 2, inclusive, to a minimum of zero.<br />
|-<br />
| Firewall || Whenever you '''download''' a File, if the File is '''corrupted''', the Mainframe must privately randomly determine whether the File actually is downloaded or not, with both options being equally likely.<br />
|}<br />
<br />
The Effects of a Program only apply to Agents who have at least one File with that Program in their Warez. As a daily virtual action, an Agent may '''execute''' a File by specifying the name of exactly one File in their Warez. This may be re-attempted if the action fails.<br />
<br />
===Malware===<br />
An instance of a File in a list may be '''corrupted''' by none or more of the '''Malware''' described in the table below, defaulting to none. Whenever an Agent downloads a corrupted File, the File added to the Agent’s Warez will also be corrupted by the same Malware.<br />
<br />
{| class="wikitable"<br />
|+ Malware<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Virus || Whenever a Client performs a Shell Command, if the initiating Agent's Warez contains a File corrupted by a Virus, the Mainframe must make one of the Client's uncorrupted Files, if there are any, as well as one of the initiating Agent's Warez' uncorrupted Files, if there are any, corrupted by a Virus.<br />
|-<br />
| Trojan horse || If a file is corrupted by a Trojan horse, its name is allowed to contain brackets. However, such a File may not contain a Program.<br />
|}<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page is gamestate and may not be altered except as specified by the ruleset or through the passage of a Proposal or CfJ; however, its contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Mainframe specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset; these rules must then be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Mainframe makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected. There are currently no Recommended Building Blocks.<br />
<br />
==No Private Communication==<br />
Agents may not privately communicate with each other about dynastic gameplay or votable matters that affect the dynastic ruleset or gamestate. Private communications are considered to be anything that any other Agent could not reasonably be privy to, perceive, or understand. Discussion conducted in plain English on the BlogNomic wiki and blog, and the #current-dynasty, #blognomic-general and #new-player-questions-and-mentorships Discord channels, are not considered to be private communication. Idle Agents (or people who are not yet Agents) also face the same restrictions if they intend to become an active Agent during the course of the dynasty. The use of creative strategies to circumvent this rule may be considered to be a scam for the purposes of determining whether an infraction of Fair Play has taken place.<br />
<br />
A mentor and mentee may still privately converse with each other, but should keep their conversations away from discussing specific gameplay strategy. This rule’s restrictions on communication do not apply during an Interregnum. The restrictions in this rule on communication in non-blognomic-related media shall not be construed as to cause those media to be gamestate.<br />
<br />
If information which was not allowed to be discussed is still privately discussed, the Agents who were part of the conversation should make a post to the blog disclosing what information was discussed as their earliest convenience.<br />
<br />
==Virtual Actions==<br />
A Virtual Action is a type of action that the Mainframe performs on behalf of an Agent. An Agent may initiate a virtual action by privately communicating to the Mainframe their request to do so, along with any additional information needed to carry it out. The Mainframe shall resolve the Virtual Action by performing the following Atomic Action:<br />
# Determine whether the Virtual Action fails (if it does not fail, it is successful).<br />
# If the action is successful, apply any specified effects on the gamestate and/or perform any specified actions on behalf of the Agent.<br />
<br />
If a Virtual Action fails, the Mainframe should tell the Agent why. A virtual action may fail for any of these reasons:<br />
* Some requirements/prerequisites to perform the action are not met.<br />
* The request does not contain all the information needed to resolve the action.<br />
* The request is unintelligible, or too vague to interpret unambiguously.<br />
* It would require the Mainframe to do something they cannot do.<br />
* Any other reason specified by the action itself.<br />
<br />
Except where otherwise stated by the ruleset, the Mainframe must resolve all virtual actions in the order that they are received. A virtual action is considered to have occurred at the time it was resolved.<br />
<br />
Until a virtual action is resolved, it is pending. An Agent may cancel a pending Virtual Action by privately communicating to the Mainframe their request to do so<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Agent per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Agent per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Agents.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Effective Vote Comment (EVC): An Agent's Effective Vote Comment with respect to a given Votable Matter is that Agent's Comment to that Votable Matter, if any, that contains that Agent's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Agents , as well as people who are not Agents but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Agents who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Agents are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the Dynastic Rules explicitly mention (except for dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Pass the Mantle: Passing the Mantle is a mechanism by which, during an Interregnum, a Mainframe may nominate another Agent to become the Mainframe in the upcoming dynasty. Unless a Core, Dynastic or Building Block rule explicitly states otherwise, Passing the Mantle is currently prohibited.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Mainframe.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Agents” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To Uphold an illegal action is to retroactively declare the attempt to take it to have been successful, and to declare that all attempted game actions taken after it were attempted as if the Upheld action had been successful.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Agent may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may be altered by its author if it is less than 4 hours old and either no Agent has commented on it or (if it is a Votable Matter) if all comments on it contain no voting icons; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Mainframe to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Mainframe may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of an Agent’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Agent may correct the representations to comply with the Gamestate.<br />
<br />
If an Agent feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Agent, if doing so would not require the correcting Agent to make any decisions on behalf of the original Agent.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Agents are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
An Agent may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name an Agent with such access. Only an Agent with such access may Enact that Votable Matter. If that Votable Matter does not name an Agent with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Agent making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Agent making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When an Agent performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete.<br />
* If a rule allows the Agent performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If an Agent arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Agent must redo the Atomic Action; for that purpose, the Agent uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Agent would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, an Agent can spend or pay from only their own values, and a rule that allows Agents to transfer or pay a numeric value to another Agent only allows them to transfer that value from themselves to that other Agent (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Agents are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Mainframe (including secretly random selections), then that information may only be revealed by the Mainframe when the ruleset allows it. If an Agent should already know such a piece of information (in that the Mainframe has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Mainframe may repeat it to them.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Agent may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Agents may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Mainframe has voted DEFERENTIAL on a Proposal, that vote is instead considered to be valid and either FOR (if more Agents have a valid FOR vote on that Proposal than have a valid AGAINST vote on it) or AGAINST (in all other cases). However, in either case, votes of DEFERENTIAL made by other Agents on the same Proposal are not considered to be valid. If there are six or fewer Agents, then the Mainframe’s vote of DEFERENTIAL on a proposal is only affected by this rule if all Agents who are not the Mainframe have cast a vote on that proposal.<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* An Agent may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Agents may correct obvious spelling, punctuation, and/or typographical mistakes in the Ruleset and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Agents with the corresponding forms of the singular “they”.<br />
* An Agent may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, an Agent's (or prospective Agent's ) new name must be between 4 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Agents may Kick each other” and “Agents may not Kick each other on Tuesdays” exist, and it is Tuesday, Agents may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Agents may Punch a Spaceman on Friday” and “Agents may not Punch Spacemen on Friday”, then Agents may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
An Agent may have another Agent as a Mentor. Agents who are willing to act as a Mentor are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of an Agent who has requested a change on their own behalf, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Agent requests a Mentor, or a new Agent has joined the game and has no Mentor, the Mainframe should select a Tenured Agent and ask them to take that Agent on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Mainframe should announce it in a blog post. The Mainframe should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. An Agent may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Mainframe, any Agent who has been active in at least three previous dynasties may act as Mainframe for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Agent or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Agents .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Agent” and “Mainframe”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Agent (Player)<br />
* Mainframe (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=25495Ruleset2024-01-29T19:44:48Z<p>Zack: /* Best Practices */ Add flair</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Agents shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Agent may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[The Database]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Agents ==<br />
A human with access to the blog who is not already an Agent may make a blog post making clear their wish to be an Agent (plural form Agents); in response, an Admin shall add them to the roster in the sidebar, at which moment they become an Agent. (See the [[FAQ#Can_I_join_in.3F|FAQ]] for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
An Agent may only change their name as a result of a Proposal approving the change.<br />
<br />
Some Agents are '''Admins''', responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. Agents may be made Admins through Proposal or CFJ.<br />
<br />
An Agent may cease to be an Agent at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be an Agent in this way may not become an Agent again within the following two weeks.<br />
<br />
===Idle Agents ===<br />
<br />
If an Agent is Idle, this is tracked by their name being removed or concealed in the list of currently active Agents in the Sidebar. For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Agents ”, “Dynasties”, “Fair Play”, "Mentors" and any of those Rules’ subrules, Idle Agents are not counted as Agents . The combined term “Idle Agent” can be used to refer to Agents who are Idle even in rules that do not treat them as Agents.<br />
<br />
If a Proposal contains a provision that targets a specifically named Idle Agent, then that Idle Agent is considered to be Unidle solely for the purposes of enacting that specific provision.<br />
<br />
When an Agent is unidled, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Agent Idled in a different Dynasty), the Agent is given the default value for new Agents, if such a value exists.<br />
<br />
An Admin may render an Agent Idle if that Agent has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Agent has not posted an entry or comment in the past 168 Hours (7 days). In the latter case, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Agent during the current and subsequent dynasty. Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so. An Admin may Unidle an Agent if that Agent is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may Unidle themselves at any time, unless the Agent who would be Unidled has become Idle within the past 96 hours (4 days), and within the current Dynasty.<br />
<br />
Admins who are unidling themselves should, in their first vote following each unidling, highlight their changed idle status and any changes to Quorum to have come about as a result of it.<br />
<br />
Idle admins can resolve Votable Matters as a non-idle admin would.<br />
<br />
===Dormancy===<br />
If there are fewer than four Agents (not including the Mainframe), then BlogNomic is on Hiatus.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Agent, known as the Mainframe. If there is no Mainframe, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before an Ascension Address has been posted. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Agent may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Mainframe is not an Agent.<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Agents may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Agent may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. An Agent's Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Agent never has a Vote, even if they were an Agent previously and had cast a valid Vote.<br />
<br />
If an Agent other than the Mainframe casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Mainframe. When the Mainframe has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Mainframe's Vote for the purposes of other rules unless otherwise specified. When the Mainframe themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Agents who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Agent may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Agent already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When an Agent casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Mainframe may use VETO as a voting icon to cast a Vote on a Proposal; when the Mainframe casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Mainframe later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Agent A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If an Agent (other than the Mainframe) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
An Agent's vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Agent may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, it has been open for at least 12 hours, and either the Mainframe has Voted FOR it or it has no AGAINST Votes.<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, and it has been open for at least 24 hours.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Agent who posted the DoV becomes Mainframe, and the game enters an Interregnum. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Mainframe must either Pass the Mantle (by making a post naming an Agent who was not the last dynasty’s Mainframe, in which case the passing Agent ceases to be the Mainframe and the Agent so named becomes the Mainframe) or start a new dynasty by completing the following Atomic Action:<br />
* Make an Ascension Address by posting an entry in the “Ascension Address” category. This should specify the Mainframe's chosen theme for the new Dynasty, and it may optionally specify new dynasty-specific terms as outline in the rule "Synonyms", and/or list a number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed).<br />
* Optionally specify any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section.<br />
* Update the Ruleset to reflect any changed terms, repeal any dynastic rules which were not listed to be kept, and make any specified or automatic changes to the Building Blocks section of the ruleset. Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Optionally change the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if an Agent's behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Agents should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Agent within BlogNomic, and should announce publicly if they control both a non-Idle Agent and any Idle Agents. This extends to exerting full control over the actions of another Agent, defined here as the controlled Agent's game behavior being functionally indistinguishable from if the controlling Agent was logged into their account and playing through it, over a period of more than a day.<br />
* An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* An Agent should not edit their own blog comments once posted, nor those of any other Agent.<br />
* An Agent should not edit the “Entry Date” field of a blog post.<br />
* An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* An Agent should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. an Agent must use their own name in the Dice Roller, when rolling dice.<br />
* An Agent should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* An Agent should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause an Agent to achieve victory.<br />
* An Agent should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Agent or Agents to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Agents and idle Agents should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Agents are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
<br />
==The Mainframe==<br />
'''The Mainframe''' is a strong AI with advanced natural language capabilities. All dynastic gamestate is secretly tracked by the Mainframe unless otherwise stated, or where it would be impossible.<br />
<br />
The Mainframe shall assign each Agent an '''IP address''' in the form #.#.#.# where each # is a number from 1-255. If any Agent has not been assigned an IP, the Mainframe should secretly randomly assign them one before performing any dynastic actions.<br />
<br />
Each Agent has a number named '''CPU Cycles''' which defaults to 1.<br />
<br />
Communication between Agents that is facilitated by the Mainframe is exempt from the restrictions described in the rule “No Private Communications”.<br />
<br />
==Clients==<br />
There may be any number of '''Clients'''. Each Client has a unique Name and a Passcode, which are strings of 4-16 characters containing only letters, numbers, and underscores. Names are not case-sensitive but Passcodes are. Client Names are publicly tracked in the Database.<br />
<br />
As a weekly virtual action, an Agent may '''create a new Client''' by specifying the desired Name and Passcode for the Client. This may be re-attempted if the action fails.<br />
<br />
Each Client has a list of Files, defaulting to an empty list.<br />
<br />
A '''Brute Force Attempt''' is a pairing of a number named Progress and the name of an Agent. Each Client has a list of Brute Force Attempts, defaulting to an empty list.<br />
<br />
A '''Passcode Complexity''' is a derived value that equals the number of characters a Client's Passcode has, multiplied by how many of the following criteria (which should be a number from 1 to 3) one or more of its characters meets: lowercase letters, uppercase letters, numbers.<br />
<br />
===Connections===<br />
An Agent may be '''connected''' to any number of Clients. A connection is a relationship between exactly one Agent and one Client.<br />
<br />
As a virtual action, an Agent may '''connect to a Client''' by specifying exactly one Client Name and Passcode pair. If the Passcode is correct for the specified Client, the Agent becomes connected to that Client.<br />
<br />
As a virtual action, an Agent may '''disconnect from a Client''' by specifying a client they are connected to, at which point the Agent is no longer connected to that Client.<br />
<br />
===The Dark Web===<br />
There is a Client named '''Dark Web''' with the Passcode '''1337''' and the following '''Files''':<br />
<br />
* BackOrifice<br />
* MyDoom<br />
* Klex<br />
* StuxNet<br />
* WannaCry<br />
<br />
==Shell Commands==<br />
A '''Shell Command''' is a type of Virtual Action that the Mainframe performs as a Client on behalf of an Agent. For the purposes of resolving Shell Commands, a Client is considered an Agent; The Client serves as a proxy for the Agent who initiated the command.<br />
<br />
An Agent must be connected to a Client to perform Shell Commands as that Client. ''To perform a Shell Command, you must always specify exactly one Client that you are connected to, or the action fails.''<br />
<br />
The definition of a Shell Command should be contained within the “Shell command” flair; If one is not, the Mainframe may edit the ruleset to make it so.<br />
<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client can '''ping''' the Mainframe. The Mainframe will respond to confirm that it is online.<br />
{{Flair bottom}}<br />
<br />
===Logging===<br />
The Mainframe shall maintain a '''log''' of successful Shell Commands. Each new log entry shall include:<br />
* the time/date it occurred<br />
* the IP of the initiating Agent<br />
* the name of the Client<br />
* the type of command<br />
* any other data the command specifies to be logged<br />
<br />
{{Flair top|Shell command}}<br />
As a shell command, a Client may '''request a copy of logs''' within a particular scope (e.g. a certain timeframe, logs associated with a certain IP, etc). Each log entry will be accompanied by an MD5 hash of the entry by which it can be identified.<br />
<br />
If the Client does not have access to all of the logs in the desired scope, the action will fail. By default, a Client only has access to the logs of actions performed by that particular Client.<br />
{{Flair bottom}}<br />
<br />
===Downloading===<br />
Each Agent has '''Warez''', which is a list of Files, defaulting to an empty list.<br />
<br />
{{Flair top|Shell command}}<br />
If a Client has one or more Files, as a Daily Shell Command, that Client may '''download file''' with the name of the File to download. If the File does not already exist in that Agent's Warez, it is added to the Warez of the Agent performing this command, otherwise the command fails. This command may be re-attempted if it failed.<br />
{{Flair bottom}}<br />
<br />
===Brute Force===<br />
{{Flair top|Shell command}}<br />
As a Daily Shell Command, a Client may '''brute force''' a '''Target''', which is the name of another Client other than this one. If the name of the Agent performing the command is not in the list of Brute Force Attempts for the Target, the Mainframe should add an entry to that list with the Progress set to 0 and the Agent set to the name of that Agent.<br />
<br />
In the entry of Brute Force Attempts for the Target that matches the name of the Agent performing this command, the Mainframe should add the Agent's CPU Cycles to the Progress of that entry. If that entry's Progress is equal to or greater than the Target's Passcode Complexity, the command succeeds, and the Mainframe should secretly communicate the Target's Passcode to the Agent. Otherwise, the command fails and may not be reattempted that day. On failure, the Mainframe should include the Target and the value of that entry's Progress in the description of the failure reason and in the Client's (not the Target's) Log, but must not include the Target's Passcode Complexity in either the failure reason or the Log.<br />
{{Flair bottom}}<br />
<br />
==Best Practices==<br />
{{Flair top|Shell command}}<br />
As a weekly Shell Command, a client may '''change passcode'''. The Client specifies a new valid Passcode and the Client's Passcode is changed to the new value. After this command executes, all Connections to the Client are removed. The Client's Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.<br />
{{Flair bottom}}<br />
<br />
==Files==<br />
A '''File''' consists of:<br />
* A '''name''', which is a string defaulting to "untitled"<br />
* Optionally one '''Program''' from the table “Programs”<br />
<br />
If a File contains a Program, the Type of the Program must be included in its name in brackets. Only Files with a Program may have brackets in their names, unless otherwise stated by the ruleset.<br />
<br />
{| class="wikitable"<br />
|+ Programs<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Anti-malware || When this File is executed, you may '''scan''' all files in your Warez. The Mainframe will respond with the number of corrupted Files in your Warez plus a privately randomly generated number between -2 and 2, inclusive, to a minimum of zero.<br />
|-<br />
| Firewall || Whenever you '''download''' a File, if the File is '''corrupted''', the Mainframe must privately randomly determine whether the File actually is downloaded or not, with both options being equally likely.<br />
|}<br />
<br />
The Effects of a Program only apply to Agents who have at least one File with that Program in their Warez. As a daily virtual action, an Agent may '''execute''' a File by specifying the name of exactly one File in their Warez. This may be re-attempted if the action fails.<br />
<br />
===Malware===<br />
An instance of a File in a list may be '''corrupted''' by none or more of the '''Malware''' described in the table below, defaulting to none. Whenever an Agent downloads a corrupted File, the File added to the Agent’s Warez will also be corrupted by the same Malware.<br />
<br />
{| class="wikitable"<br />
|+ Malware<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Virus || Whenever a Client performs a Shell Command, if the initiating Agent's Warez contains a File corrupted by a Virus, the Mainframe must make one of the Client's uncorrupted Files, if there are any, as well as one of the initiating Agent's Warez' uncorrupted Files, if there are any, corrupted by a Virus.<br />
|-<br />
| Trojan horse || If a file is corrupted by a Trojan horse, its name is allowed to contain brackets. However, such a File may not contain a Program.<br />
|}<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page is gamestate and may not be altered except as specified by the ruleset or through the passage of a Proposal or CfJ; however, its contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Mainframe specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset; these rules must then be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Mainframe makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected. There are currently no Recommended Building Blocks.<br />
<br />
==No Private Communication==<br />
Agents may not privately communicate with each other about dynastic gameplay or votable matters that affect the dynastic ruleset or gamestate. Private communications are considered to be anything that any other Agent could not reasonably be privy to, perceive, or understand. Discussion conducted in plain English on the BlogNomic wiki and blog, and the #current-dynasty, #blognomic-general and #new-player-questions-and-mentorships Discord channels, are not considered to be private communication. Idle Agents (or people who are not yet Agents) also face the same restrictions if they intend to become an active Agent during the course of the dynasty. The use of creative strategies to circumvent this rule may be considered to be a scam for the purposes of determining whether an infraction of Fair Play has taken place.<br />
<br />
A mentor and mentee may still privately converse with each other, but should keep their conversations away from discussing specific gameplay strategy. This rule’s restrictions on communication do not apply during an Interregnum. The restrictions in this rule on communication in non-blognomic-related media shall not be construed as to cause those media to be gamestate.<br />
<br />
If information which was not allowed to be discussed is still privately discussed, the Agents who were part of the conversation should make a post to the blog disclosing what information was discussed as their earliest convenience.<br />
<br />
==Virtual Actions==<br />
A Virtual Action is a type of action that the Mainframe performs on behalf of an Agent. An Agent may initiate a virtual action by privately communicating to the Mainframe their request to do so, along with any additional information needed to carry it out. The Mainframe shall resolve the Virtual Action by performing the following Atomic Action:<br />
# Determine whether the Virtual Action fails (if it does not fail, it is successful).<br />
# If the action is successful, apply any specified effects on the gamestate and/or perform any specified actions on behalf of the Agent.<br />
<br />
If a Virtual Action fails, the Mainframe should tell the Agent why. A virtual action may fail for any of these reasons:<br />
* Some requirements/prerequisites to perform the action are not met.<br />
* The request does not contain all the information needed to resolve the action.<br />
* The request is unintelligible, or too vague to interpret unambiguously.<br />
* It would require the Mainframe to do something they cannot do.<br />
* Any other reason specified by the action itself.<br />
<br />
Except where otherwise stated by the ruleset, the Mainframe must resolve all virtual actions in the order that they are received. A virtual action is considered to have occurred at the time it was resolved.<br />
<br />
Until a virtual action is resolved, it is pending. An Agent may cancel a pending Virtual Action by privately communicating to the Mainframe their request to do so<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Agent per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Agent per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Agents.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Effective Vote Comment (EVC): An Agent's Effective Vote Comment with respect to a given Votable Matter is that Agent's Comment to that Votable Matter, if any, that contains that Agent's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Agents , as well as people who are not Agents but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Agents who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Agents are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the Dynastic Rules explicitly mention (except for dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Pass the Mantle: Passing the Mantle is a mechanism by which, during an Interregnum, a Mainframe may nominate another Agent to become the Mainframe in the upcoming dynasty. Unless a Core, Dynastic or Building Block rule explicitly states otherwise, Passing the Mantle is currently prohibited.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Mainframe.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Agents” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To Uphold an illegal action is to retroactively declare the attempt to take it to have been successful, and to declare that all attempted game actions taken after it were attempted as if the Upheld action had been successful.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Agent may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may be altered by its author if it is less than 4 hours old and either no Agent has commented on it or (if it is a Votable Matter) if all comments on it contain no voting icons; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Mainframe to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Mainframe may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of an Agent’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Agent may correct the representations to comply with the Gamestate.<br />
<br />
If an Agent feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Agent, if doing so would not require the correcting Agent to make any decisions on behalf of the original Agent.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Agents are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
An Agent may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name an Agent with such access. Only an Agent with such access may Enact that Votable Matter. If that Votable Matter does not name an Agent with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Agent making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Agent making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When an Agent performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete.<br />
* If a rule allows the Agent performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If an Agent arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Agent must redo the Atomic Action; for that purpose, the Agent uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Agent would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, an Agent can spend or pay from only their own values, and a rule that allows Agents to transfer or pay a numeric value to another Agent only allows them to transfer that value from themselves to that other Agent (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Agents are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Mainframe (including secretly random selections), then that information may only be revealed by the Mainframe when the ruleset allows it. If an Agent should already know such a piece of information (in that the Mainframe has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Mainframe may repeat it to them.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Agent may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Agents may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Mainframe has voted DEFERENTIAL on a Proposal, that vote is instead considered to be valid and either FOR (if more Agents have a valid FOR vote on that Proposal than have a valid AGAINST vote on it) or AGAINST (in all other cases). However, in either case, votes of DEFERENTIAL made by other Agents on the same Proposal are not considered to be valid. If there are six or fewer Agents, then the Mainframe’s vote of DEFERENTIAL on a proposal is only affected by this rule if all Agents who are not the Mainframe have cast a vote on that proposal.<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* An Agent may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Agents may correct obvious spelling, punctuation, and/or typographical mistakes in the Ruleset and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Agents with the corresponding forms of the singular “they”.<br />
* An Agent may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, an Agent's (or prospective Agent's ) new name must be between 4 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Agents may Kick each other” and “Agents may not Kick each other on Tuesdays” exist, and it is Tuesday, Agents may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Agents may Punch a Spaceman on Friday” and “Agents may not Punch Spacemen on Friday”, then Agents may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
An Agent may have another Agent as a Mentor. Agents who are willing to act as a Mentor are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of an Agent who has requested a change on their own behalf, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Agent requests a Mentor, or a new Agent has joined the game and has no Mentor, the Mainframe should select a Tenured Agent and ask them to take that Agent on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Mainframe should announce it in a blog post. The Mainframe should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. An Agent may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Mainframe, any Agent who has been active in at least three previous dynasties may act as Mainframe for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Agent or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Agents .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Agent” and “Mainframe”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Agent (Player)<br />
* Mainframe (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=Ruleset&diff=25493Ruleset2024-01-29T15:28:07Z<p>Zack: /* The Mainframe */ Enacting "Secure Channel"</p>
<hr />
<div>{{TOCRight}}<br />
<br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Core Rules =<br />
<br />
== Ruleset and Gamestate ==<br />
This is the '''Ruleset''' for BlogNomic; all Agents shall obey it.<br />
<br />
It comprises four Sections: 1) the “core rules” of BlogNomic, covering the essential elements of gameplay; 2) the rules of the current Dynasty; 3) rules which set metagame parameters for the current dynasty; and 4) the appendix, which complements and clarifies the Ruleset.<br />
<br />
The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. This document is considered to be, in effect, the only Ruleset for BlogNomic, so long as it is located at at the URL https://wiki.blognomic.com/index.php?title=Ruleset.<br />
<br />
If the text of the Ruleset document does not reflect all legal changes that have been authorised to be made to it, any Agent may update it to do so.<br />
<br />
The gamestate tracking page for this dynasty is the [[The Database]] page of the wiki. Unless otherwise stated, all publicly tracked gamestate information is tracked on it.<br />
<br />
== Agents ==<br />
A human with access to the blog who is not already an Agent may make a blog post making clear their wish to be an Agent (plural form Agents); in response, an Admin shall add them to the roster in the sidebar, at which moment they become an Agent. (See the [[FAQ#Can_I_join_in.3F|FAQ]] for guidance on how to apply for access to the BlogNomic blog.)<br />
<br />
An Agent may only change their name as a result of a Proposal approving the change.<br />
<br />
Some Agents are '''Admins''', responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. Agents may be made Admins through Proposal or CFJ.<br />
<br />
An Agent may cease to be an Agent at any time by posting an entry to the BlogNomic weblog requesting such an action. A human who has ceased to be an Agent in this way may not become an Agent again within the following two weeks.<br />
<br />
===Idle Agents ===<br />
<br />
If an Agent is Idle, this is tracked by their name being removed or concealed in the list of currently active Agents in the Sidebar. For the purposes of all Gamestate and the Ruleset, excluding the core and appendix Rules “Ruleset and Gamestate”, “Agents ”, “Dynasties”, “Fair Play”, "Mentors" and any of those Rules’ subrules, Idle Agents are not counted as Agents . The combined term “Idle Agent” can be used to refer to Agents who are Idle even in rules that do not treat them as Agents.<br />
<br />
If a Proposal contains a provision that targets a specifically named Idle Agent, then that Idle Agent is considered to be Unidle solely for the purposes of enacting that specific provision.<br />
<br />
When an Agent is unidled, if they went Idle in the same Dynasty, their personal gamestate retains the last legally endowed values it had, if they are still valid. Otherwise (including if a value is invalid, does not exist, or the Agent Idled in a different Dynasty), the Agent is given the default value for new Agents, if such a value exists.<br />
<br />
An Admin may render an Agent Idle if that Agent has asked to become Idle in an entry or comment from the past 96 hours (4 Days), or if that Agent has not posted an entry or comment in the past 168 Hours (7 days). In the latter case, the Admin must announce the idling in a blog post, and the 168 Hour idle timeout is considered to be reduced to 96 hours for that Agent during the current and subsequent dynasty. Admins may render themselves Idle at any time, but should announce it in a post or comment when they do so. An Admin may Unidle an Agent if that Agent is Idle and has asked to become Unidle in an entry or comment from the past 96 hours (4 Days), and Idle Admins may Unidle themselves at any time, unless the Agent who would be Unidled has become Idle within the past 96 hours (4 days), and within the current Dynasty.<br />
<br />
Admins who are unidling themselves should, in their first vote following each unidling, highlight their changed idle status and any changes to Quorum to have come about as a result of it.<br />
<br />
Idle admins can resolve Votable Matters as a non-idle admin would.<br />
<br />
===Dormancy===<br />
If there are fewer than four Agents (not including the Mainframe), then BlogNomic is on Hiatus.<br />
<br />
== Dynasties ==<br />
BlogNomic is divided into a number of '''Dynasties'''. Each Dynasty may be headed by a single Agent, known as the Mainframe. If there is no Mainframe, the Dynasty is a Metadynasty.<br />
<br />
An Interregnum is the period between dynasties, after a DoV has been enacted and before an Ascension Address has been posted. During an Interregnum the game is in hiatus; additionally, no DoVs may be made, and no Agent may achieve Victory. However, dynastic actions that are specifically permitted to be carried out during an Interregnum may be carried out.<br />
<br />
Unless otherwise stated by a dynastic or Building Blocks rule, then for the purposes of dynastic and Building Blocks rules, the Mainframe is not an Agent.<br />
<br />
== Votable Matters ==<br />
A '''Votable Matter''' is a post which Agents may cast Votes on, such as a Proposal, a Call for Judgement or a Declaration of Victory.<br />
<br />
===Votes===<br />
Each Agent may cast one Vote on a Votable Matter by making a comment to the Official Post that comprises that Votable Matter using a voting icon of FOR, AGAINST, or DEFERENTIAL. Additional voting icons may be permitted in some cases by other rules. A valid Vote is, except when otherwise specified, a Vote of FOR or AGAINST. An Agent's Vote on a Votable Matter is the last valid voting icon that they have used in any comment on that Votable Matter. Additionally, if the author of a Votable Matter has not used a valid voting icon in a comment to the post, then the author’s Vote is FOR. A non-Agent never has a Vote, even if they were an Agent previously and had cast a valid Vote.<br />
<br />
If an Agent other than the Mainframe casts a vote of DEFERENTIAL, then the Vote of DEFERENTIAL is an indication of confidence in the Mainframe. When the Mainframe has a valid Vote other than VETO on a Votable Matter, then all votes of DEFERENTIAL on that Votable Matter are instead considered to be valid and the same as the Mainframe's Vote for the purposes of other rules unless otherwise specified. When the Mainframe themselves casts a vote of DEFERENTIAL, it indicates an indication of confidence in the votes of the other players; please see the Rules and Votable Matters section of the Appendix for more information on how this is resolved.<br />
<br />
A Votable Matter is '''Popular''' if any of the following are true:<br />
* It has a number of FOR Votes that exceed or equal Quorum.<br />
* It has been open for voting for at least 48 hours, it has more than 1 valid Vote cast on it, and more valid Votes cast on it are FOR than are AGAINST. <br />
<br />
A Votable Matter is '''Unpopular''' if any of the following are true:<br />
* The number of Agents who are not voting AGAINST it is less than Quorum.<br />
* It has been open for voting for at least 48 hours and it is not Popular.<br />
<br />
=== Enacting and Failing ===<br />
<br />
Votable matters have a status, which can either be Pending, Enacted, Failed, or Illegal. When a votable matter is first put forward it is considered Pending (which is tracked as having no status in the current blog software), and it remains Pending until it is Resolved.<br />
<br />
A votable matter is resolved by an admin setting its status through use of the “status” field in the blog post editing form. When an admin resolves a votable matter they should mark their name, and are highly encouraged to report the final tally of Votes (or the fact that it was withdrawn or vetoed). Comments cannot be made on resolved Votable Matters.<br />
<br />
A votable matter may not be resolved except as directed by the ruleset, and the status of a resolved votable matter, once resolved, is determined by the votes cast upon it, as assessed by the rules that govern the specific kind of votable matter (as well as any other considerations regarding the legality of the votable matter, such as the stipulations put forward in the Appendix rule Official Posts). When a Failed proposal has been Vetoed it may optionally have the Vetoed status upon resolution, which is considered to be the same as Failed for the purposes of all other rules.<br />
<br />
This rule cannot be overruled by any other rule in its application to Calls for Judgement or Declarations of Victory.<br />
<br />
===Tags===<br />
Votable Matters have zero or more tags. Tags are represented in the title of a Votable Matter with the format “[X]” (e.g. “[Core] Wording Fix”, where “[Core]” is the tag).<br />
<br />
Votable Matters making changes to the Core Rules, the Building Blocks Rules or the Appendix Rules require any of the following to be true for each such change in order to make that specific modification to the ruleset:<br />
* The Votable Matter has the appropriate Tag or Tags for that change: [Core] for Core Rules changes, [Building Blocks] for Building Blocks Rules changes and [Appendix] for Appendix Rules changes.<br />
* The modification is preceded or followed immediately by an unambiguous statement of which section of the ruleset it takes place.<br />
* The modification specifically states a rule using its number or the name of the stated rule only occurs once in the ruleset.<br />
<br />
== Proposals ==<br />
Any Agent may submit a '''Proposal''' to change the Ruleset or Gamestate, by posting an entry in the “Proposal” category that describes those changes (unless the Agent already has 2 Proposals pending or has already made 3 Proposals that day).<br />
<br />
=== Special Proposal Voting ===<br />
<br />
When an Agent casts a vote AGAINST their own Proposal (which is not in the form of a DEFERENTIAL vote), this renders the Proposal '''Withdrawn''', even if the author later changes their Vote. The Mainframe may use VETO as a voting icon to cast a Vote on a Proposal; when the Mainframe casts a vote of VETO on a Proposal, this renders the Proposal Vetoed, even if the Mainframe later changes their Vote.<br />
<br />
=== Resolution of Proposals ===<br />
<br />
The oldest Pending [[#Proposals|Proposal]] may be '''Enacted''' by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
* It has been open for voting for at least 12 hours.<br />
* It has not been Vetoed or Withdrawn.<br />
<br />
The oldest Pending Proposal may be '''Failed''' by any Admin, if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It has been Vetoed or Withdrawn.<br />
<br />
If a Proposal somehow ends up being pending for more than 7 days, it is ignored for the purpose of calculating the oldest pending Proposal, and can be failed by any Admin.<br />
<br />
When a Proposal is Enacted, its stated effects are applied by treating the text in the Proposal as a series of steps starting from the beginning of that Proposal’s text and performing each step until reaching the end of that Proposal’s text, except that if the Admin Enacting it reaches a step which cannot be applied immediately (e.g. “two days after this Votable Matter enacts, Agent A gains 1 point”) or at all (e.g. applying to a rule which does not exist), that step is ignored for the purposes of Enactment; the Admin Enacting the Proposal shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in each step that was performed.<br />
<br />
== Calls for Judgement ==<br />
If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a '''Call for Judgement''' (abbreviated “CfJ”) by posting an entry in the “Call for Judgement” category.<br />
<br />
A Pending CfJ may be Enacted by any Admin if all of the following are true:<br />
<br />
* It is Popular.<br />
<br />
A Pending CfJ may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular.<br />
* It specifies neither changes to the Gamestate or Ruleset nor corrections to any gamestate-tracking entities.<br />
<br />
When a CfJ is Enacted, the Admin Enacting it shall update the Gamestate and Ruleset, and correct any gamestate-tracking entities, as specified in the CfJ.<br />
<br />
This Rule may not be overruled by Dynastic Rules.<br />
<br />
== Victory and Ascension ==<br />
<br />
If an Agent (other than the Mainframe) believes that they have achieved victory in the current Dynasty, they may make a '''Declaration of Victory''' (abbreviated “DoV”) detailing this, by posting an entry in the “Declaration of Victory” category.<br />
<br />
An Agent's vote on a DoV is encouraged to reflect whether or not they agree with the proposition that the poster has achieved victory in the current Dynasty. If there is at least one pending DoV, BlogNomic is [[#hiatus|on Hiatus]], no Idle Agent may be made unidle, and no new player joining requests may be administered.<br />
<br />
A Pending DoV may be Enacted by any Admin if any of the following are true:<br />
<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, it has been open for at least 12 hours, and either the Mainframe has Voted FOR it or it has no AGAINST Votes.<br />
* It has a number of FOR Votes greater than 2/3rds of the number of Agents, and it has been open for at least 24 hours.<br />
<br />
A Pending DoV may be Failed by any Admin if any of the following are true:<br />
<br />
* It is Unpopular, and it has been open for at least 12 hours.<br />
* It is more than 48 hours old and cannot be Enacted<br />
<br />
If a DoV is Failed and it had at least one AGAINST vote, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was Failed.<br />
<br />
When a DoV is Enacted, all other pending DoVs are Failed, the Agent who posted the DoV becomes Mainframe, and the game enters an Interregnum. When a DoV is enacted then all game actions that led up to it are considered to be upheld.<br />
<br />
If the game is in an Interregnum then the new Mainframe must either Pass the Mantle (by making a post naming an Agent who was not the last dynasty’s Mainframe, in which case the passing Agent ceases to be the Mainframe and the Agent so named becomes the Mainframe) or start a new dynasty by completing the following Atomic Action:<br />
* Make an Ascension Address by posting an entry in the “Ascension Address” category. This should specify the Mainframe's chosen theme for the new Dynasty, and it may optionally specify new dynasty-specific terms as outline in the rule "Synonyms", and/or list a number of dynastic rules to keep (if none are specifed then the entire Dynastic Ruleset is repealed).<br />
* Optionally specify any number of Building Blocks rules to remove or insert, as per the instructions in the Building Blocks section.<br />
* Update the Ruleset to reflect any changed terms, repeal any dynastic rules which were not listed to be kept, and make any specified or automatic changes to the Building Blocks section of the ruleset. Update the Building Blocks page to reflect any changes to the terms outlined in the rule Synonyms.<br />
* Optionally change the gamestate tracking page referred to in the rule “Ruleset and Gamestate” to a different page that does not exist and does not start with the word “Ruleset”.<br />
<br />
Once this Atomic Action has been completed the Interregnum ends and the new dynasty begins.<br />
<br />
== Fair Play ==<br />
The following are BlogNomic’s rules of '''fair play'''. If any of these rules are found to have been broken, or if an Agent's behaviour or actions are otherwise deemed unacceptable (socially or otherwise), a Proposal or CfJ may be made to reprimand or punish the perpetrator or, in cases of extreme or repeated violations, remove them from the game and bar them from rejoining. Agents should vote against any DoV that relies on having broken a fair play rule.<br />
<br />
* A single person should not control more than one non-Idle Agent within BlogNomic, and should announce publicly if they control both a non-Idle Agent and any Idle Agents. This extends to exerting full control over the actions of another Agent, defined here as the controlled Agent's game behavior being functionally indistinguishable from if the controlling Agent was logged into their account and playing through it, over a period of more than a day.<br />
* An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.<br />
* An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or other blognomic.com scripts).<br />
* An Agent should not edit their own blog comments once posted, nor those of any other Agent.<br />
* An Agent should not edit the “Entry Date” field of a blog post.<br />
* An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.<br />
* An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an Ascension Address).<br />
* An Agent should not roll dice that are clearly associated with a particular action in the Ruleset, but with the intention to not use these rolled values to the best of their ability to resolve that action. an Agent must use their own name in the Dice Roller, when rolling dice.<br />
* An Agent should not deliberately and unreasonably prolong the performance of a game action once they have started it.<br />
* An Agent should not use a Core, Building Blocks, or Appendix rules scam to directly or indirectly cause an Agent to achieve victory.<br />
* An Agent should not trade actions in BlogNomic for favors or compensation outside of BlogNomic, nor trade actions in any other game for favors within BlogNomic.<br />
*A person with administrative, moderation, or other heightened access to the software running or supporting BlogNomic should not take any action using such heightened access for the purpose of causing any Agent or Agents to gain, receive, maintain, or preserve gameplay advantage unless any of the following is true:<br />
**Such action is required or explicitly permitted by the rules or required to implement an action required or explicitly permitted by the rules.<br />
**A reasonable, impartial, and prudent external observer would deem such action necessary or reasonable for the purpose of supporting, moderating, or administering BlogNomic or such software.<br />
<br />
All Agents and idle Agents should be aware of the BlogNomic [[Community Guidelines]]. The contents of this page are not ruletext and are nonbinding as pertains to the ruleset, but Agents are encouraged to commit to upholding them to whatever extent is possible.<br />
<br />
</div><br />
<br />
= Dynastic Rules =<br />
<br />
==The Mainframe==<br />
'''The Mainframe''' is a strong AI with advanced natural language capabilities. All dynastic gamestate is secretly tracked by the Mainframe unless otherwise stated, or where it would be impossible.<br />
<br />
The Mainframe shall assign each Agent an '''IP address''' in the form #.#.#.# where each # is a number from 1-255. If any Agent has not been assigned an IP, the Mainframe should secretly randomly assign them one before performing any dynastic actions.<br />
<br />
Each Agent has a number named '''CPU Cycles''' which defaults to 1.<br />
<br />
Communication between Agents that is facilitated by the Mainframe is exempt from the restrictions described in the rule “No Private Communications”.<br />
<br />
==Clients==<br />
There may be any number of '''Clients'''. Each Client has a unique Name and a Passcode, which are strings of 4-16 characters containing only letters, numbers, and underscores. Names are not case-sensitive but Passcodes are. Client Names are publicly tracked in the Database.<br />
<br />
As a weekly virtual action, an Agent may '''create a new Client''' by specifying the desired Name and Passcode for the Client. This may be re-attempted if the action fails.<br />
<br />
A '''File''' is a string. Each Client has a list of Files, defaulting to an empty list.<br />
<br />
A '''Brute Force Attempt''' is a pairing of a number named Progress and the name of an Agent. Each Client has a list of Brute Force Attempts, defaulting to an empty list.<br />
<br />
A '''Passcode Complexity''' is a derived value that equals the number of characters a Client's Passcode has, multiplied by how many of the following criteria (which should be a number from 1 to 3) one or more of its characters meets: lowercase letters, uppercase letters, numbers.<br />
<br />
===Connections===<br />
An Agent may be '''connected''' to any number of Clients. A connection is a relationship between exactly one Agent and one Client.<br />
<br />
As a virtual action, an Agent may '''connect to a Client''' by specifying exactly one Client Name and Passcode pair. If the Passcode is correct for the specified Client, the Agent becomes connected to that Client.<br />
<br />
As a virtual action, an Agent may '''disconnect from a Client''' by specifying a client they are connected to, at which point the Agent is no longer connected to that Client.<br />
<br />
===The Dark Web===<br />
There is a Client named '''Dark Web''' with the Passcode '''1337''' and the following '''Files''':<br />
<br />
* BackOrifice<br />
* MyDoom<br />
* Klex<br />
* StuxNet<br />
* WannaCry<br />
<br />
==Shell Commands==<br />
A '''Shell Command''' is a type of Virtual Action that the Mainframe performs as a Client on behalf of an Agent. For the purposes of resolving Shell Commands, a Client is considered an Agent; The Client serves as a proxy for the Agent who initiated the command.<br />
<br />
An Agent must be connected to a Client to perform Shell Commands as that Client. ''To perform a Shell Command, you must always specify exactly one Client that you are connected to, or the action fails.''<br />
<br />
The definition of a Shell Command should be contained within the “Shell command” flair; If one is not, the Mainframe may edit the ruleset to make it so.<br />
<br />
{{Flair top|Shell command}}<br />
As a Shell Command, a Client can '''ping''' the Mainframe. The Mainframe will respond to confirm that it is online.<br />
{{Flair bottom}}<br />
<br />
===Logging===<br />
The Mainframe shall maintain a '''log''' of successful Shell Commands. Each new log entry shall include:<br />
* the time/date it occurred<br />
* the IP of the initiating Agent<br />
* the name of the Client<br />
* the type of command<br />
* any other data the command specifies to be logged<br />
<br />
{{Flair top|Shell command}}<br />
As a shell command, a Client may '''request a copy of logs''' within a particular scope (e.g. a certain timeframe, logs associated with a certain IP, etc). Each log entry will be accompanied by an MD5 hash of the entry by which it can be identified.<br />
<br />
If the Client does not have access to all of the logs in the desired scope, the action will fail. By default, a Client only has access to the logs of actions performed by that particular Client.<br />
{{Flair bottom}}<br />
<br />
===Downloading===<br />
Each Agent has '''Warez''', which is a list of Files, defaulting to an empty list.<br />
<br />
{{Flair top|Shell command}}<br />
If a Client has one or more Files, as a Daily Shell Command, that Client may '''download file''' with the name of the File to download. If the name of the File does not already exist in that Agent's Warez, it is added to the Warez of the Agent performing this command, otherwise the command fails. This command may be re-attempted if it failed.<br />
{{Flair bottom}}<br />
<br />
===Brute Force===<br />
{{Flair top|Shell command}}<br />
As a Daily Shell Command, a Client may '''brute force''' a '''Target''', which is the name of another Client other than this one. If the name of the Agent performing the command is not in the list of Brute Force Attempts for the Target, the Mainframe should add an entry to that list with the Progress set to 0 and the Agent set to the name of that Agent.<br />
<br />
In the entry of Brute Force Attempts for the Target that matches the name of the Agent performing this command, the Mainframe should add the Agent's CPU Cycles to the Progress of that entry. If that entry's Progress is equal to or greater than the Target's Passcode Complexity, the command succeeds, and the Mainframe should secretly communicate the Target's Passcode to the Agent. Otherwise, the command fails and may not be reattempted that day. On failure, the Mainframe should include the Target and the value of that entry's Progress in the description of the failure reason and in the Client's (not the Target's) Log, but must not include the Target's Passcode Complexity in either the failure reason or the Log.<br />
{{Flair bottom}}<br />
<br />
==Best Practices==<br />
As a weekly Shell Command, a client may '''change passcode'''. The Client specifies a new valid Passcode and the Client's Passcode is changed to the new value. After this command executes, all Connections to the Client are removed. The Client's Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.<br />
<br />
==Malware==<br />
An instance of a File in a list may be '''corrupted''' by none or more of the '''Malware''' described in the table below, defaulting to none. Whenever an Agent downloads a corrupted File, the File added to the Agent’s Warez will also be corrupted by the same Malware.<br />
<br />
{| class="wikitable"<br />
|+ Malware<br />
|-<br />
! Type !! Effects<br />
|-<br />
| Virus || Whenever a Client performs a Shell Command, if the initiating Agent's Warez contains a File corrupted by a Virus, the Mainframe must make one of the Client's uncorrupted Files, if there are any, as well as one of the initiating Agent's Warez' uncorrupted Files, if there are any, corrupted by a Virus.<br />
|}<br />
<br />
<!-- DYNASTIC RULES GO ABOVE THIS COMMENT. DO NOT DELETE THE NEXT LINE WHEN CLEARING THE RULES FOR A NEW DYNASTY. --><br /><br />
<div style="padding:8px;background:#bbb;"><br />
<br />
= Building Blocks =<br />
Building Blocks are rules that can be substituted in and out of the ruleset as needed, usually as a result of an Ascension Address. All rules in the Building Blocks section are ruletext.<br />
<br />
Potential Building Blocks rules can be found at the [[Building Blocks]] page of the wiki. That page is gamestate and may not be altered except as specified by the ruleset or through the passage of a Proposal or CfJ; however, its contents are not rulestext. When the contents of the Building Blocks page are referred to as ‘rules’ by the ruleset or by a votable matter, it should be assumed that said contents are being referred to as potential rules rather than actual rules.<br />
<br />
When a Mainframe specifies the Building Blocks rules in use for a new dynasty in an Ascension Address, they should specify (by name) the rules from the Building Blocks page that they would like to be included in this section of the ruleset; these rules must then be transcribed faithfully to this section of the ruleset, and any Building Blocks rules not so named must be removed from the Building Blocks section. Some rules on the Building Blocks page are listed as being Recommended; if the new Mainframe makes no statement on Building Blocks rules to be included in their Ascension Address then the Recommended Building Blocks are considered to have been selected. There are currently no Recommended Building Blocks.<br />
<br />
==No Private Communication==<br />
Agents may not privately communicate with each other about dynastic gameplay or votable matters that affect the dynastic ruleset or gamestate. Private communications are considered to be anything that any other Agent could not reasonably be privy to, perceive, or understand. Discussion conducted in plain English on the BlogNomic wiki and blog, and the #current-dynasty, #blognomic-general and #new-player-questions-and-mentorships Discord channels, are not considered to be private communication. Idle Agents (or people who are not yet Agents) also face the same restrictions if they intend to become an active Agent during the course of the dynasty. The use of creative strategies to circumvent this rule may be considered to be a scam for the purposes of determining whether an infraction of Fair Play has taken place.<br />
<br />
A mentor and mentee may still privately converse with each other, but should keep their conversations away from discussing specific gameplay strategy. This rule’s restrictions on communication do not apply during an Interregnum. The restrictions in this rule on communication in non-blognomic-related media shall not be construed as to cause those media to be gamestate.<br />
<br />
If information which was not allowed to be discussed is still privately discussed, the Agents who were part of the conversation should make a post to the blog disclosing what information was discussed as their earliest convenience.<br />
<br />
==Virtual Actions==<br />
A Virtual Action is a type of action that the Mainframe performs on behalf of an Agent. An Agent may initiate a virtual action by privately communicating to the Mainframe their request to do so, along with any additional information needed to carry it out. The Mainframe shall resolve the Virtual Action by performing the following Atomic Action:<br />
# Determine whether the Virtual Action fails (if it does not fail, it is successful).<br />
# If the action is successful, apply any specified effects on the gamestate and/or perform any specified actions on behalf of the Agent.<br />
<br />
If a Virtual Action fails, the Mainframe should tell the Agent why. A virtual action may fail for any of these reasons:<br />
* Some requirements/prerequisites to perform the action are not met.<br />
* The request does not contain all the information needed to resolve the action.<br />
* The request is unintelligible, or too vague to interpret unambiguously.<br />
* It would require the Mainframe to do something they cannot do.<br />
* Any other reason specified by the action itself.<br />
<br />
Except where otherwise stated by the ruleset, the Mainframe must resolve all virtual actions in the order that they are received. A virtual action is considered to have occurred at the time it was resolved.<br />
<br />
Until a virtual action is resolved, it is pending. An Agent may cancel a pending Virtual Action by privately communicating to the Mainframe their request to do so<br />
</div><br />
<div style="padding:8px;background:#ddd;"><br />
<br />
= Appendix =<br />
<br />
==Keywords==<br />
A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (e.g. A rule specifying “bananas are blue” cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying “every day is Sunday” will be overruled by the glossary entry below.)<br />
<br />
===Imperatives===<br />
;Can: “is able to”<br />
;Shall: “is required to”<br />
;Should: “is recommended that”<br />
<br />
===Time===<br />
;Daily Action: If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every ten hours.<br />
;Daily Communal Action: A Daily Communal Action is a Daily Action that can only be performed by one Agent per day.<br />
;Day: References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 UTC, ending when the next day begins. It can never be 2 different days at the same instant.<br />
;Week: References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.<br />
;Weekly Action: If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.<br />
;Weekly Communal Action: A Weekly Communal action is a Weekly Action that can only be performed by one Agent per week. <br />
<br />
===Other===<br />
;Comment: A blog comment published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Core Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of Admin status from one or more Agents.<br />
;Dice: References to “DICEX” or “YDICEX” refer to X-sided dice and Y amount of X-sided dice, rolled using the Dice Roller.<br />
;Dynastic Action: An action that is defined in the Dynastic rules.<br />
;Dynastic Proposal: A Proposal which mandates changes that, even if conditionally, are limited to the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.<br />
;Effective Vote Comment (EVC): An Agent's Effective Vote Comment with respect to a given Votable Matter is that Agent's Comment to that Votable Matter, if any, that contains that Agent's Vote on that Votable Matter.<br />
;Commentary: When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.<br />
;Discord: The BlogNomic Discord can be accessed at https://discord.gg/J7kP9KuHQK and is also linked to on the sidebar. Agents , as well as people who are not Agents but are interested in learning more about BlogNomic, may join the Discord by clicking the button in the sidebar.<br />
;Discord Channel: A Discord Channel is any channel on the BlogNomic Discord in the BlogNomic Discussion category. All Agents who are in the Discord should have the ability to access all of these channels. To reference a Discord Channel, use a hash (#) followed by the name of that channel (e.g. #random).<br />
;Flavour Text: If a part of the ruleset or gamestate is defined as being “flavour text”, it retains its context, but is not considered to have any meaning beyond being a string of characters. Agents are not required to obey flavour text and may not perform any action defined by it, and any statements that flavour text makes about gamestate are ignored.<br />
;Gamestate: Any information which the Ruleset regulates the alteration of. All wiki pages that the Dynastic Rules explicitly mention (except for dynastic histories and discussion pages) and any images or Templates contained within (or indirectly invoked by Templates contained within) those Wiki Pages are assumed to be Gamestate.<br />
;<span id="hiatus">Hiatus</span>: If BlogNomic is on Hiatus, Dynastic Actions may not be taken (except where the rule defining the action explicitly requires it to be taken during Hiatus), and Proposals may not be submitted or Resolved. If multiple rules require BlogNomic to be on Hiatus at any given time, BlogNomic will continue to be on Hiatus until no rules require it.<br />
;Pass the Mantle: Passing the Mantle is a mechanism by which, during an Interregnum, a Mainframe may nominate another Agent to become the Mainframe in the upcoming dynasty. Unless a Core, Dynastic or Building Block rule explicitly states otherwise, Passing the Mantle is currently prohibited.<br />
;Post: A blog post published to the BlogNomic weblog at [http://blognomic.com blognomic.com]<br />
;Quorum: Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.<br />
;Resolve/Resolution: If used in a context of a Votable Matter, the word “Resolve” means to perform the act, as an Admin, of enacting, failing, or marking illegal a Votable Matter. The world “Resolution” means then the act of doing so. If used in any other context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words. The resolution of a votable matter is tracked by reference to its status in the blog post edit form. If otherwise legally applied, the application of any status through the blog post editing form is sufficient to consider that votable matter to have been correctly resolved, but a resolved votable matter should have the correct status wherever possible; if any admin believes that a resolved votable matter has an incorrect status then they may correct it.<br />
;Rule: Each individually numbered and titled block of text (using the wikimedia section heading formatting) of the Ruleset is a rule, including rules that are subrules of other rules; with the exception that the top-level headings defined as ‘sections’ in the rule “Ruleset and Gamestate” are considered sections but not rules themselves.<br />
;Sticky Post: A blog post where the “Make Entry Sticky” option has been enabled. Changing the state of this option is not considering altering or modifying the post with regards to the rules on Official Posts. The sticky status of posts should generally be left to the discretion of the Mainframe.<br />
;Story Post: A Story Post is an entry in the “Story Post” category.<br />
;Subject: The “subject” of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is “” (i.e. an empty string) is not valid.<br />
;Seasonal Downtime: On the 24th, 25th and 26th of December, BlogNomic is [[#hiatus|on Hiatus]]. In addition, game actions defined by the core rules titled “Agents” and “Victory and Ascension” (with the exception of Voting in DoVs) may not be taken.<br />
;Subrule: A subrule is a type of rule that is hierarchically ordered beneath another rule. Rules and proposals that refer to a rule do not also refer to its subrules, unless otherwise specified.<br />
;Table of Contents: The directory of section headings that is generated by the MediaWiki software for most pages in the wiki.<br />
;Uphold: To Uphold an illegal action is to retroactively declare the attempt to take it to have been successful, and to declare that all attempted game actions taken after it were attempted as if the Upheld action had been successful.<br />
;Vote: The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule “Votable Matters”. The word “Vote”, used as a verb, means the act of casting such a Vote.<br />
;Voting Icons: For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, a DEF http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and a crossed-out circle http://blognomic.com/images/vote/seal.gif shall represent a vote to VETO.<br />
;Wiki: The BlogNomic Wiki at http://wiki.blognomic.com<br />
<br />
== Gamestate Tracking ==<br />
<br />
===Official Posts===<br />
<br />
Votable Matters and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at [http://blognomic.com http://blognomic.com]. Any Agent may [http://blognomic.com/update/index.php?C=publish post] to the blog at any time, but may only make official posts to the blog when the [[#Ruleset and Gamestate|Ruleset]] allows it. Posts following the format specified by a rule are considered official posts. Any single official post cannot be of two different types of official post unless a rule explicitly states otherwise. Dynastic rules cannot define posts in the “Call for Judgement” category to be a type of official post other than a Call for Judgement, and this restriction cannot be overridden by dynastic rules.<br />
<br />
An official post may only be removed as allowed by the Ruleset. An official post may be altered by its author if it is less than 4 hours old and either no Agent has commented on it or (if it is a Votable Matter) if all comments on it contain no voting icons; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post’s Status must be changed to reflect its status. An official blog post that has the status of Enacted or Failed cannot change categories, except that a votable matter’s illegal resolution may be overturned. An official blog post’s status may never be altered except in accordance with the rules that define that official post.<br />
<br />
A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following two exceptions: Firstly, whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish. Secondly, if a post is less than six hours old and appears to the Mainframe to have been intended as a Proposal, and if its author does not already have two Proposals pending, then the Mainframe may move it into the Proposal category, causing it to be considered to have been open for voting since the time that the post was first posted.<br />
<br />
Any post that is or is made illegal as a result of an infraction against any of the prohibitions set out in this rule, except for a votable matter’s illegal resolution that has been overturned, continues to be an Official Post but may no longer have any effect on the ruleset or the gamestate. If it is a Votable Matter then it is Unpopular, regardless of any other performance against criteria set out in the core rules. When it is resolved it may be marked as Illegal by the resolving admin. A post that is illegal in this manner cannot subsequently be made legal by any means, except for the legal enactment of a CFJ. An illegal CFJ cannot cause itself to become legal.<br />
<br />
===Representations of the Gamestate===<br />
If authorised by the rules as a result of an Agent’s action, changes to gamestate which is tracked in a specific place (such as a wiki page) do not take effect until the representation of that gamestate has been updated to match the authorised change. One wiki update may contain one or more alterations, or one alteration may be split over multiple updates, as long as it is clear what is happening and the alterations are otherwise legal. The wiki merely represents the Gamestate tracked there, and is not the same thing. In the event that the Gamestate and its representations are different, any Agent may correct the representations to comply with the Gamestate.<br />
<br />
If an Agent feels that a representation of the gamestate (such as a wiki page) does not match the gamestate, they may either:<br />
<br />
* Undo the effects of any alteration that led to it, if that alteration did not follow the rules at the time it was made.<br />
* Alter the representation to match what they believe to be the correct application of an incorrectly-applied alteration. This may include completing incomplete actions on behalf of the original Agent, if doing so would not require the correcting Agent to make any decisions on behalf of the original Agent.<br />
Instead of repeatedly reverting and re-reverting a disputed alteration, however, Agents are encouraged to raise a Call for Judgement.<br />
The historical fact of the occurrence of a defined game action is itself considered to be gamestate, tracked in the history of whatever resource is used to track the gamestate modified by that action, where possible, or in the wiki page [[Gamestate Modifications]] if this is not possible.<br />
<br />
===Orphan Variables===<br />
<br />
An Orphan Variable is a dynastic gamestate variable which has neither a location in which it’s tracked, nor a reasonable manner in which it can be determined from other gamestate variables, specified in the Ruleset.<br />
<br />
An Agent may not take any dynastic actions that are contingent on the specific value of an Orphan Variable.<br />
<br />
=== Random Generators ===<br />
The Dice Roller at https://blognomic.com/dice/roll.php can be used to generate random results.<br />
<br />
* The DICE''N'' command can be used to generate a random number between 1 and N.<br />
* The FRUIT command will return a random result from the following options: Lemon, Orange, Kiwi, Grape, Cherry, Tangelo.<br />
* The COLOUR (or COLOR) command will return a random result from the following: White, Red, Green, Silver, Yellow, Turquoise, Magenta, Orange, Purple, Black.<br />
* The CARD command will return a card with a random suit (either Hearts, Diamonds, Spades or Clubs) and a random value (either Ace, 2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, King). A card with a value that is either Jack, Queen or King is a face card.<br />
* A list of comma-separated values in curly brackets (eg {x,y}) will return one of the values at random.<br />
<br />
Any changes to the potential outcomes of the Dice Roller’s random result commands must be made by Votable Matter.<br />
<br />
If a Votable Matter proposes a change to this rule that would require server-level access to the BlogNomic site to fully enact its effects, that Votable Matter must name an Agent with such access. Only an Agent with such access may Enact that Votable Matter. If that Votable Matter does not name an Agent with such access, that Votable Matter is Illegal.<br />
<br />
If a number or other game variable is selected “at random” or “randomly” from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified. This value must be determined by an appropriate roll in the Dice Roller, unless otherwise specified, and which value the roll result corresponds to must be reasonably inferable from the nature of the roll and any comments supplied by the Agent making the roll before or while making the roll. If a selection is explicitly specified as being “secretly” random, the Agent making this determination may do so using a private method of their choosing, instead of the Dice Roller.<br />
<br />
==Atomic Actions==<br />
<br />
An Atomic Action combines otherwise separate game actions into a single action.<br />
<br />
* All steps of an Atomic Action are considered one action, including the steps of an Atomic Action that is itself a step of a parent Atomic Action.<br />
* When an Agent performs an Atomic Action, they must complete all its steps; they must complete them in order; and they may not take any other dynastic action, or achieve victory, until all the steps are complete.<br />
* If a rule allows the Agent performing an Atomic Action to skip some of its steps, the skipped steps are considered to have been completed.<br />
* If an Agent arrives at a step in an Atomic Action and they cannot perform that step, they undo all the steps they have performed of that Action and are considered never to have performed that Action.<br />
* If one or more steps of an Atomic Action were done incorrectly, the Agent must redo the Atomic Action; for that purpose, the Agent uses any legal steps that have already been completed in the illegal Atomic Action and only redoes the illegal ones. (For example, if an Atomic Action consists of rolling a dice and then doing steps based upon its result, the Agent would have to reroll the dice only if they rolled the wrong one in the first place, and would then have to repeat any steps that depended upon the result of that dice; however, if they rolled the dice correctly but took an illegal step later on, the result of the original dice roll would still be used in the redone step.)<br />
* For the purposes of determining the ordering or legality of game actions, the time of an Atomic Action shall be the time that it is completed. For Atomic Actions that are redone, the time of completion is the last redone step.<br />
<br />
==Clarifications==<br />
<br />
===Numbers and Variables===<br />
* If a set of valid values is not specified in their definition, game variables defined to hold numeric values can hold only non-negative integers. Any action that would set those values below zero is an illegal action unless explicitly otherwise stated in the Ruleset.<br />
* Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.<br />
* All numbers, unless stated otherwise by a rule, are in base ten.<br />
* Unless otherwise specified, to “spend,” “pay” or “lose” an amount X of a numeric value “V” means to subtract X from V; to “gain” X of a numeric value “V” means to add X to V; and to “transfer” or “pay” X of a numeric value “V” from A to B means to subtract X from A’s V and add X to B’s V. Unless otherwise specified, only positive amounts can be spent, paid, lost, gained, or transferred, an Agent can spend or pay from only their own values, and a rule that allows Agents to transfer or pay a numeric value to another Agent only allows them to transfer that value from themselves to that other Agent (of their choice unless otherwise stated).<br />
* If a Dynastic Action is defined as having a cost X of numeric value V, or defines a requirement to spend, pay, or lose X of numeric value V to accomplish an effect or multiple effects, then the arithmetic effects of spending or payment and the act of carrying out those effects are considered to be subsequent steps in an Atomic Action, with the spending or payment step taking place before the effects step unless stated otherwise.<br />
* An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action’s effects are limited to changing values tracked in gamestate-tracking entities (such as a wiki page), and b) the action would change one or more of those values to an illegal value.<br />
* If a rule implies that the result of any calculation should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the calculation is instead the result rounded towards 0.<br />
* If a game variable has a default value but no defined starting value, then its default value should also be considered a starting value. If a game variable has neither a default value nor a starting value, then both may be considered to be the nearest legal value to zero that it may take (for numerical variables, defaulting to positive if tied), blank (for a text string or list that may be blank), the alphabetically earliest legal text string it may take (for a text string which may not be blank, with the digits 0 through 9 considered to precede “A”), or the list which is alphabetically earliest from the set of lists with the fewest elements (for lists which may not be blank, and considering each list to be a single unpunctuated text string, with the digits 0 through 9 considered to precede “A”). For the purposes of this bullet point, the names of Agents are not considered to be legal values for game variables, nor for list items within game variables.<br />
* If the rules that define a game variable are amended, and some previously valid values become invalid as a consequence, any existing variables whose current values would become invalid are instead set to their starting value.<br />
* Invalid values for game variables can never be used, even if the values stored in a gamestate-tracking entity remain valid. (for example, if X appears in a formula referring to a value that is a non-negative integer, X must be used as a non-negative integer)<br />
* DICEN cannot be rolled in the Dice Roller if N is greater than one million.<br />
* If a piece of information is described as being tracked secretly or privately by the Mainframe (including secretly random selections), then that information may only be revealed by the Mainframe when the ruleset allows it. If an Agent should already know such a piece of information (in that the Mainframe has already told them it, or vice versa, and there is no way that the information could have been changed since then), the Mainframe may repeat it to them.<br />
<br />
===Rules and Votable Matters===<br />
* If a new rule is created by a Votable Matter and its location is not noted in that Votable Matter, that new rule is to be placed in the Dynastic Rules.<br />
* If a wiki page becomes gamestate as a result of a Votable Matter enacting, that page shall – unless otherwise specified – be reverted to whatever state it was in at the time of that Votable Matter’s submission (and if the page did not exist at that time, it shall be blanked).<br />
* Where a [[#Votable Matters|Votable Matter]] would amend the effects of Votable Matter Enactment, this does not apply to its own enactment unless explicitly stated (e.g. a Votable Matter proposing that enacted Votable Matters earn their author a banana when enacted would not earn a banana for its own author, when enacted).<br />
* Rules which trigger upon the Resolution of a Votable Matter are the responsibility of the Admin who Resolves it.<br />
* Unless otherwise specified, a new Dynastic rule shall be placed at the end of the Dynastic Rules.<br />
* If a dynastic rule has no text and no subrules, any Agent may delete it from the ruleset.<br />
* A rule may be accompanied by one or more illustrations, and an illustration may have a caption. In all situations, unless otherwise explicitly stated, an illustration and a caption to an illustration must be treated as flavour text.<br />
* When the ruleset calls for the use of a specific tool (such as the dice roller, or an off-domain website, or a specific piece of downloadable software), Agents may not deliberately interfere with the function of that tool except in ways explicitly permitted by the ruleset.<br />
* If the Mainframe has voted DEFERENTIAL on a Proposal, that vote is instead considered to be valid and either FOR (if more Agents have a valid FOR vote on that Proposal than have a valid AGAINST vote on it) or AGAINST (in all other cases). However, in either case, votes of DEFERENTIAL made by other Agents on the same Proposal are not considered to be valid. If there are six or fewer Agents, then the Mainframe’s vote of DEFERENTIAL on a proposal is only affected by this rule if all Agents who are not the Mainframe have cast a vote on that proposal.<br />
<br />
===Time===<br />
* For the purpose of all rules, time in BlogNomic is in UTC.<br />
* All references to time must be either specific or defined within the Ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. “dinnertime”, “twilight”) cannot be achieved until they fulfil one of these criteria.<br />
* Where the month, day and/or year of a calendar date are ambiguous (e.g. “04/10/09”), it shall be assumed that the date is in a day/month/year format.<br />
* An Agent may not take more than one dynastic game action at the same time (excluding any actions which have been ongoing for more than three hours).<br />
<br />
===Spelling and formatting===<br />
* Superficial differences between the spelling of geographic versions of English, e.g. British English, American English and Australian English shall be construed as irrelevant for the purposes of play.<br />
* Agents may correct obvious spelling, punctuation, and/or typographical mistakes in the Ruleset and their own Pending Votable Matters at any time, including replacing Spivak and gender-specific pronouns that refer to Agents with the corresponding forms of the singular “they”.<br />
* An Agent may reformat a list of items in the dynastic ruleset to have bullet points or other appropriate list markup, if doing so would not change the order of that list, nor how any rules interpreted its content.<br />
<br />
===Names===<br />
* Within the Ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.<br />
* If a rule would ever have no name, it is instead given the name of the Votable Matter that created it, or (if this is not possible) the name “Unnamed Rule”.<br />
* The names of rules and wiki pages (other than the Ruleset) are flavour text.<br />
* Subrules can be referred to by a name which incorporates name of the rule they are a subrule of. Example: a subrule of the rule “Gin” is a “Gin Rule”, however the rule “Gin” is not a “Gin Rule” because it’s not a subrule of the rule “Gin”.<br />
* When referring to a Votable Matter, the name used in reference to a specific Votable Matter may be simplified by not including braces and any text between the opening and closing braces. i.e. a Votable Matter named “Changes [Core]” could instead be referred to by the name “Changes”.<br />
* When referring to a Rule, the name used in reference to a specific Rule may be simplified by not including braces and any text between a pair of opening and closing braces, as long as such a reference would be unambiguous.<br />
* Where a Votable Matter refers to a second Votable Matter by name, it is assumed to refer to the most recently posted Votable Matter of that name which pre-dates the first Votable Matter.<br />
* When changing their name or joining the game for the first time, an Agent's (or prospective Agent's ) new name must be between 4 and 30 characters in length, and may only include the 26 letters of the Latin alphabet, numbers, underscores, hyphens, full stops and apostrophes.<br />
<br />
==Prioritisation==<br />
* If two parts of the Ruleset contradict each other, precedence shall be construed in the following order:<br />
# The Appendix has precedence over any other Rule;<br />
# If a Core Rule explicitly says it cannot be overruled by a Dynastic Rule, that Core Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has precedence over that Core Rule;<br />
# If a Building Blocks Rule explicitly says that it cannot be overruled by a Dynastic Rule, that Building Blocks Rule has precedence over a Dynastic Rule, otherwise a Dynastic Rule has equal precedence as that Building Blocks Rule;<br />
# If two contradicting parts have equal precedence, the part with more limited scope applies (e.g. if the rules “Agents may Kick each other” and “Agents may not Kick each other on Tuesdays” exist, and it is Tuesday, Agents may not Kick each other);<br />
# If two contradicting parts have the same scope, or have scopes that only overlap where they contradict each other, the negative rule applies (e.g. with “Agents may Punch a Spaceman on Friday” and “Agents may not Punch Spacemen on Friday”, then Agents may not Punch Spacemen on Friday).<br />
<br />
==Mentors==<br />
<br />
An Agent may have another Agent as a Mentor. Agents who are willing to act as a Mentor are listed on the [[Mentorships]] wiki page, and are said to be “Tenured”. An Admin may add or remove their own name, or the name of an Agent who has requested a change on their own behalf, from this list at any time. The Mentorships page is also used to list the names of players who are prohibited from becoming Tenured; this list may only be amended by the effect of a votable matter.<br />
<br />
If an unmentored Agent requests a Mentor, or a new Agent has joined the game and has no Mentor, the Mainframe should select a Tenured Agent and ask them to take that Agent on as a Mentee; if they accept, then such a Mentorship is established. The members and starting dates of all active Mentorships are tracked on the Mentorships wiki page, and whenever a new Mentorship is established, the Mainframe should announce it in a blog post. The Mainframe should take care to consider game balance when selecting a potential mentor.<br />
<br />
A relationship between a mentor and a mentee is a Mentorship. An Agent may dissolve a Mentorship they are part of at any time, by announcing this in a blog post.<br />
<br />
If there is no Mainframe, any Agent who has been active in at least three previous dynasties may act as Mainframe for the purposes of this rule.<br />
<br />
===Things that a mentor must do===<br />
<br />
A mentor must do the following:<br />
<br />
*Make pro-active contact with their mentee when appointed, and explain the dynamics of the Mentorship system;<br />
*Be available to answer any questions that their mentee may have about the game, including explaining the rules, common standards and etiquette of play, proofreading posts and clarifying game events;<br />
*Introduce their mentee to the various platforms of the game, including the wiki and Dice Roller, and optionally the game’s Discord and social media feeds<br />
*If possible, give their mentee a nudge if it appears that they are at risk of becoming Idle;<br />
*If they themselves go idle, communicate with their mentee to either continue to support them as an idle Agent or arrange a handover to another mentor if requested.<br />
<br />
===Things that a mentor should do===<br />
The following sets out suggested best practice for Mentorship relationships:<br />
<br />
*The Mentorship lasts for four weeks or until the next Ascension Address, whichever occurs latest. It can continue informally for longer but after this threshold the mentor is no longer bound by any of the conditions set out in the parent rule to this rule, or any of its subrules.<br />
*The mentor can and should advise the mentee on how to proceed in the mentee’s own best interests. This can include making connections with other Agents .<br />
*The mentor should consider copying the mentee in on private, game-related communications, where it does not unfairly prejudice their own interests. The mentee should keep this information private without explicit consent from the mentor.<br />
*The mentor and mentee may work together to achieve victory. If a mentor achieves victory with support of their mentee then they should, if the mentee wishes it, pass the baton to the mentee.<br />
<br />
===Things that a mentor should not do===<br />
The following sets out a list of things that a mentor should not do in their relationship with their mentee. All of these are considered to be Fair Play rules, as per the rule Fair Play.<br />
<br />
*The mentor should not sock-puppet, bully, coerce or otherwise manipulate the mentee into performing any game actions.<br />
*The mentor should not seek to dissuade the mentee from pursuing other alliances.<br />
*A former mentor should not seek to use the fact of a prior Mentorship to influence the former mentee on an ongoing basis.<br />
<br />
== Synonyms ==<br />
<br />
A dynasty may provide extra theming by using alternative terms for words like “Agent” and “Mainframe”.<br />
<br />
Each term in this list is synonymous with the term in parentheses<br />
<br />
* Agent (Player)<br />
* Mainframe (Emperor)<br />
<br />
When a new Dynasty is started, the Ascension Address may specify new terms for each entry in the above list, provided the newly chosen term does not appear anywhere in the Building Blocks page or the ruleset outside of this rule (though if it only appears in rules which are being removed as part of the Ascension Address, it is fine), and that doing so would not cause two terms in the above list to become synonymous with each other. Doing so causes the old corresponding value (including regional spelling variations) to be replaced by the new value everywhere in the ruleset except in any of the parentheses in the above list.<br />
<br />
</div></div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25487The Database2024-01-26T18:33:46Z<p>Zack: New client</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Client Names<br />
|-<br />
| The Gibson<br />
|-<br />
| _Mel<br />
|-<br />
| jumpbox<br />
|-<br />
| Lilac<br />
|-<br />
| monkey<br />
|-<br />
| Dark Web<br />
|}</div>Zackhttps://wiki.blognomic.com/index.php?title=The_Database&diff=25485The Database2024-01-26T12:50:53Z<p>Zack: New client</p>
<hr />
<div>{| class="wikitable"<br />
|-<br />
! Client Names<br />
|-<br />
| The Gibson<br />
|-<br />
| _Mel<br />
|-<br />
| jumpbox<br />
|-<br />
| Lilac<br />
|-<br />
| monkey<br />
|}</div>Zack