Supports 10+ Characters: The thing that limits the number of characters is the fact that they cannot all fit on your screen. There is no hard limit of characters in the script itself.
Standard Multi Character Method: The standard method works similar to esx_kashacters and this is enabled by default, meaning the switch from esx_kashacters to cd_multicharacter is extremely simple, essentially a drag and drop with minor modifications required. If this is your first time using a multiple-character script it’s also very easy to set up.
Advanced Multi Character Method: We also have an advanced method that is completely optional but far more optimized. This method modifies your xPlayer.identifier based on your chosen characters id. So when you choose to play on your second character, your xPlayer.identifier will return “Char2:110000105bdca75”. This is the opposite of how the standard method works. With the standard method your xPlayer.identifier will always stay the same eg., “steam:110000105bdca75” but all of your identifiers in the database will be changed (by executing a huge amount of SQL queries). But with the advanced method, your xPlayer.identifier is changed every time based on which character you have chosen, and all of your identifiers in the database are never changed (reducing the number of SQL queries, which means better optimization).
Individual Max Character Limit: Staff can add/remove character slots to players using a chat command. This can be used on online or offline players. A few use cases for this could be; rewarding good roleplayers, perks for staff, perks for donators, etc. There is also a command to reset everyone’s max character limit to an amount you choose.
Database Cleaner: When using multi-character resources on esx, a lot of unnecessary rows are added in the database, with this small addition, we can remove a lot of rows from your database that is unnecessary and just take up space.
Delete Characters: You can choose whether players can delete their characters.
Ped Model Compatibility: When using esx_skin and a modified version of skinchanger, your saved ped models will be visible during character selection as seen here.
Supports ANY Skin Resource:
Default: By default we have added support for cui_character, along with the existing esx_skin and betrayed_clothing.
Add your own: You can now make any skin resource compatible if you have the knowledge to do so, as the full code which handles the peds skin is now open to edit.
All of these options can be customized (enabled or disabled) based on your preference and the requirements of your server.
Documentation
We recommend that anyone interested in this resource checks out our new Documentation Website. This documentation includes:
Step by step installation guide
Common issues & solutions
Code snippets
Error codes
Full preview of the Configs, Locales/Translations & SQL
Troubleshooting guide
Dependencies and Compatibility
Framework Dependencies
Framework
Compatibility
Notes
ESX
drag-and-drop compatible
Supports esx 1.1, 1.2, 1.final, extendedmode and all legacy versions.
This script is a beauty!!! I had so many problems with Kashacters and although I eventually got it to work, I appreciate this script way more!! It’s simply beautiful. Pretty much plug and play. Switching over from Kashacters was no problem at all. Devs are super nice and helped me out any time I needed it. I also have their PlayerHud and it looks real slick too. Everything they release is awesome!! Can’t wait to get the dispatch and garage
I try to be an honest person and never lie. I just say things how I see and feel them. We were having about 2 weeks of issues after connecting. Firstly players still could see the loading screen of the script and, when it got fixed, the NUI was not showing for players with the error message “You are not allowed to run the script”. This issue got fixed after one-two weeks. Unfortunately, we lost around 30 on average players at about 8 PM and this was sad for us. But happily, when it got fixed by Codesign, we got around 50 news players and we were on numbers of players we wanted to. The other thing to add is that we were worried about buying it, because we had a bad experience with kashacters, with the duplicity of inventory, spawning dead, etc. … but with cd_multicharacter, nothing. Everything works well. The NUI is simple, there are no unnecessary elements, fresh, cool, nice design. There are literary no bugs and no errors. The one thing and I am looking forward to (it should be done in the next update) is displayed job name, which can be replaced by job label.
Resource looks neat and its cool you added additional documentation.
In regards to dependencies/compatibility, your links are a bit incorrect and misleading
v1 final and 1.2 are the same so there’s no need to link them as separate I’ve never understood why it was said to be the final commit as this happened after the es ditch with issues that have since been fixed. Would of made sense if it was said to be final 1.1 commit. Regardless, the fxmanifest didn’t change versions.
Regardless, the resource should still be compatible with the esx versions linked below (i noticed you had outdated links. These are the same links within the ESX Discord that are pinned.):
The only major difference between 1.1 limit and weight is the way items are handled which would essentially make no difference. 1.2/FinalV1 has the es ditch, ditch support for steam, encoded inventory, accounts change and the removal of core fivem resources. This would essentially be the only variant for you to worry about.
Hey man thanks for the kind words, tbh it was confusing to us at the start too and still kinda is now with all these different esx versions, but we learnt through trial and error that 1.2 and 1.final are same in many ways and also different in some ways, in the case of the multi character they are different in a way that can break the script if is the wrong version is chosen.
1.2 uses the user_accounts database table to store money/bank and uses this playerjoined trigger event TriggerServerEvent('esx:playerJoined')
1.final uses users database table to store the money/bank in the accounts column in json format and uses this playerjoined trigger event TriggerServerEvent('esx:onPlayerJoined')
And as you can see in the documentation the modifications required for each version is sightly different too
The 1.2 you linked here was just a bad commit name and is actually in a broken state . Its not recommended to be used what so ever. The ESX docs recommend the legacy branch, the fxmanifest still refers to it as 1.2, but it’s essentially the latest commits.
It’s the same with 1.1 tree as that one is from 2018. Where there was still a year of commits following that tag to 1.1 as it didn’t become 1.2 until February of 2020 :p.
Essentially the one you linked is the commit after they did the json encoded inventory and half assed ditched ES. It was changed to 1.2, in the manifest, on that commit. No one actually uses that one though as everyone is directed to the legacy branch on the GitHub repository as it contains the latest 1.2 code.
I’m aware the tags refer to 1.2 and v1 final as different ESX, they’re still the same if you look at the fxmanifest for both of them though. Just v1Final is most updated. I’ll see if I can contact the current ESX maintainer and see if something can be done to improve those tags as this seems to be causing some confusions even with other resources too. I realized why people thought they were different versions now and it caused numerous issues when providing support for them in the ESX Discord.
After reading the reviews all I see is that it is really easy to set up and is very optimized. Yall really do know how to make some scripts that are very well optimized.