It is possible to write a DLL that receives data from the simulated bike in realtime.
Example source code can be downloaded at http://www.gp-bikes.com/?page=downloads
Please note that all function calls are blocking, so control should be returned to simulation as soon as possible to avoid framerate issues.
The DLL must be compiled for 64 bit.
The plugin must have the file extension renamed to DLO and it must be copied to the "gpbikes/plugins" directory in GP Bikes installation folder.
NOTE: a license is not needed to add plugins.
Example source code updated to the latest interface.
What has changed ? I've seen the GetModDataVersion has been moved to 2 (from 1), but is there anything else ?
I don't see the centerline stuff.
MaX.
Quote from: HornetMaX on December 15, 2013, 03:21:12 PM
What has changed ? I've seen the GetModDataVersion has been moved to 2 (from 1), but is there anything else ?
I don't see the centerline stuff.
MaX.
m_szEngineMapping has been added.
Example source code updated to include the TrackCenterline definition.
Quote from: PiBoSo on December 15, 2013, 05:06:16 PM
Example source code updated to include the TrackCenterline definition.
Can't see it yet in the download section: gpb_example.c is still as before (nothing related to the centerline).
MaX.
Got the centerline stuff now, thanks !
MaX.
Now that I try to play with it, I do think that it would have been much better to have the centerline stuff (int _iNumSegments, SPluginsTrackSegment_t *_pasSegment) passed as extra arguments of EventInit instead of introducing a new function (TrackCenterline). As the info is track-related, it makes sense for it to be in EventInit.
MaX.
Quote from: HornetMaX on December 16, 2013, 02:02:21 AM
Now that I try to play with it, I do think that it would have been much better to have the centerline stuff (int _iNumSegments, SPluginsTrackSegment_t *_pasSegment) passed as extra arguments of EventInit instead of introducing a new function (TrackCenterline). As the info is track-related, it makes sense for it to be in EventInit.
MaX.
It makes sense to have different functions, because those writing a dash plugin, or a telemetry plugin, can completely skip the centerline.
Quote from: PiBoSo on December 16, 2013, 09:43:21 AM
Quote from: HornetMaX on December 16, 2013, 02:02:21 AM
Now that I try to play with it, I do think that it would have been much better to have the centerline stuff (int _iNumSegments, SPluginsTrackSegment_t *_pasSegment) passed as extra arguments of EventInit instead of introducing a new function (TrackCenterline). As the info is track-related, it makes sense for it to be in EventInit.
MaX.
It makes sense to have different functions, because those writing a dash plugin, or a telemetry plugin, can completely skip the centerline.
Well, ignoring two extra arguments doesn't seem very complicate.
On the other hand, as the number of quads will be only known once TrackCenterline is called, one has to defer the allocation until then (previously I was allocating everything at EventInit).
This is not a bug deal, but is TrackCenterLine called always ? Even when a track has no centerline ?
MaX.
Quote from: PiBoSo on December 15, 2013, 05:06:16 PM
Quote from: HornetMaX on December 15, 2013, 03:21:12 PM
What has changed ? I've seen the GetModDataVersion has been moved to 2 (from 1), but is there anything else ?
m_szEngineMapping has been added.
Hmm, I'm working on some telemetry stuff (plugin to log data in binary format and external app to visualize it).
I'm not sure that having "char m_szEngineMapping[100];" in each Telemetry data point is a good idea ... 100 bytes at each point when a simple integer (index of the mapping) could do the same work (more or less). Maybe the Mapping names (strings) can be provided in ther Event structure, so that the int can directly reference them.
No big deal, as most likely I'll write out individual values instead of the entire structure.
MaX.
Example source code updated to the latest interface.
Example source code updated to add info about track centerline data.
Thx.
Example source code updated to the latest interface.
Bit confused, but am i right in understanding GPB should make the call to this function 'Startup' when the program starts?
FILE *g_hTestLog;
/* called when software is started */
__declspec(dllexport) int Startup(char *_szSavePath)
{
g_hTestLog = fopen("gpbikes_log.txt","wt");
if (g_hTestLog)
{
fprintf(g_hTestLog,"Startup\n");
}
/*
return value is requested rate
0 = 100hz; 1 = 50hz; 2 = 20hz; 3 = 10hz; -1 = disable
*/
return 3;
}
I cannot see the file 'gpbikes_log.txt' on my system which suggest this never executes. As it also sets the data rate for GPB output i cannot see any reason to call it from my host.
Where would the default path for log file be?
Am i right jn assuming the rate the is how often the shared memory area information is refreshed?
Thanks
@h106frp: if you're compiling c++ you have to put extern "C" before all __declspec(dllexport)
Should be like this:
extern "C" __declspec(dllexport) int Startup(char *_szSavePath)
{
... ...
MaX.
Thanks, i will recompile,still getting to grip with C++
If you only want to use C you won't need the "extern" declaration. But you need to tell your compiler that you want to compile C-style :)
MaX.
All good now :) Acceleration outputs looking more like i was hoping for at 100Hz rate :)
Example source code updated to the latest interface.
Oh damn, more work :)
Thanks !
MaX.
Example source code updated to the latest interface.
The only change is the addition of m_fTrackPos to SPluginsRaceTrackPosition_t
Since this structure was probably still unused, no changes have been made to version checking, to preserve compatibility.
Quote from: PiBoSo on February 18, 2016, 04:21:28 PM
Example source code updated to the latest interface.
The only change is the addition of m_fTrackPos to SPluginsRaceTrackPosition_t
Since this structure was probably still unused, no changes have been made to version checking, to preserve compatibility.
Thx (and no problem for me about the ninja change).
One question however: it seems to me that the issue discussed here (http://forum.kartracing-pro.com/index.php?topic=5478.0) (client not being able to know his own race number, or the number of the bike being watched, if in replay mode on a bike-attached camera) is still not solved.
Quote from: HornetMaX on February 18, 2016, 08:19:22 PM
Quote from: PiBoSo on February 18, 2016, 04:21:28 PM
Example source code updated to the latest interface.
The only change is the addition of m_fTrackPos to SPluginsRaceTrackPosition_t
Since this structure was probably still unused, no changes have been made to version checking, to preserve compatibility.
Thx (and no problem for me about the ninja change).
One question however: it seems to me that the issue discussed here (http://forum.kartracing-pro.com/index.php?topic=5478.0) (client not being able to know his own race number, or the number of the bike being watched, if in replay mode on a bike-attached camera) is still not solved.
RaceVehicleData should receive the data you need, using the SPluginsRaceVehicleData_t structure.
Quote from: PiBoSo on February 18, 2016, 08:38:42 PM
RaceVehicleData should receive the data you need, using the SPluginsRaceVehicleData_t structure.
Embarassing, I dind't even notice it :-[
Thx !
Hi All
This is a great post!!! I want to use this simulator for a few projects that I have in the works, and I was wondering if I could get real time data, this is great, now I know I can. One question what about GPS, can I have the simulator output a NMEA sentence, or perhaps simply the GPS coordinates?
Example source code updated to the latest interface.
Example source code updated to the latest interface.
Removed the "semaphore" session state only.
Totally minor, but I still see the "semaphore" state in the comments of the example.
Example source code updated to the latest interface.
Example source code updated to the latest interface.
Example source code updated to the latest interface.
Please note that, starting with Beta14, output plugins must be compiled for 64 bit.
Example source code updated with the latest structure members descriptions.
Example source code updated to the latest interface.
Hi. Does anyone know what is the structure and the variable that indicates the status REPLAY ON? I have been checking the plugin example gpb_example.c but not sure. I know that there are RACE, PRACTICE, QUALIFY ... etc .. Thanks for your work.
Quote from: UMO on May 05, 2020, 08:59:58 AMHi. Does anyone know what is the structure and the variable that indicates the status REPLAY ON? I have been checking the plugin example gpb_example.c but not sure. I know that there are RACE, PRACTICE, QUALIFY ... etc .. Thanks for your work.
Replay, Spectate or On-Track are given by _iState in the Draw call:
/*
_iState: 0 = on track; 1 = spectate; 2 = replay.
Set _piNumQuads to the number of quads to draw.
Set _ppQuad to an array of SPluginQuad_t structures.
Set _piNumString to the number of strings to draw.
Set _ppString to an array of SPluginString_t structures.
This function is optional
*/
__declspec(dllexport) void Draw(int _iState,int *_piNumQuads,void **_ppQuad,int *_piNumString,void **_ppString)
{
*_piNumQuads = 0;
*_piNumString = 0;
}
@HornetMax: New dlo done and working :D but I observed that Piboso does not generate telemetry in the replays :'( A shame! It is a limitation. Do you know why it is not generated?
Quote from: UMO on May 07, 2020, 12:17:51 PM@HornetMax: New dlo done and working :D but I observed that Piboso does not generate telemetry in the replays :'( A shame! It is a limitation. Do you know why it is not generated?
Because it would make the replay too big, likely.
Example source code updated to the latest interface.
Example source code updated to the latest interface.
Example source code updated to the latest interface.
Example source code updated to add a couple functions to control the replay / live riders and cameras selection.