Dayz Local Mod Loading on a Dedicated Server

[Phalanxer 0]

Hey everyone, I run my own dedicated server and launch using the DayzServer executable with arguments. I used to use Omega Manager, but it's a lot handier to boot the server when the server hardware powers on with the .exe and task scheduler. I've figured out how to do everything through the .exe + launch parameters except one thing, loading local mods. In Omega Manager config this was easy, I just set the workshop ID to zero in the config and voila, worked like a charm. However I haven't been able to figure out how to load a local non-workshop mod using the .exe + launch parameters, any ideas?

Edited December 2 by Phalanxer

[Sid Debian 134]

11 hours ago, Phalanxer said:

Hey everyone, I run my own dedicated server and launch using the DayzServer executable with arguments. I used to use Omega Manager, but it's a lot handier to boot the server when the server hardware powers on with the .exe and task scheduler. I've figured out how to do everything through the .exe + launch parameters except one thing, loading local mods. In Omega Manager config this was easy, I just set the workshop ID to zero in the config and voila, worked like a charm. However I haven't been able to figure out how to load a local non-workshop mod using the .exe + launch parameters, any ideas?

Depends on type of mod you have 2 possible cases.

Case 1: "-mod=@My Awesome Mod1;@My Awesome Mod...;@My Awesome ModX"

Case 2: "-servermod=@My Awesome Mod1;@My Awesome Mod...;@My Awesome ModX"

Each case has 2 sub-cases:

Case A: "-mod=@My Awesome Mod1" <- mod shall be stored inside DayZ server folder aka same folder like DayZServer_x64.exe

Case B: "-mod=C:\...\@My Awesome Mod1" <- any location on the drives of the system.

So based on both approaches and possible combinations of it you can load mods to your server.

However if your mod(s) using configurations only (no GUI tasks) it might be loaded as server-side mod and that will not required the client has that mod installed.

Other case if your mod using GUI (idk crafting recipes, strings overrides and other stuff) you shall load mod as decency in -mod section (and server will requred the connecting user to have that mod).

Have fun. 

[Phalanxer 0]

Thanks for the advice. Basically what happened a while ago was a workshop mod got pulled from the workshop temporarily while the mod owner updated some things for 1.26. Because the mod didn't exist on the workshop anymore the sever started to report "Mod xxx has a workshop ID of 0". In Omega manager I was able to circumvent this by setting the workshop ID to 0 in the configuration so I could continue to use the mod locally temporarily until the updated version came out. In case this ever happens again, i'd like to be able to stop the sever checking the workshop for the mod if required. I'm not sure how to replicate what setting the workshop ID to zero did in the Omega Manager config. I had a suspicion it possibly altered the meta.cpp file workshop ID, but I've not had any success there.

[Sid Debian 134]

59 minutes ago, Phalanxer said:

Thanks for the advice. Basically what happened a while ago was a workshop mod got pulled from the workshop temporarily while the mod owner updated some things for 1.26. Because the mod didn't exist on the workshop anymore the sever started to report "Mod xxx has a workshop ID of 0". In Omega manager I was able to circumvent this by setting the workshop ID to 0 in the configuration so I could continue to use the mod locally temporarily until the updated version came out. In case this ever happens again, i'd like to be able to stop the sever checking the workshop for the mod if required. I'm not sure how to replicate what setting the workshop ID to zero did in the Omega Manager config. I had a suspicion it possibly altered the meta.cpp file workshop ID, but I've not had any success there.

Dig and find or don't dig and suffer.

Now the reality that's hidden because you can not use simple notepad.

Go to addon folder and you'll find 2 files:

meta.cpp and mod.cpp

Meta.cpp - steam file that contains basic information from Steam about Workshop item such as:

1. Protocol -> idk what's that

2. PublishedID -> Workshop ID of addon

3. Name -> Workshop name of addon

4. Timestamp -> Timestamp of last addon update.

Mod.cpp - file for DayZ game and server, contains next fields:

1. Name -> name of addon ingame menu & default DZ Launcher.

2. Picture & logo -> icons for ingame menu (just in case if it's not defined in main addon file

3. Logosmall -> ...

4. Logoover -> ...

5. Tooltip -> for hinds in main menu of game

6. Overview -> short info about addon, used in main menu.

7. Action -> URL for web browser.

8. Author -> Name of creator 

9. AuthorID -> SteamID64 of creator/owner of addon

10. Version -> useless string about whole version of addon.

Edited December 3 by Sid Debian

[Phalanxer 0]

I have dug quite a lot, that's why I've come to the forum to ask for help! I can see Omega Manager doesn't change the meta.cpp file. Possibly this is a feature of Omega Manager that can't be replicated using a standard launcher and is internal to their architecture. Since Omega is a closed source (As far as I can tell) I can't see what it modifies with the following file_id parameter, and I was hoping someone in the community might know.

"mods": [
          {
               "directory": "@CF", 
               "disable_updates": false, 
               "disabled": false, 
               "file_id": 0, 
               "server_side": false
          }, 
          {
               "directory": "@Community-Online-Tools", 
               "disable_updates": false, 
               "disabled": false, 
               "file_id": 1564026768, 
               "server_side": false
          }

 

[Sid Debian 134]

17 minutes ago, Phalanxer said:

I have dug quite a lot, that's why I've come to the forum to ask for help! I can see Omega Manager doesn't change the meta.cpp file. Possibly this is a feature of Omega Manager that can't be replicated using a standard launcher and is internal to their architecture. Since Omega is a closed source (As far as I can tell) I can't see what it modifies with the following file_id parameter, and I was hoping someone in the community might know.

"mods": [
          {
               "directory": "@CF", 
               "disable_updates": false, 
               "disabled": false, 
               "file_id": 0, 
               "server_side": false
          }, 
          {
               "directory": "@Community-Online-Tools", 
               "disable_updates": false, 
               "disabled": false, 
               "file_id": 1564026768, 
               "server_side": false
          }

 

Again it's steam workshop id. If you have running steam client omega manager established connection to the steam client and request downloading of mod throw steam client library. So yeah that app shouldn't update the meta.cpp, coz it will be auto updated by steam itself. Waste some of your time and find how Steam performing update of mods and etc. you'll find many interesting information.  Ut that idea shall visit your head quite long time ago.