Yielding from a coroutine seems to clear a local table

[MyNameIsTrez]

Describe the bug I expected 5 to be printed a second time here, rather than it becoming 0. I can't explain the fact that a and #b are still the correct value after the yield, though.

PRINT: 1. #PathDump is:
PRINT: 5
PRINT: 2. #PathDump is:
PRINT: 0
PRINT: a is:
PRINT: 1
PRINT: #b is:
PRINT: 1

since I can't think of a normal way in Lua for coroutine.yield() to alter the local PathDump

-- no waypoint list, create one in several small steps to reduce lag
local PathDump = {}
if Owner.MOMoveTarget and MovableMan:ValidMO(Owner.MOMoveTarget) then
	Owner:DrawWaypoints(false)
	
	-- copy the MovePath to a temporary table so we can yield safely while working on the path
	for WptPos in Owner.MovePath do
		print("Inserting WptPos:")
		print(WptPos)
		table.insert(PathDump, WptPos)
	end

	-- clear the path here so the graphical representation does not flicker on and off as much
	Owner:ClearMovePath()
	Owner:AddToMovePathEnd(Owner.MOMoveTarget.Pos)
else
	coroutine.yield() -- wait until next frame

	-- copy the MovePath to a temporary table so we can yield safely while working on the path
	for WptPos in Owner.MovePath do
		table.insert(PathDump, WptPos)
	end
end

local a = 1
local b = {"c"}
print("1. #PathDump is:")
print(#PathDump)
coroutine.yield() -- wait until next frame
print("2. #PathDump is:")
print(#PathDump)
print("a is:")
print(a)
print("#b is:")
print(#b)

I am 99% sure the mod didn't have this issue in pre5, as my mod updater script would've noticed this error in the log back then, caused by PathDump being empty:

BoS Initiate GoToWpt error:
Mods/bos.rte/Actors/Soldiers/MeleeHumanBehaviors.lua:1201: attempt to index field 'Pos' (a nil value)

To Reproduce

1. Download bos.rte.zip
2. Download Benchmark.rte.zip
3. Use this in your Settings.ini to instantly have the issue printed when the game boots:

	LaunchIntoActivity = 1
	DefaultActivityType = GAScripted
	DefaultActivityName = Combat Benchmark
	DefaultSceneName = Benchmark

[MyNameIsTrez]

@Causeless I can confirm the issue didn't happen in Pre 5.0. Here's benchmark.rte for pre5: Benchmark.rte.zip And here's bos.rte for pre5. I commented out the printing of a and #b in this version: bos.rte.zip

I notice that in Pre 5.0, the LogConsole.txt starts off with non-zero values being printed every time:

PRINT: 1. #PathDump is:
PRINT: 4
PRINT: 1. #PathDump is:
PRINT: 7
PRINT: 1. #PathDump is:
PRINT: 5
PRINT: 1. #PathDump is:
PRINT: 5
PRINT: 1. #PathDump is:
PRINT: 8

whereas the Release 6.0 mod start off with zeros being printed every time:

PRINT: 1. #PathDump is:
PRINT: 0
PRINT: 1. #PathDump is:
PRINT: 0
PRINT: 1. #PathDump is:
PRINT: 0
PRINT: 1. #PathDump is:
PRINT: 0
PRINT: 1. #PathDump is:
PRINT: 5

I don't know whether this is unexpected though, since it might just be because the game is now more multithreaded.

[MyNameIsTrez]

So in pre5 I didn't get any errors, of course

[Causeless]

Well, in pre5 the pathrequests would complete immediately in a blocking manner whereas in pre6 they are non-blocking and async. So starting with zeros is expected, it's just the game goes onto the next frame immediately instead of blocking and framespiking as it waits for the results. Though it is unexpected in this case that it's go from a positive value back to zero, unless the coroutine is restarting altogether.

I'll need to look closer.