This is in an existing K2SE world. I haven't played for a week while I've been on vacation, but I only have the one vehicle with sensors in it, a regular car which I use for rapidly hauling stuff between logistics networks remotely. I'm not currently on the surface the car is on, and it was not queued to perform any work.

Some of my significantly older saves seem to work fine where the car only had a Gate Sensor and a Follow Player Sensor, so it may be that the issue is related to one of the additional items I've added since that time.

The mod Autodrive (1.1.6) caused a non-recoverable error.
Please report this error to the mod author.

Error while running event autodrive::on_tick (ID 0)
autodrive/scripts/sensors/logistic.lua:227: attempt to index global 'GCKI' (a boolean value)
stack traceback:
autodrive/scripts/sensors/logistic.lua:227: in function 'logistic_unpack'
autodrive/scripts/driving.lua:333: in function 'check_crons'
autodrive/scripts/driving.lua:988: in function 'tick_vehicle'
autodrive/scripts/event_handlers.lua:1048: in function <autodrive/scripts/event_handlers.lua:968>

I'd also report this on GCKI, since it's being referenced here, but you develop both so I figured this one seemed more fitting, even if it looks like an interaction between the two is involved.

Thanks for the report! In Autodrive, I use GCKI as a flag indicating whether GCKI is active; in GCKI, GCKI is used as a prefix for functions and variables that need to be accessible from every file in the mod. As I've been working on both mods in parallel, I guess I have copy-pasted code from GCKI to Autodrive and forgotten to change the prefix.

The fix is simple, just change line 227 of file scripts/sensors/logistic.lua from

  local player = GCKI.ascertain_player(state.owner) or state.entity.last_user

to

  local player = AD.ascertain_player(state.owner) or state.entity.last_user

Could you try this and see if you get any other errors? I wouldn't like to push out a new version for each typo that may have gone unnoticed so far. :-D

(By the way, your error message was garbled because posts on the mod portal are in the Markdown format, and the __ before/after the mod name is Markdown for highlighting text. You can mark code by adding an empty line before and after the code block and putting four spaces at the start of each line.)

Ah, I see. I hadn't noticed the bold formatting there. I'm used to talking on forums where you have a WYSIWYG editor rather than Markdown.

The suggested change appears to have resolved that specific error, but then I get a new one in sequence.

The mod Autodrive (1.1.6) caused a non-recoverable error.
Please report this error to the mod author.

Error while running event autodrive::on_tick (ID 0)
__autodrive__/scripts/sensors/logistic.lua:233: attempt to call field 'argprintNewBlock' (a nil value)
stack traceback:
    __autodrive__/scripts/sensors/logistic.lua:233: in function 'logistic_unpack'
    __autodrive__/scripts/driving.lua:333: in function 'check_crons'
    __autodrive__/scripts/driving.lua:988: in function 'tick_vehicle'
    __autodrive__/scripts/event_handlers.lua:1048: in function <__autodrive__/scripts/event_handlers.lua:968>

I'll investigate the file and see what I can see. It's interesting to realize how plain the lua scripts actually are written out. I wasn't previously aware of the format mods were stored in.

Ah, I see. I hadn't noticed the bold formatting there. I'm used to talking on forums where you have a WYSIWYG editor rather than Markdown.

Yes, it's sometimes inconvenient, not sure why they decided to use Markdown here …

The suggested change appears to have resolved that specific error, but then I get a new one in sequence.

Error while running event autodrive::on_tick (ID 0)
__autodrive__/scripts/sensors/logistic.lua:233: attempt to call field 'argprintNewBlock' (a nil value)

That's already been reported here. Another typo: It should be writeDebugNewBlock instead of argprintNewBlock, the same error also occurs in line 270.

Funny enough, my own testing had just led me there. I wasn't sure whether it was supposed to be argprint or or writeDebugNewBlock, so I was just about to test both. With those three things resolved, it appears that my save will now migrate correctly to this version. Thanks very much!

Funny enough, my own testing had just led me there. I wasn't sure whether it was supposed to be argprint or or writeDebugNewBlock, so I was just about to test both.

writeDebug() will print formatted or unformatted text, so it's useful for descriptive debugging messages:

-- Plain text
AD.writeDebug("Hello, world!")

-- Formatted text
AD.writeDebug("Hello, %s!", {"world"})

-- Formatted text forced to be in one line
AD.writeDebug("Position: %s", {serpent.block(position)}, "line")

writeDebugNewBlock() does just the same, but it outputs a line break first, so blocks can be visually separated in the log file.

argprint() will show the object in a reasonable way:

-- Not useful:   {__self = "userdata"}
game.print(serpent.line(game.get_player(1)))

-- Human-readable output: LuaPlayer 1 ("Pi-C")
game.print(AD.argprint(game.get_player(1)))

With those three things resolved, it appears that my save will now migrate correctly to this version. Thanks very much!

You're welcome! :-)

Should be fixed in version 1.1.7!