Open IstuntmanI opened 7 years ago
You forgot about passengers.
It looks like I always forget about passengers. 😆 Thanks. I wasn't sure if OnEnterExitModShop
is called for passengers too, so I searched for "OnEnterExitModShop
passengers" and I see that someone already tried to solve this issue: http://forum.sa-mp.com/showthread.php?t=520391 . From that it looks like it isn't called for passengers. Edited the possible implementation in the OP.
Temporarily change player's virtual world to
playerid+1
Say I have a mode that is divided into different submodes with each a different virtual world assigned, and by just using GetPlayerVirtualWorld you know what submode a player is in. There are no other variables that keep track of what submode a player is in.
Within your solution, the possible virtual worlds for modshops range from 1 to 1000. Given this, say a submode uses one of the virtual worlds in that range. This could potentially break the user's script when GetPlayerVirtualWorld is used to know what submode a user is in while he is in the modshop.
To fix this, either the user could update his script, which is ... not optimal, since this include is meant to fix things, not introduce new bugs when any breaking effects are known in advance, of which this example is one. Or you could provide a starting value which the user can redefine before including the include and otherwise use the default behaviour. Which is better than the former, but still not optimal, since the user has to know of the default behaviour of this fix, or have the starting value redefined.
//myscript.pwn
#define SOME_STARTING_VW 1000
#include <fixes>
//fixes.inc
#if !defined SOME_STARTING_VW
#define SOME_STARTING_VW 0
#endif
SetPlayerVirtualWorld(i, SOME_STARTING_VW + playerid);
There are over 2 milliard virtual worlds, I'm sure we can find an addition that doesn't conflict, and even hook SetPlayerVirtualWorld
to give a warning if it uses a reserved one. I like playerid + 0x73654C59
.
Then maybe use VWs somewhere in the back, instead of in the front, since those are a lot less likely to be used already. I also like the idea about the hook and warning.
What I said is pretty near the back, and quite random really - nothing close to a neat number, so unlikely to have been taken. People tend to favour numbers like 1000
not 1936018521
.
Why wouldn't we just refuse the player updates when they are in modshops? so they wont stream to each other and wont collide?
Why wouldn't we just refuse the player updates when they are in modshops? so they wont stream to each other and wont collide?
Because other players will see players in garage.
Players are colliding with each other when they are in mod shops.
Temporarily change player's virtual world to
playerid+1
when entering a mod shop and set it back to the old one when they leave. This helps a lot: http://wiki.sa-mp.com/wiki/OnEnterExitModShop . Additionally, we should provide aIsPlayerInModShop
.new gFIXES_PlayerInfo[ MAX_PLAYERS ][ gFIXES_PlayerInfoEnum ];
/ < resetting gFIXES_PlayerInfo[ i ][ _FIXES_inModShop ] under OnPlayerConnect > /
public OnEnterExitModShop( playerid, enterexit, interiorid ) { if( _FIXES_inModShop == enterexit ) // already has that mod shop status, probably hacking ? { Kick( playerid ); return 1; }
}
stock bool:IsPlayerInModShop( playerid ) { if( !_FIXES_IN_RANGE( playerid, 0, MAX_PLAYERS ) ) return 0;
}