Steam Bug Report: Spg Gp38-2 Wrong Eotd Pressure (fix Suggested)

Hello DTG Matt and team.

I want to report a long standing issue with Sand Patch Grade's CSX GP38-2.

The End-Of-Train-Device shows the wrong pressure on the cab EOT display.

If the brakes are cut-in in "Freight" mode the loco correctly operates with 90 psi BP pressure. On a full release, there is a difference of about 15 psi in the EOT display.

Means in normal operation, the brakepipe is at 89 psi (1 psi less than 90 due to normal leakage), but the EOT shows 104.

I have looked up the script and think I found the line that causes the mismatch.

File: TS2Prototype\Plugins\DLC\CSX_GP38-2\Content\Simulation\GP38-2_RVM.uasset
Export: 124, "UpdateBrakeCutOutState"; Script statement index: 168

Excerpt:

Code:

    {
      "Inst": "Let",
      "Variable": {
        "Inst": "LocalVariable",
        "VariableType": {
          "PinCategory": "Float",
          "PinSubCategory": "Float"
        },
        "VariableName": "CallFunc_Add_FloatFloat_ReturnValue"
      },
      "Expression": {
        "Inst": "CallMath",
        "Function": "Add_FloatFloat",
        "ContextClass": "/Script/Engine.KismetMathLibrary",
        "Parameters": [
          {
            "Inst": "LocalVariable",
            "VariableType": {
              "PinCategory": "Float",
              "PinSubCategory": "Float"
            },
            "VariableName": "CallFunc_SelectFloat_ReturnValue"
          },
          {
            "Inst": "FloatConst",
            "Value": 14.6959743
          }
        ]
      },
      "StatementIndex": 168
    },

Suggestion: "Value": 14.6959743 should be set to 0. That seems to be a leftover from TSW2020 / CSX:Heavy Haul, I noticed that ~15psi on the AC4400 ER pressure adjustment display on the screen back then. - see below, issue is in the RVV not substracting that value

 

I have raised a ticket fyi.

Currently I have not found a way to modify/inject script bytecode myself, so I'm relying on you DTG to fix it.

 

Good luck..it's American stuff, so it's not important.

 

Nice job tracking down this issue! Hopefully DTG appreciates your effort and implements the changes to finally fix this issue. One can always hope.

 

I doubt that, seeing that the issue has not been even noticed or acknowledged. It took them months to correct their brakes on the TSC Tehachapi ES44DC, although I'd told them to just change a "MinimumReduction" string to "HoldLapped" which was the fix.

They're not very appreciative apart from TSC's senior producer Steve Dark (yes he's even leaving Likes and Helpfuls on user posts) as far as my experiences are.

People reporting TSW bugs are an annoyance for Matt & co it seems, doesn't help if you support them in tracking down the cause for the issue. Matt sometimes drops in, the usual "I'll have someone look into it but I can't promise" to never be seen again and dodging further questions, the forums are full of examples. That's DTG unfortunately.

A company that values their community (not just their useful ambassadors) would say: "Hey, thank you, we're testing your fix and will include it in the next update if tested successfully. Thank you for helping to make our game better!"

DTG say nothing. Buy our bugs and don't complain as long as the train is moving anyhow . We're only pretending to be railfans.

 

This is an old problem, it was generated in the migration from TSW 2020 to TSW 2... https://forums.dovetailgames.com/threads/end-of-train-device-psi-value.37809/

You also made a mistake in clarifying the problem, it is on the Head Of Train device, not the End Of Train device. I'm sure that if you change the value 14.6959743 to 0, it will generate another problem, as this is the input value for several locomotives, the SD40-2 itself contains this same value and works correctly, so the problem is elsewhere.

I can even re-cook the files in Unreal Engine later and see what happens, possibly new problems.

 

I cannot, but it should be enough for DTG to figure out the issue. Probably the SD40-2 and other locos compensate the value elsewhere. If this constant offset if vital for the physics, it must be substracted in the HOTD module again.

Why they need to add a static value to the brake pressure, only DTG know. I haven't checked the EOTD/HOTD code.

All I know is the brake physics were totally off in CSX:Heavy Haul, and maybe they used constant values to tweak it, resulting in a bit of a mess.

 

I've found the corresponding offset in the RVV file

 

... and here we have the definite issue, it's in the RVV (View), not the RVM (physics) blueprint.

The SD40 HOTD Update pressure script indeed substracts the 14 psi again - this is missing in the GP38-2 HOTD pressure update script!
DTG Matt DTG Alex DTG-Chris Issue pinpointed:

CSX SD40-2 RVV file: yellow section is missing in the GP38-2! That's why the SD40-2 shows correct pressure.


wellington You're right - that value might be needed for correct physics - it's just what's displayed that needs changing. Can you add the marked Statement into the CSX GP38-2 RVV?

 

Well... I saw that you understood the logic of the value 14.6959743 and that it can't be changed to 0 in GP38-2_RVM.uasset, but I changed it anyway to show the new problems generated, the train also took longer to depart than normal; that is, it's part of the physics of many items.

The images show all the problems created.

 

That 14 psi is probably a value just for tweaking the physics to match real life.

As I said, the RVV HOTD script must be adjusted to substract this constant again.

 

Full brake release / HOTD = 88.8


Full brake release / EOTD = 89


Emergency brake / HOTD = 00.1


Emergency brake / EOTD = 00


=====

 

DTG Alex

Any info on this. Wellington has proved my suggestion to add a substraction statement to the GP38-2's RVV HOTD update script does work.

Will you implement this now for everyone and show you're willing to fix bugs?

Thanks.

 

I didn't do this with your suggestion, I had to use the inverse function, because the subtract function caused the game to close, it seems that there was a project error, it's also not just about add the function, you have to use pseudo logic so that is shown correctly on the display.

I'll see if I can find some time over the weekend to look at the C40-8W, as it doesn't show anything.
https://forums.dovetailgames.com/threads/c40-8w-brake-issue.37580/#post-745658

 

But maybe it works if DTG apply it to the uncooked source files.

I'm not aware of the tools/methods you're using to modify script bytecode in cooked assets, but the missing substraction statement is what distinguishes the GP from the SD.

As for the Dash-8, I think it has to do with what stock is coupled to it (not sure though, haven't played it in a while). Don't use freeroam to test, as this often does not recognize an EOTD device at all.

 

In fact, the C40-8W unit has never worked HOTD since its release in TSW 2, perhaps I and many others don't know how to turn it on, I think I will turn to a real engineer to tell me where the correct switch. The strange thing is that only the decimal points are shown on the displays.

https://forums.dovetailgames.com/threads/c40-8w-brake-issue.37580/

 

Yeah, I had enough of their wimsy pimzy attitude about getting around to fixing crucial bugs and being bothered by us reporting stuff. I'm done playing their half done lazy LOVE game also. Not buying anymore future TSW games either.. big waste of money.

 

How come you can find this stuff but DTG mumbles and stumbles about fixing these bugs and little game glitches? They have many little worker bees working on this stupid game and can't figure this stuff out? Where does DTG find these people at? What are they doing there? This game has a lot of things wrong that need fixed, but seem to always just linger on in the shadows to further annoy us. Do not understand.