Crash while removing/replacing biofluid pipe

EigensheepLambda commented 5 months ago

Mod source

Factorio Mod Portal

Which mod are you having an issue with?

[X] pyalienlife
[ ] pyalternativeenergy
[ ] pycoalprocessing
[ ] pyfusionenergy
[ ] pyhightech
[ ] pyindustry
[ ] pypetroleumhandling
[ ] pypostprocessing
[ ] pyrawores

Operating system

=Windows 10

What kind of issue is this?

[ ] Compatibility
[ ] Locale (names, descriptions, unknown keys)
[ ] Graphical
[X] Crash
[ ] Progression
[ ] Balance
[ ] Pypostprocessing failure
[ ] Other

What is the problem?

Built out a fairly large biofluid network (~80 consumers and providers, few hundred "pipe" segments including undergrounds). As it got large, it started becoming unreliable- sections of requestors would start acting like they were disconnected and could be fixed just by replacing or 360-rotating segments in the path between working requestors and nonworking requestors. When tearing some of it down to try to get it to a stable state, a non-underground segment did not visually reshape itself into a corner segment when removing a branching connection, and when removing and replacing that segment, the game crashed with the below error.

Steps to reproduce

No response

Additional context

crash_biofluid

Log file

factorio-current.log

EigensheepLambda commented 5 months ago

Minor extra bonus bug- can't click-select floating biopyanoports when they've been built on ore. (Or is this intended behavior to punish heresy?)

EigensheepLambda commented 5 months ago

The weird behavior in my large biofluid network (requestors at distant ends frequently acting like they're not connected to the rest of the network whenever I modify any part of the network) seems to be mitigated by not having the usual factorio-style underground-underground-gap-underground-underground-etc pipe runs.

That is, if I add one or more normal segments in between each of the underground pairs (underground-straight-underground-gap-underground-straight-underground-etc), or just make really long runs of normal segments with no undergrounds, the problem stops occurring (at least, so far).

Hopefully this helps narrow down which bit of logic is misbehaving.