checkquest / questprogress

[kisuka]

We had a heated debate in the staff chat regarding an issue with quest log commands. I'd like to get the community's opinion on this matter.

At the moment, when using checkquest() the returned values are:

• -1 = Quest not started (not in quest log)
  
• 0  = Quest has been given, but the state is "inactive"
  
• 1  = Quest has been given, and the state is "active"
  
• 2  = Quest completed
  

As a scripter, these values have always frustrated me as I couldn't use ! for checking if a user didn't have a quest, as 0 (has quest) would make this true. Not to mention that having 0 as a true value just doesn't make sense.

So for my rewrite of checkquest, now named questprogress() I changed the values to:

• 0 = Quest not started (not in quest log)
  
• 1  = Quest has been given (state is ignored)
  
• 2  = Quest completed
  

This is exactly how the command works in AEGIS. Now, the point at which the debate became heated was in regards to me removing the ability to check if a quest is marked as active or inactive. I explained my reasonings as follows:

• Even though a quest is marked as inactive by a player, it is still considered a quest that is in-progress, and therefore in an active state of having the quest.
   
  
• Displaying different dialog / performing different actions to a player if they marked a quest as inactive can cause for some serious user experience issues (confusion).
  why? Because, let's say a user had accidently marked a quest as inactive, or did it long ago then forgot. Then they went to do the quest and it wouldn't let them progress due to the fact that the quest was marked as inactive. Now you have an upset player who doesn't know what's going on.
   
  
• The inactive/active state in my opinion, is purely cosmetic (how it's displayed in the quest log UI), and should not be used in logic situations such as determining the progress of the quest in a script file.
   
  
• I don't know of any script or script dev that would actively make use of checking if a player has marked a quest as inactive.
   
  
• No official script checks if a user has marked a quest as inactive, because an inactive quest is still a quest that's in progress and therefore active in the eyes of the server.
   
  
• Could cause confusion for new script developers.
  

The debate was to keep the ability to check if a quest is marked as active/inactive vs not having that ability.

I personally didn't see the purpose of such a function, due to the fact that the active/inactive state's function is purely to tell the client where it should show up in the log UI. And that from a script developers perspective, it just doesn't make sense to ever perform differently based on if a quest was marked as inactive in a quest log by the player (because it's often ton to hide a quest for later) because it's still considered an active state.

So, like I said, I've come here to ask your opinion. Would you ever make use of a function to check if a player had marked a quest as inactive? Or do you purely only need the ability to check if they don't have the quest, if they have it, and if they've completed it?

My vote is to only have the three options, as logically it makes more sense. What is your opinion on this matter?

 

[Nameless2you]

I like your idea. Don't see any good argument to keeping the inactive/active state at the moment.

And maybe make checkquest() an alias of questprogress().

 

[evilpuncker]

I like your idea as well, btw add a poll to the topic

 

[kisuka]

I like your idea as well, btw add a poll to the topic

Done

 

[Samuel]

Like three options, much easier to use and understand.

 

[GmOcean]

I completely agree with the removal of those extra values. It's really not needed. Because, I only need to know 2 things, 1) Does Player have quest? Yes/No  2) Is quest Done? Yes/No.

Everything else, is a waste of time imo. It doesn't really matter to me if they obtained the quest but aren't tracking it. Because to me, that is purely for their ease.

It's like this in almost every MMO ever...

1. You obtain a quest.

2. You either choose to track it ( active ) or remove it from your tracking bar since it's not that important ( inactive ).

3. You kill monsters, talk to npcs, etc..

4. Your quest get's updated whether your tracking it or not (active or inactive).

5. You turn it in whether your tracking it or not (active or inactive).

So again, let's just remove it, not needed D:

 

[Dastgir]

I like your idea. Don't see any good argument to keeping the inactive/active state at the moment.

Agree with you and kisuka.

 

[Xgear]

I agree with the possibility to just !check_quest could be good to make things easier, however, if the possibility to detect the quest state is available because the client does send the info to the server, means it *COULD* be used at some point and it does not hurt anyone to have the possibility there to handle the data

However, probably the values returned are not the right ones

• 0 = Quest not started (not in quest log)
  
• 1  = Quest has been given, but the state is "inactive"
  
• 2  = Quest has been given, and the state is "active"
  
• 3  = Quest completed
  

However, since that will probably break a lot of scripts

• 0 = Quest not started (not in quest log)
  
• 1  = Quest has been given, but the state is "active"
  
• 2  = Quest completed
  
• 3  = Quest has been given, and the state is "inactive"
  

I don't like jumping through the numbers but since the amount of times these functions are used are not as much

Or a second command could be implemented check_quest2 to check the UI state of the quest, but I don't agree with removing the functionality completely. 

 

[kisuka]

means it *COULD* be used at some point

In terms of official scripts, it will never be used as that's not how AEGIS handles it. In official, that state is purely for where it shows up in the Quest log UI. AEGIS sees an inactive state in the same light as a quest in active state because it's still considered 'in-progress'.

 

[Xgear]

Yes, but that is not a completely valid argument, we have plenty of features/functions that arent working the same as AEGIS (Either because we have a better way, we lack info or because there are bugs involved otherwise).

In general we try to mimic aegis the best we can, but that doesn't mean we can't do it better by providing a small extra functionality (Remarking small) that doesn't affect the code much. 

I understand your point and I partially agree with it, but I think you're just trying to force it up instead of bending a bit around the idea to make it a bit more flexible. 

 

[kisuka]

Yes, but that is not a completely valid argument, we have plenty of features/functions that arent working the same as AEGIS (Either because we have a better way, we lack info or because there are bugs involved otherwise).

In general we try to mimic aegis the best we can, but that doesn't mean we can't do it better by providing a small extra functionality (Remarking small) that doesn't affect the code much. 

I understand your point and I partially agree with it, but I think you're just trying to force it up instead of bending a bit around the idea to make it a bit more flexible.

I'm all for flexibility but in this case I think it's taking it to a point where it's just making it messy. It feels like it's breaking how quest log is meant to be used. Flexibility is fine, as long as you aren't creating logic that doesn't need to be in place, or are breaking how a function in-game is meant to be used. questprogress and checkquest are commands meant to check your current progress of a quest; a quest in inactive/active state has nothing to do with progress; It is not a step in a user's quest history, it's a UI function controlled by the player.

The active / inactive state can also not be controlled by the server. There is no command to toggle that state for a player. Adding such a command and using it would also cause for some serious game experience issues for a player, as they wouldn't know a quest had been marked as inactive, nor where to find it to re-enable it, etc.

In short, it's not meant to be used in progress checking scenarios, as it's not considered a "step", it's a UI function.

 

[Xgear]

The active / inactive state can also not be controlled by the server. There is no command to toggle that state for a player. Adding such a command and using it would also cause for some serious game experience issues for a player, as they wouldn't know a quest had been marked as inactive, nor where to find it to re-enable it, etc.

In short, it's not meant to be used in progress checking scenarios, as it's not considered a "step", it's a UI function.

Might not be a step, doesnt mean it has no usability:

Lets say you wanna make 3 quests, which require you to kill Poring, Poporing and Drops, you can go to Poring island and AoE it all to finish it fast, how about the scripter wants to only allow "active" quest kills to count in an attempt to increase difficulty?

If we can provide the function without compromising performance, why not do it?

And lets not forget a simple fact, the function is already there, we CANT take it out, its as simple as that, at least not without providing an alternative to mimic the functionality. 

Anyways, I don't wanna turn this into an ABAB discussion, I guess we both stated our POV.

P.S.: Your poll missed a 3rd option to implement an alternative

checkquest(0/1) ftw!

 

[kisuka]

The active / inactive state can also not be controlled by the server. There is no command to toggle that state for a player. Adding such a command and using it would also cause for some serious game experience issues for a player, as they wouldn't know a quest had been marked as inactive, nor where to find it to re-enable it, etc.

In short, it's not meant to be used in progress checking scenarios, as it's not considered a "step", it's a UI function.

Might not be a step, doesnt mean it has no usability:

Lets say you wanna make 3 quests, which require you to kill Poring, Poporing and Drops, you can go to Poring island and AoE it all to finish it fast, how about the scripter wants to only allow "active" quest kills to count in an attempt to increase difficulty?

If we can provide the function without compromising performance, why not do it?

And lets not forget a simple fact, the function is already there, we CANT take it out, its as simple as that, at least not without providing an alternative to mimic the functionality. 

Anyways, I don't wanna turn this into an ABAB discussion, I guess we both stated our POV.

P.S.: Your poll missed a 3rd option to implement an alternative

checkquest(0/1) ftw!

That would be impossible, because a hunting type quest still counts kills for a quest marked as inactive. Regarding the 'we cant take it out' That's is what deprecation means. checkquest will continue to exist and work as it has forever for a period of x months then it will be removed in favor of the new command.

 

[Zephyr]

Personally, I think this way is good. I have custom quests and I need to check if it's active or inactive.

for( set @i, 50009; @i <= 50036; set @i, @i + 1 )if( checkquest( @i ) == 1 && checkquest( @i, HUNTING ) == 1 ) { mes "Do you want to abandon the quest?"; if( select( "No, I'll continue this quest.", "Yes, I want to give up." ) == 1 ) close; dispbottom "You have deleted this quest.."; erasequest @i; close;}

If I can't check if it's inactive, the player can take another quest.

My system is a daily quest that the user can do it 10 times to receive a reward, but they can't take a quest, set it as inactive and take another. If it was like that, I could take a quest to kill 30 Dullahans, set it to inactive, take another, active both and kill 30 (not 60) to complete both together killing just a half.

Screenshots with your way (sorry I'm brazilian):

Take a quest:



Set it as inactive:



Take another quest:



Now I have two quests:



Now, the way it is with screenshots:

for( set @i, 50009; @i <= 50036; set @i, @i + 1 )if( checkquest( @i ) >= 0 && checkquest( @i, HUNTING ) < 2 ) { mes "Do you want to abandon the quest?"; if( select( "No, I'll continue this quest.", "Yes, I want to give up." ) == 1 ) close; dispbottom "You have deleted this quest.."; erasequest @i; close;}
Take the quest:



Set it as inactive:



Can't take another:



Talk to me if you need more translation, but I think you'll understand. I translated both script parts to English for you to understand.

---

That's fine if you guys make the command like that:

• 0 = Quest not started (not in quest log)
  
• 1  = Quest has been given, but the state is "inactive"
  
• 2  = Quest has been given, and the state is "active"
  
• 3  = Quest completed
  

...But if I understood your question wrong, let me know.

 

[GmOcean]

@Zephyr - See, your situation is a matter of just scripting flaw. Instead of determining whether or not to give a player based on whether the quest is active or not, you should be deciding whether or not to give the player the quest depending on whether or not it's complete.

for( set @i, 50009; @i <= 50036; set @i, @i +1 ) {    if( !checkquest( @i ) && getd("quest_limit"+@i+"") <= 10 ) { // Hasn't obtained quest        mes "Do you want to obtain this quest?";        if( select("Yes:No") == 2 ) { close; }        setquest @i;    } else if( checkquest( @i ) != 2 ) { // Has quest but is unfinished.        mes "Do you want to abandon this quest?";        if( select("Yes:No") == 2 ) { close; }        erasequest @i;    } else if( getd("quest_limit"+@i+"") > 10 ) {        mes "You can't do this quest anymore times today.";    } else {        mes "Congratulations! You fished the quest. Did you want to turn it in?";        if( select("Yes:No") == 2 ) { close; }        setd "quest_limit"+@i+"", getd("quest_limit"+@i+"") - 1;        // Obtain Reward.        erasequest @i; //Erase quest again.        if( !getd("quest_limit"+@i+"") ) { setd "quest_limit"+@i+"", gettimetick(2) + (3600 * 24 ); }        mes "Quest turned in.";    }    close;}OnPCLoginEvent:for( @i = 50009; @i <= 50036; @i++ ) {    if( gettimetick(2) > getd("quest_limit"+@i+"") ) { setd "quest_limit"+@i+"", 10; }}end;

 

[Zephyr]

That's fine if I can check if the quest is with the player, even if it's inactive. I thought that checkprogress would return false if the quest were inactive. But I still prefer the way it is, for example, if the user inactive the quest by mistake (it happens a lot, since it's just to right-click), my NPC checks if the quest is inactive and alert the player:

for( set @i, 50009; @i <= 50036; set @i, @i + 1 )  if(checkquest(@i) == 0) {    mes "Oh! You returned alive,";    mes "I thought you were died";    mes "for that stupid monsters,";    mes "I was almost sending reinforcements";    mes "to you.";    next;    mes .@n$;    mes "Please, your mission seems like";    mes "to be inactive at the moment,";    mes "open your quest menu (alt+u),";    mes "click on the 2nd tab and active";    mes "it again. Back to work soldier!";    close;  }
I think this is cleaner, beaultiful, alerts the player, and you can make the player feels good. lol

My whole script for consult:

Spoiler

//-------------------------------// Daily Quests//-------------------------------prt_in,45,102,0    script    Kingdom's Guardian#prt    417,{set .@n$, "^0000FF|^000000 " + strnpcinfo(1) + " ^0000FF|^000000";    if( QuestR != gettime(8) ) {        set QuestR, gettime(8);        set QuestRT, ( getgroupid() ? 10:5 );    }    if( QuestR == 0 ) {        mes .@n$;        mes "Thanks for your help, that's all for today.";        close;    }mes .@n$;    for( set .@i, 50009; .@i <= 50036; set .@i, .@i + 1 )    if( checkquest(.@i) == 0 ) {        mes "Oh! You returned alive,";        mes "I thought you were died";        mes "for that stupid monsters,";        mes "I was almost sending reinforcements";        mes "to you.";        next;        mes .@n$;        mes "Please, your mission seems like";        mes "to be inactive at the moment,";        mes "open your quest menu (alt+u),";        mes "click on the 2nd tab and active";        mes "it again. Back to work soldier!";        close;    } else if( checkquest( .@i ) >= 0 && checkquest( .@i, HUNTING ) < 2 ) {        mes "Do you like to abandon the quest?";        if( select( "No, I'll continue this.", "Yes, I want to give up." ) == 1 ) close;        dispbottom "You abandoned the quest.";        erasequest .@i;        close;    } else if( checkquest( .@i, HUNTING ) == 2 && checkquest( .@i ) != 2 ) {        mes "Mission accomplished";        mes "successfully! Thanks for";        mes "your help soldier!";        // -- My rewards, change for yours. --        // set .@bexp, ( BaseLevel < 80 )?( BaseLevel * 50 + rand(2000,8000) )  BaseLevel * 300 + rand(500000,1000000) );        // set .@jexp, ( BaseLevel < 80 )?( BaseLevel * 30 + rand(1000,2000) )  BaseLevel * 250 + rand(200000,800000) );        // dispbottom "Você ganhou " + .@bexp + " de EXP e " + .@jexp + " de Job.";        // callfunc "gethonor",10,(Sex?"M":"F");        // getexp .@bexp, .@jexp;        // set Honor, Honor + 10;        erasequest .@i;        close;    }mes "Our Kingdom has a team";mes "specialized on kill monsters";mes "to keep the things under control";mes "of this shit. More members,";mes "more easy is to control the number";mes "of monsters that lately is";mes "growing a lot.";    if( BaseLevel < 30 ) close;next;mes .@n$;mes "Would you like to join the team?";    if( select( "Yes, count with me! [" + QuestRT + "]","Not now." ) == 2 ) close;    if( BaseLevel >= 30 && BaseLevel <= 39 ) setquest rand( 50009, 50012 );    if( BaseLevel >= 40 && BaseLevel <= 49 ) setquest rand( 50013, 50016 );    if( BaseLevel >= 50 && BaseLevel <= 59 ) setquest rand( 50017, 50020 );    if( BaseLevel >= 60 && BaseLevel <= 69 ) setquest rand( 50021, 50024 );    if( BaseLevel >= 70 && BaseLevel <= 79 ) setquest rand( 50025, 50028 );    if( BaseLevel >= 80 && BaseLevel <= 89 ) setquest rand( 50029, 50032 );    if( BaseLevel >= 90 && BaseLevel <= 99 ) setquest rand( 50033, 50036 );mes "Good luck!";set QuestRT, (QuestRT - 1 );close;OnInit:waitingroom "Daily Quests",0;end;}

 

[kisuka]

@Zephyr : Not trying to criticize your scripting but why have such a check at all? The script you posted shows that if the player marks the quest as inactive they cannot abandon it, complete it, or get a new one without marking it as active again... that seems like bad user experience / cause for confusion. To limit it to 1 hunting quest at a time it would make more sense to check if a user has any quest 50009 ~ 50036 using checkquest to check for an inprogress quest (remember, inactive/active both count as an active quest. when hunting mobs, if your quest is marked as inactive it will still count the kills), if an quest exists but they didn't complete it then offer them to abandon it.

I don't fully understand the purpose of the inactive state in your script. As all it seems to do is cause a user to go through the hassle of re-enabling it, rather than letting the script handle it for them allowing for a more pleasant gaming experience.

 

[Yommy]

the active/inactive is purely a client side visual effect, for players to chose which tab to put the quest.

there shouldnt be any server logic done with that choice from the server point of view, its just visual.

scripts only really need to know them 3 things..

..player has quest.

..player does not have quest.

..player has completed quest.

Kisuka is right,

that is all.

 

[Zephyr]

In my experience with Ragnarok, I'm not a new user, actually here, yes, but I build servers for about 5 years, and based on what I know, check more is not a issue, it's for protect, users can lag, no server are perfect, and NPCs can be always exploitable, that's why the double-checking.

And @Yommy, you say that Kisuke is right, because was not you that received a topic like that in your forum:

"ADM PLZ THE DAILY QUEST IS NOT WOKRING ANYMORE, I NEED THEM TO UP PLZ FIX IT ASAP WHEN I TALK TO THE NPC HE TALKS TO ABANDON THE QUEST BUT I DONT HAVE ANY HEEEEEEEELP"

Where were the quest? Can you guess? ~

My vote is "NO" for this poll and I'll save the diff to always revert you're doing on removing features. You could just change from "-1" to "0", simple, will not change almost nothing, you'll get your "false" return, and I'll get my "inactive" or "active" status. But instead, you're going to remove, and I didn't like that because my server is entirely based on quests, and I need to check everything, thank you, that's my unchangeable opinion.