That's because I fixed it ;)
I just forgot to update the on-load version number announcement to v3.14-hotfix.1
Printable View
Sorry for the delay on this. I have a working prototype and would love feedback.
https://i.imgur.com/gRnM2gb.png
Basically if you set the second box to a different ammo type any recovered arrows will go there instead of returning to the original item.
If the two boxes are set the same or if the second box is not set, recovered arrows go back to the original item count.
For reference:
"Arrow, +1
Weapon, uncommon
You have a +1 bonus to attack and damage rolls made with this piece of magic ammunition. Once it hits a target, the ammunition is no longer magical."
How's this? Now it counts misses and hits separately and allows you to recover either one.
The workflow for magic arrows would be to set "recover to" to just "Arrows" before recovering hits and to set it to "+1 Arrows" before recovering misses.
That's a bit fiddly, but it does allow for homebrew rules, special items, etc
https://i.imgur.com/Y5nd0G3.png
Seems to meet the requirements. There are limits to how much you can really anticipate and automate. Some decisions still have to be made and some clicking required. Even so this is very good at minimizing all of that.
The one alternate approach that comes to mind would be duplicating the percentage as well and putting them back on the same line as the ammo picker.
Pros: Perhaps a more intuitive interface. Misses go next to the ammo picker. Hits go next to the "alternate recover to" picker.
Cons: Can't recover misses to an alternate. Doing this is kind of an edge case, but I'm sure some people would use it.
So I'd love feedback on whether that sounds significantly more intuitive.
I like this suggestion and I agree it does seem like an edge case but feels more intuitive, in my opinion.
Additionally, there is the issue of having normal ammo requiring you to recovery both hits and misses which is an extra step no matter which way it is implemented.
Is there a way to know magic ammo is selected? If so then proceed as outlined above but if normal ammo is used simply tally all hits and misses in one field (call it spent vs misses for example) allow for one click to recover? Just a thought.
I have a session this weekend with some range characters. I would be happy to test a UI and gather feedback from them after, if that would be of value.
the other option looks like this
https://i.imgur.com/bsVVZKA.png
I don't want to make a working prototype of that unless it's chosen as the approach because it means changing stuff in other places that will have to be rolled back if it isn't liked
It does look like the hits are tied to the recovery that way. Maybe stack the ammo and recovery selections on top and the two lines for misses and hits under. . A vertical stack, that way the selections feel connected and the misses and hits don't feel connected to any one selector?
Yeah, having them connected just feels less flexible
Ammunition Manager v4.0-beta.2
Click here to see raw code changes
- Reworked UI in 5E and PFRPG to count hits and misses separately and allow recovering either to different ammo items (such as for magic items that lose their magic when they hit).
- Pretty major back-end changes to support these changes in a modular fashion.
- All data for extension is now stored in a sub-node of each weapon rather than directly inside the weapon -- kind of like having a subfolder.
- Removed Starfinder support as it is being forked into its own extension by SoxMax.
- Updated UI to resize its width along with the rest of the weapon details window.
- Optional Custom Weapons ext can now add and remove item names and properties from search lists.
This has been pushed to FG Forge's Test channel.
The UI is kind of a middle ground between the previews I posted.
Very cool. My first tests indicate it is working well. I like the new layout. I will have the group test it today and report back.
I have (a bit prematurely) uploaded a new "custom weapons" extension to the first post for use with v4.
It can now allow adding/removing search terms for weapon name and properties.
For users of v3 versions, it only allows adding weapon names.
Initial test of this did not remove "load" from crossbows when I added the line to the 5e section. It maybe me misunderstanding how to use the new ext but I thought I could remove the load and no longer need to add the noload property.
function onInit()
local sRuleset = User.getRulesetName()
-- replace result handlers
if sRuleset == "PFRPG" or sRuleset == "3.5E" then
table.insert(AmmunitionManager.tLoadWeapons, 'T-Shirt Cannon') -- use lines like these to require loading actions for weapons that include this word in their name
table.insert(AmmunitionManager.tLoadWeaponProps, 'junk') -- use lines like these to require loading actions for weapons with this property
table.insert(AmmunitionManager.tNoLoadWeapons, 'crossbow') -- use lines like these to remove loading actions from weapons that include this word
table.insert(AmmunitionManager.tNoLoadWeaponProps, 'heroic') -- use lines like these to remove loading actions for weapons with this property
elseif sRuleset == "4E" then
table.insert(AmmunitionManager.tLoadWeapons, 'Softball Bat')
elseif sRuleset == "5E" then
table.insert(AmmunitionManager.tNoLoadWeapons, 'crossbow') -- use lines like these to remove loading actions from weapons that include this word
end
end
tNoLoadWeapons only overrides tLoadWeapons and tNoLoadWeaponProps only overrides tLoadWeaponProps.
Your crossbow probably has the loading property so even if it's not matching because of crossbow it's still matching loading.
Do you think tNoLoadWeapons should override tLoadWeaponProps as well?
table.insert(AmmunitionManager.tNoLoadWeaponProps, 'loading') would work currently, but will also remove the button for other weapons with that property
I have uploaded a new version of the custom ext in the first post that has much clearer documentation about all this.
I tried the "table.insert(AmmunitionManager.tNoLoadWeaponProps , 'loading')" and it still has a load button on the heavy crossbow. Not sure how to get this to go away.
In 5e we don't have to worry about "loading" so the button just adds a click to the overall action to attack that is not needed. Having a way to set all crossbows to not loading would be ideal for my group.
Here is my file:
function onInit()
local sRuleset = User.getRulesetName()
-- These sections allow you to limit changes to specific ruleset(s)
if sRuleset == "PFRPG" or sRuleset == "3.5E" then
-- put your lines here to limit them to PFRPG or 3.5E
elseif sRuleset == "4E" then
-- put your lines here to limit them to 4E
elseif sRuleset == "5E" then
table.insert(AmmunitionManager.tNoLoadWeaponProps, 'loading')
end
-- This section allows you to change all supported rulesets.
-- IMPORTANT: remove any examples you don't want or disable them without deleting them by adding "-- " before "table.insert"
table.insert(AmmunitionManager.tLoadWeapons, "T-Shirt Cannon") -- use lines like these to require loading actions for weapons that include this word in their name
table.insert(AmmunitionManager.tNoLoadWeapons, "crossbow") -- use lines like these to remove loading actions from weapons that include this word (overrides tLoadWeapons)
table.insert(AmmunitionManager.tLoadWeaponProps, "junk") -- use lines like these to require loading actions for weapons with this property
table.in
Otherwise, everything seem to work fine in tonight's game.
Ammunition Manager v4.0-rc.1
Click here to see raw code changes
- Reworked UI in 5E and PFRPG to count hits and misses separately and allow recovering either to different ammo items (such as for magic items that lose their magic when they hit).
- Pretty major back-end changes to support these changes in a modular fashion.
- All data for extension is now stored in a sub-node of each weapon rather than directly inside the weapon -- kind of like having a subfolder.
- Removed Starfinder support as it is being forked into its own extension by SoxMax.
- Updated UI to resize its width along with the rest of the weapon details window.
- Loading property in 5E no longer requires loading manually as it takes no discrete action.
Gave the 4.0-rc.1 a try and the crossbows are still adding with a load button in 5e. Maybe I need to use the other ext to sort them out? Or I can just use the noload property on the crossbows as well.
Ah, I found a place where 5e was totally ignoring everything I had done and just looking for crossbow and loading >.<
Try rc.2! It's definitely working now!
I will test it tonight. Thanks.
That got it! Thanks!
v4 has now been released.
Ammunition Manager v4.0-hotfix.2
Click here to see raw code changes
- Reworked UI in 5E and PFRPG to count hits and misses separately and allow recovering either to different ammo items (such as for magic items that lose their magic when they hit).
- Pretty major back-end changes to support these changes in a modular fashion.
- All data for extension is now stored in a sub-node of each weapon rather than directly inside the weapon -- kind of like having a subfolder.
- Removed Starfinder support as it has been forked into its own extension by SoxMax.
- Updated UI to resize its width along with the rest of the weapon details window.
- Optional Custom Loading Weapons ext can now add and remove item names and properties from search lists.
- Loading property in 5E no longer requires loading manually as it takes no discrete action. Crossbow Expert feat no longer used to remove loading button on Crossbows (as they don't have it now unless you do that yourself).
- HOTFIX: Move 5e field visibility code to another function to facilitate easier extension compatibility patching.
- HOTFIX: Fix potential issue of onAttackAction not being de-registered correctly in 5e when char_weapon windowclass is unloaded
Hello Bmos, hello B9,
I have discovered a compatibility issue in-between B9's Advanced Weapon Damage and Bmos' Ammunition Manager extension. Nothing causing a script error, just an inconsistent UI.
Tested with a fresh 5e campaign and only those two extensions (plus B9 Core, so actually three) loaded.
When both are loaded, the "load" button is visible even for melee weapons. You can load and unload them (with corresponding chat notification), and both extensions work, so it's just cosmetics.
I suspect this is due to both extensions changing the weapon entry in the actions.
I am sending a note to the other forum threat, but not repeat the post to avoid forking discussions.
Attachment 56862
Likely this is because B9 is overriding onDataChanged in char_weapon without calling previous copies via super.onDataChanged.
I don't know this for sure, but that's the most likely thing I can think of. If I'm correct, the hiding of the ammo checkboxes and linking of the ammo field when you link ammo should also not be working.
If overriding this is required for the features of that extension (since of course it's usually best to call the prior function when you override it), it shouldn't be hard to add some compatibility code to the replaced function based on this.
I've released v2.7, which adds calls to the super onInit/onClose which clear up the loading/unloading icons on my tests... but not sure if the 'DB.addHandler(DB.getPath(nodeWeapon), 'onChildUpdate', onDataChanged)' in my onInit and in yours will both be called due to them been on the same node...
As I'm not sure on the exact setup and usage for 5e to have these show up or not and work etc.. can some one check with the v2.7 and see if this has resolved the issues. If not we can talk about now to deal with DB.addhandler calls from both extensions.
-pete
So I did a check with the hotfix version and my version against the 'onDataChange' call back registered by both extensions. It does seem with debug.chat tests in both extensions that both get called..
So you dont need the refactor your 'onDataChange', as calling the super is not required. And also you would need to pass down the 'nodeWeapon' into the 'super.onDataChanged(nodeWeapon)'.
But feel free to have a test against v2.7 to see if other conflicts exist, but you should not need that slight refactor as both are getting called.
It probably was just the onInit/onClose in my extension not calling the super, which was skipping your onInit/onClose which registers you onDataChange etc... all getting lost with the error in my code.
-pete
Hello, can this be extended to pathfinder 2.0? SoxMax created a ammo manager for starfinder https://forge.fantasygrounds.com/shop/items/1128/view and the ruyles as far as I know aren't any different but if you need any info I am happy to help. Your extensions are amazing you are very talented. You have made my GM job much easier.
Yep the callback does provide the node...
but you line
if super and super.onDamage then super.onDamage() end
does not pass it down... I was point out the bug that it should have been...
if super and super.onDamage then super.onDamage(NODE) end
but I assume you have removed this code as both extensions have registered handlers and both handlers get call... so no need to try and call a super function.
-pete
Testing with B9 - Advanced Weapon Damage 2.7, Common Core v0.1a & Bmos Ammunition Manager v4.0-hotfix.3, the issue persists
Attachment 56871
Because AWD replaces some of the onDataChange, onAction,onDamage as it has to evaluate damage line clauses and reject or include depending on if things like 'slashing,type(undead) in the weapon damage line, it would be best if Ammo manager could load after AWD, so after loadorder 110. I'm not sure if Ammo manager can move from its 34, which seems a very specific number so maybe locked to a low value due to other extension conflicts. I dont know.
But since Ammo manager only seems to not call the super version in cases when no ammo exists and should not process, it make more sense for a load order after mine.
( I'm also not convinced that some of the addhandler calls should also call the supers as it assumes only one addhandler will fire, when they all fire from each level... so you end you with multiple calls as each addhandler fires and then the supers call extra versions on top of the addhandler version of other extensions.. it gets a mess. I need to look into what the original ruleset code is registering and what is been called. )
At the moment the self.onDataChange in the ammo manager oninit, is causing the AWD onDataChange function to be called, which does not call down to the super and hence does not call the ammo manager onDataChange. But if you edit and cause an update action then both extensions onDataChange get called from the addhandlers registered from each extension and it should sort the 'load'/'unload' visibility. But if we both have super calls in these then they will nest recursive which could cause data to be process multiple times which might cause issues... Specially on the onDamage and onAction versions of these functions.. we dont want to end up doing multiple 'performRoll' action calls which would happen if both extension 'onDamageAction' were called and hence can not and should not have super calls. In these cases the resolution is to basically have one extension that is loaded last have to 'process' all other extensions.. This can be seen in both our code as we both have to 'have special' code for 'AdvancedEffects' extensions as our call cause us to replace the lower order loaded 'AdvancedEffects' onDamageAction changes... so it propagates code from other extensions into each of ours. With the current load order, I'd have to include and process Ammo managers 'code' for onDamageAction in my onDamageAction to resolve all extensions and end up with just a single 'preformRoll' call.
So its not just a case of load order, and super calls... this gets very messy very quick due to how the ruleset was written and how things merge.
( Sorry if i have to edit this in the morning to have it make sense, its late night for me )
-pete
Sounds like a lot of effort, likely too much for a cosmetical issue - I have advised my players to ignore the "load" button on melee weapons. Functionality was not affected (at least when I reported the issue), so when they "load" a sword it's funny one or twice then no more