Quote:

It should be possible to transfer all the entities' handles to a bunch of arrays or something similar?


Quoted Gorthaur.
If I were trying to enable support for the game_load and game_save instructions, I probably wouldn't choose 'array final destinations' for the handle values, instead, assuming I can access the 'true handle' values, I would probably try to write the handle values to file.
Quote:

Then when you load, reinstate all the eLLs and handles to do with them. Downsides:


Quote:

very lengthy operation,


I don't know what is really meant by 'very lengthy operation' here, but for some interpretations, generally, it wouldn't seem to be to me.
Quote:

tricky to code,


Assuming the 'true handle values' can be accessed, simply dumping the handle values to file, retrieving them again and recreating the lists might almost be trival, but it probably isn't practical to do so from C-Script because there may be no access to the 'true handle values'.
User proofing might be 'tricky' or impossible.
Without some knowledge pertaining to the behavior of the game_load and game_save instructions and how the user might use those instructions and still 'maintain sync', the almost trival parts might be irrelevant and real working functionality might be damned.
Quote:

probably increase the save/load time by a lot, etc.


Maybe not.

Quote:

testDummy: What I meant was pretty much what you have here, but instead of storing entities, it stores variables. I was going to have a crack at modifying the source myself, but the first line lost me I'm not a C++ programmer

I'm trying to create a neural network with 3DGS, and I want the network to store the values of its nodes and weights internally - rather than using a fixed-size global array. For this I need an array bigger than 3 vars long. If I instead give it a pointer to a dynamically allocated array, my problem is solved.


Quoted Gorthaur.
(In such cases, you would probably want to reuse memory and not grab large, temporary chunks and needlessly throw those large chunks away often.)
If I were going to write something for that or for similar things, I might write a separate plugin. Although it's use might be relatively awkward, writing a plugin that just handles dynamic arrays of variables somewhat, probably wouldn't prove to be all that difficult. Maybe I'll try to write such a plugin in the near future (certainly I would trade such a plugin for a full and complete understanding of neural networks), but, in the meantime, I might suggest that you make a request thread in the "User Requests" thread category. Certainly, such a plugin might be 'easy work' for many.

Quote:

Testdummy, I'm not sure wether or not there were any significant changes concerning plug-in 'support' in the most recently released update, however aware of the possibility that this dll may not work with A6.50.2 would you be so kind as to recompile this dll so it's functional with A6.50.2? That would be cool,


Quoted PHeMoX.

I'm sorry, but I am under the impression that 3DGS version 6.50.2 is not, in fact, an official update, but is instead a (very buggy?) public beta and, at this time, I do not intend to work with that version (currently waiting for more stability and permanence) and I do not intend to compile plugins for something so mutable. However, for the most part, I do intend to compile plugins for future official updates. In this instance, I do not necessarily want to be 'unhelpful', so I may very well provide a sample testing device (set of scripts, level, etc.) so that eLL functionality can be more easily tested by others, so that it is not all that difficult for users to quicky determine whether or not the plugin works for them, with the 3DGS version they are using.

edit: At this time, I'm not going to download and install the complete 3DGS (public beta?) version 6.50.2 just to recompile the eLL plugin. However, assuming that the (6.50 SDK?) has changed , you may provide a link to download the SDK only (assuming that there are no license violations in doing so), and I may recompile the eLL plugin using that SDK, but if I do so, it will not be tested with version 6.50.2 of the engine by me.