Here is the python file.
Let me know if you find any bugs.
And this is an example alcscript:
- Code: Select all
- type: pythonfile
name: SolutionParser
pythonfile:
file: Rendercity1SolutionParser
parameters:
- type: string
value: "R1Pos,R2Pos,R3Pos,R4Pos,R5Pos"
- type: string
value: RButton
- type: int
value: 8
- type: string
value: "1,2,3,4,5"
- type: float
value: 4.4
- type: bool
value: true
#solution responder
- type: responder
ref: <name or $tag>
#backwards responder
- type: responder
ref: <name or $tag>
The lists are in parameters 1 (SDL names) and 4 (solution values). They can be of any length as long as they are equally long. SDL name 1 corresponds to solution value 1 etc.
The backwards responder should be used to reset the solution responder. It is optional and whether you need it or not depends on what exactly the responder does. If it is some kind of door opening animation you'll probably need that backwards responder in order to avoid multiplayer sync issues.
I'll give you an example: Once the puzzle is solved and someone messes with the buttons again the solution code is no longer valid. However, without a backwards responder the puzzle reward remains in its solved state. On the other hand, new explorers who link in will see the puzzle reward in its unsolved default state, because their client checks the solution code on arrival. And since that code is now wrong the solution responder refuses to run for them.
A few words of caution about the reset. If the responders controlled by IntRespList contain avatar animations the SDL reset will cause all of those to run and warp the avatar around like crazy. Unfortunately that is how IntRespList works.
If this happens we can fix it by adding a new SDL tag 'skipavatar' to IntRespList. IntRespList already has a 'fastforward' tag, but that will skip the entire responder to its end state.