Bug - Fixed NPE in AdventureQueueDatabase.applyQueueEffects

Veracity

Veracity

Developer
Staff member
Code: 
Unexpected error, debug log printed.
class java.lang.NullPointerException: null
java.lang.NullPointerException
	at net.sourceforge.kolmafia.persistence.AdventureQueueDatabase.applyQueueEffects(AdventureQueueDatabase.java:361)
	at net.sourceforge.kolmafia.AreaCombatData.getMonsterString(AreaCombatData.java:934)
	at net.sourceforge.kolmafia.AreaCombatData.getMonsterData(AreaCombatData.java:696)
	at net.sourceforge.kolmafia.AreaCombatData.toString(AreaCombatData.java:575)
	at net.sourceforge.kolmafia.swingui.panel.AdventureSelectPanel$SafetyField.setSafetyString(AdventureSelectPanel.java:671)
	at net.sourceforge.kolmafia.swingui.panel.AdventureSelectPanel$SafetyField.run(AdventureSelectPanel.java:658)
	at net.sourceforge.kolmafia.listener.CharacterListener.update(CharacterListener.java:55)
	at net.sourceforge.kolmafia.listener.CharacterListenerRegistry.updateStatus(CharacterListenerRegistry.java:84)
	at net.sourceforge.kolmafia.KoLCharacter.updateStatus(KoLCharacter.java:4899)
	at net.sourceforge.kolmafia.KoLCharacter.updateSelectedLocation(KoLCharacter.java:4910)
	at net.sourceforge.kolmafia.KoLAdventure.setNextAdventure(KoLAdventure.java:1397)
	at net.sourceforge.kolmafia.request.RelayRequest.sendWarnings(RelayRequest.java:2963)
	at net.sourceforge.kolmafia.request.RelayRequest.run(RelayRequest.java:2860)
	at net.sourceforge.kolmafia.RequestThread.postRequest(RequestThread.java:285)
	at net.sourceforge.kolmafia.RequestThread.postRequest(RequestThread.java:248)
	at net.sourceforge.kolmafia.webui.RelayAgent.readServerResponse(RelayAgent.java:552)
	at net.sourceforge.kolmafia.webui.RelayAgent.performRelay(RelayAgent.java:157)
	at net.sourceforge.kolmafia.webui.RelayAgent.run(RelayAgent.java:130)
This happens when I try to visit the Red Zeppelin in the Relay Browser. In fact, I get 6 stack traces. All of them are a result of an NPE at net.sourceforge.kolmafia.persistence.AdventureQueueDatabase.applyQueueEffects(AdventureQueueDatabase.java:361)
 
Revision 14709 patches this. It also gets rid of a lot of Object stuff in the AdventureQueue, since RollingList now lets you specify what kind of objects are in the list. I can now log in again.

I'm leaving this open, since I think the author might want to look at the situation and decide whether the monster really should be able to be null in this situation.

I wanted to go to the Red Zeppelin. That zone has a "special" monster - Red Fox. Which is why I was going there. :)
 
Ok, I think I know what happened, but I just want to check.

I think you'd visited the Red Zeppelin previously, and got The Red Fox, then left, so have The Red Fox in the queue. However, by that point the name had been changed to Red Fox, so it didn't match, and thus monster was null. So adding the handling is correct, and might be needed any time we change names.
 
This character has been alternating getting The Red Fox and (whatever) for semirares. So, yeah - assuming we keep the queue across days she was in the queue from yesterday.

(I find it odd that a semirare monster would be in the queue, since you either always find it (if the conditionsa are right) or never find it.)
 
Yes, queue is only cleared at ascension.

Whilst appearance of a semi-rare in the queue does not affect the chance of anything appearing, it does count as one of the up to five monsters in the queue. If we (and KoL) didn't add it to the queue it wouldn't push something else out. Assuming, of course, that's what KoL does. I'm not sure if that's been spaded. Ditto for wandering monsters.
 
Darzil said:
Yes, queue is only cleared at ascension.

Whilst appearance of a semi-rare in the queue does not affect the chance of anything appearing, it does count as one of the up to five monsters in the queue. If we (and KoL) didn't add it to the queue it wouldn't push something else out. Assuming, of course, that's what KoL does. I'm not sure if that's been spaded. Ditto for wandering monsters.
Click to expand...

I doubt it pushes anything out. I would expect that to only happen once KoL decides it's giving a normal combat and looks for a monster. That's why I brought it up before that not adding those monsters to mafia's queue might be a good idea.
 
Ok, so we need a list of all monsters which are Wandering, Clover adventures (none?), Semi-rare, superlikely or free combats. We should stop them going into the queue.
 
We don't need that list, we can use the existing list for each location of monsters that are actually supposed to be there.
 
I'm not quite so sure. Semirare monsters do appear there, with a weighting of zero, but other things with a weighting of zero also appear there, Superlikely ones also appear there.

If ever we are to handle the appearance rates correctly, which we're moving to, we'll need it.

Am looking at adding flags to monsters.txt for WANDER, ULTRARARE, SEMIRARE, SUPERLIKELY and FREE, then handling lookups for types pretty trivially as needed. Better than hard coded lists.
 
0 covers too many cases, including things that only conditionally get added to queues, like Dis monsters, but which do get queued.

r14720 stops these monsters being added to the queue (and uses ConsequenceManager to get encounter names, so things like Ninja Snowman do get added to the queue). It uses an additional optional flag in monsters.txt.

I think we'll be able to get rid of our hard coded Ultrarare list, but haven't looked at that yet.
 
You must log in or register to reply here.
Back
Top