Jump to content

Is there any way to test mods on a dedicated server without having to reupload them to the workshop over and over?


Recommended Posts

And over and over and over and over and over?

 

modoverrides.lua doesn't seem to enable mods (at least not local mods).

 

ForceEnableMod() loads local mods, but doesn't seem to do **** without ServerModSetup().

 

So dedicated servers require ServerModSetup().

 

ServerModSetup() requires a workshop id.

 

So bug fixes require reuploading the mod to the Steam Workshop over and over and over and over and over and over.

 

I can't see any way to bug-hunt a mod client-side without uploading it to the workshop.

 

I can't even imagine why it's like that. Does Klei get a nickel for every workshop upload or something?

 

I just want one less hoop to jump through so I can port a mod so everybody will shut up and get off my back about it.

Link to comment
Share on other sites

13 hours ago, mouse said:

modoverrides.lua doesn't seem to enable mods (at least not local mods).

I don't have any access to my computer right now. But i'm pretty sure it's possible to use modoverride to enable local mod.

At least it's the case when you use steamcmd for the dedicated server. I copy my local mod in the folder for mod in steamcmd and it works.

Of course it doesn't work for "all client mod" for other people if they try to join the server.

 

I don't know however if some options could work, like some of the commands.

I hope it's clear. I will have access to my computer soon, so quote me in two days if i don't anser and i'll try to give more information and screenshots.

 

Link to comment
Share on other sites

17 hours ago, Lumina said:

Of course it doesn't work for "all client mod" for other people if they try to join the server.

Well that explains why modoverrides.lua wasn't working then, even when the mod was in both "mods" directories.

Link to comment
Share on other sites

  • Developer

May i ask why you need to test it on a dedicated server?
for all intents and purposes, you have two enviroments:
a single world server(ie forest only) hosted by a player(the easiest differentiation is no local/remote cmd options when you hit ~)
a multi world server(forest and caves) hosted by a player/dedicated server, there is zero differentiation between a "full dedicated server" and a player hosted multi world server. 
 

Link to comment
Share on other sites

13 hours ago, mouse said:

Well that explains why modoverrides.lua wasn't working then, even when the mod was in both "mods" directories.

If you try to join your server, even with local mod "all client require mod", it will work. It works for me without trouble.

But if someone else try to join i'm not sure it will work. They probably need the mod, but since the mod isn't in the workshop, you need to provide them the mod manually and it will probably create a lot of trouble if the mod isn't up to date. So if you plan to test with other people, a mod on the workshop is probably a cleaner way to proceed.

 

If you want to do quick tests yourself, a dedicated server is an option (but yeah, a server with caves is probably a lot less trouble) and should work fine even with mods that aren't on the workshop.

Are you sure you gave the right name for the modoverride.lua file ? It should be the name of the folder of your mod.

1 hour ago, Zarklord said:

May i ask why you need to test it on a dedicated server?

For me it's more convenient because i can easily set up a configuration that will stay. Presets, mods, mode of the server, all of this will stay, and i find it very convenient. Half of the time when i want to do a quick test i forget one element or another when i create the server (usually, caves).

Also, i usually use the different saves of the game for quick tests or games with friends, so i find it better to have the dedicated server somewhere else.

And finally, it took me so long to create a dedicated server, back in time when caves didn't exist and it was the only way to test my own mod as a client. I did not do this for nothing.

Link to comment
Share on other sites

3 hours ago, Zarklord said:

May i ask why you need to test it on a dedicated server?

Because I need to test client side functionality as some bugs only appear for clients(and not servers/hosts), Steam won't let you run more than one instance at a time, dedicated servers don't use up as many system resources as two instances of a game, and the terminal prints outputs in real time, so it's easier to see exactly when something happens server side.

 

Me: This thing isn't working.

Them: Yes it is.

Me: No, it's really not. I tried everything. I spent 5 hours trying to make it work, and everything I do makes no difference at all. It simply isn't working for me.

Them: Yes it is.

This is why I don't like asking for help.
 

 

2 hours ago, Lumina said:

If you try to join your server, even with local mod "all client require mod", it will work. It works for me without trouble.

I don't know what to tell you. It's not working for me. These are fresh installs for DST and the DST dedicated server. I even deleted all of the settings so new settings would be generated when I restarted DST. So all of the settings and config files were auto generated. Even modoverrides.lua itself was auto generated. So I don't know what else it could be. modoverrides.lua is supposed to be in ../DoNotStarveTogether/Cluster_[number]/Master/ right?

 

Edited by mouse
Link to comment
Share on other sites

2 minutes ago, mouse said:

modoverrides.lua is supposed to be in ../DoNotStarveTogether/Cluster_[number]/Master/ right?

Is " Cluster_[number]" the name of your dedicated server ? If yes, yes, it should works, but if you have Caves you need this file in the Caves folder too.

I will try to give you examples tomorrow with screenshots if i could.

Link to comment
Share on other sites

  • Developer
On 8/1/2018 at 5:34 PM, mouse said:

Because I need to test client side functionality as some bugs only appear for clients(and not servers/hosts), Steam won't let you run more than one instance at a time, dedicated servers don't use up as many system resources as two instances of a game, and the terminal prints outputs in real time, so it's easier to see exactly when something happens server side.

when you host a server with forest+caves, YOU ARE A CLIENT.
the difference between a dedicated server, and a forest+caves player hosted server, is that a variable is changed so that the dedicated server icon appears in a server browser, and causing the server to close when the host leaves. nothing else has changed.

Link to comment
Share on other sites

51 minutes ago, Zarklord said:

when you host a server with forest+caves, YOU ARE A CLIENT.
the difference between a dedicated server, and a forest+caves player hosted server, is that a variable is changed so that the dedicated server icon appears in a server browser, and causing the server to close when the host leaves. nothing else has changed.

Then why is it when all of the fatal bugs have been fixed for hosting, I get an entirely new set of fatal bugs to fix when I join my own dedicated server (with the mod enabled) as a client (with the mod enabled)? They're obviously not the same.

 

All of the variables and tables have a "clean" version and a "dirty" version. "Clean" is when they're server side, "dirty" is when they're client. If the host is handling all of these variables properly, but clients aren't, clients will crash. Hence different results in both situations. That's why clients can crash constantly, while the mod is running flawlessly server side. That's why it's possible for items to exist for clients but not hosts, and vice versa. So dedicated servers are mandatory for client side testing if you intend to take your mod seriously, and you don't have your own staff/volunteers to host/join for you.

 

EDIT: For clarity, I should point out a lot of variables simply don't exist client side. It's not purely a "clean" and "dirty" version of each. Some simply don't exist, and if the client attempts to reference those variables, a crash will occur. That's just one example of why it needs to be tested for clients, too.

Edited by mouse
Link to comment
Share on other sites

1 hour ago, mouse said:

Then why is it when all of the fatal bugs have been fixed for hosting, I get an entirely new set of fatal bugs to fix when I join my own dedicated server (with the mod enabled) as a client (with the mod enabled)? They're obviously not the same.

 

Client could have their own bugs, because you didn't put something server side when it should or stuff like this, but you SHOULD be client side when you host a world with surface+caves, with the client side related bugs.

Sorry i'm a little busy at the moment, i'll try to provide information if you still have the problem and still need to solve it, but don't hesitate to answer the question above for more details.

Link to comment
Share on other sites

To test code, I always do it with caves enabled. The game makes a dedicated instance and then connects me to it.

This way the game loads server side mods on the server instance, client side mods on the client instance, and the rest on both.

all_clients_require_mod = false // client_only_mod = false => server side only

all_clients_require_mod = true // client_only_mod = false => server and client side loaded

all_clients_require_mod = false // client_only_mod = true => client side only

all_clients_require_mod = true // client_only_mod = true => nonsense

I don't have to use the workshop at all, I just go to the world tab, enable caves, go to the mod tab, enable mods.

When you don't have caves enabled, all mods are loaded (because the instance you see is both server and client, you are the server, your interactions with the world instance are the same like in Don't Starve, lag never bothers you).

To debug, I read the relevant logs (client_log.txt on DoNotStarveTogether with no caves or with caves and client crashes, or server_log.txt on the Cluster_X/Master or Caves folder with caves and server crashes). When the server crashes, clients just disconnect. I do admit it is cumbersome to have to reload each log when I'm looking for sequences of messages. What I also use is the c_announce console command instead of print, to make the clients see messages on top of the screen.

Link to comment
Share on other sites

Okay I think I understand where all of the confusion is coming from now.

 

I was under the impression caves were always enabled, much like in DS. So I didn't know if everybody was talking about one of the config folders that does or doesn't generate, depending if you're running the dedicated server via dontstarve_dedicated_server_nullrenderer, dontstarve, launch_preconfigured_servers, or launch_dedicated_server. Or for all I knew, it could have been something else entirely (which I guess it was).

 

It seemed odd everybody kept specifically mentioning caves, but I didn't realize it was a whole other setting that was disabled by default. Now I see everybody is talking about about the caves tab on the hosting screen and how it has to be manually enabled. And yeah, that's a lot easier than reuploading to the workshop or messing with dedicated server configurations.

 

So my fault, yall. Thank you for the help!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
  • Create New...