Duke4.net Forums: readarrayfromfile can implicitly shrink the target gamearray - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

readarrayfromfile can implicitly shrink the target gamearray

#1

I noticed that if one uses the CON command `readarrayfromfile` to load a file that is smaller than the target gamearray, the game will implicitly shrink the array.

Here's a scenario where this behavior could have unexpected consequences:
  • The developer of a mod wants to store game progress externally in an array of 16 entries.
  • The mod is released, people play it and have their progress saved in this array, stored as a file on disk.
  • The developer then releases an update to the mod which increases the size of the array to 32 elements.
  • However, players that want to keep their progress will encounter errors -- as the game loads their files, the array is implicitly sized back down to 16, thus causing exceptions once the game tries to access indices of 16 or higher.

I argue that this behavior is undesired, and the game should only resize the gamearray if the contents of the file do not fit.

In the attachment you'll find the CON file I used to test this.

Attached File(s)



This post has been edited by Doom64hunter: 22 January 2020 - 04:20 AM

1

User is offline   Fox 

  • Fraka kaka kaka kaka-kow!

#2

If you are writing an array from a file, it's expected that the array will be resized.

You should instead use getarraysize to verify the array size to avoid errors.
1

User is offline   Hendricks266 

  • Weaponized Autism

  #3

View PostDoom64hunter, on 22 January 2020 - 04:19 AM, said:

I argue that this behavior is undesired, and the game should only resize the gamearray if the contents of the file do not fit.

No, it's not undesired. It is sane and intuitive behavior for an array read from a file to contain only what is read in.

If your proposal were implemented there would be no way to tell how large the array read in actually is on disk.

If you've come up with a construct such as a permanent data storage array that should be maintained across updates of your project, you need to do the legwork to support that. Fox is right. Teach the code that the array used to be one size, now it's another, and it needs to know how to handle that.
0

#4

View PostHendricks266, on 23 January 2020 - 01:53 AM, said:

No, it's not undesired. It is sane and intuitive behavior for an array read from a file to contain only what is read in.

I would agree if we were talking about allocating a new array from a file without having allocated space beforehand, but the way this command is used you'd expect it to behave more like an operation that reads data into an existing buffer, in which case I don't think it's intuitive for it to reduce (or even grow) the size of said buffer.
Either way I added a description of this behavior to the corresponding wiki page to avoid further confusion should someone else use this command.

View PostHendricks266, on 23 January 2020 - 01:53 AM, said:

If your proposal were implemented there would be no way to tell how large the array read in actually is on disk.

This could have been done by loading the number of bytes or entries loaded into a variable passed as a third argument. But not really important now in any case.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5

No, that's not a proper expectation. You can't make that claim for a language that does not even have local variables. You are making global assumptions that are actually specific to your own particular use case. What if someone used arrays that did not have a guaranteed fixed size? The absence of a length return parameter proves what the expectation for the command should be.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options