Quote:
|
Quote:
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 Quote:
|
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:
Code:
if (level > 75) 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.
|
Quote:
Take a look at the Client::SendItemPacket function. This shows an example of how this is done in tributes. |
All times are GMT -4. The time now is 11:13 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.