Duplicate 94035

Yes, it happened when opening entity gui for Train Stop. This is a duplicate.

Duplicate 94035

When zoomed in there are 2 types of layers beying rendered - for chunks that are visible and for chunks under the fog of war. Robots still have to be processed when zoomed in because of the fog of war.

I was hoping for something more interesting but this was already being reported multiple times in different contexts. Line on the splitter output was kept active and so it updated first, then the line downstream of it started to move requesting all the transport lines upstream to update but the righ...

All the entity statuses issues i am consider to be at most `minor` because they are not game breaking and they are exposing some of the internal state weirdness that is acceptable on the inside. I will be assigning all of them to kovarex so he decides if he wants to fix them.

The thing that is wrong is that a train can keep the same schedule and a station can use the logic of enable/disable and the behaviour of that train can be changed by simply adding a second station with the same name. No, everything here is fine. If you have 2 train stops and one is disabled, the t...

Ok i fixed the train behavior a little for 1.1.9: when a train stop is destroyed while a train is stopped at it, since the departure was not fulfilled i decided it should go to another train stop under the same station name (retry the same schedule record), just as it would not yet arrive to this tr...

ptx0 wrote: ↑

Fri Jan 08, 2021 10:12 am

when using linked-belts and linked-pipes, it shouldn't.

linked-pipes are not implemented. They are strong candidate but i am not touching that area right now at all.

I checked what is wrong and the issue is with the inserter and it has nothing to do with entity statuses. Mining drill would say "waiting for space in destination" only if it would become inactive which does not happen because inserters do not support input wakeup lists. That means that an...

There were no changes related to folders in between of 1.1.6 and 1.1.8 so i am not considering this a Bug report. Moving to Technical help.

Thanks for the report. This minor blasphemy is now fixed for 1.1.9. I was going to "Not a bug" this but since it is also possible to get using accumulators in multiple networks (one with lamps and the other for charging) i decided to fix it anyway.

I see nothing wrong. You disabled train stop while the train was on route and it has nowhere to go to so it stopped. It works as designed.

I see nothing wrong here. It is the consequence of disabling train stop that has trains incoming and not having overflow train stop for those trains that happened to be on route. When all train stop under given station name are disabled trains will skip such schedule record but in your case there is...

Thanks for the report. Issues are now fixed for 1.1.8.

Xorimuth wrote: ↑

Thu Jan 07, 2021 1:30 pm

I think that you forgot your train stop colour change from the changelog: viewtopic.php?f=66&t=79681 (great addition btw!)

When a change consists of 2 lines added (tint added to 2 utility sprites) it was highly possible i could forget a changelog entry.

Not a bug. If you want you can adjust the request amounts. 67985

1.1.7:

1.1.7: