GoogleCodeExporter
commented
9 years ago [deleted comment]Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago [deleted comment]I'm not sure exactly where this is coming from. For a long time now certain
monsters have needed you to visit the Monster page, and then one (or more) of
the actual monsters before anything would appear on the Dashboard. Not sure if
this is the same issue, but I'm inclined to think it is.
I've seen a report where Monster.data isn't populated too. Not quite sure if
that's relevant, but mentioning anyway in case it helps find the thing.
I bet that when we do finally fix it, it's going to be a "doh!" moment ;-)Original comment by RycochetTM on 23 Oct 2010 at 8:49
GoogleCodeExporter
commented
9 years ago Monster.data was good before call _flush, but not after calling _unflush for
the monster worker. The first time through _working[data] was true.
Not sure why this popped up, but I resolved it by initializing _working:
Worker.prototype._flush = function() {
this._push();
this._working = {data:false, option:false, runtime:false, update:false};
this._save();
if (!this.settings.keep) {
delete this.data;
}
this._pop();
};
It may not be the correct solution, but it is working for me.Original comment by LickThis...@yahoo.com on 23 Oct 2010 at 11:45
GoogleCodeExporter
commented
9 years ago Worker._working is initialized when the worker is instanced, so if that sorts
it there's something underlying causing a problem. The monsters not showing up
immediately seems to be linked to the regexp used to find out the names - which
is getting looked at now ;-)Original comment by RycochetTM on 23 Oct 2010 at 11:55
GoogleCodeExporter
commented
9 years ago Hmmm... that is odd. I also globally changed the instances of ' == ' to ' ===
'. I noticed the list would get filled but I was always getting reset (so
thought it was all in my mind). It wasn't until I changed the _flush that the
would be preserved.Original comment by LickThis...@yahoo.com on 23 Oct 2010 at 8:40
GoogleCodeExporter
commented
9 years ago Globally changing == to === *will* break things where strict typing is
undesirable. While === is the preferred method for testing (safer etc) there
are several places within the code that trying to use it will basically mean
that features won't work.
To temporarily test if it's the flush causing it, just disable the _flush
functionality - comment out the "delete" line - it will probably result in
memory leaks and the like over time, but testing code locally doesn't care
about that.
_working is used to prevent deadlock loops - however the need for it is slowly
being removed as other code within the Worker class is getting changed...Original comment by RycochetTM on 24 Oct 2010 at 2:53
GoogleCodeExporter
commented
9 years ago Ok, the == vs.=== shouldn't matter that much, and I was still having problems
until I changed the _flush.
I had an issue with a completed monster I couldn't clear (would keep coming
back) in addition to not getting the new monsters. I set debug breakpoints
before the call to flush and visited the monster page. On the "monster" worker
iteration, when looking at the Monster.data I saw the new monsters present.
Stepping into the _flush I saw the saving of data exited early so I bodged
something to compel saving the data (and the trouble disappeared). Although it
is unlikely the root cause, it made stuff work for me.
PPS. The list was cleared and the phantom returned some time after this, so it
si not a solution, just a work-around.Original comment by LickThis...@yahoo.com on 24 Oct 2010 at 3:00
GoogleCodeExporter
commented
9 years ago I was typing while you were typing.
My phantom monster seems to have disappeared in the 836/837 versions (there is
a small mismatch), so maybe everything is hunky-dorry. Only upgraded beyond 818
on this chrome browser. Too much was changing after that :) Once things
stabilize I might do a Firefox, and prop some personal tweaks.Original comment by LickThis...@yahoo.com on 24 Oct 2010 at 3:14
GoogleCodeExporter
commented
9 years ago I suspect that some of the issue with monsters not parsing/saving correctly and
monsters returning that had been deleted may have been related to and solved by
the recent fix for _remind and _revive. They would have caused _update to fail
sometimes with an uncaught exception, which in turn would not save out new
information or changes made in that update cycle. It may be best to try to find
these cases happening again after r837, to see if there is a remaining bug that
needs hunting down.
An outstanding issue that I am aware of related to this is funny or failed
parsing of combinations of player names and/or monster names containing
apostrophe "s" ('s). I'll try to get a reliable patch in for those cases soon. Original comment by lur...@hotmail.com on 24 Oct 2010 at 6:04
GoogleCodeExporter
commented
9 years ago Monster and player names with possessives should parse better with r839.
Aurelius, Lion's Revenge is the only monster posing that problem currently, but
player names used to truncate before on possessives (ie: Bob's Army's Gehenna
became Bob instead of Bob's Army) and shouldn't now.Original comment by lur...@hotmail.com on 26 Oct 2010 at 1:30
GoogleCodeExporter
commented
9 years ago i noticed that if i delete monster.data datas in about:config this fix the
monsters not show in dashboard.. how i can do the same thing in chrome?? where
are stored the datas of chrome version??Original comment by carlo.so...@gmail.com on 26 Oct 2010 at 12:02
GoogleCodeExporter
commented
9 years ago In chrome the storage can be accessed via the Developer Tools area
(Control-Shift-I or Control-Shift-J both get there), then choosing Storage on
the top icon strip, then Local Storage on the left menu strip. You are then
given a list of keys and values, very similar to about:config in Firefox, but
specific to that one web page/domain/app.Original comment by lur...@hotmail.com on 26 Oct 2010 at 3:25
GoogleCodeExporter
commented
9 years ago Seems fixed. Closing.Original comment by 0Artifi...@gmail.com on 21 Mar 2011 at 6:25
Original issue reported on code.google.com by
VirtualJ...@gmail.comon 21 Oct 2010 at 11:40