When using the NPC LLM, can the interaction response struct be persisted across sessions? Is this built in, or would you need to use verse persistence?
I am thinking the latter may be possible, but the data types might not be able to be saved, and I am unsure how I would then apply that to the llm in a new session.
I’m basically looking for a way for the conversation to continue across sessions. Thank you!
Not built in. The NPC LLM interaction response is a device result for the current session, and nothing in that device writes it to the island’s save data. A new session starts with an empty conversation unless you store the text yourself. Verse persistence is the right tool, but not by saving that struct.
The response struct is an engine type. Persistence only keeps values in your own persistable module: logic, int, float, string, enums, arrays, maps, option, and classes or structs you mark persistable whose fields are all persistable. It will not keep a creative device, an agent, or a device struct that contains those. If you put the interaction response itself into a weak_map it will fail to compile or fail to save. Copy out the strings you actually need, the player line and the NPC reply.
A player-scoped log looks like this:
persistable_chat := class:
Lines : string = array{}
var PlayerChats : weak_map(player, persistable_chat) = map{}
SaveLine(P : player, Line : string):void =
if (Chat := PlayerChats[P]):
set Chat.Lines = Chat.Lines + array{Line}
else:
Fresh := persistable_chat{Lines := array{Line}}
if (set PlayerChats[P] = Fresh) {}
Call SaveLine with the player text and with the reply text after each exchange. On the next session, PlayerChats[P] is still there for that player.
Feeding it back is the part the device does not do for you. Take the last few saved lines, make a short recap string, and send that as part of the next utterance you submit (or write it into the instruction / context text if the device instance you are using exposes one you can set from Verse). If the only input is the current player message, prefix that message with the recap so the model sees the history. Keep the stored log short. Persistence has a size budget, and a raw transcript of every session will eventually be too big, so store a rolling summary plus the last handful of lines rather than the entire response struct.