Currently, OMSIPresence only supports the latest Steam version (2.3.004) of OMSI 2, due to version-specific memory offsets required for the plugin to run.
The issue was caused by a recent change in 1.0 which added support for logfile.txt entries - the plugin's logging function calls a game function, AddLogEntry (the original name of the function is unknown, this is the custom name i gave the function), which writes to the log file. As this is a game function, a version-specific memory offset is required for it to work.
Unfortunately, OMSIPresence's logging function is active way before any game version checks are made, causing the plugin (and thus, the game) to jump to whatever was stored in memory at address 0x8022C0 - usually garbage and not real machine code. When this happened, the two most common error types can be observed:
Externe Exception C000001D - which is a code for "illegal instruction"
Errors mentioning an address/hex number within the vicinity of 008022C0
The intended behavior was for the plugin to show an error instead (not the game), indicating that OMSIPresence does not support the currently running version of OMSI 2, and remain dormant in the game (it can't be detached as OMSI 2 keeps track of all its plugins until they're finalized - prematurely detaching from the game results in endless errors upon attempting to exit the game and thus the game must be closed in an unsafe manner) - ie. it will do nothing (not to waste performance).
This is because it can be incredibly annoying to keep moving the plugin in and out of the plugins folder for users that, for example, switch between the two most popular OMSI 2 versions: Steam latest (2.3.004) and "Tram patch" (2.2.032) - as they both have their own pros and cons.
Originally, I've considered not logging anything before the actual version check, but sometimes this may not be ideal, in case earlier something goes wrong earlier in the plugin's startup procedure. Logging can still be useful in that case, as debug mode may be active - outputting to the debug console works independently from the game and thus is not version specific.
Thus, the fix that I've employed is to set a global variable g::version_supported (which is false by default) to true if version checking was successful, and only then allow the plugin to call AddLogEntry as we know that the version-specific memory offset for it is correct. An update will be released in the coming hours/days, depending on free time and testing success.
Related issue: Support for OMSI 2 version 2.2.032 - "Tram patch" (#5)
If you are unsure whether this is your issue, feel free to create a new one - you will be referenced to this one if it is.
brokenphilip
commented
9 months ago
Currently, OMSIPresence only supports the latest Steam version (2.3.004) of OMSI 2, due to version-specific memory offsets required for the plugin to run.
The issue was caused by a recent change in 1.0 which added support for
logfile.txtentries - the plugin's logging function calls a game function,AddLogEntry(the original name of the function is unknown, this is the custom name i gave the function), which writes to the log file. As this is a game function, a version-specific memory offset is required for it to work.Unfortunately, OMSIPresence's logging function is active way before any game version checks are made, causing the plugin (and thus, the game) to jump to whatever was stored in memory at address
0x8022C0- usually garbage and not real machine code. When this happened, the two most common error types can be observed:Externe Exception C000001D- which is a code for "illegal instruction"008022C0The intended behavior was for the plugin to show an error instead (not the game), indicating that OMSIPresence does not support the currently running version of OMSI 2, and remain dormant in the game (it can't be detached as OMSI 2 keeps track of all its plugins until they're finalized - prematurely detaching from the game results in endless errors upon attempting to exit the game and thus the game must be closed in an unsafe manner) - ie. it will do nothing (not to waste performance).
This is because it can be incredibly annoying to keep moving the plugin in and out of the
pluginsfolder for users that, for example, switch between the two most popular OMSI 2 versions: Steam latest (2.3.004) and "Tram patch" (2.2.032) - as they both have their own pros and cons.Originally, I've considered not logging anything before the actual version check, but sometimes this may not be ideal, in case earlier something goes wrong earlier in the plugin's startup procedure. Logging can still be useful in that case, as debug mode may be active - outputting to the debug console works independently from the game and thus is not version specific.
Thus, the fix that I've employed is to set a global variable
g::version_supported(which isfalseby default) totrueif version checking was successful, and only then allow the plugin to callAddLogEntryas we know that the version-specific memory offset for it is correct. An update will be released in the coming hours/days, depending on free time and testing success.Related issue: Support for OMSI 2 version 2.2.032 - "Tram patch" (#5)
If you are unsure whether this is your issue, feel free to create a new one - you will be referenced to this one if it is.