Jump to content

Vincula

Pathfinder
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

3 Neutral

About Vincula

  • Rank
    Pathfinder

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I need to delete one specific character off our dedicated server... I've looked at the database using the redis desktop manager, but I am not completely sure what to remove. I can see two folders that seem to contain some player data; PlayerDataId and playerinfo (marked with the subtle red rectangles and even more subtle red arrows). I can find out which character is which by looking at the data in the playerinfo folder, but should I remove that entry in both of these folders, or just one of them?
  2. It's not exactly a game-breaker when there is a known and working fix available, I would agree to that. But since this problem isn't actually caused by user error (at least not according to anything I've seen from devs or other users), and the only known solution so far is to basically kill everything with fire and start over from scratch, it's not exactly in the "working perfectly" category either... Especially not for a game where progress requires such a significant investment of time. Yes, I know it's still in (very) early release, that problems and bugs are virtually guaranteed at this stage, and that you should always expect to have to reset occasionally due to updates and changes. I usually don't get scared away from a game just because of stuff like this (I'd even go so far as to say that I enjoy a good problem)... But I do get a bit worried that the less forgiving users probably outnumber me rather massively, and if things like this happens too often, a lot of them might give up on the game, which could end up burying it. I fully agree with your basic message, which is - if you'll allow some interpretation on my part - to just leave Grapeshot be and let them get on with it, instead of whining our asses off at any given opportunity. But no matter what you or I think, the fact is that Grapeshot will be blamed for this by a lot of users, because Internet "logic" dictates that if you get a sudden problem, and you did not make any changes beforehand, then it's always the developers' fault - especially if this happens just after an update. I just hope they get it fixed before it generates too much fallout in the community... I'd hate to see this game die before it's even born.
  3. Okay, we tried deleting our characters - we did a full reset of all servers - and now everything is working again It looks like it was the same problem that's already been reported to the devs after server crashes, transfer failures, and updates. To elaborate: to fix this, we cleared the redis server and deleted the ShooterGame\Saved folder. Yep, it's a restart of your pirating career, but at least you can play again. Luckily, we've found a quick and easy way of distributing changes to the .ini files to all 225 save folders ahead of time, so the only thing we need to do now is to put on the tricorn hats and eyepatches and make the seas unsafe once again. Sigh. Our brand new brigantine... Oh, well. Yarr, maties... Hope this is useful to someone else as well!
  4. Nope, still not working. (But not entirely working either.) Atlas client still v. 16.31, dedicated server v. 16.39. Are the rest of you up and running, or are you also still getting that annoying timeout? Update: Okay, I did some testing, and an ominous pattern emerged... It seems I can actually join any server - except any server on which I have an existing character. Apart from the fact that we never had the usual kick/server crash that usually seems to set this off, this is beginning to sound an awful lot like something I heard about while reseaching this problem. I think I remember that the fix in that case was given as "delete your character", but I hope I'm wrong. I'll research it some more, test, and update again.
  5. I see there is a server update this morning (well, it's that end of the day where I am, anyway). Hopefully, that will fix the issue... I can't check until I get home later today; I only have access to the server from work, not my client machine. That happens every once in a while... It did with ARK too; most often in the early days. Usually, though, one of their 27 unannounced daily patches will fix anything at some point, given enough time Granted; these guys have a pretty damn alternative approach to creating a video game, but at least they usually keep working at it like a bunch of highly enthusiastic hyperactive ants on crack until it works (unlike a LOT of other developers, who publish grand-looking plans right up until they've sold enough copies, at which point the game is reduced to a defective Pacman clone and nothing ever happens again). It might not always work during development, and it's next to impossible to get any sort of information out of the devs even on updates that have been rolled out, but at least they actually seem to be putting in the hours, just like they did with ARK. To be fair, I think they have learned from the ARK development, but most of it's about how stuff works in-game. For example, creating buildings in ARK, especially in the early versions, was... Let's just call it "challenging" and leave it at that. Contrast with how that works in ATLAS from the get-go (i.e., better than it ever did in ARK, even after numerous improvements); it seems they did learn their lessons there. As for the community communication skills; not so much, but nobody is perfect
  6. Yep, same here - my server is at 16.33, and seems to think it's fully up to date. The client only updates to 16.31, but maybe that's planned. Ever since that update, by the way, we can't connect to our dedicated server... It asks for the password, but immediately gives a Host Pending Connection Timeout when we try to log on. Everything worked fine yesterday, and the only thing we did since then was update. This sucks
  7. First of all, thanks for creating a tool that makes playing the full map easy for those of us who don't happen to own a server farm! Second; can you tell us what the changes from v1.5 are?
  8. Changes to the Game.ini files are relatively easy to handle, since the contents of the Game.ini file is identical for all servers... At least for our setup - but obviously not if you're running with different settings for levels, stat increases, etc., on each server grid. If you do run with identical setups, then all your Game.ini will essentially also be identical, and you can disitribute them using a simple batch file like this: @ECHO OFF SETLOCAL EnableDelayedExpansion FOR /l %%x IN (0, 1, 14) DO ( FOR /l %%y IN (0, 1, 14) DO ( IF %%x LSS 10 (SET XNum=0%%x) ELSE (SET XNum=%%x) IF %%y LSS 10 (SET YNum=0%%y) ELSE (SET Ynum=%%y) SET FileNum=!XNum!!YNum! REM MD !FileNum!\Config\WindowsServer COPY /y Game.ini !FileNum!\Config\WindowsServer ) ) You just put your Game.ini in the ShooterGame\Saved folder along with a .bat file containing this, and run the .bat file - it should distribute the Game.ini in your Saved folder to each of the 225 server save folders, as long as you kept the default naming scheme for the save folders (0000-1414). If you want to do this before starting the servers, edit the batch and remove the REM and space before the MD !FileNum!\Config\WindowsServer line - this will make the script create all your save folders and then copy the Game.ini to them, overwriting any existing file in the folder. Re-add the REM and space afterwards (or delete the whole line) to use the batch for any later updates to your Game.ini. This works at my end, because the Game.ini the servers want to create is actually empty, and it seems that it doesn't overwrite the existing contents when it doesn't have anything to replace it with. Use at your own peril (and by all means, test it first by adding an ECHO to the start of the COPY line so it just outputs the text to the console without doing anything) Unfortunately, this does not work for me - I always get the same default settings no matter what I do to the DefaultGameUserSettings.ini before starting a new server. And here, we can't use the same batch trick as we could with Game.ini, because GameUserSettings.ini contains several settings which are unique to that specific server (port settings and session name, to name a few)... I tried to distribute a GameUserSettings.ini ahead of time which only contained the lines I want to add, but it was completely overwritten on server startup - probably because this, unlike the default Game.ini, actually contains data. This also means that, for servers which haven't run before, you have to start it, shut it down, change the settings, and then restart it, before your changed settings take effect. But we still have one thing we can do instead: Command line arguments in the launch batch files (i.e., the 225 Start XXYY.bat files). Since all the batch files are already created before server startup, adding the settings to these instead makes sense - the first-time servers will launch with the your settings the first time around. However, we still can't just replace the entire file contents, because it contains even more server specific settings which must be correct, for example ServerX, ServerY, AltSaveDirectoryName, and query/game/rcon port numbers. A script for adding what you want to all the .bat files without changing the rest of the contents is a bit more complex, but not much: @ECHO OFF SETLOCAL EnableDelayedExpansion SET "Insert=UserBaseAlienationFactor=8.000000?NetworkLagInductionMultiplier=15.000000" FOR /l %%x IN (0, 1, 14) DO ( FOR /l %%y IN (0, 1, 14) DO ( IF %%x LSS 10 (SET XNum=0%%x) ELSE (SET XNum=%%x) IF %%y LSS 10 (SET YNum=0%%y) ELSE (SET Ynum=%%y) SET "FileNum=!XNum!!YNum!" SET "FileName=Start !FileNum!.bat" ECHO Filename: !FileName! REN "!FileName!" temp.txt ( FOR /F "tokens=1-12 delims=?" %%a IN (temp.txt) DO ( IF NOT "%%b"=="" ( ECHO %%a?%%b?%%c?%%d?%%e?%%f?%%g?%Insert%?%%h?%%i?%%j?%%k?%%l ECHO exit ) ) ) >edited.txt REN edited.txt "!FileName!" DEL /q temp.txt ECHO has been updated ) ) You basically place this .bat in the same folder as all your launch files, edit the third line to include your preferred GameUserSettings.ini options divided by question marks (but none at the start or end of the string). Needless to say, UserBaseAlienationFactor and NetworkLagInductionMultiplier don't really exist in the game (at least I seriously hope not), so replace them with the actual game settings you want to change. Beware that this script CANNOT be used to do running updates directly, unlike the Game.ini script above! This script is pretty much hard-coded to be used on the original start batches, and will not be able to handle anything else - personally, I've taken backups of all 225 files in their original versions... If I want to change something, I change the script and use it on fresh copies of the originals, so the files do not contain anything unexpected. Please note that even small changes to the Start XXYY.bat file contents will make this script do weird things - for example, the number of settings in the arguments (i.e. the number of expected question marks (delimiters)) is hardcoded to 12 - so ONLY ever use it on unedited start files which has a form similar to this: start /high ShooterGame\Binaries\Win64\ShooterGameServer.exe Ocean?ServerX=0?ServerY=0?AltSaveDirectoryName=0000?ServerAdminPassword=1234?MaxPlayers=50?ReservedPlayerSlots=25?QueryPort=50002?Port=5002?SeamlessIP=192.168.1.225?RCONEnabled=true?RCONPort=28450 -log -server -NoBattlEye exit The number of switches at the end should pose no problem, but add or remove a term in the block separated by question marks, and you will have to recode. I'm sure someone with more experience writing batch files could do something more general instead of this hard-coded mess, but it might still be useful to someone out there apart from myself (if nothing else, then as an inspiration to go "okay, so I'm definitely not doing that"), so here you all have it.
  9. Nope; already checked... I can edit the Default*.ini files just fine, and the changes stick in the files, but it seems that this is not actually where it gets the settings from. It doesn't make any sense, really, but that's the behaviour we're seeing. I'll try batching the batches later today, I think that's the most promising method so far. If that doesn't work, I'll try wading through the .json and see what I can find there. You can run it in two different ways, or combine the two: Automatic startup/shutdown of servers sets five servers running; the one you're in, and the four servers you can travel to from there (up, down, left, and right). When you cross the border to the next one, the program shuts down the three that are no longer bordering on the now occupied grid square, and starts up three new ones, so you again have all four surrounding servers running. Of course, this requires your hardware to be able to handle five servers plus the redis simulataneously (which, according to several people in here would be about 20 GB of RAM and eight CPU cores). It also requires some tracking of one player, but my current setup cannot handle five servers at a time, so I've never used this myself (but I will try it out once I get my new PC up and running). This also means that it will only auto-start/shutdown servers based on that one player's location, and not the others. Manual startup/shutdown of servers allows you to manually start up and shut down servers as you wish. You have to do this manually, but it's only a few clicks each time - I use a TeamViewer connection to the server machine, so I can control this via a tablet (and avoid running through the house every time we change map squares). The advantage for people with limited hardware resources on the server (like me) is that you can use this method as long as it can handle two servers + redis (which is about 8 GB of RAM free and 4 cores) - you just start the neighboring server you want to travel to, cross the border, and shut down the previous one. Most of the time, you will probably only have one running (plus redis). If you have an even beefier hardware setup, nothing prevents you from combining these, so that you have the current grid and its neighbours active using the automatic part, and up to four other servers always running (for Homeports, for example). So there's a hard limit on how many locations this tool can have running at once; 9 grid squares - the automatic five-server cluster, and four manual ones. This means that you won't need a lot of people in different grids before it gets both impractical and fairly hardware intensive. Rememeber that treasure maps that spawn in-game can only point to grid squares that are currently active on the map... This means that if you play in, say, grid E10, and only have that grid running, then all treasure maps you pick up will always be for grid E10. This also means that if you are in E10 and you want one in O15, you can just start that one too, which makes it equally likely that the maps will be for grid O15. I don't pretend to understand the reason, but I hear from seemingly well-informed people in here that this is just the way it is - if you want your treasure maps to be able to hit any grid square, this is currently impossible without running all grid squares simultaneously. Good point about the homeports - make sure that joining players or dead people have somewhere to spawn! We build beds with obsessive priority on our ships and anywhere we stay for more than about five minutes, which also works, by the way... Our hardware resources on the server are limited to running three servers at a time (maybe four if we bully it a lot, but I haven't dared trying this yet for fear of sudden crashes), so we prefer being able to respawn where we're currently lurking about. It makes things easier for us that no one new ever needs to join, however.
  10. Unfortunately, editing the DefaultGame.ini and DefaultGameUserSettings.ini does not work for me for some reason - it ignores any changes and just applies the defaults when the server is launched. It's the same problem with the islad editor... The only thing I've had working was to edit the settings for each map grid, but then I'd have to edit all 225 manually, and then it's actually faster to just edit the .ini files. I still haven't tried inserting the lines into the "Start XXXX.bat" files, but I think that might actually work. I will update once I get a chance to try that.
  11. Maybe you did - it's not easy to tell what someone is trying to say when their writing style contains more punctuation than letters... I'm 35+ and not fluent in teen-speak. I did ask you, but your answer to that wasn't any clearer that what you said the first time around. It was, however, a lot more abrasive, which I think was hardly called for. Kramuze managed to deliver the same info in clear language using just two lines of text, so yeah, his post was a lot more useful to me.
  12. All the correct ones Sorry; I'll try for a non-stupid answer instead... I forwarded ports 50002-50898, 5002-5898, and 27000-27896, as it said to do in the tool, and made an exception in my firewall as well for the same port ranges (both UDP and TCP in both places). FYI, I am using the following settings in the tool, and I am using a 15 x 15 grid. Query Port (the one that's just called "Port"): 50002 Game Port: 5002 Seamless Port: 27000 Port Sequence: Every 4th This made it work at my end, but only after I had my ISP change our IP to a public one. We got a dynamic one, which could be an issue with setups where you want others from outside your network to be able to join, but we don't need that (but by the way, that dynamic IP hasn't changed once since we got it two weeks ago). Because only our own household uses the server, we're using local IPs (192.168.XXX.XXX) everywhere in the server setup, which is working fine for us (actually, the one time we tried using the public IP, we couldn't see or connect to the server, so we've only ever seen the local setup work). The only thing we use the external IP for is to connect to the server... Whenever we can't see it in the in-game server list - which happens annoyingly often - we can usually connect to the server using the Steam overlay (Shift+Tab when in-game) web browser with our external IP (5.XXX.XXX.XXX) and the query port number of the server we're connecting to (e.g. steam://connect/5.XXX.XXX.XXX:50278 to connect to map grid E10 on our setup). Thanks; I will look into that. It might be necessary because of the damn spaces in the filenames for the server start .bat files - an underscore instead would have made it a lot simpler for my limited scripting skills (compounded by the word "start" not exactly being meaningless in a batch file) Why oh why did my grade school waste time teaching me a bunch of crap about history and society, when what I abviously really needed was some solid scripting skills? I'll never know
  13. I've tried editing the Default*.ini files, but the servers still use the same standard setup each time regardless... They seem to ignore any changes when the server .ini files are generated. Basically; what he said. I would just need to edit 225 separate .bat files instead of 225 .ini files. This might be possible using a homemade .bat file, though - create one that goes through each startup .bat file, looks for something in the string, and adds whatever I want to the launch option string. The reason this would require a restart of the server with the .ini file is beacuse the .ini has to be generated before it can be edited, but the .bat is already there, meaning the servers would start up with the correct settings the first time. Hmm... Too tired for scripting right now; I'll get on it tomorrow. Thanks for the help and/or inspiration
  14. I am not at all sure I understand you... If you're talking about the ability to edit these in the ServerGridEditor, then yes, I am aware of that - I also have 225 servers that need the same setup, so I would very much prefer not to have to do this manually for each one. Then again, I might have misunderstood that, so corrections are welcome. I am completely sure that I have no idea what the Command/Arg thing means, though.
×
×
  • Create New...