Shop Keeper + Quest Giver

[slickdeath97]

I was wondering if I could get some help with trying to set this event up. I have an NPC in my game that is going to be both a shop keeper and a quest giver. I am using Hime's Choice Options script and need help to use it in the event. Here is how I want to set up the event: Script: http://himeworks.com/2013/03/choice-options/

• The NPC asks you if you want to buy something or take a quest.
• If you choose to do a quest then you get three difficulty options for the quests: Easy, Normal, and Deadly.
• I want to make it to where you can only get one quest at a time.
• I also want to make it to where when you get a quest, you can still talk to him to get into the store, but the quest selection will be disabled.
• Here is a screenshot of what I have set up atm:

Any help would be appreciated.

 

[ShadowDragon]

the easiest way I can think off, is make 3 common events and 3 variables, 3 switches (this can also apply to VC, VX Ace, MV)

common event "easy quest" and variable Easy Quest.
if Easy Quest is ON
if variable "Easy Quest" = 0
(give quest here)
else
You are already doing a quest.
end

if Easy Quest is ON
if variable "Easy Quest" = 1
(give quest here)
else
You are already doing a quest.
end

repeat above to how many easy quest.
the rest apply for Normal Quest and Normal Quest Variable
and for Deadly Quest and Deadly Quest Variable.

if quest is compleet, just add +1 variable so the next one triggers when asking for a quest.

Now make sure to turn on the quest switches on the start (Easy Quest, Normal Quest, Deadly Quest are ON)
when taking a quest, turn those switches OFF, when a quest is compleeted, turn them ON.

This is only 1 way, but the only way I can think off atm

 

[Heirukichi]

I would like to suggest a different solution, although the one above does indeed work. The main reason is that I think that this solution makes use of less common event and variables.

All you need is 1 variable and 3 switches.

If the player selects "Quests" you check that variable, when that value is 0, it means there is no active quest, otherwise you show a "You are already on a quest" message. When there is no active quest you change the variable according to the quest selected (1: Easy, 2: Normal, 3: Hard) and show its relative messages. Of course, you need a check to see if any of those has already been completed, but since you stored the value of the quest taken in a variable, this branch can be independent.

Since you have already stored the quest difficulty in the variable you can simply use conditional branches to display the quest-related messages, without having to use common events. This ensures that you have everything in one place and allows you to easily control your flow.

Once the quest is finished you can turn the variable back to 0. And the switch relative to that quest ON.

EDIT
To be honest you could to this with just 1 variable without having to use switches by using a different logic.

Spoiler: How to do it

Quest 1 taken: Variable += 3
Quest 2 taken: Variable += 7
Quest 3 taken: Variable += 13
if (Variable % 2 != 0)
  You are not on a quest
else
  You are on a quest
end

In this case you can add 1 to the variable whenever a quest is completed, the result will be the following:

Quests Completed:
1 -> Variable = 4
2 -> Variable = 8
3 -> Variable = 14
1 and 2 -> Variable = 12
1 and 3 -> Variable = 18
2 and 3 -> Variable = 22
all -> Variable = 26

As you can see there is no ambiguity here. The conditions to check if a quest is available or not can be these:

if (Variable < 26)
  if (Variable < 14)
    Quest 3: available
  end
  if (((Variable % 7) % 2) == 0)
  # alternatively you can use if ([4, 14, 18].include?(Variable))
    Quest 2: available
  end
  if ((Variable % 7) < 2)
  # alternatively you can use if ([8, 14, 22].include?(Variable))
    Quest 1: available
  end
end

This way switches become useless and you can use a single variable, but this requires a bit of fore thinking and only applies if you have 3 quests, if you have more, the logic must be different.

 

[ShadowDragon]

@Heirukichi the use for 1 variable is nice, but to be honest, I dont quit understand it.
it would be alot of think work if you have 25 or more.

Although, I didn't know that way either, but the way I did it, was kinda use friendly if they are new to the maker.
As well for a nice clean setup to refer back too if you make a mistake, would be harder in your case.

Especially if you have figured out 10 quest and you want to add a bunch more, you need to redo alot
to re-correct it. but for small amount of quests, it seems usefull though =)

 

[Heirukichi]

@ShadowDragon that is why the one-variable-solution with no switches is in the spoiler. It is not user friendly at all and I know it, although, especially if the OP wants to offer the player a chance to only pick one among three quests it should fit perfectly (I already did the think work XD).

Speculating about possible solutions that are easier to handle and, at the same time, are useful to save memory, something like this is also possible.

Spoiler: Optimal solution

2 variables: one for quest taken, the other to store quests completed.
Variable to store quest completed -> Quests Variable.
Variable to store quest taken -> Current Quest Variable.

Once those two variables are decided, we have to define a couple of IDs.
On quest -> ID = 0
Each quest will have an ID assigned that is equal to or greater than 1.

The quest variable starts at 0. When a quest is picked, the following happens:

Quest Variable += 1
Current Quest Variable = Quest ID

When a quest is completed, the Quest Variable gets reduced by 1, and then you add a value that is

(2 ** Current Quest Variable)

In short, you can do this:

Quest Variable -= 1
Quest Variable += (2 ** Current Quest Variable)
Current Quest Variable = 0

In this situation, to see if a certain quest can be taken or not you have to set the following conditions:

Pseudocode:
if (Quest Variable % 2 == 0)
  Quest Value = 2 ** Quest ID
  if (Quest Variable & Quest Value != Quest Value)
    Assign Quest
  else
    Show Message "You have already completed this quest."
  end
else
  Show Message "You are already on a quest."
end

This requires 0 fore thinking and can store a lot of multiple quests in a single variable. It can be extended to an unlimited amount of quests as long as you are smart enough to store your quest data. You can use an array (recommended) or different variables, but this allows you to store MANY quests taken in a single variable.

NOTICE:
The syntax here is the same in JavaScript and Ruby so this solution can be used in any Maker from XP onward.

 

[slickdeath97]

@Heirukichi and @ShadowDragon I really appreciate the help, but some of my quests already run on variable, and I already have a crap ton of switches. I have a switch that is used for when a quest is accepted:
I also am using a battle quest add on for battle quests.
I am also using Hime's Choice Options script, so I am trying to find out a way to implement that with the quests so that when a quest is already being done the Quest option will be grey and disabled from being chosen.

 

[Heirukichi]

@slickdeath97 it doesn't matter if you already have a variable or not, the variable I mentioned in my post(s) only takes into account quest completion. Using Hime's Choice Option script you should be able to gray out options related to that quest. In both my posts you have conditions to see if a certain quest can be taken or not, you just have to use those conditions in Hime's script instead of using them in an if/else branch.

 

[slickdeath97]

@slickdeath97 it doesn't matter if you already have a variable or not, the variable I mentioned in my post(s) only takes into account quest completion. Using Hime's Choice Option script you should be able to gray out options related to that quest. In both my posts you have conditions to see if a certain quest can be taken or not, you just have to use those conditions in Hime's script instead of using them in an if/else branch.

Was wondering what you might think of this idea:

• Set a conditional branch before being able to select shop or quest
• If one of the quests is already accepted then the quest selection is greyed out and disabled
• If not then you can select a quest to do.
• If there is a quest that is accepted then another choice pops up called Turn In A Quest
• If you don't have a quest accepted from him then that option is not in the choices

 

[Heirukichi]

It is basically the same that we both suggested, with the addition of having the choice "Turn in a Quest" pop up. The game is yours, we can give you the logic to handle something, but besides that every other choice is yours. If you think that such a solution fits your game aesthetics, then go for it.

 

[slickdeath97]

It is basically the same that we both suggested, with the addition of having the choice "Turn in a Quest" pop up. The game is yours, we can give you the logic to handle something, but besides that every other choice is yours. If you think that such a solution fits your game aesthetics, then go for it.

Ok, I really do appreciate the help, I will try it out and see what happens.

 

[slickdeath97]

Ok so here is how I have it set up atm:


When i accept the quest it goes fine until i talk to the guy again, When i talk to him after accepting the quest i get this error:

How do I fix this?

 

[Heirukichi]

That error is something you get when what you wrote in a script call or in a script box is somehow wrong or when there is an error with something related to it. What I can tell you at a first glance is that you have used

$game_quests[:Bloody_Slimes].accepted?

in your conditional branch script box, but then you used

$game_quests[:Bloody_Slimes].accepted

in the script call. Which one is the correct form?

 

[slickdeath97]

That error is something you get when what you wrote in a script call or in a script box is somehow wrong or when there is an error with something related to it. What I can tell you at a first glance is that you have used

$game_quests[:Bloody_Slimes].accepted?

in your conditional branch script box, but then you used

$game_quests[:Bloody_Slimes].accepted

in the script call. Which one is the correct form?

When i used
$game_quests[:Bloody_Slimes].accepted? in the script box it still gave the same error.
$game_quests[:Bloody_Slimes].accepted? this is what the script call is supposed to look like but it gave me the same error

 

[Heirukichi]

The problem lies within the fact that, according to Hime's script, the condition has to be a string that can be evaluated. Put it between quotation marks and you will solve your issue.

disable_choice(2, "$game_quests[:Bloody_Slimes].accepted?")

This is how it is supposed to look like.

 

[slickdeath97]

The problem lies within the fact that, according to Hime's script, the condition has to be a string that can be evaluated. Put it between quotation marks and you will solve your issue.

disable_choice(2, "$game_quests[:Bloody_Slimes].accepted?")

This is how it is supposed to look like.

Ok so that worked, Now how would it look with more than one quest? Say for example you got either the Bloody Slime Quest or the Devils Layer Quest?
Would it by chance look like this:
disable_choice(2, "$game_quests[:Bloody_Slimes].accepted?" || "$game_quests[Devils_Layer].accepted?")

 

[Heirukichi]

Yes, it would look like that, but this is precisely why I recommend using a single switch/variable to check if the player is on a quest, and then separate switches/variables for quest completion. This way you can handle everything in a simple condition, otherwise that condition is going to be insanely big and might end up not fitting the script call box, which might (or might not, depending on how you write it) cause troubles.

 

[slickdeath97]

Yes, it would look like that, but this is precisely why I recommend using a single switch/variable to check if the player is on a quest, and then separate switches/variables for quest completion. This way you can handle everything in a simple condition, otherwise that condition is going to be insanely big and might end up not fitting the script call box, which might (or might not, depending on how you write it) cause troubles.

Ok, I will see what I can do. If I come across any more problems I will let you guys know. Thank you so much for the help.