Fix unreachable milestones

[veger]

When I create a new project with the (full) Pyanodon mods, I get the error that "Py science pack 4", "Utility science pack" and "Space science pack" are not accessible.

As far as I can see, this is not the correct behavior for the mod-suite and the 3 milestones are reachable in-game doing research.

After adding debug info (see commit d2d8949d182372f259c6bd5faf396ff7fb519034) and some analysis, I found that quite a lot (group) dependency lists are empty:

Unexpected: void (2) [Special] - Source group deps empty, will cause unreachable elements
Unexpected: tar-patch (14574) [Entity] - ItemToPlace group deps empty, will cause unreachable elements
Unexpected: natural-gas-seep-mk01-base (14900) [EntityCrafter] - ItemToPlace group deps empty, will cause unreachable elements
Unexpected: tar-seep-mk01-base (14901) [EntityCrafter] - ItemToPlace group deps empty, will cause unreachable elements
Unexpected: bitumen-seep-mk04-base (14927) [EntityCrafter] - ItemToPlace group deps empty, will cause unreachable elements
Unexpected: bitumen-seep-mk03-base (14928) [EntityCrafter] - ItemToPlace group deps empty, will cause unreachable elements
Unexpected: bitumen-seep-mk02-base (14929) [EntityCrafter] - ItemToPlace group deps empty, will cause unreachable elements
Unexpected: bitumen-seep-mk01-base (14930) [EntityCrafter] - ItemToPlace group deps empty, will cause unreachable elements
Unexpected: mining.ore-nexelit.ore-nexelit (13100) [Mechanics] - CraftingEntity group deps empty, will cause unreachable elements
...
Unexpected: auog-food-01b (10757) [Recipe] - TechnologyUnlock group deps empty, will cause unreachable elements
Unexpected: uranium-fuel-cell-mk02 (12134) [Recipe] - TechnologyUnlock group deps empty, will cause unreachable elements
Unexpected: abacus (12623) [Recipe] - TechnologyUnlock group deps empty, will cause unreachable elements
Unexpected: auog-paddock (12841) [Recipe] - TechnologyUnlock group deps empty, will cause unreachable elements
Unexpected: kicalk-plantation (12842) [Recipe] - TechnologyUnlock group deps empty, will cause unreachable elements
Unexpected: zipir (12843) [Recipe] - TechnologyUnlock group deps empty, will cause unreachable elements
Unexpected: uranium-processing (9910) [Recipe] - TechnologyUnlock group deps empty, will cause unreachable elements
Unexpected: blackhole (12844) [Recipe] - TechnologyUnlock group deps empty, will cause unreachable elements

The cause I do not know, as I do not fully understand the 'parser code', so my solution (work-around I guess) is to not add the empty groups in the dependency collector.

Now a new project is created fine, and the added (default) milestones are all reachable, and so are lots of elements that were not reachable before (in my actual, non-empty project)

[DaleStan]

I think this PR gets the wrong answer in a few cases. With this change, YAFC decides the natural-gas-extractor-mk0#, oil-derrick-mk0#, and tar-extractor-mk0# entities are accessible. I've never gotten more than a couple hours into a Pyanodon playthrough, but sandbox mode makes me think those entities should be inaccessible. I'm guessing (incorrectly) these are deprecated entities that have been replaced by natural-gas-seep-mk0#, bitumen-seep-mk0#, and tar-seep-mk0#?

I've pushed an alternative solution, as #209. Would you check and see if that PR has any problems I've missed, please?

[veger]

Thanks for checking this out. I am also reasonable new (50-ish hours) to pyanodon (especially since I run into issues with YAFC that need fixing for me to continue :stuck_out_tongue: )

But when I check the research tree (in-game) and search for 'derrick', it shows that the 'Small oid derrick' is unlocked with the 'Drilling fluid - Stage 1' technology. The others you mention are part of the same technology as well.

In order to figure out this PR, I followed the dependencies of the unavailable science(s), and saw that 'numal' was not available ,because of its 'artificial reef' were unavailable. (also having those magic placers you mention in #209). I found that some of the optional dependencies (lists) were empty, causing not dependencies being available resulting in YAFC deciding the object is not available. Which is wrong IMO, as an empty dependency list would mean there are no dependencies to require the object..!

Note that the objects you mention and the numal-reef-mk0# are all in the pypostprocessing mod (/pypostprocessing_0.2.4/prototypes/config.lua). So maybe due to some magic there, YAFC doesn't handle them properly? I could not really find the cause of the empty optional dependencies though. So this PR is more of a workaround.

Then I found 'empty lists' were used for some 'magic', hence the updates of this PR and adding exceptions for those flags... I am on the fence when choosing between #209 or this PR:

• this PR is a generic solution and doesn't need to add special mod support, but might cause other issues due to changing the dependency handling slightly

• 209 is more clear and less error-prone (I guess, as I am not certain this is 100% working, due to the issues I found later). Although I don't know the side-effects of getting rid of the 'placers'... (I never got this far in a play-through, so I don't know if those are actual things, or just some behind-the-scene magic) Also, this change breaks, if the mod author decides the replace the 'placers' by some other logic/scripts/black-magic to support their ideas on the mods and how they should function (again, I have no idea about the placers and how they show up in the game as I never reached this far into the mods)

[DaleStan]

Dependencies

My interpretation of "empty dependency list", in the context of the current numal-reef problems, is "You must have access to at least one of these zero items in order to build a Numal Reef." Technically, but also uselessly, this is correct. Searching for place_result\s*=\s*['"]numal-reef finds four items in PyAE, all of which produce one of the four placer entities. Unpatched, YAFC reports that the four reef entities are accessible, but not the four useful entities. (The same applies to the tidal power plants.)

I decided that the placers were just behind the scenes magic based partly on

[entity-description]
numal-reef-mk01-placer=Please if you're reading this you have to send help they're going to find me I'm not sure how long I have

and partly based on the code in PyAE's control.lua, starting at line 68.

But I didn't notice the placer items in pypostprocessing, and now I don't like my solution as much. I don't want to go back to the version that explicitly listed the eight placers, but I don't want to break trainfactory either.

Accessibility

I had to turn on the show-debug-info-in-tooltips options to make sure I knew what I was seeing in-game, and to correctly compare things to YAFC. (And, spoiler alert, learned I was wrong and #209 is definitely incomplete.)

I updated command-line example to load mods and print out the inaccessible items:

File.WriteAllLines("inaccessible.207.txt", Database.objects.all.Where(o => !o.IsAccessible()).Select(o => o.typeDotName).OrderBy(a => a));

And I got this list of objects that are accessible in #207 but not in #209

```diff --- inaccessible.207.txt 2023-02-18 18:42:57.862503200 -0500 +++ inaccessible.209.txt 2023-02-18 18:42:19.661592700 -0500 +Entity.bitumen-seep-mk01-base +Entity.bitumen-seep-mk02-base +Entity.bitumen-seep-mk03-base +Entity.bitumen-seep-mk04-base +Entity.ee-infinity-accumulator-primary-input +Entity.ee-infinity-accumulator-primary-output +Entity.ee-infinity-accumulator-secondary-input +Entity.ee-infinity-accumulator-secondary-output +Entity.ee-infinity-accumulator-tertiary-buffer +Entity.ee-infinity-accumulator-tertiary-input +Entity.ee-infinity-accumulator-tertiary-output +Entity.ee-infinity-loader-inserter +Entity.hawt-turbine-mk01-blank +Entity.hawt-turbine-mk02-blank +Entity.hawt-turbine-mk03-blank +Entity.hawt-turbine-mk04-blank +Entity.hidden-electric-energy-interface +Entity.multiblade-turbine-mk01-blank +Entity.multiblade-turbine-mk03-blank +Entity.natural-gas-extractor-mk01 +Entity.natural-gas-extractor-mk02 +Entity.natural-gas-extractor-mk03 +Entity.natural-gas-extractor-mk04 +Entity.natural-gas-seep-mk01-base +Entity.neutron-absorber-mk01 +Entity.oil-derrick-mk01 +Entity.oil-derrick-mk02 +Entity.oil-derrick-mk03 +Entity.oil-derrick-mk04 +Entity.pydrive_skin +Entity.solar-tower-building +Entity.tar-extractor-mk01 +Entity.tar-extractor-mk02 +Entity.tar-extractor-mk03 +Entity.tar-extractor-mk04 +Entity.tar-seep-mk01-base +Item.ee-infinity-accumulator +Mechanics.boiler.solar-tower-building.hot-molten-salt +Mechanics.mining.ore-nexelit.ore-nexelit +Recipe.ee-infinity-accumulator-pyvoid ```

Some are better in 209: The Editor Extensions infinity accumulator should not be accessible. Some are better in 207: We both agree that Entity.bitumen-seep-mk0#, the entities that consume mining fluid and produce nothing, are accessible, but Entity.oil-derrick-mk0#, the entities that actually produce crude oil, are only accessible in 207. And some are wrong in both: Neither of us have Mechanics.mining.natural-gas.natural-gas-mk0# or Mechanics.mining.oil-mk0#.oil-mk0# automatically marked as accessible.

(On the one hand, Pyanodon is why I have YAFC in the first place. But on the other hand, Augh!)

[veger]

I have been looking for issues with creating natural gas, but it all seems to be there:

• recipe to pump up raw gas (fluid.raw-gas) using pump jack (pumpjack-mk0#)
• recipe to refine it into natural gas ( fluid.natural-gas) using compressor (compressor-mk0#) So even the mechanic mining.natural-gas.natural-gas-mk0# is not available the natural gas is accessible. Depending on what pyanodon mods are active objects are disabled. So maybe this mechanic is disabled for the full mod-suite?

Crude oil can be mined as well (recipe.oil-01), as well as obtained via the alien life route (manure) and petrochemical (I guess) via taillings.

I cannot seem to find raw oil, but this is vanilla Factorio, so I guess it is removed by the mod suite?

(On the one hand, Pyanodon is why I have YAFC in the first place.

Same here :smiley: The mod-suite is very complex (both in using and code-wise), and YAFC seems to be the only one capable of handling it!

But now we have the ~problem~ challenge figuring out whether YAFC is handling completely/correctly... :smile: