Version 2.0.34

[B4SK3]

I don't see an entry on recycling yet I get this message when loading a 2.0.33 save:

[Muche]

I don't see an entry on recycling yet I get this message when loading a 2.0.33 save:

Most likely it's due to 124333 Factoriopedia shows impossible recycling recipes.
Some fixes for it went to v2.0.34, some will be in v2.0.35.

[Hares]

I like what you did with the virtual signals, they look much nicer now.

However, I've noticed a (probably accidental) breaking change: The "ghost" virtual signal has been removed and there seems to be no migration to replace it with a different signal when loading a save game. All circuits using the ghost signal will therefore stop working after the update.

For example, if you have an inserter with the enable condition "[signal-ghost] > 0" and load this save game in 2.0.34, the configured signal will be removed, resulting in "[empty] > 0".

Was the ghost signal removed intentionally or simply forgot during the signal redesign?

Is still there for me

02-09-2025, 16-24-40.png (816.29 KiB) Viewed 553 times

[Hares]

Can somebody confirm that before 2.0.34 the operation name for combs were centered?

02-09-2025, 16-31-49.png (183.32 KiB) Viewed 546 times

[Muche]

Can somebody confirm that before 2.0.34 the operation name for combs were centered?
02-09-2025, 16-31-49.png

I'm not sure what you mean, this is how it looks for me in 2.0.33:

662313-AriComb_v2033.jpg (54.01 KiB) Viewed 523 times

[thedoh]

Changes

• Drag building produces one merge undo action per the whole drag, instead of the individual undo actions for every entity built.

Please, I beg to put this behind a setting. The vast majority of the time when I need to undo something it's because I have built one too many and want to undo just the one, and not the entire line of furnaces.

[Hares]

I like what you did with the virtual signals, they look much nicer now.

However, I've noticed a (probably accidental) breaking change: The "ghost" virtual signal has been removed and there seems to be no migration to replace it with a different signal when loading a save game. All circuits using the ghost signal will therefore stop working after the update.

For example, if you have an inserter with the enable condition "[signal-ghost] > 0" and load this save game in 2.0.34, the configured signal will be removed, resulting in "[empty] > 0".

Was the ghost signal removed intentionally or simply forgot during the signal redesign?

Is still there for me

I wondered why my Glebase died while I was chatting...

02-09-2025, 18-24-43.png (1.61 MiB) Viewed 464 times

02-09-2025, 18-50-20.png (1.54 MiB) Viewed 422 times

02-09-2025, 18-50-26.png (857.91 KiB) Viewed 422 times

No more questions.
Patch 2.0.34 is broken.

Edit #1: Filed a bug report: 126713: [2.0.34] "virtual-signal=signal-ghost" is gone without migration

Edit #2: Attachments disappeared (ref: 117527: Attachment disappears after submitting a post), reuploaded

[Chindraba]

I'm unsure if I like the background change on the virtual signals from blue to black. I will adjust, I'm sure. For the numeric signals, however, it makes an interesting case. The virtual signal zero is nearly indistinguishable from the value of zero.

02-09-2025, 15-39-56.png (215.47 KiB) Viewed 421 times

The colored background made the symbols stand out better in combinators while also, imho, looking 'cleaner' in blueprint icons.

Lastly, the symbols for everything, each, and anything do seem like a nice switch. The anything, however, keeps feeling like an everything since the symbol is a mirror of the symbol for everything. I do get that ∃ is technically applicable for the context as well as being a pleasing balance, when stylised, to ∈ for everything. Perhaps, with the player base being less than 100% set theorists, you could get away with using ∀ for anything. Technically incorrect, yet the "A" shape would mesh with the anything better than a backwards rounded "E". I recognize that the 'a' in anything is an English language condition, and fails in many others. Yet I'd suspect that the set of non set theory aware users is much larger than the set of non-English aware users.

[Chindraba]

Can somebody confirm that before 2.0.34 the operation name for combs were centered?
02-09-2025, 16-31-49.png

I'm not sure what you mean, this is how it looks for me in 2.0.33:
662313-AriComb_v2033.jpg

Without adding a duplicate image, the results in stable 2.0.32 are the same (other than the symbol for each of course.)
Guessing that "operation name" is the operator, modulo in this case, the results in 1.1.110 are the same, the "%" symbol is left-justified.

[Hares]

Lastly, the symbols for everything, each, and anything do seem like a nice switch. The anything, however, keeps feeling like an everything since the symbol is a mirror of the symbol for everything. I do get that ∃ is technically applicable for the context as well as being a pleasing balance, when stylised, to ∈ for everything. Perhaps, with the player base being less than 100% set theorists, you could get away with using ∀ for anything. Technically incorrect, yet the "A" shape would mesh with the anything better than a backwards rounded "E". I recognize that the 'a' in anything is an English language condition, and fails in many others. Yet I'd suspect that the set of non set theory aware users is much larger than the set of non-English aware users.

For me personally, ∀ should be for "everything", ∃ for "anything", and something like → for "each"

[Omnifarious]

A change that is not mentioned in the changelog is that Linux builds are now built with Clang instead of GCC, which has allowed us to re-enable link-time optimization on Linux builds. Linux players should see some performance improvements due to this.

I'm curious, what was the blocker for LTO under gcc? Is this a bug in gcc?

[raiguard]

I'm curious, what was the blocker for LTO under gcc? Is this a bug in gcc?

When we enabled LTO on GCC we were getting "Undefined reference to main()" errors that we could not figure out how to fix. Bisecting resulted in a completely random commit related to trains that, when reverted, fixed the issue. But reverting was not an option because it fixed a critical bug.

Compilers are finicky things sometimes.