Touch zones & commands behave weirdly

[NYCTRailer]

When setting up a train panel.animated with touch operation, under the same command, each time a touch event happens, the command index shifts... The following video is a little test i set up to demonstrate that, notice how the same command is used on most elements being shown.

Also the command index value is not consistent with the enum value given in the commands list according to the source code, at least when using the "Security" commands

https://youtu.be/I3tOC70A03U

[leezer3]

I'm sure someone has brought this up before, but I can't see it at the minute...

https://github.com/leezer3/OpenBVE/blob/master/source/OpenBVE/Graphics/Renderers/Touch.cs#L342
The command index is slightly or at least non-intuitive; it's the index to the current internal controls array (as displayed in the controls options window), not the actual enum.
This is set via the touch file parser:
https://github.com/leezer3/OpenBVE/blob/master/source/Plugins/Train.OpenBve/Panel/PanelAnimatedXmlParser.cs#L415
Essentially, it adds a 'new' instance of the appropriate control with a new actuator, and hits this on the backend.

All of this is code S520 wrote, and possibly could be optimised a bit, but it's not something I've got around to playing much with....

---

I can't immediately see any reason why the indicies should change though.
I suspect you're probably duplicating the command. In the XML in the backdrop of your video, you've got SECURITY_M defined twice in one of the command entries.
This would effectively trigger two keypresses of SECURITY_M with ascending command indicies, as there's no check for duplicate entries.

[leezer3]

I've thought about it some more...

If you've got multiple zones with the same command, then yes this will use a different command index for each.

---

Perhaps a better question is to ask what's actually broken, rather than looking at your sympton video.

Is it that the commands aren't being passed to the plugin correctly, or what exactly?
I'm not sure how you're getting the message popup either; is this the plugin doing it or what?

Will do some more checking, but it's absolutely the wrong time of year to be thinking too much the week before Christmas :)

[NYCTRailer]

The message popup is a little test i made via the plugin, when i noticed the command index didnt line up with the enum value, i was trying to figure out which values are really being passed on. So in the touch event method i read the passed on indicies using a message box.

But considering the fact that each zone under the same command passes a different index makes me think that each command entry definition in the xml file is taken into account as new controls and added at the end of the controls array in the order they are defined in the file, if this is true then the above behavior is expected.

Notice how its irrelevant if its Security_L or Security_M... it just takes the index sequentially rather than by reference which is what i expected

[NYCTRailer]

Yeah i think my suspicion is correct, the following is my local controls.cfg file and if we turn on line numbers in the code and offset the controls list to start exactly at line 1, we reach the end of the list at line 116. Precisely from this point on, starting at 117 is when the indicies start in the touch commands and then passed on sequentially from there:

[leezer3]

That's correct.

I'm stilll not clear though as to whether something isn't working for you.

[AmberIsFrozen]

Notice how its irrelevant if its Security_L or Security_M... it just takes the index sequentially rather than by reference which is what i expected

By any chance this is the same as #895 (comment)? (Ignore all the keypad talk aside), that for plugin we are not able to correlate the command index with the command enum / a specific touch element.
We could hardcode a specific numeric value for checking, but that'd differ on everyone's computer configuration with different control list, so outside of "personal use" context / embedded environment (Where we have full control over the environment & the control list), the value obtained is not reliable enough to be put in use for addons to be distributed

[NYCTRailer]

Yeah exactly, so what im doing currently as a workaround is to read the touch events as if they were key presses taking advantage of the fact that touch events call the KeyUp method sending over the virtual key equivalent to the command... this method is kinda flawed though considering that keyboard inputs would make your touch zones/groups go out of sync with the setup if you press any actual physical keys and also some rare times there is a glitch where if you hold the touch zone too long or if you tap the touch zone in a specific way (near edges mainly) it would not call the KeyUp method with the key but the touch groups still update (if there is a jump screen for example) and this also makes the visual setup go out of sync with the touch zones.

I tried a similar setup to this workaround once where i tried to fix the two sync problems, which was to detect wether the touch event was raised before the command's intended actions where applied, but this ended up with an out of sync setup anyway and worse than the above. When the train was stationary it would work perfectly, but if you try touch while moving, for some reason there is no guarantee that the touch event and key up methods would be called sequentially in the same instance, so it breaks. 😞

[leezer3]

OK, so I don't think there's a backwards compatible way to do anything to this method. (although it's working entirely as designed)

With that in mind, I've added a new TouchEvent method to the interface.
This sends the Translations.Command associated with the control, not the index in the control array, and have marked the original method as obsolete.

Will need to put out a fresh public release at some point reasonably soon, so please test that and let me know if it'll now do what you want.
Once it's been in a public build, it really then needs to be fixed :)

[NYCTRailer]

Works as expected! though i had the message popup still in there, and it seems touch events really do not like it when its like that, apparently after the message box pops up within the same instance the touch event is raised, it looks like it skips the whole method and makes my setup go out of sync with the touch zones. However this is not of concern as it was only there for debugging, after i removed it, the setup works like a charm, made a few run tests and we're good! 😄

[NYCTRailer]

Alright so i ran into the first major issue after the build, similar to my alternative setup, rarely there is a chance that touch events dont call the touch event method but the touch zones update internally making my setup go out of sync, specifically when making contact near the edges of the touch zone (i think if you press the touch zone but run your mouse outside the touch zone while still pressing down, and then releasing is what causes this)

Yeah just confirmed, it happens if you try pressing down the touch element and then out the element while still pressing down, then releasing

[AmberIsFrozen]

Is it be backward compatible with existing plugin implementing IRawRuntime, or do they have to be recompiled?
Got a crash on a plugin that implements IRawRuntime (N.B. The plugin is private for now, it's not by me nor do I have the source code of it, and i haven't looked any closer to it)

2025-12-29 20:02:13
OpenBVE 1.7.2253.1201-lx86 Crash Log
Program is running on the Linux backend
Current screen resolution is: Windowed 960px X 600px 
Current routefile is: /media/ModAndGames/Simulation/OpenBVE/Content/Rail/Others/ISL (SACEM)/Railway/Route/ISL_UP_PeakHour.csv
Current train is: /media/ModAndGames/Simulation/OpenBVE/Content/Rail/Others/ISL (SACEM)/Train/M-STOCK
The current routefile caused the following exception: 
System.TypeLoadException: VTable setup of type SACEM_M.ApiProxy failed
  at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00029] in /build/mono/src/mono/mcs/class/corlib/System.Reflection/RuntimeMethodInfo.cs:951 
  at System.RuntimeType.CreateInstanceMono (System.Boolean nonPublic, System.Boolean wrapExceptions) [0x00095] in /build/mono/src/mono/mcs/class/corlib/ReferenceSources/RuntimeType.cs:185 
  at System.RuntimeType.CreateInstanceSlow (System.Boolean publicOnly, System.Boolean wrapExceptions, System.Boolean skipCheckThis, System.Boolean fillCache) [0x00009] in /build/mono/src/mono/mcs/class/corlib/ReferenceSources/RuntimeType.cs:155 
  at System.RuntimeType.CreateInstanceDefaultCtor (System.Boolean publicOnly, System.Boolean skipCheckThis, System.Boolean fillCache, System.Boolean wrapExceptions, System.Threading.StackCrawlMark& stackMark) [0x00027] in /build/mono/src/mono/mcs/class/referencesource/mscorlib/system/rttype.cs:5770 
  at System.Activator.CreateInstance (System.Type type, System.Boolean nonPublic, System.Boolean wrapExceptions) [0x00039] in /build/mono/src/mono/mcs/class/referencesource/mscorlib/system/activator.cs:206 
  at System.Activator.CreateInstance (System.Type type, System.Boolean nonPublic) [0x00000] in /build/mono/src/mono/mcs/class/referencesource/mscorlib/system/activator.cs:190 
  at System.Activator.CreateInstance (System.Type type) [0x00000] in /build/mono/src/mono/mcs/class/referencesource/mscorlib/system/activator.cs:134 
  at TrainManager.Trains.TrainBase.LoadPlugin (System.String pluginFile, System.String trainFolder) [0x001c6] in /media/ModAndGames/Simulation/OpenBVE/Program/OpenBVE-source/source/TrainManager/SafetySystems/Plugin/Plugin.Functions.cs:242 
  at TrainManager.Trains.TrainBase.LoadCustomPlugin (System.String trainFolder, System.Text.Encoding encoding) [0x00226] in /media/ModAndGames/Simulation/OpenBVE/Program/OpenBVE-source/source/TrainManager/SafetySystems/Plugin/Plugin.Functions.cs:97 
  at OpenBve.Loading.LoadEverythingThreaded () [0x0090d] in /media/ModAndGames/Simulation/OpenBVE/Program/OpenBVE-source/source/OpenBVE/System/Loading.cs:476 
  at OpenBve.Loading.LoadThreaded () [0x00002] in /media/ModAndGames/Simulation/OpenBVE/Program/OpenBVE-source/source/OpenBVE/System/Loading.cs:274   at System.Environment.get_StackTrace () [0x00000] in /build/mono/src/mono/mcs/class/corlib/System/Environment.cs:316 
  at OpenBve.Loading.LoadThreaded () [0x001fa] in /media/ModAndGames/Simulation/OpenBVE/Program/OpenBVE-source/source/OpenBVE/System/Loading.cs:303 
  at System.Threading.ThreadHelper.ThreadStart_Context (System.Object state) [0x00014] in /build/mono/src/mono/mcs/class/referencesource/mscorlib/system/threading/thread.cs:74 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00071] in /build/mono/src/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:968 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in /build/mono/src/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:910 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x0002b] in /build/mono/src/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:899 
  at System.Threading.ThreadHelper.ThreadStart () [0x00008] in /build/mono/src/mono/mcs/class/referencesource/mscorlib/system/threading/thread.cs:111 
Current program memory usage: 422.48mb
System memory free: 0mb

[leezer3]

It should be backwards compatible, that was the point of adding a new method.

If there's a copy of OpenBveApi.dll in the plugin's folder, please delete it- I think that's the most likely cause of this.
(This normally comes back to having two conflicting copies of the same library in the same path)

[AmberIsFrozen]

Couldn't find any copies there.
I've tried it over on Windows with .NET Framework, didn't crash though failed to load. The log gave a different error this time around, which I suspect might be the culprit? (No implementation for the new method in the interface, though since we're stuck on .NET Framework it seems we can't have a default interface method...)

13:58:43  Loading train plugin: D:\Simulation\OpenBVE\Content\Rail\Others\ISL (SACEM)\Train\M-STOCK\plugins\SACEM_M.dll
13:58:43  The train plugin SACEM_M.dll raised an exception on loading: Method 'TouchEvent' in type 'SACEM_M.ApiProxy' from assembly 'SACEM_M, Version=1.0.9492.5785, Culture=neutral, PublicKeyToken=null' does not have an implementation.
--------------------
13:58:56  Loading complete, starting simulation.