sorry, got confused. i thought you were talking about the translator, but you were talking about augmentation.

i am not sure that Species is enough... Species might be set even if population is zero.
So population > 0.001 might be better fix.

lots of stuff which does not directly apply because of my confusion, but might restart discussion of when stuff may be enqueued.:

I think the use case is that you can start building universal translator before or parallel to colonizing. 
I'd classify as feature, not bug.

Helping people not shoot in the foot would be an improvement.
We could switch the Uninhabitable condition to checking if pop>0 or a colony building is enqueued or a marker building is enqueued or finished.
That 0PP marker building would designate the outpost for colonisation and would allow buildings like the translator to be enqueued.


> To reproduce:
>     * The focs.txt format is planned to be deprecated, right? This test would be `HasSpecies()` instead in focs.py, a regrettable divergence.

you mean that it is not called Species? That is mostly for technical reasons and not a problem. The new parser is not as powerful as the old one, so we can not reuse tokens - there is a Species valueref and a Species condition, so in python one has to write (e.g. Source.Species) and HasSpecies.

We could probably skip the marker building; the main case is similar to advanced shipyards: not having to revisit a planet to apply orders.
Also applying the advanced shipyard solution could make sense (allow enqueue, but deny build unless there is pop>0)
this needs *short* forum discussion/decision

feature - before or parallel to colonizing

I disagree. Doesn't fit the pattern of existing buildings that can be built on an outpost-only, nor does the description state it can be built on outposts (iirc most such buildings say so), nor does it fit that you can't pre-colonization build translators without Augmentation. Also, fits narrative.

shown in the colonization preview

What's that... The pedia entry "Planet Suitability" showing encyclopedia/EP_wheel.png I guess. Correct, that would likely "break" with this patch. Will need investigation. My mental model was so clear - "having a target pop > 0 when there aren't any actual people there makes no sense" - but for that preview that's another matter. That would mean all buildings checking target pop would need to be re-evaluated. I had already tested that variant, but the fix here seemed cleaner, as it would cover all candidate buildings... I count 14 plus the terraforming variants. Also - if they didn't additionally have a stability filter / focus filter, Augmentation would make the techs nascent ai, adaptive automation, sentient automation apply to unsettled outposts too...

population > 0.001 might be better

I'd actually advocate >= 1, at least considering the translator, though that might need some broader consensus. Also, precedents are using low=0.0001, one zero more 🤪. Actually, you can experience that in-game, though it's very hard to provoke the situation: Don't focus any growth specials, don't research any target population increasing techs, don't research cryo, and find a planet with the gaia special. Colonize it - pop will drop below 1 right on its first populated turn, and you'll notice a whole bunch of buildings can't be queued though you normally would be able to, you'll have to wait for the auto-terraform to kick in enough to allow pop to recover. Even makes kinda sense IMHO.

iirc most such buildings say so

Actually, that's the BUILDING_AVAILABLE_ON_OUTPOSTS macro, and some outpost-enabled ones don't include it - I can name starlane bore or nexus, maybe others? Edit: this led to #5315.

shown in the colonization preview

I was wrong, this works just fine with both the "Planet Suitability" page and the Colonize(x/y) label of the colony ship's button:

        EffectsGroup(
            scope=IsSource,
            activation=Turn(low=4, high=4),
            effects=[
                GiveEmpirePolicy(name="PLC_AUGMENTATION", empire=Target.Owner),
            ],
        ),

... though honestly, I don't really understand why.

shown in the colonization preview

I was wrong, this works just fine with both the "Planet Suitability" page and the Colonize(x/y) label of the colony ship's button:

Early game, with availability of Augmentation cheated in via the species file:
... though honestly, I don't really understand why.

This does a normal effect application for the calculation in the background, so it has to have the right species on the planet. Not sure if it opens a mini-universe with a single planet or uses the respective colony.
So Species condition should work there.

...got intrigued RefreshDetailPanelSuitabilityTag, it fetches the current planet. not sure about the universe/context though

void RefreshDetailPanelSuitabilityTag(...
auto& universe = context.ContextUniverse();
auto& objects = context.ContextObjects();
auto planet = objects.get(planet_id); // non-const so it can be test modified to check results for various species
int planet_id = ToInt(item_name, INVALID_OBJECT_ID);
const auto target_population_species = SpeciesEnvByTargetPop(planet, species_names);

And SpeciesEnvByTargetPop remembers original values, disables notices, for each species: sets temporary values and does the calculation; afterwards sets the original values; enables notices

        universe.InhibitUniverseObjectSignals(true);

        for (const auto species_name : species_names) { // TODO: parallelize somehow? tricky since an existing planet is being modified, rather than adding a test planet...                                                                
            // Setting the planet's species allows all of it meters to reflect                                                                                                                                                              
            // species (and empire) properties, such as environment type                                                                                                                                                                    
            // preferences and tech.                                                                                                                                                                                                        
            // @see also: MapWnd::ApplyMeterEffectsAndUpdateMeters                                                                                                                                                                          
            // NOTE: Overridding current or initial value of MeterType::METER_TARGET_POPULATION prior to update                                                                                                                             
            //       results in incorrect estimates for at least effects with a min target population of 0                                                                                                                                  
            try {
                planet->SetSpecies(std::string{species_name}, context.current_turn, context.species);
                planet->SetOwner(empire_id);
                universe.ApplyMeterEffectsAndUpdateMeters(planet_id_vec, context, fa

From that source dive I would expect that my suggestion (pop >0.001) would not work in the DetailPanel.

regarding the UI I think in the last discussion we settled for: colonization is an important event, it is fine to demand the player has to have a look at the colony (instead of prequeueing build items).

Not sure if it opens a mini-universe with a single planet or uses the respective colony.

Ah, yes, that immediately sounds right. Reminds me of how Unciv treats or treated some question "can I do something here" by cloning and modifying the context - only the modification could not be done without nefariously elusive side effects without cloning the entire game state, so that led to a lot of effort...

only the modification could not be done without nefariously elusive side effects without cloning the entire game state, so that led to a lot of effort...

yeah. it does apply meter changes, so that is the only kind of side effect which can happen. It probably is also restricted to the given target and the effects are not propagated.

But probably if you change some unexpected meters this will create side effects in the client state, the reset is ad-hoc and only for some meters.

it would be cool if you could playtest this. dunno by increasing stealth and max stockpile by 100 in the augmentation effect. and looking multiple times at the planet. but on the other hand i think we would have noticed this...

By chance I just came across that same "sim" code while investigating

ghost fleets:
... which I suspect is due to that very same SetOwner applied to en-route ships not copying the trajectory properly... But haven't had any inspiration yet on how to fix that. Mod-only, trying a "Snowflake in the Ice" special that yields a variant that can grow into a Psionic Snowflake. And owning one of those produces those quirks - but when the Experimentors own them it's not much better, just less observable.

Make an issue and include a minimal content script modification and test save that uses it?

Make an issue

That was half the point - haven't got a clear enough picture yet. I may get there eventually...