What exactly do you want to do? You haven't pointed out the goal of all this but from my perspective this approach seems a bit strange. There's probably a better way of doing this.

It is impossible for Gamestudio to allocate this much memory because Gamestudio is a 32 Bit application. On Windows a 32 Bit application can allocate just about 1.5 GB. This means that Acknex's limit is also at about 1.5 GB.

sys_malloc will return NULL if it can't allocate the memory. Your mega_nodes pointer is a NULL-pointer. Using it as usual will crash your game. Check every time before using a pointer which can be a NULL-pointer if it is pointing to NULL. When it's not, then you can use it, but not before checking.

The nexus is memory for your level. When you create a level in WED and load it via level_load, then your level needs memory for textures and blocks and so on. Gamestudio allocates a memory area on the heap and calls this area nexus. This speeds up playing the level because everything needed is already stored inside the nexus when you start your level. After that loading is done Gamestudio doesn't need to load more data from your hard drive which saves time and lowers the risk of running out of memory while playing. If you don't work with level_load you will have nothing to do with the nexus.

When you access an array the last slot is at the position 'arraysize - 1' because the first slot is at position 0. The second slot is at position 1, the third slot is at position 2, ... and the last slot is at the position which equals 'arraysize - 1'. If you try to access a slot at a later position you will produce an error because you're outside the bounds of the array.

Hey everyone! See if you can bear with me:

The reason for all this is because, I am porting an old A* code from George's AUM all the way from A6. In the script, it uses a big array to store path information, its a big array that should be big enough to hold Max_nodes*Max_nodes. So since a Var array cannot exceed 999999 slots, the maximum amount of nodes I can have in the level is roughly 999, since 999*999 = 998,001.(in a test level, I kept the max nodes to be around 980 just because). My test AI pathers can run around this huge level perfectly fine (aside from adding local avoidance). I am a little hesitant to move to a different pathfinding code just yet, because I know this one already, and I can get it working if I keep the node count under that limit, and I am perfectly fine with that. I can just increase the range at which nodes can connect to each other, as well as be stingy within reason when placing nodes in the level. (I have downloaded Superku's pathfinding, and I will be trying that in a new project when I get to that point as well.)

But I want to see how far I can potentially go with this current pathfinding, mainly in how many nodes I can push. At one point, I was able to have 1600 nodes, and have the AI's run around correctly as well! But the problems here was that:

1. Path calculation for 1600 nodes took a long time, so I was looking into ways to save paths for each level beforehand. (I have found a way to do this using game_save with SV_info, and with array names ending with _i. Using memcpy seen in another thread, I was able to copy the saved array into the working array. But this also got me thinking about how data types are stored and read)

2. I wasnt using sys_malloc, and if I wanted to save the game, I ran out of memory!

3. The code would crash randomly at the start, and at times it would crash and give me seemingly random errors in unrelated functions, which meant memory wasnt being managed right.

So thats why Im looking to see how big an array I can get, which will let me know how many nodes I could feasibly attain. If I can correctly allocate a big array, as well as be able to find any position in it using the multidimensional maths, I could then see if I can add more nodes.

It may not be feasible to have 4000 nodes in your level for a finished commercial game, because you have GUI, graphics, animation, physics, sound, music, input, collision detection, all competing. But if Im doing foundational stuff, I would like to try to see how far I can get it now, and when I have the worst case scenario running correctly, I can worry about pulling back when it comes time to make an actual level.

Is this for your sword fighting game? Steering behaviors for ai characters is a much better choice for huge outdoor levels than pathfinding which is better suited for tight corridors and labyrinths. And steering behaviors are calculated very fast. Maybe pathfinding is the wrong technique here.

Hey Ezzett! Yes its for my sword fighting game! My game will have a mix of both corridors as well as wide open areas, but im leaning towards smaller tighter arena places.

Is steering behavior the technique to fill the whole walkable area with "force" directions? Pushing entities towards their goal?

Steering behaviors work by giving an entity a goal (a position in your map) an tell the entity what to do with this goal (walking over to the goal, running away, pursuing a moving goal, velocity matching and so on). You do this by giving your entity a velocity or acceleration. You can add collision avoidance so that entities run around objects while getting to their goal. Of course, this will not work for tight or complex geometry, here you need pathfinding. But you can combine entities to groups and create coordinated movements and it will look really complex and "intelligent" while being fast to compute and not so hard to implement, depending on your programming knowledge.

I read about this topic in the book 'Artificial Intelligence for Games' by Ian Millington. In the book he uses high level pseudo code, but he offers source code for many (not all) techniques on www.ai4g.com. For example, if you look at the code for some steering behaviors at https://github.com/idmillington/aicore/blob/master/src/steering.cpp
you'll see that each steering behaviors consist of just a few lines of code.

https://www.youtube.com/watch?v=PJCSvRh9ljI