Problems / Bugs with BRP?

[sirkerry]

As the oldest system in the catalog it certainly shows it's age. The ruleset is as is in terms of features. The encumbrance system is the same when the system launched on the platform. As the system doesn't have a dedicated developer it's in a maintenance mode that means keeping it running with the CoreRPG latest updates and resolving those bugs from them. What you've presented will go on my list of things to investigate, but look to be more in line with feature requests to expand the current functionality. Which may or may not be addressed in the near future.

I can as a quick fix adjust the label Wt to Enc and see if I can adjust the anchoring to be a bit more accommodating to the window size changing.

I hear/see what you're saying, but nowhere on the store page to purchase the Basic Roleplaying ruleset for FGU do I see it state anywhere that the ruleset is 'as is in terms of features', but, I would argue that the encumbrance/weight disconnect in the ruleset (the items don't have a weight stat, instead have an encumbrance stat, but the Inventory tab is looking for a weight stat instead of encumbrance) is a defect in the product code that should be fixed and not a request for a new feature to expand current functionality, but instead a request to fix an implied basic functionality expected by a purchaser in a FGU ruleset for a game that has an encumbrance system (an experience formed by the purchase of several other rulesets).

[damned]

For the (bhag) $5/month revenue it generates I dont think you are going to get any updates of that size.

[superteddy57]

I hear/see what you're saying, but nowhere on the store page to purchase the Basic Roleplaying ruleset for FGU do I see it state anywhere that the ruleset is 'as is in terms of features', but, I would argue that the encumbrance/weight disconnect in the ruleset (the items don't have a weight stat, instead have an encumbrance stat, but the Inventory tab is looking for a weight stat instead of encumbrance) is a defect in the product code that should be fixed and not a request for a new feature to expand current functionality, but instead a request to fix an implied basic functionality expected by a purchaser in a FGU ruleset for a game that has an encumbrance system (an experience formed by the purchase of several other rulesets).

Thanks for the response and as I said, I will have this on my list to look over and see what would be involved in adjusting that.

[sirkerry]

For the (bhag) $5/month revenue it generates I dont think you are going to get any updates of that size.

Maybe, heck, even most likely, but I don't know if I don't ask.

[sirkerry]

Thanks for the response and as I said, I will have this on my list to look over and see what would be involved in adjusting that.

Thank you.

[IrishSpider]

Hello,

I am trying to figure out why the combat tracker follows Dex instead of SR (Which it doesn't seem to fill). Is there a setting I am missing?

Appreciate it.

[superteddy57]

It's never sorted by SR from my memory of the code. It's always been DEX based. I'm not also able to locate any options from the original developer to sort it by SR.

[superteddy57]

Would adding the ability to sort the combat tracker by SR and calculate a base SR be sufficient for your case? I can add a global option to turn it on and off to change the sort from the Dex box to the SR box. The SR box won't auto populate or adjust automatically, but can add a combat tracker menu option to calculate the base SR. Would this help?

[peterb]

Problem with hit-location rolls

Re-posted from the BRP discord channel.

Last session my gaming group noticed that all hit locations rolls were made on the missile hit location table. It didn’t matter whether you held down the shift key, all rolls where on the missile hit location table. I double-checked on a new vanilla BRP campaign, and the error persists.

The error can be verified by making a few hit-location rolls. You are likely to soon get faulty results.

The code in /scripts/manager_gameline.lua haven’t changed for ages, so that’s not the source of the error. I also tried to override the 'roll hit-location' code and remove Input.isShiftPressed(), but that didn’t have any effect at all. So, I’m a bit puzzled, what could cause this error?

[peterb]

Would adding the ability to sort the combat tracker by SR and calculate a base SR be sufficient for your case? I can add a global option to turn it on and off to change the sort from the Dex box to the SR box. The SR box won't auto populate or adjust automatically, but can add a combat tracker menu option to calculate the base SR. Would this help?

Unfortunately no. The effective SR is calculated using the actors DEX and SIZ as well as the SR of the active weapon. I've seen traces of SR handling in the code (or at least there where there back in 2009-10) but I understand why it was never fully implemented. Passing on the SR of the currently used weapon is (or was at the time) not trivial. The problem must have been solved by the Author of the upcoming Runequest ruleset, since otherwise that ruleset wouldn't be working correctly.

So, while I would be very happy if SR's where implemented in full, I understand that doing so is not trivial. Also it has never worked so it would not be a bug correction, but a new feature, so I'll understand if Smiteworks have better things to spend their time on.