Seems like it, but shouldn't running out of power immediately update the position to avoid such jumps?


The performance optimization means that it doesn't actually check the power level at every point. Seems like it's not checking for how much power is left until after it tries to subtract how ...

Hello, I tested this in the current version, and it seems to be fixed already.

Hello, you just can't have separate parameters with the same value.
The value is the primary identifier of the parameter, and the whole point of the system is, that all of the same numbers are merged and changed in one go.

Hello, thx for the reports.
These have been fixed in the recent updates.

Hello, thanks for the report.
I added more context to the train parameters collection for the next verison.

The problem with parametrising interrupts is, that interrupts are global, you can create one interrupt and use it in different trains, and edit it for all of them at the same time.
When you parametrise interrupt in a way, that the parametrisation makes completely new interrupt with a new name, it ...

Hello, thanks for the report, it is now fixed for the next release.

All I can see is two number values with the value 0. Each value need to be unique.

Hello, thanks for the report, it is now fixed for the next version.

I think it is fine behaviour, that it sorts by least/most time remaining, not relative percentage. It already is quite a weird situation when you use it to sort different kind of spoiled items at the same time.

Yes, this is already fixed.

Hello, I tested it, and it works now, so it was apparently fixed by some of the fixes in the past already.

Not a bug.
There is a rule, that when you use any other than normal quality in the source, it is expected the quality is preserved from the source. (For example, one parameter used with different qualities in a single blueprint).
If you use only normal quality for the parameter, you can then select ...

This would basically require to add yet another type of dependency.
Currently we have ingredient#1 ingredient#2 etc.
On top of that, we would have selectable result#1, result#2 etc.

Programming the logic wouldn't be big of a problem, but the UI would get even more complicated, so I'm questioning if ...

Hello, I'm sorry but I don't really understand the problem describtion.
Generally, you can't have different parametrisation of the same number value.

Hello, I was halfway through writing the test, but then I noticed the blueprint is all wrong, and it is not actually a bug.
You have all the original values to be 1. I don't know how it happened that they show separatly in the parametrisatio, but when I make blueprint with more values being 1, they ...

Hello, thanks for the report, it is now fixed for the next release.

Hello, it is the number of ticks to be waited in the schedule.
I added a context to be shown for this kind of value for the next version.

It is actually not max_uint32, but lower. (4294963296 instead of 4294967296), which is 4000 lower.
The number was already imported as that for the max count of the logistic set (yes, in constant combinator, but they support that as well).
So the question is, how did this number get imported like ...

Thanks for the report.
Parameters resulting in a duplicite requests are now (in the next release) merged into the existing requests with the count summed.