on/off: occurs immediately when active or loaded but inactive unloaded is impossible because wire will load the block before delivering the event.interrupt: occurs on schedule when active occurs on schedule when loaded but inactive occurs and forces loading (but not activation) of the mapblock when unloaded (luacontroller lc_interrupt callback calls NodeMetaRef::get_int which calls NodeMetaRef::getmeta which calls Map::getNodeMetadata which calls Map::emergeBlock which loads the block).program: obviously impossible to perform without a player nearby.But it responds to digilines in merely loaded blocks as well (and digilines load all the wire on message just like meseons IIRC), and thus is able to detect unloaded blocks: these are reported as ignore (detector has to be in another block for that to work, of course).Īccumulated notes for later turning into something nice: LuaController, by event Normally, it works in active blocks only (as it uses an ABM). Node detector is even more interesting.The exact behavior here won’t fit in such a table. For example, piston consists of 2 nodes, and pushes (or pulls) some more.The situation is more complicated with some other nodes, though. Moreover, VoxelManips load blocks as well, so everything at the end will be at least loaded. LuaC fully works in loaded (“cached” in your terms) blocks AFAIK, and interrupts load the block when necessary (unsure on that).Blinky plant blinks in active blocks only as it uses ABM for that.Good idea! I needed that information often to build reliable circuits, and had to guess and to experiment (and to look through the source sometimes) to obtain it. For example, wire can conduct signal through even unloaded mapblocks due to using voxelmanips, but what happens at the end? If it hits a piston in an unloaded block, will the piston extend? Will it move the other nodes in front of it, or not? What about a movestone? Or, another example, if a blinky plant is in an unloaded node, will it keep blinking (I’m guessing no, but I don’t know for sure). The same information for other nodes would also be useful. Presumably the entire “active” column would just say “handled immediately”, but the other columns could say something like “handled immediately” (the mapblock is loaded into RAM if needed and the code runs, regardless of whether there are players or anchors nearby), “deferred” (nothing happens, but next time a player goes near the Luacontroller, it will run the code for the event), or “dropped” (the event disappears and the code will never run). ![]() Within each cell of the grid would be an explanation of what happens to that event when the Luacontroller is in a mapblock of the designated state. Then there would be a row for each thing that can happen to a Luacontroller: incoming Mesecons wire state change, incoming Digiline message, interrupt timer expires, etc. ![]() There would be three columns representing the state of the mapblock containing the Luacontroller: “active” (anchored or a player is nearby), “cached” (not active but still in RAM), and “unloaded” (not in RAM). ![]() So, it would be nice to have some documentation regarding what exactly happens when a particular event happens in a mapblock at a particular state.įor example, for the Luacontroller, I could imagine a matrix (grid). Sometimes you don’t want to anchor everything, because that would be a lot of mapblocks.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |