So bandolier function is safe to use in RoF2 client? Before it was a great way to destroy your weapons. In fact Hunter even has a post on here somewhere saying, "Use bandolier and lose your epics you're SOL"

The changes I made do not affect the functionality of the bandolier itself.  It only fixes a graphical display issue where a Treasure Chest icon was being displayed in empty bandolier slots.  I believe the bandolier is much better than it was years ago after some fixes were added quite a while back, but I am not 100% positive it is flawless at this point.  Bandolier still functions the exact same way on RoF2 as it did/does on UF or any other client.

If anyone has been regularly using bandolier and has had issues, or not had issues, it might be good to get some feedback on the subject.  Details of issues can help to get them isolated and resolved when time permits.

[Hate]

The exp buff seemed to be using a nimbus-like particle effect that never faded.


-Hate

Many of the nimbus effects don't fade.  It is possible that they changed whatever effect you are using on the spell (or script) to be a permanent one instead of temporary like normal spell effects.  If that is the case, I would suggest either changing the effect, or maybe adding a script to stop the nimbus effect shortly after it is cast.  I would have to do testing to be sure of exactly what is going on though.  Again, if you know the actual effect value for the visual, that would help a lot.

I will check out the remove nimbus effect stuff to make sure it is working correctly.  To be clear; is this effect something that only shows up briefly on older clients and then clears, but does not clear on the RoF2 client?  Or, is the issue that the effect stays on you on all clients, but for some reason it is actually visible when playing in 1st person on RoF2 client?  If that is the case, it sounds like it could be something weird with how the client is handling the effects.  I will do some tests and see if I can resolve it.  Would help to know which nimbus effect ID it is that you guys are reporting as a blue spell effect (more of a question for the EZ devs).

This actually has to do with the RoF client, it loads a lot of resources on demand so what happens when you zone is that you are seeing a freeze where it is loading race models into the client on demand via memory so it locks up for a quick second. This is purely a client thing which is not really an issue even though it is slightly bothersome in the beginning.

You notice this because you zone so much more faster on EQEmu than you would on EQ Live servers that your toon enters often times before NPC's. Otherwise before your toon is given the 'Ready state', it is sent all the NPC and door positions before it is given the zone to drop into which allows it time to load resources. In this case, you're zoning so fast its happening backwards and then the client loads everything just after zoning.

Hopefully that makes some sense.

While the load on demand could definitely be the cause of the lag spikes on RoF2, I am not 100% convinced that is the issue yet.  I hadn't experienced these lag spikes on my GM char previously, but I loaded a level 1 char and saw the spikes yesterday.  Kayen had mentioned that they come in as the no mercenary messages come in.  So, it may be some kind of lockup related to the merc packets that are getting sent.  I am not sure offhand if EZ gets these messages since Mercs are not enabled there, but I don't think there is anything preventing them, so you may get those messages.

Once most of the RoF2 remaining issues are resolved, I will look into this lag spike issue further to see if it can be resolved as well.  It will be easy to prevent the messages from coming in on servers that don't use Mercs (if you guys even get those messages).  Also, I need to look into why the message is coming in twice, and probably need to prevent it from coming in at all.

We are also still looking into the buy now button issue for aug slot type 21.

The "Buy Now" button issue on aug type 21 slots has now been resolved in the latest source code.

Not sure if this has been stated but, since the update this morning i can no longer put heroic resist augs into my t5 gear on my intellect casters.  I tried to see if it was a problem on the other classes and it is not.  So far my necro and enchanter can not add augs to thier t5 gear.  It gives you a message saying "the item does not meat the augment restrictions".  I tried to see if i could insert these augs in the UF client and i was able to do it.  I do not know if this is happening to other tier intellect gear.  This problem is not happening on your non set armor.  Belts,face etc. still can be slotted

This issue should now be resolved in the latest source code updates (not on EZ yet).

Experienced the looting bug. Tried to loot on one toon and item wouldn't loot. Second toon wasn't able till I camped 1st toon out then same issue. Had to swap to UF to get loot.

We are aware of this issue and still investigating.  I am sure it is related to slot conversions from old system to the new clients.

We are also still looking into the buy now button issue for aug slot type 21.

Again, here is the thread on EQEmu where we are tracking all remaining issues and which are resolved:
http://www.eqemulator.org/forums/showthread.php?t=39092

Trader seems to be non functional with ROF. Can search or buy from a trader in UF client, cannot interact at all with traders in RoF.

Yes, that is a known issue with RoF and will probably be one of the last things that gets fixed on RoF2.  This is because the trader system was completely overhauled since UF.  It now uses a system that you can access from any zone.  It will be a really cool system once implemented, but it is complicated and will take a good amount of work I think.

Here is the development tracking thread for RoF2, which documents all of the current known issues and such:
http://www.eqemulator.org/forums/showthread.php?p=236264

Using ROF client, got a new bracer from t8 today tried to put on just one HR7 aug, and it says "that item does not satisfy the augments restrictions" I had no issues yesterday putting augs on.

I don't know why this would be an RoF2 specific issue.  Does it work properly in UF?  If not, maybe there were database changes for aug slots?

Run speed is down.  On both clients.

Ranged clicks are slowed on both as well.    I can click my bow to pull, turn and run back toward camp before the arrow aggro's the target.

Possible results of server code updates on the whole and not just the implementation of ROF?

The arrow thing is probably related to some recent changes to how projectiles work.  That would be the same for all clients, not just RoF2.

are bank and merchant pets following us around until they poof going to be a way of life now?

That isn't related to RoF/RoF2 specifically.  That was a global change to how temp pets work.  I think the easiest solution is to have the NPC's Runspeed set to 0.

Two more issues I have found:

1) Cannot rez a character with RoF.

2) Also cannot hand a pet anything. When you try its as if the pet isnt there. In fact....cannot mouse target pet at all.

Rez is fixed in the latest updates from today.

I am not sure about the pet thing yet.  Though, I do know there are new options in the options menu that allow you to set click through for self, merc, and maybe other stuff.  Sounds like that is what is happening.  Will need to test that more, or get more details.

Pull more than 5 mobs. Using exact same settings as UF. No issues in uf.

I'm sure its frustrating but I'm going to need more detail to work with. Is it a specific zone, a specific subset of mobs?

I am hoping this is just some bug related to the Extended Targets being messed up.  If the wrong packets were being sent, it might have been causing the client to do something weird and lag worse and worse as you aggro'd more mobs.  Try it again once EZ has the Extended Targets fix in and let us know if you still have the same issue.  If so, I will see if I can reproduce it and figure it out.

I also fixed the guild rank message when zoning/logging in with today's updates.

I am close to having the cursor buffer fixed, but it still needs more work before I can put out the update.

Was able to duplicate the buy now button for aug slot 21.  I am still looking into it, but am guessing it is related to the membership packets.  If I can't figure it out, I bet Secrets can

I am still not clear on the runspeed issue.  Sounds like a custom spell file, and maybe you didn't update RoF2 with the EZ custom spell file yet?

Thanks for the response Trevius,
One thing I did not see you reference is 2 like aug failure.
With the old system let's assume we have 3 like augs, heroic resist stone III. If you wanted to have all like augs in an item, you would have to put 2 place holder augs in the top 2 slots then insert the hrIII. You would then remove the middle slot aug and insert the 2nd hrIII. Rinse and repeat for the last and top aug. If you did not use a place holder in the top 2 slots, the hrIII would tak the top slot and not allow the same aug to be placed in the 2nd or 3rd slot. A poster above said with the new system they could not aug same augs together.

Edit. I just confirmed, you get the error "you cannot place two duplicate gems in the same item"
I tried different variations and same error.

Yes, that sounds like an exploit from what I can tell and I see no reason to support an exploit from a previous client.  More likely, we should fix the exploit in the older clients as well!  If you are using augments as intended on the server, then the people managing the content should adjust the augs in question to work in a legit way instead of requiring an exploit/bug.  It sounds like there are already a few suggested solutions to this from the server side of things by simply making variations of these augs.

Epic is slot type 21.  The mouse hover tip on the Buy Now button says to click to open marketplace to purchase special ornamentation ability.  Shows this on default UI with MQ2 unloaded also.

That was my guess for the slot type that was causing this problem.  Slot 20 and 21 are for Ornamentation and Special Ornamentation.  Since Ornamentations are now supported in the newest source, I would recommend moving the augs that use these slot types to another slot type.  I discuss it fairly thoroughly in this thread:
http://www.eqemulator.org/forums/showthread.php?p=236202#post236202

Though, those slot types should (in theory) be fine to use for other augs without getting that buy now button.  I haven't seen that button show up after using these on my server yet, but I think I only tried slot 20, not 21 so far.  I will do some more testing on it and see if I can resolve whatever issue that is.

2) Extended Target Window doesnt seem to work, any UI, no matter what we do. Happens with or without MQ2.

3) Aforementioned run speed issues

I have fixed the Extended Target Window in the latest source updates from today. 

I am not clear on the run speed issue yet, because I am not sure what you are referring to.  Using SoE and SoW seem to increase run speed fine.  Are the speed clickies you are referring do something other than a run speed buff?  I don't think I have tried bard songs yet for run speed, so maybe that is it?

I will check out the Runspeed and Extended Targets issues.

As mentioned, augmenting does not work the same as before.  No more need for the aug pool as aug slots on items stats window have slots similar to a bag that you can just drop an aug into.  This is a pretty awesome feature and makes aug management must easier.  You do still need to have distillers in your inventory to remove augments.

Akkadius mentioned that you guys were reporting issues with making item Hotkeys.  As far as I know, the old client functionality is still available for making slot based hotkeys for clickies and such.  The new clients have a new feature that maps hotkeys to a specific item instead of a slot, and will follow that item around if you move it.  You can still create a slot based hotkey by holding ALT, then hold left click on the slot that you want to make a hotkey for.  At some point, we will get the item based hotkey stuff working, but at least the old functionality is still available in the mean-time.

I am not sure why you are getting the buy now button on items after you removed an epic aug.  What aug slot type is it?  I need  more info so I can test and figure it out.  I am guessing it is something in the item header that would cause that buy now button to show up.

I am also not sure about the reported "String Not Found (5362)" issue at character select, as I have not seen that yet.

Hunter,

There are no exploits that exist in RoF that doesn't exist in other clients as far as I am aware.  All client use the same code as far as items are concerned.  If something is possible to exploit for duping in RoF, then it should be possible for all previous clients.  The RoF client definitely does allow certain things with items that previous clients did not, but using hacking tools like MQ2 could accomplish the same thing on any other client.  We have to make sure the server won't allow duping in any scenario no matter what client it is.  Basically, we never trust what the client is telling us, we always have to rely on what the server knows about the items, they should never just come out of nowhere.

I did get a report of a duping issue on RoF (which I am not going to go into detail here just in case), but it turned out to just be a de-sync of the client and the server's inventory.  That means that to the client it appeared to be duping items, but when they zoned or relogged, all of the items were gone, and never actually existed server-side.  If the item does not exist server-side, then it should be impossible for it to be used in any way including tradeskills, click effects, sold, etc.

Of course, if there is a dupe issue possible in RoF, make sure to let me or one of the other devs know as much detail as possible on it and hopefully we can duplicate it and resolve it ASAP.  As I said, if it exists in RoF, then it should exist in all other clients as a possibility.  The main difference between clients are the packets that get sent, which ideally should not break the code that deals with items in any way.

Hunter,

Your issues with Mercs saying you don't meet the requirements means the merc merchant you tried does not have an entry in its merchant table that matches for you.  The tables for them are a bit complicated, but running all of the SQL in order should work.  I had the same issue after one of the updates and it was just because I didn't have the right info in my merc_stats table.  There has to be entries there for every client level that can use mercs.  So, if your char is level 70, you need entries for level 70 clientlevel in the merc_stats table.  If you are testing on a GM char that is above the highest clientlevel setting in the merc_stats table, you will get that error.  Mine goes up to level 85, which I think is included in the SQL updates.  Different merc merchants have different mercs available, so you might also need to try a different merchant.

Also, since your chars have pretty high stats compared to Live and the merc stats are more live-based, they probably won't be too useful for your higher end players.  But, you can adjust the stats on them in that table to whatever you want.  You can also create different merc tiers and such and make them available to whichever players you want so it is something they may need to earn access to for the good ones.

As for RoF, I am not aware of any item loss issues, or anything that would cause permanent issues for players.  The biggest problem is that you just can't add or remove augments, but you can still have them on your gear and there isn't any way to lose them as far as I know.  Having multiple items stacked on your cursor (such as summoning multiple items or getting multiple quest items returned at once) does require you to zone to get the next item placed on your cursor, but no items are lost from it.  It is just an annoyance for now until it can be resolved.  Relogging or zoning multiple times and placing the cursor item in your inventory each time will eventually clear the cursor buffer once you have done it enough times to get all items that are on the buffer.  Hopefully Uleat will have a cursor buffer fix for this soon.  The augmenting issue will take a bit longer to fix as it requires us to completely overhaul the slot system so it uses the new RoF system for slots instead of Titanium.  The cool thing about the new RoF slot system is that it will allow us to easily add some of the new RoF features like having bags that are larger than 10 slots (I tested a 100 slot bag and it worked), and also adds the option to enable the 2 new main inventory slots for a total of 10 instead of 8.  Note that when you have GM mode on, you will still see the 2 new inventory slots, but they are disabled on RoF for non-GMs so your players won't be able to lose items by using those slots that don't exist in the EQEmu source yet.  Just make sure you don't use them when you have GM mode on as well and you won't have any issues.  Same for bags > 10 slots (you shouldn't use them until the slot system revamp is done).

More importantly, if you updated to Rev2490, you will want to update again to Rev2491 ASAP as there is a pretty major issue with quiver haste in the Rev2487 to Rev2490 changes that was fixed/reverted in Rev2491.

Feel free to PM me on the EQEmu forums or on the EZ forums and I will give you my gmail address if you don't have it and I can help you with whatever you need for updating and such.  There have been a ton of changes going on lately (more than have happened in years), and a lot are pretty big changes, which explains why there are difficulties when updating.  Some of it is still a WIP (such as Mercs, RoF, and the Warning fixes KLS is working on now), and there are other things still being planned that will probably be started soon (RoF slot system, possible removal of some of the DB blob fields, and possibly switching from SVN to Git, and more).  It is always a bit of a pain to adjust to changes, but hopefully they will all be improvements in the end and will make things easier and more flexible.

Sorry for the wall of text!

I much prefer a race change over a permanent Illusion. Reason being, race change bestows bonuses (iksar AC bonus and regen bonus ** regen not important**, Ogre frontal 100% stun immunity, etc...). Illusions do not aside for the minor bonuses a few of the spells produce.

-Vessel

I saw mention of player race changes as well as non-player race changes being options.  Your suggestion for a perma race change is probably a good one for the racial bonuses as mentioned when changing to another player race.  Keep in mind that any gear that is not all/all may not function for certain class/race combos.  Also, if a player is perma race changed into a NPC race, I am pretty sure that will cause major issues, so it would probably be best for those type of race changes to be an illusion.  If you were perma changed to a NPC race, I don't think you could equip any normal player items (because all/all only encompasses player races), but I haven't really tested it personally.

[Does anyone notice a difference in looting response times depending on if they have /autosplit turned on or off?]

Thanks for the information so far.  I recently moved back to Linux on another host for my server and all reports say that loot lag is now gone.  I don't know yet if it was due to the better hard drive speeds on the host we are on now, or the difference from Windows to Linux.

Anyway, I did find something just now that could definitely cause a noticeable amount of extra unnecessary work on the server during looting.  Basically, in the Corpse::MakeLootRequestPackets(Client* client, const EQApplicationPacket* app) function, it does a client->Save() after it gives out any cash from the corpse.  The problem is that client->Save() is a very heavy database query.  Within that same function, it also uses the AddMoneyToPP() function to add money to the player profile, which also saves the character with save().  This means it is doing a very heavy query 2 times in a row when it only needs to be doing it once.  I think we can just remove the extra client->Save() from the MakeLootRequestPackets() function to make a noticeable improvement on loot performance.

Related to that find, I have another question:

Does anyone notice a difference in looting response times depending on if they have /autosplit turned on or off?

As mentioned above, the Save() function causes some pretty heavy work on the server.  For anyone with autosplit enabled, it does a Save() for each member of the group when they get money from the split, so for a full group using autosplit, that would cause 7 Saves() (including the 1 extra one it does that isn't needed).  I would guess that if you disable autosplit, on your character that is looting, the looting performance would increase considerably.   Furthermore, I would guess that Shawo has /autosplit enabled on the older characters that are taking longer to loot than the newer character (which I also guess do NOT have /autosplit enabled).  Right now, that is the only explanation I can find that would explain why certain characters would experience loot lag while others do not.

Please let me know what your testing finds.  I will keep looking and will probably update the source to remove the extra Save() that is not needed unless Secrets or someone else gets to it first.


*** EDIT ***

Well, from looking through the source, I think there are probably a few more places where Save() may be able to be removed to improve performance.  For one; in client_packet.cpp in Handle_OP_ShopPlayerSell it also uses AddMoneyToPP() which does Save() as well as another Save(1) at the end of the function.  So, if people are experiencing loot lag, they may also see lag while selling to merchants due to the same double Save() reason as looting.

Also, while looking closer at the Save() function, I noticed that  SavePetInfo() was added by Leere on the Rev2069 Commit on Nov 26 2011.
http://code.google.com/p/projecteqemu/source/detail?r=2069

If you take a look at the SavePetInfo() function, it does quite a few extra DB queries.
http://code.google.com/p/projecteqemu/source/search?q=SavePetInfo&origq=SavePetInfo&btnG=Search+Trunk

For anyone who ran a server a few years ago, they may remember the issue with lag caused by server-wide character Save()s that happened every 60 seconds by default.  With all of the Save()s in the code now, a big server could probably suffer from similar performance issues like were seen at that time, but more on a player by player basis I think depending on what they are doing.

I think to really fix this, it might require a few complex changes.  The easiest fix to improve performance would probably be to move the SavePetInfo() function out of the Save() function, but then we would need to find the best spots to put it, which would take some research and testing.  Leere may know offhand which times are essential to make sure that info is saved.  I would guess anytime you zone, when you summon a pet, when a pet dies, when a pet is given items or buffed, and when you log out might be enough, but there could be others.

Next, the best way to improve performance would be to get rid of the damn player profile blob in the database.  Then, instead of having to do a whole Save() (which saves a ton of extra crap), we could just have it save money value changes when selling something, or inventory changes, etc all separately as needed.  Though, that would require individual functions for each and also all of those functions to be distributed out in the source to the correct functions as needed.  I think this could boost overall performance considerably and allow a much higher number of players on a server before lag is seen (assuming the internet connection can handle it).

I do still think that Discovered Items can be written to not cause nearly as many DB hits as it does by just loading Discovered Items into memory so we only need to hit the database if something isn't already loaded into memory as being discovered.  But, I don't think it is the cause of the loot lag that has been seen on several servers recently.