Bug - Fixed 100% run warning for the NS fight

[slyz]

A clanmate just fought the NS after forgetting to switch back to the familiar she was doing a 100% run with. Apparently the familiar warning added by Hola in r9762 wasn't shown before the NS fight.

Specifically, I think the culprit is the change in r9770 in which an AreaCombatData check was added:

if ( KoLCharacter.getFamiliar().isUnexpectedFamiliar() && areaSummary != null && areaSummary.combats() > 0 &&
	 ( !KoLCharacter.kingLiberated() || KoLCharacter.getFamiliar().getId() == FamiliarPool.BLACK_CAT ) )
{
	this.sendFamiliarWarning();
	return;
}

It looks like the Sorceress Tower isn't included in combats.txt, so areaSummary is probably null for the NS fight. The warning probably doesn't fire for the tower monsters or the Shadow fight either.

I'm not sure what the best way to fix this is:
- roll back r9770
- add "Level 1" to "Level 6", "Shadow Fight" and "Naughty Sorceress" to combats.txt
- add something like urlString.indexOf( "lair" ) != -1 to the check above

Thoughts?

 

[Fred Nefler]

A clanmate has reported a similar issue with the Daily Dungeon, and another alleged that anything not using adv.php failed to get the warning.

 

[slyz]

It's not exactly whether the zone is adventure.php or not, it's whether the area has an AreaCombatData that Mafia retrieves from its combats.txt data file. For example, the Hidden City is not an adventure.php location, but is in combats.txt, so the warning should fire.

I'm in favor of rolling back r9770, where the AreaCombatData lookup was added before displaying the warning. This way, people on 100% runs will get the warning each time they don't have their familiar equipped, and click somewhere that Mafia recognizes as an adventure.

 

[Theraze]

Wouldn't it alternatively make sense to just add the areas with known monsters into combats.txt? I mean, we know that the Lair will have combat with the NS. She could be added. We know that the bottom of the pyramid will have combat with Ed and Ed2-7. We know that the daily dungeon can have battle with apathetic lizardmen, mayonaise wasps, etc...

 

[Fred Nefler]

Wouldn't it alternatively make sense to just add the areas with known monsters into combats.txt? I mean, we know that the Lair will have combat with the NS. She could be added. We know that the bottom of the pyramid will have combat with Ed and Ed2-7. We know that the daily dungeon can have battle with apathetic lizardmen, mayonaise wasps, etc...

That sounds better.

I would propose a system that allows a more robust default handling. Any zone/location which is unrecognized, or is otherwise not definitively known to have no combats, is a zone I would like to see trigger this sort of warning. Then any new additions/changes to the game will still give the warning, protecting (or at least warning) the curious and errant clickers. It should probably give a special message for unrecognized zones, so those that bother to read will know why the warning has popped up.

I would also like to see the presence of wandering monsters adjust this. So on FoB, for example, the warning would still pop up in pure noncombat zones. Preferably it would only do so during the window when a monster can actually show up (and only where they could actually pop up). Similarly for other zones that wandering monsters can appear in. Including other holiday monsters, hipster fights, and romantic arrow targets (during appropriate windows, when known, and with appropriately detailed warning messages). I assume this would be complicated, such as making sure the windows are created appropriately and detected, but I'd still like it.

 

[slyz]

There are so few pure non-combat zones during an ascension that I still think the simplest solution is to roll back the check for combats in an area.

 

[holatuwol]

Any zone/location which is unrecognized, or is otherwise not definitively known to have no combats, is a zone I would like to see trigger this sort of warning.

This part is done, 9875. The fancier "is there any possible way I could have a combat right now" is not in, however.

 

[slyz]

I'm having a small problem with r9875 that I can't track down. I'm currently on a 100% run, but I need my Exotic Parrot to pass an elemental test in the Daily Dungeon.

With r9875, I correctly get the familiar warning when I try to pass a test in the Daily Dungeon. When I click the Exotic Parrot link in the familiar warning (dungeon.php?pwd&action=Yep&option=1&confirm=on), I get send back to the Daily Dungeon room instead of passing the test.

I'm testing a few solutions, I'll see if I can find something that works.

 

[slyz]

It looks like the POST request to pass a Daily Dungeon test is turned into a GET in the familiar warning link.

Clicking on the "I TRIPLE-dog-dare ya! (1)" button in the Daily Dungeon room:

-----From Browser-----
POST /dungeon.php HTTP/1.1
Host: 127.0.0.1:60080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://127.0.0.1:60080/dungeon.php?pwd&action=Yep&option=1&userconfirm=on
Cookie: feed=inline; meatcreate=inline; keep=inline
Content-Type: application/x-www-form-urlencoded
Content-Length: 56
pwd=*snip*&action=Yep&option=1
----------

Clicking on the Exotic Parrot image in the familiar warning (dungeon.php?pwd&action=Yep&option=1&confirm=on):

-----From Browser-----
GET /dungeon.php?pwd&action=Yep&option=1&confirm=on HTTP/1.1
Host: 127.0.0.1:60080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://127.0.0.1:60080/dungeon.php
Cookie: feed=inline; meatcreate=inline; keep=inline
----------

 

[slyz]

Here is a patch that works to fix the issue by adding "usepost=true" at the end of the link in the familiar warning, when the current request is a POST request.

When RelayRequest.java gets a GET request with "usepost=true", it turns it into a POST request.

I'm not committing this though. Hola knows his way around these kinds of thing much better than I do, and probably has a fix that isn't a clumsy hack.

 

[slyz]

r9876 is a... simpler solution