Custom quest support
- Jay_H
- Posts: 4072
- Joined: Tue Aug 25, 2015 1:54 am
- Contact:
Re: Custom quest support
Aha, I made a separate victory condition for each item and it works. Apparently the have ___ action doesn't permit multiple triggers leading to a single task.
- Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: Custom quest support
That's interesting! Sounds like we're finally getting to root of problem.
I feel the HaveItem action should probably be able to support this, as each action should have its own discrete item test and target task.
Can you hit me with a minimum repro for that specific problem? I'll see if I can improve this if possible.
I feel the HaveItem action should probably be able to support this, as each action should have its own discrete item test and target task.
Can you hit me with a minimum repro for that specific problem? I'll see if I can improve this if possible.
- Jay_H
- Posts: 4072
- Joined: Tue Aug 25, 2015 1:54 am
- Contact:
Re: Custom quest support
Done!
The action only sticks to the last referenced haveitem action in the quest file. I have two quest files as proof.
This will tick off 3 timers which each grant an item to the player. The victory will only happen when the last one is triggered.
Now, we alter the timers and make it so the last item is given second, and the second item is given last.
The third item opens a loop (unending), prior to the second item's receipt.
I believe this is definite proof of the matter.
The action only sticks to the last referenced haveitem action in the quest file. I have two quest files as proof.
Code: Select all
Quest: HAVEITEM
-- Message panels
QRC:
QuestComplete: [1004]
<ce> Task condition met.
QBN:
Item _a1_ amulet
Item _a2_ letter
Item _a3_ diamond
Clock _S.00_ 00:01
Clock _S.01_ 00:02
Clock _S.02_ 00:03
-- Quest start-up:
start timer _S.00_
start timer _S.01_
start timer _S.02_
have _a1_ set _victory_
have _a2_ set _victory_
have _a3_ set _victory_
_S.00_ task:
get item _a1_
_S.01_ task:
get item _a2_
_S.02_ task:
get item _a3_
_victory_ task:
give pc nothing
end quest
Now, we alter the timers and make it so the last item is given second, and the second item is given last.
Code: Select all
Quest: HAVEITEM
-- Message panels
QRC:
QuestComplete: [1004]
<ce> Task condition met.
QBN:
Item _a1_ amulet
Item _a2_ letter
Item _a3_ diamond
Clock _S.00_ 00:01
Clock _S.01_ 00:03
Clock _S.02_ 00:02
-- Quest start-up:
start timer _S.00_
start timer _S.01_
start timer _S.02_
have _a1_ set _victory_
have _a2_ set _victory_
have _a3_ set _victory_
_S.00_ task:
get item _a1_
_S.01_ task:
get item _a2_
_S.02_ task:
get item _a3_
_victory_ task:
give pc nothing
end quest
I believe this is definite proof of the matter.
- Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: Custom quest support
That's exactly the sort of thing I need. Cheers!
At least you can work around the problem for now, and I'll take a closer look at why this is happening when I can.
At least you can work around the problem for now, and I'll take a closer look at why this is happening when I can.
- Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: Custom quest support
OK, I've worked out the problem.
HaveItem currently works like a toggle action. Just like "pc at" will turn a task on when player is at a certain location and off again when they leave that location, HaveItem will turn the target task on when player has the item and off when player does not have the item.
So what's happening above when everything is sharing the same victory condition is that 1x HaveItem wants to turn the target on while the other 2x HaveItem actions want to turn it off. They're all fighting the system which is why last one in order wins.
There are three ways of fixing this:
First is to use a one-for-one HaveItem > target Task relationship. From there you could even set a final task to act as the victory outcome (a set is one-way and you can pile the actual victory logic under that final task).
Second option is I can change HaveItem from working like a toggle. There's probably I reason I set it this way in the first place though - I believe some quests (Elysana's Robe?) is used to toggle target action this way. I believe this is the way the action is supposed to function. I'd rather not do this without diving back into the behaviours again to verify correct emulation.
The third solution is to ensure that only one HaveItem action is running at a time. So start HaveItem ticking in the same task as the "pick one" outcome to assign item to target Foe. Let me know if this one needs more explanation.
HaveItem currently works like a toggle action. Just like "pc at" will turn a task on when player is at a certain location and off again when they leave that location, HaveItem will turn the target task on when player has the item and off when player does not have the item.
So what's happening above when everything is sharing the same victory condition is that 1x HaveItem wants to turn the target on while the other 2x HaveItem actions want to turn it off. They're all fighting the system which is why last one in order wins.
There are three ways of fixing this:
First is to use a one-for-one HaveItem > target Task relationship. From there you could even set a final task to act as the victory outcome (a set is one-way and you can pile the actual victory logic under that final task).
Second option is I can change HaveItem from working like a toggle. There's probably I reason I set it this way in the first place though - I believe some quests (Elysana's Robe?) is used to toggle target action this way. I believe this is the way the action is supposed to function. I'd rather not do this without diving back into the behaviours again to verify correct emulation.
The third solution is to ensure that only one HaveItem action is running at a time. So start HaveItem ticking in the same task as the "pick one" outcome to assign item to target Foe. Let me know if this one needs more explanation.
- Jay_H
- Posts: 4072
- Joined: Tue Aug 25, 2015 1:54 am
- Contact:
Re: Custom quest support
To be honest, I don't have the foresight to choose any of them. I know the limitations and I can work around them, so you can do any improvements you think are best and I'll adapt to them.
- Interkarma
- Posts: 7247
- Joined: Sun Mar 22, 2015 1:51 am
Re: Custom quest support
Item #1 & #3 are just ways you can work around the current design from within a quest script. Either will do the same job. Probably #3 is the cleanest.
I'd rather not change #2 until I can confirm why I designed that way. I might have done it for a reason, or it could just have been my interpretation at the time. This would be a permanent fix, but I need to make sure I'm not breaking any classic quests. Unfortunately I'm currently deep-diving some other systems and would need to reset my head back to this space. Can revisit it later if you can workaround for now.
I'd rather not change #2 until I can confirm why I designed that way. I might have done it for a reason, or it could just have been my interpretation at the time. This would be a permanent fix, but I need to make sure I'm not breaking any classic quests. Unfortunately I'm currently deep-diving some other systems and would need to reset my head back to this space. Can revisit it later if you can workaround for now.
- Jay_H
- Posts: 4072
- Joined: Tue Aug 25, 2015 1:54 am
- Contact:
Re: Custom quest support
Of course! I don't need a thing changed. Come back to this whenever you want... and let me know if/when my quests are gonna break then
Now with the additional explanation, I'm understanding them better. I believe #3 is certainly the best. I might try revisiting this quest and seeing if I can make this work around more efficiently.
EDIT: Yes, #3 worked. Keeping only one action active at a time is a solution.
Now with the additional explanation, I'm understanding them better. I believe #3 is certainly the best. I might try revisiting this quest and seeing if I can make this work around more efficiently.
EDIT: Yes, #3 worked. Keeping only one action active at a time is a solution.
- Jay_H
- Posts: 4072
- Joined: Tue Aug 25, 2015 1:54 am
- Contact:
Re: Custom quest support
I'm trying to test a quest, and I'm getting this error in the quest log:
What does this refer to?
Code: Select all
Parsing quest JHMG009.txt
Parsing quest JHMG009.txt FAILED!
Argument is out of range.
Parameter name: index