Finding a specific spot in a text file

[Raknarg]

Like I could just rewrite the file every time it changes, but that doesnt seem like the best option.

[Aange10]

Okay, but your able to keep track of where grass blocks are, so keep track of where chest blocks are too. Just instead of chst, define it by its number. That away you can assign each chest a specific state.

Instead of saying "Theres an 8 by 8 block of grass at 300, 300, 300 with an open chest"

you can say "There's an 8 by 8 block of grass, at 300, 300, 300 with chest 13486"


say your player goes within 20 blocks of a chest, you can tell the computer "If the player is within 20 blocks of a chest, then take the chest's name, and find its state."


You could write the state of any given chest in another txt file, or you could keep an array with the chests state.

** Also in case you're thinking the array would get too big, I have two points.

1) I don't know anybody who would have 10,000 chests. or 100,000 or 1,000,000 chests. If it took a second to get a chest, it would take 11 and a half days straight to get 1,000,000 chests.

2) During loading, you could have it filter through the chests and check to see if they exist. (You could have 4 flags. Open/Close/Locked/Destroyed [or use whatever flag you currently use]) And if they don't exist anymore, free the spot in the array. I'm sure your map file would have already replace the "chest" with "air" or whatever it is that was put there.

[Raknarg]

Of course I can keep track of them, that is not the problem. The problem is rewriting a text file with the desired data in only one spot without rewriting the entire file, if possible.

It's not teh array thats the problem here.

[ProgrammingFun]

Tony @ Fri Nov 25, 2011 7:55 pm wrote:

as was asked above, why not?

Ideally, yes -- that feels like work... suboptimal... wrong. But from a Software Engineering stand point -- how much of a performance hit is that?

[DemonWasp]

The best way to do this kind of thing involves having the file format itself tell you (or imply) where the record you want to change is found. In all examples, I will assume that your file is binary, but this is also technically possible with a text (ASCII) file. Typically, there are a few solutions:

Solution A:
This solution is relatively easy to visualize and quick to program. It has some inflexibility and limitations, but you can work around those relatively easily.
1. Separate your files into sections. Each section holds exactly one type of data (doors, or chests, but never "doors and chests"; have separate sections for each).
2. Make it so that each record always consumes the exact same number of bytes. For example, a "chest" record takes up 10 bytes -- 4 are "CHST", 2 are X-coord, 2 are Y-coord, 2 are flags (open, destroyed, key, etc).
3. The "header" of your file -- the first bit you read -- is a constant length. It describes the initial location of each section and the number of elements in that section.
4. Now, to change chest 423, you just need to edit starting at (start of chests section) + 423 * (size of a chest record), and you need to write exactly (size of a chest record) bytes.

Solution B:
This kind of thing is more useful when your objects are logically grouped, but contain varying amounts of information -- for example, items include swords and rings and potions, but each stores a different amount of information and is therefore a different length. However, it is considerably more complicated.
1. The header of your file stores the number of items and the offset to an "index table".
2. The "index table" is just a bunch of offsets into the file, describing the start of each item. So the first 4 bytes of the index table describe the offset of the first item.
3. When you go to the offset described in the table, you read a "record header" that tells you the type of the record and how long it is. This gives you enough information to figure out how much to read or write.
4. Now, to change chest (record number 423, chest number 1), you would go to the offset table at index 423 and read 4 bytes of offset. Then, at that offset, you would read "CHST" as the type and 6 as the length. Now you know you can write 6 bytes (X coord, Y coord, flags).

If you absolutely must pursue this, I recommend you start with solution A. However, I recommend that you consider just rewriting the file every time you save -- this is how professionally-developed games do it, and for good reason: small random writes to files are disproportionately expensive compared to large, consecutive writes. Another good reason is that doing it this way is considerably harder than just rewriting the entire file -- and therefore, more prone to bugs that damage saved games so they can't be loaded again.

[Raknarg]

Thanks, I'll look into that.

[smool]

alright, its like what Tony said earlier i think, just overwrite everything.
Load the file at the start of the session, save all the data to variables instead of the txt file being the data, and then rewrite the text file when the user hits save?