[Papyrus] Script array limitation?

[jags78]

Hi Guys and Gals

 

I heard something along the line that formlists have a 128 forms limitation... Does that apply to script arrays to? Is for example an Entry[] or an Int[] limited to 128 entries? And is it a fact that formlists have that limitation?

 

Thanks in advanced for the reply.

 

Greetings

 

jags78

[deadbeeftffn]

All arrays are limited to 128 entries. Though, there is an exception: There are few functions returning arrays with more than 128 entries. So, you must be prepared to handle larger arrays...

[SKKmods]

Formlists do not have a 128 limit, I have used them with over 1,000 entries (forms and object references).

 

ReferenceCollectionAliases are also unlimited, well I have used them up to 10,000 object reference entries.

Edited June 8, 2019 by SKK50

[ElPolloAzul]

Yep, FormLists and the like are probably a good solution for you. I've specified them in-editor past any theorized 128 element limit for sure. The issue presumably comes in when you need dynamically allocable lists (not just pre-created lists) of dynamic size within a script.

 

For that, I've detailed my highly circuitous approach to that in a recent post:

https://forums.nexusmods.com/index.php?/topic/7683768-tracking-container-contents/

[jags78]

Dang it !! No multi-dimensional arrays and a limit of 128 entries... what where they thinking! I'm working with an Entry[] in one of my mods and I was afraid that there would be some kind of problem sooner or later when trying to expend it.

 

Formlists and ReferenceCollectionAliases aren't the solution, I would have to change the core-script fundamentally. I'll have to find a way to script around that limitation.

 

Thank anyways guys.

[niston]

Yeah, it's pretty bleak, isn't it.

 

I tried to hack my way out of the situation using a FormList in the post that ElPolloAzul linked, only to hit another wall behind the wall.

 

Here's some hoping: Does anybody know if the 128 elements limit is enforced by the papyrus compiler, or is indeed an engine/VM limit? If the former, does caprica enforce it?

 

But in the end, I guess EPA's idea of having what amounts to a linked list is probably the only remedy. Too bad there are no generics in papyrus, either!

 

 

NB: As I understood, the limit only applies to arrays declared/elements added by script; Arrays returned by the game can and sometimes will have in excess of 128 entries. Also I think F4SE has some functions to create arrays of arbitrary size.

[ElPolloAzul]

 

But in the end, I guess EPA's idea of having what amounts to a linked list is probably the only remedy. Too bad there are no generics in papyrus, either!

 

Yeah, that makes things less convenient, but luckily you can still put elements of variant type into the array. In your list segment data structure class, you can have this:

var[] Property raw_array Auto

If there were no var arrays legal in Papyrus, there would have been no way to expose nearly all Papyrus functions to an in-game programmer using CallFunction.

 

You can either grab the objects out as you go and fetch the type with a chain of is statements (probably pretty expensive), or if the list is carrying things of homogeneous type, you can embed some logic into the "constructor" which does this once and then sets a type int or string field or similar which tags the array's type. Concept if not implementation overall is kinda like a tagged union. Fortunately, most of the "indispensability" of generics comes about when you are doing usually-horrid things like having nested generics (we've all committed some atrocities for fun).

 

I wouldn't recommend it, but for stupid fun there are two very dumb remedies potentially feasible if you are committed to merely a constant total capacity that just happens to be larger than 128. You could make an extended/jumbo array class that holds a few hardcoded arrays (Scriptname UtilityJunk:MondoArray extends ObjectReference) and provide your own functions for doing things (as you would have to with the linked list approach, using mod to find the correct raw array index), or (oh, far worse) you could use two global collections of FormList etc. type (one heap list contains all extended list objects ever, and the other header list contains the ranges of "lists" in that list, and each user maintains a id to the "list" they want to use -- like a handle vs. a smart pointer reference system).

 

Linked array lists aren't that bad to implement, even in this less-than-ideal environment, and if I had lots of time to write and debug and was confident that native Papyrus would continue to be useful, I guess I would probably have rolled up a library of all the common ADTs (graphs, trees, stacks, queues, priority queues, deques, maps, sets) as a modder's resource. For my own stuff, the maps I just used with sequential search because I had very few keys although it would have been pretty trivial to set up a hashmap for performance. As a community project, there could be a lot of potential for testing and visually benchmarking design choices in such a library.

Edited June 9, 2019 by ElPolloAzul

[Evangela]

Dang it !! No multi-dimensional arrays and a limit of 128 entries... what where they thinking! I'm working with an Entry[] in one of my mods and I was afraid that there would be some kind of problem sooner or later when trying to expend it.

 

Formlists and ReferenceCollectionAliases aren't the solution, I would have to change the core-script fundamentally. I'll have to find a way to script around that limitation.

 

Thank anyways guys.

Papyrus was created from C++. If you know C++, then you know right away that Papyrus is just a stripped down, mangled version of C++. Classes are called objects. Namespaces are just folders(lol), no array of an array of an array :tongue:. No for, do while, for each loops. No switch, no case. No break, no continue. Just While. It's crap like that, which led to script extenders/DLL plugins. Also the structs aren't exactly structs. I don't know what those are supposed to be actually.

Edited June 9, 2019 by Rasikko

[jags78]

This kept me awake a while last night. I think I'll go back to the drawing-board and go for Formlists.

 

A purely scripted approach sounds like a fun challenge... but not for now.

 

Must be at least 15 years since I last coded something in C++. 15 years!! Damn I'm getting old :D... All the missing functions aren't what pain me since you could code them yourself and pop them into a "library" or work with what papyrus deliveres. The limitation is what pains me since I didn't know about it before making the concept for my mod.

 

Oh well... Makes no sense complaining now. Thanks to everybody for the exchange.

[Carreau]

I don't know if linked lists are really feasible. Papyrus has no implementation for pointers, so that's a problem with linked list implementation.

 

Also, adding a struct to a struct is forbidden, so you can't directly implement.

 

I attempted to add a struct to a struct and the compiler returned

 

"D:\Steam\steamapps\common\Fallout 4\Papyrus Compiler\TestStruct.psc(6,9): struct variables cannot be structs themselves
No output generated for TestStruct.psc, compilation failed."

 

Where my struct was defined

 

Struct TestOne
int index
string name
testOne nextStruct
EndStruct

 

There are ways to cheese multidimensional arrays using formlists. https://www.creationkit.com/index.php?title=Arrays_(Papyrus) About halfway down, there's a discussion about ways to effectively create multidimensional arrays. My concern here is that they use activators to spawn instances of arrays. Given how the game cleans up activators, I don't know what the long term sustainability of this method would be.

 

I was hoping it would be possible to make a formlist of structs, but that is throwing compiler errors as well

 

D:\Steam\steamapps\common\Fallout 4\Papyrus Compiler\TestStruct.psc(19,19): type mismatch on parameter 1 - cannot pass a teststruct#testone to a form

 

In this case, I'm trying to use AddForm on a formlist property to add a struct. So no dice in that front.