RAD won't assign to Bezhetsk

[Mehring]

Over the last 4 turns or more I've had XII RAD labour group asigned to various HQs within 5 hexes of Bezhetsk (220,110) intending for it to repair rail to the depot built there. The hex is not on the front line and not fully stacked but nobody will send them there. The labour group appears just to sit in the HQ every turn. Is this bad luck, is it being asigned to dig trenches, or is there something off with Bezhetsk?

Server game Mehring v Pekkavilamoura

[Joel Billings]

No way to know for sure what's going on there. Gary worked on the rail code several times after release. It's not straightforward, has randoms, and has enough going on that there's no guarantee that you will get a rail hex repaired. It was not something we intend to go back to. Is this near the frontline? Isn't there a limit as to how close to an enemy hex these units will operate?

[Mehring]

It's two hexes or so from the front line. RADs will repair rail in a frontline hex and even if without a friendly combat unit, as long as no enemy units are adjacent.

[Joel Billings]

So they will repair even within a few hexes of enemy units? I may be thinking of something else that doesn't happen near the enemy. I don't know why it isn't repairing. Gary always says it's easier to find why something does happen then to find why something doesn't happen.

[Mehring]

So they will repair even within a few hexes of enemy units? I may be thinking of something else that doesn't happen near the enemy. I don't know why it isn't repairing. Gary always says it's easier to find why something does happen then to find why something doesn't happen.

Yes, they'll repair frontline hexes so long as no enemy is adjacent.

It just occured to me, could supply be an issue here? Currently, the RAD in question has 12 supply out of 18 need.

In any case, I just transferred two smaller and well supplied RAD groups to several local HQs to see if they do the job.

[Joel Billings]

Could be, but it might be nearby freight or supplies in nearby cities. Don't remember what gets used to repair rails, but pretty sure there is a cost of some kind.

[Mehring]

All three RADs remained in their HQs, whatever's going on it's more than bad luck.

[Jango32]

Screenshot?

[Mehring]

Screenshot?

https://drive.google.com/file/d/1rGO7_T ... sp=sharing

[Jango32]

Where's the FBD in all this?

[Mehring]

There is no FBD.

[tyronec]

I have seen that sometimes the SUs will not deploy within 2 hexes of an enemy unit. Don't understand why, because sometimes they do but in my current game there was one hex near Lenningrad where it wouldn't deploy until the Soviets were pushed back an extra hex.

[Mehring]

I have seen that sometimes the SUs will not deploy within 2 hexes of an enemy unit. Don't understand why, because sometimes they do but in my current game there was one hex near Lenningrad where it wouldn't deploy until the Soviets were pushed back an extra hex.

Possibly, but unless that repeats it could just be a coincidence. Was it during snow or blizzard?

I'm getting more strange results in heavy snow and blizzard like two near 100% ToE Rumanian RR SUs stacked leaving 58% still to repair in a turn, while in another hex just one of the same unit leaves only 2% unrepaired. The underperforming SUs are actually better supplied than the single SU.

[tyronec]

Possibly, but unless that repeats it could just be a coincidence. Was it during snow or blizzard?

No, it was during the '41 push for Lenningrad.

[Mehring]

Possibly, but unless that repeats it could just be a coincidence. Was it during snow or blizzard?

No, it was during the '41 push for Lenningrad.

I've often seen that RADs will occaionally not deploy to repair for a turn but will do so subsequently far behind the frontline, much too far for enemy unit proximity to be an issue. I've always assumed this was due to an initiative or admin check failure. Could this explain your experience?

[tyronec]

I've often seen that RADs will occaionally not deploy to repair for a turn but will do so subsequently far behind the frontline, much too far for enemy unit proximity to be an issue. I've always assumed this was due to an initiative or admin check failure. Could this explain your experience?

It could, this one didn't deploy for at least two turns, as far as I remember.

[Mehring]

Here's another odd one. 4 posts up you'll read "two near 100% ToE Rumanian RR SUs stacked leaving 58% still to repair in a turn". A turn later they're still in the hex which remains 58% still to repair. https://drive.google.com/file/d/18BgnYD ... sp=sharing

[Mehring]

...and the next turn, still the two SU's in hex 246,204 and no repair progress. Supply situation is excellent, this is messed up and needs attention, something is either badly wrong or requires an explanation.

[Mehring]

...and two turns on, now cold with no blizzard, still stuck with 2 Rumanian SUs in the hex and no change to repair. I've never seen this in any previous version. https://drive.google.com/file/d/1F3YcP6 ... sp=sharing

[Joel Billings]

Figuring out if something here is broken is the hardest part. Based on the last time Gary used the debugger on rail unit questions, he wasn't able to see why some things were not happening (again, easier to say why something happened than why something doesn't happen). If I have a save, maybe I can get Gary or Pavel to try to list out some of the factors that might prevent a rail unit from going out. However, IIRC I went through this with Gary in the past and it was not something where the info came easily. When the individual unit rail repair piece was being adjusted in WitE2, we never wanted/expected them to do more than repair rails in the rear that were not critical rails. They were intended to help repair over time the many rail hexes that would be damaged but left behind by the FBD/NKPS units that were repairing the main lines. We realize players found they could try to focus them on certain more important hexes and save the FBD/NKPS units to work on other things, but this was never our intent. So fundamentally you are doing something we did not intend in the design, and then complaining that they aren't working as you expect. I appreciate your frustration, but it is not at all easy to figure out and describe what is going on here (maybe impossible at this point for Gary without spending many hours, and Pavel didn't write any of this code, so he would be coming to it cold). Since we never intended for it to be something that always worked and could be laser focused, we can't justify a lot of time on this. Again, if I have a before save (pre-logistics save), maybe I can get some more info on what factors go into it, but depending on how the code is structured, I can't even promise that.