Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FF6WC: Better Objective Parsing, Prevent Softlocks with Unique Boss Count, Fix Starting Espers processing, remove APItem from shops #6

Closed
wants to merge 1 commit into from

Conversation

BriGuy7727
Copy link

@BriGuy7727 BriGuy7727 commented Jan 16, 2025

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:
image

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:
image

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:
image

If this makes graphical changes, please attach screenshots.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant