Datastore issue with negative indices

SDK Get Help
1

Hi, I've discovered something that seems like a bug with datastore. I'm only saying it may be a "bug" because, while I've heard there can be some issues with negative indices on tables in lua, I haven't had any problems up to now using them.

This code is an example of what I'm using to create a field of hex spaces. Being able to use negative indices is important for simplifying how this is constrained in a cubic coordinate system. This is working as intended throughout my code.

local fvJunk = {}
for i = -5,5 do
	fvJunk[i] = {}
	for j = -5,5 do
		fvJunk[i][j] = {}
		for k = -5,5 do
			fvJunk[i][j][k] = {x = i,y = j,z = k}
		end
	end
end

However, what I'm seeing is that attempting to use datastore.write on a table with negative indices ends up providing something like this in the resulting json file:

{
	"_array": [
		 {
			"_array": [
				 {
				},
				 {
				},
				 {
				},
				 {
				}
			]
		},
		 {
			"_array": [
				 {
				},
				 {
				},
				 {
				}
			]
		},
		 {
			"_array": [
				 {
				},
				 {
				}
			]
		},
		 {
			"_array": [
				 {
				}
			]
		},
		 {
		}
	]
}

Which is obviously unusable. From all my testing, it seems that datastore.write will not actually write a table entry that has a negative index. Can someone confirm if this is a bug that can be fixed?

Thanks!

2

I can't answer re the underlying question. And I don't know about performance... so you have probably already rejected this workaround... But could you use tostring to make those coordinate integers work as named keys in the table instead of numeric indices?

fvJunk[tostring(i)]

fvJunk[tostring(i)][tostring(j)]

etc.?
3

Thanks for the idea. That is a workaround yes, just not with the mathematical "purity" I was looking for. For now I've decided to rely on saving and loading a separate unordered list I keep of hexes and then rebuilding the array-style table after loading. But in any case, if datastore is using ipairs and thus is having issues with negative indices, it would be nice if that was either fixed or listed as an expectation.

4

I can fix the problem where it's ignoring negative integer keys, but then it encodes them as strings. So you won't be able to do list[-2] when you decode it, you'll have to do list["-2"]. :confused:

I.. think I'm going to break the spec here and allow numbers on the left side of the : separator in tables. :open_mouth: Not our fault that json isn't expressive enough.

5

I got this working today but it took some significant changes to the encoder/decoder guts so I'm not comfortable pushing it in the next update. I'll get it merged to main after that so we can have it running here for a while to try and catch the bugs I inevitably added.

6

no, strike that. It's been a year and a half and I don't think anyone's missed this, so I'm going to drop it. It's not worth the risk for the very little reward.

3 Likes
7

I think it would be worth mentioning in the docs that the JSON conversion is non-standard/complex and encode/decode process possibly does not return the initial table.

I ran into two issues with JSON encoding just today (dropped [0] indexes with numbered tables and above described broken mixed tables with both string keys a numbered values). I don’t see it as a problem as it is (and changing it in any way would probably be a big BC break) but it would be nice to add some caveats to the docs to save dev time.

EDIT: I realized that my issue might be more general than the above described issue with the datastore. If desirable, I can create a new thread.