arkark

Unfortunately, I don't think anything will change in the future. And if it does it will be at the cost of losing functionality. Apparently someone thought it would be a good idea to reuse ASE servers that are practically 8-10 years old, and besides, instead of putting three game servers for each physical machine what they have done is to put five for each physical machine. Something inconceivable knowing the antecedents of how bad ASE was in populated maps. Obviously what they have is not enough, and I doubt very much that they are going to achieve a moderately acceptable performance during the whole life of ASA, unless they discover that there is a huge bug in the code that is weighing down the performance of the servers in a very significant way, which as I say I don't think is going to happen. I think, totally unfounded opinion, but I think one of the next steps they will take will be to eliminate the issue that the dinos move with UE5 pathing system and activate some switch for the officials to work in the old mode that is probably less expensive, since the issue that in officials the dinos remain static for many seconds, is something that has been spoiling the experience since day one, and is possibly one of the points where the hardware of the officials is not suitable.

There are many things wrong with the new cryopods. To begin with it doesn't make any sense that they are introducing them now in PVP. They are supposed to be coming early to alleviate the serious problem in PVE with the tame cap. Tame cap problems do not exist in PVP, they have the ability to purge dinos. In PVE as they have approached it, what they are going to do is to further worsen the coexistence on the servers. They will cause a privileged tribe to obtain the areas closest to the caves to be able to introduce the dinos they want, while the rest of the players who are not their allies will have to settle indefinitely to play in worse conditions. In addition, this brings collateral effects, since there will be no more sleeping bags at the entrances of the caves. That practice so normal in ARK is over, now unfortunately you will have to go far away, until you do not find structures of other tribes to place your sleeping bag. The issue of having to release cryos near a cryofridge does not displease me, it is consistent with the idea that the important thing now is to alleviate the load on the servers and reduce the tame cap. However I would go further: - I would only allow one cryofridge per tribe. - This cryofridge would have an activation time of 24h, so that it is not mobile. - The cryofridge would be 250 slots, and the dinos in cryopod would not count for the global tame cap of the server but would count for the limit of dinos per tribe. In this way the problem is solved, without giving unfair advantages to anyone and in the most similar way that the gameplay would be in an ideal server where there would be no need to implement this emergency measure.

What you want to do is implemented in Ark Smart Breeding, in the tab "Stat Testing". In the case of the deino, a 0 damage points hatched deino would be 125.8% dmg, a 55 damage points hatched deino would be 449.2%. From here you can calculate how much % dmg it gains per level: 449.2 - 125.8 ~= 323.4 <- total % damage gained with levels Divide then by the number of levels applied: 323.4 / 55 ~= 5.88 <- % dmg gained per level 449.2 + 5.88 = 455.08 == 455.1% <- rounded, this is the stat that you will see ingame for 56 dmg points. Bear in mind that the decimals are rounded in ark hud, so the calcs are not perfect accurate. I would just dont re-invent the wheel and would give it a try to ASB which fits perfectly with what you trying to do.

It does not make sense at all to release an event with dino colors and breeding rates while most of official servers are tame capped. I think you should hurry to release cryopods at least in pve.

Well, after searching and searching for information about this, I finally did what I should have done from the start, which is to check it out for myself. In case anyone is interested, they have replaced the Steam protocol with the EpicGames API, so to get the server status, requests have to be made to the API. The API is not public, and I haven't seen anywhere that you can request a key. However, very well known server metric services have been using it since the launch day of ASA without it seeming to be a problem for Wildcard. I would appreciate it if a moderator could ask and inform me whether I have permission to post an example of using the API that includes the key I found, or if they could shed some light on how to request a key for the API. In my case, for instance, it's to help a friend with his website for his ASE and now also ASA cluster, which shows the server status, players connected, ping, etc. I also use it for myself, to check the server status once I've disconnected from a map (very useful to know if the server crashes within 15 minutes of disconnecting, before saving).

Official 5193: 1 minute in dino breeding is 1 minute and 45 seconds in real time so basically the increased rates you applying are halved. Already reported, and indeed, reported also every day since days ago.

In ASE we could use Steam Query Protocol to get info (ping, users, name, and others..) of a server. Apparently this no longer works in ASA. What is the new method to retrieve that information and where is the documentation? Some sites like battlemetrics already have it implemented.

As far as I know a tool that can do this completely offline doesn't exists (yet).

sure, https://github.com/alez-repos/shrink-ark-saves It can be a bit complex if you are not familiar with the subject. If you get stuck at any point, let me know and I'll give you a hand and improve the documentation.

Thanks. The largest one I've completed is the one at position 44 with 2.4GB. There might be others slightly larger (up to 2.8 or 3.0GB) that are feasible given my computer's specifications (32GB RAM). I tried with valguero544, and my computer crashed after 3 hours, struggling with 79GB of virtual memory used. So, given my specs, I would need to adopt a different approach or just increase RAM amount. I did another program before discovering the json server option, to parse the save file and extract all the tribe IDs. However, unlike with the JSON, I didn't studied the save file format in depth to be able to determine how many structures each tribe has. Anyway, out of almost 1900 servers only 15 would be problematic for someone with 32GB of RAM. And also most of that top 15 list are PVP servers, so I assume that the vast majority of structures and dinos will belong to the server's alpha tribe.

Which server number, I want to see how much time it takes

Yes, I've seen some json up to 0.5GB but not really getting struggled when parsing it. I extract all the info from them in about 10-15 secs.

Yes, I use the -parseservertojson option then either RCON or 'exec' (depending on the tribe size) command to destroy the stuff.

I haven't been on the forums for a while but this couple of days I've been doing a little utility to clean up the maps and preserve that little piece of history that is my own bases and the ones of my friends on the official servers. Some examples of how it turned out: Server | Size in disk | Memory usage | Server save time | before after | before after after wilddinowipe | before after ------------------------------------------------------------------------------------------------------------------------------------------------------ Ragnarok 210 | 1.6GB 400MB | 18GB 10GB 2.4GB | 25s 0.7s Gen2 1008 | 2.5GB 187MB | 24GB 12GB 3.1GB | 35s 0.4s Mainly I have done this because I think that having to handle so much data that we do not need its not very environmental friendly, a waste of energy and computing resources (Wildcard, which from what I see has employees on twitter who do activism on a consistent basis, should have been more careful about this and been more responsible, facilitating it themselves), and also in terms of monthly expenses if we are going to deploy the servers at an external provider it is not optimal because, like Nitrado, they will want to charge us, rightly so, for a giant server. My utility extracts information from the save and removes everything that is not related to a list of tribes I want to preserve. It is almost fully automatic, relatively fast and secure. I don't know if there are people interested, or if there are other similar methods to clean the server in an almost unattended way and guaranteeing that everything is cleaned. At least from what I researched before I started programming my own utility is that what there was was compatible with saves prior to version 11. One of the ways to achieve something similar is to allow everything on the server to decay. But this is very inefficient, takes a lot of time (+80 ingame days due to structures like tek dedi-storage), and can also cause problems if we want to do it very fast and we have several bases to maintain and have to refresh them every few time cycles. If I see a lot of interest I might upload my utility for anyone who wants to use it, or create a discord server to support it. PS: While doing this I have seen some absolutely crazy things, for example in Ragnarok 210 there was one tribe with over 68000 structures, another with over 16000 cryoed dinos. It explains a lot why the servers were going the way they were going. I think it makes you wonder to what extent the developers shouldn't put some parameter in the official servers to limit this.

Gen 2 934, 935, 936, 937, 938 and Gen 2 Legacy 946, 947. All this 7 (7!) servers are on the same physical machine. When one of this servers crash it often drags all the other servers with it. Example of this morning: At 07:33 server 938 crashes. At 07:58 while 938 is not responding (crashed, crashing, generating dump, or even booting), all the other servers on the machine start crashing one after other This is just a real example of this morning. This exact same behaviour is happening 10-15 times a day on this machine. When one server crashes it grabs all the other servers on the same machine with it. I would speculate about this is some memory leakage on the crashing server that hog the resources of the machine until every server crashes, result of limited shared resources (RAM) of the physical machine. But this is just speculation. What is clear is that until you take a look at it and move some server to another machine or increase the shared resources this situation is not gonna improve. Please do it soon so we can enjoy gen2 without being worried all the time about if we can do x thing because it may crash or not. @lilpanda @Cedric