What do I need to do as a server admin?

Where should the whitelist be stored?

• I want to host it here: You will receive your URL and the GUI-Ini-Row in the Output-Dialog.
• Dedicated server: You can store the whitelist in the file system, where all maps can access it.
• Webspace: You can store the whitelist there.
• Github: Use the RAW display URL. Please don’t ask how exactly this works – if you’re using Github, you should already know.

Recommendation: I recommend the last two options (webspace or Github), as they are usually faster to access than your hopefully well-secured root server. At Nitrado, you can test the file system option (not yet tested – feedback? 😉), but you have to do this for each server in the cluster. Using the web option, one file is enough for maintenance, which means less effort. Additionally, with this option, you can delegate the management of custom cosmetics to a user without needing to grant admin access to the game server/Nitrado!

What do I need to configure on the server?

There is a parameter called "DoCustomCosmeticValidation" that needs to be removed.

• In the GameUserSettings.ini under [ServerSettings] – if this parameter exists, delete it!
• If you’re using a server manager, this option might be found in the start parameters. In the ASADedicatedManager, for example, it’s under "Command Line" at the bottom – make sure it’s unchecked.
• I couldn’t find this option on Nitrado. Use the configuration instead.

Now, we need to tell the server where the whitelist is located. By default, the official Wildcard whitelist is used, but we want to override that. Open the GameUserSettings.ini and under [ServerSettings] add the following:

• For webspace usage:

  CosmeticWhitelistOverride="https://webserver.tld/name_of_file.txt"

• For file system usage:

  CosmeticWhitelistOverride="c:\path_to_whitelist.txt"

That’s the configuration part!

---

How to use the generator?

Option A: You already have a whitelist on your server

1. Go to the WL-Generator.
2. Click on "Import Whitelist".
3. Paste your whitelist into the field below.
4. Click on "Import".
5. Select additional skins (first column), delete some, etc. The search window accepts project IDs (which you can find on Curseforge) or skin names. I recommend enabling dynamic download and NonDataOnly for all, then customizing them as needed.
6. Click on "Save Whitelist" – this is important!
7. Click on "Output" – the whitelist will be output in the official format. You can now use it via a website or save it as a file on the file system.
8. Make sure to note down the Whitelist-Guest-ID! With this, you can retrieve and continue editing your whitelist next time. Guest whitelists are deleted after 14 days of inactivity.

Option B: You don’t have a whitelist yet?

1. Go to the WL-Generator.
2. Select your desired skins (first column). The search window accepts project IDs or skin names. I recommend enabling dynamic download and NonDataOnly for all, then customizing them as needed.
3. Click on "Save Whitelist" – this is important!
4. Click on "Output" – the whitelist will be output in the official format. You can now use it via a website or save it as a file on the file system.
5. Make sure to note down the Whitelist-Guest-ID! With this, you can retrieve and continue editing your whitelist next time. Guest whitelists are deleted after 14 days of inactivity.

---

How do custom cosmetics work?

Custom cosmetics (skins) are client-based. However, a server-side whitelist is required to use skins on the server. To prevent outdated skins from being used, Wildcard introduced a hash system, but unfortunately, it was a "company secret" how these hashes were created. With the parameter DoCustomCosmeticValidation=True, hashes had to be included in the whitelist. For private whitelists, this was nearly impossible (unless you installed them all). Therefore, I removed this parameter as the effort was not feasible!

Since the Aberration DLC, the hash is no longer needed. Why Wildcard removed it is unclear. Whether this affects DoCustomCosmeticValidation, I don’t know. Now there’s nothing left to validate – does the parameter still make sense? I haven’t tested it.

Whitelist parameters

The whitelist contains, in addition to the mod’s project ID, two more parameters:

• Enable DynamicDownload (0/1): This defines whether the skin can be downloaded dynamically. If you see a skinned object but don’t have the skin, it will be downloaded (view-only). If you want to use the skin yourself, you must manually download it in ARK’s mod list. I use 0 for testing and switch to 1 if everything works. Skins that aren’t good are removed entirely.
• Allow non-dataonly blueprints (0/1): This parameter allows skins with script components, such as Wildcard’s Tic-Tac-Toe table. However, this option doesn’t seem to be active, as all entries in the official list are set to 1, and the table works even with 0. If anyone knows more, feel free to enlighten me!

What does the server do with the whitelist?

Every 30 minutes, the server queries the whitelist to retrieve the allowed IDs and their parameters. The server doesn’t need to be restarted for this. If a client has a skin that is not on the whitelist, it cannot be used. If it’s on the list, it works as expected.