Here's a brief description of what to do (in practice) with the Questjournal OLC. If there are any questions, feel free to shoot Roland, Maco, or me a note.
Current Questcards will be in this post ; New questcards will be in a separate post.
The goal of the questjournal is to:
- Prevent spam / too many single questflags when you vstat a player
- Provide some information to any imms when trying to debug a quest. Eg, is it a logic problem in a quest, or typo problem in a quest, or some other issue?
- Allow players to track their quest status
- Allow players to track their trading status
- Allow players to reset questflags
The following post gives design suggestions on how to transfer current questcards to the quest journal.
Essentially, you need to know the zone in and out.
First, you need to know what ALL the flags are, and how they should be replaced with a new flag. The new flag should be something of the form "questcard<num>_<questname>" etc so it's easier to track flags.
Second, you need to plan how many questflags you want to have, and how the variables in the questflag will change based on the player's status in the quest, and which variables to reset. You should do this before editing any triggers, etc.
Third, while planning the questflags, you should also think of constructing a debug mode trigger at the same time. This helps to prevent errors.
Fourth, you want a mechanism that replaces the flags properly. Remember that questflags are checked when a player interacts with any mob, room, or object that is part of the quest. Function triggers are useful here if you don't want to duplicate code, and prevent errors.
Fifth - extensive testing on 6001 to make sure that every step of the quest / every possible combination works (or doesn't work). Ensure that the debug trigger tells the imm who is debugging where the player is, and what the player needs to do. More information is always better.
A warning for old-> new flag replacing.
Old->New flag replacingIf a player types qcheck <num> <something>, the quest journal will check if the player has the questflags given in the OLC. If not, the quest journal will auto set them. This is great for new quests, but bad for old quests.
Why is this? For example, we will look at Quest 6 (Thetis' Lover). The old quest has 11 questflags, thetis1, thetis2, ... thetis11.
Previously, at a stage, the code would look something like this:
if %actor.varexists(thetis2)%
%echo% You are on stage 2!
else
%echo% Good day, %actor.name%
endif
Of course, what we really need to do is to create a variable (maybe thetis) - with and set it to different values for each stage, eg
set thetis 2
remote thetis %actor.id%
because then we could just do:
if %actor.varexists(thetis)%
if %actor.thetis% == 2
%echo% You are on stage 2
endif
endif
So far - this makes sense, right?
In the previous version where we had a quest journal, we put the replacing of flags in a function. Here is how this would have looked like.
* Assume this is trigger 12345 as a function
if !%actor.varexists(questcard6_thetis)%
set questcard6_thetis 0
if %actor.varexists(thetis1)%
set questcard6_thetis 1
rdelete thetis1 %actor.id%
endif
if %actor.varexists(thetis2)%
set questcard6_thetis 2
rdelete thetis2 %actor.id%
endif
if %actor.varexists(thetis3)%
set questcard6_thetis 3
rdelete thetis3 %actor.id%
endif
* etc etc
remote questcard6_thetis %actor.id%
endif
etc all the way till thetis11. Note that while the code looks long, and would have eleven if checks (for thetis1 to thetis 11), the first if branch is only ever executed once.
So what would usually be done is this:
* Create Thetis flag, and replace questflag
function 12345
if %actor.questcard6_thetis% == 2
%echo% You are on stage 2
endif
Notice that in the above code, we did not check if the variable questcard6_thetis existed, because our function 12345 would have created this for us automatically if it did not exist. Furthermore, the time taken for the MUD to execute this is almost the same time if we had just replaced function 12345 by
if %actor.varexists(questcard6_thetis)%
However: We have a problem when the quest journal auto puts the flags on players. The replacing does not take place. So players may have duplicate flags - both old flags and new flags.
Ahhah, you say. But that is an easy fix - we can move the inner if statements out, eg:
* new function
if !%actor.varexists(questcard6_thetis)%
set questcard6_thetis 0
remote questcard6_thetis %actor.id%
endif
if %actor.varexists(thetis1)%
set questcard6_thetis 1
remote questcard6_thetis %actor.id%
rdelete thetis1 %actor.id%
endif
if %actor.varexists(thetis2)%
set questcard6_thetis 2
remote questcard6_thetis %actor.id%
rdelete thetis2 %actor.id%
endif
if %actor.varexists(thetis3)%
set questcard6_thetis 3
remote questcard6_thetis %actor.id%
rdelete thetis3 %actor.id%
endif
* etc etc
But in this case - each time the actor is on any part of the quest chain and this function is called, eleven if statements will be checked, potentially adding lag to the MUD.
What's the solution?
We have come up with a nifty way to add all questflags on the player once they: go into Limbo, walk into Recall, die, or use the Time Guardian. Of course, you have to send a note to Pix (or Roland) what the new questflags are, and how the old questflags should be replaced. It's even better if you give us a trigger that does this in the first place.
PS: If you are a player when a current quest is added to the quest journal, we suggest you walk to Recall / use the Time Guardian. Otherwise, you might get the new set of flags which signal that you haven't done a quest, but without the replacing of old flags done. While this might allow you to get more token rewards, it also means if you remove and wear a quest equip, it might purge itself.
Recent Posts
-> eg, you can type tsearch all 7958 to see the impact of this.
rej_max_items: How many "special" items will the mob reject? Same like above, we have variables rej1, rej2, ..., and rejspeecha1, rejspeechb1, rejspeechc1, .... etc.