Is this character and wardrobe compatible with vrpex?
Is it somehow possible to make people on their first spawn invisible ? itās so hard to make a nice character if everyone is standing inside each otherā¦
Can anyone help me how to change the height to metric system instead of imperial?
Do i have to modify esx_identity files too?
Ok fixed
Go to scripts.js and change:
Around line 1063: let feet = Math.floor(inches / 12); to let feet = Math.floor(inches);
Around line 1070: valueCenter.text(feet + āā - ā + inchesLeft + ā"ā); to valueCenter.text(feet + ācmā);
Also open config.lua and change Min and Max Height around line 111,112 to the numbers u want at cm
Also u dont need to edit anything else at esx_identity
3 Likes
Someone help how i can add vest ? to menu
The only way i managed to make the job outfit work is NOT to start esx_skin and skinchanger
will see if it brakes other scripts
1 Like
Good day, first of all, I would like to thank the author for implementing the resource, since there are very few such things for ESX, in particular, and the standard editor remains the best, no matter how outdated it may be.
I installed your resource without any problems, following the instructions.
I noticed that you used the same table and field in the database as the standard editor.
I started testing and was upset that all the objects of things are written sequentially. For example, the same pants will move across all existing colors. It would be more convenient to select an Item and then lower its color, since this is implemented in the standard ESX editor.
I do not know why you decided not to follow the example of the standard editor and did not take it as a basis, because this way your resource would become as compatible as possible with any resources related to things. Obviously, there were reasons for this.
But itās frustrating. p. s. I would look at a person who will be looking for his favorite business, whose position is in the list of 1500.)))
After the tests, I decided to read the forum, and I already realized that you have moved away from the number system, apparently, for numbering things.
Perhaps someone will be able to implement this instead of you, maybe you are looking in this direction yourself, but if this resource was maximally adapted to interact with other resources, and the approach to storing and getting the meaning of things was rethought, then this would definitely be the release of the year.
Do not judge strictly, I am not yet a master in the development of scripts for Fivem, perhaps I do not fully understand some things.
Perhaps you have Discrord for the convenience of tracking news about your developments?
I hope you will be able to complete it.
2 Likes
Hi, i love this script but i have a little bug.
When iām hurt and iām going to the clothes shop and i cancel, my life gone full. Someone have the same problem ?
I havenāt had much time to devote to this project lately and didnāt check out the forums in some time, but I liked your post and felt like you deserve some honest answers.
The reason I chose to make this for ESX is that I had no experience at all with FiveM when I started this project and ESX seemed easier to learn than the āvanillaā FiveM. This is also the reason why I decided to use the same database fields and names (even though some of them were very misleading).
After working enough on this, I realized that there is a lot of problems with ESX and Iām not at all surprised why the ESX team decided to abandon version 1.x entirely and rewrite their project from scratch.
Biggest problem I see is how character/player data is stored and how multiple characters per player is not supported natively.
All the multicharacter resources for ESX are ugly hacks that modify database on the fly, but they clearly expose why it could not have been done better and still be compatible. There simply is a fatal flaw in base ESX design. This is why I decided to not support any form of multicharacter at all.
If this were to be fixed, there has to be separate āper playerā and āper characterā data and every character has to have own, unique identifier in the database.
If I were to start a project like this with the experience I have now, I would absolutely not choose ESX, instead I would take the standalone approach and design a system with multiple characters per player and player login clearly separated from actual character spawn in the world.
The reason for this is that I intended to fix all the problems with the currently available clothing systems, main ones being:
- Players having to manually choose arms to match their clothes selection
- Completely uncontrolled possility to create mismatched, clipping or even half-invisible characters.
- Unintuitive and difficult to remember raw numbers being used instead of names that Rockstar gave to the clothing sets (in GTA Online)
This proved to be a very time consuming task, but I wanted to release the resource with all the other character customization features, so I decided to put an experimental clothing system in āfor nowā.
Itās almost 3/4 year of this āfor nowā, but if I were to wait until itās perfect, this still would be far from being released and seen by anyone.
Turns out that creating a really good clothing system that fixes all the above problems requires either reverse-engineering Rockstarās approach or creating custom clothing database tables (that define ālegalā combinations) with a custom piece matching system that uses them.
Iāve posted a topic on the forums asking for help with the first approach, but got no responses, so I decided to go with the second.
I wasnāt really aiming at ārealease of the yearā or antyhing like that. I just noticed that the quality of most publicly available and free FiveM resources (especially for character creation) is overall very low, so I wanted to try to identify the problems with them, make something I think is better and see how people react when I release it.
Compatibility with those other resources was never even the goal, I just wanted to minimize conflicts where I could.
I am very positively surprised with how much traction this topic has gained. Iāve received and responded to tons of private messages and I lost track of all the explanations Iāve given and to who. I didnāt expect anything close to this.
3 Likes
i understand you. Now everything has become much clearer to me.
thanks for your reply. About esx 1.* I would rather agree with you, because I face a number of problems when building a project on it.
I havenāt decided yet to build on the reborn version.
Solved it! needs some rework though and Iām trying to build an arms dictionary to automatically place the correct arms
People have said this before but sometimes the ESX.RegisterServerCallback('cui_character:getIdentity) doesnāt seem to work. I tried everything followed the instructions. Could you take a look at this?
Someoneās already attempted creating something like that, check out this file. I think it will help you.
Doesnāt work how? Does it retrieve empty or wrong data set or thereās an actual error displayed in the console?
1 Like
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,
`accounts` LONGTEXT NULL DEFAULT NULL,
`group` VARCHAR(50) NULL DEFAULT 'user',
`inventory` LONGTEXT NULL DEFAULT NULL,
`job` VARCHAR(20) NULL DEFAULT 'unemployed',
`job_grade` INT NULL DEFAULT 0,
`loadout` LONGTEXT NULL DEFAULT NULL,
`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.
or
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