tabatkins

D&D 5e Weapon Construction Rules

Way back in D&D 3rd edition, I noticed that the weapons table seemed very regular. There were certain patterns that were maintained almost completely across the board. I documented these and wrote them up (still on my very very old pbwiki), to help other people create new balanced weapons.

(Later, one of the 3e designers, Sean K Reynolds, confirmed for me that, while they hadn't quite formalized the rules in the form that I was presenting, my rules were accurate.)

Later, when 5th edition came out, I looked over the weapons again and attempted to extract a similar set of rules. They were a bit more complex, surprisingly, and not quite as regular - 5e seems to have embraced sometimes giving less-effective options for flavor or lower cost (look at the armor table, for instance, phew).

But if you look at the reasonably optimal weapons, the following rules will construct weapon

tabatkins

XML-in-KDL (XiK)

This specification describes a canonical way to losslessly encode XML in KDL. While this isn't a very useful thing to want to do on its own, it's occasionally useful when using a KDL toolchain while speaking with an XML-consuming or -emitting service.

This is version 1.0.0 of XiK.

XML-in-KDL (XiK from now on) is a kdl microsyntax for losslessly encoding XML into a KDL document. XML and KDL, luckily, have very similar data models (KDL is almost a superset of XML), so it's quite straightforward to encode most XML documents into KDL.

XML has four types of nodes, corresponding to certain KDL constructs:

tabatkins

JSON-in-KDL

This specification describes a canonical way to losslessly encode JSON in KDL. While this isn't a very useful thing to want to do on its own, it's occasionally useful when using a KDL toolchain while speaking with a JSON-consuming or -emitting service.

JSON-in-KDL (JiK from now on) is a kdl microsyntax consisting of three types of nodes:

• literal nodes, with _ as the nodename
• array nodes, with array as the nodename
• dict nodes, with dict as the nodename

tabatkins

function construct(getNextStates) {
	return function ai(currentState) {
		const pieces = [
			{name:"S", annoyance:7},
			{name:"Z", annoyance:6},
			{name:"O", annoyance:5},
			{name:"I", annoyance:4},
			{name:"L", annoyance:3},
			{name:"J", annoyance:2},
			{name:"T", annoyance:1},

tabatkins

Real world use-case: someone asking for Object.values()/etc to be installed as Symbol-keyed properties on Object.prototype, so they can have method chains working on arrays/iterators that produce an Object at some intermediate point, without having to go back and wrap an entire chunk of the method chain in a big wrapping Object.values().

That is, they're prefer not to have to write this code:

const x = Object.values(array.filter(x=>x).map(x=>f(x)).reduce(intoObjectSomehow)).map(y=>g(y))

tabatkins

There's a reason people don't like to write HTML tables, 
and it's because they don't write good HTML in the first place.

Case in point, taken from a spec I'm editting right this moment:

```html
    <table id="distinguishable-table" class="matrix data complex">
        <tr>
            <th class="corner"></th>
                <th><div>

tabatkins

We've been deadlocked for a while on the pipeline operator proposal, for a few reasons. Partially it's just low implementor interest, as this is fundamentally just syntactic sugar, but also because there are three competing proposals and the proponents of each haven't been convinced by the others yet.

In this essay I hope to briefly outline the problem space, summarize the three proposals, and talk about what's gained/lost by each of them. (Spoiler: they're all nearly identical; we're arguing over very small potatoes.)

tabatkins

• Python's pattern-matching PEP 634
• Tutorial PEP 636
• Design doc PEP 635

(Note that PEP 642 was rejected, but its points are intriguing; I discuss it at the end of this document.)

Basic patterns are identical to my proposal, modulo obvious differences in Python spelling vs JS spelling:

• Identical "leaf" matchers (ident-matcher, nil-matcher, literal-matchers)
• identical array-matcher,

tabatkins

Masterwork Properties

Masterwork properties can be applied to any masterwork weapon or suit of armor, provided you can spare the time and gold cost required to apply it. Each property entry details the property’s level and the type of equipment it can be applied to.

Unless otherwise noted, a piece of gear cannot have the same property more than once; for example, you cannot

tabatkins

JS Pattern-Matching Construct

Building on the previous work by Kat Marchán.

Comparison with Python's newly-accepted pattern-match syntax.

Core Syntax