Feedback Thread - FGU v4.5.10 and 2024-08 Ruleset Updates

[SilentRuin]

This is rather vague...

Review any overrides to the following scripts:

LibraryData, ItemManager

I have no idea what to do with this.

I use (don't override) calls in LibraryData.

I override ItemManager functions:

ItemManager.getItemSourceType
ItemManager.handleAnyDrop
ItemManager.addItemToList
ItemManager.sendItemTransfer
ItemManager.getDisplayName

All of these will call original code (if not deciding to go its own way).

[Moon Wizard]

That's correct. If you are overriding the core functionality of either of those global scripts; you will need to review your code and compare with the core version.

Regards,
JPG

[SilentRuin]

That's correct. If you are overriding the core functionality of either of those global scripts; you will need to review your code and compare with the core version.

Regards,
JPG

Yep I see now it completely broke the transfers in Map Parcel extension for TEST.

[dmbrown]

Is it possible to release the files used to create this new theme, so that it will be easier for others to create their own theme? Something like the link below, but for all the various pieces in multiple Photoshop files?
https://fantasygroundsunity.atlassia...ar+Dock+Frames

[SilentRuin]

Bug?

Previously ItemManager.getItemSourceType would return the following for this node:

s'treasureparcels.id-00005.itemlist.id-00001'
s'treasureparcel'

In TEST this now returns "" which causes me much grief.

This still returns the correct value in TEST for the following node:

s'treasureparcels.id-00005'
s'treasureparcel'

So was this an intentional "no longer works as it did" change that I have to now resolve on my own or is this actually a bug in TEST?

[Viryz]

The new theme looks excellent. The interface is visually less cluttered, but I think the spacing between elements needs some work, as it's clearly the same as before, although it could definitely be reduced.

I have a question/suggestion on a slightly different topic. I've been using the new item functionality, and learned that the item picture can be put on the map. Are there plans to make this picture also a link to the item's statblock? To be able to open the item from a token on the map? Is there a chance of such functionality in Parcels?
Or maybe it's better to write it in Feature Request if there are no such plans?

[SilentRuin]

Bug?

Previously ItemManager.getItemSourceType would return the following for this node:

s'treasureparcels.id-00005.itemlist.id-00001'
s'treasureparcel'

In TEST this now returns "" which causes me much grief.

This still returns the correct value in TEST for the following node:

s'treasureparcels.id-00005'
s'treasureparcel'

So was this an intentional "no longer works as it did" change that I have to now resolve on my own or is this actually a bug in TEST?

The first three of these are required to get ItemManager.getItemSourceType back to working in my world (not sure if there are more that are busted but these are ones returning "" that I know are different that they were) - the last two I don't know if I require or not but figured I'd play it safe. Gist being if this new TEST stuff returns "" I can't believe it and have to do these checks to make sure.

	if StringManager.startsWith(sNodePath, "treasureparcel") then
		return "treasureparcel";
	elseif StringManager.startsWith(sNodePath, "partysheet") then
		return "partysheet";
	elseif StringManager.startsWith(sNodePath, "charsheet") then
		return "charsheet";
	elseif StringManager.startsWith(sNodePath, "temp") then
		return "temp";
	elseif StringManager.startsWith(sNodePath, "item") then
		return "item";
	end

[SilentRuin]

I don't know why TEST has added these verifications for records

-- bCurrency = Enables currency can be transferred to this record type. (See ItemManager for default currency paths; or use custom data registration to set different one.)
-- bInventory = Enables items can be transferred to this record type. (See ItemManager for default inventory paths; or use custom data registration to set different one.)


But of course for Extensions (more than one does this) that have inventory tabs added onto NPC/VEHICLE sheets this needlessly breaks them all.

I suppose the only recourse is to now override

aRecords = {
	["vehicle"] = { 
		aDataMap = { "vehicle", "reference.vehicles" }, 
		aGMListButtons = { "button_vehicle_type" },
		aCustomFilters = {
			["Type"] = { sField = "type" },
		},
		tOptions = {
			bExport = true,
			bID = true,
			bPicture = true,
			bToken = true,
			bCurrency = true,
			bInventory = true,
		},
	["npc"] = { 
		aDataMap = { "npc", "reference.npcs" }, 
		sListDisplayClass = "masterindexitem_id",
		aGMEditButtons = { "button_add_npc_import" },
		aCustom = {
			tWindowMenu = { ["left"] = { "chat_speak" } },
		},
		tOptions = {
			bExport = true,
			bID = true,
			bPicture = true,
			bToken = true,
			bCurrency = true,
			bInventory = true,
		}
}

This seems like a really unnecessary burden to level upon extensions to insure these checks are not short circuited. It seems the code is getting less flexible every update.

I'm actually not even sure how much has been broken due to these checks. Or what will happen if I set these in aRecords now.

[SilentRuin]

I don't know why TEST has added these verifications for records

-- bCurrency = Enables currency can be transferred to this record type. (See ItemManager for default currency paths; or use custom data registration to set different one.)
-- bInventory = Enables items can be transferred to this record type. (See ItemManager for default inventory paths; or use custom data registration to set different one.)


But of course for Extensions (more than one does this) that have inventory tabs added onto NPC/VEHICLE sheets this needlessly breaks them all.

I suppose the only recourse is to now override

aRecords = {
	["vehicle"] = { 
		aDataMap = { "vehicle", "reference.vehicles" }, 
		aGMListButtons = { "button_vehicle_type" },
		aCustomFilters = {
			["Type"] = { sField = "type" },
		},
		tOptions = {
			bExport = true,
			bID = true,
			bPicture = true,
			bToken = true,
			bCurrency = true,
			bInventory = true,
		},
	["npc"] = { 
		aDataMap = { "npc", "reference.npcs" }, 
		sListDisplayClass = "masterindexitem_id",
		aGMEditButtons = { "button_add_npc_import" },
		aCustom = {
			tWindowMenu = { ["left"] = { "chat_speak" } },
		},
		tOptions = {
			bExport = true,
			bID = true,
			bPicture = true,
			bToken = true,
			bCurrency = true,
			bInventory = true,
		}
}

This seems like a really unnecessary burden to level upon extensions to insure these checks are not short circuited. It seems the code is getting less flexible every update.

I'm actually not even sure how much has been broken due to these checks. Or what will happen if I set these in aRecords now.

Not even setting these flags can get this working again. I'll have to rip out and override these new guards as they are unusable. To test I did the following in my onInit()...

	RecordDataManager.setRecordTypeOption("npc", "bInventory", true);
	RecordDataManager.setRecordTypeOption("npc", "bCurrency", true);
	RecordDataManager.setRecordTypeOption("vehicle", "bInventory", true);
	RecordDataManager.setRecordTypeOption("vehicle", "bCurrency", true);

This to get it to skip these checks for these sheets which are processing charsheet's inventory tab... Failed still get the dreaded "Currency support not registered for record type..." every time the inventory currency was copied to (bInventory was not really needed for this stuff so that data transfer still works after previous mentioned bug? was fixed).

So I overrode the following to see why it refuses to recognize bCurrency for npc sheet - just to add some Debug.console() checks:

	CurrencyManager.addActorCurrency = addActorCurrency;

function addActorCurrency(nodeActor, sNewCurrency, nNewCurrency)
	Debug.console(DB.getPath(nodeActor));
	local sRecordType = RecordDataManager.getRecordTypeFromRecordPath(DB.getPath(nodeActor));
	Debug.console(sRecordType);
	Debug.console(RecordDataManager.getRecordTypeOption(sRecordType, "bCurrency"));
	if not ItemManager.doesRecordTypeHaveCurrency(sRecordType) then
...

and see that the results show me

[7/21/2024 10:59:44 AM] s'combattracker.list.id-00028'
[7/21/2024 10:59:44 AM] s''
[7/21/2024 10:59:44 AM] bFALSE


Which of course will never get processed.

Before I'm forced to butcher all this code to make it ignore these checks I'd like to understand why they are being done.

[Moon Wizard]

The code allows records to specify that they support inventory and/or currency via flags on the records; and the ItemManager script was updated to support that behavior.

Regards,
JPG