Topic: Scenarios: File I/O

Can you provide me with the scenario that you are using for testing your branch?

Busy indexing nil values

Top

Quote

Can you provide me with the scenario that you are using for testing your branch?

Here´s my test script:

local game = wl.Game()

print("Starting to WRITE...")
game:save_campaign_data("TestCampaign", "test_scenario", {
   abc = "Hello",
   d = 8,
   efg = "World",
   h = -999,
   i = true,
   jklmno = 0,
   pq = "Hello",
   rstuv = 999,
   wxyz = false
})
print("Done.")

print("Starting to READ...")
local result = game:read_campaign_data("TestCampaign", "test_scenario")
print("Returned:")
if result == nil then
   print ("<nil>")
else
   print ("  " .. #result .. " item(s)")
   for k,v in ipairs(result) do
      print ("    " .. k .. " = " .. v)
   end
end
print("Done.")

The desired output would be

Returned:
  9 item(s)
   abc = "Hello",
   d = 8,
   efg = "World",
   h = -999,
   i = true,
   jklmno = 0,
   pq = "Hello",
   rstuv = 999,
   wxyz = false

But I always get:

Returned:
  0 item(s)

The .wcd file is written to correctly, though in wrong order.

@ypopezios: That´s a very good idea! I was going to use 1/x or exp(-x) functions to balance difficulties, but your approach will work much better (the only difficulty in scripting will be finding good min/max values). I´ll definitely use it in scenario #4 (though it will be some time until even #3 is complete…)

Top

Quote

I hate spending so much time debugging my code when only the test script is wrong… now it works. Thanks

I pulled out the code that parses/creates the table into a recursive read/write function, so tables can now be used as values. Scenarios can save subtables, e.g.

game:save_campaign_data("test_campaign", "test_scenario", {
   a_key = 0,
   another_key = {
      a = 0,
      b = "abc",
      c = {
         a = 4,
         b = false,
         xxx = {},
         yyy = "Hello",
         zzz = {
            key1 = "Hello",
            key2 = "You",
            key3 = "World",
            key4 = "!",
            subtbl = {
               ...
            },
            also_a_subtable = {
               ...
            }
         }
      }
   }
})

One other thing it would be nice to have is to permit arrays as well as tables. Using an array currently causes a coroutine error ("invalid key to 'next'"). I don´t know how to fix that though…

Top

Quote

Experimented some more and it turned out that actually the error message is incorrect. It´s luaL_checkstring() that can´t cope with integer keys for whatever reason, not lua_next(). Checking for lua_type(L, -1) fixes that problem.

I guess you'd have to iterate over the current table to check if all keys can be reverted to consecutive ints, starting from 1.

As far as I know, tables can either be arrays with indices 1..n, or have only strings as keys.
I now implemented a solution where integer keys are ignored when saving; and entries with no keys defined are assigned to an integer key when reading. If my guess is incorrect, this design is fragile though…

Finally, one small bug remaining: In arrays, nil values are silently omitted while saving; so any indices after nil values are decremented in reading the data. Example:

game:save_campaign_data("test_campaign", "test_scenario", {
   "Hello", nil, "World" -- index of "World" is 3
}

local data = game:read_campaign_data("test_campaign", "test_scenario")
--> data = {"Hello", "World"} -- index of "World" is 2

I have no idea where this could come from…

Top

Quote

But if a nil value exists, the mandatory typecheck should return neither "string", "number", "boolean" nor "table", so the if/else block would already trigger an error, just like it does when an object is used as a value. Perhaps this is the fault of lua_next(), it appears to skip keys that are mapped to nil. I don´t know why it confuses the int-keys then, though.
I wrote a warning for this bug in the documentation of save_campaign_data(), perhaps we could leave it as it is?

Top

Quote