Text Files and Stats

[KamikazeHighland]

I don't understand how text files to store stats.  I'd open the file, append it and WriteInt with a new stat, then save it.  But how would I read from it?

All the numbers would be in order (i.e. 56, 78, 43, 97, etc...), but how would I then write a script that says something like: stringStat = value at line 7, or so?

How do I store information in sequence and then read it back based on it's position or line number?  I.e. Line 1 = 56, Line 2 = 78, Line 3 = 43, etc...

Or, if all the information was saved in sequence, how could I convert the text file into something AGS could read in order?

EDIT:
I guess, for now, I could save all the information as one long appended string and truncate it accordingly.  It'd be nice to use outside files, though.

[monkey0506]

You should probably consider actually looking over the File functions and properties to see what AGS offers in that regard.

AGS' File functions don't presently offer any way of seeking the read/write position aside from actually performing a read/write operation directly. What I'm getting at is that you would have to read the file from the beginning until you got to the point in the file you needed, so it would probably just make more sense for you to read the file at once.

Reading the values back depends a lot on how and what you're storing the values into, but you could do something along the lines of this:

Code: ags

int values[50];

function ReadFile()
{
  File *f = File.Open("stats.dat", eFileRead);
  if (f == null) return;
  int i = 0;
  while ((i < 50) && (!f.EOF))
  {
    values[i] = f.ReadInt();
    i++;
  }
}

Edit: As a matter of fact, that's nearly identical to the example code provided for File.ReadInt, a fact which I didn't actually realize until after I typed this out, but I laughed when I saw the existing example code also used "stats.dat"

[KamikazeHighland]

Lol.  That would work, but it's probably not necessary.  I can store the information in a long string and save that to a text file, it just won't be fun to read as text or friendly to import/export, but it will help for cross saved-game information.

Thanks.

[monkey0506]

Why would using Strings make it less friendly to read/write the file? You could just use File.WriteString and File.ReadStringBack. I don't understand why that's more difficult than reading/writing integers.

If you did use Strings, it's not that difficult to split a String into a dynamic array. You could even specifically return an integer array by just using the AsInt property of each value read out from the conjoined String.

I'm pretty sure this is kind of like the scene in Blue Harvest where Peter Griffin as Han Solo and Chris Griffin as Luke Skywalker are trying to get a couch onto the Millennium Falcon, when Han says, "This is easier than we're making it."

[KamikazeHighland]

Nice!  You're right.  I knew the answer before I asked.  I was just thinking in order to read from the string I'd have to import the whole thing each time, but I suppose I don't.

[monkey0506]

Well the real question is, why are you trying to read this data at different times to begin with instead of reading the entire thing into your data structure at once? You haven't really said what this is for, or how it's used, which could quite probably be relevant.

If you wrote all of the data into a single String then I don't see how you'd get around reading the entire thing back at once unless you wrote it via WriteRawLine and then read it back via ReadRawChar (one char at a time). Of course that would be ridiculously inefficient compared to using WriteString/ReadString.

I don't know why you think that if you wrote the file with WriteInt that you wouldn't be able to use ReadInt to read the values back in the exact same order, but okay..anyway.

It would help to know what you're trying to actually achieve to determine what the best way of doing that is.

[KamikazeHighland]

I'm saving information in a concise format, out of runtime and out of saved games as separate files.  I can see what's confusing you:  while I need to store a sequence of information in order, I only ever need to read small parts of it at once.  I.e. I'd save information as a string and save that string to a file, then later read that string and truncate as needed to only get the pertinent part of it.

[monkey0506]

So you would read a string from a file, cut out a substring of said string, use it, send the string and the file pointer off to be happily destroyed, rinse and repeat. Hmm..well I just hope you realize how inefficient that is.

You should really consider reading the file once, storing the data into an array or structure within the script, and reading the data out of that as needed. The difference of the end-result at runtime might not be immediately apparent, but if you did this often enough, especially in a game with a lot of graphical effects or other things going on, it could quite heavily impact your game. Besides, is there really a reason you would want your code to be less efficient??

[KamikazeHighland]

I'd like to allow a high degree of customization, which means having a lot of information to keep track of, little of which would be pertinent at any one moment.  I haven't decided on specifics, but I'm considering things like custom characters, custom items, custom inventories, the total number of which would grow with the amount of time played.  This information would be indefinite.

Since most of it would be unnecessary to have in a script I'd save what's not being used to several files so that, when something needs to be used, there'd be chunks of information to go through but nothing too big, and everything else not being used would be saved outside of runtime and outside of saved games.  The saved games part is to make loading saved games easier as well as to allow information to be used across saved games.

[monkey0506]

You're right. Do what you want. Sorry for trying to explain why inefficiency in your code is a bad model to explicitly employ. Silly of me to think that you might want to not needlessly waste CPU cycles constantly writing and reading to and from the hard drive.