More than 144?

I have a question, Let's suppose I have created functions like CreateArray(size) , SetArrayInt(arrayid,index,value) and GetArrayInt(arrayid,index) . Well the question is:
Would you ever need to use a dynamic array with a size bigger than 144 when making things for your map?

By dynamic array u mean something like a collection object? If so then I'd be using a lot of those, but each one would be smaller than 144 indexes, why do u ask?

Mostly because I noticed that making the limit quite small like that makes things better but if there are good uses for more than 144 then I should use a better limit

Of any given type, I don't feel I've ever, EVER used more than 144.
There's only one instance I have, and it was for use with assistance timers for the assistance system in my map.

Aside from that, I think 144 is a very reasonable upper limit.
If you're that concerned though, might you just add an option to increase the limit at the user's own risk?

144 is fine as long as you can have plenty of different arrays

Is not my developement but usefull

http://xgm.ru/forum/attachment.php?attachmentid=7161

Following copyright i give original link, forum is russian but map have eng readme

The limit of the number of arrays is , well infinite. Of course the computer's ram memory should influence it . Maybe also the actual limit of integers.

But well if you use a lot of arrays, the arrays created later will use gamecache and then be as slow as gamecache

And how many would u have to use in order to get to gamecache? Also, how would u make the first ones?

I heard about russians making alternatives to gamecache a while ago. But that system is bad -) , Well it is really good but it is not really dynamic. Mine is the result of ideas of pipedream , peppar and me, combining locations, arrays and gamecache. It requires only 2 global arrays instead of 32 like the "super buffer" and should have the same usability.




I am guessing that map is kind of old what makes me wonder why is that the Russian modding community hardly shares. The full screen inventory wouldn't have came out of Russia if it wasn't for an unofficial poster that uploaded it to wc3sear.ch ...

I think I should use hex in comparissions as well. It looks cool

It is awfully simple actually : http://www.wc3campaigns.net/showthread.php?t=85135

I have the final code at home it is going to be really useful and will be released in the new version of CSCache.

I think the multiple array is a good way to expand the space. Rather than serially though do it in parallel, such that each slot is a union over all possible objects. If all your objects are size 1-10 this is fairly practical. Most people could probably get away with an atomic allocator with this strategy, and it lets you use arrays of say unit type, so you can avoid a slow return bug. When you need something object like(GetObjectX(obj)) rather than array like(GetObject(obj,X)), it's a good way to fly.
Eventually someone will write an OO compiler to automate this with a sexy syntax.

Reminded me that I have to post about a project of mine in the editing tools forum, err maybe it is better to keep stuff here.

Lemme just see if I got this right:
You're using locations to form a double-linked list and storing their adresses in global variables, and getting all the regular functionality out of them a lot faster than gamecache.
If so, then awesome! But why a limit of 144 indexes? Some special reason or?

More likelly 144 is # 10 in the fibonacci number list. I am using the fibonacci sequence but not really in the same way as pipedream.