MrMarx

For dynamic npcs, one can start with a basic conversation to familiarized with the script engine and then develop until LLM conversations I guess. I'll share some ideas and then resources I have been noticing from some RO developers. - First, familiarize on the mes, npctalk commands. Script commands documentation covers most of it. - Then, Hercules codebase shares many examples and uitilies. One I recommend is doc/sample/npc_test_pcre.txt. Check the subfolder for more, then the npc/ folder for many other examples. Searching for key terms or *script_functions one is interested in could be a thing. - If more development is needed, plugin system covers most. Studying the examples plugins and perhaps some other open source shared repositories could provide many insights on how it works. Querying the db may be possible but take note on the observation from KirieZ - After familizaring with the plugin system, possibily using a Python, Go or whatever hook on it and connection with favorite LLM implementation may be possible. How secure, performant or gameplay satisfactory and others may vary by developer. Check those two links https://www.reddit.com/r/RagnarokOnline/s/xpYwY2ZOCq https://github.com/lenaxia For an implementation with players. Tweaking it for NPCs may be possible. Some other good developers repositories, for reference: https://annieruru.blogspot.com/2019/01/scripting-guides.html?m=1 https://github.com/dastgirp/HPM-Plugins

First, about npc directions *setnpcdir({<name>, }<direction>) Set npc direction. If npc name missing, will be used attached npc. Example: setnpcdir(DIR_WEST); or *movenpc("<NPC name>", <x>, <y>{, <dir>}) This command looks like the npcwalktoxy function, but is a little different. While npcwalktoxy just makes the NPC 'walk' to the coordinates given (which sometimes gives problems if the path isn't a straight line without objects), this command just moves the NPC. It basically warps out and in on the current and given spot. Direction can be used to change the NPC's facing direction. Example: // This will move Bugga from to the coordinates 100,20 (if those // coordinates are legit). movenpc("Bugga", 100, 20); One will probably need to decide what direction npc should be facing. If thats the last invoking npc direction, fetching the coordinates and deciding by math on coordinates or other way how to do it.

Think the closest to have for now is saving the relevant information you want in instance creation. *instance_create("<instance_name>", <owner_id>{, <owner_type>}) Creates an instance using the name "<instance_name>" for the <owner_id> of <owner_type> (when not provided, defaults to IOT_PARTY). Most instance_* commands are used in conjunction with this command and depend on the ID this command returns. Valid <owner_type> values: - IOT_NONE (0) - <owner_id> can be any arbitrary number. - IOT_CHAR (1) - <owner_id> is account ID. - IOT_PARTY (2) - <owner_id> is party ID. - IOT_GUILD (3) - <owner_id> is guild ID. Example: // Store the Party ID of the invoking character. .@party_id = getcharid(CHAR_ID_PARTY); // Attempt to create an instance using that party ID. .@id = instance_create("Endless Tower", .@party_id); if (.@id == -1) { // Invalid type - not used anymore // ... } else if (.@id == -2) { // Invalid Party ID // ... } else if (.@id == -4) { // Already exists // ... } else if (.@id < 0) { // Unspecified error while queuing instance. // ... } The alternative would be to change the way instance is handled in source code, or implement a plugin to fetch instance info similar on how rAthena does and uses on that script. From what I understood, you want to retrieve the instance level mode by supplying the instance owner id?

The supplied data/luafiles514/lua files/skillinfoz/skilltreeview.lub, or file similar for your client version, may contain mistakes. Confirm if the tree view has the proper syntax and skills entries are following the rules. Else, I would say to check if jobinheritlist.lub is correct.

*savepoint("<map name>", <x>, <y>) This command saves where the invoking character will return to upon 'return to save point', if dead or in some other cases. The two versions are equivalent. Map name, X coordinate and Y coordinate should be perfectly obvious. This ignores any and all map flags, and can make a character respawn where no teleportation is otherwise possible. savepoint("place", 350, 75); By using savepoint on the script, one can set up a logic of having the spawn point being map 'A' during a session of the event, and having a trigger to change it to map 'B' if another event happened. Can tweak it to your use case, for example setting Prontera as savepoint once landing or being warped to the pvp map.

I use the following: function script funCopyInstanceMaps { // Given instance name, and a reference to an Array, // copy the array of maps to this new array. .@instance_name$ = getarg(0); .@which_maps$ = "$@maps_this_run_" + .@instance_name$ + "$"; .@map_count = getarraysize(getd(.@which_maps$)); copyarray(getarg(1), getd(.@which_maps$), .@map_count); return; } Should be similar to your case. Usage of copyarray is documented in the script_commands.txt and there are examples on samples folder. Should work in your case with some tweaking for your situation, I suppose? Can have guard clauses on the amount of data to copy if desired. I have getarg(1) as argument on copyarray because this is the variable I want to store the copy of the array by using getd on variable I'm obtaining dynamically on the string written in .@which_maps$.