This following code has been tested and works in any game you put it in. What it does is create a cache of the person list in JS and only ever updates it when an entity dies, or gets created.



How to use:
Just copy and paste it somewhere in your code and the overrides do the rest.

So does this basically fix any crashes in more recent Sphere versions? Radnen, you're wonderful.

Also, nice way to make sure it still returns just the list of people, and not also the extra properties you've given it.

So does this basically fix any crashes in more recent Sphere versions? Radnen, you're wonderful.

Yes, I had to use a version of this in my LD game since I used the person list frequently. I tested calling the list each frame and it crashes in 6 seconds, with this fix it never crashed at all.

Stickied. Fixes like this that work are important and IMO the cornerstone of what should constitute an official system script for Sphere.

I'm fully in support of adding a system script strictly for in-code fixes, even more so if the fixes are also backwards compatible w/Sphere versions between 1.0 and 1.5.

Have you considered using an IIFE to avoid polluting the global namespace?

Something like this...



This seems cleaner to me as it properly encapsulates the flag and cached person list. It also passes the original implementations of each function to get free renaming. (I renamed 'updated' to 'dirty' also as it fits the use better. Having 'updated' as true when it actually means the list *needs* updating rather than has already been updated seemed backwards)

Obviously, I hadn't considered IIFE even though it's a design pattern I use frequently (check out analogue.js). But at least your version is here for those interested to look at.

Stickied. Fixes like this that work are important and IMO the cornerstone of what should constitute an official system script for Sphere.

That's... debatable in this case. Wouldn't it be better to fix the bug at the source?  In my opinion, system scripts should be for value-added features (menu systems, cutscene managers, etc.), not hacks to work around engine bugs.

That's... debatable in this case. Wouldn't it be better to fix the bug at the source?  In my opinion, system scripts should be for value-added features (menu systems, cutscene managers, etc.), not hacks to work around engine bugs.

Well, it would be helpful for games that relied on a certain version of Sphere. GetPersonList() was also slow to use too and this method is indeed faster, it can even crash on non-1.6 sphere, but happens less frequently (More stable? More JS memory? Quicker GC's?). Whatever the issue, having a single system script with 'hacks' is not so bad for an ill-updated legacy engine.

I mean this code really isn't deployable in Sphere-SFML since issues like these are already fixed.

GetPersonList is such trivial functionality, you wouldn't expect something like that to be able to take down the whole engine.  I wonder what causes the crashes... are the strings being garbage-collected prematurely or something?

For maps with quite a few entities, I think it recreates a new list each time rather than return one from the background. I still don't understand the crashing unless the JS memory is eaten up (well it only does this crashing if called frequently).

If there is really something wrong with GetPersonList, might it be worth replacing it altogether and maintaining a separate list to avoid any calls at all?

Edit: I've just realised that persons on maps would break this. Never mind!

Well, I did have CreatePerson and DestroyPerson just add/remove from the internal list, but that was in fact slower than reconstructing the list.