![]() ![]() This one just does deleteLine() as there is no useful information to parse. I went with a regex here as well, just in case. The first is to catch the ’empty’ lines between blocks. ![]() These sit just below the inner trigger gate parent, but beneath the very first Trigger Parent at the very top. Inner Trigger Gate Child: the second line of info on a dominated mob Tidying up We’ll use another regular expression for this trigger, with the pattern of: \| STR: (?\d ) INT: (?\d ) DEX: (?\d ) CON: (?\d ) WIS: (?\d ) CHA: (?\d )Īnd the script will be: local info = dominatesįirst we retrieve the information we stored in the previous trigger, then we add the new information to it, and assign it back to the dominates table. Once you create it, you drag it on to the previous trigger, as shown in the pictures. This trigger captures the information out of the second block. We use the number provided by the block as the key, and copy in all the information we have obtained. The pattern in this case is: \| Dom (?\d ): (?. ) HP: (?\d ) SP: (?\d ) LVL: (?\d ) NEED: (?\d ) KILLS: (?\d )Īnd the code in the scripting box looks like this: dominatenum = tonumber(matches.number)īecause it’s the first line in the block, we create a new entry in the dominates table. Because we’re matching and parsing information out of this line, we’ll use a regex trigger. We set a fire length of 1 because we know the next pattern comes on the very next line. The icon for the first trigger will become a funnel when this happens. This new trigger must be dragged on to the first trigger to establish the parentchild relationship. You could get by without these inner triggers being gated but it’s good practice. Each block of information on a dominated mob is two lines long, so we’ll use a trigger gate to match these. The Inner Trigger Gateįor this one in particular, we’re going to use a nested trigger gate. Also shows the overall layout of the triggers when complete. dominates = ĭeleteLine() Screenshot of the trigger head. We also delete the line, because we want this parsing to be invisible in the main display. In the code for the trigger we wipe/recreate a table to hold our dominated mobs (dominates). We set the fire length of this trigger to 99, because we’re not sure how many lines will be in the center bit. This is the first line in the block, in this case: The first trigger we make is the parent trigger or the trigger gate itself. I’m going to walk through the different pieces of this trigger one at a time, but the complete trigger stack can be downloaded as an xml you can paste into the Trigger editor in Mudlet here. This is a perfect candidate for gated triggers, as you may not know exactly what comes inside the block but you know exactly how it starts, a general pattern for the pieces in the center, and exactly how it ends. And this is the block they needed to parse To start with, someone came in and said they needed help matching a block of text from Lost Wishes. I resolved the issue on Discord and asked them if I could use the example to reference back to. And the solution to this question is one that comes up fairly frequently, but can be difficult to explain without examples. So once again I found myself sitting in the Mudlet #help channel on Discord and someone came in with a question. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |