Jump to content

Search the Community

Showing results for tags 'server'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Vintagestory Discussion
    • News
    • Discussion
    • Suggestions
    • Questions
    • Multiplayer
    • Bugs
  • Creative endeavors
    • Builds
    • Videos, Art or Screenshots
    • Story
  • Vintage Story Modding
    • Mod Releases
    • Modpack Releases
    • Mod Development
  • Off Topic
    • Other Games
    • General Offtopic

Categories

  • News
  • Community Spotlight
  • Stories

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 20 results

  1. Version 1.1.0 The mod creates a default Item-Package, stored in JSON file. As Server-Admin (also in Singleplayer) you can edit this json file by adding the items / blocks with its code. Editing the Item-Package-Json file requires a restart of the Server/Singleplayer. path: \VintagestoryData\ModData\<world-id>\starterpack.deliveritempackage.json Only the ItemCodes are supported! All Players will be recorded by its uuid, which is created by VintageStory-AccountManagement, and garantues that no one will get the items twice. path: \VintagestoryData\ModData\<world-id>\starterpack.playersreceivedpackage.json You can edit both files, but be sure you know what you are doing with it. For Multiplayer, this Mod is only needed on Server-Side Singleplayer is supported also. V. 1.0.0 creates both JSON files on first startup, in context of the world-id => \VintagestoryData\ModData\<world-id>\ edit deliveritempackage.json needs restart of server/singleplayer. BE AWARE: using Codes only! edit playersreceivedpackage.json needs restart of server/singleplayer V. 1.0.1 Add error handling when item not exist when block not exist V. 1.0.2 Fix (Singleplayer) when switching world, the files where not created Add exception handling when items / blocks not found V. 1.1.0 Improve some codings, clearing some compatibility issues to my other mods, by a shared library Known issues: Backpacks / Baskets etc causing client crashes, so blacklisted them by mod-coding - sorry. [Mod for Version .1.13.4+] starterpack-1.1.0.zip https://www.vintagestory.at/applications/core/interface/file/attachment.php?id=4074 ----------- Sample of the default Item-pack-json file {"deliverItems":[ {"Type":"block","Code":"torch-up","Amount":3}, {"Type":"item","Code":"stick","Amount":10}, {"Type":"item","Code":"flint","Amount":10}, {"Type":"item","Code":"fruit-redcurrant","Amount":20}, {"Type":"item","Code":"bread-spelt","Amount":3} ]}
  2. Administrator's Toolkit It allows Administrators to force players to both read (or at least skim), server rules and conditions. Optionally this can also be configured to ENFORCE players agree to these rules. This works by changing a players default roles around - they become a 'guest' unable to place blocks until they issue a '/rules agree' command... It can list both online / offline administrators automatically, dynamically. It has a nifty automatic-backup sub-system that can keep rotating backups of the game world database. Its a SERVER SIDE ONLY mod. (clients need nothing extra) Admin Toolkit *DOWNLOAD* Version 0.3.4: Updated to be Compatible with VS 1.12.4 Using official API for server commands now...not the workaround code anymore. Fixed offline admin names not appearing Brief manual: Readme.md (link) While this mod has been tested - and should work for VS1.12 , VS itself is under constant revision and updates - so it may need to be upgraded for the next release. It will probably gain new features or capabilities as admins request these, and please comment in this thread about bugs, issues or requests. Source code: https://osdn.net/users/melchior/pf/admintoolkit/scm/
  3. Version 2.1.2 Main features of Mod Portcullis in different sizes (3x3 to 5x5) Drawbridges in different sizes (3x4 to 5x7) Floor-Plates for auto-open/close Doors and Gates Full animated Every item has recipe Seperate Portcullis-Part item for construction Recycle gates back to parts recipe included Languages: English + German Wood material and texture on Drawbridges V. 1.0.0-RC1 V. 1.0.2-RC3 V. 1.1.0-RC1 V. 1.1.0-RC2 V. 1.2.0-Alpha1 V. 2.0.0 REQUIRES VintageStory 1.13.1+ FIX minimap textured Fix texture-orientation on drawbridge New textures, by adding wood-material to each Drawbridge (Oak, acazia, birch, etc) Compatible to previous version, by doing code-remapping! Singleplayer will this map-patching reqested to the player! Server will do that on the next start automatically BOTH take some minutes cause of those many Code-Mappings! Stay calm V. 2.0.1 Fix recipe for Floorplate Stone V. 2.1.0 Add Lockable to Drawbridges and Portcullis Add Player identication to Floorplates V. 2.1.1 Fix Portcullis interaction caused crashes V. 2.1.2 Fix Lockable behavior not worked correctly. Other players could open the locked Drawbridges / Portcullis. Thanks for reporting @Tech_Rabbit Known issues: Code-Mapping takes some time (only on old maps) V2.1.x does not work with VS-1.13.0 by a bug, which is fixed in VS-1.13.1 Planned features : Interaction-Blocks for open / close Drawbridges and Portcullis Big Gates / Doors [Mod for Version 1.13.0+] gates-1.2.0-Alpha1.zip [Mod for Version 1.13.1+] gates-2.1.2.zip
  4. , I suggest... A switch (for server administrators) that allows players to load (for a singleplay) the server map...
  5. I often start a server for friends using VintagestoryServer.exe. But since its icon and name are very similar to Vintagestory.exe, I sometimes get confused and run the wrong thing. It would help inattentive people like me, and indeed it would be beautiful!
  6. In this spotlight you can see what the players have built on our server.
  7. The idea for this server is to offer a family safe and fun place to play VintageStory. We now have 4 servers to attend to all tastes. They have different rules and content: Default Darkagecraft: Moded PVE The server is only used to host Vintage Story. The Darkagecraft PVE Moded Server at darkagecraft.net The Darkagecraft Vanilla, with the latest stable game version at darkagecraft.net:42423 The Darkagecraft Creative, again with the latest stable version at darkagecraft.net:42422 The Darkagecraft Dominions, a Moded PVP server at darkagecraft.net:42424 Please make sure to type your Vintage Story Username correctly, we will copy and paste it into the server.
  8. This is a simple, server-only mod that allows you to automatically broadcast messages in server chat with the prefix [Info]. I'll update it soon to make the prefix customizable. How to use: Put the zip file into your mods folder, and start the server. This will create 2 files in your Data Folder (where the serverconfig.json etc. are). One is called messages.txt and the other one messages.config. Open messages.txt and type whatever you want (each line represents one message). To set the interval, open messages.config and edit the number after "interval" to your liking (default is 10, in minutes, positive natural numbers only, make sure there is only one space between "interval" and your number). Restart the server, now a message will be sent to chat every x minutes. If you're experiencing any issues, please report them here! Hope you enjoy it announce_v1.0.0.zip
  9. Hallo zusammen Wir suchen weitere Spieler für unseren Server. Ein paar Eckdaten: [GER] quer-wisser.de - Multihome, Spawn - Multihome Erstelle bis zu drei Homespots. Nach Bedarf und Anzahl der Spieler, kann es beliebig angepasst werden - Spawn Kehrt zum Herzstück zurück, der Spawn wird stetig erweitert - Zufallsteleport Teleportiert dich auf eine zufällige Position. Mit den Multihome Spots in Verbindung, kann man perfekt die Welt erforschen - PVE Dies soll ein reiner PVE Server bleiben - Backups In Regelmäßigen Abständen werden Serverbackups erstellt. - Discord Unser Discordserver - Webseite Unsere Webseite - Facebook Erste deutsche VintageStory Facebook Gruppe Wir würden uns freuen weitere Spieler hier begrüßen zu dürfen. Aktuell werden Teile vom Spawn noch gebaut. Die nächste große Spawnerweiterung ist fast vor Fertigstellung ...
  10. Hello, When playing on servers, you notice progress of time can both be quite crippling and boosting at the same time if you compare the mp experience with the sp experience. When you're not in-game while others are, time progresses to affect food decay, plant & animal growth and reproduction, torches burning out and barrel aging/ripening processes (and crop decay as of next update) in the chunks you are in, even when your whereabouts are nowhere near the place where other players are active. So, when you rejoin the server after some period of absence, you can find all your food (and crops) decayed, the torches you placed burnt out and all those saplings you planted the day before fully grown. This is not encouraging nor adding to the intended immersion for any player in early game, for players who play less frequently or on a more occassional/casual basis than the more fanatic ones on any server. The food (and crop) decay aspect is the most discouraging one in this respect, obviously. Many experienced veteran players have hardly experienced this as an inconvenience as they either hardly played as a new player on servers since many time dependent relationships were introduced, or are already aware of how to deal with the odd inconveniences, as I experienced myself as well after a while. Still, it does not seem right in various ways that the mp experience differs so strongly from the sp experience, for any player, in any in-game development stage. I think any game ready for beta release should strive to provide similar mp and sp experiences to its (new, cash-flow generating) player audience especially when it comes to mechanics that strongly affect what a player does or plans to do on an in-game-daily basis. The time progress mechanics connected to food decay, crop growth (and decay) and all of the other time dependent processes are referenced to a server timer, and calculated based on 'world time progress' as soon as a chunk is loaded. I wish to suggest to consider to add chunk and/or player based time referencing for those mechanics and make this configurable for servers. This would imply adding chunk and player time stamps, respectively updated every time a chunk is unloaded or a player logs off. These can be used as reference for calculation of food decay state every time a food item is loaded/accessed by the player who last touched/accessed/processed it and also for calculation of any other time dependent states each time a chunk is loaded. Progress in time will resume normally once players (incl. their inventories) and chunks are loaded, just the progress during the time they were not loaded will have stagnated. When a player is online and moves from one chunk to another, and eventually chunks they started in are unloaded and when they return and load chunks back again, you would want time for both food decay, crop growth (and decay) and other time dependencies to have progressed during the entire time that player was online. So, player online time duration should be leading in any case. This implies a server must store the last login time of a player and the duration they played since then, for chunk progress mechanism updates to be referenced. Then, upon a chunk reload, the progress for said mechanics shouldn't be adjusted by just accounting for the timestamp left in the chunk, but corrected for player playtime since last unloading event of that chunk and until recent loading event as well, and that for the player who last left the chunk before it was reloaded. This implies a chunk would also have to store 'last player who was in the chunk before it unloaded'. For food decay one could consider two variants. One where a prepared food items decay is calculated based on a timestamp connected to a player and their nett playing time, and another where food decay is calculated based on the time the chunk where that food item is stored has been loaded. For multiplayer servers this can make a huge difference in areas where many players are active in the same or overlapping areas for many possible reasons. For instance, for hardcore PvP servers, where player competition can have quite a devastating character, players can force load chunks of other players' bases and consequently make their food (and crop) storages go to waste. For such servers it may be recommendable to use 'player playtime referenced food decay'. For strict PvE servers where many players are building their own and in many cases only visit each others habitat for direct interaction, 'chunk loadtime referenced food decay' would be an acceptable alternative. For cooperative food production and sharing it will be worthwhile to 'retag' a food items decay time reference with another player as soon as the item is handled by a different player than the one that originally 'created' the item. In case of 'player playtime referenced food decay' there can be a potential 'tavern exploit' where one player processes a lot of food in single item containers (crocks) in one area to leave it for others to use when they need it and the producer player logs off for an indefinite period of time. Chances of players actually doing this may be relatively low, but it is not an unthinkable scenario and it therefore justifies a counter. On servers where this possible exploit is deemed a serious risk, 'chunk loadtime referenced food decay' may be considered. An alternative is to add a 'claim ownership/access permissions override'. Any food item in a claim accessed by anyone with specific privileges in that claim, will have decay progress dependent on the in-game time of any of those players. If a 'tavern' has food stored produced by player A and player A shares the access to the containers in that tavern with players B and C via the claim system, in-game presence of players B and C will also ensure decay progress of any of the food items in the claim. Also with this scenario in mind, the desirability of any option can strongly depend on the type of server, so configurability seems required. For PvP/faction focussed servers the claim override option may be best suited. Another alternative may be to have a setting per player that determines whether the food decay for items produced by that player will be 'player playtime referenced' or 'chunk loadtime referenced'. That can then be set at the moment a new player joins the server, either defaulted or left to the player to choose. Any food item will then get a tag indicating how food decay progress is to be calculated. As soon as a different player handles an item or a food holding container, the tag of the affected item(s) can be made to irreversibly switch to 'chunk loadtime referenced'. Seasons are planned to be introduced in a next game update. This will enhance the effects offline time progress will have on individual, new and/or more casual / less active, players on servers, and will therefore only increase the urge to address the issue brought forward here. Overall: For food decay, calculate the actual shelf life progress of any item based on the playtime of the player who last processed/handled/stored it: 'player playtime referenced progress of time'. If a player creates a processed food item and stores it in some container, the shelf life progress will be equal to the time that player is in-game. As soon as another player 'takes over', the in-game time of that player will become determinant for the shelf life progress. For all other processes, calculate the time progress based on both the time the chunk where the affected items/entities are located and the time the player spent in-game who was the last to load the chunk: 'chunk loadtime referenced progress of time'. This may also be useful as an alternative for food decay, dependent on server/community playstyle/goals. For food decay a combination of both calculation methods may also be considered. The proposed changes will not lead to an 'ideal fix of the issue' (which may simply be non-existant or not achievable), but it will improve the situation considerably for a lot of players on servers. For new and/or more casual players on servers who value the experience of the various sp game dynamics next to having company while playing, the situation will become much more pleasant and inviting. For servers where most players are involved in joint efforts, focussed on one or only a few locations, or where most players spend their time 24/7 on the server, it may be worthwhile to leave the option to not use this alternate time referencing method and just keep using the present method. There may be more aspects to address when considering this suggestion. Any progressive insight will be processed in the core text above. This will obviously not be of any added value for single player worlds, but for multiplayer worlds this can have profound impact on the experience of individual players and on their motivation to continue playing, and consequently on long term server and community viability. I hope the above makes sense, you will be able to find a suitable way to tackle the issue brought forward and my suggestion is worth considering. Cheerio, Alte Edits: 1) After more pondering it became obvious that for food decay on multiplayer servers the aforementioned 'timestamp connected to a player' option would be the way to go. In other words this would concern a system where each food item is time-tagged with the player who last handled it. This could also be seen as an 'ownership system' as worded by radfast in one of his constructive comments below. This post summarizes this view and some additional thoughts related to hoppers. 2) This also concerns the burning time of torches, and the aging/ripening times for various recipes in barrels. For these processes I would also recommend to use time referencing based on a combination of chunk loading/unloading and player activity. 3-5) Various rewrites. Added remark related to potential 'tavern exploit' that could affect mass produced food in single item containers, as discussed with Saraty on Chrometech. Included 'crop decay'.
  11. Joining a server for the first time can be a very unpleasant experience for new players. The experience can be much different from that in single player in various ways (a.o. the progress of time). In this suggestion thread I wish to focus on the first in-game day or days of playing on a server. I want to address the fact that when a new player joins, they tend to be in urgent need to gather a lot of stuff that can help them settle for a safe passage of the night and/or go out on their first main adventure, to find a nice place to settle. This first experience can be quite hindered by the fact that players cannot see whether it is dawn or dusk, day or night on a server before they join. Also, a heavy temporal storm could just hit the moment a new player has just gathered their first resources to craft something simple as their first axe. It would be very helpful to ensure new players aren't set back too much from their first attempts to join a server if server management could have one or more of the following options at their disposal: Show in the server listing info what the time of day is on a server. The format for the displayed info could be made customisable for server management. As soon as 'seasons' are implemented, season info may also be very useful for new players (any player) to have in the server listing info. Make the server time of day get adjusted to dawn as soon as a player joins the server for the first time. The exact time could be made customisable for server management. Make the temporal progress timer reset as soon as a player joins the server for the first time. I'm not sure what variables need to be considered for this, but I can imagine the exact 'shift' could be made customisable for server management. Provide new players with essential gear, a.k.a. a 'starters kit', as soon as a player joins the server for the first time. Server management obviously would want to be able to provide new players with anything they think fitting, including armour already donned, and mobile containers possibly already filled. All dependent on how they and their community would want a new player to experience their server. With seasons, a season dependency may also be desirable. More favourable seasons may require less of a starter boost than a fresh start during the dark of winter. ... Some of these options may have been suggested before and there can be more options to be considered for this purpose. I just wish to list them here and want to stress that whatever may get implemented of these options (if any) they should be considered as 'options' for server management to decide on using for their specific purpose and use any related settings at their own discretion. The view of server owners/staff/communities on how their server best be set up can differ quite dramatically. I'm curious if there may be additional options the VS team could consider for this purpose. Please do not hesitate to add any in a comment below, nor to provide any other feedback on the above. Note that this excludes any options like 'provide a pleasant spawn environment with plenty of food and what-have-you', because that is obviously already an option for server management.
  12. Was wondering if when you get your vintage story server hosted and you set "AdvertiseServer": true, do you see it listed in the Multiplayer Section under browser public servers? If not how does one get it listed? Also is there a way to search of server? Thank you
  13. 1866 OLD WEST SERVER 88.214.57.152:2006 Neuer Server. Baue im Wild West Stil.PVP Bounties, Duelle, Turniere sind in Planung KEINE Tempority Stability Weniger Hunger (0.1) Monster am 10. Tag STARTER KIT (Melde Dich bei Joe_Garret und erhalte Essen,Fackel,Bett,Gear für SETHome) /home /spawn Discord <soon> MODS Immersion Mod folgt sobald Server auf Version 1.12.8 ist Wir freuen uns auf Deinen Besuch !
  14. Estou criando esse server brasileiro, logo deixarei ele completamente online por enquanto estou em fase de testes. mais fica como acessa-lo. bom infelizmente eu sou usuário de uma internet compartilhada logo não posso fazer alterações de portas, então para acessar o server vocês precisaram baixar esse aplicativo que deixarei o link disponível. Raidmin VPN Parecido com Hamachi. em baixo as instruções de como entrar na rede.
  15. By courtesy of Tony, host of Darkagecraft, I invite everyone interested in a lore driven, civilization-craft RP server to join our ----Discord Server-----. We love creating unique lore for our world, ranging from speculative cultures, ethnicities, religions, and the dynamics of these. But we also welcome more personal lore about your character and his/her navigation of the Dominions setting! Server features: RP-driven civilizations, Neolithic mod pack and more, Fluid and dynamic world lore that you can shape, RP-motivated PVP allowed ----Discord Server----- Server IP: darkagecraft.net:42424 To get the pack needed to connect to the server, please join our discord linked above
  16. This server was born out of a discord discussion about having a stable Vanilla Server. The server will only update to stable versions, The server will not have any mods ever. There is no whitelist. Any and all are welcome. The server address is darkagecraft.net:42423 The port number is important as we have the moded server on the default port. We do need admins and moderators, so if you are interested please reach me on the Discord Channel
  17. Graciously hosted by @Geartwo Mode: Just plain Survival Address: chrometech.at Rules: Don't break other peoples things, respect eachother, try to leave behind not too much mess (like floating blocks) I took the freedom to give op status to all of the VS team plus @copygirl, @Geartwo and @redram. If someone else wants to moderate, let me know. Please keep it at survival mode only. Since our player count is still pretty low, feel free to use this post to arrange playing times!
  18. When a player first joins a server they are shown an outfit selection window where they tune the character appearance. (This is quite comfortable for singleplayer, because of no mobs first 3 days. Tho I didn't know about this detail when I started ) It is uneasy/uncomfortable to select it at that time because players don't know if there is any danger around. So some of them try to close the window asap. Actually it may be even worse - when joining at night (tho sure it's better to wait and start a bit later at day). Afaik player can re-open the outfit window with C button (not yet described on Wiki probably), but I was told it doesn't allow to change clothes, unless I have found some in dungeons or got by trade from players. So players don't get a second chance to select their appearance and the first chance is uneasy. So probably lot of people will be running naked or random at best. Please improve the outfit selection feature. Maybe keep player in creative while they are in the initial dialog (Stroam). Or open the dialog just before joining server and showing the world. Sorry if there already is some way to do it comfortably. Please do tell, I'll update Wiki.
  19. VS-Server Service Copy your server.sh script with sudo or root to "/etc/init.d/<name>" Now you can user the script from everywhere e.g. "service <name> start" The server.sh commands start: Starts a new screen (use "screen -ls" to get the name) stop: Save the map warn the player and stops the server status: Tells you the if the VS-Server is running or not command "/<command> <parameter>": Execute a command with highest ranks backup: Saves all data in you VS folder except the backup folder in the backup folder (with VS-Version, time and date) update: Compares your version with the current version If the current version is higher warns users and stop the VS-Server Makes a backup Downloads the new version, extrakts and overrides old files Sets username and path in the new "server.sh" and sets executable rights Starts the VS-Server reinstall: Does a fresh installation of VS (a force update) Tips and Tricks Server setting are in "./VintagestoryData/serverconfig.json". There you can set settings like Port, Password, map size, Welcome Message and group settings Tweak performance when you have a strong server in "./VintagestoryData/servermagicnumbers.json": ChunkColumnsToGeneratePerThreadTick: 10-21 ChunksColumnsToRequestPerTick: 4-7 SpawnChunksWidth: 0 (When you set up buildprotection) ChunksToSendPerTick: 20-42 Good to know servermagicnumbers.json SpawnChunksWidth: How much chunks should be load/generated before server accept users ChunkThreadTickTime: 10(ms) = 1 Tick, that mean you have 100 generation-Ticks/second ChunksToSendPerTick: 20(ms) = 1 Tick, that mean you have 40 send-Ticks/second
  20. Important-Importante-Wichtig-重要-重要-важно If you have no clue how to use, monitor and maintain Linux, then you should use a professional gameserver hoster or if you have to much time and leisure, you should get first basic hosting skills. CentOS 7 (RHEL, Fedora) 1. EPEL/screen/wget/curl Install yum -y install epel-release screen wget curl 2. Mono Install yum -y install yum-utils rpm --import "http://keyserver.ubuntu.com/pks/lookup?op=get&search=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF" yum-config-manager --add-repo http://download.mono-project.com/repo/centos/ yum -y install mono mono-utils 3. Add the port to the firewall firewalld firewall-cmd --permanent --zone=public --add-port=42420/tcp firewall-cmd --reload iptables iptables -A INPUT -p tcp -m tcp --dport 42420 -j ACCEPT 4. Download the game Goto http://account.vintagestory.at/downloads Copy the link of the newest "vs_server_*.*.*.tar.gz" package Enter in the console "wget" and parse the link Hint: Make for VS a own directory the tar have no subfolder 5. Open TarGZ package tar -xzf vs_server_*.*.*.tar.gz 6. Make the server.sh executeable chmod 755 server.sh 7. Edit server.sh file USERNAME='<your-vs-server-username>' VSPATH='<your-vs-directory>' 8. Server start and first steps ./server.sh start # Wait for startup then you can give you OP ./server.sh command "/op <youusername>" 9. Connect to you IP/Domain and have fun
×
×
  • 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.