Page 1 of 4
Possible bug: SuperWho locking up EQ
Posted: Sat Nov 01, 2003 2:03 pm
by MacroFiend
When I tried to do an unfiltered /who from the bazaar (404 active traders ... no idea how many shoppers), the entire EQ session locked up. I then logged on a different char in another less populated zone. Again tried an unfiltered who and locked up.
Then ... just for kicks, I did a /who (targetname) and even that locked up.
I have made attempts using both the MQChat window and the default chat.
Any insight would be appreciated.
*edit
Normal MQ chat output is ok "/echo $char(state)"
Posted: Sat Nov 01, 2003 2:37 pm
by EqMule
I eh cvsed a new macrocommand called $dec
but I havent zipped it since i saw that /who thing to... my money is on Lax being the guilty one? some change to mqchat perhaps?
In my personal version which doesnt have the chatwindow yet, it works fine and I know the SRC-20031031a.zip doesnt have this problem, so what source are u using? latest dev cvs?
Posted: Sat Nov 01, 2003 2:47 pm
by MacroFiend
Latest anon CVS is the clean copy I started with. The 20031031a zip does not have this issue at all. The new changes were CVSd last night ... and since the SourceForge CVS servers appear to be syncing a lot more often, it was in the anon CVS this morning.
Note: The colorized /zem reports "Zone experience modifie" instead of "Zone experience modifier: 0% bonus" ... so my money is on the new color converter routine since it appears to be eating characters off the string.
I would imagine that if you took a line of text and then added enough color that it chopped off all the characters, it might throw a fit.
Posted: Sat Nov 01, 2003 3:42 pm
by tehHax0r
short answer: dont use the anon cvs, cause its totally fubar'd.
i've only been using the zips ever since sourceforge started doing the backup stuff
Posted: Sat Nov 01, 2003 5:02 pm
by Lax
Fixed in dev cvs, it got broke this morning
Posted: Sun Nov 02, 2003 2:43 pm
by pooz
Latest IRC .zip is borked with new EQ window, related to new STML converter eating chars...
the blue is REALLY hard to see.
/who npc a
List of NPCs
--------------------------------------
[23 Human Warrior] dervish cutthroat, a <NPC> (523.23 WNW)
o, a
o, a
o, a
o, a
There are 5 NPCs in Desert of North Ro.
Posted: Sun Nov 02, 2003 3:21 pm
by Lax
No, unrelated. It actually has to do with the "nopets" filter. I had a problem with it earlier, but I'm not sure exactly what happened. What I did was a /who nopets something, logged out and logged in and it seemed to fix itself. No idea.
Yes the dark blue is hard to see but as it's just used for the [] () around the important stuff, you don't need to see it
Also, the color processor doesn't eat chars :)
Posted: Sun Nov 02, 2003 4:52 pm
by wassup
pooz wrote:Latest IRC .zip is borked with new EQ window, related to new STML converter eating chars...
the blue is REALLY hard to see.
/who npc a
List of NPCs
--------------------------------------
[23 Human Warrior] dervish cutthroat, a <NPC> (523.23 WNW)
o, a
o, a
o, a
o, a
There are 5 NPCs in Desert of North Ro.
I get the same thing when doing a /who <class>
[65 Iksar Enchanter
] "playername", <Guild Name>
(523.23 WNW
)
<Guild Name>
<Guild Name>
<Guild Name>
<Guild Name>
There are
5 players in <zonename>.
Posted: Sun Nov 02, 2003 7:09 pm
by Lax
Problem has something to do with nopets. If you look at debugspew it'll have several lines of find pet spam for the one mob.
Posted: Sun Nov 02, 2003 7:56 pm
by pooz
/who pet
List of (null)s
--------------------------------
(0-100) (null) not found.
Posted: Sun Nov 02, 2003 8:17 pm
by Mckorr
SuperWho is a mess right now, basically nonfunctional, and that is with the latest dev CVS. Dunno what is causing the problem.
Posted: Sun Nov 02, 2003 9:26 pm
by MacroFiend
I'm not sure why the nopet feature would cause this kind of error. The default of finding pets may but when the nopet argument is there, it totally bypasses the search for pets and the corresponding output.
The SuperWhoFindPets uses the SpawnID of the spawn being checked, looks for a pet and runs SuperWhoDisplay to show that pet. Control is then returned to the SuperWhoDisplay to continue its loop through the other search results.
When I ran it, the extra lines were everything except the first three characters of my guild name.
*edit:
Were there any recent struct changes to SPAWNINFO or SWHOSORT? It seems like either the iterator isn't incrementing when sorted or the data is going to the wrong place.
Reverting to 11/1a codebase and the SWho functions work properly. Will add in the CVS diffs until I break it :)
Posted: Sun Nov 02, 2003 10:07 pm
by Plazmic
Latest zip seems to work fine... I don't play well with CVS...
I've fixed the "/who pet" -> (null) issue on my system (which is 100% unrelated to nopets)
Posted: Sun Nov 02, 2003 10:56 pm
by MacroFiend
I found the code block that actually seems to have broken it. The red code is where the /who stopped behaving properly. I have no idea how the filters work or if they are just not initiallized properly for a clean install since they are Plaz's but when I used the SRC-20031102a.zip, I had the same issue until I removed the red code.
EQLib_UI.cpp
Code: Select all
void CChatWindow__AddOutputText(PEQCHATWINDOW pWnd, const char *Text, int RGBA=0)
{
if (!pWnd || !Text) return;[color=red]
PFILTER Filter = gpFilters;
while (Filter) {
if (!Filter->pEnabled || (*Filter->pEnabled)) {
if (!strnicmp(Text,Filter->FilterText,Filter->Length)) return;
}
Filter = Filter->pNext;
} [/color]
char out[MAX_STRING];
Posted: Mon Nov 03, 2003 5:01 pm
by Mckorr
Confirmed. Commented out that code and SuperWho started working correctly again.