harpy eagle wrote: "when you access variables inside those functions"
Yeah, this is a critical piece of low-level magic that comes into effect when working with AI helpers. It's arguably over-complex and over-designed, but, it can also be very handy.
harpy eagle wrote: So in order to store something in the temporary AI state you need to assign it to an upvalue when inside an ai_context call, like what is done in init_production_desire.ships().
Yes. (Though, to be pedantic about it, it's _ENV that's the true upvalue in this situation -- in the case of design_to_ship==_ENV.design_to_ship==SCOPE["temp AI State"].design_to_ship, design_to_ship is formally a field stored inside a table upvalue.)
edit: Um, in lua-parlance, an 'upvalue' is a local that's being accessed from a closure that shares scope with that local. Because they're really a form of local-variable access, 'upvalue' reads and writes can't trigger metamethods. However, if you have a table which is itself an upvalue (which is what _ENV is in Lua 5.2), then reads and writes to and from that table can trigger metamethods. Um, that's why the upvalue distinction matters.
