Possible Fix? Table Results with Output Encounter, but referencing Random Encounters.

[knucklehead]

Okay, so, if that title doesn't make sense. Someone was asking in discord if it was possible to randomly roll and use different encounter generation techniques automatically (like 1d4 zombies encounter, or 1d20 zombies encounter...), and it's not on the face of it (Random Encounters being generators of encounters, not actually encounters themselves...)

So here's the behavior now:

1) Create a "Random Encounter Table" and request an Encounter back:

Attachment 18133

(Brackets weren't initially in there as I wasn't referencing another table, but I tried it because nested tables work like that in the wiki for treasure generation, and I wanted to try it out)

2) Get back a Result that opens up a new random encounter record, instead of having it generate a new encounter and returning that.
Attachment 18134

Could the table to encounter output include a check on the class and handle a random encounter record and call its generate() function to return the encounter window as the result? (Or alternately return a link to the generated encounter in chat results?)


Like, wherever "sendResultToChat" or "openEncounterWindow" functions exist from that table (Yes, I'm totally guessing, lol), is there anything stopping someone from calling generate() on the random encounter record, so it'd look like other table-asking-for-an-encounter results?

Attachment 18135

Attachment 18136

corerpg/campaign/record_encounterrandom.xml and encounterrandom.lua

<template name="battle_button_generate">
	<button_text_sm>
		<anchored to="npcs" width="100">
			<top anchor="bottom" offset="20" />
			<left anchor="center" offset="-50" />
		</anchored>
		<state textres="battle_button_generate" />
		<gmvisibleonly />
		<script>
			function onButtonPress()
				window.generate();
			end
		</script>
	</button_text_sm>
</template>


function generate()
	local sDisplayClass = LibraryData.getRecordDisplayClass("battle");
	local sRootMapping = LibraryData.getRootMapping("battle");
	if ((sRootMapping or "") == "") then
		return;
	end
	
	local nodeTarget = DB.createChild(sRootMapping);
	DB.copyNode(getDatabaseNode(), nodeTarget);
	
	local sTargetNPCList = LibraryData.getCustomData("battle", "npclist") or "npclist";
	for _,nodeNPC in pairs(DB.getChildren(nodeTarget, sTargetNPCList)) do
		local sExpr = DB.getValue(nodeNPC, "expr", "");
		DB.deleteChild(nodeNPC, "expr");
		
		sExpr = sExpr:gsub("$PC", tostring(PartyManager.getPartyCount()));
		
		local nCount = StringManager.evalDiceMathExpression(sExpr);
		DB.setValue(nodeNPC, "count", "number", nCount);
	end
	DB.setValue(nodeTarget, "generated", "number", 1);
	DB.setValue(nodeTarget, "locked", "number", 1);
        
	Interface.openWindow(sDisplayClass, nodeTarget);
end

Trying to give meaningful context without a mile long text box. I get the idea that window.callAFunction() might be a bit simpler than referenceToARecordSomewhere.callAFunction() could make things more difficult, but that's only because I'm still getting my head around scoping in extensions...

Anyway, hope that was somewhat cogent. I'm running about 36 hours straight without sleep and this just happened to keep whirring around my head...

[LordEntrails]

I've been meaning to try generating random numbers of creatures in an encounter. But I think it's much easier than you are indicating. I think all you have to do is drag the desired die into the encounter quantity field and then it becomes 1d4 or whatever goblins etc.

I'll try it out later today to see if it works. Or someone else will jump in and clarify/verify.

[knucklehead]

Well the thing is if you link to an encounter in a table, it pops open the encounter window.

If you link to a random encounter with the "Encounter" as requested output, you get a brand new empty battlerandom window with a brand new random encounter record.

The random encounter linked to is set up properly, and generates random encounters just fine.

The issue is when you're requesting an encounter output from a table, but you're really using a link for a random encounter, because the table didn't actually fetch an encounter. (Edit for clarification.)

/corerpg/scripts/manager_table.lua:

elseif sOutput == "encounter" then
       if not nodeTarget then
		local sRootMapping = LibraryData.getRootMapping("battle");
		nodeTarget = DB.createChild(sRootMapping);
		if nodeTarget then
			DB.setValue(nodeTarget, "name", "string", sResultName);
			Interface.openWindow("battle", nodeTarget);
		else
			sOutput = "";
		end
	end

So I'm guessing since there is no check for sOutput == "encounterrandom" there's no way for it to eventually do an "Interface.openWindow("battlerandom", nodeTarget);

unless there's some way from that context to check the type (battle or battlerandom) which is where I instinctively want to see it, but I'm not sure if that's right at all...

....I just started looking around, so please let me know if I'm going down the wrong rabbit hole...

[knucklehead]

Also noticed when I was plugging away at it:

There's never a time where a table entry pointing at a regular encounter will actually open up the encounter -- it'll create a duplicate and open that.

So even if you have, say, fifteen regular encounters built already, and have them in fifteen entries on the table, it'll generate a new encounter with the same details, and name it with the result string.

I'm not *sure* that's working as intended, or maybe it is. It really looks like the code is supposed to be looking for the entry, and adds a new encounter to the encounters DB only if it's not there already.

For instance:

Roll 1 on a d10, get "My Encounter"

Get a new window, with new db entry named "[RESULT] My Encounter" which.... is a copy of the encounter, but not the encounter itself. Clearly the encounter is being identified because we generated a perfect copy of it.

Thus, if you were in a campaign and rolled up a "Two trolls and a pet Rock" encounter ten times from your table over the course of the adventures, you'd have eleven entries in your "Encounters" section: The original "Two trolls and a pet Rock" along with ten "[RESULT] Two trolls and a pet Rock" encounters.



Of course, I just realized that maybe the point of "Encounter as output" was for another use of tables entirely, and the idea is to generate new encounters through some other use of tables that I don't yet understand. For some reason I thought the point of "output == encounter" is to just automatically open an encounter window when it's selected, rather than dragging it from the chat.

Hmmm...

[Moon Wizard]

The purpose of the alternate output options for tables (Story/Encounter/Parcel) is to generate a new record of that type with the text and links that make sense. (All for Story, NPCs for Encounters, Coin text and items for Parcels)

The standard table output option will share any link that is part of the result with the chat window. If the table roll is public when you do this, then the record is also shared with players so they can click on it.

Regards,
JPG

[knucklehead]

I guess where I'm having trouble is understanding something that is is probably an FG user convention.

As a new user in that situation, I see "Encounter" as an output from tables and I think "Ah, the result will be a an open window to my encounter" and it totally is, but it generates a copy of the encounter, and with n results of that type, I'll get n duplicates in my encounters list. And if I put in a random encounter generator as the result, it doesn't generate a populated record, or even the random generator I created, but just gives me a new blank encounter generator.

I was watching a twitch stream and there was one way, which involved rolling on a table, opening a story panel with a series of instructions for typing in data, then copying and pasting die rolls into a random encounter generator to then generate the encounter.

What I was thinking, though, was if there's a way then, through "table output" to have an encounter or random encounter as a result, and have the actual encounter pop up, or have the encounter generator I linked to generate() (and thus open) a new encounter record that's already populated based on the dice/npc's defined in it.

So the process would be "Roll on a table, get the encounter you pre-built to show up, or generate a new randomized encounter if it's a random battle" and skip all the interstitial typing, cutting, pasting, etc.

Does that make sense? It seems like the code linked above is very, very close to that behavior already, I'm just not sure if I'm articulating well enough. :/

I don't mind trying to plug away at this myself, but it seems to me this functionality might be built in somewhere else already and I'm looking down the wrong path right now.

[knucklehead]

See, where I thought this was possible was through the following 5E screenshot (I initially had it on Output Encounter, which pops open that encounter. I changed it to chat to see the difference. It just adds a chat message with the result and a link you can click on, where Encounter just shows the table result and opens the Result window directly (again, this part meets my expectation as a user stumbling around the interface)

Attachment 18176

Wilderness Encounters lists dice rolls for different entries, but they're really just links to encounters. You'll always get 3 ghouls on the "Ghouls (1d4 +1)" entry because they're not being generated dynamically though a generator, but by linking to an encounter with three ghouls that happens to be named "Ghouls (1d4 +1)"

Additionally, every time I roll on that table I'll be creating duplicate entries that already exist on Wilderness Encounters (Night) in my encounters list, all named "[RESULT] Wilderness Encounters (Night)" even though there's nothing at all to distinguish them in any way from the existing entries.

Maybe that helps explain why I thought there was a way to use a random encounter (battlerandom window I believe) to create a new random encounter, but instead I'm just generating copies of static entries, much like the behavior I experienced in CoreRPG.

I'm pretty sure this random encounter functionality came after the tables were made -- I was just thinking if you've got Encounter output option, and you now have the ability to call on random encounter generate functions, then this would be exactly what I'd expect to happen. And if I'd linked to a static encounter, rather than making many extraneous copies of them, I'd instead open up the window to that particular encounter.

[Trenloe]

@knucklehead - you're correct, the random encounter functionality was added after tables were made. When the random encounter functionality was being developed the ability to have dice strings in the base encounter record was originally tried (in the FG test channel) but there were various issues with this. Hence the separate random encounter -> encounter functionality you see now.

[knucklehead]

@knucklehead - you're correct, the random encounter functionality was added after tables were made. When the random encounter functionality was being developed the ability to have dice strings in the base encounter record was originally tried (in the FG test channel) but there were various issues with this. Hence the separate random encounter -> encounter functionality you see now.

Any reason for the behavior on a linked encounter to be creating an additional entry, though?

It seems if you can test a node type to see if it's a random or regular encounter, then you can move on in to the "encounter" branch with the results of that typecheck (assuming a failure returns nil, or that type checking is even possible beyond "it's a node" or whatever), then either open the encounter window directly, or create a new encounter from the generator.

Is it that there's some other feature/mechanism which currently relies on this functionality of returning a link to chat to manually open, or creating duplicate entries of existing encounters?

All my questions are in earnest, by the way. I really don't quite follow it all...it just seems like the random generator getting functionality exactly like the current "encounter" gets is just kind of, perfect for a random table result, and actually opening up an encounter that already exists would be equally fabulous.

[Moon Wizard]

The table encounter output should generate a new encounter entry containing any NPC links from encounter links or direct NPC links. If you specify a [#x] tag, then a multiple will be added.

If it's working differently, then it's not working as intended, and it would be great to get a good easy example. (Or example campaign zipped up.)

Thanks,
JPG