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 2826 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 2820 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 2797 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 2738 times

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

02-09-2025, 18-50-26.png (857.91 KiB) Viewed 2696 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 2695 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.

[Hares]

Speaking of drag-undo, it does NOT undo dragging of tiles.

[gGeorg]

I like more signals and their description. Also usage of 3 colours : dark-white - plus one color it is great style. Artistic AND readable.

However, the black background of a signal, is nearly the same as UI general color, which cause various readability issues.
Designing a circuitry is serious brain process, making it more difficult by UI which blends into each other is a problem.
On top , Inability differentiate signal vs value is tragic design fail.

I hope you fix this !

I can understand that an artist had some idea, of consistency, but consequences are terrible.
Another artistic overdo mistake is applying a skeleton of Wube logo as virtual keystone background. Again, art style won over readabilty & useability. I guess you know why sans-serif fonts are used in gaming, manuals and important presentations - it is readable ! Simple shapes helps brain focus at important values! Also simple shapes preventing eye unnecessary constrains.

Most of your changes are good or even great, but this is mistake !

How to fix >>>>>>
1. Put back black letters on teal colour keycap style. (or develop any other color combination which do not blend with UI and is EASY readable.)
2. Use simple SQUARE keycap background for all signals iinclude Any,All, Each - to prevent eye strain and improve read ability.
3. Newly developed symbols for Any,All, Each are some artistic licensee. It gives no sense. Put back previous SIMPLE style OR use standard mathematical symbols !

Thank you for fixing this mess !

[AntiElitz]

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

When will this be reverted? It's terrible .

[Zavian]

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

When will this be reverted? It's terrible .

Can't you just right click on the last ghost, rather than use control-Z (or mine the last item if you placed items directly)?

[thedoh]

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

When will this be reverted? It's terrible .

Can't you just right click on the last ghost, rather than use control-Z (or mine the last item if you placed items directly)?

This goes against ten years of muscle memory (to say nothing of general computer usage these days)

[nthexwn]

Can't you just right click on the last ghost, rather than use control-Z (or mine the last item if you placed items directly)?

Sure, but it's slower and less precise. The guy you responded to is a former (current?) world-record holder for Factorio speedruns. He does a lot of drag-building. Being able to control-z if he goes too far shaves off several seconds from runs versus those workarounds. The new system just isn't as efficient.

I've also frequently used control-z to back up a step or two when doing drag-placements. I can't recall a single time where drag placements caused my command history to be too large for me to go back and undo some earlier action. I get that they're trying to help here, but I think they're throwing out a majority convenience for a minority one.

If I may offer a suggestion: Perhaps we could have some kind of backoff algorithm (IE: fibonacci) for control-z actions when drag undoing? For instance, if you dragged 40 of something the first control-z would undo 1, the second would undo 1, the third would undo 2, 3, 5, 8, 13, and the last one would remove the remaining 7? This seems like it would provide the best of both worlds, as it would give fine-grained control over the last few undo actions while also breaking further undos into a more manageable count so the command stack remained relatively small.

[burninghey]

While it happens to me sometimes, that undo is just not feasible due to the large number of ctrl-z to undo a single drag, I would prefer some option for ctrl-z undoing whole drag. Like said before, fibonacci-pattern on undo or option in menu, or (we don't have enough keys yet!) a modifier key (shift?).

[Omnifarious]

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.

Thank you for the information. That definitely sounds like a gcc bug. Interesting. It also sounds like one of those bugs where it's nearly impossible to create a small isolated test case. And absent that, I despair of it ever being fixed.