fixed for 2.1.18

i've dug into this some and the TL;DR is that if we were using TCP (and for things like RCON where we *are* using TCP), the socket would just handle this for us because when it forms a connection, that connection is identified by the full tuple (local addr, local port, remote addr, remote port) and ...

DebugAdapter was incorrectly holding cached information about the caller function after the tailcall hook, when the callee got moved up into that slot (and thus now matches by address), and only refreshing the line number, thus leading to the incorrect "merged" stack report with the callee's line ...

it looks like this is specifically an issue with tailcalls (of metamethods? not sure yet...), so as a workaround for now, putting parens around the return makes it step to the correct location:

okay, i've replicated it now, investigating...

the trace you have provided does not seem to match these over-cropped screenshots (at no point does it include a stack trace for any of the shown function names), and there is not enough information to attempt to recreate the issue.

2.1 does not support this. use the console to assign new values.

i think some folks have found it works if you point fmtk at the real binary instead of the arch dispatch script, while we work on a cleaner solution

yes

fixed for 2.1.17

oh wow this is extremely stupid:

While trying to describe a value
I try to call its __tostring for it to describe itself
and when that fails, i then try to describe the value again for the error message
which repeats the attemped __tostring 🤦

should be a fairly straightforward fix though ...

hmm, looks like i fell into a loop trying to describe some value (possibly an error object?). will have to dig a little to say more than that though...

poking around at this some more trying to reconstruct the specific events - i have been unable to reproduce a crash now (and the checkstack fixes in 2.1.13 may very well have fixed it, iirc you said it was less reproducible after that), but more specifically what occurred is this:
1. while in a ...

a quick look suggests this is the checkstack thing again, in another variation

fwiw, you can still (and always could) enter the sign bit/minint as its actual value, -0x80000000

there's a note somewhere that says it's excluding the ones that just depend on everything

edit: in the hover for "Default"

nevermind i didn't read close enough

i posted a fix for this, pending review fixed for next release

i believe this is distinct from those linked crashes, i will be looking into this deeper shortly; i think it should be a relatively easy fix, but i have to set up some quick tests first to verify i've understood the situation!

it looks like it requested the restart for the mod changes, but some curl task was not yet completed, and failed to cancel

please try this again with factorio 2.1.9 / fmtk 2.1.4 - if it still crashes, i'd also like the DAP trace log you get from adding "trace":true to the launch.json options while reproing