Jump to content


Very Important Vintarian
  • Content Count

  • Joined

  • Last visited

  • Days Won


skol last won the day on July 5

skol had the most liked content!

Community Reputation

26 Excellent

About skol

  • Rank
    Bronze Caster

Recent Profile Visitors

833 profile views
  1. Distro / Kernel release : Ubuntu Mate 18.04 LTS / 4.15.0-22-generic Mono / .NET package version : mono-complete Graphics driver version : NVIDIA binary driver 390.48 (proprietary) Works for client, mp server or both : client + multiplayer server Installation method used : server.sh Hacks (if needed) : none
  2. As we have a decent number of Linux users in the community, I would be great to collect the experience, for which distros/configurations it could be managed to run VintageStory. Please share in the comments your working VS linux configuration in the following way: Distro / Kernel release : Ubuntu Studio 16.04 LTS / 4.4.0-127-lowlatency Mono / .NET package version : mono-complete Graphics driver version : NVIDIA binary driver 384.130 (proprietary) Works for client, mp server or both : client + multiplayer server Installation method used : server.sh Hacks (if needed) : server.sh needs at least wget version 1.17.9 (not in the standard repo of Ubuntu 16.04)
  3. The root certicates were also the root cause for the connect issue with wine. In Ubuntu, mono comes with certificates. Good to know how to handle this in Gentoo!
  4. The last time I got this connect issue was when I tried to install/run VS with wine (this was version 1.0.2 - there was no installation tarball at this time). I never had this issue with mono. Which mono version do you have installed?
  5. @tony Liberatto Maybe you and the other mods want to disclose their personal info to the friendly community, too. This would allow to communicate at the same level of information.
  6. #metoo please I already joined after setup but that was before the whitelist was set up Vintage Story Player name: skol Age: 100/2 - 1 boring old-fashioned IT-Professional from Germany Do you agree to follow the server rules?: of course
  7. Yes, that's the scope. And it is of course a console interface and not a fully flegded and feature-rich GUI. But as Tyron mentioned, the script should be, let's say, encapsulated, being at least possible to handle multiple instances/installations. But I think the script already is encapsulated this way and I only need to test and describe how to separate the custom options that were chosen for each install. This documentation should prevent experiments of users to end with frustration and complains.
  8. @TyronYour wish is my command. Uploaded the current script with some tweaks and provided documentation, see https://github.com/zkol/vsadmin The documentation should explain e.g. how to run multiple instances on different ports in parallel. Documentation how to install different versions in parallel will follow. After this I'm going to split the script to create a basic (aka "more minimal") version that uses per default a data path relative to the script location as Tryon suggested (using internally the --dataPath arg to make this happen). home/vintagestory/1.5.2 server => here should reside the script of v1.5.2 data => this would be derived from script location: ../data /home/vintagestory/1.5.1 server => here should reside the script of v1.5.1 data => this would be derived from script location: ../data I think the basic script could maybe offer a stable backend interface for other tools like the more powerful remote web GUI that @Milo Christiansen announced. I think it would be helpful if this basic script would pass every invocation parameter transparently to VintagestoryServer.exe in a way that overrides the default parameters.
  9. @Milo Christiansen Don't get what you mean with big fuss. @Tyron seems to think about changing the datapath logic again. That's his choice. I he wants to keep the mentioned benefits of the --datapath option or not is his choice. I'm just waiting patiently for his decision and not part of any fuss.
  10. @Tyron In the comments above you asked about having packages for linux distros. With a distro package it would be impossible to have multiple versions of the same package installed - so you would force the package maintainer to create a new package for each version.
  11. @Tyron I know this of course. I left this detail out because it is not crucial for the decision. Before: Relative datapath per default. Now: independent datapath configurable. Point to discuss: Relative datapath per default. One argument for the discussion: By switching back to relative datapath, you are forced to install the full software for each instance you want to run.
  12. @TyronIn principle, thats where we came from before configurable datapath was introduced. Of course you can roll back this with all the consequences regarding backward compatiblity. But maybe it is less trouble to keep this approach and have a start/stop that is capable to handle this.
  13. Good to hear that this works for you! I understood that you installed the server tarfiles manually and managed your own folder structure, right? How do you start the server? Does "shortcut" mean a mini-script like "mono VintagestoryServer.exe --datapath whatever" ?
  14. @Tyron how shall I start a server without handling the data folder by parameter? It would only work with the default data folder location that is coded in VintagestorySerer.exe
  15. I think it is important to highlight that there is no need to use the server script to run a server. It is sufficient to run mono VintagestoryServer.exe --datapath whatever If you separate different worlds with different ports configured by datapath then the work is done. If one is familiar with shell then it is no great challenge. Most important is a clear structure to manage 6 installations (and maybe some different software versions too). Is it easy? Depends on your skill. The main usecase of server.sh is to provide a bit comfort in terms of having a quick start to fire up a multiplayer server (e.g. in the home LAN): start/stop script that can be integrated in the boot process backup feature update/reinstall feature console access to server commands primitive status monitoring This is a starting point but not a hosting solution. Means it is limited, but I think this should be OK. Imho the main goal of the script is to be robust, portable and easy to use. Enhancing the script to have more comfort and less limits, makes it harder to achieve this goal. E.g. the option to have the datapath seperated from the software installation and to configure this per commandline enables a multi-instance setup. But it made the script usage complex and error prone too. Therefore some checks and limitations shall prevent issues, data corruption and data loss. Currently, this limitation includes preventing multiple instances from being started at the same time (as this was no requested use case until now). If Tyron wants server.sh to support this, it would be not big coding effort to extend the existing script logic to allow one instance per port. But again - this would be another step to increase the complexity. Therefore my recommendation is to split the current script functionality in two scripts: basic start/stop/status features of server.sh (portable according to system V init style) enhanced features of server.sh The basic usecases would build a stable foundation that not affected by the increased complexity of the enhanced features. This foundation could be used as a backend for a web GUI (which is another level of encapsulated complexity) @Tyron I have no ambition to maintain a debian or ubuntu package, sorry.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.