server
server copied to clipboard
🐛 A Boy's Dream locks progression if you get the odonto ra/ex item before trading Ailbeche the Shell Bug
- [x] I have paid attention to this example and will edit again if need be to not break the formatting, or I will be ignored
- [x] I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated
- [x] I have read and understood the Contributing Guide
Branch affected by issue
base
Steps to reproduce
This is visible in Ailbeche's lua: relevant lines This needs retail verification
Steps: Start PLD AF2 A Boy's Dream. Immediately go to get the Odontotyrannus Try to progress the quest normally. Due to the lua we have, Ailbeche will not progress the CS var for this quest because it is specifically checking that the player does not have that item in their inventory (maybe the intent was to make sure they're not trying to trade the Giant Shell Bug and the Odonto at the same time? I have no idea here, just guessing) This effectively locks the player out of the quest. FFXIclopedia actually recommends people to do this BGwiki does not (it just lists the steps in the normal order, with no mention of the odonto until trading it to Ailbeche after trading the Giant Shell Bug, and has this step as optional)
Expected behavior
Unless retail follows this behavior, this quest should be changed to not care if the player has obtained the ra/ex prior to trading the Giant Shell Bug to Ailbeche. On a personal note, if retail DOES behave this way, I see no reason this can't be configurable for quests like this, as it has no effect on the progression (they still have to go out, fish up an NM and defeat it to get the item, it just changes when this can be done)
Edit: ffxiclopedia does in fact have a line that tells players to skip trading the Giant Shell Bug and going straight to getting the odonto.
iir you can accidently reset yourself to earlier steps if you trade wrong item for the wrong steps, but it's been awhile
going by the 2 lua files (northern sandy/npcs/Ailbeche and selbina/npcs/Zoland) it shouldn't
Ailbeiche:
elseif (aBoysDreamCS == 2) then
player:startEvent(46) -- During Quest "A Boy's Dream"
elseif (aBoysDreamCS == 3) then
player:startEvent(39) -- During Quest "A Boy's Dream" (after exoroche cs)
elseif (aBoysDreamCS == 4) then
player:startEvent(60) -- During Quest "A Boy's Dream" (after trading bug) madame ?
elseif (aBoysDreamCS == 5) then
player:startEvent(47) -- During Quest "A Boy's Dream" (after trading odontotyrannus)
elseif (aBoysDreamCS >= 6) then
player:startEvent(25) -- During Quest "A Boy's Dream" (after Zaldon CS)
Zaldon
elseif player:getCharVar("aBoysDreamCS") == 5 and npcUtil.tradeHas(trade, 4562) then
player:startEvent(85)
Are these event calls (player:startEvent(x)
) what's setting aBoysDreamCS ?
If I'm wrong, this could be accounted for by checking the aBoysDreamCS
value in the trade instead of just saying NO if they already have the odonto (to prevent triggering the trade rolling back the CS value)
Instead of this:
if (player:getCharVar("aBoysDreamCS") >= 3) then
if (trade:hasItemQty(17001, 1) == true and trade:getItemCount() == 1 and player:hasItem(4562) == false) then
player:startEvent(15) -- During Quest "A Boy's Dream" (trading bug) madame ?
elseif (trade:hasItemQty(4562, 1) == true and trade:getItemCount() == 1) then
player:startEvent(47) -- During Quest "A Boy's Dream" (trading odontotyrannus)
end
end
it should be
if (trade:hasItemQty(17001, 1) == true and trade:getItemCount() == 1 and player:getCharVar("aBoysDreamCS") == 3) then
player:startEvent(15) -- During Quest "A Boy's Dream" (trading bug) madame ?
elseif (trade:hasItemQty(4562, 1) == true and trade:getItemCount() == 1 and player:getCharVar("aBoysDreamCS") == 4) then
player:startEvent(47) -- During Quest "A Boy's Dream" (trading odontotyrannus)
end
Edit: Changed the CS values I'm checking against here because these are the ones that worked when I tested it.
the variable would get set on cs completion, all that is the logic telling it which cs to play (which doesn't mean that logic is good!)
I'll test my solution locally. At the very least, if it doesn't get PRed here for whatever reason, it'll lower the problems our players are having with this quest.
ultimately the quest will get redone for the interaction system, but for now I'd stamp tested fixes for it.
I put in a PR for this.