Official Pathfinder Modules Bug Report Thread

[Trenloe]

I can see "Map - Hook Mountain Clanhold" in LIbrary -> Images & Maps but when I open it, it is a New Drawing (empty). Same empty New Drawing opens from Story entry.

Yeah, I think the underlying issue is with the image name. But for me it displays OK. See screenshot below.

Can you check in the Module Versioning in the reference manual what version you have?

I assume you're running the PFRPG ruleset, v3.3.8 (live not test)? If so, can you try it in a brand new campaign with no extensions loaded?

[sciencephile]

That was weird. For some reason, the Name and Non-ID Name tags were missing. This causes the map to be there but without its name. I fixed it and checked it in so it will be updated during next Tuesday's update. In the meantime, you should be able to use the map indicated above. It just has no name.

-Danny

[HoloGnome]

It looks like we can no longer manually enter carrying capacity values. However, the automatically-calculated encumbrance values in PFRPG (1.0) are not correct. But...in general, I like the idea of automated entry (as long as it works).

For example:
- For a small biped creature with 9 strength, the Light encumbrance should be 22.5lbs, not 22lbs. Please do not remove the decimal fraction. Items are not always multiples of 1 lb. and there should be at least 2 decimal places supported (some items are 1/2 or 1/4 lb. and size modifiers require .xx resolution with proper rounding.
- In terms of clarity/usability, there is no way to specify a quadruped creature. There should either be a radio-button A/B for biped / quadruped, or checkbox for quadruped. And, this function should ideally be in the encumbrance box to facilitate easy use by shape-changers (druids, etc.). There is wasted space in that box layout and this feature could easily go at the bottom by reclaiming wasted space.
- I realize that there is now a pop-up multiplier box as a possible workaround, but those calculations also do not work (or round) properly with respect to decimals. For example, if you set size as small, then it defaults to biped values. If you then multiply by 1.33 to eliminate the .75 multiplier, the resulting values appeared to be rounded down instead of up when the decimal portion is >= .5.

Hmmm...looking a bit more, it may be that only the Light and Medium encumbrance boxes are not showing 2 decimal places. The other 4 boxes seem to be OK. So, maybe that is the main issue for bipeds. But, the biped/quadruped thing is still a potential usability issue.

Edit: Nope - the calculations are just incorrect. For 9 strength, base values should be: 22.5, 45, 67.5, but instead are 22, 44, 67 (all 3 are wrong, and therefore, the bottom row values are also all wrong).

Please fix or unlock entry - thanks!

Edit: Any chance this issue could be resolved by FGCON?

[Moon Wizard]

This code has not changed in 2 years; so it's been this way for quite a while.

The problem with not rounding the number is that number representation in Lua is via floating point, and these sorts of calculations can cause the number returned to look like 1.00001 or 4.49999; which is not correct either.

I'll look into it, but any fix would be queued for v3.3.9 or later, which will be released after FGCon.

Regards,
JPG

[HoloGnome]

Well...it's definitely an important problem, so I hope it can be fixed soon. The change (whenever it was made) breaks encumbrance for PFRPG (and makes it unusable because of the errors). So, it's very surprising that nobody noticed. It points to the need for better specs for these types of changes and more detailed unit testing afterwards.

I noticed the problem immediately upon trying to create a small PC. However, the issue will also occur with quadrupeds, as noted in my original post.

Also, as for rounding, it should be a simple matter to do traditional rounding in Lua to 2 decimal places. Both rounding and # of decimal places are problems for the encumbrance fields. Again - would benefit from better specification and unit testing.

I tried a couple of workarounds, but there is an override when the sheet loads. Ah well.

I hope you guys can prioritize this change. I guess I could just hack the character sheet as a workaround, if needed, but I would rather not have to do that.

Anyway - thanks for looking into it.

[Kelrugem]

Well...it's definitely an important problem, so I hope it can be fixed soon. The change (whenever it was made) breaks encumbrance for PFRPG (and makes it unusable because of the errors). So, it's very surprising that nobody noticed. It points to the need for better specs for these types of changes and more detailed unit testing afterwards.

I noticed the problem immediately upon trying to create a small PC. However, the issue will also occur with quadrupeds, as noted in my original post.

Also, as for rounding, it should be a simple matter to do traditional rounding in Lua to 2 decimal places. Both rounding and # of decimal places are problems for the encumbrance fields. Again - would benefit from better specification and unit testing.

I tried a couple of workarounds, but there is an override when the sheet loads. Ah well.

I hope you guys can prioritize this change. I guess I could just hack the character sheet as a workaround, if needed, but I would rather not have to do that.

Anyway - thanks for looking into it.

You should look into the 3.3.9 thread Moon Wizard added that already today (up to one decimal point, when I remember correctly) See https://www.fantasygrounds.com/forum...406#post458406

I guess noone noticed because (at least for me) it is not so incredible important that every number is as in the core rules (but it is nice that it now fits ). It is already abstract (one could discuss the connection to strength and how it is related to that in what amounts of possible encumbrance and so on) and many handle encumbrance (parts of it) manually, personally I also do not really care about 0.5 or 1 missing lbs, in sense of that I would only have looked in my book when the deviation would be so extreme that I would have noticed That is probably the reason why noone noticed

[HoloGnome]

Kelrugem - thanks for the thread pointer. I didn't see it. Unfortunately, as in my original post, encumbrance needs to support 2 decimal places in order to function correctly based on the SRD Pathfinder inventory and carrying capacity math. And, looking quickly at the code in 3.5E/onEncumbranceChanged() in char_inv.lua (if that's where it is inheriting from), it's pretty clear why things aren't working in the current version.

MW - I appreciate you looking into this issue. If you can match it to what the SRD requires, including support for 2 decimal places (1/4 lb. resolution required), that would be great.

Edit - Besides precision, in terms of correcting the values, the simplest implementation for this feature is probably with a basic lookup table for carrying capacity, a table for size modifiers (which I guess would subsume footed modifiers), and a well-crafted rounding routine. Then, just figure out the indices into each table, multiply and round. But, I guess there is also the issue of very high strength, which would extend the table. Hmmm...

[HoloGnome]

Attached is a spreadsheet with all the correct math and tables for all sizes of Pathfinder bipeds and quadrupeds for general use or testing purposes. It also includes custom calculation fields for any STR value. I hope it helps simplify the task of correcting the encumbrance problems and is sufficient to support development of a complete spec. It should also serve as a good verification test tool or great gaming utility for anyone who wants to double-check encumbrance values. If you see any problems with it, let me know and I will correct them.

HoloGnome's Pathfinder Encumbrance Tables for Bipeds and Quadrupeds v1.0.0

[Leonal]

Hiya! I haven't been here for quite a few years, but now my group is back playing the Mummy's Mask. :)

As the GM I noticed some bugs with the maps for the first part in the area Sanctum of the Erudite Eye. On the player map "D Sanctum of the Erudite Eye" a secret door has a very large 'S'. Additionally the map "D Sanctum of the Erudite Eye Crypts" has a layer bug where the doors appear to be under the wall layer. I couldn't find this reported elsewhere on the forums.

The latter bug is not a big deal, but the first one is kinda hard to not show to the players without making it obvious something hidden is there. I'll probably just let the players know that they can see a poorly hidden secret door, but if some other group plays this later on I'm sure they'd appreciate an update if possible. :)

Kudos for making the modules! So much more convenient than scrubbing the PDFs like we did in the old days...:D

[lokiare]

Hiya! I haven't been here for quite a few years, but now my group is back playing the Mummy's Mask.

As the GM I noticed some bugs with the maps for the first part in the area Sanctum of the Erudite Eye. On the player map "D Sanctum of the Erudite Eye" a secret door has a very large 'S'. Additionally the map "D Sanctum of the Erudite Eye Crypts" has a layer bug where the doors appear to be under the wall layer. I couldn't find this reported elsewhere on the forums.

The latter bug is not a big deal, but the first one is kinda hard to not show to the players without making it obvious something hidden is there. I'll probably just let the players know that they can see a poorly hidden secret door, but if some other group plays this later on I'm sure they'd appreciate an update if possible.

Kudos for making the modules! So much more convenient than scrubbing the PDFs like we did in the old days...

The developer has been notified of the issues. When you say 'layer' what do you mean exactly? Are you using Fantasy Grounds Unity?