Making a plugin survive driver swaps

I took the same approach, controlling realtime status via EnterRealtime and ExitRealtime.



So assuming you're checking for realtime via ScoringInfoV01.mInRealtime, it should suffice to maintain a current realtime status and check against it; when the state changes either way, run the Enter/Exit code, and everything should be dandy. Might give that a go then.
I also check against ScoringInfoV01.mVehicle.mIsPlayer every update as I think you might be in mInRealTime when you're a passenger waiting for a change or when you're pass the car to another player.


long playerSlot = 0;

void VHUD::UpdateScoring(const ScoringInfoV01& info)
{
inRealtime = info.mInRealtime;
isPlayer = IsPlayer(info);

if (!inRealtime || !isPlayer)
return;

// Your code here
}

bool VHUD::IsPlayer(const ScoringInfoV01 & info)
{

//If the player connects as a spectator to a empty server
if (info.mNumVehicles < 1)
return false;

//Our vehicle most likely have the same index once we got it so let's look there first
if (info.mVehicle[playerSlot].mIsPlayer)
return true;

//Loop through the whole grid looking for the player's vehicle
for (long i = 0; i < info.mNumVehicles; ++i)
{
if (info.mVehicle.mIsPlayer)
{
playerSlot = i;
return true;
}
}

//Player's vehicle not found
return false;
}
 
Last edited:
I took the same approach, controlling realtime status via EnterRealtime and ExitRealtime.



So assuming you're checking for realtime via ScoringInfoV01.mInRealtime, it should suffice to maintain a current realtime status and check against it; when the state changes either way, run the Enter/Exit code, and everything should be dandy. Might give that a go then.
@Lazza do you think shared memory plugin should expose both versions of mInRealtime, for example, mInRealtime set by function call and mInRealtimeScoringUpdate set via ScoringInfo, so that users have more information available? I could also try to combine both into one variable.

EDIT: actually I have been thinking about this and I will expose both variables via shared memory. This will give clients most flexiblility to decide how to respond.
 
Last edited:
@The Iron Wolf yeah, both sounds best for transparency.

I changed my plugin as described earlier, a quick SP test seemed to work as normal, so when I get a chance I'll do a test build and see if anyone can test a swap with it. Darn work getting in the way.
 
@The Iron Wolf yeah, both sounds best for transparency.

I changed my plugin as described earlier, a quick SP test seemed to work as normal, so when I get a chance I'll do a test build and see if anyone can test a swap with it. Darn work getting in the way.
Hopefully, one day we'll see source of DAMPlugin, would be great to learn from your experience, instead of reinventing the wheel :)

I'll expose those variables in the next couple of weeks, luckily I am the only user atm, so I can not bother with compatibility :)

work in a way of modding, sounds familiar :)
 
Last edited:
@The Iron Wolf 2 reasons you won't see my source code... first, I'm an ugly programmer (not just behind the keyboard!) and I don't want to embarrass myself. Second, what I've worked out could be used to compete directly with Motec products, which I don't want to encourage or support.

Anyway, I've just built a test version of my DAMPlugin to see if it works any better with driver swaps. Can anyone try it out at some point? Thanks :)

https://forum.studio-397.com/index.php?threads/damplugin-for-rf2.49363/page-10#post-880298
 
I hope that studio397 give attention to this topic, because using spectator mode to make driverswap is a workaround that is causing this kind of problems. Ideally, the driverswap should be done entering as a driver.
 
Last edited:
I hope that studio397 give attention to this topic, because using spectator mode to make driverswap is a workaround that is causing this kind of problems. Ideally, the driverswap should be done entering as a driver.

It's not a workaround, it's almost necessary, otherwise you'd be having carmodels loading in and out of memory all the time during the race, so you would either race against a lot of "temporary cars" or experience lags as the new cars load.
 
It's not a workaround, it's almost necessary, otherwise you'd be having carmodels loading in and out of memory all the time during the race, so you would either race against a lot of "temporary cars" or experience lags as the new cars load.

sry about lack of precision in my argument, what i'm trying to say, is that we need a team system, at point that when a driver enter the race, the simulator knows if the player car is already in the track. Like iRacing does in Team Racing.
 
Ok, it looks like my change in approach will work fine, I just have a strange bug in my DAMPlugin code and need to track down the culprit. But the data was all generated correctly, indicating the plugin activated and deactivated itself properly during driver swaps (both when taking control, and yielding it).

In summary:
- Don't rely solely on EnterRealtime and ExitRealtime; they don't get called in driver swap situations.
- Don't just check .mIsPlayer, check whether .mControl is 0 (and/or 1, if local AI control is acceptable). (I'm not 100% sure this is necessary, the video earlier suggests .mIsPlayer works fine, but it shouldn't hurt)

I suspect my remaining bug might be due to ScoringInfoV01.mInRealtime being true before the vehicle's .mControl changes to 0 (or .mIsPlayer changing to true). Guessing it might indicate realtime as soon as you jump into the car in spectate mode?

Big big thanks to @Josh.H for promptly testing and providing some clear logs to look at.
 
Well, the solution is the one Martin indicated:
I also check against ScoringInfoV01.mVehicle.mIsPlayer every update as I think you might be in mInRealTime when you're a passenger waiting for a change or when you're pass the car to another player.

So EnterRealtime() and ExitRealtime() update the state, but also UpdateScoring() has to, by way of ScoringInfoV01.mInRealtime.

Thanks Martin!
 
Back
Top