Closed Cordir closed 8 years ago
Example is below. This is from issue #16 for the editor.
*Give container to mob, which has a container with items inside. M 0 2109 1 1297 Minotaur Key Holder E 1 2161 20 1 7 Huge Spiked Seste G 1 2129 100 a chest I 0 2162 1 2129 Multi-Colored Key Ring (contains color key) P 1 2153 100 2162 Red Key P 1 2154 100 2162 Black Key P 1 2155 100 2162 White Key P 1 2156 100 2162 Brown Key P 1 2157 100 2162 Yellow Key P 1 2158 100 2162 Maroon Key P 1 2159 100 2162 Green Key P 1 2160 100 2162 Grey Key E 1 2161 100 16 Huge Maul
From Issue #17:
TokugawaTFC commented on Feb 14, 2015 Reset a container on the ground with a container inside with objects in second container. O reset puts the chest on the ground I resets puts the box in the chest P reset puts the key in the box
Can you (P)ut directly into a (G)iven or (E)quipped object?
You can use a P reset in a Give and Object reset but not an Equipped item.
In regards to the image you would do a (G)ive or (O)bject reset first. Then the (I)nsert reset followed by the (P)lace reset.
I could try and do a flow chart similar to what you did if you like.
So, no (I)nsert on (E)quipped container either?
You can do that also. My example above with the mob shows that.
Seeing the resets is the easiest way for me to visualize it.
Er, wait. My mistake. I am not sure about equipping a container. It might work but I have not seen an example of this.
I am following with regard to order, just want to be sure all combinations are covered. The fact that there were combinations not previously accounted for has created the current predicament.
Updated associations below with daashed=tentative for P and I acting upon an E.
I looked at the chart again and compared it to the resets I have and the chart looks ok now. It was just a little confusing to me at first. I'll let you know tomorrow about the (E)quip reset and see if the P and I reset works with it as well.
Right, right. It's not flow per se. More so, I'm mapping out which items (can) belong to which.
The flow or sequential order will be generated based on the relationships.
In a related item, "sub-resets" are now called "dependent resets" and will display as more compact, collapsed lists (click to expand):
Collapsed
Expanded
FYI, old style P resets will now show "(LEGACY)". This relates to the above diagram and is informational only (don't let it bother you).
New reset nesting working in beta.
Interface showing nesting:
Output for the above:
I'm trying to figure out what specific series of steps you followed to make the Insert reset happen...? I'm poking around with the resets and haven't been able to find it yet.
It's not live yet.
It is live now. Please test...
The nested/dependent resets are showing the warning for an object that has no associated reset.
I have created a sample area (The Practice Fields) as a test and demonstration. It shared with all so you can see it, poke at it, and potentially download and test load.
See area for details, but it definitely includes the following (assuming things are done right):
'No reset' warnings for nested/depended resets fixed.
I clicked on the Download and Preview buttons so I could put this on the test port and I got a generic error that something went wrong.
On Tue, Apr 12, 2016 at 8:36 PM, Gwyrdain notifications@github.com wrote:
'No reset' warnings for nested/depended resets fixed.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Gwyrdain/apprentices-workshop/issues/71#issuecomment-209213017
Apparently I broke something.
Should be fixed now.
I've tested this in live, and it appears to work. (That's just me figuring out how to go about doing it, NOT testing it on a mud environment to see if it actually functioned. Tokugawa's going to be doing that, but the test server is not currently available.)
I clicked on the 'Review' button in 'The Practice Fields' area and am getting the following warnings. Should this be changed to show this is not an error? I am assuming this is not really an error but is being caused by the nested resets.
Overloaded container reset: Insert 'a golden locket necklace' into 'a saddlebag'. Overloaded container reset: Insert 'a picture frame' into 'a cloth backpack'.
I looked over the resets on the test port and it all looks good. Below are the notes I took while reviewing this.
* Mobile Resets * M 0 40000 1 40001 * Load 'a workhorse' at 'The Practice Field's Northwest Corner' E 0 40004 100 12 * Equip 'a workhorse' with 'a saddlebag' as ABOUT BODY P 0 40007 100 40004 * Put 'a few pebbles' into 'a saddlebag' I 0 40005 100 40004 * Insert 'a golden locket necklace' into 'a saddlebag' P 0 40006 100 40005 * Put 'a single crimson hair' into 'a golden locket necklace' G 0 40008 100 * Give 'a workhorse' 'a carrot'
A workhorse is using:
Other than the warning on the Review of the zone I think this can be closed.
The warning appears to be working correctly. In both cases the container was being told to load beyond its capacity -- both had capacities of zero. As we can see above, TFC will execute the resets even if there is a "logical" weight problem. I think as a rule AC's would expect containers to be loaded logically (e.g., don't load 100kg into a 1kg pouch), so this seems like a good back-check to me.
I added the capacity calc to the dependent resets so this is more clearly observable. One of the overloads in question is shown below.
I am trying to create a reset of a container (with items in it) inside another container... but it doesn't seem to be allowing it. :(
Area: The Grand Library
Primary container: Load 'a heavy marble worktable' at 'The Grand Library Conservation Room' Associated Sub-resets Put 'a fire-charred journal' into 'a heavy marble worktable'
Secondary Container: a fire-charred journal (39034) Should contain: