Bug - Fixed set_location() failing to update pressure modifiers

When I click sea locations in mafia's GUI, it alters the droprate based on the pressure modifier for that location.

I'd assume that setting my location with set_location() should provide the same functionality, but it only selects the general zone in the GUI, not the specific location. The item drop modifiers and meat drop modifiers aren't affected.

> ash set_location($location[the dive bar])

Returned: void

> ash my_location()

Returned: The Dive Bar
nocombats => false
zone => The Sea
parent => The Sea
parentdesc => The Sea
bounty => none

> ash item_drop_modifier()

Returned: 50.0

> ash numeric_modifier("Item Drop Penalty")

Returned: 0.0

Click to expand...

If you then manually click the Dive Bar location in the GUI you get the following:

> ash item_drop_modifier()

Returned: -150.0

> ash numeric_modifier("Item Drop Penalty")

Returned: -200.0

Click to expand...

Additionally, when adventuring through the Relay Browser, if you switch locations, the first time it only switches to the right zone (Plains, Woods, etc.), the second time is when the specific location is highlighted (and also when it is considered when calculating +item and so on).

lost's comment made me think. The following log took place without me doing anything in the GUI. It seems that using set_location() a second time to a different place in the same zone will actually set the location properly!

Note that I am using my Eggman for +50% item drops. No other modifiers are active.

> ash set_location($location[dive bar]); item_drop_modifier()

Returned: 50.0

> ash set_location($location[dive bar]); item_drop_modifier()

Returned: 50.0

> ash set_location($location[ skate park]); item_drop_modifier()

Returned: -50.0

> ash set_location($location[dive bar]); item_drop_modifier()

Returned: -150.0

Click to expand...

I see that set_location( location ) updates lastLocation (why?), and by design it does nothing if you try to set your location to what it should already be set to, so repeated calls with the same location parameter are expected to do nothing. Since that function does something, AdventureSelectPanel.UpdateSelectedAdventure() is running.

It looks like the issue is that when runs, locationSelect can have the locations for the previous zone rather than the one that should be switched to. This would happen if is not reached (I think), which would mean that is true.

If "useZoneComboBox" (Preferences -> General -> Use zone selection instead of adventure name filter) is enabled, then everything works properly because zoneSelect is never an AutoFilterTextField.

In my opinion the graphical widget should reflect the state of some internal variable, rather than the other way around. Sounds like some refactoring is in order.

lostcalpolydude said:

If "useZoneComboBox" (Preferences -> General -> Use zone selection instead of adventure name filter) is enabled, then everything works properly because zoneSelect is never an AutoFilterTextField.

Click to expand...

That's a handy workaround. I'd actually tried toggling it, but didn't realise I'd also need to restart the client.

Just thought I'd bump this report with another aspect of the strange behaviour that I just ran into. This is while using the option "Preferences -> General -> Use zone selection".

Using set_location() and checking item_drop_modifier() I'm getting different results inside a foreach loop than when I simply execute the commands.

In the first example I set my location to the Briniest Deepests, then report the drop modifier. Then I set location to the Icy Peak and report drop modifier. It works correctly.
Then in the second example I do a foreach loop of locations. If the location is the Deepests or the Peak then I report the item drop modifier.

roippi said:

In my opinion the graphical widget should reflect the state of some internal variable, rather than the other way around. Sounds like some refactoring is in order.

Click to expand...

Agreed.

Revision 13129 should fix this.