Feature - Implemented improvements to quest tracking

roippi

Developer
Current status quo: at login, load three pages of questlog.php, parse them, and store quest completion data in QuestLogRequest.java.

problems:

-three unnecessary pageloads.
-most quests are still not tracked
-character state can still get out-of-sync

solution:

Store quest completion data in preferences. (lastXXX format) Load state from preferences on login. If we visit questlog.php, parse it then and adjust preferences.

see Veracity's post here for more details.

----

The number of quests that QuestLogRequest currently parses is surprisingly small:

chatAvailable
dungeonOfDoomAvailable
whiteCitadelAvailable
friarsAvailable
blackMarketAvailable
hippyStoreAvailable
hermitHax0red (already a preference)

I envision tracking for not only the above (which are required to set availability of NPCs, stores, etc) but also pretty much every council, guild, and miscellaneous quest through freeing the king. This will allow us to close out a good number of bug reports/feature requests.
 

Theraze

Active member
Would it make sense to request an api.php for quests, so we can do a single pageload instead of 3 and make certain that it's up to date on initial login?
 

roippi

Developer
The one hit on login might be a good compromise to make sure it's up to date, but we should probably still parse questlog.php whenever we visit it in-run.
 

Theraze

Active member
Definitely... it feels stupid when writing scripts to have 5 server hits to check on the quest status. I'm trying to reduce them as I go so that it only checks to validate that we are actually on the step that I think we're on, and if we haven't done any actual questing between steps, don't hit the server to validate that we really haven't done anything in the half second since the last hit... but being able to reduce all of those and just parse preferences would be a nice asset.

The initial hit would just be good though so that we can tell people that updating and restarting mafia should fix their problems if it gets out of sync... we don't have to have them do the 3+ extra hits from parsing the questlog. If they actually go to the questlog immediately instead of checking the council and wandering lost and confused for a bit trying to solve the problem themselves... :)
 

slyz

Developer
I was wondering about how certain quests would be tracked, since most of them involve multiple steps. Maybe hitting questlog.php at start-up instead of simply relying on preferences would allow for more complicated tracking internally (and it would be exposed to users via ASH functions).

Doing the same thing with only one preference per quest would mean using ints or strings instead of booleans, and scripters would need extra functions to interpret the preference.
 

roippi

Developer
If we follow the current idiom, they are usually ints in the form lastXXX, i.e. lastTempleUnlock. The number is the last ascension that you did it. No reason you can't have multiple prefs for one quest. In fact the level 11 quest has a -ton- already.
 

Theraze

Active member
Potentially... but if the existing preferences keep their values, and new preferences get int or string values, it wouldn't break anything.

Or, y'know, multiple values per quest. :) Which has the added advantage of not telling you which order you should be doing the steel organ quests in, etc.
 

Nifft

Member
Can whoever ends up planning this feature out... please create a list of the current and new prefs they plan to use to encompass the overall coverage (and if any aren't totally obvious which quest/step they go with), so additional requests for any that were missed or any quests that need subdivided more can be made before the development gets too far along?

Please/thanks!
~ Nifft
 

matt.chugg

Moderator
I'd like to know a bit more than if the quest is done, for example, I propose (starting with the easiest I think)

for the larva quest, 3 boolean preferences: questLarvaStarted, questLarvaFound, questLarvaComplete to indicate whether the council has given the quest, whether the larva has been found (even if the quest isn't complete) and whether you have completed the quest (thanks from the council..) these would then be reset upon ascension.

Slightly selfish start from me, as I would like this so I can complete the patch to decorate top level choice adventures in the forest.

patch attached! (compiles and works (not tested ascending) on test character)
 

Attachments

  • questLevel1.patch
    2.9 KB · Views: 31
Last edited:

lostcalpolydude

Developer
Staff member
Three separate settings? Maybe questLarvaStatus could be "" or "started" or "completed" (check for larva in inventory along with "completed" for scripts, perhaps). The exact details could be changed, but 1 preference seems sufficient.
 

matt.chugg

Moderator
fair point, 3 might be overkill!

if people agree with that, i'll work up a new patch..

I think the first few quests will be fine with "" | "started" | "complete"

questLarvaStatus = "" | "started" | "complete"

and for next few quests

questTavernStatus = "" | "started" | "complete"
questBossBatStatus = "" | "started" | "complete"
questKnobKingStatus = "" | "started" | "complete"

I'm sure there might be better names though, but I like the form "questSomethingStatus"

also, is the council visited at login, would text from the completed quests also be parsed from genericrequest (should I add completed quest text too)
 

Veracity

Developer
Staff member
The text of the Quest Log? I don't like it. We read - and parse, for our own uses - the Quest log at login, but we can detect the starting and completion of quests after that by seeing what the Council - or the Tr4pz0r or the Untinker or whoever - says to us.

FWIW, we have a preference for the Island War:

warProgress: unstarted | started | finished
 

matt.chugg

Moderator
What if we dumped all the text to 3 preferences? o_0

:O that would work!

3? Council Text, Completed Quests text and Current Quests text?

although... would there be any need to store it in a preference?


just thinking...

3 internal (java) variables/functions, members of KoLCharacter? updated on login, and every time the page is visited

KoLCharacter.currentCouncilText
KoLCharacter.currentCompletedQuests
KoLCharacter.currentQuests

then 3 ash functions with optional boolean parameter to force a server hit to refresh that wrap it

string CurrentCouncilText(boolean refresh=false)
string currentCompletedQuests(boolean refresh=false)
string currentQuests(boolean refresh=false)


I could be miles off the mark there though!!!!
 

roippi

Developer
So - in general, storing something in a preference means that the data persists across logins. In this case, I think you always want to hit quest.php at login to ensure mafia's state is synced with the game's. So, storing the quest data doesn't really help you, unless we want to decide to completely avoid hitting quest.php at login. And I'm not sure we can do that.
 

matt.chugg

Moderator
Attached is a patch that adds 4 new preferences for quest tracking quests 2, 3, 4 and 5 (larva to goblin king):

Code:
user	questStatusLarva	unstarted
user	questStatusTavern	unstarted
user	questStatusBossBat	unstarted
user	questStatusGoblinKing	unstarted

values of these are set to "started" or "finished" depending on quest status (based on text from the council, or questlog, or possible from the adventure response itself (tavern doesn't require council visit to complete quest) and then reset to unstarted when one ascends

It looks like mafia already hits questlog on login, so these are all synced at login. (at least from unstarted, if somehow a quest preference is set to "finished", when it hasn't been started then it can't update, but I don't think that really possible without manually setting it.)

since warProgress already uses "unstarted" "started" "finished" I figure I should keep using the same.

Am I barking up the right tree, am I even in the right forest?!
 

Attachments

  • questTracking2-5.patch
    4.7 KB · Views: 34
Top