derikb / rpg-table-randomizer Goto Github PK

Calling toJSON outside the context of a JSON.stringify doesn't recursive call toJSON on all the properties, so trying to create serializable objects from the NPC class fails if there are results or result sets in the field values.

defaultToJSON probably needs to check for "toJSON" method on any objects and call it if it's there.

I should be able to set up multiple entry points, so having one that is just the dice roller might be nice for my character sheet app (I want to add a dice roller there, but I don't need all the other randomization stuff at this point.

Add French style names

So it can be more easily detected/indentified.

Happened when I used generateList() with no arguments, first names were "Peta" (female) and "Istu" (male) which are from the native american list (which is the list with no lastnames).

Should be able to use standard-release scripts to run buildTest and compileTypes and commit any changed files before the release is packaged and tagged.

Some easy way to format in Markdown and end up with a RandomTable config object.

If the passed in displayOptions isn't a Map the data is just ignored.

Forgot it.

Also I think NPCSchema needs to import isEmpty. Also it could take a toJSON method too.

That would enable an easier way to format the data in different ways. And have the data be structured rather than just a string.

I'm trying to figure out how I would simulate having a bonus when rolling on a table? For example, when rolling on table A, add +1 bonus if your character is an Elf.

A way to have a top level table that uses a bunch of different other tables to generate some larger result.

For example, a mission generator that draws on tables for actions, antagonists, patrons, rewards, etc. This is possible with the current code by just having 1 result in a table that is just a token for another table, but that seems cheap and possibly confusing.

For example:

"sequence": "rollall",
"tables": {
    "action": [
        { "label": "{{table:mission_action}}" }
    ],
    "patron": [
        { "label": "{{table:mission_patron}}" }
    ],
    "antagonist": [
        { "label": "{{table:mission_antagonist}}" }
    ],
    "complication": [
        { "label": "{{table:mission_complication}}" }
    ],
    "reward": [
        { "label": "{{table:mission_reward}}" }
    ]
}

The idea being you can create a schema for fields and calculations and then use that to generate an NPC using the randomized, tables, names, rolls, etc.

Was going to do this as a separate module but it made more sense in the end to work it in here.

Way to see what table dependencies there are for a specific RandomTable or NPC Schema. This would be helpful for causes where not all tables are currently available or need to be selected/added from a centralized source.

Some kind of dice notation to represent situations like this:

• Roll x take highest.
• Roll x take lowest.
• Roll x drop lowest.
• Roll x drop lowest.

When using the library in another codebase, the relative reference to uuid fails because uuid gets installed in the other code bases node_modules directory which is no longer in the same relative position.

Bleah... this means either you have to:

• use a "bare" import and force people to use a bundler or...
• load it from a cdn, import { v4 as uuidv4 } from 'https://jspm.dev/uuid'; or...
• ??

serializeValue in r_helpers handles Map objects but not Set objects.

NPC._convertFieldValue falls back from a few simple types to checking className property, but fails to first confirm a) that the value is an object b) that is has the className property.

I think the issue came up in some code when NPCSchemaField.defaultEmpty returned null, which doesn't fit any of the branches in _convertFieldValue.

probably just make it the table key?

Should be able to unit test a lot of this now that it's all in modules.

So you can give it a label that isn't the field key.

via table:subtable syntax.

Somehow I missed that Randomizer.registerTokenType is coded as registerTokenType = function (name, process) { which is broken syntax in that context... Not quite sure how that got through.

To reduce the size of JSON encoded data, we can skip bundling properties that are set to the default, in particular empty arrays and blank strings.

in re #36 have an option where the (sub)table is an ordered table, such that each entry represents a numeric value(s). The table could then be "rolled on" via a dice token or could just be selected from with an integer.

Offering code to convert from formats used by various services/sites would be helpful. Each one could be filed as it's own issue.

Such as:

• Chartopia
• ???

(Looking for ideas/examples.)

It would be helpful if the NPC creation process could return classes that extend the base NPC class, so you can add extra properties, methods, etc. but still be able to make use the of the code in initializeNewNPC that sets all the random fields.

If you set up your tokens in a certain way you could end up recursively calling the same table(s) until you ran out of memory.

Need to figure out a way to somehow track token/subtable rolls so they either stop at a certain number or they make sure they aren't recursively calling the same table/subtable that was called higher up in the stack.

In the nameTokenCallback the random is getting reset to an empty string and then in createName that is not being handled. The arg defaults to "random" but that only works if the value is undefined.

Probably nameTokenCallback you set the unset/empty/etc fields to "random".
Though maybe createName should handle empty values too.

Otherwise it does... something not quite right.

Other than the array type and getting multiple results from the source, the type property is mostly ignored. Should be using that in various places to I think to help with typing the field values, and serialize/unserialize.

The randomizer code would be a lot smoother if in the RandomTable itself we normalized all the entries. Right now they can be strings, arrays, objects. Should generate a simple class that has all the properties. That should make the randomizer's select methods a lot less reliant on checking types.

Rather than a plain Object. That will help maintain the order in the original? It would also make serialization simpler.

In general, I think, avoiding plain Objects as properties is a good idea.

The names are largest part of the browser build, so offering them as an optional add-on may be preferable to cut down the size.

Turns out that causes some issues if you try to export the functions inside separately. Things errorred out with

import { initializeNewNPC } from 'npc.js'

when the default was there.

Right now calling Randomizer.setTableKeyLookup directly replaces Randomizer.getTableByKey, which means when calling that method elsewhere you don't really know what you'll get in return.

Change this so the former method sets a separate method (marked as internal) and then the latter method calls that separate method and checks typing before returning anything. This way we can be sure getTableByKey's return is always RandomTable|null.

In case you want to have multiple name generators in one project. With the current method you can only set the nameddata once.

They are a little... off with the others. They can be rewritten as normal RandomTables in the sample data.

In my VSCode setup at least, the typings I added are not being found when I install the package in another app... There must be some setting or config off causing them to not get found.

... and maybe change it to "output options"? displayoptions?

We should test the browserified version of the code.

Need to figure out how to do that with Mocha (if we can).

It was only in there for adding table tokens to names, which is unnecessary and adds complication. You can also do that in a random table outside of the basic name generation (see the holmes name sample data).

As used in Randomizer, they tend to be:

• table {String} perhaps with special method for "isDefault" where name === default
• result {String}
• desc {String} Extra... text...

Would simplify some kind I think to be able to have a class for this. Maybe a class for a collection of them, since tables can return an array of results. That would aid in formatting table result output a lot I think.

Some first names had spaces in them which broke the regexes in the tests.

If you have a result set there is no direct way to reference the specific table it came from.

Have a lot of already formatted tables from my first attempt at this. Add them to a directory and offer a way to load/use them.

So like... first name from one type, last name from another. maybe with the token "mixed"

Even though the code isn't written in typescript having the declarations would help for including the module in a typescript project (like the Angular one I am working on).

Throw away the browserify/babelify stuff and just have modules.