you've pretty much got it figured out.
although the scripts aren't technically run at the time of upload, its just that uploading a script uses one of the player's energy points, which then triggers a world step to occur.
for each world step, for each entity, I first call into the its scripts "step" function passing a map that represents an entity (the format is specified in docs.: ) (since you've already played the game you might have select "restore default files" from the settings to see the changes) and an array of tiles in the entities fov. while each tile does contain the data of an entity, and you can technically change it, the changes are local to the function call. So changing the "tag" property of the entity map doesn't effect the data in the field of view. Basically, everything that goes into and out from a function callback is passed by value.
all (non player) movement is handled by the "goal" command. I find the the shortest path (A*) from the entities position to the goal and update its path which in then follows until the "goal" is overwritten, is reached, or the entity collides with another entity.
so, after "step" is called, the entity attempts to move along this path.
If a collision occurs I call into the "collide" function (added in the updated verison) which is the same as step except it contains a third argument representing the entity that is in the tile it wants to move into.
The wander code is actually very simple. Entities have a "goal" property that only exists in the map if their goal is already set. So, in the step function, I check if the entity doesn't have a goal, then I loop through every tile its field of view adding all non wall tiles to a list of possible tiles to move to, I then select one at random using the built in 'rand function, and assign the the tiles "pos" property to the "goal" command.
Then (outside the script) the shortest path from the entities position to the "goal" is calculated using A*. So even though there are edge cases where a non-reachable tile is in the field of view, if that tile is chosen the entity simply wont be assigned a path and the script will pick a different random tile the next time "step" is called.
I did change how "heal" works, so now it does take a position. The amount that it heals is now based on an entity's "strength" stat.
The main thing I forgot to mention in the docs in this update was that you can see print statements in the terminal from the scripts of entities you are connected to. So to see the exact layout of the entity map that's passed to step you can upload this script to an entity:
: step ( ent
$ ent
)
you've correctly identified the limitations. That is, there's no direct communication between entities, entity's tags cannot be changed, and you can't pass arbitrary data to entity's scripts. This is something I've already thought a lot about. I already implemented this kind of functionality in my other project that uses this scripting language so its certainly possible, but its a very different game.
I actually just started a new project based on Stuck In Rogue, that is more focused around networking. I'm planning on making it so not only the player, but every entity is able to connect to other entities and modify their scripts or give commands directly. I've been working on terminal cmds for uploading, downloading, connecting, scanning for possible connections, etc. and then all I'll have to do if allow entities to issue commands to the terminal. I also plan on including the ability to spawn items, but I'm still thinking of how that might work.
I probably wont be adding these features back into Stuck in Rogue in as the new codebase is already diverging. But I might go back and add more detailed documentation.