5E ruleset, TYPE() code question

[celestian]

So tonight I was messing about with TYPE() effects and noticed that it wouldn't work for me when the npc type was set to "goblin" and the TYPE(goblin) was in the effect. It seems that for some reason the getCreatureTypeHelper() code depends on some static arrays. If the "type" isn't in those then it doesn't find it so the TYPE never works.

This is the function that splits up the TYPE() and compares it to the DataCommon.* arrays.

function getCreatureTypeHelper(sTypeCheck, bUseDefaultType)
	local aCheckSplit = StringManager.split(sTypeCheck:lower(), ", %(%)", true);
	
	local aTypeCheck = {};
	local aSubTypeCheck = {};
	
	-- Handle half races
	local nHalfRace = 0;
	for k = 1, #aCheckSplit do
		if aCheckSplit[k]:sub(1, #DataCommon.creaturehalftype) == DataCommon.creaturehalftype then
			aCheckSplit[k] = aCheckSplit[k]:sub(#DataCommon.creaturehalftype + 1);
			nHalfRace = nHalfRace + 1;
		end
	end
	if nHalfRace == 1 then
		if not StringManager.contains (aCheckSplit, DataCommon.creaturehalftypesubrace) then
			table.insert(aCheckSplit, DataCommon.creaturehalftypesubrace);
		end
	end
	
	-- Check each word combo in the creature type string against standard creature types and subtypes
	for k = 1, #aCheckSplit do
		for _,sMainType in ipairs(DataCommon.creaturetype) do
			local aMainTypeSplit = StringManager.split(sMainType, " ", true);
			if #aMainTypeSplit > 0 then
				local bMatch = true;
				for i = 1, #aMainTypeSplit do
					if aMainTypeSplit[i] ~= aCheckSplit[k - 1 + i] then
						bMatch = false;
						break;
					end
				end
				if bMatch then
					table.insert(aTypeCheck, sMainType);
					k = k + (#aMainTypeSplit - 1);
				end
			end
		end
		for _,sSubType in ipairs(DataCommon.creaturesubtype) do
			local aSubTypeSplit = StringManager.split(sSubType, " ", true);
			if #aSubTypeSplit > 0 then
				local bMatch = true;
				for i = 1, #aSubTypeSplit do
					if aSubTypeSplit[i] ~= aCheckSplit[k - 1 + i] then
						bMatch = false;
						break;
					end
				end
				if bMatch then
					table.insert(aSubTypeCheck, sSubType);
					k = k + (#aSubTypeSplit - 1);
				end
			end
		end
	end
	
	-- Make sure we have a default creature type (if requested)
	if bUseDefaultType then
		if #aTypeCheck == 0 then
			table.insert(aTypeCheck, DataCommon.creaturedefaulttype);
		end
	end
	
	-- Combine into a single list
	for _,vSubType in ipairs(aSubTypeCheck) do
		table.insert(aTypeCheck, vSubType);
	end
	
	return aTypeCheck;
end

This is the function I ended up with. BOLD I replaced, italic I commented. Basically I just didn't use the above function.

function isCreatureType(rActor, sTypeCheck)
  -- I dont like having static list of types
  --local aTypeCheck = getCreatureTypeHelper(sTypeCheck, false);
  -- so ... just split on comma
  local aTypeCheck = StringManager.split(sTypeCheck:lower(), ",", true);
	if #aTypeCheck == 0 then
		return false;
	end
	local sType, nodeActor = ActorManager.getTypeAndNode(rActor);
	local sField = "race";
	if sType ~= "pc" then
		sField = "type";
	end
  -- I dont like having static list of types
  --local aTypeActor = getCreatureTypeHelper(DB.getValue(nodeActor, sField, ""), true);
  -- so split on comma and go.
  local sTypeString = DB.getValue(nodeActor, sField, "")
  local aTypeActor = StringManager.split(sTypeString:lower(), ",", true);
  
	local bReturn = false;
	for kCheck,vCheck in ipairs(aTypeCheck) do
		if StringManager.contains(aTypeActor, vCheck) then
			bReturn = true;
			break;
		end
	end
	return bReturn;
end

It by-passes those static array checks and checks for any TYPE() given with any possible creature TYPE set on an npc. To me it seems infinitely more useful to have it work for whatever the DM decides to set for a type because not using the arrays doesn't break it if it's never needed far as I can tell.

So, I know you guys did this for a reason and I'm curious, why?

[Ken L]

IIRC it does this for most "types" in the data_common be they damage (fire,cold,electricity), conditions (stunned, intoxicated, cursed), etc.. It's a validity checker so it makes sense to filter out non-valid entries.

Adding additional types to the data_common isn't a huge deal, but if it's removed then anything under the sun can be considered a type, including typos.

[celestian]

IIRC it does this for most "types" in the data_common be they damage (fire,cold,electricity), conditions (stunned, intoxicated, cursed), etc.. It's a validity checker so it makes sense to filter out non-valid entries.

Adding additional types to the data_common isn't a huge deal, but if it's removed then anything under the sun can be considered a type, including typos.

It's not a big deal for someone like us to add/change it but if a DM just happens to make up a new races/type of creatures... it's a non-trivial thing for most people I would imagine.

I can sorta see why they would want to have arrays for weapon/power damage types but still, NPC types aren't used for anything other than... effect TYPE() that I know of. As a filter, again, I don't see the win. If it's a typo (the effect string) it won't match regardless. If the value is a typo on the NPC it won't match the effect string.

It just seems overly complex (and restrictive) for comparing with npc.type. I'm wondering if this is something that's still hanging around due to some previous ruleset requirement.

[Moon Wizard]

Technically, the goblin sub-type is "goblinoid", which several creatures in the MM fit into.

It's because the Type field is a freeform string field that can be stuffed with any text. By limiting, it defines clear support for the various valid NPC creature types.

Also, it is a bit of code maintenance, since it is maintained in step with Pathfinder code in which the Type field is stuffed with lots of other information (alignment, size, etc.)

Plus, I've found that third party content creators can sometimes get creative with where data is placed.

Cheers,
JPG

[celestian]

Also, it is a bit of code maintenance, since it is maintained in step with Pathfinder code in which the Type field is stuffed with lots of other information (alignment, size, etc.)

Okay, that explains it

I wish I could figure out a decent branching repository tool that allowed for variances in specific files that didn't require a lot of fiddling to work with.