Test Update 5/15/2023 - Patch Notes and Discussions

Thanks Guys, looks like you are hard at work. Keep up the good work!

So after some testing it seems so much better!

Major issue I've observed is when mobs are in the process of resetting, from say a monk FDing, and they happen to path through a player engaged with a different mob they will social aggro on to said player and retain the lock on the FD'd monk.

A separate issue where I was also able to create the scenario of having locked mobs on players is if a player with the lock who pulled leaves the group/raid while other players are aggro'd on. It seems to keep the lock for the puller and aggro doesn't vanish so now the group has mobs beating on them they cannot interact with.

Might need to add some safety nets of auto adding targets to the lock list if they have aggro and are getting hit, that or auto unlocking mobs if they are hitting targets not on the locked list. I'm sure this is way easier to say than do.

Also being on the lock list and then being removed if the original person leaves the group/raid seems weird. I feel like once you're on the locked list and have aggro with the monsters you shouldn't be able to be removed from it.

Either way good luck and thanks for the hard work!

Since Oakwynd is not going to be high level for a while, I created a new enchanter. Lull works the way I expect and doesn't, on its own, put the character/mob on lock. Mez worked and did not bug out the target. I have the very early animation and it's not causing any lock issues. My baby 'chanter hasn't gotten charm yet and I might not have enough time to play tonight for that. I have seen the name change to the non-lock when the memblur of mez worked. No other player near at that moment to see it it was really unlocked. I did find another person in the Mines and tried to take their target and then asked them to try to take mine with the mage pet. Both of us got the expected lock or not a valid target messages.

But.. so far, it looks decent. I'll have to get used to the mobs changing colour after they're attacked but that's not a bad thing.

I have a little time this week, I'll /testcopy from Live and poke some more.

Was happy to see this, but it's still not working :'(
Still have to copy files into default to see changes.

This still persists as well.

Don't forget you can also /testbuff the baby to 25

Thank you for the reminder.
If the copies aren't there today, I will do that with the test baby. I have characters in several level ranges and know exactly how the 'work' on Live and it should be the same aside from the specifics of locking.

Something else I forgot to note that's something to get used to but I think is a great change. When you have killed something that was locked to you, the corpse's name tag remains the bright green. If the corpse was killed by someone else's lock, it remains grey. Super easy to spot what was locked to you when you killed it. I think that's a great knock-on effect.

Did you also use /ui reloadhtml after you made changes?

yes. I found out on discord that the ui changes said in this update didn't make it because it was "part of the build process that was missed." It should be on live tommorow, then on test when they do the update to match live.

EDIT: aaannnd still not working on live.

Literally nothing more should be done on the the UI system revamp until the Converter works 100% of the time on all possible custom versions of the UIs. eqinterface.com has tons of custom UIs that you can use to test. This never should have went to live until the converter worked without a hitch and without having to move every stupid file from default into the custom folder.

At the absolute minimum the 'converter' should be able to convert the 'default' UI with zero errors, warnings or issues!

And the fact that it can't seems like a punchline for a joke.

You mean the couple of windows that they have converted so far? Most of the windows will error out because it isn't possible to covert them at this time.

Yes, at minimum it should be able to properly convert the four windows they have ported/converted so far. It cannot.

If it could, we'd actually be able to convert most of the windows of the UI error-free because of which four windows they chose to start with - the bare bones for most element types is there. The converter is having major issues with the syntax changes though, which is causing many of the errors. Whoever wrote the 'conversion rules' for it did a terrible job.

Obviously the engine wouldn't read anything other than those four files though until the official port for other windows is completed.

The converter should have a list of which windows are convertable and only try to convert those.

The UI scale only works on windows that have been converted. At this time, that is the Inventory, Story, Quantity, and Window Selector windows.

Per EQ Dev post
https://forums.daybreakgames.com/eq/index.php?threads/ui-scale-is-invalid.290928/#post-4225798

That is another BS excuse that makes absolutely no sense. There is no reason at all that the converter should not be 100% capable of converting the default XML files from the default SUITE UI to match exactly the default Gameface UI files. The converter in no way needs to be able to convert all windows. That is not even how it is designed to work. In the converter you are allowed to to select specific windows and convert just them.

Sure it would be nice but what is the rush to partially convert a custom UI and get issues such as the inventory window always being on top that people are complaining about? Personally I don't want to use a mixed UI and don't want my custom UI converted until everything is done.