New Content - Implemented Manual of Numberology

Revision 16399 now lets "numberology 69" actually cast the skill and handle the resulting choice. The command will not let you use a "Try Again" result, and will fail with a helpful "try again in N turns" sort of message if the result is not currently available.

I need to make sure that session logging looks good; I had a bug in today's single attempt at this and it stopped after submitting the use skill request (which correctly redirected to the choice adventure) before it submitted the choice. Fortunately, simply typing "choice.php?whichchoice=1103&option=1&num=14" (where 14 was the correct seed for result 69) into the gCLI resulted in "You gain 3 Adventures".

Also to come will be ASH support. I have the primitives all set up in NumberologyManager to make it easy, a la what NumberologyCommand does.

I also need to make sure that _universeCalculated is set appropriately in ChoiceManager, so it will work even from the Relay Browser, not just from the numberology CLI command.
 
I've noticed that any given result is available in 0, 1, 2, or 3 turns. The 61 non-Try-Again results are split into 4 sets, which form a cycle. I wonder what the math is behind this? Given the non-"Adventures Left" component of the formula, is it mathematically guaranteed that there is a cycle of four subsets of 61 numbers?
 
Checking on another character, and there are obviously wrinkles; those cycles I mention apply to my main character at level 21 and 15 spleen.

Another character at level 60 and 15 spleen has only 3 numbers currently available, and "numberology 69" says it will be available in 8 turns.
 
I think setting _universeCalculated in ChoiceManager will only set it once a number is submitted (even if the result is Try Again), and not set it if you cast the skill and then walk away to adventure. I couldn't find any current place to put it to not work that way, at least. Maybe preChoice() before the initial return?

Getting PvP fights from this isn't parsed. I guess other sources of fights result in a charpane refresh, so we were able to get away with not parsing it, and we only look for "PvP Fight" for a few specific things (shrub/goth kid basically).
 
I think that visitChoice is the place. That is called when we see the choice for the first time, before actually submitting an option. From what I can tell, when you cast the skill, you see that page - and that's it. Submit it before you adventure, or lose it.

We just have to make sure we can recognize which choice it is. I got a DEBUG log today and when I cast the skill, it redirected to choice.php?forceoption=0 and in the result text, there was a form to submit with the "text" field for the number and whichchoice of 1103. I expect I can use that responseText to test.

Sounds like we should parse PVP fights from choices. Is there any reason we shouldn't make that part of general result processing? Can you get a DEBUG log of what you get when you make that choice, please? I'm done with PVP until next season, and even then, unless/until I decide to try to compete again, rather than simply get the season's swagger reward, I doubt that a few extra PVP fights will ever be worth more to me than a few extra adventures.
 
It probably should be part of general result processing. Which I should be able to handle, though it's been a while since I looked at that code.

That's the type of thing that's easy to test repeatedly on a devster until it works right, so I expect I'll take care of that tomorrow.

I tend to value my extra progress toward Essence of Annoyance (next at 35k) more than a few more turns spent going for an ultra rare (for a ribbon). Neither one is worth all that much, but meat farming is kind of pointless with a subscription set up...
 
By the way - if there is no charpane refresh in the result from this choice.php, that's a KoL bug. You can get Meat, adventures, or PvP fights, all of which affect the charpane.
 
Veracity said:
I've noticed that any given result is available in 0, 1, 2, or 3 turns. The 61 non-Try-Again results are split into 4 sets, which form a cycle. I wonder what the math is behind this? Given the non-"Adventures Left" component of the formula, is it mathematically guaranteed that there is a cycle of four subsets of 61 numbers?
Click to expand...

Veracity said:
Checking on another character, and there are obviously wrinkles; those cycles I mention apply to my main character at level 21 and 15 spleen.

Another character at level 60 and 15 spleen has only 3 numbers currently available, and "numberology 69" says it will be available in 8 turns.
Click to expand...

The number of cycles is given by gcd(100, level + spleen use); in this case you have gcd(100, 36) = 4. The math involved is the modular arithmetic I mentioned a page back; the premise is that you can only reach some set of numbers if you start at B and keep adding A (this might be easier to see modulo 10: if you keep adding 10, the last digit will not change; if you keep adding 5 to A, the last digit will only take two values; if you keep adding 2, the last digit will take on either even or odd values only, yielding five values). Obviously certain values are really bad (e.g. level + spleen use = 100).

In the course of an ascension, you can typically guarantee nice results, especially if you can fill your last three spleen with wads (of any four consecutive numbers, at least 1 will be coprime with 100, i.e. you'll be able to reach any target value without spending adventures).
 
Yeah. I was thinking about this before getting out of bed this morning and was pondering gcd - and then I realized that you had discussed this before and I didn't pay enough attention. I came to acknowledge that - and here you are again. Thanks. :)

I am content with the output of the numberology command - although it might be nice to say "you can get result Z in X turns or Y spleen". Since I don't care (so far) when, exactly, during the day I get my prize, running a few adventures is not a hardship - especially if I've already filled up on spleen, although, perhaps I should be more careful about that...

I think it will be nice to refine my primitives to use this math more. Something like:

int partitions()
int current_partition()
int partition( result )
int turns_until_partition( n ) -> ( n + partitions() - current_partition() ) % partitions()
int spleen_until_partition( n ) -> something
int result_to_seed() -> something

... for example.

I think deciding what ASH functions to expose will wait until that work is done; it is reasonable to want to know the set of currently available results, but if the only reason Bale wanted "what results are available in N turns" is to brute force the solution to turns_until_partition( partition( result ) ), perhaps we can do better.

It will be a few days before I have time to think more about refactoring NumberologyManager and NumberologyCommand to use the math that you have shared. If you feel the urge to do it yourself, don't be shy. ;)
 
Veracity said:
We just have to make sure we can recognize which choice it is. I got a DEBUG log today and when I cast the skill, it redirected to choice.php?forceoption=0 and in the result text, there was a form to submit with the "text" field for the number and whichchoice of 1103. I expect I can use that responseText to test.
Click to expand...
Code: 
[color=green]> test load maths.html[/color]

Read 8,026 bytes into a 8,026 character string

[color=green]> test visit-choice[/color]

choice = 1103
We should be good to go. I'll move setting _universeCalculated to visitChoice and try it out.
 
No go. I cast the skill in the relay browser, which redirected to the choice. Here is my session log:

Code: 
cast 1 Calculate the Universe
numberology 69
You gain 3 Adventures

which is fine. Here is the CLI:

Code: 
[color=green]> get _universeCalculated[/color]

false

numberology 69
You gain 3 Adventures

[color=green]> get _universeCalculated[/color]

false
I vaguely remember that I had to insert a call to visitChoice after some other thing that redirected to choice.php. I assume I have to do the same thing for this one, somewhere.
 
After a stupid amount of testing, I finally realized that mafia does recognize gaining fites from that choice (as reported by pvp_attacks_left()), but the side panel doesn't update in response to that. The update happens in ResultProcessor.tallyResult() at the end (which was the last time I looked at general result processing, apparently). I have no idea how to get the side pane to update for that, the way it does for gaining an adventure.
 
Add to KoLCharacter.setAttacksLeft():

Code: 
		KoLCharacter.updateStatus();

That is called in many - but not all - places in KoLCharacter that change something that is displayed in the compact side pane. It fires all CharacterListeners and PreferenceListeners (should be NamedListeners, but we didn't used to have those) on "(character)" (which is not a Preference, which is why it should be a NamedListener).

I'm not sure why we don't call it EVERY time we change a variable in KoLCharacter. Perhaps we think it will result in too many little incremental calls to update things when a mass update - like parsing api.php - happens. The result is, though, that unless there is a call to api.php (or charpane.php), we won't update.

In any case, the CompactSidePane registers a CharacterListener and will refresh every time it fires with the current character state.
 
Bump to remind myself to continue with this, now that I am done with VYKEA companions.

First thing will to have the numberology command tell you that your desired prize will be available in X turns or Y spleen.

And then, to actually use the math, as described by heeheehee.
 
_universeCalculated now seems to get set to true as soon as you enter choice 1103. That doesn't seem the right place for that flag to be set, as you can still back out of the choice and use the skill later.
 
darkcodelagsniper said:
_universeCalculated now seems to get set to true as soon as you enter choice 1103. That doesn't seem the right place for that flag to be set, as you can still back out of the choice and use the skill later.
Click to expand...
lostcalpolydude said:
You can walk away from the choice (you couldn't initially, but people kept getting stuck in it), but the skill is used up anyway. (You can go back to choice.php to finish using it still, as long as you don't do anything to change that.) CDMoyer wasn't interested in changing that behavior, so the number needs to be validated before casting the skill.
Click to expand...
I assume these are talking about the same thing, although they seem to be saying the opposite.

Once you cast the skill, it is used up, but you can back out of the choice, go and do ... some kinds of thing ... and then return to choice.php.

vs.

Once you cast the skill, it is not actually used up until you actually take the choice.

So which is it? It is currently coded to agree with lost's report - as soon as you see the choice, we won't let you cast the skill again, although you are welcome to code a visit to choice.php yourself to finish it, as long as you haven't done things that break it. You are saying that KoL changed and you can actually walk away from the choice now and find it again by casting the skill again?
 
Veracity said:
It is currently coded to agree with lost's report - as soon as you see the choice, we won't let you cast the skill again, although you are welcome to code a visit to choice.php yourself to finish it, as long as you haven't done things that break it. You are saying that KoL changed and you can actually walk away from the choice now and find it again by casting the skill again?
Click to expand...

Last I checked I couldn't recast it after I walked out (vanilla). I already used my cast for the day, so I can't test if that changed. If it still needs testing tomorrow, how do you go back to the Number choice if you walk away from it? Just go to /choice.php and it'll load?
 
Yes something like that, I don't know specifically. If you go adventuring after casting you can't go back, however.
 
You must log in or register to reply here.
Back
Top