[RELEASE] CleanUI (cui) character

Hello, did you like try to look at esx_multicharacter from liden… it’s like only one usable multicharacter, what you can get…
plus people start using legacy… i mean everyone start using it…
I think there is no way saying “every multichars is ugly”…

Btw waiting for cui_multichar…

I don’t think you understood what I meant when I said that.

It has nothing to do with how the ui looks. It’s about what operations the code performs on the data in the database.

I looked briefly into esx_multicharacter code, check out this file around line 14.

When a character is created, an identifier is dynamically built out of player identifier and some prefix, while databases are fully capable of generating unique identifiers on their own.

The fact that this modification is required is a sign of poorly designed underlying data structure. THIS is what I call ugly and it’s none of the muticharacter resource creators fault that they are forced to do this.

This makes trivial operations more complicated, for example in order to find all characters of a particular player you have to start dissecting this compound identifier to look for a common part instead of just executing a simple SELECT statement.

Just look at how ESX’s users table is defined:

CREATE TABLE `users` (
	`identifier` VARCHAR(60) NOT NULL,
	`group` VARCHAR(50) NULL DEFAULT 'user',
	`job` VARCHAR(20) NULL DEFAULT 'unemployed',
	`job_grade` INT NULL DEFAULT 0,
	`position` VARCHAR(255) NULL DEFAULT '{"x":-269.4,"y":-955.3,"z":31.2,"heading":205.8}',

	PRIMARY KEY (`identifier`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Heart of the problem: The identifier is defined per player and the other fields in the table that this identifier is associated with should be defined per character.

This is what I mean when I say that ESX was not designed to support multicharacter. It’s not possible to implement multiple characters per player in ESX without using an ugly hack.

EDIT: changed a bad example to a better one.

Maybe we should start making a new framework based on multi-character design.
Like having an account table with identifier then a character table.

Was responding to the first example you gave, which was a fairly bad example since it just ensures all separate identifier fields are the correct size (since everybody defines their own).

In the case of the new example, I only did that for supports sake (if somebody swaps from another multicharacter that stores in a similar format, or swapped away from my own).

My own personal build of ESX and Multicharacter stores differently

Really the worse example is the multiple queries when deleting a character, which requires setting up foreign keys to resolve… most people can’t run an SQL file so…

1 Like

This is exactly my point. In order to make this feature possible, one of these two things has to be done:

A. The underlying data table has to be redefined, which requires changes to all other resources in order for them to remain compatible.


B. Some sort of compatibility layer has to be written that modifies the data on the fly or handles insertion of new data based on analysis of already present values.

In my opinion the A is clean and the B is ugly.

I personally think that the effort required to keep all the old code compatible is not worth it and it would be more expedient (and definitely more future-proof) to fix the core issue with the main framework and update the old resources to be compatible with a new format.

ESX Legacy is never going to have the core issues resolved; the team is working on Reborn (aka ESX 2). There’s plenty of things I would have liked to put into Legacy but compatibility with 1.2 is more important.

As it is most people are still using 1.1 with essentialmode.

I don’t think people will use the Reborn any time soon.
It is a complete new approach. Any script will have to be remade from scratch.
(Can be good for real devs, but for those who just plug&play will have no choice)

I got Reborn running a couple of months ago. I think it’s amazing from the beginning but it’s a long way from being even remotely viable for a live server

1 Like

I know of a server that are on v1-final and in the process of downgrading to v1.1 because apparently “big servers running it don’t have the same level of performance issues”. Massive mistake in my mind. Out server with 45 players was struggling like crazy and crashing every few hours until we put the GetExtendedPlayers calls in for society. We were still having lots of issues, but after merging es_extended into our code base (I couln’t drop in due to custom stuff we’ve added as well as esx_billing, esx_datastore and esx_society our issues have been completely resolved. We up our player max to 128 and had a massive event on the weekend. THe server survived through texture stuff ups from all the vehicles and players and mumble going all naff and we’ve gone to 12 hours restarts. The only hitching we get now is from the anti cheat we use which is apparently discord API related. I can only imagine how much better it will be once all the other addons are merged and we update every other 3rd party resource following those principals. Seriously great work Linden.


Even once we get the inventory out of the way and start working on all the modules that rely on it, it’s got a while to go before it can be called “ready to use”; even then that will only be for actual developers.

Full features are a long way off.

One thing I’m keen to know is, with esx_property using esx_addon_inventory and esx_addonaccount resources are property inventories shared amongst all the characters a player has?

It says there is no such export as getIdentity :man_shrugging:

What are you talking about? I’m talking of completly ditching the arrows and use a drop down fast selection combobox. I’ve done it and it’s working with arms. The only thing I still couldn’t figure it out was how to set the arms on the selection on entering into the shop.

same. followed the instructions per the config to integrate identity and I get callback does not exist for callback cui_character:getIdentity.

How did you get the addon clothes to work? If that is what you did. I am currently trying to play with the arms to try and get them to show up but still kinda new to this so all I got was it to show on the ui

Hi guys, I’ve been trying to add a function that lets you change the clothes colors, is there a way to do this? if so, can y’all please send me the guide or function to add it?

That’s not at all what you said. You said you were “trying to build an arms dictionary” and what I linked is exactly that - main top (coponent 11) drawable numbers assigned to valid arm (component 3) value groups.

What resource is this error listed in?
That’s very strange, it means you are trying to use getIdentity in some other resource.
If that’s really what you want to do, you should open cui_character fxmanifest.lua and add ‘getIdentity’ to exports.

Only way I can think of for this to happen is that if you’ve made a mistake like didn’t set EnableESXIdentityIntegration to true or did set StandAlone to true while using esx.

I think its none of the two, im pretty sure this isn’t compatible with the new esx_legacy that was released like 10 days ago (GitHub - esx-framework/esx-legacy: Consolidated esx-legacy files into one repo for easy download since we will not support it)

I’ve followed the instructions as well, and i can’t seem to get it to work, i’ll leave you the errors that i get on the console

neither case is true. enableesx is true, standalone is false, and the changes were made /shrug.

question: could this error arise if the character already exists? I wonder if I made a new character if it’d make a difference.