Secrets of Faydwer - Bug Tracking

[Secrets]

Originally Posted by trevius

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.

[Secrets]

Originally Posted by Secrets

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.

[Shendare]

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.

[trevius]

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

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

Cosmetic Work:
1. Spawn Structure - The spawn structure could use a few more fields to be identified (hair/beard color, hair, other facial features, sneak, and invis).

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.

[Shendare]

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

[warhawk]

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

[trevius]

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.

[kimura0715]

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

[ojamajoe]

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.

[Davood]

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?

[Davood]

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

[trevius]

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:

if (level > 75)
{
  BaseHP = 5;
  BaseEnd = 5;
  BaseMana = 5;
}

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.

[Secrets]

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.

[trevius]

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.

[Secrets]

Originally Posted by trevius

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.