PDA

View Full Version : Another shared memory question - participant array ordering



mr_belowski
31-10-2017, 13:00
Ayup folks, got a quick data question. In shared memory there's no indication that the viewed participant is the player. We know which car is being viewed (in race or via the monitor) but we don't know if that car is the player.

Can we use the ordering of the participants array here? Is the local player always at position 0, even when viewing a different participant?

The UDP format has an 'isHuman' variable to help with this, but there's no equivalent in shared memory


For pcars 1 I wrote loads of horrible hacks to try and get the right participant for the player, but I really don't want to do this, and as far as I can see the only alternative is to assume the player is always at position 0

daniel_
31-10-2017, 13:26
I have the same question. However, for the time being I will stick with the currently viewed player and show his information.

However, the 'isHuman' - flag. What about multiplayer with AI? Some players will have the flag = true and some don't, right?

mr_belowski
31-10-2017, 16:28
from the UDP spec:

unsigned shortsCarIndex; // -- top bit shows if participant is (local or remote) human player or not

so i guess this isn't enough to identify the participant index of the local player.

Because Crew Chief builds up the race state (including the player's timing data) over the course of a session, being able to know whether a lap time or whatever is for the player is really important - if the app thinks data from other participants is actually for the player, the internal state gets really screwed up :(

mr_belowski
31-10-2017, 17:19
Answering my own question here -

"no" the order of the participants array is *not* consistent and the local player can be at *any* index online. The viewed participant index when you first enter a session is *not* always the same as the local player's viewed participant index - in one example I entered the session and this was '9', and when I clicked Drive it changed to '1'.

So I have no sensible way to establish who is the local player :(

mr_belowski
31-10-2017, 18:33
Fingers crossed it gets added to the data output. In the mean time I'm doing this:




int latestGuessAtPlayerIndexInThisSession = -1;
public static int getPlayerIndex(pCars2APIStruct pCars2APIStruct)
{
// we have no idea where in the participants array the local player is.
// Offline it's generally 0. Online it can be anything. We can't use mViewedParticipantIndex directly here because monitoring other
// cars will mess up the internal state. mViewedParticipantIndex can be wrong when you first enter a session so we
// can't just grab and reuse the first value we get.
//
// If we're 'playing' assume we're the player:
if (pCars2APIStruct.mGameState == (uint) eGameState.GAME_INGAME_PLAYING)
{
latestGuessAtPlayerIndexInThisSession = pCars2APIStruct.mViewedParticipantIndex;
}
// if we've never played in this session, return what the game tells us (might be wrong, it's the best we have):
if (latestGuessAtPlayerIndexInThisSession == -1)
{
return pCars2APIStruct.mViewedParticipantIndex;
}
return latestGuessAtPlayerIndexInThisSession;
}

daniel_
01-11-2017, 11:12
What about asking the player for his name? Should not change that often...

mr_belowski
01-11-2017, 11:15
i did that in pcars1. The issue here is that the player name may be misspelled, or contain characters that the UDP / shared memory String encoding (<cough> should always be UTF8 <cough>) can't represent. So relying on this is risky

daniel_
01-11-2017, 11:44
and letting the user choose? Like 'Hey, I found these people, who is you?' And then save this...

mr_belowski
01-11-2017, 12:06
again, because the game sends the Steam name, and loads of Steam names have non-Latin characters in them, the app will only receive the name text up to the point that the game encounters a character it can't encode in platform-default encoding (Cp1252 for windows I think). All the rest will be truncated

daniel_
01-11-2017, 12:08
ok, I see. "Please click here if you are watching yourself" - I get your point. Let's see how I will have to treat this.

bigj_pcars
06-01-2018, 10:53
hey guys ;)

from my experience (i use only shared memory) in pcars 1 the local player had index 0 in offline sessions
and in online sessions the owner/host of the lobby had index 0
so i did some similar to mr_belowski: searched the participants by name and saved the corresponding index (all the time) (i do the same in pcars2)
(at least it works ;) )

by the way @mr_belowsky: you started a string enconding in pcars thread
if u still need info: doesnt seem to be real or 100% UTF-8: i got the usual ascii values but also negativ values
if you still need it i can give u the list of all letters and correspondig values i found so far

EDIT: this thing could be Windows related

as u surely experienced ur self already: sometimes the * is in the name string data, most of the time names containing a * results in empty name string data
if im not mistaken: even pcars (1 and 2) is inconsitant in displaying such names (sometimes playername display is empty/ no name)

greetings ;)



didnt want to start a new thread, maybe u guys can help: (shared memory 2)

concerning mPitSchedules[]

which uses

// (Type#8) Pit Stop Schedule (to be used with 'mPitSchedule') => at least it would make sense, in the header file Type#7 is written, but must be a mistake?
enum
{
PIT_SCHEDULE_NONE = 0, // Nothing scheduled
PIT_SCHEDULE_PLAYER_REQUESTED, // Used for standard pit sequence - requested by player
PIT_SCHEDULE_ENGINEER_REQUESTED, // Used for standard pit sequence - requested by engineer
PIT_SCHEDULE_DAMAGE_REQUESTED, // Used for standard pit sequence - requested by engineer for damage
PIT_SCHEDULE_MANDATORY, // Used for standard pit sequence - requested by engineer from career enforced lap number
PIT_SCHEDULE_DRIVE_THROUGH, // Used for drive-through penalty
PIT_SCHEDULE_STOP_GO, // Used for stop-go penalty
PIT_SCHEDULE_PITSPOT_OCCUPIED, // Used for drive-through when pitspot is occupied
//-------------
PIT_SCHEDULE_MAX
};

is it possible this is not fully implemented yet?
when a driver/player gets a drive through penalty mPitSchedules[] is 5 => PIT_SCHEDULE_DRIVE_THROUGH
in all other cases mPitSchedules[] is 0
and stop-go is this ment to represent slow-down penalties?

thx ;)