Mesecon integration #11
Comments
|
Speaking of, wooden/steel levers would be cool for portcullises. |
|
I just refreshed my familiarity with this mod's code (been a while since I did anything with it) and I suspect it'll be super easy - barely an inconvenience. All that's needed to operate a gate is to call
on any node of the target gate, and the only reason "node" is a required parameter is so that you can assign this method to a gate node's I'm going to be out of the house for a few hours, and am busy getting my butt back in gear on dfcaverns, but even so I think I might be able to knock this together tonight. Thank you, past-me, for writing this mod with flexibility like this in mind. :) |
Thus, if I understand it correctly, the lever node (generically, "the switch") must store the associated gate's coordinates. Therefore one must have a way to get the gate's coords, and then to insert them into the switch. Two methods come in mind. Method #1: Method #2:
Thinking of your Sounding Line, you could apply it to both methods, making it look like a rope (for a wooden lever) or a wire (for a techy switch); beside the "cool effect" this would visually confirm that "Switch/Lever A" has been assigned to "Gate/Portcullis B" and not "Drawbridge C". The lever node could reuse the default torches "on wall" shape, upside-down when in the opposite state; e.g. lever up = normal torch-on-wall; lever down = vertically flipped torch-on-wall.
Heh, I wish I could say the same! My coding skills have never been beyond the "hobbyst amateur" level, and after about one year of hiatus I hardly understand how I could write some of my mods. |
|
Unfortunately, right after I committed to doing this real life came up and punched me in the throat with a plot twist. Huge sigh. But I've been dredging spare time back up again lately, and I've started into this. The branch is at https://github.com/minetest-mods/castle_gates/tree/switches The approach I've taken is to create a "linkage" tool that you use on both the switch node and on the gate node. Click one and then the other, and it establishes the link between the two. It's a many-to-many relationship; you can have one switch connect up to multiple gates, and one gate can be controlled by many switches. The relationship is stored in a map that gets saved out to a file in the world folder. I'm still working on the UI. The streamers of particles from switch to target gates sounds nice, I'll work on that next. For now I've got a thing that adds HUD waypoints to the target gate nodes when you right-click on the switch. Right now there's not enough feedback to the player as to what's going on when he's right-clicking and left-clicking on various things, I need to fancy that up some more. |
|
Okay, I think I've got the user interface sorted out. The way this works:
The switch/gate linkage display times out in 30 seconds unless you refresh it by clicking some more with the linkage tool. Does this seem intuitive and functional to you? If so, I think this is about ready to merge into master. |
|
Hey there! The first attempt: I've placed a 'steel_gate_edge_handle' on the floor, then a switch, and then linked the two by clicking them with 'linkage', first on the switch, then on the gate. The link worked, it has shown the particles beam from the switch to the gate, but when I tried to use the switch it crashed with this message: Thus I thought that it might have been caused by the fact that there wasn't a wall next to the gate, thus I did this:
When I right clicked on whe switch, the lever moved, but nothing happened. And when I relogged the gate was floating 1 node above the ground, I tried to use the switch again and it did nothing except playing its sound:
Am I doing something wrong? |
|
Well, the movement upward is actually correct - that's not a hinged door panel, so it'll be treated as a sliding door panel and the only way it could move is upward. And the very first time you click on a newly-built gate nothing will happen yet because it has to figure out that it is a gate and what directions are free, that's a known issue I've never got around to fixing (all subsequent clicks will work fine). So if you trigger that gate it'll slide upward into the sky. Looks like it managed to get that far before the crash happened, so something was going right. There's a fraction of a second delay between a switch-linked gate segment moving and the updated linkage being written to disk in the world directory for persistence, so the game probably crashed before that was able to be done. That'd explain why the switch linkage was lost. I've been unable to reproduce the crash itself yet though. It's odd, I'm using Minetest 5.1 as well but line 410 of builtin\game\item.lua that your callstacks reference as part of the crash is a line of whitespace in between two functions in my copy. I haven't updated to the latest dev version of 5.1 in quite a while though, looks like my 5.1 is from mid July. I'll dig up the latest and try it with that. Edit: I grabbed yesterday's 5.2 build from https://gitlab.com/minetest/minetest/pipelines and wasn't able to repro the crash on there either. This callstack baffles me, somehow the code is reaching item.on_place from inside the right-click callback of the switch node. I'll poke around a bit more. |
Oh Christ... Anyway, I have just checked my builtin\game\item.lua and the one on the repository, they are different. EDIT: I have double-checked, my item.lua and the one on the stable branch are the same. Their version is this item.lua @410 However, at this point - granted that I was actually using the switch on the wrong node - I don't know what to say: there will always be someone using some older/newer version of the engine. EDIT: I have double-checked, my item.lua and the one on the stable branch are the same. |
|
I've managed to hack cross-version compatibility issues in my mods before, maybe I'll be able to manage it for this one too. I've got to leave the house for a few hours now but when I get back I'll try this out on the stable branch. I really want to repro that crash if at all possible, even if I can't work around it I can at least add a note about compatibility to the documentation and add an option to disable switches for versions it doesn't work on. |
|
Well, I downloaded the 5.1.0 release from https://www.minetest.net/downloads/, and I confirmed that its item.lua line 410 matched your line 410. Sadly, no crash for me. So I'm going to try a few "this shouldn't be a problem but I'll try 'fixing' it anyway" touch-ups to the code as a hail Mary. What OS are you using, by the way? I'm on Windows 10, I'm assuming from your screenshot you're on Linux? That makes me think perhaps there's a problem with how I'm writing out the switch linkage map to a file in the world persistence, I ran into a bug with something similar on commoditymarket that only manifested on Linux (I was using the wrong path separators and Windows was helpfully pretending I was using the right ones). That doesn't seem to be the problem here, but maybe there's some other OS-specific thing biting me. Unfortunately I don't have a Linux machine handy to test on. |
|
I have downloaded this: https://github.com/minetest/minetest/archive/stable-5.zip Then I've run this (copy-pasted from README.md @ 145)
My Debian10 O.S. told me: Translated: "Everything is already at its most recent version; 0 updated, 0 installed, 0 to remove and 0 outdated." cmake . -DRUN_IN_PLACE=TRUE make -j4 Then I have downloaded this: https://github.com/minetest/minetest_game/archive/stable-5.zip And placed it into /home/utente/minetest/games/ And then I've downloaded this: https://github.com/minetest-mods/castle_gates/archive/switches.zip Inclusive of eb34743 And placed it into /home/utente/minetest/mods/ I've built this:
When I right clicked the switch, it sent a chat message: "Gate triggered", the gate didn't moved, I've right-clicked the switch again and it crashed dumping this: When I relogged, the gate was open:
Only God knows. |
|
There actually is a useful bit of new information here; the fact that the switch reported "gate triggered" and did nothing the very first time the gate was triggered tells me that the switch code itself may not be the source of the crash. Not directly, anyway. As I mentioned in an earlier comment there's a known issue in this mod where the very first time you trigger a gate after it has been built will do nothing because the gate uses that opportunity to figure out what direction it's supposed to open in. So that tells me the switch went through its correct sequence of operation and sent the gate a "trigger now" command without crashing. Then, the gate actually moved one step before the game crashed. That's useful information too. Down at the very bottom of the gate_functions.lua file there's some code wrapped in "if door_moved then" that's the code responsible for having a gate continue to move after it's been triggered. What it essentially does is call minetest.after() to do a one-second-delayed re-triggering of the gate to make it move again. So something goes wrong before minetest.after is able to trigger the gate a second time, or possibly during the second triggering (though not very far into the second triggering, since one of the very first things that triggering the gate does is erase the gate's existing nodes from the world). The callstack still seems weird, though. It definitely implicates switch.lua somehow. Hm... I'm still at a loss here. I think my best bet is to take this question to the forums to get a wider audience to help me troubleshoot this since I've no way of reproducing this for myself. I'll write it up later tonight and post an update here with a link when I've done so. Thank you for going to such lengths to help me try to figure this out. It's frustrating to be so seemingly close to being able to merge this, but less frustrating than if I'd gone ahead and merged it and then been sent baffling bugs about it crashing this way. :) |
|
You're welcome! :) I did some more screenshots to confirm the dynamic that you have described: After crash:
Relinking:
After the new crash:
What about filling the code of debugging statements? To narrow the suspected area, nail the point actually causing the crash and then check it for every possible error; maybe it's just a type mismatch, something so simple that one would never think about it. |
|
I just submitted a change that adds a ton of debugging log statements to both the trigger_gate and trigger_switch sides of things, if nothing else it'll help narrow down exactly which chunk of code is crashing. Haven't posted to the forum yet, I got waylaid last night with an idea for commoditymarket. :) |
|
Cool, I've tested it with the same building and here is the log: |
|
Well, that confirms most of the narrative I figured out earlier. The switch triggers the gate, the gate successfully moves, and then the game crashes before it's able to attempt to trigger a second move to continue the gate's full swing. in Try commenting that whole block out. The gate will only move a single step after being triggered and not move again until you restart the server (since the triggered_already entries will never be cleared), but if it doesn't crash afterward then that means there's definitely something about the minetest.after call that caused this. And we never see "minetest.after call executing" in the log, so whatever it is that kills Minetest is doing it before the delayed function call actually tries to execute. If that's the case then I'm almost certain there's something engine-side going on here and I'll need to escalate this to the forum. |
|
Ok, I've commented it: Then:
EDIT: this is the log: |
|
Well... huh. There is one other potential minetest.after call that could be involved in this, over in switch.lua there's this guy in the |
|
Uhm, I've commented switch.lua @ 36: Then I have:
It crashed again, but look at the first line - is it expected since it is a new world, or is it wrong? |
|
EDIT: never mind, it says "LOADED"... I'm getting blind. :D I've just checked the debug.txt, that error was being thrown also in the old map, ever since you added the debug messages: I've overlooked it because generally prints are after the MINETEST ASCII art; I'm not a programmer but I guess that failing to find a piece of the program is not good - perhaps this is the root of the issue? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Seems like it should be pretty straightforward to set these gates to be triggerable by mesecon signals, investigate that at some point (filing issue to myself to ensure I don't forget).
The text was updated successfully, but these errors were encountered: