FF6WC: Better Objective Parsing, Prevent Softlocks with Unique Boss Count, Fix Starting Espers processing, remove APItem from shops #6
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is this fixing or adding?
This PR accomplishes several items which have been under discussion in the AP Discord server for this game.
Remove ArchplgoItem from shops
The implementation of the AP version of FF6WC required that an item be sent for processing to work correctly. The original implementer chose to alter the RenameCard, an item which allows you to rename characters but has no other inherent gameplay functionality, to be the ArchplgoItem which is what is used to pass rewards to the FF6WC player and is collected by them to send to other players.
When this item that had been re-purposed from the RenameCard showed up in shops, this was very confusing for newer players as they may have thought that they needed to purchase the item to complete a check, however, that is not the case since it's not actually a check, just a repurposed item. Removing them from shops avoids any confusion and does not detract from any gameplay.
Verifying Objective flagstring at AP Generate time vs. FF6WC Launch time
There have been several cases of people using custom flagstrings which should have caused syntax errors in the first pass of the parser in the verify_flagstring method which is called from generate_output in init.py. This caused the AP multi-world game to Generate, however, when attempting to actually play the game via Launch, an error would be thrown due to a bad objective string. This was frustrating for those running larger async rooms as the multi-world game in some cases would start, but this FF6WC seed would be unplayable because it contained an error.
Most of the Objective parse problems are caught during parse phase which is what the verify_flagstring method calls except for the case where there was a result specified, but no condition arguments after the condition type was specified. This scenario is now detected properly at parse time instead of log or run time.
Prevent softlocks due to requiring a boss count higher than the number of unique bosses that the game has placed.
If selecting the RandomizedBosses option in the yaml or -bbr flag and having a Kefka Unlock objective that requires a number of bosses condition for completion or using the BossCount option in the yaml, the game only counts unique bosses towards that goal, not total bosses. This can lead to cases where a person may select a large number of bosses to beat the game, however, the game will not place enough unique bosses in the game to get to that unlock objective condition.
The game already had this logic for specific bosses and dragons to be placed in the required boss/dragon pool as well as ensuring that there were enough unique dragons for a potential Kefka Unlock objective condition, but did NOT do the same with the number of bosses. This processing has been added to prevent future softlocks. There is a manual prevention mechanism in the generate_objectives_string method of Options.py to reduce the BossCount value to 18 maximum, this code can also be removed now.
See for additional detail: https://discord.com/channels/666661907628949504/1235621693381410906
The Starting Espers flag -stesp was not supported by the AP version of the code.
This is because the AP code needs to pick all of the rewards for all worlds prior to the FF6WC code getting control that would pick the starting espers, so there would be times were errors would occur in the Launch phase of the game. Some handshaking going back & forth between the code has been added in such that the AP code will pick the X specific starting espers and add them to the precollected items for this player. This means that the FF6WC code must accept a new flag to indicate which specific espers were selected during the AP Generate phase and add them to the inventory as per usual, but the selection of the espers is now done in AP code vs. FF6WC code.
How was this tested?
Remove APitem from shops
I used the -sl flag to print a spoiler log when seeds were generated. I verified that the ArchplgoItem does NOT appear in any shops.
Verifying Objective flagstring at AP Generate time vs. FF6WC Launch time
I used 3 different yamls for this, 2 of which came directly from the AP Discord, another I created for all of the different parts of the objective string parsing steps where an error could occur.
Flagstring: -cg -oa 2.3.3.2.12.12.4.24.24.6.8.8 -ob 3.1.1.2.9.9.4.12.12.10.21.21 -oc 30.8.8.1.1.11.8 -od 59.1.1.11.31 -oe 8.4.4.3.1.3.3.3.3.3.5.5.5.8.12 -of 40.4.4.3.6.3.3.0.9.2.5.16.12 -og 13.5.5.3.8.3.3.7.7.9.9.9.10.5.17 -sc1 randomngu -sal -sn -eu -csrp 85 130 -fst -brl -slr 3 5 -lmprp 75 125 -lel -srr 25 30 -rnl -rnc -sdr 1 1 -das -dda -dns -sch -scis -com 98989898989898989898989898 -rec1 28 -rec2 27 -rec3 6 -rec4 24 -rec5 97 -xpm 4 -mpm 4 -gpm 4 -nxppd -lsbd 3 -hmbd 2.5 -xgbd 2 -ase 2 -msl 97 -sed -sfb -bbs -drloc mix -stloc shuffle -be -res -fer 0 -escr 100 -dgne -mmnu -cmd -stesp 1 1 -esr 2 4 -elrt -ebr 80 -emprp 75 125 -emi -nm1 random -rnl1 -rns1 -nm2 random -rnl2 -rns2 -nmmi -mmprp 75 125 -gp 5000 -smc 1 -sto 1 -ieor 40 -ieror 40 -ir standard -csb 20 20 -mca -stra -saw -sisr 15 -sprp 75 120 -sdm 5 -npi -snbr -sebr -snes -snsb -sesb -snee -snil -ccsr 15 -chrm 5 5 -cms -name TERRA.LOCKE.CYAN.SHADOW.EDGAR.SABIN.CELES.STRAGO.RELM.SETZER.KRILE.GAU.GOGO.GREG -cpal 0.1.2.3.4.60.6 -cpor 334.327.320.332.321.330.319.333.329.331.373.322.325.104.46 -cspr 330.1.2.3.4.5.255.7.104.9.84.11.12.72.14.61.107.19.20.21 -cspp 2.1.4.4.0.0.3.3.3.4.0.3.3.5.1.0.0.1.0.3 -frw -wmhc -ahtc -cor 80 -crr 80 -crvr 100 120 -crm -cnee -cnil -ari -anca -adeh -ame 1 -nmc -nil -noshoes -u254 -nfps -fs -fe -fvd -fr -fj -fbs -fedc -fc -ond -scan -etn -ymain
Errors occur in multiple objectives in this flagstring and I removed erroneous ones to test only the code paths that were updated when needed.
Objective E is missing a max condition argument.
-oe 8.4.4.3.1.3.3.3.3.3.5.5.5.8.12
Result: 8 -> Auto-Haste
Conditions Required: 4.4 -> needs to complete 4 out of 4
Condition 1: 3.1 -> Recruit Locke
Condition 2: 3.3 -> Recruit Shadow
Condition 3: 3.3 -> Recruit Shadow (yes a second time)
Condition 4: 3.5 -> Recruit Sabin
Condition 5: 5.5 -> Esper Shoat
Condition 6: 8.12 -> Bosses 12-?
This is missing a second condition argument telling it the upper range for the number of bosses to kill to complete this objective.
Error Message with fix:
Objective F is missing a condition argument.
-of 40.4.4.3.6.3.3.0.9.2.5.16.12
Result: 40 -> Illumina
Conditions Required: 4.4 -> needs to complete 4 out of 4
Condition 1: 3.6 -> Recruit Celes
Condition 2: 3.3 -> Recruit Shadow
Condition 3: 0 -> None (this just gets ignored, but it's weird to have it in here)
Condition 4: 9.2 -> Boss AtmaWeapon
Condition 5: 5.16 -> Esper Ragnarok
Condition 6: 12 -> Quest ?
This is missing a condition argument indicating which Quest needs to be completed
Error message with fix:
Flagstring: -cg -oa 2.5.5.2.6.6.4.9.9.1.r.1.r.1.1.r -ob 3.1.1.2.9.9.4.12.12.10.21.21 -oc 30.8.8.1.1.11.8 -od 59.1.1.11.31 -sc1 random -sc2 randomngu -sal -eu -csrp 80 125 -fst -brl -slr 3 5 -lmprp 75 125 -lel -srr 25 35 -rnl -rnc -sdr 1 2 -das -dda -dns -sch -scis -com 98989898989898989898989898 -rec1 28 -rec2 27 -xpm 2 -mpm 5 -gpm 5 -nxppd -lsc 1 -hmc 1 -xgc 1 -ase 2 -msl 40 -sed -bbs -drloc shuffle -stloc shuffle -be -bnu -res -fer 0 -escr 100 -dgne -wnz -mmnu -cmd -esr 2 5 -elrt -ebs -emprp 75 125 -eebr 6 -emi -nm1 random -rnl1 -rns1 -nm2 random -rnl2 -rns2 -nmmi -mmprp 75 125 -gp 100000 -smc 3 -sto 1 -ieor 33 -ieror 33 -ir standard -csb 6 14 -mca -stra -saw -sisr 20 -sprp 75 125 -sdm 5 -npi -sebr -snsb -snee -snil -ccsr 20 -chrm 0 0 -cms -frm -wmhc -ahtc -cor 100 -crr 100 -crvr 100 120 -crm -ari -anca -adeh -ame 1 -nmc -noshoes -u254 -nfps -fs -fe -fvd -fr -fj -fbs -fedc -fc -ond -scan -warp -move bd -etn -yremove
The other one seems to have been already caught in another part of the parsing process before verify_flagstring gets called, so this one also properly fails, but not using either of my new paths I put in place:
If this makes graphical changes, please attach screenshots.