.animated sound

Alright so on MTR M-Train in Hong Kong, different car's closing and opening door sound is different. I would want to recreate it(or help others, at least), and it seems that my only solution is to use .animated sound section, however after following the docs, no sound is played in-game(v1.7.0.3). Is there any way I can achieve this? Thanks.(I don't have the code anymore, but I was confused about where to place the sound section, how to make it play when the door opens/close.)

I tried to solve the problem, but I failed either
I tried to use StateChangeSound, but not only the sound does not play, the model does not load either.

Code:

[Object]
Position = 0, 0, 0
States = DK3Body.obj.csv

[Object]
Position = 0, 0, 0
States = doora1.obj.csv
TranslateXFunction = Ceiling[rightdoors] * (0.02)
TranslateZFunction = Min[Max[If[rightDoorsTarget==0,rightDoors*2.3077-0.1385,If[rightDoors<0.0189,value,value+delta*0.1622]],0],0.6]

[Object]
Position = 0, 0, 0
States = doora2.obj.csv, doora2.obj.csv
StateFunction = rightDoorsTarget
TranslateXFunction = Ceiling[rightdoors] * (0.02)
TranslateZFunction = -Min[Max[If[rightDoorsTarget==0,rightDoors*2.3077-0.1385,If[rightDoors<0.0189,-value,-value+delta*0.1622]],0],0.6]

[StateChangeSound]
FileNames = ../AnimDoorCls.wav, ../AnimDoorOpn.wav
Position = 0, 0, 0
Volume = 1.0
Pitch = 1.0
Radius = 30
PlayOnShow = 1
PlayOnHide = 0

[Object]
Position = 0, 0, 0
States = doorb1.obj.csv
TranslateXFunction = Ceiling[leftdoors] * (-0.02)
TranslateZFunction = -Min[Max[If[leftDoorsTarget==0,leftDoors*2.3077-0.1385,If[leftDoors<0.0189,-value,-value+delta*0.1622]],0],0.6]

[Object]
Position = 0, 0, 0
States = doorb2.obj.csv, doorb2.obj.csv
StateFunction = leftDoorsTarget
TranslateXFunction = Ceiling[leftdoors] * (-0.02)
TranslateZFunction = Min[Max[If[leftDoorsTarget==0,leftDoors*2.3077-0.1385,If[leftDoors<0.0189,value,value+delta*0.1622]],0],0.6]

[StateChangeSound]
FileNames = ../AnimDoorCls.wav, ../AnimDoorOpn.wav
Position = 0, 0, 0
Volume = 1.0
Pitch = 1.0
Radius = 30
PlayOnShow = 1
PlayOnHide = 0


And it causes "Plugin Object.Animated.dll returned unsuccessfully at LoadObject"

zbx1425 wrote:I tried to solve the problem, but I failed either
I tried to use StateChangeSound, but not only the sound does not play, the model does not load either.

Code:

[Object]
Position = 0, 0, 0
States = DK3Body.obj.csv

[Object]
Position = 0, 0, 0
States = doora1.obj.csv
TranslateXFunction = Ceiling[rightdoors] * (0.02)
TranslateZFunction = Min[Max[If[rightDoorsTarget==0,rightDoors*2.3077-0.1385,If[rightDoors<0.0189,value,value+delta*0.1622]],0],0.6]

[Object]
Position = 0, 0, 0
States = doora2.obj.csv, doora2.obj.csv
StateFunction = rightDoorsTarget
TranslateXFunction = Ceiling[rightdoors] * (0.02)
TranslateZFunction = -Min[Max[If[rightDoorsTarget==0,rightDoors*2.3077-0.1385,If[rightDoors<0.0189,-value,-value+delta*0.1622]],0],0.6]

[StateChangeSound]
FileNames = ../AnimDoorCls.wav, ../AnimDoorOpn.wav
Position = 0, 0, 0
Volume = 1.0
Pitch = 1.0
Radius = 30
PlayOnShow = 1
PlayOnHide = 0

[Object]
Position = 0, 0, 0
States = doorb1.obj.csv
TranslateXFunction = Ceiling[leftdoors] * (-0.02)
TranslateZFunction = -Min[Max[If[leftDoorsTarget==0,leftDoors*2.3077-0.1385,If[leftDoors<0.0189,-value,-value+delta*0.1622]],0],0.6]

[Object]
Position = 0, 0, 0
States = doorb2.obj.csv, doorb2.obj.csv
StateFunction = leftDoorsTarget
TranslateXFunction = Ceiling[leftdoors] * (-0.02)
TranslateZFunction = Min[Max[If[leftDoorsTarget==0,leftDoors*2.3077-0.1385,If[leftDoors<0.0189,value,value+delta*0.1622]],0],0.6]

[StateChangeSound]
FileNames = ../AnimDoorCls.wav, ../AnimDoorOpn.wav
Position = 0, 0, 0
Volume = 1.0
Pitch = 1.0
Radius = 30
PlayOnShow = 1
PlayOnHide = 0


And it causes "Plugin Object.Animated.dll returned unsuccessfully at LoadObject"

I would just hope that it's not a bug(or at least we have a way to do this without new update)
v1.7.1.0(and beyond) are causing so many problems. On higher quality route, the fps still drops. Some reports that the texture coordinate is completely messed up, some reports that the texture are dimmed, and there is alot of trains in Hong Kong that use the same texture on Day and Night texture in the interior(basically the effect before v1.7.1 is the same as SetEmissiveColor 255) ,now the texture blinks.
I would love to see patches using the old render, but it is unlikely to happen.

LXQt wrote:I would just hope that it's not a bug(or at least we have a way to do this without new update)
v1.7.1.0(and beyond) are causing so many problems. On higher quality route, the fps still drops. Some reports that the texture coordinate is completely messed up, some reports that the texture are dimmed, and there is alot of trains in Hong Kong that use the same texture on Day and Night texture in the interior(basically the effect before v1.7.1 is the same as SetEmissiveColor 255) ,now the texture blinks.
I would love to see patches using the old render, but it is unlikely to happen.

Well, I personally think not updating is not a good idea. As while you get less bug, you also get less feature.
Maybe the best solution is to show the broken routes to the developer. As the openBVE is meant to be backward-compatible.
So that if there is bug in the program we can fix it, and if there is non-standard practices in the routes we can implement some content-specific hacks.
BTW the new renderer is NOT ENABLED by default in 1.7.1 as the dev is aware of its instability. It can only be enabled by ticking "Enable the new renderer" in the second page of the preference. So I doubt if the coordinate and fps problem has anything to do with the new renderer.
The Day & Night texture behavior change seems to be the cause of dimming and blinking. As this bug is already widely wrongly used, I hope Mr.leezer3 can think twice whether changing the behavior and making it non backward-compatible is proper.

zbx1425 wrote:

LXQt wrote:I would just hope that it's not a bug(or at least we have a way to do this without new update)
v1.7.1.0(and beyond) are causing so many problems. On higher quality route, the fps still drops. Some reports that the texture coordinate is completely messed up, some reports that the texture are dimmed, and there is alot of trains in Hong Kong that use the same texture on Day and Night texture in the interior(basically the effect before v1.7.1 is the same as SetEmissiveColor 255) ,now the texture blinks.
I would love to see patches using the old render, but it is unlikely to happen.

Well, I personally think not updating is not a good idea. As while you get less bug, you also get less feature.
Maybe the best solution is to show the broken routes to the developer. As the openBVE is meant to be backward-compatible.
So that if there is bug in the program we can fix it, and if there is non-standard practices in the routes we can implement some content-specific hacks.
BTW the new renderer is NOT ENABLED by default in 1.7.1 as the dev is aware of its instability. It can only be enabled by ticking "Enable the new renderer" in the second page of the preference. So I doubt if the coordinate and fps problem has anything to do with the new renderer.
The Day & Night texture behavior change seems to be the cause of dimming and blinking. As this bug is already widely wrongly used, I hope Mr.leezer3 can think twice whether changing the behavior and making it non backward-compatible is proper.

Correction: I didn't ticked the "Enable the new render" at all the time, now I got nearly double of the fps in v1.7.0.3 and I am kinda satisfied with it.
However again, the dimmed texture are everywhere due to developers using the bug wrongly, I hope this will change in the future version to make it backward-compatible.
Anyway, I would just like to see how the animated sound works, if it needs an updated version, it's fine.

LXQt wrote:Correction: I didn't ticked the "Enable the new render" at all the time, now I got nearly double of the fps in v1.7.0.3 and I am kinda satisfied with it.
However again, the dimmed texture are everywhere due to developers using the bug wrongly, I hope this will change in the future version to make it backward-compatible.
Anyway, I would just like to see how the animated sound works, if it needs an updated version, it's fine.

The new renderer is designed to boost the fps, but it is often seen doing this exact opposite
I'd like to hear Mr.leezer3's word on the Night & Day texture problem too. I also think the bug is too widely used to fix without major impact.
BTW I'd also like to have Mr.leezer3 take a look on my code and tell me why it does not work 

zbx1425 wrote:

LXQt wrote:Correction: I didn't ticked the "Enable the new render" at all the time, now I got nearly double of the fps in v1.7.0.3 and I am kinda satisfied with it.
However again, the dimmed texture are everywhere due to developers using the bug wrongly, I hope this will change in the future version to make it backward-compatible.
Anyway, I would just like to see how the animated sound works, if it needs an updated version, it's fine.

The new renderer is designed to boost the fps, but it is often seen doing this exact opposite
I'd like to hear Mr.leezer3's word on the Night & Day texture problem too. I also think the bug is too widely used to fix without major impact.
BTW I'd also like to have Mr.leezer3 take a look on my code and tell me why it does not work 

This is primarily my issue, although you did something unexpected which confused things

Two glitches-
1. You'd used multiple sounds / objects in a file. (My typo!)
2. I hadn't considered what would happen when PlayOnHide was set to false with multiple states; This was intended for use with a single sound for all states only (makes no sense otherwise). I've updated the documentation to clarify that these will now be ignored in this case, and that the single sound for the new state will now be played in this case.

Today's build should make your example work.
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2020-04-04.zip

With the new renderer-
It's a *lot* more behind the scenes than just a simple openGL version change, which is why the initial introduction has been a little iffy unfortunately.
On the positive side, we're nearly at the stage where all three programs (sim and viewers) are running off a single set of internal libraries and parsers, and everything has been converted into plugins. This will make the introduction of new formats and features far, far easier in future

Fixing the duplicated textures 'bug' is somewhere where unfortunately, we're between a rock and a hard place
It was clearly unintended behaviour in the first place, and as there are other correct ways to achieve the same effect in my opinion fixing it was the right course of action.

leezer3 wrote:Two glitches-
1. You'd used multiple sounds / objects in a file. (My typo!)
2. I hadn't considered what would happen when PlayOnHide was set to false with multiple states; This was intended for use with a single sound for all states only (makes no sense otherwise). I've updated the documentation to clarify that these will now be ignored in this case, and that the single sound for the new state will now be played in this case.

The problem is that the door opening-closing sound must be triggered EXACTLY the same time when the doortarget changes, so the StateChangeSound must be used, and Sound cannot achieve this since it is looping (Am I understanding this correctly?) and can be played "halfway".
My current .animated code is also not perfect, as it would not stop the closing sound when it is reopened. I hope you can bring me a better solution about this problem.
There are requirements of triggering a sound from the beginning at a time. It would be nice if we have more control over this once the sound is triggered, like stopping it in the door reopening scenerio.

I don't personally agree with your decision of this Day & Night texture bug. Fixing this breaks the backward-compatibility, and will break many, many routes which used this bug wrongly.
And it would just stop players from upgrading openBVE, since the newer versions break their routes. In fact many developer organizations, such as HKRSC, has been deliberately suggesting their players not to use a version above 1.7.0.0.
Using content-specific fixes would be a solution, but there will be many routes requiring to be fixed, and you cannot expect all players or developers know how to report a problem to you.
So I am worried that this behavior change might make openBVE be like python 2 and 3. Different routes requires non-compatible different versions, and players have to install multiple instances of openBVE to play new routes and old routes. That would be really, really annoying.

I still don't get this though
My code is:

Code:

[Object]
States = door\doorL.csv
Position = -0.015,0.1,-0.25
TranslateZFunction = 0.89*if[leftDoors[0]>0.7,1,leftDoors[0]*1.4]

I would like to add the sound to this object. Using the code given above, the entire door will disappear without error.
do I put the [StateChangeSound] section below this object?

Also is there any plan for content specific hacks for HK Route, I've heard that they would keep using the duplicate texture instead of SetEmissiveColor, plus some trains stopped updating. Once they entered the tunnel(or .brightness 0), only few objects remains bright in the interior.

LXQt wrote:I would like to add the sound to this object. Using the code given above, the entire door will disappear without error.
do I put the [StateChangeSound] section below this object?

Also is there any plan for content specific hacks for HK Route, I've heard that they would keep using the duplicate texture instead of SetEmissiveColor, plus some trains stopped updating. Once they entered the tunnel(or .brightness 0), only few objects remains bright in the interior.

I used a little hack, as [StateChangeSound] uses the StateIndex of the last Object as its sound index. So you can see I used the doorstarget as StatesFunction at the door object, and used two same States so the StatesFunction does not affect the appearance, and only the following [StateChangeSound] section makes use of it to choose the sound. You do have to put the [StateChangeSound] RIGHT below the [Object] with the StatesFunction assigned.
BTW, about the door TranslateZFormula, I have written a convenient calculator to generate working formulas easily. You can use it at https://zbx1425.tk/obvemainsite/doorzfunc.html . It is in Simp Chinese but I am sure that would not be a problem for you.

As many developers who had made use of Night & Day texture bug have quit developing, so it is not quite possible for them to patch their routes and trains. So we must either add an enormous amount of content-specific hacks, or just leave the bug there and maybe add an optional argument in CSV to turn on for correct behavior. Just like what we did for Options.ObjectVisibility .

One of the problems here is that I'm primarily European based, and I don't directly do written Chinese.

If the players / developers from HKRSC don't communicate with me / report things with issues & just reccomend an older version, it's *incredibly* hard for me to gauge exactly how big a problem really is.
Adding a hack to control this is easy and quick if required, and I think a far better solution.

From a software development point of view (and for that matter a consistancy point of view), being broken by default is what I can only describe as terminally stupid, and causes even greater problems in the long-run.
I could understand it a little better if the bug produced a logical effect, but there's absolutely no sensible reason for it to produce unlight polygons.

---

If I can have a list / links to what you know is broken, I'll take a closer look at the amount of work required to implement a hack.

zbx1425 wrote:

LXQt wrote:I would like to add the sound to this object. Using the code given above, the entire door will disappear without error.
do I put the [StateChangeSound] section below this object?

Also is there any plan for content specific hacks for HK Route, I've heard that they would keep using the duplicate texture instead of SetEmissiveColor, plus some trains stopped updating. Once they entered the tunnel(or .brightness 0), only few objects remains bright in the interior.

I used a little hack, as [StateChangeSound] uses the StateIndex of the last Object as its sound index. So you can see I used the doorstarget as StatesFunction at the door object, and used two same States so the StatesFunction does not affect the appearance, and only the following [StateChangeSound] section makes use of it to choose the sound. You do have to put the [StateChangeSound] RIGHT below the [Object] with the StatesFunction assigned.
BTW, about the door TranslateZFormula, I have written a convenient calculator to generate working formulas easily. You can use it at https://zbx1425.tk/obvemainsite/doorzfunc.html . It is in Simp Chinese but I am sure that would not be a problem for you.

As many developers who had made use of Night & Day texture bug have quit developing, so it is not quite possible for them to patch their routes and trains. So we must either add an enormous amount of content-specific hacks, or just leave the bug there and maybe add an optional argument in CSV to turn on for correct behavior. Just like what we did for Options.ObjectVisibility .

I am planning to make toggleable light and it would require StateFunction(to switch between the dimmed version), I don't think there is way to fit in these 2? Is there any alternative solution for this?
Also thanks for the tools, I will find the data I need later.
And for the Day Night Texture bug, I would like it to be an options in the OpenBVE program itself(default is not to fix the bug). In my case, it affects the train most, here is a screenshot of Winsome's M-train(discontinued) on the 04-04-20 build with the new render options turned on, brightness 0.

As you can see, almost everything is dimmed. Despite getting over 60fps(before is 40fps), it is surely not an enjoyable experience and I am not happy about it.
p.s. content specific hacks sounds like a (sort of) more fair options

zbx1425 wrote:The problem is that the door opening-closing sound must be triggered EXACTLY the same time when the doortarget changes, so the StateChangeSound must be used, and Sound cannot achieve this since it is looping (Am I understanding this correctly?) and can be played "halfway".
My current .animated code is also not perfect, as it would not stop the closing sound when it is reopened. I hope you can bring me a better solution about this problem.
There are requirements of triggering a sound from the beginning at a time. It would be nice if we have more control over this once the sound is triggered, like stopping it in the door reopening scenerio.

Not exactly; The sound should only play once.

When the controlling state changes (e.g. the DoorsTarget), the *new* sound will immediately be queued for playback on the next frame, so there will be something in the order of a 16ms delay (assuming 60fps) from the absolute change to the first playback.
You've also got to remember the rounding issue, in that your animation will probably be slower to physically start moving.

However, if a *previous* state change sound is currently playing, this will finish before the new one starts.

Could probably add another option to control whether the previous sound is stopped.

leezer3 wrote:From a software development point of view (and for that matter a consistancy point of view), being broken by default is what I can only describe as terminally stupid, and causes even greater problems in the long-run.
I could understand it a little better if the bug produced a logical effect, but there's absolutely no sensible reason for it to produce unlight polygons.

I think that makes a bit sense, as assigning the same Day & Night image in panel2.cfg does produce a self-illuminate component. And that might be the reason for this design oversight.
I agree with your idea that just keeping this bug is silly. But I think the amount of trains and routes making use of this would not be under 10. I don't have an idea about this, so I would leave this part to Mr. LXQt, who has a better view on the BVE routes in HK than me.
This must be handled carefully, as fixing this bug breaks many trains, and not fixing these bugs caused by fixing the bug () would just stop players from upgrading.

BTW, talking about the version problem, this paragraph is right there written in the FAQ section of HKRSC's (formal) official website (they updated the whole website yesterday and I haven't got to see that):

https://hkrsc.zbx1425.tk/hkrailsimcentre.weebly.com/209862969437679354923005938754.html wrote:[size=32]​​出現錯誤畫面[/size]
部份路綫及列車並不兼容較新版本的程式，進入時或會出現錯誤畫面
​解決方法：下載較舊版本的openBVE程式(例如1.4.3.1)，然後重新進行遊戲
[size=32]​​Error dialog is displayed[/size]
Some of our trains and routes are not compatible with the newer versions of openBVE, and would cause error when loaded.
​Solution: Play with an older version of openBVE (Such as 1.4.3.1).

That error screen picture suggests that something is failing to load completely, which is unrelated to the lighting change.

Will try and look at all their content today and see if something falls over.

As an experiment, I've added a fix controlled by the existing Enable Hacks for Buggy Older Content checkbox. Not really very happy with this as a solution mind.......
I believe this fixes the issue, although some lighting may be slightly different in the new renderer.

zbx1425 wrote:I agree with your idea that just keeping this bug is silly. But I think the amount of trains and routes making use of this would not be under 10. I don't have an idea about this, so I would leave this part to Mr. LXQt, who has a better view on the BVE routes in HK than me.

I've just talked to the developers in Hong Kong, they agree that adding hacks is the only solution to this. Even WIP Projects (started before 1.7.1 released) used the bug above, (The entire route is making use of  the bug) It would take forever for them to change all the code if they have to, so adding hacks would be a better options.

leezer3 wrote:That error screen picture suggests that something is failing to load completely, which is unrelated to the lighting change.

Will try and look at all their content today and see if something falls over.

As an experiment, I've added a fix controlled by the existing Enable Hacks for Buggy Older Content checkbox. Not really very happy with this as a solution mind.......
I believe this fixes the issue, although some lighting may be slightly different in the new renderer.

This partially solves issues for train interior graphics, though may not necessarily work for station structure (e.g. walls, platform screen doors)

On the other hand, I have a rendering issue that breaks textures, regardless of 'lighting bug' usage, that expands to 2D markers; this issue is not only occurring on Nvidia graphics cards (GTX 970 and 1070) but also AMD GPU users.

If possible, can you please investigate this? We're scratching our heads here, and despite attempts to curb this such as disabling the onboard iGPU,  it eventually resurfaces on a 30~50% chance per launch.

For better context, the ATP Marker on the top right corner is fried, along with the track concrete texture (which does not use any lighting coding)

This phenomenon is random in nature and may corrupt/destroy textures at random; the following is a more severe example:


For comparison, the following is how it would be rendered normally:

I don't think I've ever seen anything like that.

The pole in the second image suggests memory corruption, but I can't immediately think how this could occur- The static pattern says to me that this can't be a lighting or shader issue.

Experimental thought- Try enabling (or disabling) Unload Unused Textures

Another thought-
You're using the overlay map in the second corrupted image.
Does the issue go away if you don't use this?

(This constantly updates a texture, which makes me suspicious)

leezer3 wrote:Another thought-
You're using the overlay map in the second corrupted image.
Does the issue go away if you don't use this?

(This constantly updates a texture, which makes me suspicious)

Regarding the overlay map, the texture corruption occurs with or without the overlap map, so I find it rather odd.

leezer3 wrote:I don't think I've ever seen anything like that.

The pole in the second image suggests memory corruption, but I can't immediately think how this could occur- The static pattern says to me that this can't be a lighting or shader issue.

Experimental thought- Try enabling (or disabling) Unload Unused Textures

Unload Unused Textures seems to stabilize the rendering, though it makes FPS drop slightly.
Would heavy route and/or train files cause memory corruption to occur easily? I definitely won't call the files from the Hong Kong community light-weighted by any means.

OmegaZeroKiller wrote:Unload Unused Textures seems to stabilize the rendering, though it makes FPS drop slightly.
Would heavy route and/or train files cause memory corruption to occur easily? I definitely won't call the files from the Hong Kong community light-weighted by any means.

Well, talking about memory, although I am not a single bit professional about this, maybe carrying out a MemTest86 https://www.memtest86.com/ would spot hardware issues.
Have seen people encounter weird problems because of faulty RAMs. Not on openBVE though.
And it is fat chance that hardware is really the cause, but I just wanted to speak something...

As Unload Unused Textures works & stops the issue, my strong suspicion would be that you're running out of available video RAM.
In *theory*, the drivers ought to handle this case gracefully, but something isn't quite right obviously.

I'll take a look and see if I can reproduce on a lower-end machine.

Some TLDR about the Hong Kong content:
A massive problem I'm seeing from digging around in what I've got saved is texture sizing and number of textures.
The compressed on-disk size is *not* what the texture will take up in VRAM- This is (roughly) the following:
First, the texture will be internally upscaled by the driver to the nearest power of two.
Either 3 (RGB) or 4 (RGBA) bytes per pixel.
An simple animated escalator from the Choi Hung to Whampoa route is eating well over 200mb of texture memory, and uses 11 unique textures.
With a little resizing of textures and object work, I could probably drop this to one texture at a quarter of the size.

The route has 658 textures in total, and so at a rough guess you're looking at somewhere around 20gb maximum theoretical video memory usage with a 3D train.

leezer3 wrote:As Unload Unused Textures works & stops the issue, my strong suspicion would be that you're running out of available video RAM.
In *theory*, the drivers ought to handle this case gracefully, but something isn't quite right obviously.

I'll take a look and see if I can reproduce on a lower-end machine.

Some TLDR about the Hong Kong content:
A massive problem I'm seeing from digging around in what I've got saved is texture sizing and number of textures.
The compressed on-disk size is *not* what the texture will take up in VRAM- This is (roughly) the following:
First, the texture will be internally upscaled by the driver to the nearest power of two.
Either 3 (RGB) or 4 (RGBA) bytes per pixel.
An simple animated escalator from the Choi Hung to Whampoa route is eating well over 200mb of texture memory, and uses 11 unique textures.
With a little resizing of textures and object work, I could probably drop this to one texture at a quarter of the size.

The route has 658 textures in total, and so at a rough guess you're looking at somewhere around 20gb maximum theoretical video memory usage with a 3D train.

Update on the situation: Texture corruption still occurred after Unloading Unused Textures, so that's ruled out for now.

For better reference, here are the specs of my development environment:
CPU: i7-4790K@4.00Ghz
RAM: 32GB DDR3 1600Mhz
GPU: Nvidia GeForce GTX 1070 DDR5 8GB
OS: Windows 7 Ultimate SP1 64-bit

Not entirely sure, but I believe 8GB of VRAM should be rather sufficient for 3D rendering, which is why I find the issue extremely odd, especially when it has occurred on a range of machines, including but not limited to units sporting an Nvidia GT650 Ti with 1GB of VRAM, to AMD VEGAS Pro.

In addition, this includes, but not limited to, Hong Kong routes and light-weight, BVE4-era Japanese routes alike (JR East Nambu Branch Line), which further compounds the situation.

P.S. I haven't mentioned this because I had yet to join here or the Japanese community chats back then, but this phenomenon had actually persisted since 2016, when the menu UI had a major changeover; not solely on Windows, but also on other platforms, including but not limited to Ubuntu Linux (on the same unit) and OS X Yosemite (on a MacBook Pro 15', Mid-2014).