Datatypes:
Code:
public static final Value LOCATION_INIT = new Value(DataTypes.LOCATION_TYPE, "none", null);
RuntimeLibrary:
Code:
public static Value set_location(ScriptRuntime controller, final Value location) {
KoLAdventure adventure = (KoLAdventure) location.rawValue();
KoLAdventure.setNextAdventure(adventure);
return DataTypes.VOID_VALUE;
}
So, yeah - the KoLAdventure is null.
GenericRequest:
Code:
private static void checkItemRedirection(final String location) {
...
if (nextAdventure == null) {
KoLAdventure.setLastAdventure("None");
KoLAdventure.setNextAdventure("None");
} else {
KoLAdventure adventure = AdventureDatabase.getAdventure(nextAdventure);
KoLAdventure.setLastAdventure(adventure);
KoLAdventure.setNextAdventure(adventure);
EncounterManager.registerAdventure(adventure);
}
...
}
We certainly have the concept of "none" for the next location; almost all items that lead to fights are in that location.
(lynyrd snare, rusty hedge trimmers, and white page are the only exceptions.)
KoLAdventure:
Code:
public static void setNextAdventure(final String adventureName) {
KoLAdventure adventure = AdventureDatabase.getAdventure(adventureName);
if (adventure == null) {
Preferences.setString("nextAdventure", adventureName);
KoLCharacter.updateSelectedLocation(null);
return;
}
KoLAdventure.setNextAdventure(adventure);
EncounterManager.registerAdventure(adventureName);
}
public static void setNextAdventure(final KoLAdventure adventure) {
if (adventure == null) {
return;
}
Preferences.setString("nextAdventure", adventure.adventureName);
KoLCharacter.updateSelectedLocation(adventure);
NamedListenerRegistry.fireChange("(koladventure)");
}
You can set the nextAdventure either from an adventureName or a KoLAdventure.
Similar methods exist for setLastAdventure.
GenericRequest.checkItemRedirection uses "lookup by name" - where "name" is usually "None".
RuntimeLibrary sets ONLY setNextAdventure and ONLY via KoLAdventure.
I find it odd that setNextAdventure(KoLAdventure) - with non null KoLAdventure does this:
Code:
Preferences.setString("nextAdventure", adventure.adventureName);
KoLCharacter.updateSelectedLocation(adventure);
NamedListenerRegistry.fireChange("(koladventure)");
and setNextAdventure(String adventureName) - with a name that resolves to a valid KoLAdventure does this:
Code:
KoLAdventure.setNextAdventure(adventure);
EncounterManager.registerAdventure(adventureName);
i.e. those three lines and also registering the adventure in EncounterManager.
Perhaps those are correct for most uses of those methods.
Huh. AdventureSelectPanel.valueChanged:
Code:
KoLAdventure location = AdventureSelectPanel.this.getSelectedAdventure();
if (location != null) {
KoLAdventure.setNextAdventure(location);
}
This is equivalent of what RuntimeLibrary wants to do: set the adventuring location in a way that location-specific modifiers are visible.
Note that doing it that way (correctly?) does not register the adventure in EncounterManager.
Something funny:
setNextAdventure(KoLAdventure):
Code:
NamedListenerRegistry.fireChange("(koladventure)")
KoLCharacter.updateSelectedLocation(KoLAdventure):
Code:
PreferenceListenerRegistry.firePreferenceChanged("(location)");
The first one is used only by the AdventureFrame and the second is for scripts, I guess; it is not used internally.
I think RuntimeLibrary, as opposed to AdventureSelectPanel has a valid use for setting nextLocation to "none".
Perhaps it wants sort of a hybrid approach which does exactly the minimum?
Code:
public static Value set_location(ScriptRuntime controller, final Value location) {
KoLAdventure adventure = (KoLAdventure) location.rawValue();
if (adventure == null) {
Preferences.setString("nextAdventure", "None");
KoLCharacter.updateSelectedLocation(null);
} else {
Preferences.setString("nextAdventure", adventure.getAdventureName());
KoLCharacter.updateSelectedLocation(adventure);
}
return DataTypes.VOID_VALUE;
}
This will not update the AdventureFrame (GUI) - which seems correct, for speculation.