Secrets of Faydwer - Bug Tracking
 

This post is created to allow us to track bug reports with Secrets of Faydwer. A current list of the known issues for development tracking can be seen here:

http://www.eqemulator.net/forums/showthread.php?t=27429

If you find a bug that is not already on that list, please post it in this thread (not the development thread linked above) and I will get it added to that list. The list is updated regularly, so check back for current status and updates on bug reports and resolutions.

Here is a list of some of the known issues/bugs with SoF and what is known about them:
1. /who - /who actually works almost perfectly now. But, if you search for /who <name> or use /whotarget, it returns all players in the current zone.
2. Item Trading - Appears trading items may not always work perfectly. This is almost certainly a slot issue with the trade window and can probably be corrected with an adjustment to the encode/decode of it.

Unverified Bug Reports:
1. Disciplines Failing - Reports of some disciplines failing to execute. I think this happens on all clients.

SoF Bugs with the client iself:
1. Highhold Keep - From the brief testing I did on this, it appears that trying to enter the old HHK zone causes the client to crash and it needs to be moved out of the zone for them to be able to log in again. The old HHK zone was removed from the newer clients, and so they cannot access that zone.


Fixed Bugs from this post:
1. Fast Food/Drink Consumption - Food and Drink now get consumed at the proper rate.
2. Throwing/Ranged Animation - The throwing animation is now working (thanks Derision!)
3. Animation - All Animation issues are now resolved (thanks Derision!)
4. Drakkin Corpses - Drakkin corpses (as well as Froglok corpses) now show properly even after a zone dump occurs (thanks Derision!)
5. Spell Fizzles - After fizzling a spell, there is an especially long delay before the spell can be recast. It appears that there may be different ways of handling spell fizzles in SoF. In Titanium, I believe it was treated like a normal spell interrupt.
6. Disconnect on Death - You are no longer disconnected on Death in SoF.
7. Potion Belt - Potion belt appears to function correctly now.
8. Total Spent AAs - This is now reported correctly for all clients including SoF and SoD.

I will add more to this list later.

I was messing around on my 30 days that came with SoF, and this would go under new systems. There appears to be the rest system now. Once a player leaves combat a 30 second timer begins, once that 30 second timer is up the player can med/regen 2x faster while sitting. I didn't see it on the list so figured I'd throw it out there.

What's with the bind traps? Human guys with "Bind Trap" for a name. There is one near the bank in POK.

Yeah, I was going to ask about this. They showed up a couple of rev's ago. Anyone know what they are?

If this clutters this thread too badly, feel free to move it to its own thread.

Besides the things like the bind traps in pok, or the shortened item link text, I've noticed a number of things that either haven't been mentioned, or have been talked about a bit but not the same symptoms I found.

Quick info: using rev408-bots (binaries). DB and quests aren't newest, but merely a few days old (April 8th?). Most testing done in sof, some comparisons done in titanium, all done with minilogin.
In previous sessions, I've had issues with zone going to sleep when I'm zoning, so set up a boot3zones.bat to test if issue's with launcher or zone.

Quicker stuff first:

Now the larger part, with clips of feedback from world and zone windows.

Qeynos Zone:PoK Zone:Tested note again, in Nexus. Again locked up mouse and prevents inventory screen from opening. Zoned into shadowhaven. Zoned in ok, mouse usable again, but went linkdead after trying to consider a guard.
Ran Titanium client, created nearly identical character, read note, no issues.

Upon linkdeath in shadowhaven, debug net errors occurred again, preventing access to feedback in zone screen due to the number of these errors.


World feedback:

Thanks for the reports, but remember when testing SoF and reporting issues, it is very important that you are using the absolute latest updates from the SVN. While the binaries try to stay somewhat current, they can get behind fairly quickly considering how quickly the SoF updates come in at times.

Almost every issue you mentioned has already been corrected as of Revision 432, which is the current one ( quite a few updates since R408 ). See the change list here for recent updates:

http://code.google.com/p/projecteqemu/source/list

I think the only issue you mentioned that hasn't been addressed yet is the issue with books. I haven't even tested them yet personally, but I would guess that we probably need to adjust the structure for them to work properly.

As for the hex you are seeing in your log files, that can be any number of things. Most of the stuff you see in there atm should be perfectly normal.

I think the bind traps are something specific to the new PEQ database updates. I am not exactly sure what they are, but I would guess they are something similar to the Illusionist I have set on Storm Haven. Basically, I use that NPC to move players from their spawn point so you don't get 20 characters all piling up on top of each other. Otherwise, it can get characters stuck and also causes heavy position updates to be sent out wasting a ton of bandwidth. I dunno if PEQ has them set to be invisible in Titanium, but if so, they might need to do something different to make them invisible in SoF. I think race 240 works fine for invisible NPCs no matter what client. Also, I think that the invis field in the spawn structure for SoF isn't found yet, but that is on the todo list.

Bind Traps were collecting from Live. We don't use them on PEQ, as we're not sure what they are used for. However, they and I noticed many other "trigger" type NPCs are visible using SoF and are not using 0.6.2 and Titanium. I figure that will be ironed out eventually :)

Couple things I noticed while playing on my server using SoF client. My server is at rev 437 using PEQ svn 4

Spell fizzles:

If you fizzle a spell the recast time on it seems extra long.

Bags:

If you purchase more bags from a vendor than you have open slots bags will start going into other bags.

Now please note I have not played on live in like 5 years and have been playing on the titanium client since it was first supported by the eqemu project. So that is pretty much what I know, and I am not sure if these are legit changes per live, or if they are bugs.

Animations:

Iksar monks have no throwing animation. Not sure if this applies to other races or not.

Arrow
 

For archery, the archery animation works, but the arrow animation doesn't show. I do see the arrow in the Titanium client so maybe the SoF client doesn't recognize the SendItemAnimation()? Code from special_attacks.cpp:

A few more bugs I have noticed:

Items such as "Silver Moon Wrist Wraps" that have a long cast time do not show the casting progress bar decrease until there is a few seconds left on the timer. This particular item has a 25 second cast timer and it does not start decreasing the timer until about 20 seconds into the cast.

Right clickable items that are labeled "Must Equip" are castable from inventory. You should have to put them into a slot to use them.

Disciplines don't seem to be working from my limited testing. They say I need to be out of combat, regardless if I am in combat or not.

That seems odd since many are designed specifically for being used in combat.

That may be a spell file issue. It probably depends on how you have your server setup. If you use a custom spell file, you probably need to create one to use for SoF as well so they match up. They seem to work fine for me after I did that.

What you should do is use the new import/export scripts that AndMetal made. You can import your custom Titanium spell file into the database using them. Then, export it back into the same file. What that will do is add all of the extra spell fields that are required for SoF. Otherwise, if you try to use a plain Titanium spell file on SoF, it crashes the client. But, by doing the import and export, the spell file will then work for both clients. The file is always backwards compatible (as far as I know), but it is not forwards compatible.

I may need to do more testing on Discs, but so far they seem fine to me.

It's probably the disc type, since all of the spells on KMRA were hand-made and it would seem in SoF some of them are hardcoded to have a specific disc re-use as out of combat only. I'll try and get the number on the one that doesn't work, but some discs do work, some don't... i'm willing to bet it's spell file dependant.

Just an update on this, for reference:

I ended up importing the spells, exporting them, and some spells were working because the number of fields was correct for titanium. Some of the older spells Raid Addicts has did *not* have all the required fields for titanium, however the titanium client still read the spell. When I converted this over to SoF with the import/export technique, those spells got corrupted. I ended up taking my broken file and opening it up in Ailia's Spell Editor, and then save it without doing any changes, and that added the missing fields.

It's a good thing to know, because if I didn't have those fields, they would have got parsed incorrectly into the DB (which they did initially) and then broken in the end SoF client. So, I imported and exported again after saving the spell file again, and this time it made a very nice Secrets of Faydwer compatable spell file.

Just wanted to post my progress on this for reference.

I'm sure this is a low priority, but I notice that with the SoF client and rev488 codebase, the npc_types fields luclin_hairstyle, luclin_haircolor, luclin_beard, and luclin_beardcolor are not being recognized.

All Luclin-model playable-race NPCs display the defaults for these values, regardless of the database's settings.

The Titanium client appears to be able to work with the aforementioned fields' values, and both clients are able to acknowledge face, luclin_eyecolor, and luclin_eyecolor2.

Thanks for the report, Shendare, but that is already a known issue as posted here:

http://www.eqemulator.net/forums/showthread.php?t=27429

That post is updated regularly, so please make sure to check there as well as the first page in this thread before posting new bug reports.

I totally missed that while looking over the list. Sorry about that! Feel free to delete my post!

Potion belt bug
 

Hi

I've noticed a bug with the potion belt using the SOF client. If i have a stack of 6 potions it shows 36 in the potion belt icon. Also ,when clicked it gives the error message Error: item not found in inventory slot 272..

This is on PEQ using version 491

Sounds like we need to set a slot encode for the potion belt as well. The whole slot change thing from Titanium to SoF is probably one of the biggest pains of anything lol. I will add that to the list of bugs and try to take a look at it later tonight. Thanks for the report.

Edit: After checking on this a bit, it seems that the slot problem is caused by OP_CastSpell. Looks like we just need to set an encode to convert all of the inventory slots (including inside bags) from Titanium to SoF, since almost all slot numbers changed. This should be a fairly simple change. I am not sure what else is going to need to be done to allow potions to be cast while inside bags as that might be a restriction by castspell itself. If so, I am sure we can correct it, but it will probably mean doing some type of check for if the item is a potion or not, because normal clicky items shouldn't be clickable from inside bags.

not sure if its reported yet, but on my server, if using SoF, some of the augs are invisible....if u do link all on the mob's corpse it will show an aug, but its invisible...i can even loot it and put it in a bag, but just cant see it

Variables:expansions
 

The SOF client seems to ignore the value set in the database under variables: expansions. Hardly earth-shattering, but some people like to use this to limit features.

The SoF client seems to display hp strangely above level 75, it doesn't show the base HP and the stamina/wis/int calculated HPs/Mana (IE a naked level 76 toon would have like 50 hp/mana). Items and such work fine;

Could we send a higher hp value to the client as a work around? Is this even a client problem? SoF client should be doing calculations properly until level 80 right?

ok after some testing;

it looks like the BASE HP and the HP from stamina is not being sent to the client when the cilent is over 75. The hp on the server side is fine however....

is the client handling the hp differently over 75?!?!

Keep in mind, we are talking SoF client

Yeah, it is the SoF client, but the eqgame.exe version that was used for SoF was actually released on Live over a month before SoF actually came out. So, since the cap was still level 75 at that time, maybe they had the client limited to not calculate base HPs/Mana/End above that level yet. I am guessing they have some if statement in there that says:

That is my guess as to what the client is doing, NOT what the EQEmu server is doing. The EQEmu server calculates stats just fine for post 75, but the SoF client isn't so friendly about it. So, while SoF fixed the issue with skills rolling over when higher than the level cap (like Titanium has an issue with), they introduced a new issue with HP/Mana/End not being calculated properly.

I am sure there is more than 1 way around it, but one idea would be to just pick a common slot and send the base hp/mana/end of the char for the item in that slot if they are over level 75. So, if your base HP should be 2000, and we are putting it on a charm that has 50HPs on it already, the charm would actually display as having 2050HPs for chars over level 75. This would all still be calculated the normal way server-side, but would just be a work-around hack to trick the client. It would actually be fairly simple to do this change, I think.

You could always make a function to send a fake item to a weird slot on the player. That way, the player equips it, and gets the statistics from it, but doesn't actually see it.

If the player can't see it, neither can the client, unfortunately. The only option I can think of that would be similar to that would be to force the Power Source slot to always be equipped and for that slot to handle the level 76+ base hp/mana/end.

Incorrect; the player cannot see tribute slots, which are invisible slots. Could always add it to the base of the tribute items + the tribute effects.

Take a look at the Client::SendItemPacket function. This shows an example of how this is done in tributes.

I'll actually code this just so we can get this working, instead of arguing it pointlessly :P

He's right, here's some very simple code demonstrating the concept:

Makes the client gain the stats of the item in your lower right inventory slot without equiping it. It's somewhat complicated in terms of a client hack but in theory yes it could certainly work.

Awesome! I forgot about tribute being invisible item slots. That should work perfectly, and as far as hacks go, at least that would be a fairly clean one as far as the client is concerned.

this not gonna screw up the actual tribute in anyway? Not that I care much for tribute, but I am just curious.
Also - since this is a fix for SoF - will people running T be adversely affected?
Since post 75 T client shows hp correctly already.

Well in the sever handshake; the server knows if the client is running titanium or SoF; therefore you can run the extra code just for the SoF clients.

That or you can not be lazy and I don't know account for the tribute in there too. That's what I meant by somewhat complicated.

I hacked up the tribute code and came up with this.

tribute.cpp, replaced the entire function

inventory.cpp, new function

and the corresponding header function in Client.h

and lastly, make it so every time a player gains a level that it recalculates tributes & sends a new item, effectively granting the player a new stat, exp.cpp:

near

that should do it. most of the hard work is done.

Also, I would change 1001 to a blank item, or use a non-used ID like 10 for the item. That will resolve adding AC to the client.

Other than that, it works.

I would actually add it into CalcBonuses(); near the end, since that's the most logical place for it, seeing as it needs to be updated every time your hp/mana/end is changed, now that I think about it :p

As per KLS' suggestion, I should use new instead of malloc(), so I am going to. I should also free memory :P

I'm pretty sure this kills some tribute functionality which isn't acceptable but based on what's here we can rewrite this to be more consistent with our codebase:

And there isn't a point in making a SendFakeItem() when it copies SendItemPacket word for word. All that said I think it's an acceptable proof of concept and I think we can put it into action. =p