[2.0.55] Wildcards not syncing with cargo-types in train

[Cooltank10]

What did you do?

I ran across a very odd behaviour with wildcards in my attempt to create a 2-gauge blueprint-able train system. Here is my forum post giving more context:
129264

Just to reiterate (this is going to be complex so strap in); I'm engineering a dual-direction 2-lane (2-gauge) train system that is completely made up of sections of blueprints based on 4-long trains (locomotive included). These sections are aligned to the absolute world grid.

I have 2 different train types; Supply Trains and Refueling Trains. Supply Trains are a locomotive with 3 cargo/fluid wagons attached. Refueling Trains are a locomotive with 2 cargo wagons followed by a fluid wagon.

Currently I'm making a train station for the Refueling Trains to fill up with:

• Fuel, cargo wagon #1
• Solid Ammo (for gun turrets OR artillery), cargo wagon #2
• Fluid Ammo (for flamethrowers), fluid wagon

ALL stop names are ONLY rich text icons. For example: iron ore pickup is a iron ore rich text followed by a up arrow rich text. A drop-off station is iron ore rich text followed by a down arrow rich text.

In order to make a generalized refueling stop I need to have wildcards in interrupts to send the train from the pickup station to the numerous drop-off stations of matching cargo-types. I'm currently using 3 wildcards for this purpose (in order); Fuel, Signal, and Fluid. I'm using a generalized refueling stop because otherwise I would have to manually make 60 different interrupts (5 fuels * 4 item ammos * 3 fluid ammos) for each permutation of the combinations of possible fuels/item ammos/fluid ammos. This gets exponentially worse with modded items. (I'm not using mods but Space Age introduces a lot more ammo types which drastically increases the interrupt count)

Without using train limits/dynamic priority/dynamic station disabling, these work perfectly normal. However I have to use these to solve other problems.

What happened?

Now for the bug, heres my generic interrupt for leaving the pickup refueling station and going to one drop-off refueling station:

pic

Interrupt having the issue

202506~1.JPG (191.63 KiB) Viewed 927 times

The chain refuels you see are used to move between drop-off stations when; the stations are full (via an inactivity timer) OR when the train is empty of one type of material. If I set the train to automatic here's what happens (with pictures):

• Train in manual mode:
  pic

  

  Train in manual mode (before test)

  202506~2.JPG (274.62 KiB) Viewed 927 times

• Automatic train heads for an available refueling pickup station
• After filling with items, the waiting condition is met and starts scanning the interrupts' conditions
• Meets the condition for '[Test2] First Refuel' and schedules a departure at the Target Station:
  pic

  

  Stuck train in automatic mode (test's conclusion)

  202506~3.JPG (278.55 KiB) Viewed 927 times

• Oddly the wildcards are unable to match to the Nuclear Fuel in the locomotive AND the Light Oil in the fluid wagon. But it's able to sync the signal wildcard just fine.

This is repeatable and it always happens in this configuration, I've double checked everything and it should work as intended.

I did a control test as well with a different train without all the circuitry and it works just fine:

pic

Control Test

202506~4.JPG (240.73 KiB) Viewed 927 times

Note: Both locomotives above are full of Nuclear Fuel, and the wagons are full of their respective material.

What did you expect to happen instead? It might be obvious to you, but do it anyway!

I expected the interrupt to successfully sync ALL of the wildcards just like it did in the control test. The strange thing is that the interrupt's condition successfully triggered while the Target Station didn't sync 2 wildcards but successfully sync'd the signal wildcard. The contents of the train was full when the condition of the interrupt was met so it should've synced all 3 wildcards in the target station.

Does it happen always, once, or sometimes?

Yes, it always happens in this configuration. Although it doesn't happen when the station is controlled by circuitry. Specifically dynamic priority, dynamic station disabling, and a train limit. I have only tested if the station has all 3 circuitry-related controls active at once.

I have included my log files and my save file. Let me know if I missed anything or you need further info. Thanks for the assistance!

[Yodo]

One problem I see is that you use the any-fuel wildcard, but want it to react to the train's cargo. I don't think this will work (this was also mentioned in the other thread.).

Also, can you confirm that the triple-wildcard interrupt works if you don't use dynamic train stop limits or priority?

Does it help if you add the wait condition fluid count: any-fluid > 0?

[Cooltank10]

I can confirm the issue is still present in <[2.0.72] build 84292 expansion, win64>.

One problem I see is that you use the any-fuel wildcard, but want it to react to the train's cargo. I don't think this will work (this was also mentioned in the other thread.).

The only reason I'm using the any-fuel wildcard is that the any-item wildcard can possibly be either a fuel or a ammo type. Since I'm transporting a solid fuel and ammo all in one train, that would bring up the possibility of the any-item wildcard choosing the ammo and not the intended solid fuel. This possible error would ruin the logic I currently have. Using the any-fuel wildcard would prevent this from happening as it takes the fuel type directly from the engine. The wildcards are only used to find the specific fuel that the train is using to then find a matching refuel drop-off station for the train to path-find to via interrupts. I have separate logic to measure and report the cargo wagon of solid fuel to the train station(s) for a dynamic priority feature.

Also, can you confirm that the triple-wildcard interrupt works if you don't use dynamic train stop limits or priority?

Yes, It absolutely works as intended without any other dynamic limits or dynamic priority systems.

I've made a identical train setup without the dynamic stuff and the train successfully fetches;
- It's own fuel item type w/ the any-fuel wildcard
- The copper ore signal given to the train by the station by the any-signal wildcard
Note: I used copper ore as a replacement for an ammo type. Changing this to another item type wouldn't change the functionality of the any-signal wildcard.
- The fluid being carried w/ the any-fluid wildcard.

Also, my priority and train limiter systems shouldn't effect the any-item or any-fluid wildcards as they don't interact at all with any part of those within the train. The only thing my priority/limiter systems effect is the any-signal wildcard which is also unaffected by the 2 extra non-item/fluid signals as I believe signal precedence dictates that item and fluid signals are fetched before signals like <P> or <up-arrow> are taken.

Does it help if you add the wait condition fluid count: any-fluid > 0?

The problem is that the any-item AND my any-fluid wildcards in my interrupts are not correctly syncing with the train's cargo even though it did sync correctly in the No-Dynamics test. It doesn't work when I try to implement the priority/limiter systems, even though it should work.

The strange thing is that the interrupt's condition is correctly detecting the train with the 3 wildcards (any-fuel, any-signal, any-fluid), but the Interrupt's Targets fails to replace the any-fuel and any-fluid wildcards. The any-signal wildcard hasn't broken only the other 2 wildcards during the target selection of the Interrupt. This is with the dynamic system in place. Without the dynamics, the Interrupt Target would have successfully replaced the 2 wildcards with their respective Rich Text.

Hopefully that shed more light onto the problem. Let me know if you have any questions!