Possibility to disable certain Creature Groups, that can't spawn/can't be tamed.

[Pingger]

Hi,

I recently ran into the issue described in #1097. To prevent this from happening again I went into the values.json and removed all Creatures, that can't spawn on the Servers I play on and removed all Creatures that can't be tamed.

I propose

A feature to disable entire Creature Groups, so that the OCR and the Search no longer show/select them.

Example

Add a setting that looks like this:

• [ ] Abberant
• [ ] Extinction
• [ ] Ragnarok
• [ ] Scorched Earth
• [ ] The Center
• [x] The Island
• [ ] Valguero _
• [ ] Untameable
• [ ] Alphas

Why this should be considered?

To prevent issues like #1097 from occuring...

Greetings

[coldino]

Your values.json changes will be overwritten as soon as the next change appears on the server.

On the data-extraction layer we investigated the species you reported and found it was evading some of our checks and auto-variant marking mechanisms. As it turns out there were Easy/Medium/Hard versions of this species plus a base-class that should never be accessible. Our fix was to ensure the correct Minion variant is added to each of the Easy/Medium/Hard versions and to remove the base-class species entirely from the data. This improves your situation a little and should be present in the live data already.

That said, the core idea here is a decent target and something that should be discussed.

Untameable

This is probably the most useful group suggestion but also hardest to implement. There is already a "Display non-domesticable species" checkbox in the species selector that should be helpful, but it is not perfect as we simply do not have a foolproof way to detect tameability from the Ark data.

Perhaps the biggest win is to simply improve this check-box. Maybe @cadon can comment on whether it would be possible to extend this tick-box functionality to also exclude a list of variants: Minion, Boss, Corrupted, VR, Retrieve, Gauntlet, Sport, Race, Cave, LifeLabyrinth - and I'm sure there are more.

Alphas

This is something we have not attempted to detect yet. The game uses a mixture of Mega and Alpha, with Alpha also referring to boss difficulty, and once you consider mod support you cannot simply look for Alpha in the name. Open to suggestions.

DLCs

Sadly this not simple. A large percentage of the species included in DLCs actually reside in the core game with nothing to distinguish them - not even blueprint paths. Again, open to suggestions.

Background info for the OP: The data extraction project is arkutils/Purlovia and the data is posted daily to arkutils/Obelisk.

[cadon]

Would it be helpful to remove / ignore all variants or just a specific group of them, i.e. is there a variant that should not be removed?

I'll improve the way a species is selected via a name so non-variants are preferred over variants.

Another solution could be an ignoreSpecies.json-file with a list of blueprint paths that should be ignored totally when opening the application.

[coldino]

There are certainly variants that are valid and tameable. Off the top of my head Snow, Ocean, etc, but I expect there are more.

[Pingger]

DLCs

Sadly this not simple. A large percentage of the species included in DLCs actually reside in the core game with nothing to distinguish them - not even blueprint paths. Again, open to suggestions.

So ... the simple checks for

• BP Name ends with "BP_Abberration" (Abberation exlusive creatures)
• BP Path is in "Extinction" (Extinctionexclusive creatures)
• BP Path is in "Genesis" (Genesis exclusive creatures)
• BP Path is in "ScorechedEarth" (ScorechedEarthexclusive creatures)
• BP Path is in "Valguero" (Valguero exclusive creatures)
• BP Path contains/is in god knows what (no longer have a full values.json to check what the other blueprint paths where, that I used for the regex to remove them ...)

do not work? Because for me they do ...

[cadon]

Some species can be sorted out that way. Counter examples to that are

• "Blueprint'/Game/PrimalEarth/Dinos/CrystalWyvern/CrystalWyvern_Character_BP.CrystalWyvern_Character_BP'" (DLC Crystal Isles)
• "Blueprint'/Game/PrimalEarth/Dinos/Raptor/Uberraptor/Deinonychus_Character_BP.Deinonychus_Character_BP'" (DLC Valguero)
• "Blueprint'/Game/PrimalEarth/Dinos/Griffin/Griffin_Character_BP.Griffin_Character_BP'" (DLC Ragnarok, Crystal Isles)

Aside from that, is the species selection of the OCR working in 0.40.5 now, e.g. does it select the correct dimorphodon variant?

[coldino]

Plain text matching has been done in ASB before, and it resulted in a mess of exclusions and exceptions. It would have been totally unmanageable when mod support was added. Additionally, most of your suggested options miss out significant species from the DLCs. Think Valguero's Deino, Rag's Griffin, etc, and cannot be used when you consider modded species use these phases frequently.

We have a cleaner system to achieve this - the variant system. We already provide variant detection for Corrupted, Aberrant, Valguero, Ragnarok, bosses, minions, mission-specific, biome-specific. I suggest we could extend the existing variant system to include the missing DLCs. It cannot do them all automatically (e.g. Deino, Griffin and others), but with help we can find and mark all of the outliers.

I suggest ASB's UI could be extended to allow disabling selectively some groups of these variants:

• Valguero: Valguero
• Ragnarok: Ragnarok
• Aberration: Aberration*
• Extinction: Extinction*
• Genesis: Genesis*
• Scorched Earth: ScorchedEarth*
• CrystalIsles: CrystalIsles*
• Untameable: Corrupted, Boss, Minion, Mission, Cave, Mega*

Variants with stars will be added in the next data release. Mega is what we'll have to use for Alphas, as Alpha is used to label boss difficulty.

[Pingger]

Then again I'm wondering why these special exception, that exist most probably because the ARK Devs once again have no proper organization, can't be manually set in the central values.json ... maybe just add another git repo, so people could contribute to it?

Or even more automizable: Just use the wiki for (additional) data extraction? (I am aware, that probably most of the values in the wiki are provided by the data extraction project, but why not share the information bidirectionally?) If I'm not mistaken, all missing properties can be found there! Properties I found:

• Blueprint Path
• Variants
• Base Stats
• Wild Level up behaviour
• Tamed Level up behaviour
• Taming Boni
• To which DLC they belong
• On which Maps they spawn
• tameability
• Taming Method
• Ridability
• Breedability
• Torporimmunity
• Color Regions and possible values
• Required Taming Foods
• Preferred Taming Foods

Properties I did not find:

• breeding cooldowns
• maturation durations

For the question if it works with the new release: I need to check that tomorrow ...

[coldino]

All of this data on the wiki already comes from our data extraction project, and the project that came before.

[Pingger]

All of this data on the wiki already comes from our data extraction project, and the project that came before.

if it is, then you CAN actually check on which Island(s) the specific Creature spawns, which contradicts the previous Statement:

DLCs

Sadly this not simple. A large percentage of the species included in DLCs actually reside in the core game with nothing to distinguish them - not even blueprint paths. Again, open to suggestions.

_

Aside from that, is the species selection of the OCR working in 0.40.5 now, e.g. does it select the correct dimorphodon variant?

Yes it looks like it. I also now configured a nextcloud share to which the current savegame is uploaded, so I can just simply import from there.

(with autosave interval set to 1 minute and a cronjob running this script:

nextcloud_path=https://nextcloud.iskariot.info/remote.php/dav/files/<username>/<path>/<in>/<account>/ARK/SmartBreeding/Savegame
nextcloud_username=<username>
nextcloud_password=<password>
# Path to Savegame:
cd /mnt/nfs/storage_01/ark_ds/ShooterGame/Saved/SavedArks;
curl -T TheIsland.ark -u ${nextcloud_username}:${nextcloud_password} "${nextcloud_path}/TheIsland.ark";

find . -type f -name \*.arktribe | while read x;do filename=$(basename $x); curl -T $x -u ${nextcloud_username}:${nextcloud_password} "${nextcloud_path}/$filename";done
find . -type f -name \*.arkprofile | while read x;do filename=$(basename $x); curl -T $x -u ${nextcloud_username}:${nextcloud_password} "${nextcloud_path}/$filename";done

)

[VolatilePulse]

I think what you're failing to understand is that the Wiki isn't fully automated. The information that the wiki uses is hand tailored by the admin and other users based off of the data that we provide. A lot of time the pages are only modified when someone raises an issue within the pages discussion or on their Discord. When a new species is added to Ark, they look at the data that we provide and they write the description up and regular users are free to modify the rest of the page. They're more interested at the moment with the loot tables, spawn regions, etc. that we provide them since the species data is not automated on the wiki.

Due to the sheer volume of data that we automate, we can not reasonably look through everything by hand every time something is changed in Ark. Per coldino's response regarding the DLCs, the species he was referring to are ones that are within the core game directory, PrimalEarth, and can't be easily distinguished by other means. It's easy to separate a species that has a different core directory, like ScorchedEarth, but Wildcard isn't always consistent with their organization of assets. If you have any suggests on ways we could accurately separate the species automatically, we're always open to suggestions. And no, grabbing data from the wiki is not only not practical, they tend to be significantly further behind with their information. We were the first program to support Genesis and Crystal Isles that we are aware of as the moment it launched, we had species data within an hour.

In regards to using the save game import in ASB, all of this becomes a moot point. By far, this is one of the most accurate systems ASB has to offer, but it's unfortunately not available to everyone. This would alleviate the issue that you initially opened the issue for. We're always trying to find ways to improve the user experience in ASB, but it can be rather difficult having to support so many different features and versions of Ark.

I hope this helped clarify some things for you. Any other questions you have, feel free to ask.

[Pingger]

I am very aware of how a wiki works. I am also very aware of the lackluster organization inside the ARK Assets ... I also already understood that some creatures are placed in the core game folder, while they should actually be in the dlc folders...

So I guess it is

1. not feasible to add text telling the user, that the Data for which creatures spawn on which map is community provided and still adding that information from the wiki (other games already do stuff like this)
2. not feasible to go through a. the map files b. iterating through the spawn regions c. through the spawn groups (up to this point, the data is in the wiki and it has to come from somewhere. it is also detailed enough, that I don't think it was done manually!) d. through the seperate spawns and accumulating the Blueprint-Paths in a Set e. then using the Set for each map to provide the information to the blueprints, where they spawn...

This honestly looks to me like you are grasping at every tiny bit to not support the feature and instead try to run me in circles?! I honstely hat working with Python as it makes in many places no sense and additionally the package-creep is just extreme. Throw me the extraction project in C, C#, Java or even ShellScript and I would contribute to it, but Python is just ugly and not performing well ...

[coldino]

I don't know if you've been reading but we've already put in a huge amount of work to support both your requests and many, many more before. We are volunteers, doing this for enjoyment. We welcome contributions, but this topic is done.

[Pingger]

1. Q.E.D. (https://github.com/cadon/ARKStatsExtractor/issues/1100#issuecomment-667696117)

2. I do understand that you are volunteers. I tried to give you points, where you could get the information using simple API requests or where you would find the required Data in gamefiles, trying to contribute useful information and efficient ways to implement the filter(s). YOUR Part coldino was mostly to disregard anything with "reasons" that don't have anything to do with the issue at hand, which is why worte that last paragraph in my previous comment (https://github.com/cadon/ARKStatsExtractor/issues/1100#issuecomment-667662346).

3. I did read what you wrote, which is exactly the reason why I am responding the way I do. Despite the checkbox to hide creature variants, you only discussed what might work, but mostly disregarded that a few comments later. The referenced commit e859042a20fba47715277f202a40192cf5ba67d4 doesn't look like much work for someone familiar with the code, which speaks of good codemanagement, but not of a "huge amount of work".

4. Regarding https://github.com/cadon/ARKStatsExtractor/issues/1100#issuecomment-666875412 DID YOU EVEN READ WHAT I WROTE?! "(I am aware, that probably most of the values in the wiki are provided by the data extraction project, but why not share the information bidirectionally?)" ... "[because it is] significantly further behind with their information". You completly disregarded, that a simple "hey this information might not be 100% accurate. Go to the wiki to improve it."-notice would even make people go there and help build the wiki. Despite that you are already using similar notices at other locations in ASB...

5. To what VolatilePulse wrote (https://github.com/cadon/ARKStatsExtractor/issues/1100#issuecomment-667430989): I AM AWARE, that a wiki is a community driven project to provide information on a specific topic, in this case the game ARK. But this wiki makes good use of wiki templates allowing for simple API requests, that allow getting the required information from it quite easily and in a way, that can easily parsed programmatically, definitely easier than the ARK gamefiles, as the API responses are human-readable.

6. Also are so harddriven on the example I gave in the OP. I agree, that the untameable filter would be the most useful, but I don't see why Map specific filters should be any less useful? Most players only play on a single Map at once and therefore wouldn't even need the creatures from the other maps. I also somewhat understand that the "Alpha"-detection might be hard even though they are easily identified by the Buff-Effect each one has (the one that triggers the orange smoke), that could be parsed.

7. But as I have said in 1. "Q.E.D." you've proven my point exactly with this comment https://github.com/cadon/ARKStatsExtractor/issues/1100#issuecomment-667696117. So I will consider this discussion dead. And will set this issue on the blocklist to not receive notifications on it again, so I'm not tempted to reply to it again.

Have a nice day and sorry if I sound rude, but I do hope, that I don't meet you (coldino) again on a project more important than a game related Tool ...

[cadon]

Pingger, you're right that a lot of your suggestions are possible and you also wrote how to achieve them. The issue might be that it sounded a bit like "Here's what I want, this is how it can be done, now please do it, it's not hard". In the end it sounded for me like you're our boss giving orders on what we should work next.

Extracting all the data is complex. Looping through all maps and spawning areas and your other suggestions might be a solution to identify the variants of species, but it's a lot of data and I expect ARK to have exceptions that need to be considered. Currently I don't feel this extra bit of information is worth all the work. A lot of variants are added already in the data for ASB. Also a method to add custom variants to species will be in the next release. Adding more info to ASB would also require to present that data in an informative way. It's all not impossible, but someone has to do it, even if it looks simple in the end. We're glad about suggestions and if we like them and find the time, we might implement them.