Great! Thanks.Quote:
Originally Posted by superteddy57
Printable View
Great! Thanks.Quote:
Originally Posted by superteddy57
I'm afraid there's also a problem with missile weapon damage bonuses. They are ignored for NPCs.
Attachment 54226
Attachment 54230
Thanks for fixing this in the latest update.Quote:
Originally Posted by peterb
Just noticed that NPC hit location data is not parsed correctly. Also, the armor points are not properly parsed. I'm pretty certain that all this once worked. Screen-shots below:
Attachment 54249
Attachment 54250
The data in the "Calc" column is correctly calculated, it's just not the right data for that column. It's HP per hit location. It should be input to a calculation formula. For example, for a humanoid it should be "1/3" for a leg, "1/4" for an arm and "0.4" for the chest. I'm also think that the armor data was parsed and correctly inserted into the AP column, but here I might remember wrong.
Does this look right?
Attachment 54251
Sorry, no it doesn't. The image below is a screen-shot from excel.
Attachment 54254
The data is retrieved from the table "HitLocationTemplates" in scripts/manager_gameline.lua
I was referring to the amount of the HP being calculated to be sure it was outputting as expected from the data within the ruleset. I see that from your screenshot. The issue here is the column headers were incorrect as you pointed out. I adjusted the headers to match the controls underneath them and ensured they match.
I noticed that this is now fixed in the test channel. Thanks!Quote:
Originally Posted by superteddy57
Got a couple of issues with the BRP ruleset, one is a cosmetic nitpick, the other is very annoying to me (especially since I like using encumbrance systems in my games).
1. Attachment 56254
When Use Fatigue, Use Power Points, and Use Sanity are enabled in Options | House Rules, the field for the Max value of those characteristics appears to be set in relation to the right edge of the Main tab rather than in relation to the left edge of the value label Max for them. I know this is a nitpick, but I find it very distracting.
2. Attachment 56255
The Inventory tab is a bit broken. BRP doesn't use Weight, it's items have Encumbrance, which the when you view an item shows. However on the Inventory tab, the Wt column should be showing as ENC instead and should population with the Encumbrance value from the item. Also the Total weight carrier should be Total Encumbrance. Also I'm not sure what the label Armor is supposed to be doing, but even when armor type item is equipped it doesn't change, so I suspect it's broke also.
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).Quote:
Originally Posted by superteddy57
For the (bhag) $5/month revenue it generates I dont think you are going to get any updates of that size.
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.Quote:
Originally Posted by sirkerry
Maybe, heck, even most likely, but I don't know if I don't ask.Quote:
Originally Posted by damned
Thank you.Quote:
Originally Posted by superteddy57
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.
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.
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?
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?
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.Quote:
Originally Posted by superteddy57
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.
Please provide me with more step by step processes to replicate. I'm just not able to replicate it with rolling on the armor tab.Quote:
Originally Posted by peterb
From the chat log:
Basic Roleplaying: the Chaosium Roleplaying System (2023-02-21) Copyright 2023 Smiteworks USA, LLC
Core RPG ruleset (2023-03-07) for Fantasy Grounds Copyright 2023 Smiteworks USA, LLC
Steps to re-create. Roll a series of hit-location rolls, you probably need to roll twenty or so.
See the image provided, for examples:
Attachment 57069
The first roll a 16 is not aright arm roll on the melee hit location table, its a left arm roll. And the last roll is not a chest hitlocation roll. On the melee table only a 12 hits the chest. These results are from the missile hit location table, even though I didn't press shift when I made the rolls.
Added:
Just to make sure that this is not a problem with my FG installation, I installed FG on a secondary PC and created a new BRP campaign. The problem remains.
Are these all performed using the hit location button on the main tab? The armor tab button or double clicking on the hit location column strings?
With the next update I will have an option to show the SR column on the combat tracker and allow it to be sorted by the SR number in those. The number calculated will be the base calculation of DEX + SIZ modifiers. As adding in the weapon modifier will require a lengthy development cycle, it won't be collected and calculated. The GM would need to adjust it by hand to add that in, but this will at least set the base DEX/SIZ calculation as a quicker start point. It should be off by default to keep with the standard process that is currently in place. I think this being made available for those that wish to use it will be fine and help enhance those games. It's not a full feature expansion, but just plugging in those parts that are there and providing more help to those that use the option.
As per your hit location report, I was able to see a disconnect and have found a solution for that as well. I will also add in a new chat output that will indicate if the missile table is being used instead of the melee one. I believe prior to my fix the work around would be to double click on the text of the table on the armor tab you would like to roll on till this is available with the next weekly update.
I used the one on the armor tab for these examples, but I have done the same test from the main tab, same result.Quote:
Originally Posted by superteddy57
The chat output already shows when a roll on the missile table is done: "hit location (missile) -> Left Arm", so no need to spend time on that.Quote:
Originally Posted by superteddy57
I mostly use the automatic hit location when you use targeting.
And I hope that it's using the right table because it don't show in the chat window.
Attachment 57080
On the automatic calculation of total weight
The problem is not in the code as sirkerry notes, but in the XML-files. If you enter items and their weight manually everything works as expected. I did a quick test and replacedQuote:
Originally Posted by sirkerryI 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.
Quote:
Originally Posted by superteddy57
withCode:<encumbrance type='string'>0.5</encumbrance>
in client.xml in the module BRPGameSystem. I had to edit some values, e.g. missile weapons had both the weight of the missile weapon and the weight of the ammunition in the encumbrance field. But, after that change the automatic handling of weights also worked for items dragged from the equipment lists.Code:<weight type='number'>0.5</weight>
If you know your way around XML-files and how to package module files in FG then you can do the change yourself. I suspect Smitheworks need permission from Chaosium before they can do a change to the XML-files and ship updated ones. But, as I said, the solution is not complicated nor time consuming to implement.
When clicking on the link to the table of armors, located in the list of frequently used tables, I get an error message in the console: "[5/9/2023 3:36:03 PM] [ERROR] Script execution error: [string "W:reference_armor"]:21: attempt to index global 'content' (a nil value)". I get the same error when clicking on the link to the table of shields. As the error message suggests, the variable "content" doesn't exists. I don't know how long this error has been in the code, it was a while since I clicked on these links. Any suggestions on how to fix this?
I have used a vanilla campaign with no extensions, standard theme.
[5/9/2023 3:35:43 PM] RULESET: Basic Roleplaying: the Chaosium Roleplaying System (2023-04-17) Copyright 2023 Smiteworks USA, LLC
[5/9/2023 3:35:43 PM] RULESET: Core RPG ruleset (2023-04-25) for Fantasy Grounds Copyright 2023 Smiteworks USA, LLC
See attached image:
Attachment 57310
The relevant code is in ref/ref_basicclasses.xml, in the windowclass "reference_armor"
Code:local catlist = {};
local catcount = 0;
local entcount = 0;
function onInit()
local src = DB.getValue(getDatabaseNode(), "source", "");
local source = nil;
local w,h;
if super and super.onInit then
super.onInit();
end
if src and src~="" then
source = DB.findNode(src);
for _,node in ipairs(DB.getChildList(source)) do
if DB.getValue(node, "equipmenttype", "") == "Armor" then
local catname = DB.getValue(node, "catname");
local win = catlist[catname];
if not win then
catcount = catcount + 1;
win = content.createWindow();
catlist[catname] = win;
win.name.setValue(catname);
end
win.content.createWindow(node);
entcount = entcount + 1;
end
end
content.applySort();
w = getSize();
h = catcount*29 + entcount*15 + 61;
setSize(w,h);
end
end
MOD: Moved to Bug report thread. I will have a look over what you've found. Might not be ready for today's update push.
Thanks for looking into this.
I did some digging in my backed-up editions of the ruleset. The current look and feel for table item first appeared in 2021-09-11. Table item are now drag-and-droppable to the inventory tab. But the current error message for armor and shields also first appear here. In the previous edition, just a few days earlier, 2021-09-08, the old look and feel still reigned. Weapon, armor and shield content are shown, but they can't be dragged to the inventory, nor is the list scrollable, and the link icons use a D&D style icon. So, there was a codebase change in September 2021 that introduced the current state.
Hope this helps.
There is a windowlist called 'content' but it's located in another windowclass "reference_armor_category". So, when in onInit in windowclass "reference_armor" the code makes are reference to 'content' it's out of scope, and that's why we get the error message.
Code in made bold by me.
Proper referencing always confuses me in FG. In this case we have a function that tries to reference a named item in another windowclass:Code:function onInit()
local src = DB.getValue(getDatabaseNode(), "source", "");
local source = nil;
local w,h;
if super and super.onInit then
super.onInit();
end
if src and src~="" then
source = DB.findNode(src);
for _,node in ipairs(DB.getChildList(source)) do
if DB.getValue(node, "equipmenttype", "") == "Armor" then
local catname = DB.getValue(node, "catname");
local win = catlist[catname];
if not win then
catcount = catcount + 1;
win = content.createWindow();
catlist[catname] = win;
win.name.setValue(catname);
end
win.content.createWindow(node);
entcount = entcount + 1;
end
end
content.applySort();
w = getSize();
h = catcount*29 + entcount*15 + 61;
setSize(w,h);
end
end
So how do you do the proper referencing?Code:windowclass A
function
windowclass B
item
I just pushed a fix to address the script error in reference_armor. Both content.createWindow and content.applySort were pointing at the wrong control; it should be list.createWindow and list.applySort. I've checked in a change that I think should fix, but I'm not familiar with where to pull up that list.
Can you run a new Check for Updates and verify whether that fixes the issue for reference_armor, or walk me through the steps to find that list with the included data?
Thanks,
JPG
The change did indeed fix, at least one part of the problem. The list of armors is now properly displayed.
Two issues remain:
a) The armor items are not drag-and-droppable, like weapons are.
b) The same fix needs to be applied to reference_shields as well, since it has the same problem.
Thanks for looking into the problem and providing a fix.
When I review the code, I see that you have in fact changed the code in reference_shields. But I still get an error message, as before, about 'content' being a nil value when clicking on the link to "Shields".
Ok, good catch on the other equipment types (I should have checked for similar issues in that file), as well as the items not being able to be dragged and dropped. I've added fixes for each of those items in a new build, if you want to run a new Check For Updates to take a look.
This is our oldest ruleset we still sell, and it doesn't have a dedicated developer any more (moved on long ago). So, we're still trying to maintain to keep it working with Core features, and fix any bugs reported. Thanks for your help figuring them out.
Regards,
JPG
All items in the tables are now shown as expected and they are all drag and droppable. Even items in my homemade modules that wasn't working before.
Many thanks for this update!
/Peter
As currently coded the npc sheet expect a creatures description to be stored in an xml element named "appears", see campaign/record_npc.xml lines 45 and 61. The creatures in the Game Master Guide module stores all their descriptions in the (unformatted) notes element so they are not affected by this. However, the creatures in the "Basic Creatures" module, which is not for sale anymore, use an element named "text", as is 3.5E and 5E. So, these creatures descriptions are not shown. I used the same layout in when I created a module containing creatures converted from the 5E SRD to BRP, so my creature descriptions doesn't show either. I propose that the code in campaign/record_npc.xml is changed so it uses the element name "text" instead of "appears", as in the code below. This change will not affect any creatures in the Game Master Guide, but it will make the descriptions in the "Basic Creature" module visible. And, I guess, using the element name "text" is more inline with what other rulesets use in the same situation. The other option would be to change the xml code of a module that is not on sale anymore.
In the windowclass "npc" (campaign/record_npc.xml)
Code:<script>
function onInit()
onStateChanged();
end
function onLockChanged()
onStateChanged();
end
function onStateChanged()
if header.subwindow then
header.subwindow.update();
end
if main.subwindow then
main.subwindow.update();
end
if combat.subwindow then
combat.subwindow.update();
end
if notes.subwindow then
notes.subwindow.update();
end
local bReadOnly = WindowManager.getReadOnlyState(getDatabaseNode());
text.setReadOnly(bReadOnly);
end
</script>
<sheetdata>
<sub_record_header name="header">
<class>npc_header</class>
</sub_record_header>
<frame_record_content_tabbed name="contentframe" />
<subwindow_record name="main">
<class>npc_main</class>
</subwindow_record>
<subwindow_record name="combat">
<class>npc_combat</class>
</subwindow_record>
<ft_record name="text">
<anchored to="contentframe" position="over" />
<invisible />
</ft_record>
<subwindow_record name="notes">
<class>npc_notes</class>
</subwindow_record>
<scrollbar_record>
<target>main</target>
</scrollbar_record>
<scrollbar_record>
<target>combat</target>
</scrollbar_record>
<scrollbar_record>
<target>appears</target>
</scrollbar_record>
<scrollbar_record>
<target>notes</target>
</scrollbar_record>
<tabs_recordsheet name="tabs">
<tab>
<icon>tab_main</icon>
<subwindow>main</subwindow>
</tab>
<tab>
<icon>tab_combat</icon>
<subwindow>combat</subwindow>
</tab>
<tab>
<icon>tab_appears</icon>
<subwindow>text</subwindow>
</tab>
<tab>
<icon>tab_notes</icon>
<subwindow>notes</subwindow>
</tab>
</tabs_recordsheet>
<resize_recordsheet />
<close_recordsheet />
</sheetdata>
</windowclass>
Seems reasonable, though there is a gotcha. BRP is the oldest ruleset still being offered in the store, which is why it does everything a little different.
The gotcha is that any data placed in those fields within an existing campaign or custom module will not be available any longer. Since it's a low use ruleset, I'll probably just offer to do the data migration if anyone encounters that.
The ruleset is currently locked down pending the new release, so the changes are currently in the beta Test channel and will be released in June.
Regards,
JPG
OK. Thanks!