Listing artistic species in Pedia

[wobbly]

So I noticed there's a pedia page for Artistic Species now. I don't remember that being there, maybe was added by St-pa-fo. I'd like to list the artistic species on this page. I guess there are 2 choices of format:

• Species that have: This would look like the species that like/dislike on the policy page
• Artistic Species list: i.e. like the metabolism lists etc. under species

My preference is the 1st. Either way it seems I can't just do this in FOCs. Is that correct? I'm not very familiar with C++, but I could probably work it out. Species that like is done with:

Code: Select all

 // species that like / dislike part
        auto species_that_like = GetSpeciesManager().SpeciesThatLike(item_name);
.
.
.

and a corresponding part elsewhere. So for doing species list for traits that would be something like GetSpeciesManager().SpeciesThatHave(trait_name)? with a corresponding part that picks up artistic, telepathic or xenophobic in FOCs?

[Ophiuchus]

As traits do not exist, you ask to filter species by tag. Not sure how that is done best in C++/our backend.

I guess I would prefer a generic way to get the tags and apply a filter function on use site on that as opposed to a specalised e.g. getSpeciesByTag function.

[Ophiuchus]

Either way it seems I can't just do this in FOCs. Is that correct?

there is no FOCS used inside the pedia besides the named value refs;

if we had a type for a list of strings, we could probably use a named value ref to save it and reference it from the pedia.
we currently do not (officially) support non-constant value refs, but i guess such a global search for a tag of all species in the current universe would work in-game (but not in the starting page, where there is no universe).

having such support for referencing (computed) lists of strings would be certainly good to have, also for reuse in FOCS scripting. one can use macros to reuse that in some cases, but not always.

tl:dr; so currently i think it is not possible in FOCS.

[stpa]

looks to me like this can totally be done in focs alone. see screenshots attached.

edit; oh wait no. right. little tiny bit of c++ would be required indeed.

[Ophiuchus]

looks to me like this can totally be done in focs alone. see screenshots attached.

edit; oh wait no. right. little tiny bit of c++ would be required indeed.

actually not sure what you show in the screenshots (which seems to be concerned how its done for playable species?).
OP is about artistic species; there is no concept of "artistic" in the backend.
but it should be easy to add something to filter species by tag name (if it does not exist).

[wobbly]

Either way it seems I can't just do this in FOCs. Is that correct?

there is no FOCS used inside the pedia besides the named value refs;

if we had a type for a list of strings, we could probably use a named value ref to save it and reference it from the pedia.
we currently do not (officially) support non-constant value refs, but i guess such a global search for a tag of all species in the current universe would work in-game (but not in the starting page, where there is no universe).

having such support for referencing (computed) lists of strings would be certainly good to have, also for reuse in FOCS scripting. one can use macros to reuse that in some cases, but not always.

tl:dr; so currently i think it is not possible in FOCS.

Is there a general plan for how pedia changes shoud be handled? I've only briefly looked at how the pedia works, but at 1st glance it seems a lot of it is embedded into the source code, rather then out in the edit files.

[Ophiuchus]

Is there a general plan for how pedia changes shoud be handled? I've only briefly looked at how the pedia works, but at 1st glance it seems a lot of it is embedded into the source code, rather then out in the edit files.

i guess do what is possible in the text/pedia files and do what is necessary in c++

we dont have a handling of list of strings etc in the pedia.
one could probably implement a stringtable tag for listing e.g. species with a certain tag, or even better list species chosen by named conditions (which also do not exist).

but if no one does that, hard coding the pages/listing is ok. it is more important to have the content shown than how that is done. I am not sure the hardcoded stuff would work for a different pedia "client" (e.g. godot or html).

[Oberlus]

it is more important to have the content shown than how that is done

I think that is agreeable by anyone. But it is also important the how, if it affects how much work a contributor can get out per hour or if it affects for how long will that contribution be valid.

[Ophiuchus]

it is more important to have the content shown than how that is done

I think that is agreeable by anyone. But it is also important the how, if it affects how much work a contributor can get out per hour or if it affects for how long will that contribution be valid.

i think hard coding it in the backend code is fast/not much work (for someone with a c++ background). the important work for the pedia is structuring and finding out what to show where, so if we have better solutions it will be fast to migrate if it is already coded in some way.

for the other solutions; named conditions will also be a real pain to implement; last time i fiddled with tags it was quite complicated and took quite long (was to show named values in the pedia/stringtables)

[wobbly]

It can be done in FOCs ... almost ....

Code: Select all

    /** @brief Checks content tags for a custom defined pedia category.
     * 
     * @param[in,out] tags content tags to check for a matching pedia prefix tag
     * 
     * @return The first matched pedia category for this set of tags,
     *          or empty string if there are no matches.
     */
    std::string_view DetermineCustomCategory(const std::set<std::string>& tags) {
        // for each tag, check if it starts with the prefix TAG_PEDIA_PREFIX
        // when a match is found, return the match (without the prefix portion)
        for (auto& tag : tags) {
            if (boost::starts_with(tag, TAG_PEDIA_PREFIX)) {
                //return boost::replace_first_copy(tag, TAG_PEDIA_PREFIX, "");
                std::string_view retval{tag};
                retval.remove_prefix(TAG_PEDIA_PREFIX.length());
                return retval;
            }
        }

returns the first matched pedia category:

So laenfa can either be phototrophic species or ... fuel parts
Its probably pure luck that sly are gaseous species and not ... fuel parts

Probably doesn't need many changes in EncyclopediaDetailPanel.cpp to get it to work automatically. At least I hope.

Edit: Other relevant bit:

Code: Select all

 // species
            for (auto& [species_name, species] : GetSpeciesManager())
                if (dir_name == "ALL_SPECIES" ||
                   (dir_name == "NATIVE_SPECIES" && species->Native()) ||
                   (dir_name == "PLAYABLE_SPECIES" && species->Playable()) ||
                    DetermineCustomCategory(species->Tags()) == dir_name)
                {
                    dir_entries.emplace(
                        UserString(species_name),
                        std::pair{VarText::SPECIES_TAG, species_name});
                }

[Geoff the Medio]

it is more important to have the content shown than how that is done

If it involves hard-coding in C++ a particular bit of scripted content, then it probably isn't acceptable...

Regardless, rather than DetermineCustomCategory(species->Tags()) == dir_name, a function returning a bool like HasTagWithPrefix(species->Tags(), dir_name) or HasTagWithSubstring(species->Tags(), dir_name) might be part of a solution. It would check all the passed-in strings to find if any have the specified prefix or substring and return true/false if there is one, rather than return the first of the tags that start with PEDIA_.

Or rather, HasCustomCategory(species->Tags(), dir_name) and HasCustomCategory(species->Tags()) that both call DetermineCustomCategories(tags).

https://github.com/freeorion/freeorion/pull/3707

[wobbly]

Thanks Geoff!

Shiny (except for the species species trait bit):

Artistic.png (267.99 KiB) Viewed 1379 times

Not so shiny:

Fuel.png (42.49 KiB) Viewed 1379 times

[Geoff the Medio]

So I should commit that for now and the details can be fixed later?

[wobbly]

Is working for me. (Haven't played just compiled and looked through pedia). I'd say yes.

[Geoff the Medio]

Did you add something else to get the artistic species article to have the list and working icon? I just get the article text and an error on the command line about the artisans icon being missing, since it's been renamed to social_artisans.png