You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Somewhat sorted list of apprentice weapon properties
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
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.)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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:
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:
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