नियमसेट का कैरेक्टर बिल्डर

इस पेज की मदद से ऐसा गाइडेड बिल्डर जोड़ें जो नस्ल और क्लास से लेकर स्कोर, दक्षताओं, स्पेल और सामान तक, चरणों में कैरेक्टर बनाता है। यह पेज नियमसेट लिखने वालों के लिए है। शुरू करने से पहले Game Mode के नियमसेट लिखना पढ़ें।

शीट sheet.builder घोषित कर सकती है (Capability API 1.86)। तब कैरेक्टर और पर्सोना एडिटर में और गेम के Edit sheet (शीट एडिट करें) में शीट एडिटर पूरे फ़ॉर्म, यानी All fields (सारे फ़ील्ड), के बगल में Guided (गाइडेड) व्यू पर खुलता है: ऊपर एक कतार में चरण, हर एक पर एक बैज जो गिनता है कि वह अभी कितने चुनावों का इंतज़ार कर रहा है, Back (पीछे) और Next (आगे) जो कभी नहीं रोकते (खिलाड़ी चुनाव बाद के लिए छोड़ सकता है), और उनके बगल में कैरेक्टर जैसा वह अभी है: चरणों ने जो लिखा, स्कोर, gm.sheetSummary के बताए मान (आर्मर क्लास, दक्षता बोनस) और प्रशिक्षित सेव और स्किल।

"builder": {
  "tier": "proficient",
  "steps": [
    { "id": "race", "label": "Race", "kind": "catalog", "catalog": "races", "field": "race" },
    { "id": "subrace", "label": "Subrace", "kind": "catalog", "catalog": "races", "min": 0,
      "within": { "step": "race", "filter": "parent" } },
    { "id": "class", "label": "Class", "kind": "catalog", "catalog": "classes", "field": "class" },
    { "id": "level", "label": "Level", "kind": "fields", "fields": ["level", "background"] },
    { "id": "scores", "label": "Ability Scores", "kind": "abilities", "methods": {
      "pointBuy": { "budget": 27, "costs": [[8, 0], [9, 1], [10, 2], [11, 3], [12, 4], [13, 5], [14, 7], [15, 9]] },
      "standardArray": [15, 14, 13, 12, 10, 8],
      "roll": { "count": 4, "sides": 6, "keep": 3 },
      "manual": true } },
    { "id": "skills", "label": "Proficiencies", "kind": "trained" },
    { "id": "gear", "label": "Equipment", "kind": "startingGear" }
  ]
}

अधिकतम 32 चरण, हर एक { id, label, kind, ... }; 16 से ज़्यादा वाला पैकेज Capability API 1.112 घोषित करता है, और 24 से ज़्यादा वाला Capability API 1.768:

  {
    "id": "spells",
    "label": "Spells",
    "kind": "catalog",
    "catalog": "spells",
    "within": { "step": "class", "filter": "class_ids" },
    "stamp": { "class": { "fromWithin": "label" } }
  }

शुरुआती सामान वाला चरण "strict": true रख सकता है (Capability API 1.109)। डिफ़ॉल्ट, सिर्फ़-मान्य (legal-only) मोड में, यह सिर्फ़ वह सामान देता है जिसका fits लाइव स्टेट के बिना शीट की अभी की हालत पर true पढ़ा जाता है, साथ में बिना fits वाला सामान; कोई Other gear सूची नहीं होती। 5e के लिए, Wizard किट पर fits: { "value": { "field": "wizard_level" }, "atLeast": 1 } रखें और हर दूसरी क्लास की किट पर उसी क्लास के स्तर वाला फ़ील्ड; Acolyte किट से fits हटा दें ताकि वह सबके लिए फ़िट हो। Free edit हर किट फिर से देता है। इन्वेंटरी का पिकर क्लास बदलने या Free edit छोड़ने के बाद फ़िट न होने वाला चुनाव साफ़ कर देता है और वजह बताता है; सामान लेने से पहले वह फ़िट भी जाँचता है। फ़िट होने वाला कोई सामान न हो तो चरण अपनी खाली हालत दिखाता है, और Next खुला रहता है। strict के बिना वाले चरण हर किट देते रहते हैं। मोड हर स्क्रीन का अपना होता है, सेव हुए बिल्ड के साथ दर्ज नहीं होता और सर्वर को नहीं भेजा जाता।

किसी चुनाव से जो मिलता है वह उसकी एंट्री का grants है, जिसे सिर्फ़ बिल्डर पढ़ता है:

{
  "id": "half-elf",
  "label": "Half-Elf",
  "grants": {
    "abilities": { "add": { "cha": 2 }, "choose": [{ "count": 2, "amount": 1, "except": ["cha"] }] },
    "trained": { "skills": [], "saves": [], "choose": [{ "what": "skills", "count": 2 }] },
    "sets": { "speed": 30 }
  }
}

चुनाव हटाने से वह वापस लिया जाता है जो उस चुनाव ने दिया था, और सिर्फ़ वही: उसकी बढ़ोतरी (जितना किसी स्कोर की सीमाएँ उसे ऊपर जाने देती थीं), उसका प्रशिक्षण, उसके फ़ील्ड के मान और उसकी पंक्तियाँ। शीट में खिलाड़ी का अपना जो पहले से था (हाथ से प्रशिक्षित की गई स्किल, कैटलॉग पिकर से जोड़ी गई पंक्ति) वह उसी का रहता है, और All fields में किया गया एडिट तब तक रहता है जब तक उस मान के लिए बिल्डर का अपना जवाब न बदले। एक ही कैटलॉग पर दो चरणों में चुनी गई एंट्री एक बार देती है, और गेम की लेयर जिस एंट्री को छिपाती है, वह अपनी दी चीज़ों के लिए फिर भी गिनी जाती है। जिस फ़ील्ड को कोई चुनाव sets करता है, वह सिर्फ़ तब लिखा जाता है जब वह अब भी खाली हो, या जब बिल्डर पहले से उसके लिए जवाब देता हो, इसलिए हाथ से टाइप किया गया स्तर कभी दोबारा नहीं लिखा जाता; जिस मान के लिए बिल्डर जवाब देता है और जिसे खिलाड़ी उसके अपने fields चरण में बदलता है, वह बिल्डर का ही रहता है, और तब चला जाता है जब बाद का कोई चुनाव उसे नहीं माँगता। खिलाड़ी के चुनाव शीट के बगल में रखे जाते हैं, इसलिए कोई चरण बाद में फिर खोला जा सकता है।

चरणों में रेटिंग बाँटना (Capability API 1.152)। allocate चरण हर पॉइंट पर एक डॉट खरीदता है, अपने बजट और बनाने के समय की सीमाओं के साथ। यह इकलौते abilities चरण का तरीका या सेव किए जवाब नहीं बदलता। एट्रिब्यूट, Virtues और बाद के freebies के लिए अलग-अलग चरण इस्तेमाल करें:

{
  "id": "attributes",
  "label": "Attributes",
  "kind": "allocate",
  "priorities": [7, 5, 3],
  "annotations": true,
  "groups": [
    {
      "id": "physical",
      "label": "Physical",
      "targets": [{ "ability": "strength" }, { "ability": "dexterity" }, { "ability": "stamina" }],
      "base": 1,
      "min": 1,
      "max": 5
    },
    {
      "id": "social",
      "label": "Social",
      "targets": [{ "ability": "charisma" }, { "ability": "manipulation" }, { "ability": "appearance" }],
      "base": 1,
      "min": 1,
      "max": 5
    },
    {
      "id": "mental",
      "label": "Mental",
      "targets": [{ "ability": "perception" }, { "ability": "intelligence" }, { "ability": "wits" }],
      "base": 1,
      "min": 1,
      "max": 5
    }
  ]
}

1–12 समूह होते हैं, हर एक में स्थिर id, label और 1–120 लक्ष्य। लक्ष्य पूरे चरण में अलग-अलग होते हैं। लक्ष्य ठीक एक मौजूदा { ability }, संख्या वाले { field }, { skill }, { save } या { bonus } का नाम देता है; बोनस किसी मौजूदा स्किल या सेव के लिए संख्या वाली build.bonuses एंट्री है। समूह ठीक एक बजट मोड इस्तेमाल करते हैं: priorities में हर समूह के लिए एक गैर-ऋणात्मक पूर्णांक हिस्सा होता है (दोहराव मंज़ूर), या हर समूह budget: Ref घोषित करता है। प्राथमिकता के स्लॉट साफ़ तौर पर दिए जाते हैं, और भरा हुआ स्लॉट देने पर समूह आपस में अदल-बदल जाते हैं। ऐरे का क्रम primary, secondary, tertiary, फिर नंबर वाली प्राथमिकताएँ बताता है; अगर ये नाम आकार के क्रम में चाहिए तो बड़े हिस्से पहले रखें। बजट अधिकतम 1,200,000 पॉइंट होते हैं।

base वैकल्पिक है; min और max ज़रूरी हैं। हर एक पूर्णांक या गैर-लाइव Ref लेता है, जैसे { "derived": "archetype_floor" }। रेटिंग 0 से 10,000 तक की पूरी संख्याएँ बननी चाहिए और लक्ष्य की स्टोरेज सीमाओं या स्तर मैप में समानी चाहिए। पहला base खाली लक्ष्य के डिफ़ॉल्ट की जगह लेता है, मौजूदा तरीके के स्कोर और देन रखते हुए; बाद का base पिछली स्टेज पर निचली सीमा है। base के बिना स्टेज मौजूदा रेटिंग से शुरू होती है। बराबर min/max बनाने का स्कोर तय कर देता है: base: 0, min: 0, max: 0 तय Appearance बताता है। न्यूनतम अपने आप डॉट नहीं खरीदते। बजट और सीमाएँ निकाले गए मानों के मौजूदा ऑपरेटर इस्तेमाल कर सकती हैं, लेकिन इस या बाद के चरण से बदले गए लक्ष्य नहीं पढ़ सकतीं, निकाले गए मानों के ज़रिए भी नहीं। मुफ़्त देन की शर्तें भी उस बाँटने वाले समूह की रेटिंग नहीं पढ़ सकतीं जिसे वे बदल सकती हैं, दूसरी स्टेज के जुड़े हुए समूहों समेत। फ़ॉर्मूले वाली कीमतें समर्थित नहीं हैं: हर चुकाई गई बढ़ोतरी की कीमत एक पॉइंट है। जो स्रोत सुलझ न सके या अमान्य हो, वह not configured दिखता है।

स्किल और सेव लक्ष्यों को sheet.builder.ratingTiers चाहिए, हर लक्ष्य के लिए अलग से:

"ratingTiers": [
  { "target": { "skill": "athletics" }, "tiers": ["none", "trained", "expert"] },
  { "target": { "save": "will" }, "tiers": ["none", "trained"] }
]

ऐरे का इंडेक्स संख्या वाली रेटिंग है। मैप में 1–12 मौजूदा, बढ़ते क्रम में दिए गए स्तर ID होते हैं, जो नियमसेट के बिना प्रशिक्षण वाले स्तर से शुरू होते हैं; इन्हें कभी स्तर के बोनस से अनुमान लगाकर नहीं निकाला जाता। अलग-अलग लक्ष्य अलग-अलग मैप इस्तेमाल कर सकते हैं। बनाने के समय की अलग सीमाओं वाले लक्ष्य अलग समूहों में रखें।

कैटलॉग का grants.ratings सारी चुकाई जाने वाली स्टेज से पहले मुफ़्त डॉट देता है:

"ratings": [
  { "target": { "skill": "athletics" }, "add": 1 },
  { "target": { "save": "will" }, "set": 1 }
]

हर देन में या तो धनात्मक add होता है या गैर-ऋणात्मक set, दोनों कभी नहीं। सारी set देन निचली सीमाएँ हैं: सबसे ऊँची जीतती है, फिर सारे add जुड़ते हैं, लक्ष्य की स्टोरेज सीमा पर रुककर। इसलिए दो मुफ़्त रैंक add, चुकाने वाले बजट से कुछ लिए बिना, रैंक दो तक पहुँचते हैं। मौजूदा प्रशिक्षण और फ़ील्ड/एबिलिटी देन इन रेटिंग देन से पहले जुड़ती हैं। एंट्री के विकल्प अब भी सिर्फ़ पंक्तियाँ लिखते हैं; वे चुनी गई एंट्री की अपनी देन कभी आगे लागू नहीं करते।

UI base/पिछली, मुफ़्त, खरीदी गई और कुल रेटिंग, बनाने का दायरा और बचा बजट दिखाता है। सीमा पर, बजट के बिना, या जब अमान्य खरीद या हाथ से किए ओवरराइड पर ध्यान देना हो, तब प्लस बंद रहता है। कम खर्च, असंभव न्यूनतम और ओवरराइड को बैज मिलते हैं; Back और Next उपलब्ध रहते हैं। प्राथमिकता फिर से देने पर समूह की सेव की गई बढ़ोतरियाँ बनी रहती हैं। ज़्यादा खर्च वाला समूह पूरा निष्क्रिय हो जाता है; लक्ष्य की सीमा से ऊपर की खरीद उस लक्ष्य के लिए निष्क्रिय हो जाती है। उन्हें ठीक करने के लिए वे जवाब घटाएँ या साफ़ करें, या उन्हें फिर सक्रिय करने के लिए पहले वाला हिस्सा लौटा दें। बाद की स्टेज बनाने के समय की पहले वाली सीमाओं से आगे जा सकती हैं। All fields खुला एडिट बना रहता है, जिसमें ओवरराइड बनाने के नियमों के हिसाब से सीमित किए जाने के बजाय साफ़ दिखाए जाते हैं।

सेव किया गया builder.allocations[stepId] समूह ID के हिसाब से प्राथमिकता स्लॉट इंडेक्स, चुकाई गई bought बढ़ोतरियाँ और स्थिर kind/id लक्ष्य कुंजियों (जैसे ability/strength) के हिसाब से वैकल्पिक notes रखता है। annotations: true विरासत की व्याख्या या विशेषज्ञता के लिए हर लक्ष्य पर अधिकतम 1,000 अक्षर देता है; बिल्डर उस टेक्स्ट को नहीं आँकता। लागू बढ़ोतरियाँ हर स्टेज के हिसाब से अलग रखी जाती हैं। फिर खोलने पर देन दोबारा नहीं दी जातीं और संसाधन फिर नहीं भरते, और मौजूदा शीट का ब्योरा देने पर चुनाव उसे दोबारा लिखे बिना दर्ज होते हैं, ब्योरा खत्म होने पर भी। चुनाव हटाने पर मुफ़्त रेटिंग और चुकाई गई स्टेज दोबारा निकाली जाती हैं, हाथ से किए अंतर बचाए रखते हुए।

साझा बजट और कीमत वाली खरीद (Capability API 1.153)। sheet.builder.pools में बनाने के अधिकतम 12 पूल घोषित करें। कई spend चरण एक पूल इस्तेमाल कर सकते हैं; अलग पूल पेशे और निजी रुचि के पॉइंट अलग रखते हैं। बजट गैर-लाइव वैल्यू रेफ़रेंस होते हैं, मौजूदा sum, scale, multiply, min, max, stepTable, enumTable और listSum गणनाओं समेत। उनका सुलझा मान सीमित और 0 से 100,000 के बीच होना चाहिए। न मिलने वाला स्रोत "not configured" है।

{
  "pools": [
    { "id": "occupation", "label": "Occupation", "budget": { "derived": "occupation_points" }, "creditLimit": 0 },
    { "id": "interest", "label": "Personal interest", "budget": { "derived": "interest_points" } }
  ],
  "steps": [
    {
      "id": "occupation_skills",
      "label": "Occupation skills",
      "kind": "spend",
      "pool": "occupation",
      "offers": [
        {
          "id": "accounting",
          "label": "Accounting",
          "target": { "field": "accounting_value" },
          "cost": { "flat": 1 },
          "min": 5,
          "max": 99
        }
      ]
    }
  ]
}

हर चरण में स्थिर id और label वाले अधिकतम 120 ऑफ़र होते हैं। लक्ष्य वही ठीक-एक ability, संख्या वाला field, मैप किया गया skill/save, या bonus वाला नियम मानते हैं जो बाँटने वाली स्टेज मानती हैं। सूची-पंक्ति की खरीद पंक्ति की पहचान वाले फ़ीचर (F4) के लिए आरक्षित है; यह API पंक्तियों को ऐरे में उनकी जगह से नहीं पहचानता। सीमाएँ लक्ष्य की स्टोरेज सीमाओं में समानी चाहिए। शुरुआती रेटिंग और मुफ़्त देन बची रहती हैं, उनकी कीमत फिर कभी नहीं ली जाती: दो मुफ़्त डॉट और पाँच चुकाए गए डॉट वाले Background के सात होते हैं।

कीमत ठीक इनमें से एक होती है:

वैकल्पिक overrides: [{ "when": { "derived": "career_affinity" }, "cost": { "perRank": 2 } }] में अधिकतम 12 एंट्री होती हैं। पहली धनात्मक शर्त जीतती है। शर्तें खरीद से पहले की शीट पढ़ती हैं; कोई मेल न होने पर बेस कीमत लगती है। बजट और शर्तें खरीदे गए लक्ष्य नहीं पढ़ सकतीं, निकाले गए मानों के ज़रिए भी नहीं, न बाद के चुनावों पर निर्भर हो सकती हैं। मुफ़्त देन और बाँटने वाली स्टेज कीमत वाली खरीद से पहले लागू होती हैं।

कीमतें धनात्मक होती हैं, सिवाय साफ़ घोषित क्रेडिट के। जिस कमी (flaw) की रेटिंग बढ़ती है, उसके लिए "credit": true, "cost": { "flat": -1 } इस्तेमाल करें। घोषित baseline से घटाने के लिए "credit": true, "baseline": 10, "min": 6, "max": 10, "cost": { "flat": 1 } इस्तेमाल करें: एक खरीद 10 को 9 करती है और एक पॉइंट का क्रेडिट दर्ज करती है। शुरुआती मान baseline से मेल खाना चाहिए। क्रेडिट वाले लक्ष्य का पूरे बिल्डर में एक ही ऑफ़र होता है, जिससे खरीद/क्रेडिट के चक्र नहीं बनते।

पूल का डिफ़ॉल्ट शून्य क्रेडिट है। creditLimit को कुल क्रेडिट की अधिकतम सीमा पर सेट करें और वैकल्पिक रूप से अधिकतम 12 caps: [{ "filter": "flaw", "maxCredit": 2 }] जोड़ें। फ़िल्टर ऑफ़र के tags: ["flaw"] का नाम देते हैं, इसलिए flaw और disadvantage के क्रेडिट की अलग-अलग सीमाएँ हो सकती हैं। सीमाएँ कुल क्रेडिट गिनती हैं, धनात्मक खर्च से अलग। अलग-अलग quirk की गिनती चुनाव/पंक्ति की पाबंदियाँ ही रहती हैं।

गिनी गई पंक्तियाँ और मेल खाने वाली पंक्तियाँ (Capability API 1.205)। listSum where: { "column", "equals" } रख सकता है ताकि सिर्फ़ वे पंक्तियाँ पढ़ी जाएँ जिनका सेल किसी मान के बराबर है (खाली सेल अपने कॉलम का डिफ़ॉल्ट पढ़ता है), और column की जगह count: true ताकि कॉलम जोड़ने के बजाय पंक्तियाँ गिनी जाएँ। Genesys का talent पिरामिड दो निकाली गई गिनतियाँ और बनाने का एक नियम है:

{
  "id": "tier2",
  "label": "Tier 2 talents",
  "op": "sum",
  "of": [{ "listSum": { "list": "talents", "count": true, "where": { "column": "tier", "equals": 2 } } }]
}

साथ में ऐसा नियम जिसका value tier2 पढ़ता है और जिसका max tier 1 की गिनती से एक कम पढ़ता है।

हर पंक्ति के लिए निकाली गई कीमत (Capability API 1.206)। rows चरण का ऑब्जेक्ट cost अपने column को times से गुणा कर सकता है और add जोड़ सकता है, इसलिए { "column": "tier", "times": 5 } Genesys talent की कीमत हर tier पर 5 XP रखता है; अकेला add ऑब्जेक्ट के रूप में लिखी गई तय कीमत है। overrides (अधिकतम 4) ऐसी कीमत देता है जो तब इस्तेमाल होती है जब किसी prefix और पंक्ति के अपने सेल से नामित निकाला गया मान शीट पर 0 से ऊपर पढ़ा जाए: { "add": 5, "overrides": [{ "derived": { "prefix": "affinity_", "cell": "ability" }, "cost": 4 }] } Exalted Charm की कीमत 4 Bonus Points रखता है जब affinity_<its Ability> 0 से ऊपर हो। enum सेल के लिए उसके हर संभव मान का निकाला गया मान होना चाहिए।

बिना कीमत वाले ऑफ़र (Capability API 1.207)। spend ऑफ़र की cost (या ओवरराइड की) { "unpriced": true } हो सकती है जब तक स्रोत ने कीमत नहीं दी: ऑफ़र एक नोट के साथ दिखता है, पूल को बिना कुछ लिए रोके रखता है, और कभी खरीदा नहीं जाता। जिस कीमत पर सेव हुई खरीद बाद में बिना कीमत की हो जाए, वह निष्क्रिय हो जाती है और ठीक करने के लिए रखी जाती है।

ज़्यादा फ़ील्ड (Capability API 1.208)। शीट अधिकतम 240 फ़ील्ड घोषित कर सकती है; 1.208 से पहले सीमा 160 है। Rolemaster के skill ranks, category ranks, potentials और totals को यह जगह चाहिए।

एबिलिटी में लिखे जाने वाले रोल (Capability API 1.209)। roll चरण का रोल field की जगह ability का नाम दे सकता है (दोनों में से ठीक एक)। नतीजा एबिलिटी की अपनी सीमाओं में रखा जाता है। gain के साथ चेक स्कोर के विरुद्ध रोल होता है और सिर्फ़ उससे ऊपर का नतीजा gain जोड़ता है, जिसे बिल्डर फिर बढ़ोतरी के रूप में रखता है: स्कोर फिर रोल करने या खरीदने पर भी सुधार ऊपर बना रहता है। gain के बिना नतीजा टाइप किए स्कोर की तरह लिखा जाता है, और तब तक रहता है जब तक उस स्कोर के लिए बिल्डर का अपना जवाब न बदले। निकाली गई एबिलिटी रोल नहीं हो सकती, और हर एबिलिटी एक चरण में अधिकतम एक बार रोल होती है।

निकाले गए सूची कॉलम (Capability API 1.210)। नंबर कॉलम sum का नाम दे सकता है: उसी पंक्ति के अधिकतम छह दूसरे नंबर कॉलम, जोड़े गए (खाली सेल अपने कॉलम का डिफ़ॉल्ट पढ़ता है) और कॉलम के min और max के अंदर रखे गए। सेल सिर्फ़ पढ़ने के लिए दिखता है, सेव हुई शीट के हर रीड पर भरा जाता है, और जोड़, पंक्ति के चेक और बाकी हर चीज़ उसे टाइप किए सेल की तरह पढ़ती है। निकाला गया कॉलम रोल नहीं होता और कभी किसी दूसरे निकाले गए कॉलम को नहीं जोड़ता। CoC specialty की रेटिंग "sum": ["base", "occupation", "interest"] है।

आंशिक स्कोर बढ़ोतरी (Capability API 1.211)। देन का abilities.choose partialFrom का नाम दे सकता है। विकल्प आने पर जो स्कोर पहले से उस निशान पर या उससे ऊपर है, उसे आंशिक बढ़ोतरी मिलती है, और दो आंशिक मिलकर एक बार amount देती हैं। विकल्प उसी क्रम में गिने जाते हैं जिसमें बिल्डर उन्हें बनाता है, हर पूरी बढ़ोतरी के बाद, इसलिए Pathfinder 2e के बाद के boosts "amount": 1, "partialFrom": 4 पढ़ते हैं: +4 मॉडिफ़ायर को +5 तक पहुँचने में दो boost लगते हैं। यह upTo के साथ मिलकर चलता है।

किसी रुख में पंक्ति के चेक (Capability API 1.212)। सूची की checks[] एंट्री stance का नाम दे सकती है, जो डाइस पूल के resolution.stances में से एक है। तब हर पंक्ति का चेक उसी रुख में होता है, जैसे रुख में सूचीबद्ध स्किल: Stewpot के pursuits STILLNESS के तरीके से डाइस गिनते हैं। Game Master का रिमाइंडर पंक्तियों का नाम रुख की स्किल के साथ देता है।

एबिलिटी की विशेषज्ञताएँ (Capability API 1.213)। सूची का contextual "abilities": true सेट कर सकता है। तब उसका skill सेल स्किल के साथ-साथ किसी एबिलिटी का नाम भी दे सकता है (ID, लेबल या छोटे रूप से), और पंक्ति उस एबिलिटी से रोल होने वाले किसी भी चेक पर लागू होती है: सीधा एबिलिटी चेक, ऐसी स्किल जिसकी अपनी एबिलिटी यही है, या ऐसी स्किल जिसे with= इस पर बदलता है। World of Darkness की attribute specialty, "Strength: lifting", "lifting" नाम की पंक्ति है जिसका skill सेल "Strength" पढ़ता है।

रद्द करना बंद (Capability API 1.214)। contextual check (सूची के contextual या एंट्री के mechanics.contextual पर) "cancel": false सेट कर सकता है। जिस रोल पर यह लागू होता है, उस पर resolution.cancel.upTo या उससे नीचे के फलक कोई सफलता नहीं घटाते; गंभीर विफलता उन्हें फिर भी पढ़ती है। बंद करने के लिए नियमसेट में resolution.cancel होना चाहिए।

साथ रखे बिना खुलने वाले आइटम (Capability API 1.215)। कैटलॉग एंट्री का grants.itemAccess नियमसेट के अधिकतम 48 आइटम सूचीबद्ध करता है (<catalog>/<entry>, कभी कोई service नहीं)। गाइडेड बिल्डर में एंट्री चुनने पर ये कैरेक्टर के लिए खुल जाते हैं: शीट और Game Master का शीट ब्लॉक इन्हें साथ न रखे गए के रूप में सूचीबद्ध करते हैं, और थैले में कुछ नहीं जाता। लिए जाने पर Game Master इन्वेंटरी में एक जोड़ता है, जैसे Blades का कैरेक्टर score की शुरुआत में load घोषित करता है।

बनाते समय पंक्तियों के डॉट (Capability API 1.216)। allocate समूह rows का नाम दे सकता है, अधिकतम चार {list, column} जोड़ियाँ: सूची की पंक्तियों में उस नंबर कॉलम के डॉट उसके लक्ष्यों के साथ समूह के बजट में गिने जाते हैं। पंक्तियाँ सूची पर एडिट होती हैं; बजट से ज़्यादा पंक्ति डॉट वाला समूह खिलाड़ी का इंतज़ार करता है। rows चरण का कीमत ओवरराइड तय cost की जगह times दे सकता है, यानी कीमत वाले कॉलम के लिए प्रति इकाई दर। Exalted की Craft पंक्तियाँ "dots" को 28 Ability डॉट में गिनती हैं और "bought" डॉट की कीमत times: 2 रखती हैं, जहाँ affinity_<ability> सेट हो वहाँ times: 1 में ओवरराइड; निकाला गया रेटिंग कॉलम (1.210) दोनों को जोड़ता है।

सबसे अच्छी रेटिंग (Capability API 1.217)। contextual check "best": true सेट कर सकता है: जिस स्किल चेक पर यह लागू होता है वह कैरेक्टर की सबसे अच्छी स्किल रेटिंग रोल करता है, जब वह माँगी गई से ऊँची हो। dice-highest नियमसेट ऐसा contextual चेक इस्तेमाल कर सकता है जो सिर्फ़ यही करे; बाकी हर चेक असर के लिए अब भी डाइस पूल चाहिए। Blades का Rook's Gambit "check": {"best": true} वाली special-ability पंक्ति है, जो नाम से लागू होती है।

ट्रैक चिह्नित करने वाली कीमतें (Capability API 1.218)। contextual cost एंट्री {"pool", "amount"} के साथ-साथ {"track": "<id>", "by": N} भी हो सकती है: पंक्ति या एंट्री लागू करने पर वह साधारण लाइव ट्रैक N से चिह्नित होता है, जहाँ तक उसकी सीमाएँ जाने दें (घाव ट्रैक इस तरह चिह्नित नहीं होता)। सूची का contextual भी cost रख सकता है। Blades का Rook's Gambit "check": {"best": true} और "cost": [{"track": "stress", "by": 2}] वाली पंक्ति है। apply= से लागू किए गए नाम घुमावदार और सीधे apostrophe और कोट को एक जैसा पढ़ते हैं।

उधार लिए गए कैटलॉग (Capability API 1.220)। कैटलॉग अपना रखने के बजाय किसी दूसरे इंस्टॉल किए नियमसेट का कैटलॉग उधार ले सकता है: { "id": "creatures", "label": "Creatures", "holds": "creatures", "from": { "ruleset": "5e-2014", "catalog": "creatures" } }। उधार देने वाला अपने ID से मिलता है, सीधे या किसी community namespace के नीचे, और उसकी एंट्री उधार लेने वाले नियमसेट के हिसाब से पढ़ी जाती हैं, इसलिए जो एंट्री किसी ऐसी चीज़ का नाम देती है जिसे उधार लेने वाला घोषित नहीं करता (स्थिति, खतरे का स्तर, इंद्रिय), वह छोड़ दी जाती है और लॉग होती है, जबकि बाकी आ जाती हैं। from के साथ entries उधार ली गई एंट्री में जुड़ती हैं, या उसी ID वाली किसी की जगह लेती हैं; नियमसेट पढ़ते समय इनकी जाँच होती है, इसलिए हेडर इनके रखे किसी भी filters का नाम देता है (बिना फ़िल्टर वाला हेडर उधार देने वाले के फ़िल्टर लेता है)। शीट के रूप में लिखा उधार लिया जीव उधार देने वाले के ID इस्तेमाल करता है; from.sheet बताता है कि वे उधार लेने वाले में कैसे पढ़े जाते हैं: fields किसी फ़ील्ड को दूसरे ID से जोड़ता है (या उसे छोड़ने के लिए null), values किसी फ़ील्ड के मान जोड़ता है, और tiers प्रशिक्षण स्तर जोड़ता है (जीव के, और जिन्हें कोई एंट्री देती या माँगती है), जैसे "sheet": { "fields": { "ac": "ac_typed", "size": null }, "values": { "hp_method": { "by_hand": "manual" } }, "tiers": { "proficient": "trained" } } में। कोई भी उधार ली गई एंट्री, आइटम समेत, दो और कुंजियाँ ले सकती है: refs उधार देने वाले का निकाला गया मान उधार लेने वाले के किसी मान के रूप में पढ़ता है ("refs": { "prof_martial_weapons": { "field": "martial_weapons" }, "armor_speed_strength": { "abilityScore": "str" } }), और slots आइटम का स्लॉट उधार लेने वाले के नाम के नीचे रखता है ("slots": { "body": "armor" })। कैटलॉग अपने ही नियमसेट से या ऐसे कैटलॉग से उधार नहीं ले सकता जो खुद उधार लेता हो। उधार लिए जीव की आर्ट उधार देने वाले के जीव की तरह मिलाई जाती है (जीव पैक में 5e-2014/creatures/<id>)। उधार लिए कैटलॉग के अंदर के हवाले, जैसे जीव के स्पेल, कैटलॉग पढ़ते समय जाँचे जाते हैं, नियमसेट पढ़ते समय नहीं।

उन्नति की लंबी सूचियाँ (Capability API 1.219)। sheet.advancement.fields अधिकतम 64 फ़ील्ड लेता है (पहले 24), इसलिए जिस गेम में स्तर कई फ़ील्ड बढ़ाता है, जैसे हर स्पेल स्तर के स्लॉट और दक्षता सूचियाँ, वह GM को उन सबको बढ़ाने दे सकता है। 24 से ज़्यादा फ़ील्ड वाली सूची को 1.219 चाहिए।

दोतरफ़ा, मालिकाना और अदला-बदली वाली खरीद (Capability API 1.164)। "direction": "both" एक ऑफ़र को अपनी रेटिंग शुरुआती जगह से ऊपर और नीचे दोनों करने देता है (घोषित होने पर उसका baseline शीट से मेल खाना चाहिए): ऊपर का हर कदम कर्व की कीमत लेता है और शुरुआत से नीचे का हर कदम उसे क्रेडिट के रूप में वापस कमाता है, पूल के creditLimit और सीमाओं के अंदर। हिसाब हमेशा एक ही दिशा में चलता है, इसलिए खरीदी गई रेटिंग घटाने से आखिरी खरीद उसी कीमत पर वापस ली जाती है जिस पर चुकाई गई थी, और घटाई गई रेटिंग बढ़ाने से उसका क्रेडिट वापस चुकाया जाता है; खरीदना और घटाना कभी क्रेडिट नहीं बनाता। ऐसे लक्ष्य का पूरे बिल्डर में एक ऑफ़र होता है। GURPS ST { "target": { "ability": "st" }, "direction": "both", "baseline": 10, "min": 7, "max": 14, "cost": { "flat": 10 } } है; टेबल वाली कीमत Basic Speed जैसे भिन्न वाले कदमों की कीमत तय करती है। "direction": "increase" और "decrease" सीधे एकतरफ़ा ऑफ़र का नाम देते हैं ("decrease" ऊपर वाली कमी है, अपने baseline और क्रेडिट के साथ)।

"effect": "ownership" किसी ऑफ़र की कीमत उसकी अपनी सीढ़ी पर, उसके baseline (या min) से ऊपर, तय करता है, और शीट अपने मान और खरीदे गए स्तर में से ऊँचा रखती है: GURPS की एक पॉइंट वाली familiarity चुकाई और सूचीबद्ध की जाती है, तब भी जब कोई default पहले से बेहतर हो, और उसे लौटाने से शीट का कुछ नहीं जाता।

"exchange": { "from": <rating>, "units": 2, "gain": 1, "floor": 9 } किसी ऑफ़र को बनाने के समय का बंद लेन-देन बनाता है: हर खरीद from को units घटाती है और लक्ष्य को gain (डिफ़ॉल्ट 1) बढ़ाती है, और कभी from को floor से नीचे या लक्ष्य को max से आगे नहीं ले जाती। इसकी पूल से कोई कीमत नहीं, इसलिए यह cost छोड़ देता है। लेन-देन में मिले पॉइंट आगे लेन-देन में नहीं जाते: एक बार किसी लेन-देन ने रेटिंग बढ़ाई, तो कोई दूसरा लेन-देन उसे नहीं घटाता, और एक बार किसी ने रेटिंग घटाई, तो कोई दूसरा उसे नहीं बढ़ाता। जो लेन-देन कोई क्लास नहीं ले सकती (when), वे उन्हीं रेटिंग का उलटे क्रम में नाम दे सकते हैं। रिफ़ंड दोनों रेटिंग वापस कर देता है। OSE का prime-requisite लेन-देन घटाए गए हर स्कोर के लिए एक ऑफ़र है:

{
  "id": "wis_to_int",
  "label": "Lower Wisdom to raise Intelligence",
  "target": { "ability": "int" },
  "exchange": { "from": { "ability": "wis" }, "units": 2, "floor": 9 },
  "min": 3,
  "max": 18
}

बिल्डर स्थिर step/offer ID के नीचे चिह्न वाले चुकाए गए अंतर और उनकी मूल कीमतें सेव करता है, हर ऑफ़र पर अधिकतम 1,000 खरीद लाइनें। रिफ़ंड सबसे नई लाइन हटाता है और ठीक उसका योगदान और दर्ज कीमत पलटता है, क्रेडिट हटाने समेत। यह कभी मुफ़्त रेटिंग रिफ़ंड नहीं करता। कोई लाइव XP, इन्वेंटरी, मुद्रा या पार्टी संसाधन खर्च नहीं होते।

करियर, मुफ़्त देन या बजट के स्रोत बदलने पर हिसाब बना रहता है। अमान्य खरीद निष्क्रिय होती हैं; पूल अपना मूल खर्च, ज़्यादा खर्च होने पर ऋणात्मक बचे पॉइंट, और प्रस्तावित नई कीमत दिखाता है। साझा लक्ष्य दूसरे पूल की निर्भर खरीद भी रोक देते हैं। Reprice saved purchases (सेव की गई खरीद की कीमत फिर तय करें) पूल के लिए मान्य नई कीमत साफ़ तौर पर स्वीकार करता है; वरना उसे ठीक करने के लिए लाइनें रिफ़ंड करें। कोई खरीद चुपचाप हटाई या बेची नहीं जाती। बिना खर्च के पॉइंट सिर्फ़ जानकारी के लिए हैं। Back/Next उपलब्ध रहते हैं, और All fields स्कीमा की सीमाओं के अंदर दिखने वाले हाथ के ओवरराइड बचाए रखता है। मौजूदा कैरेक्टर का ब्योरा देना और सेव किए चुनाव फिर खोलना कभी दोबारा डॉट नहीं देता।

नामित पंक्तियाँ (Capability API 1.154)। rows चरण खिलाड़ी को बनाते समय शीट की किसी सूची पर अपनी पंक्तियाँ जोड़ने, एडिट करने और हटाने देता है: retainers, contacts, rituals और उनकी सामग्री, या कुछ भी और जो कैटलॉग में नहीं है।

{
  "id": "retainers",
  "label": "Retainers",
  "kind": "rows",
  "list": "retainers",
  "columns": ["name", "role", "loyalty"],
  "required": ["name"],
  "min": 1,
  "max": 4,
  "defaults": { "role": "Hireling" }
}

columns सूची के कॉलम का वह हिस्सा है जिसे चरण एडिट करता है (छोड़ने पर सभी)। required उन कॉलम का नाम देता है जो किसी पंक्ति के गिने जाने के लिए भरे होने चाहिए। बैज min (0 से 20) से नीचे अभी गायब पूरी पंक्तियाँ गिनता है, साथ में हर वह पंक्ति जिसका कोई ज़रूरी सेल खाली है, इसलिए आधी लिखी सामग्री अनसुलझी रहती है। max Add a row (पंक्ति जोड़ें) रोक देता है और कभी सूची के maxItems से ज़्यादा नहीं होता। नई पंक्ति कॉलम के अपने डिफ़ॉल्ट से, फिर defaults से शुरू होती है, जो हर कॉलम में फ़िट होने चाहिए।

चरण सूची को वहीं एडिट करता है जहाँ हर पंक्ति है, इसलिए एक ही नाम वाले दो retainers दो पंक्तियाँ रहते हैं, और एक हटाने पर दूसरा रहता है। कैटलॉग के चुनाव की लिखी पंक्तियाँ "Added by a pick" नोट के साथ सिर्फ़ पढ़ने के लिए दिखती हैं और चुनाव के साथ आती-जाती हैं। All fields पहले की तरह हर पंक्ति एडिट करता है।

पंक्तियों वाला चरण countFrom (Capability API 1.799) से बता सकता है कि उसे कितनी पंक्तियाँ चाहिए, जो शीट से पढ़ा गया मान है: 5e के हिट पॉइंट रोल, स्तर 1 के बाद हर स्तर पर एक। जब चरण दिखाया जाता है, तो बिल्डर पंक्तियाँ जोड़ता है, हर एक उसी तरह जैसे Add a row बनाता है, जब तक खिलाड़ी की अपनी पंक्तियाँ उतनी न हो जाएँ, कभी max या सूची के maxItems से आगे नहीं; यह कभी कोई पंक्ति हटाता नहीं, और वहाँ हटाई गई पंक्ति तब तक हटी रहती है जब तक चरण फिर न दिखाया जाए। जिस कैरेक्टर का विवरण दिया जा रहा है, चरण देखने से उसे पंक्तियाँ नहीं दी जातीं। फिर चरण उतनी पूरी पंक्तियों का इंतज़ार करता है, जैसे min के लिए करता है, दोनों दिए होने पर दोनों में से बड़ी संख्या का, और वही "N of M" गिनती दिखाता है। इसे इस्तेमाल करने वाले नियमसेट को Capability API 1.799 चाहिए।

{
  "id": "hit_point_rolls",
  "label": "Hit point rolls",
  "kind": "rows",
  "list": "hp_rolls",
  "required": ["die", "roll"],
  "countFrom": { "derived": "hp_rolls_due" }
}

शर्त वाले ऑफ़र, शीट से पढ़ी सीमाएँ और बनाने के नियम (Capability API 1.155)। spend ऑफ़र में ये भी हो सकते हैं:

बजट और ओवरराइड की तरह, ये भी खरीदा गया लक्ष्य नहीं पढ़ सकते। onDuplicate: "replace" वाला प्रशिक्षण विकल्प replacementFrom का नाम दे सकता है, यानी वे स्किल (या सेव) जिनसे दोहराव को बदला जा सकता है, शीट की हर स्किल की जगह; यह दिखाने, सेव करने और लागू करने, तीनों पर लागू होता है।

sheet.builder.constraints में बनाने के अधिकतम 40 नियम होते हैं। हर एक उस step का नाम देता है जिसका बैज इसे दिखाता है और वह label जो विफल रहने तक वहाँ दिखता है, वैकल्पिक when: Ref, और इनमें से ठीक एक:

{
  "constraints": [
    {
      "id": "disadvantage_cap",
      "label": "Disadvantages give at most 50 points.",
      "step": "traits",
      "rows": { "list": "traits", "filter": { "column": "cost", "below": 0 }, "sum": "cost" },
      "min": -50
    }
  ]
}

विफल नियम कभी Back, Next या All fields को नहीं रोकता।

निकाले गए स्कोर और एक रोल पर लागू असर (Capability API 1.156)। एबिलिटी value: Ref[] (1 से 8) रख सकती है: उसका स्कोर इनका जोड़ है, उसके min और max के अंदर रखा गया, और सिर्फ़ पढ़ने के लिए दिखता है। Blades का attribute उसके चिह्नित actions का जोड़ है; GURPS Perception [{ "abilityScore": "iq" }, { "field": "perception_bought" }] है, और इससे रोल होने वाली स्किल वही मानती हैं जो खरीदा गया। निकाले गए मान, सीमाएँ और स्किल निकाला गया स्कोर पढ़ सकती हैं, लेकिन कोई निकाला गया स्कोर दूसरा नहीं पढ़ सकता, निकाले गए मान के ज़रिए भी नहीं। बिल्डर इसे कभी सेट नहीं करता, और इसके लिए सेव कुछ भी अनदेखा होता है।

सूची contextual घोषित कर सकती है ताकि जब Game Master उसकी पंक्तियों का नाम दे तो वे किसी रोल पर लागू हों:

{
  "id": "stunts",
  "label": "Stunts",
  "maxItems": 10,
  "columns": [
    { "id": "name", "label": "Name", "type": "text", "maxLength": 80 },
    { "id": "skill", "label": "Skill", "type": "text", "maxLength": 40 },
    { "id": "bonus", "label": "Bonus", "type": "number", "min": -5, "max": 5, "default": 2 }
  ],
  "contextual": { "name": "name", "skill": "skill", "bonus": "bonus" }
}

name वह कॉलम है जिससे Game Master पंक्ति का नाम देता है। skill (वैकल्पिक) में वह स्किल होती है जिस पर पंक्ति लागू होती है, ID या लेबल से; खाली सेल किसी भी चेक पर लागू होता है। bonus (नंबर कॉलम) और dice (डाइस कॉलम) चेक में जुड़ते हैं, पूल नियमसेट पर डाइस के रूप में। to: "saves" पंक्तियों को इसके बजाय सेव पर लागू करता है। पूल नियमसेट पर check: { dice?, successes?, double?, explode? } हर लागू पंक्ति को पूल पर एक जैसा असर देता है, जैसे ऐसी विशेषज्ञता जिसके 10 विस्फोट करते हैं।

कैटलॉग एंट्री mechanics.contextual रख सकती है, जिसमें effects (own-checks-advantage और बाकी चेक और सेव वाले असर), checks या saves पर modifiers, सीमित करने वाले skills और saves, पूल वाला check असर, और cost: [{ "pool": "...", "amount": 1 }] हो सकते हैं, जो जिस रोल पर लागू होता है उस पर एक बार चुकाया जाता है। Game Master चेक पर apply="Strong Back; Quick Eye" (अधिकतम चार नाम) लिखता है। सिर्फ़ उस चेक पर लागू होने वाले नाम उसे बदलते हैं: किसी दूसरी स्किल की पंक्ति, दो पंक्तियों का साझा नाम, और ऐसी कीमत जिसे पूल चुका नहीं सकता, कुछ नहीं बदलते। पंक्ति का होना अपने आप कभी कोई रोल नहीं बदलता। रिकॉर्ड from में बताता है कि क्या लागू हुआ।

रोल किए गए और शीट से पढ़े शुरुआती सिक्के (Capability API 1.157)। शुरुआती सामान की सिक्का लाइन count की जगह roll ("2d6" जैसे डाइस) या countFrom (धारक की शीट से पढ़ा गया Ref) रख सकती है, दोनों कभी नहीं, और times (1 से 10000) दोनों में से किसी को गुणा करता है:

{ "coins": "gold", "roll": "5d4", "times": 10 }

पिकर डाइस दिखाता है ("5d4 gold, rolled when taken")। रोल एक बार होता है, जब समूह या धारक पैकेज लेता है, इसलिए पिकर फिर खोलने से वह दोबारा रोल नहीं हो सकता। countFrom धारक की अपनी शीट पढ़ता है, जैसे Credit Rating फ़ील्ड; बिना शीट वाला धारक अस्वीकार होता है, और 0 मात्रा कुछ नहीं जोड़ती। आइटम लाइनें अपना तय count रखती हैं।

एक बार सेट होने वाले शुरुआती मान (Capability API 1.158)। kind: "initialize" वाला बिल्डर चरण खिलाड़ी के पुष्टि करने पर शुरुआती मान लिखता है, और फिर कभी अपने आप नहीं:

{
  "id": "start",
  "label": "Starting values",
  "kind": "initialize",
  "writes": [
    { "field": "san_start", "value": { "abilityScore": "pow" } },
    { "field": "xp", "remaining": "creation" }
  ]
}

हर write एक शीट फ़ील्ड का नाम देता है और या तो value (तय मान, या नंबर फ़ील्ड के लिए Ref) या remaining, यानी बिल्डर पूल में जो बिना खर्च बचा है। चरण हर फ़ील्ड को अभी जैसा है और जिस पर सेट होगा, दोनों दिखाता है; उसका बैज खिलाड़ी के उन्हें सेट करने तक इंतज़ार करता है। लिखे गए मान बिल्डर के साथ सेव होते हैं, इसलिए उसे फिर खोलना, कैरेक्टर इंपोर्ट करना या बाद में POW बदलना उन्हें कभी दोबारा नहीं लिखता। जब शीट तब से बदल चुकी हो, तो चरण दिखाता है कि फिर सेट करने से क्या बदलेगा, और ऐसा सिर्फ़ खिलाड़ी का Set again (फिर सेट करें) करता है। जैसा है वैसा ब्योरा दिया जा रहा कैरेक्टर कभी लिखा नहीं जाता।

लाइव पूल पूरे या खाली के बजाय शीट से पढ़े मान पर शुरू होने के लिए startFrom: Ref घोषित कर सकता है, जो 0 और उसके अधिकतम के बीच रखा जाता है, और साधारण ट्रैक default की जगह startFrom घोषित कर सकता है। initialize चरण के लिखे फ़ील्ड की ओर इशारा करने पर, SAN उसी POW पर शुरू होता है जिससे उसे सेट किया गया और वहीं रहता है जहाँ खेल उसे छोड़ता है: सेव हुआ लाइव मान हमेशा पूल की शुरुआत पर भारी पड़ता है।

कीमत वाले चुनाव और पंक्तियाँ (Capability API 1.159)। कैटलॉग चरण या rows चरण किसी बिल्डर pool और cost का नाम दे सकता है, ताकि खिलाड़ी जो चुनता या लिखता है उसकी कीमत उसी पूल से चुकाई जाए जिससे spend चरण चुकाते हैं। कैटलॉग चरण की कीमत एक संख्या या { "filter": "tier" } है, यानी एंट्री का अपना नंबर फ़िल्टर। rows चरण की कीमत एक संख्या या { "column": "cost" } है, जो हर पंक्ति से पढ़ी जाती है; ऋणात्मक कीमत क्रेडिट है, पूल के creditLimit के अंदर, इसलिए कोई flaw गुणों (traits) का खर्च उठाता है। rows चरण from का नाम भी दे सकता है, यानी पंक्तियों वाला ऐसा कैटलॉग जो उसकी सूची भरता है: खिलाड़ी किसी एंट्री की पंक्ति की कॉपी जितनी बार चाहे जोड़ता है, और हर कॉपी उसकी अपनी पंक्ति है, जिसकी कीमत अलग लगती है और जो अलग हटती है:

{
  "id": "charms",
  "label": "Charms",
  "kind": "rows",
  "list": "charms",
  "pool": "bonus",
  "cost": { "column": "cost" },
  "from": "charm_book"
}

जिस चुनाव की कीमत पूल नहीं चुका सकता, वह नहीं दिया जाता। कीमत वाले चुनाव और पंक्तियाँ पहले चुकाए जाते हैं और खिलाड़ी के लिए कभी बेचे नहीं जाते: जब किसी flaw को हटाने से पूल ज़्यादा खर्च हो जाता है, तो spend चरणों की खरीद तब तक लागू होना बंद हो जाती है जब तक खिलाड़ी उसे ठीक न करे, और कीमत वाले हर चरण का बैज यह सुधार गिनता है। ऐसा कुल जिससे कोई कॉलम आगे नहीं जा सकता (Rite levels), rows.sum और max वाला बनाने का नियम (1.155) है।

बनाने की प्रोफ़ाइल और पहले के दौर (Capability API 1.160)। sheet.builder.profiles (अधिकतम 16) किसी कैरेक्टर प्रकार, करियर या पैकेज को अपने चरण और बजट लाने देता है:

"profiles": [
  { "id": "dragon", "label": "Dragon-Blooded", "when": { "field": "dragon" },
    "steps": ["aspect_gifts"], "budgets": { "bonus": { "const": 15 } } },
  { "id": "lunar", "label": "Lunar", "when": { "field": "lunar" },
    "steps": ["moon_gifts"], "budgets": { "bonus": { "const": 18 } } }
]

जिस पहली प्रोफ़ाइल का when 0 से ऊपर पढ़ा जाता है वह कैरेक्टर की है, और बिल्डर बताता है कौन सी। किसी भी प्रोफ़ाइल में सूचीबद्ध चरण सिर्फ़ तब दिखता है जब उसे सूचीबद्ध करने वाली प्रोफ़ाइल कैरेक्टर की हो; छिपे रहते उसके जवाब रखे जाते हैं और कुछ नहीं देते। प्रोफ़ाइल के budgets उन पूल के अपने बजट की जगह लेते हैं, इसलिए प्रकार बदलने पर दूसरे प्रकार का बजट कभी नहीं रहता: जिन खरीद को वह अब नहीं ढकता, वे तब तक लागू नहीं होतीं जब तक खिलाड़ी उन्हें ठीक न करे।

कैटलॉग चरण या initialize चरण reads: { "before": "step_id" } घोषित कर सकता है। तब उसकी एंट्री का offeredWhen और उसका upTo (या initialize चरण के मान) शीट को वैसे पढ़ते हैं जैसा उस चरण से पहले के चरण उसे बनाते हैं: बाद के चरणों ने जो कुछ चुना, दिया या खरीदा वह वापस लिया जाता है, और खिलाड़ी का टाइप किया रखा जाता है। multiclass चरण इस स्तर के improvement से पहले के एबिलिटी स्कोर पढ़ता है; Humanity का स्नैपशॉट freebies से पहले के Virtues पढ़ता है, खिलाड़ी चरणों के बीच कितना भी आगे-पीछे गया हो।

ऐसी पंक्तियाँ जो खुद चेक हैं (Capability API 1.161)। सूची अधिकतम चार checks घोषित कर सकती है, ताकि खिलाड़ी की लिखी हर पंक्ति ऐसा चेक हो जिसे Game Master उसके नाम से माँग सके:

"checks": [{ "id": "science", "name": "name", "rating": "rating", "ability": "edu" }]

name वह टेक्स्ट कॉलम है जिससे पंक्ति को बुलाया जाता है और rating वह नंबर कॉलम जो उसकी रेटिंग है; ability (वैकल्पिक) उसी तरह जुड़ता है जैसे स्किल की एबिलिटी। Science (Physics) और Science (Biology) दो पंक्तियाँ और दो चेक हैं, हर एक की अपनी रेटिंग। एक सूची पर दो चेक एक रेटिंग वाले दो रुख हैं, हर एक के साथ एक label जो Game Master पंक्ति के नाम के बाद कहता है: "Fire stew (bold)" और "Fire stew (careful)"। शीट की अपनी स्किल, सेव और एबिलिटी पहले मिलाई जाती हैं। दो पंक्तियों का साझा नाम तब तक कोई चेक नहीं है जब तक एक का नाम न बदला जाए, और हटाई गई पंक्ति का चेक उसके साथ चला जाता है। Game Master का शीट ब्लॉक हर पंक्ति चेक को उसकी संख्या के साथ सूचीबद्ध करता है, और with= स्किल की तरह काम करता है। रेटिंग कॉलम से कीमत वाला rows चरण (1.159) रेटिंग बनाने के पूल से खरीदता है।

अपने डाइस के साथ रखे गए बनाने के रोल (Capability API 1.162)। बनाने के डाइस { "count", "sides", "keep"?, "add"?, "multiplier"? } हैं: सबसे ऊँचे keep फलक, और add, गुणा multiplier, इसलिए CoC का (2d6+6) x 5 { "count": 2, "sides": 6, "add": 6, "multiplier": 5 } है।

abilities चरण का methods.rolls हर स्कोर को क्रम से रोल करता है, हर एक अपने समूह के डाइस से, और किसी रोल को कभी दूसरे स्कोर पर जाने नहीं देता (तरीका "rolls"):

"rolls": [
  { "abilities": ["str", "con", "dex", "app", "pow"], "dice": { "count": 3, "sides": 6, "multiplier": 5 } },
  { "abilities": ["siz", "int", "edu"], "dice": { "count": 2, "sides": 6, "add": 6, "multiplier": 5 } }
]

kind: "roll" वाला चरण अधिकतम 12 rolls सूचीबद्ध करता है, हर एक किसी नंबर field में लिखा जाता है: Luck, हिट पॉइंट, शुरुआती पैसा। best (2 या 3) उतनी बार रोल करता है और सबसे अच्छा रखता है; floor (संख्या या Ref) नतीजे का न्यूनतम है, जैसे 1 हिट पॉइंट या ऐसा potential जो कभी अपने stat से नीचे न हो; gain इसे इसके बजाय improvement चेक बनाता है, जो फ़ील्ड के विरुद्ध रोल होता है और सिर्फ़ रोल उससे ऊपर होने पर gain जोड़ता है, जैसे CoC का EDU improvement करता है। हर रोल अपने फलकों के साथ रखा और दिखाया जाता है। पहले से हुआ रोल बना रहता है; बिल्डर फिर खोलने पर कभी दोबारा रोल नहीं होता, और सिर्फ़ retry: true वाला चरण ऐसा करने का विकल्प देता है। ब्योरा दिए जा रहे कैरेक्टर के लिए कभी रोल नहीं होता।

गिने गए चुनाव और बनाने की पाबंदियाँ (Capability API 1.151)। हर चरण when: Ref (उसे सिर्फ़ तब दिखाएँ और लागू करें जब गैर-लाइव शीट मान शून्य से ऊपर हो) और requiredWhen: Ref (अधूरे चुनाव उसके बैज में सिर्फ़ तब गिनें जब यह शून्य से ऊपर हो) रख सकता है। छिपे चरण अपने सेव जवाब रखते हैं। अधूरे या अमान्य चुनाव होने पर भी Next और Back उपलब्ध रहते हैं; All fields खुला एडिट बना रहता है।

कैटलॉग चरण अधिकतम 12 quotas घोषित कर सकते हैं, हर एक कैटलॉग के किसी टाइप वाले फ़िल्टर का इस्तेमाल करते हुए:

{
  "id": "ratings",
  "label": "Skill ratings",
  "kind": "catalog",
  "catalog": "ratings",
  "min": 10,
  "max": 10,
  "distinctBy": "skill",
  "quotas": [
    { "filter": "rating", "value": 4, "min": 1, "max": 1 },
    { "filter": "rating", "value": 3, "min": 2, "max": 2 },
    { "filter": "rating", "value": 2, "min": 3, "max": 3 },
    { "filter": "rating", "value": 1, "min": 4, "max": 4 }
  ]
}

जब कैटलॉग हर स्किल को हर रेटिंग पर देता है, तो यह Fate जैसा पिरामिड है। एंट्री अपनी प्रशिक्षण देन साफ़ प्रशिक्षण स्तर ID के साथ घोषित करती हैं; संख्या वाले फ़िल्टर मान कभी स्तर का मैप नहीं गढ़ते। कोटा में 0 <= min <= max <= चरण का अधिकतम होता है। न्यूनतम बैज पर असर डालते हैं; अधिकतम आगे के मेल खाते चुनाव बंद कर देते हैं। distinctBy किसी मौजूदा फ़िल्टर का नाम देता है: चुनाव उसका मान साझा नहीं कर सकते (या tags फ़िल्टर के लिए कोई टैग), और जिस एंट्री में वह फ़िल्टर नहीं, वह गिनी नहीं जा सकती। वरना अलगाव एंट्री ID से होता है। quotaBelow: { "filter": "tier" } 1 से ऊपर के धनात्मक पूर्णांक tiers के लिए tier n−1 पर tier n से ज़्यादा (बराबर नहीं) सक्रिय चुनाव माँगता है। Tier 1 बेस है। सहारा देने वाला चुनाव हटाने पर ऊँचे अतिरिक्त चुनाव निष्क्रिय हो जाते हैं, उनकी देन वापस ली जाती है जबकि उनके जवाब ठीक करने के लिए रखे जाते हैं।

abilities.choose, trained.choose, trained चरण का choose, और entries.choose स्लॉट ये लेते हैं:

एबिलिटी के विकल्प इसके अलावा from लेते हैं, जिसे शीट की एबिलिटी और except से काटा जाता है। PF2e के अलग-अलग boosts के लिए, restricted विकल्प ["str", "dex"] दे सकता है, उसके बाद background/restricted को बाहर रखने वाला free_boost विकल्प। एंट्री के विकल्प कैटलॉग चरणों जैसे ही quotas, distinctBy और quotaBelow लेते हैं, max या count के अंदर; वे अब भी चुनी गई एंट्री की अपनी देन लागू किए बिना पंक्तियाँ लिखते हैं।

प्रशिक्षण के विकल्प इसके अलावा tier (बिना प्रशिक्षण वाले स्तर से ऊपर का दिया गया स्तर, जो देन या बिल्डर के स्तर पर भारी पड़ता है), only: "any" | "trained" | "untrained" और onDuplicate: "replace" लेते हैं। योग्यता हाथ से किया प्रशिक्षण और पहले की सक्रिय देन पढ़ती है, बिल्डर के अपने पिछले लिखे को छोड़कर। उन स्रोतों से पहले से प्रशिक्षित चुनी गई स्किल उसी तरह की बिना प्रशिक्षण वाली स्किल में से अलग बदलाव स्लॉट खोलती है, मूल जवाब रखते हुए। बदलाव विकल्प के बहिष्करण और स्तर मानते हैं। उनकी सेव कुंजी मूल स्लॉट की कुंजी और /replacement है। Human के non-career ranks किसी पहले के करियर विकल्प को बाहर रख सकते हैं और only: "untrained" इस्तेमाल कर सकते हैं; करियर बदलने पर बाद के अमान्य जवाब बने रहते हैं।

शर्तें और नए स्लॉट की गिनतियाँ सिर्फ़ पहले के चरणों से बदले गए मान पढ़ सकती हैं, जिससे खुद को चालू करने वाली या चक्र वाली देन नहीं बनती। स्लॉट की गिनती शीट के मान तब नहीं पढ़ सकती जब बाद की कोई बाहरी कैटलॉग फ़ाइल उन्हें बदल सकती हो; उसके स्रोत चरण को पहले ले जाएँ या उस कैटलॉग को इनलाइन रखें। शर्त निकाले गए मान वाला मौजूदा enumTable इस्तेमाल करके सबरेस चरण को सिर्फ़ एक ancestry के लिए ज़रूरी बना सकती है। requiredWhen सिर्फ़ बैज पर असर डालता है और कोई भी मान्य गैर-लाइव मान पढ़ सकता है। योग्य सामग्री न होने पर नए सीमित विकल्प अनसुलझे रहते हैं, "not configured" व्याख्या के साथ। वे कभी चुपचाप अपनी ज़रूरी गिनती उपलब्ध सामग्री तक नहीं घटाते। हाथ से किए शीट एडिट और ब्योरे से बने कैरेक्टर बिल्डर के मौजूदा मालिकाना नियम मानते हैं।

बिल्डर के बिना बना कैरेक्टर (ऐसी शीट जो खाली नहीं है और जिसमें अभी कोई बिल्डर चुनाव नहीं) described (ब्योरे वाले) रूप में खुलता है: चुनाव वह दर्ज करते हैं जो कैरेक्टर पहले से है (उसकी रेस की बढ़ोतरियाँ उसके स्कोर में पहले से शामिल मानी जाती हैं) और शीट पर कुछ नहीं बदलते, जब तक खिलाड़ी Done: let picks change the sheet (हो गया: चुनावों को शीट बदलने दें) न चुने। तब से, कोई चुनाव बदलने पर ब्योरे वाले चुनाव का दिया वापस लिया जाता है।

tier के बिना, प्रशिक्षण शीट के दिए बिना प्रशिक्षण वाले स्तर से ऊपर के पहले स्तर तक जाता है; आधा स्तर देने वाली शीट (जैसे 5e की स्किल) "tier": "proficient" सेट करती है।