Orphaned skittles

[Reliant]

I'm seeing a lot of orphaned mob skittles (and player ones too) in the current version. Anyone have a clue where I should look in the code to identify the problem?

[pita]

I am seeing this as well. Figured I had missed changing something.

Going to get a fresh version and apply changes again, to make sure.

[sammie]

Can someone try <opcode id="5331" name="OP_DeleteSpawn" updated="11/03/10"> that plays on live? If you change it in /usr/local/share/showeq/zoneopcodes.xml all you need to do is restart SEQ to test it.

The patch today on Test Server caused the same symptoms, I think this was a case of live getting an emergency patch before Test did.

[pita]

That didn't do it.

Warning: OP_DeleteSpawn  (0x5331) (dataLen: 8) doesn't match: sizeof(deleteSpawnStruct):4

Skittles don't seem to update position after making this change either.

[sammie]

Ok, thanks for trying that, saves me hours of patching between test and live. I'd go ahead and change it back because that value apparently is only good on test server at the moment.

It does however sound like skittles are not getting cleaned up properly, and that's usually due to OP_DeleteSpawn or OP_RemoveSpawn not being correct. If there are any enterprising folks out there who can find the current opcodes for those, it should solve the problem.

[Razzle]

I only just got live patched yesterday. If I get a chance this weekend, I will get linux up and going and see what I can figure out.

I am playing the mix and match game with old computer parts, to get a functional box. I am such a cheap skate.

Razzle

[Razzle]

See if this helps.

    <opcode id="0b93" name="OP_ZoneChange" updated="11/3/10">
        <comment>old ZoneChangeCode</comment>
        <payload dir="both" typename="zoneChangeStruct" sizechecktype="match"/>
    </opcode>

I did not change the OP_DeleteSpawn opcode.

Razzle

[pita]

I had that opcode for OP_ZoneChange already.

[Razzle]

I had that opcode for OP_ZoneChange already.

Oh. I didn't. But it sure was messing my skittles up though.

Razzle

[Razzle]

Here are all the updated world opcodes that I was able to figure out. Working on zone ones next. I am learning how to do all this opcode crap. Working on the EMU code sure has helped.

    <opcode id="5B0B" name="OP_GuildList" updated="01/17/08">
        <comment>old GuildListCode</comment>
        <payload dir="server" typename="worldGuildListStruct" sizechecktype="none"/>
    </opcode>
    <opcode id="D677" name="OP_MOTD" updated="11/07/10">
        <comment>old MOTDCode Server message of the day</comment>
        <payload dir="server" typename="worldMOTDStruct" sizechecktype="none"/>
    </opcode>

<!-- Not necessary for SEQ to run but here to name packets in logs -->
    <opcode id="6893" name="OP_SendLoginInfo" updated="11/07/10">
        <comment>Client starting world session by asking for login information</comment>
    </opcode>

    <opcode id="3288" name="OP_LogServer" updated="11/07/10">
        <comment></comment>
    </opcode>
    <opcode id="115A" name="OP_ApproveWorld" updated="11/07/10">
        <comment></comment>
    </opcode>
    <opcode id="3288" name="OP_EnterWorld" updated="11/07/10">
        <comment>Server approval for client to enter world</comment>
    </opcode>
    <opcode id="1771" name="OP_ExpansionInfo" updated="11/07/10">
        <comment>Which expansions user has</comment>
    </opcode>
    <opcode id="1B85" name="OP_SendCharInfo" updated="11/07/10">
        <comment>Send all chars visible @ char select</comment>
    </opcode>
    <opcode id="3C2D" name="OP_SendSpellChecksum" updated="11/07/10">
        <comment>Contains a snippet of spell data</comment>
    </opcode>
    <opcode id="30E2" name="OP_SendExeChecksum" updated="11/07/10">
        <comment>Second client verification packet</comment>
    </opcode>
    <opcode id="2B5F" name="OP_SendBaseDataChecksum" updated="11/07/10">
	    <comment>Second client verification packet</comment>
    </opcode>
    <opcode id="2874" name="OP_SendSkillCapsChecksum" updated="11/07/10">
        <comment>Third client verification packet</comment>
    </opcode>
    <opcode id="0A54" name="OP_SetChatServer" updated="11/07/10">
        <comment>Chatserver? IP,Port,servername.Charname,password(?)</comment>
    </opcode>
    <opcode id="37DB" name="OP_SetChatServer2" updated="11/07/10">
        <comment>Chatserver? IP,Port,servername.Charname,password(?)</comment>
    </opcode>
    <opcode id="0479" name="OP_ZoneServerInfo" updated="11/07/10">
        <comment>old ZoneServerInfo</comment>
    </opcode>
    <opcode id="72F3" name="OP_WorldComplete" updated="11/07/10">
        <comment>Client telling world server it is done. World replies by disconnecting.</comment>
    </opcode>
    <opcode id="2730" name="OP_DeleteCharacter" updated="11/07/10">
        <comment>Delete character @ char select</comment>
    </opcode>
    <opcode id="49B6" name="OP_CharacterCreate" updated="11/07/10">
        <comment>Create character @ char select</comment>
    </opcode>
    <opcode id="6E97" name="OP_ApproveName" updated="11/07/10">
        <comment>Approving new character name @ char creation</comment>
    </opcode>
    <opcode id="0005" name="OP_RandomNameGenerator" updated="11/07/10">
        <comment>Returns a random name</comment>
    </opcode>

Razzle

[Newby]

I changed OP_DeleteSpawn to 0x5331 and OP_RemoveSpawn to 0x7434. That seems to work, but I'm not sure if both were necessary. I don't understand what the distinction is between the two Ops.

[Spanners]

I'll be having attempt 4 at getting things to behave later, each time I end up with spawns not updating, corpses don't register as corpses and things like swarm pets just grow in numbers.

I'm getting old and senile, so lots of changes make me confused. It can't possibly be the amount of beer, can it?

[Razzle]

Work and school got busy. So never got time to work on this more. I found out that EQExtractor2, over on the EMU project, has a lot of the opcodes mapped already. So what is needed is probably there.

Razzle

[fransick]

Anyone else's console fill up with this?

Debug: SpawnShell::fillSpawnStruct - expected length: 364, read: 363 for spawn 'a_royal_guard00'
Debug: SpawnShell::fillSpawnStruct - expected length: 261, read: 260 for spawn 'a_scavanger_beetle03'
Debug: SpawnShell::fillSpawnStruct - expected length: 258, read: 257 for spawn 'a_dream_phantom07'
Debug: SpawnShell::fillSpawnStruct - expected length: 365, read: 364 for spawn 'a_royal_knight04'
Debug: SpawnShell::fillSpawnStruct - expected length: 365, read: 364 for spawn 'a_royal_priest01'
Debug: SpawnShell::fillSpawnStruct - expected length: 364, read: 363 for spawn 'a_royal_guard01'
Debug: SpawnShell::fillSpawnStruct - expected length: 365, read: 364 for spawn 'a_royal_priest04'
Debug: SpawnShell::fillSpawnStruct - expected length: 261, read: 260 for spawn 'a_scavanger_beetle01'

I've also noticed ground spawns are not showing anymore. I don't think I've borked all the edits needed from current svn to get skittles but it's possible.

[sammie]

Anyone else's console fill up with this?

The function fillSpawnStruct in spawnshell.cpp needs work. Some changes to the packet structure were made to accomodate the "no-collision" auras that were patched in with the last big update. There doesn't seem to be any stability issues with it at the moment, so if the messages bug you, you can filter them in SEQ with Interface > Terminal > Message Type Filter > Debug until a dev has time to fix it.

As for ground spawns, I can see them in my client, so it is probably just a matter of checking that you have the correct opcode for them. I'm using <opcode id="5F0D" name="OP_GroundSpawn" updated="06/12/09"> on test, might be different on live.