Hi friends

I have a A* path calculation in the beginning of my level to compute pathfinding paths. George's AUM back in the day made a TXT file that was loaded to speed up the level loading.

Is there a way to save the contents of an array into a WRS file, and then copy this array into another? I can do the mem_copy stuff i think, But how do I save a big array into a seperate file, that cant be opened like a TXT file?

Just save and read it in binary mode?

Sorry, I've never heard of binary mode, What is that?

You write the bytes from the array byte by byte to a file.
For reading you do the exact same thing again vice versa, no need to use any kind of encoding or whatnot.

what kind of file can I write to?

Any. Binary files are an obscure Windows concept which doesn't exist on virtually any other OS (as in, all files are binary, cause that's what they are!).

In any case, there is no such thing as a file type. You can write jpeg data into a word file, because files are just binary data on disk. Windows tries really really hard to tell you that file types are a thing via extensions, but again, you can write binary data in a .txt file just fine. Obviously, users might expect certain conventions, eg that txt files contain readable text and not random binary nonsense. But who cares, it's not like anyone is going to drag you in front of the file system court.

I.....did not know that. Well I knew, but I didn't know you could just save it out like that in gamestudio. So I made up an extension and saved it out, and was able to open and read it

So I could also bind these in a wrs, so they aren't seperate files correct?

Thank you wretchedsid!!!!

Yeah you can manually bind to wrs through;
#define PRAGMA_BIND "blabla.txt";

Maybe you dont even have to do that, if use you it specifically in your script.

The only thing you have to take into account is that 'txt' files are not binded into resource files. I don't nknow why but they have to be renamed if I am not wrong.

Go to
GStudio8 -> data -> options.scr,
open it with a text editor, find
EXCLUDE_RESOURCE = "WRS;TMP;AVI;MPG;MOV;DLL;C;H;XML;LOG;TXT;PNG"
and remove
TXT
to include txt files in the WRS as well. Reason for this default setting probably is that you cannot use file_open_read on txt files which are contained in the WRS. You either have to extract them first (file_copy or what it's called) or (probably better) use file_load.

, for me personally this is already correct (maybe I changed it earlier or cause of new version, cannot remember). Also kindy funny that you can remove wrs from it, so you can have wrs files within your wrs files.

Hi friends.

A small update. I was having alot of trouble when it came to pathfinding and reading values from an array. When the level computes the paths in the beginning and fills the array, the AI's move normally But when I saved out this same array to a txt file, thats where things got bad. (I wanted to save to TXT to save from having to compute the A* every time the level is loaded)

When my AI's were using the array that was filled from a TXT file, they glitched out and gave me a bunch of errors I've been wracking my brain trying to figure out. Tried alot of different things and still couldnt get it to work. Making sure it was filling the correct values, looking at huge notepads with too many numbers, seeing if the index was off etc etc

But then I tried game_save! with SV_INFO as the flag, and then renaming this big path array with an _i at the end, I was able to load the saved array into the level using memcpy, without having to reload the level.

I will do more testing, but here is pseudo code of what I plan to do:

main()

1.find the level_name of the level
2.see if there is a saved Node.sav that matches the level name
3.if there is a save file that exists, that means the paths were computed
4.Load the .sav game then memcpy the path array into the working path array
5.Run level
6.If there is no save file that matches the level name
7.Run path calculation and fill the array
8.Create a save file and save the _i arrays
9.Run level

The initial TXT file was also pretty big. I made a worse case scenario, with an array of 999999, with a 0 in every slot, and this txt file came out to be around 5 megs. But saving these arrays in a .sav, the .sav comes out to be only 461 kilobites! The manual says .savs are compressed

@WretchedSid

Memcopy seems to only work when the array index is under 314. I have no idea why that number, but using memcopy with a huge array works until the array index is over 314. Is this a memory problem?

@jumpman that doesn't sound right, can you show us some code?

Hi wretchedsid:

//----------------These 2 arrays are the "working" arrays
var node_to_node[999999];
var visited[999999];

//----------------These 2 arrays are the ones saved in a .Sav file
var node_2_nodeCopy_i[999999];
var visited_i[999999];

Are you aware of my pathfinding "solution" which does not need to precompute stuff (apart from WED paths) and has some other useful features as well?
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=463551#Post463551

hi Superku!

Can your solution do 3d pathfinding with vertical placement? How many nodes can yours do?

memcpy copies byte wise, var is 4 bytes.
You have to multiply the memcpy size by 4 => sizeof(var) to copy the whole array.

Yes, it can deal with 3D stuff and multiple floors and stairs, as long as you set it up correctly (WED paths and regions - the region system is for bigger levels or when you know enemies won't leave that area - if they are supposed to move between different regions then there cannot be obstacles, think open world for example where regions are placed around houses or villages or forests). The number of nodes is not limited by my code, instead by Gamestudio limits/ max_paths or what that stuff is called (you would probably never hit that limit).
It finds the correct path in linear time so it's fine to use paths with a big number of nodes, however not necessarily the shortest path (in quants). It calculates the shortest path based on the number of nodes instead. Just place some extra nodes on long edges to equalize their "weight" in the pathfinding algorithm (- as a result you can make enemies avoid certain dangerous paths by placing extra nodes there).

Whoever thinks that's not acceptable that the path might not be the shortest 100% of the time... then you're probably not a game dev to begin with, at least not someone who fill finish and release a game. (which I know you are and you do, @jumpman - I got that feedback before though)

Thank you @superku, I have downloaded your demo and I will look at how it works, thank you! Someone has commented that towards you before?

@chaoscoder how do I multiply the "count" ? just multiply that 999999 by 4?

Normally you would use the "sizeof" macro to memcpy (or (sys_)malloc) stuff, like this:

memcpy(node_2_nodeCopy_i,node_to_node,999999*sizeof(var)); //
//wait(1); // is this because of the memcpy above? that's not necessary
memcpy(visited_i,visited,999999*sizeof(var)); //sizeof(var) = 4


Go ahead and please post in the pathfinding thread should you run into any troubles!

that worked superku!!!! Thank you! Originally i did 4*999999, which worked i guess? But I tried the sizeof that you posted and that worked (im assuming better)

Can memcpy be run instantly? I put a wait in there because i thought it needed time to finish a huge array. But I dont need it, why is that?

Both should work, unless you write something like
var count = 999999;
memcpy(..., 4*count); // or sizeof(var) instead of 4
Then, at least I think so, would the calculation be treated as a var result (because of var times integer) and therefore be limited by the var range (or get negative to be more precise, or positive again but at a number way too low).


Don't write random waits into your code, that does more harm than any good. Everything you write gets executed instantly and in order, and the program only continues after the current instruction or calculation has been finished (in a single threaded program like the default acknex engine).
There are (and/ or were) only a few exceptions for which there were reasons or explanations, of course. For example level_load in old acknex versions (like A5, where it was executed not immediately but at the end of the frame => wait(1)), automatic bounding box initialization at the end of the frame for entities created by ent_create (therefore a wait(1) before c_setminmax() on animated models), DirectX initialization at the end of the frame or functions using wait themselves.

In general: Don't use wait unless you really have to, like for default entity loops.

So if a function takes long to execute, the program will slow down or pause until that function completes, then moves to the next instruction?

I have changed the arrays to:

int node_to_node[9999999]; // youll see that this is seven 9's!

The reason why I am trying this is to see how many nodes I can make, and how big the paths can get. This int works when my AIs are running around, after the level computes and fills this big array.

But saving the int Array and loading the int Array is where im running into problems again:

memcpy(node_2_nodeCopy_i,node_to_node,9999999); //saving

-------------

memcpy(node_to_node,node_2_nodeCopy_i,9999999); // loading


Do I need to add sizeof() again here? I tried 9999999*4, 9999999*sizeof(int), 9999999*sizeof(var), but none of these copy over correctly. What did I do wrong here?

what does: int node_to_node[9999999]; do?

Does it create 9999999 different slots that each store regular VAR? Or does it create that many slots with 9999999 integers?

Try memcpy(node_to_node,node_2_nodeCopy_i,sizeof(node_to_node));

int node_to_node[9999999]; creates an uninitialized array of 9999999 integers.

You can create as many nodes as you like until your stack is full which will crash your game.

When a function was started the program will only jump to the following function/instruction after the current function is completely done, that's correct. If your function takes a lot of time your framerate will drop because acknex has to wait until all your functions are done to render the image to the screen.

Thank you Ezzett.

int node_to_node[9999999]; worked until I saved the game. GS ran out of memory lol.

How do I see the stack? Is that an allocated memory area I can monitor?

I wrote the answer here:

http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=466093#Post466093