[IstuntmanI]

Quote:

Originally Posted by Dokins Have to agree with this in honesty and to the word, SA-MP is pretty irritating with vehicle ID's, I tried to fix this by making them match the MYSQL ID's therefore keeping track to the letter, but it didn't really work out, I re-wrote it to put into server sided variables and load in normally, but occasionally vehicles still appear on the wrong lists i.e When people do /myvehicles, they are given a random vehicle or something, very odd. I mean, I can't really see the need to have more than 2,000 vehicles spawned at the same time if I'm honest, but it is a nice idea, but the ID's are going to be chaos.

When I got problems with vehicle IDs I double-checked and found that they were caused by MY code (most of the time when I helped others with similar things I found *retarded* mistakes related to ID storing/usage which were definitely not some SA-MP bugs). I don't think SA-MP has any problem with vehicle IDs storing left (well, excepting the ones from train carriages, AFAIK they are really bugged), as I use them pretty much and never found bugs from SA-MP related to this. SA-MP even fixed in a previous 0.3 version some bug related to vehicle IDs which was, as far as I can remember, really hard to occur.

I don't get why some guys around here are against vehicle streamers. If you don't need that it doesn't matter that others won't find some useful thing to do with it. I personally can live really well without a vehicle streamer, by destroying vehicles when they are no longer needed (for example, when the house owner leaves the server), but with only 2000 vehicles most of the map is still empty and it is dull without any vehicle. For example, a server would look more attractive with few vehicles parked at houses on almost every street (by the way, I saw few years ago some servers with vehicle streamers which were FULL with vehicles (the radar had vehicle blips everywhere), never do that ! it makes the game laggy and ugly).

--------------

I can't really test the vehicle streamer now, as I don't have enough time, so here are few things:
1. We can still use regular non-dynamic vehicles without any bugs, even if using dynamic vehicles ? (as I said, I can't test)
2. Trains are really buggy in SA-MP, I forbidden them on my server too, just because of all the SA-MP bugs (mainly because vehicle ID allocations got really bugged after spawning trains [if I remember correctly]). I don't think you'll manage to implement them at all. After all, they can still be added with AddStaticVehicle(Ex) (if the answer from point 1 is "yes"), I don't think that a server should have too many trains. CreateDynamicVehicle should instantly return INVALID_STREAMER_ID (0) and send a streamer error ("Trains aren't supported.") if a train model was specified.
3. I don't think that you should add data manipulation for vehicles, but instead you should try to add every possible function related to them. I think that lots of manipulation data types that would work only for vehicles would be horrible.
4. Please try to use the definitions "rules" from this approved pull request: https://github.com/samp-incognito/sa...lugin/pull/198 .
5. There should be some function to keep tuning at respawn, per-vehicle (SetDynamicVehRespawnTuneReset ? by default true) so we won't have to store tuning and reapply it under OnVehicleSpawn.

6. SetDynamicVehParamsForPlayer needs to be reapplied when the vehicle is restreamed in for that player, which means that those parameters need to be stored somehow. The only method to do that in Pawn would be with plugins like GVar, which isn't ok. Maybe you could try to provide some GetDynamicVehParamsForPlayer function ? But there comes another problem: objective/doorslocked can't be disabled when the function is called, they need the vehicle to be streamed out. Each vehicle should MAYBE probably contain two containers to address these issues:

Code:

// ( playerid, make_pair< objective, doorslocked > ) ) 
map< int, pair< bool, bool > > actualPlayerParams; // this should be checked in OnVehicleStreamIn, to automatically reapply the params
map< int, pair< bool, bool > > playerParams; // this could be used in a GetDynamicVehParamsForPlayer, so it won't report the actual values, for example, it will report 1 for objective if it was set to 0 but the vehicle wasn't streamed out

But if you do this, there comes another problem: SetVehicleParamsEx. Those maps should be updated for the specified vehicle for every player with the corresponding doors/objective status.

7. Related to the respawning method: from what I saw in the code, I can understand that vehicles are respawned if they are touched (somehow fine, I'll get back to this), if they have a valid respawn delay (fine) and if at least 10 seconds passed after spawning (fine).
7.1. I see that vehicles are set as "touched" when a player calls OnPlayerEnterVehicle. From what I saw, doesn't this mean that the vehicle will be instantly respawned ? Also, players can cancel that action and no callback will be called. Are you sure that you didn't mean to use OnPlayerStateChange with newstate == PLAYER_STATE_DRIVER/PASSENGER ?
7.2. You should change this, from streamer.cpp:

PHP Code:

if (v->second->respawnDelay != -1) 


to this:

PHP Code:

if (v->second->respawnDelay < 1) 


it makes more sense. In SA-MP I remember that I tested this and vehicles won't respawn with values lower than 1, but I'm not sure about this now.
7.3. I see that in processVehicles you have a problem related to possibly slow code: you are looping through all players if the vehicle (in the loop through all streamed vehicles) to check if it is occupied. If there will be, let's assume, 50 touched vehicles (they are set as touched in OnUnoccupiedVehicle, as I saw in your code) and 1000 connected players (well, huge servers may use this vehicle streamer after all, right ?) this means that it will perform 50000 iterations, which isn't too fine. To solve this, I think that you should create some additional map container for every vehicle item in which the players seat IDs are stored. If you'll do this, the speed will be greatly optimised I guess, but have something in mind: I saw that cheaters can manipulate a vehicle even if it already has a driver, so there will be 2 reported drivers (I guess that the same applies to passenger seats). A map can accept only unique keys. To fix this you either a) have to reject the second player entering in an already-occupied seat (a problem from wiki: "Sometimes the result can be 128 which is an invalid seat ID. Circumstances of this are not yet known, but it is best to discard information when returned seat number is 128.", I don't know if players may return the same seat ID by mistake - probably this could happen in buses ?). b) have to use a multimap, so multiple players will be able to report the same seat ID without caring about the SA-MP bugs (you should use a multimap I think). If you will do this (I hope you will) don't forget to remove players when they disconnect or get teleported or do some other things which may remove them from vehicles. BONUS: This can provide some really useful functions, without the need to loop everytime in Pawn:

PHP Code:

/*
- Empty slots from the array should be filled with INVALID_PLAYER_ID. (I don't know the behaviour of other streamer functions which pass values to arrays, but this is what it should happen in this case) Or at least the next empty available (if the size isn't equal or less) array slot.
- Should return the players count.
*/
/* GetDynamicVehicleSeatPlayers:
- If using a multimap an array parameter would be required to put the player IDs in it.
*/
native GetDynamicVehicleSeatPlayers( vehicleid, seatid, players[ ], maxplayers = sizeof players );
native GetDynamicVehiclePlayers( vehicleid, players[ ], maxplayers = sizeof players );
// I don't know if data related to maximum seats should be implemented inside the streamer plugin:
native GetDynamicVehicleMaxSeats( vehicleid ); 


7.4. Why not changing from callbacks.cpp

pawn Code:

if (!p->second->touched)
{
    p->second->touched = true;
}

to

pawn Code:

p->second->touched = true;

? Also, you should use "v" (vehicle) as the iterator variable name, instead of "p" (player).

--------------

*semi-rage mode enabled* SA-MP has lots of bugs and problems that make everything a lot harder, which occurred even in my suggestions from above, but still lots of guys from around this forum (I bet that most of them don't even have a server, or their servers aren't too advanced) say that SA-MP don't need any update, because there are lots of features already and all bugs can be fixed by scripting (by the way, fixes.inc has thousands of lines to fix what shouldn't even be bugged to begin with, even really small bugs which should be easy to fix internally !). I get mad about bugs sometimes. Stop being so limited guys (like the ones who don't want any vehicle streamer, I see no reason why not to) and try to get the best you can. *semi-rage mode disabled*

I really appreciate that you managed to go that far with this vehicle streamer, thinking about all SA-MP's bugs and sync problems. Also, as far as I know, trailers syncing is pretty bugged TOO (argh !! Probably SA-MP's bug number 84324), you managed to make trailers working ?

By the way, SA-MP should also provide correct access to all quaternions of unoccupied vehicles (AFAIK, this is a bug too ! Incognito saw it too when implementing attached areas with offsets to vehicles: quaternions aren't reported correctly if the vehicle isn't occupied) and also the ability to set the quaternions of vehicles (not only the Z angle). I'm not sure if native SA-MP vehicle's quaternions are bugged after they restream-in to some players, I didn't test it before, but I guess that, at least with this streamer, vehicles could get stuck in objects if they were lastly streamed out from some kind of steep slope.