-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Omsi Hook RPC Plugin #69
Conversation
…oed to external processes using OmsiHook via named pipes. + Created the project file
- Implemented a (slightly) thread safe, multi-client RPCPlugin server - Modified OmsiRemoteMethods to use OmsiHookRPCPlugin if not in an Omsi Plugin - Added GetMem and FreeMem method wrappers - Refactoring
- Memory.AllocateMemory() now uses OmsiGetMem() - OmsiRemotemethods is now static
- Memory reads now use a shared buffer to avoid allocations - Optional fast allocator added (not recommended) - Removed OmsiRemoteMethods from OmsiGlobals (might be temporary) - Bug fixes to OmsiRemoteMethods - Refactoring
- FreeMem now returns the freed address as it should - Renamed OmsiHookRPCPlugin folder - Added support for length prefixed (aka Pascal) strings - Fixed caching bug with MemArrayStringDicts - ReadMemory and WriteMemory now actually check if reads/writes are successful (much spam as a result, but it should encourage us to fix the broken struct definitions) - Added more error checking to array and string reading methods (it seems there are plenty of cases where these try to read invalid data) - Improved debug logging in MarshalStruct to hunt down incorrect marshalling - OmsiRemoteMethods initialisation is now done when you connect to Omsi - Removed some arrays from OmsiComplObjInst which weren't marshalling correctly, to be investigated - Fixed off by 1 error in the argument serialisation/deserialisation of remote method calls - Updated project platform configuration - Fixed many bugs in OmsiHookRPCPlugin & added proper support for multiple clients - Updated OmsiHookRPCPlugin .opl to read the Throttle variable which should always exist - Refactoring
Looking great, ill run some tests this evening |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Many changes, though none look too likely to break things outside of what you had already tested, im happy to approve - couple comments in there just to mess with you, please read them :P
} | ||
catch (Exception e) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pedantic but e is never used, throws a warn in the build
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e
is used in Debug builds (see the preprocessor block below), but not in Release, I could fix this at the cost of adding another preprocessor block, but who cares...
OmsiHook/OmsiComplObjInst.cs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you removed some properties, admittedly they where not implemented correctly to startwith
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we should investigate this, I can't remember if any of these arrays worked correctly before (I know some were broken but I didn't think they all were). Might be a regression.
|
||
[Obsolete] | ||
public int MakeVehicle() | ||
public static int MakeVehicle() | ||
{ | ||
int vehList = TTempRVListCreate(0x0074802C, 1); | ||
string path = @"Vehicles\GPM_MAN_LionsCity_M\MAN_A47.bus"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing this is demo data - probs shouldnt be pushed to prod, maybe bring to an example code or something 🤷
- Added StrPtrType enum to specify how strings are marshalled as an alternative to using the separate boolean flags - OmsiStrArrayPtrAttribute now supports pascal strings - Fixed bug when reading wide pascal strings - Fixed some struct definitions
This pull request isn't ready for merging quite yet and needs some extensive testing. Especially with regards to regression testing as I probably broke a bunch of stuff.