selected options for "Take a Look..." choice adventures keep changing

chown

Member
So, whenever I open the GUI for changing the selected options for choice adventures, the zone pane for "Manor1" shows the choiceAdventure888 and choiceAdventure889 options as "acquire mysticality skill" and "boost muscle substats". This happens despite my having changed them to the "Ignore this adventure" choice. If I change some other setting in the GUI, it then clobbers my setting. Does Mafia do this to everyone??
 

lostcalpolydude

Developer
Staff member
If I change some other setting in the GUI, it then clobbers my setting.

What other setting, specifically? What does "clobbers" mean?

I suspect that some script (given that you've posted in the Edscension thread, that would be my first guess) is changing the settings.
 

Bale

Minion
A quick search of all the Escension scripts (for "888" and "889") shows that we have this:

Code:
	if(item_amount($item[Spookyraven Library Key]) == 1)
	{
			print("Well, we need writing desks", "blue");
			print("Going to the liberry!", "blue");
			set_property("choiceAdventure888", "4");
			set_property("choiceAdventure889", "4");
			set_property("choiceAdventure163", "4");
			ccAdv(1, $location[The Haunted Library]);
	}

That's the only thing that changes the relevant settings.

I suspect that Escension is NOT the culprit. Unfortunately that doesn't get us any closer to finding the problem. Perhaps he uses a different between battle script. Such a script though would show a line in the CLI when it changes those settings. He should check his CLI to see if something is changing choiceAdventure888 and choiceAdventure889.
 

xKiv

Active member
So, whenever I open the GUI for changing the selected options for choice adventures, the zone pane for "Manor1" shows the choiceAdventure888 and choiceAdventure889 options as "acquire mysticality skill" and "boost muscle substats". This happens despite my having changed them to the "Ignore this adventure" choice. If I change some other setting in the GUI, it then clobbers my setting. Does Mafia do this to everyone??

How did you change them to "ignore"?
Does get choiceAdventure888 and get choiseAdventure 889 show your values, or the wrong ones?
 

chown

Member
This doesn't seem to happen on all of my characters. This is on chown, who hasn't run Edscension. (I don't suspect it anyway. I'm pretty sure that I've been having this issue since before Edscension ever existed, because I have some older scripts that try to change the settings back) He only has Universal_recovery and CounterChecker showing up in the "Automation" section of the Preferences. I've grepped around for 888 in my scripts, relay, and settings directories, but nothing even remotely suspicious shows up.

Code:
> set choiceAdventure888

4

> print changing the Dewey choice via the GUI

changing the Dewey choice via the GUI

> set choiceAdventure888

3

> print changing the "Rise of spookyraven" to "ignore this adventure"

changing the "Rise of spookyraven" to "ignore this adventure"

> set choiceAdventure888

4

> print changing the Dewey one back...

changing the Dewey one back...

> set choiceAdventure888

4

> print clicking on mer-kin library in the adventure area list box, and clicking back on the manor one

clicking on mer-kin library in the adventure area list box, and clicking back on the manor one

> print okay, the GUI again displays "acquire mysticality skill"

okay, the GUI again displays "acquire mysticality skill"

> set choiceAdventure888

4

> print so, back to where I started. GUI says "acquire mysticality skill" but chown_prefs.txt & "set choiceAdventure888" say option #4

so, back to where I started. GUI says "acquire mysticality skill" but chown_prefs.txt & "set choiceAdventure888" say option #4

Choice 4 is "ignore this adventure" in the GUI. Choice 3 is "acquire mysticality skill". In case that wasn't clear.
 

Darzil

Developer
I think what is happening, if I understand, is that when you set choiceAdventure888 outside the GUI, the GUI is not updated. When a change is then made in the GUI, the choiceAdventure settings are then set to match the current GUI state.

What would need to happen is to ensure the GUI updates when choiceAdventure888 is set outside the GUI.
 

Theraze

Active member
Correct. The GUI does not update on windows that are open when changes are made. If you have Adventure as a closed tab, set your choices in the gCLI, and then open the Adventure tab, your choices should be reflected.

I believe the same issue has been noted within the past week with some other types of tabs, with the note that if you want them to update, don't keep them open while you're doing stuff in the gCLI.
 

Veracity

Developer
Staff member
Correct. The GUI does not update on windows that are open when changes are made. If you have Adventure as a closed tab, set your choices in the gCLI, and then open the Adventure tab, your choices should be reflected.

I believe the same issue has been noted within the past week with some other types of tabs, with the note that if you want them to update, don't keep them open while you're doing stuff in the gCLI.
First time I've ever heard this.

We have "listener" technology to deal with this kind of issue: objects manipulating GUI elements (adventure tab, choice option controls, etc.) "listen" for an event that will inspire them to change the GUI, and elsewhere, when the appropriate thing changes, the event is fired and the GUI code runs and updates.

We don't use this consistently. If you want to see it work correctly (for the most part), open the Gear Changer, equip an item in the gCLI, and notice that the Gear Changer updates to show it.

Any time "the GUI doesn't update correctly on windows that are open when changes are made", that is a bug, and a bug report with precise details about how to reproduce the issue should be created.

---

Looking at ChoiceOptionsPanel, it registers a preference listener for "choiceAdventure*", so if you change such a setting in the gCLI or a script, the GUI should update appropriately.

Now, the thing about the "Take a Look" choice is that the the dropdowns do not reflect settings of a single choice adventure. Here is how we change choice settings when you select something in the dropdown (ChoiceOptionsPanel.saveSettings):

Code:
		switch ( this.riseSelect.getSelectedIndex() )
		{
		case 0: // Ignore this adventure
			Preferences.setString( "choiceAdventure888", "4" );
			break;

		case 1: // Mysticality
			Preferences.setString( "choiceAdventure888", "3" );
			Preferences.setString( "choiceAdventure88", "1" );
			break;

		case 2: // Moxie
			Preferences.setString( "choiceAdventure888", "3" );
			Preferences.setString( "choiceAdventure88", "2" );
			break;

		case 3: // Mysticality Class Skill
			Preferences.setString( "choiceAdventure888", "3" );
			Preferences.setString( "choiceAdventure88", "3" );
			break;
		}

		switch ( this.fallSelect.getSelectedIndex() )
		{
		case 0: // Ignore this adventure
			Preferences.setString( "choiceAdventure889", "4" );
			break;

		case 1: // Muscle
			Preferences.setString( "choiceAdventure889", "3" );
			break;
		}
And here is how we change the dropdowns when the choice adventure setting is changed (ChoceOptionsPanel.loadSettings):

Code:
		// Figure out what to do at the bookcases

		index = Preferences.getInteger( "choiceAdventure80" );
		if ( index == 4 )
		{
			this.riseSelect.setSelectedIndex( 0 );
		}
		else
		{
			this.riseSelect.setSelectedIndex( Preferences.getInteger( "choiceAdventure88" ) );
		}

		index = Preferences.getInteger( "choiceAdventure81" );
		if ( index == 4 )
		{
			this.fallSelect.setSelectedIndex( 0 );
		}
		else
		{
			this.fallSelect.setSelectedIndex( 1 );
		}
Notice that it is looking at choices 80 & 81. Those were the old choice numbers. It should now be looking at choices 888 and 889.
 

Veracity

Developer
Staff member
We have "listener" technology to deal with this kind of issue: objects manipulating GUI elements (adventure tab, choice option controls, etc.) "listen" for an event that will inspire them to change the GUI, and elsewhere, when the appropriate thing changes, the event is fired and the GUI code runs and updates.
This is basic MVC (Model, View, Controller) GUI design. Which, since I am a systems programmer, not an applications programmer, is not something I'd ever heard about formally until last year, when I took an Apple University course on how to write an app for IOS. Having done so, I now understand why Swing has "models" of the data that it displays in GUI elements, and why roippi used "listeners" to update Daily Deeds, and so on. Suddenly, a lot of terminology made sense - and it became clear why objects that show a View of the Model in the GUI should provide a "listener" and update when the module handling that Model fires the change, rather than having non-GUI objects explicitly calling this-or-that GUI element to update.

A lot of KoLmafia works that way, but there are parts of it in which the "Model" code is hard-wired to call methods in the GUI code to tell them to update. And its that code for which I expect "the GUI does not update on windows that are open when changes are made". As I said, make specific bug reports about such cases, and we will fix them to use the correct technology.

I suppose somebody could make a close pass over the whole program to make sure it is all MVC correct, but that would be a big project. Not a bad project, but just way too time intensive for me, say. :)
 
This is basic MVC (Model, View, Controller) GUI design. Which, since I am a systems programmer, not an applications programmer, is not something I'd ever heard about formally until last year, when I took an Apple University course on how to write an app for IOS. Having done so, I now understand why Swing has "models" of the data that it displays in GUI elements, and why roippi used "listeners" to update Daily Deeds, and so on. Suddenly, a lot of terminology made sense - and it became clear why objects that show a View of the Model in the GUI should provide a "listener" and update when the module handling that Model fires the change, rather than having non-GUI objects explicitly calling this-or-that GUI element to update.

A lot of KoLmafia works that way, but there are parts of it in which the "Model" code is hard-wired to call methods in the GUI code to tell them to update. And its that code for which I expect "the GUI does not update on windows that are open when changes are made". As I said, make specific bug reports about such cases, and we will fix them to use the correct technology.

I suppose somebody could make a close pass over the whole program to make sure it is all MVC correct, but that would be a big project. Not a bad project, but just way too time intensive for me, say. :)
This sounds right up my alley, since I am a Java programmer... but I'll have to learn MVC design principles first. D:
 

Veracity

Developer
Staff member
Notice that it is looking at choices 80 & 81. Those were the old choice numbers. It should now be looking at choices 888 and 889.
I see that nobody else stepped in to submit a fix, so I guess I'd better do so.
Revision 16239. Untested.
 
Top