The cobb::lowerstring class may be broken. I ran into problems with it when reusing it in the Outfit System and ended up having to rewrite my UTF8 code. We should backport that rewrite to CobbAPI.

Here's the SkyOutSys repo at this point in time: link. We copied over the Papyrus functions for sorting an array of strings, and sorting a pair of strings+forms (we still have that function templated under the hood).

If I use this assembly in LoadMoreEditorIDs.cpp, then it should be possible for multiple DLLs to hook the editor ID setter on the same form types, provided all such DLLs use the same approach.

_asm {
   mov  eax, dword ptr [esp + 0x4];
   push eax; // protect
   push ecx; // protect
   push eax;
   push ecx;
   call Inner; // stdcall; pops its args for us
   pop  ecx; // restore
   pop  eax; // restore
   mov  dword ptr [esp + 0x4], eax; // set up tail call
   //
   // tail call to original function:
   //
   jmp  THE_ORIGINAL_FUNCTION_WHICH_I_HAVE_STORED_SOMEHOW;
}```

I want to see if I have this straight . . . I'm looking at CobbAPIBatchMoveGroup/Rel and CobbAPIBatchSpawnComplex

The descriptions start with the word "Move". Does this mean that the entities/objrefs must already exist in the cell, or are they spawned in as new?

CobbAPIBatchSpawnComplex says:

This Papyrus class allows you to group spawns into buckets called "sets."

Am I to understand that that a "set" of objrefs could be defined, then the "task" object would spawn them in, in a group, and potentially several sets in a batch?

Here's a smidge of backstory: Back a million years ago, there was a util for Half Life called "Rand Map". You could build a "theme" for Rand Map consisting of prebuilt geometry... rooms, halls, etc. Rand Map would then take your prebuilt geometry, and shuffle it together to create a completely randomized map. This was insanely fun to work with because of the quick turnaround from design to play.

I've been dreaming for years about such a thing for Skyrim... where I could build a bunch of prefab rooms/halls/sections, and then have the game completely randomize the contents of a cell to play.

I'm "ok" with papyrus (better with javascript/react 😁), and i'm "decent" with map design, but never had any idea until now that it was even remotely possible using papyrus or even skse

So, my question is this:
I know there would need to be more to it, but I'm talking conceptually. . . Based on what I've described above, does it sound feasible to be able to design the shapes and bounds of room-like spaces, and then use your API here to use those prebuilt spaces to create randomized levels?

Either way, thanks for writing this tool.

Sorry, this seems to be the only way to add a comment to a line outside of a commit/pull request.

FormIds stored in pointer fields during the TESForm::LoadForm() phase are resolved in the TESForm::InitItem() phase (referred to as TESForm::Link() in the xSE source). The member function is usually a couple of offsets below LoadForm(). At least, that's how it used to be in Oblivion.