Two-Weapon Fighting Multiplication

[IMarvinTPA]

I'm making sure I understand the framework correctly.
Without knowing how the character will use a weapon, if it is a 2-hand weapon, it will have one solitary entry in the weapons list. However, if it is a 1 handed melee weapon, to cover your bases (in automatic generation), you'd need 5 entries:
Primary+alone+1h
Primary+heavy
Primary+light
Secondary+heavy
Secondary+light
Secondary+heavy/light

Melee weapons that can be thrown (Dagger, spear, etc) get an extra option of Primary+alone+ranged.
If the melee weapon is a 1-handed weapon (not light), you can hold it two handed: Primary+alone+2h
A short spear has all of these for 76 entries.

Edit: The weapon, when used in a Secondary slot will know if the secondary IS heavy or light, so that cuts it down by one.

Thanks,
IMarv

[lmarkus001]

Yeah bit of a nightmare for automated population.

In practice, a weapon is usually dedicated to primary or secondary. So two entries if Primary (single weapon, two-weapon + usual off-hand combo weight). Those two entries cover 99% of the TWF users. Only when a character gets higher level and has a variety of weapon combos does this tend to break down.

[neofax]

Wouldn't it be easier to change the weapons so the 2h, 1h, oh, light and such be changed during the attack? This way you would not need to code multiples? You could just have a JSON that can be read and dictates what properties could be set by the player? i.e. light weapon could not be 2h so this would not show on the input dialog

[IMarvinTPA]

Wouldn't it be easier to change the weapons so the 2h, 1h, oh, light and such be changed during the attack? This way you would not need to code multiples? You could just have a JSON that can be read and dictates what properties could be set by the player? i.e. light weapon could not be 2h so this would not show on the input dialog

It would take a redo of the weapon system in the framework for that. I think the attack macro came after the weapons macro and built off of that.

I've hijacked the "Attack" button to make a button that makes buttons and records the settings of the dialog. That way I can give my players a few buttons on their token to hit for the usual cases and they could still resort to the attack button for the odd case.

IMarv

[Azhrei]

Yeah, it would take a rewrite of the existing system.

I know Lindsay has talked about this before and I've commented on it as well, but completely automating weapons and attacks is a huge job.

Ideally we'd have a table of weapons that says how each weapon can be used.

Then we'd have a table of which weapons a particular token is carrying and which they are proficient with (both groups as well as specific weapons).

Last, the attack routine would match them up.

It sounds simple like that, but the various interoperating pieces get very complicated. And this is something that would be much easier/stronger/faster in a real language like JavaScript (sigh).

[aliasmask]

Wouldn't it be easier to change the weapons so the 2h, 1h, oh, light and such be changed during the attack? This way you would not need to code multiples? You could just have a JSON that can be read and dictates what properties could be set by the player? i.e. light weapon could not be 2h so this would not show on the input dialog

Could just add another option too, "1h or 2h" just so you don't have to mess too much with the code. But yeah, I agree. Some of the settings should probably be on the attack macro. I just started playing in a campaign, so I'll probably be a little more active with some community modding ideas.

I play a monk and there are a lot funky things they can do. My fav is improved trip, full attack. So, if my trip succeeds, then the attacks are against an opponent with -4 AC, if not, then I don't count the first attack in the full attack series. I would like to be able to include the special attacks with the attacks macro. I had an interesting idea for a new interface for attacking, but it's a considerable rewrite.

[lmarkus001]

Yeah, I REALLY want to totally rework weapons and combat. Remember that when I coded that bit was when we FIRST got a looping construct in MapTools, so it is severely archaic

[neofax]

Believe me I know! Trying to work thru how it all works in my head did not work. I had to use a flowchart to figure it out and still got Manyshot wrong. The reason I wish it was JSON is to actually have the ability to code Feats so that they can be added like Active-Mods.

[IMarvinTPA]

I'm trying to set up macro buttons on characters so the players can just say "I smack them" and they click the button and out comes the values. So, I see the "Attack" button as a button generator screen, and the actual buttons as a stored "do it" stage. Sadly, the last bits at the bottom don't perfectly map out for monk's flurry of blows and their BAB value.

I need to create a JSON structure for my website's character stat management. All variable names live at a common level and have a contributors list of expressions and conditions. If the condition is met, it's value is added (with some stacking rules.) There are several bonus "Types" that stack that aren't documented as such.

Code: Select all

function BonusTypeStacks($type) {
	switch (ucase($type)) {
		case 'UNNAMED':
		case 'BASE':
		case 'CIRCUMSTANCE':
		case 'DODGE':
		case 'RACIAL':
		case 'ABILITY':
		case '':
			return true;
		default:
			return false;
	}
}

I think Ability may be a construct I made up to lump Str_Mod, Dex_Mod, Con_Mod, Int_Mod, Wis_Mod, Cha_Mod to make them easy to remove.

Here is the internal representation of Fisreth:
http://prpg.imarvintpa.com/RawCharacter.php?ID=8

IMarv

[Azhrei]

That sounds like a good start for the stacking, but the list is wrong. Racial bonuses don't stack (so a creature with an amulet of natural armor +1 doesn't stack with +4 to natural armor from a spell like Form of the Dragon, for example).

The only things that stack are: all penalties, all untyped bonuses, all Dodge bonuses, and (some) circumstance bonuses (based on GM fiat).

Assume that you've got a series of modifiers in the format of:

Code: Select all

modifier = { amount: -2, expires: 5 } 

That would indicate the the amount and when it expires (round 5 in this case). You could have a couple dozen of these in a JSON object:

Code: Select all

object = {
  'DexMod': [ modifier1, modifier2, modifier3 ],
  'Dodge': [ modifier4, modifier5 ],
  ...
} 

Now a single function would read through the object and add them up. Each property in the object would have an array as a value. And each array is sorted in numeric order, from smallest to largest, so negative numbers (penalties) are in the front.

General algorithm:

Code: Select all

For each property name {
  totalModifier = 0
  If property name is a type that always stacks {
    totalModifier += all array elements
  } else {
    While array elements are less than 0 {
      Add element to totalModifier
    }
    Add last element to totalModifier
  }
} 

The above code adds together all penalties and only the largest bonus, unless the property name is one that stacks (like Dodge) in which case they are all added together.

Now create one of the above objects for each item that can have modifiers applied to it: ability scores, weapons, skills, and so on.

In JavaScript I would use anonymous objects and put references to them in multiple places. This would allow me to sort the array (in the above object) by amount which makes sense there, but by expiration time somewhere else. That way I could quickly expire certain modifiers without having to scan EVERY object attached to EVERY ability score/weapon/etc. If you do this, you need more information stored in the modifier so that when its sorted by expiration time it's easy to figure one which object it's in and delete it. In reality I'd probably create a proxy modifier so that the modifier in the proxy can be deleted and all references to the proxy will now return an amount of zero, then I'd clean up the objects only when they were modified (not when they were read, since I expect reading them to happen A LOT and modifying them much less often).

Sorry, a lot to read. But as you can see, I've thought about this a lot. I spent some time coding some of it in jQuery/JS for a charsheet I was working on about 16 months ago... that I lost in a hard drive crash.

[IMarvinTPA]

Natural Armor and Natural are two different bonus types. The former does not stack, the latter does.

They don't need to be sorted, you create a bin for each bonus type and if the current value is less, replace it with the higher one. If they stack, add instead. Penalties reverse the logic in smaller values win and usually stack...

If you have a chance, I made a nice table out of the variables to help see the effect.
IMarv

[Azhrei]

Natural Armor and Natural are two different bonus types. The former does not stack, the latter does.

I can see we'd have to discuss this one in more detail.

They don't need to be sorted, you create a bin for each bonus type and if the current value is less, replace it with the higher one. If they stack, add instead. Penalties reverse the logic in smaller values win and usually stack...

Your technique will work, of course, but keeping them sorted means a little extra overhead when modifying the arrays (the time required to search through the array and insert the new value in the correct place) and a LOT faster lookup when reading the array (since all non-negative values can be skipped it means the entire array doesn't need to be processed so less iterations through the loop). Given that reads are done much more often than writes it should be a huge win to keep them sorted. At least, if you're going to use this at the game table. If this is all pre-game setup then maximum performance isn't that much of an issue (but why not do it anyway?).

Given that the modsets in the current FW are changed maybe once per round per token in a level 8+ game, I would estimate that the read-to-write ratio must be somewhere around 12:1 in such a game. That includes mouseovers to see the AC values, calculating weapon attacks, applying damage and incorporating DR/ER, and so on.

If you have a chance, I made a nice table out of the variables to help see the effect.
IMarv

I'd be happy to look at it. I replied to other post as well -- looks good.

DMGenie implemented something like this a few years ago (wow, that long?) and PC-Gen too, of course. The PC-Gen formulas as stored in the LST files are a bit cumbersome to read/write, but they do work. You could perhaps extract the data from the LST files and build your own database in JSON form. That would give you the weapon, armor, and similar items pretty quickly I would think.

I mentioned DMGenie since it has the stacking rules well implemented and with some nice touches. For example, the stacking types are user-editable so that the GM can create new ones on the fly if needed. And the modifier value can be input as a string in which case it's read as another property name on the creature. This allows the property to be modified elsewhere in the code, such as in the Power Attack feat that when activated modifies the AB and DmgBonus.

One thing that DMGenie didn't do for a long time was a modifier for spell slot manipulation (so it was tough to do the Enervation spell, for example). Caster Level is another one that isn't obvious, but spells like Death Knell and the Incense of Meditation affect it. There was another one too, but I don't recall right now. (Maybe it was Spell Penetration?)