n0q / hackmaster5e-fvtt Goto Github PK

we no has, yet.

Dice so Nice 3.4.0 occasionally breaks, throwing up an error when penetrating on a die roll.

Steps to reproduce

1. /roll 1d4p until the die finally penetrates.
2. Wait for dice to finish dropping.

Sometimes (but not every time) the following error will come up:

DiceBox.js:524 Uncaught TypeError: Cannot read property '0' of undefined
    at DiceBox.swapDiceFace (DiceBox.js:524)
    at DiceBox.rollDice (DiceBox.js:999)
    at DiceBox.start_throw (DiceBox.js:904)
    at main.js:860
    at main.js:722

Not yet sure if this is a DSN bug or a hackmaster dice code bug. Keeping this issue open as a reminder.

System should display and allow modification of attack/speed/defense/damage stats for weapons. Buttons to attack, defend, and (std) damage. Doesn't have to be pretty or full featured. Just has to work.

dsn is keying die types off of termData.faces. Our dice code doesn't honor this, so while dsn is being fed correct die results, it is rolling them on larger dice than it should.

This is a purely cosmetic issue, but will confuse people until it is addressed.

combat macros would allow someone (usually a gm) to attack without ever opening a sheet. one dialogs are done, these should come next to capitalize on the added ui.

• Attack
• Defense
• Damage

We need a way to rapidly damage an actor without drilling down to their character sheet.

Clicking on 'roll initiative' should ask the user to choose from a list of dice, ranging from d20 to d3, and then roll that die along with its init mod sum (a derived stat). If a GM chooses to roll for all npcs, this same choice should apply to all npcs prior to rolling.

post 0.1.x, we're on the hook for anyone foolhearty brave enough to use this system, so migration code will be required at this point.

Presently, a character class can gracefully handle being told it's a "reroll hitdie", but only if the prior one was a new hitdie. I don't think any character classes throw consecutive rerolls at the player, but we should handle this anyway, for homebrew or new character classes.

toggles are not cooperating with editable listeners. they fire off because the editables are set to function on change, rather than on click.

as this system is in flux, it would be wise for system macros to come with a built-in expiration system. they should check their revision number against the system's and refuse (with an error message) if they're stale and need a refresh. Extending the Macro object should be the easiest way to accomplish this.

Unsurprisingly, init sorts everyone from highest to lowest, and the arrows cycle through people before changing rounds. Ideally, we'd sort from lowest to highest and arrows instantly increase the round total.

This would be nice to have for 0.1.x but it can wait until 0.2.x.

Dragging a skill to the macro bar should result in a skill macro.

right now, wounds are fairly dumb. select either the hp or duration box, and they go down. It would be a lot more reasonable if setting duration to 0 caused duration = --hp.

Needed for manipulating chat output. Used for cards. Also we can do a lot of QoL tricks with this later, such as chained dialogs (Attack -> Defense -> Damage -> Resolve).

because a full blown character sheet is a bit much for a wolf.

We'll need a place to store, roll, and present the various mods and stats which go into a character. Feats of (Str|Dex), saves, init/attack/defense/whatever mods, and so on. Presentation would be to the abilities pane of the character sheet, as these are things the player probably always wants available. Storage would be on the setup panel (#28).

universal skills are not localized yet.

For now, these simply need to serve as a record of hp, since we'll build a character's maximum hp off of a combination of constitution, racial hp mod, misc hp mod, and hit dice.

object should track class name, hp roll, hit die, and if it was a reroll.

I've added a setup panel to track character levels, but it will be necessary to track more than that. Miscellaneous bonuses will need to be stored here until there's a better place for them. Having some way to indirectly modify sheet attributes is a must from day one.

these will need to wait until there are modifiers to roll against. note that top saves will require special treatment. top save data may need to be moved away from the other saves in the actor data structure to facilitate this.

tabbing between inputs is presently a terrible experience on roll cards due to how I've set things up row-to-column rather than column-to-row. This shouldn't be difficult to fix.

for now, race should determine starting hp, movement speeds, size, and knockback. No stat bonuses yet. This needs to be integrated into the character sheet, and care should be taken that an actor is allowed only one of these.

As per #44, the code in modules/actor/actor.js is absolute horseshit and the person who wrote it should be ashamed of himself. Also I'm the person who wrote it. It's all in an effort to get a basic build out the door, but this NEEDS to be refactored. It's so horrible that it needs its own issue as a reminder.

This is not okay.

ui toggles are presently working via item entity flag. This makes it persistent (nice, but overkill) but also user independent (which is annoying). It's preferable to just toggle display: none on and off, instead.

Skill checks should provide both standard and opposed results at the same time (that is, adding and subtracting the character's skill). Presently, they're only doing one kind.

This will require setting up our first roll card, which ordinarily wouldn't be part of an mvp build.

Hackmaster's die mechanic is penetration dice. If a penetration die (denoted with a p, as in 1d6p) rolls max, you get to roll it again with a (non-stacking) -1 modifier until you fail to roll max. 1d100p's degrade to 1d20p. 1d20p degrades to 1d6p.

Some initial groundwork for this already exists, but that code is mostly placeholder and does not actually do the job it was hired for.

the current penetration die implementation is tainted because it uses code from foundry.js. This will need a do-over, unfortunately. In the process, I should take care to consider the issues raised by #75

pressing the attack, damage, and defend buttons should open a dialog to poll the player for further information.

• Attack
• Damage
• Defense

Fancier stuff (and jab support) can come in later releases, but these items are essential.

• attacks should offer a universal mod value.
• damage should offer a universal mod value and the option to do standard or shield damage.
• defense should offer a universal mod value.

point out crits, perfect defenses, and near perfect attacks. Some classes have a wider range for near perfects and this should be observed.

universal skills should display and roll default scores if mastery value is 0, null, or NaN.

the listeners need an overhaul to begin with, really

beast actors will require different handling than characters. for now, the main thing is to get hp from a formula, rather than stats.

goes side-by-side with the attack pane. Displays information on armor and shields. In the future, this will be used to track armor ablation. For now, it just needs to display what an actor has.

combat cards should chain, so an attack provides a clickable for the defender, which potentially provides a clickable for the attacker, and so on.

I'm going to need roll dialogs for a couple other sheet elements.

• Abilities
• Skills

In order to process rolls properly, we will need a dice roller to take in formulas and hints, and then spit out a roll card with intelligent (?) information. For now, it only has to receive die terms, roll the dice, and present the results on a card.

The inventory system should list every item, its type, if it's equipped or carried, and its weight. It will need controls to change equip and carry status.

Current combat tracker is simply PoC. It's not truly usable in its present state. Init shifts should be a lot more painless (and a lot less accident prone!) than they presently are. The UI could use some work, as well. Aim for the combat tracker to be ready for use.

proficiency items should contain skill level (minimal/low/medium/high), atk, def, spd, dam mods, and a 'ranged' bool. The idea is to allow a player to set/maintain this information in one place, and then designate a weapon as a consumer of this proficiency.

Likely has something to do with the Roll shim I've got in place.

When wanting to reset the initiative in the combat tracker, you can put a value in, but then it goes to standard initiative die roll request.

a fast way to change init during combat, especially since the system isn't automatically altering inits yet.

very basic. display a spell's name, speed, and sp cost upon casting. Tracking spellpoints and memorization can be manual for now.

The display metaphor I've chosen will require an "Innate" armor which is equipped at all times. Innate armor will initially provide the following:

• Bonuses/Penalties due to Abilities
• Innate Defense
• Miscellaneous

Going forward, innate armor is where other bonuses will be stored:

• Innate DR
• Temporary penalties due to fumbles/crits.

weapon proficiencies are specified by string. This is highly accident prone. If a user makes a mistake here, actors will not be proficient. It's also a bit ambiguous what to type. We really should create a select dropdown based on available proficiencies. This will require handlebar helpers we haven't written yet.

visual indication of reach and threat ranges, to be toggled for players and the gm.

For now, just displaying all wounds and allowing users to directly manipulate treatment status, wound extent, and days to heal is sufficient. System needs to interpret wound items to calculate current hp level.

the level system makes a lot more sense in a game which supports multiclassing. This mechanism needs to be revisited and completely redesigned before it's usable.

if an actor receives a wound item of hp.value > their top threshold, the system should take action based on if the player or the gm owns the actor.

1. Alert table publicly if actor is player owned, but privately if GM-owned.
2. Open ToP dialog on owner's client.
3. Calculate duration of incapacitation.
4. Present trauma result publicly if player-owed, but privately if GM-owned.