PDA

View Full Version : 2 small bugs



BlueAdept
10-02-2003, 07:45 AM
When you go to save the options, I noticed that if you have the Log Spawns checked, the next time you load SEQ, it will be unchecked again. Ill try to look at this and get a patch for it submitted.

Next question/possible bug:

Light sources. It doesnt seem to show light sources any more. Did sony remove the ability to see them or is just something screwed up?

BlueAdept
10-02-2003, 10:42 AM
As for the logging of spawns it is going to take me longer than I hoped. Ive got to figure out what is what.

In the seqdef.xml it has these 2 entries.

<property name="SpawnLogEnabled" >
<bool value="true" />
<comment>set to false to not log spawns</comment>
</property>


<property name="LogSpawns" >
<bool value="false" />
<comment>enable logging of spawns</comment>
</property>

Arent they the same thing? It seems to use the second one because it is always set to false. I think somewhere in the code, these 2 are getting mixed up.

When you save the prefs, it probably saves to the top one but it reads from the bottom one. Ill let you know what I figure out.

fester
10-02-2003, 11:22 AM
Originally posted by BlueAdept
Light sources. It doesnt seem to show light sources any more. Did sony remove the ability to see them or is just something screwed up?

Sounds like everquest.h structures for spawns has the light source pointing to the wrong area of the payload. They likely moved it and we have never went to WC and found a glowing will-o-wisp to locate the GLS position?

Zaphod
10-02-2003, 01:04 PM
Originally posted by BlueAdept
As for the logging of spawns it is going to take me longer than I hoped. Ive got to figure out what is what.

In the seqdef.xml it has these 2 entries.

<property name="SpawnLogEnabled" >
<bool value="true" />
<comment>set to false to not log spawns</comment>
</property>


<property name="LogSpawns" >
<bool value="false" />
<comment>enable logging of spawns</comment>
</property>

Arent they the same thing? It seems to use the second one because it is always set to false. I think somewhere in the code, these 2 are getting mixed up.

When you save the prefs, it probably saves to the top one but it reads from the bottom one. Ill let you know what I figure out.

And neither of the values do anything at the moment. "Log Spawns" option doesn't save in either right now. And oh yeah, there are two command line options, one to override each of these entries. But wait, there's more, the SpawnLogger is currently always instantiated and logging spawns. I just found a 125MB spawn log on my system. What a mess. This will be fixed in my ne`xt CVS commit.

Enjoy,
Zaphod (dohpaZ)

Elyon
10-02-2003, 01:08 PM
Just a heads up on the spells. I don't know if anyone else has this happening or to what extent it goes, but on my Druid, I cast any spell that isn't currently on the spell list from when I first log in to EQ. It shows up in the spell windows, but only WHILE it is being cast. When it is done being cast, it disappears from the SEQ Spell Window. Then , if I zone, it reappears in the spell window with what appears to be the correct time left. This is with 4.3.13a

In the Text Window I get: (id#) is actually a 3 digit number

SPELL: You begin casting Mask of the Hunter. Current Target is Toonname(id#)
SelfStartSpellCast - id=1565 on spawnid=id#
selfFinishSpellCast - id=1565, by=2
Dropping buff - id=1565 from spawn=id#


Same thing happens for all spells that are cast, but then, if I zone, they show back up. All Spells are sucessfully loaded at startup, ie: Loaded 4294 spells from '/path/spells_en.txt maxspell=1142

UPDATE: If the spell is cast on anyone but myself, it stays in the SEQ Spell Window.

Also, did the ability to delete a spell from the spell window by double clicking the middle mouse button get removed? This is no longer working.

One more thing I have noticed, The EQTime in SEQ is 1 hour ahead of EQTime in the game.

To fix the Time, in Packet.cpp on line 3255 change -1 to -2 and the time is correct. (Maybe Sony is on DST!)

BUMP

Still does the same thing in 4.14 No Self Cast spell stays in SEQ Windows until you zone, then it's refreshed by the Leftover Buff code.

Zaphod
10-02-2003, 01:16 PM
Originally posted by Elyon
Just a heads up on the spells. I don't know if anyone else has this happening or to what extent it goes, but on my Druid, I cast any spell that isn't currently on the spell list from when I first log in to EQ. It shows up in the spell windows, but only WHILE it is being cast. When it is done being cast, it disappears from the SEQ Spell Window. Then , if I zone, it reappears in the spell window with what appears to be the correct time left. This is with 4.3.13a

In the Text Window I get: (id#) is actually a 3 digit number

SPELL: You begin casting Mask of the Hunter. Current Target is Toonname(id#)
SelfStartSpellCast - id=1565 on spawnid=id#
selfFinishSpellCast - id=1565, by=2
Dropping buff - id=1565 from spawn=id#


Same thing happens for all spells that are cast, but then, if I zone, they show back up. All Spells are sucessfully loaded at startup, ie: Loaded 4294 spells from '/path/spells_en.txt maxspell=1142

UPDATE: If the spell is cast on anyone but myself, it stays in the SEQ Spell Window.

Also, did the ability to delete a spell from the spell window by double clicking the middle mouse button get removed? This is no longer working.

One more thing I have noticed, The EQTime in SEQ is 1 hour ahead of EQTime in the game.

To fix the Time, in Packet.cpp on line 3255 change -1 to -2 and the time is correct. (Maybe Sony is on DST!)

BUMP

Still does the same thing in 4.14 No Self Cast spell stays in SEQ Windows until you zone, then it's refreshed by the Leftover Buff code.

Elyon, these are seperate issues and should be in their own thread for ease of response purposes and so this thread doesn't get muddled. This is my last repsonse to this message in this thread.

Enjoy,
Zaphod (dohpaZ)

BlueAdept
10-03-2003, 11:17 AM
Originally posted by fester
Sounds like everquest.h structures for spawns has the light source pointing to the wrong area of the payload. They likely moved it and we have never went to WC and found a glowing will-o-wisp to locate the GLS position?

I killed a will-o-wisp that had a lightstone on it, but I didnt see any error in the console window. How do I go about finding out the proper structure to get it to work again?

fester
10-03-2003, 11:27 PM
Originally posted by BlueAdept
I killed a will-o-wisp that had a lightstone on it, but I didnt see any error in the console window. How do I go about finding out the proper structure to get it to work again?

I must say this is so cool. Lots of people helping fix ShowEQ.

Best way to fix this:

Kill a will-o-wisp that HAS a GLS (you examined the loot.)

Grab the recorded hexdump of the spawn with the same spawnid as the will-o-wisp you killed.

Look for hex 0x0b byte. Take note of any 0xb (nibble; half a byte; or 4 bits) in the spawn struct.

Kill a will-o-wisp that HAS a LS (lightstone.)

This spawn struct should have 0xa in the spot the other spawn had a 0xb. Change everquest.h spawnstruct to reflect the new location of the light information.

It is very unlikely they changed the values of the light tags so the information in spawn.cpp is still valid (line 533.)

If you find that 0xb and 0xa do not appear. Then they have done one of a couple things:

1) Created a new opcode to pass light info (unlikely.)
2) Changed the values of the light indicators.

If #2, then kill a bunch of will-o-wisps and diff all structs with identical levels (but with different light values until you find a common changed value.

BlueAdept
10-04-2003, 10:16 AM
Have a question. Im not quite sure how you record it. I checked everyone one in the network log menu (ie all packets, world data, zone data, unknown zone data and raw data.) but still cant seem to find the info for the spawn ID. I did get the spawn ID from console window.

I did notice a little bug It says unknown zone data is F8 and Raw Data is also F8.

fester
10-04-2003, 02:26 PM
Turn on zone.log and look in there.

Format:

Decoded - Client->Server: (194) Sat Oct 4 09:52:35 2003
000 | 9d 00 ...

"(194)" means 194 bytes long.
"9d 00" means opcode 0x009d (SaveZoningPlayerCode)

Once you have a spawn ID, look for packets with that spawnid in zone.log.

NewSpawnCode is 0x0201, so look for:

000 | 01 02 ...

Then look at the 45th byte:
everquest.h:
/*045*/ uint16_t spawnId; // Id of spawn

032 | 00 00 00 73 01 c0 08 00 00 00 a0 d7 ff 00 02 82 | ...s............

In this case, this is spawnID 0x0200 ("00 02" and convert. 00 is the low bit and 02 is the high bit, so 0x0200 or 512)

Make sense?

BlueAdept
10-04-2003, 07:25 PM
I believe I found it. Ill let you know (and submit a diff) if I am correct.

Thanks for putting me on the correct track.

BlueAdept
10-04-2003, 08:03 PM
It works.

It was changed to 024.

I would probably have never found it if you hadnt told me that it would show 0a or 0b. All burned out are 0a and LS are 0a. 0b's are gls.

Ill try to get a diff for you tonight.

EDIT: Patch submitted.

Thanks again :)

fester
10-05-2003, 02:35 AM
Your most welcome. I am just happy more people seem to care and less people seem to whine. The more people that care and try to fix it, the less likely each of us have to do all the work.

BlueAdept
10-05-2003, 07:28 AM
Its a lot like hacking the old dos games looking for your characters and changing all the stats to 255 :D

Broseq
10-06-2003, 08:14 AM
Great news on the Lightstone effect. This will also simplify the search for the dreaded Glowing Bile in GD.

Thanks!

BlueAdept
10-06-2003, 09:11 AM
Yea that is why I did it. I needed it to see which had the bile. I also made approximately 80pp in GLS's trying to do this :)