Showing less objects to players with a lower FPS.

[TamerGezici]

This is more of a suggestion, which would be great if we could have it.

I would like to decrease the draw distance or possibly set a limit of objects that can be shown to a player if they have a lower framerate, or maybe even both.

The way it's going to be done is upto you.

• Lower draw distances for low FPS users (maybe adding a multiplier)
• Adding a FPS lower limit for such multiplier to work.
• Limit maximum visible objects to a specific fps rate.
• Be able to do this per player (so that there are no generalizations in code, so I can set these limits depending on the player's average FPS)
• Being able to do this for all streamer entities, not just objects ofcourse.

etc.

[rt-2]

1 Is there a way to reliably know the player's FPS on the server side? There is this http://forum.sa-mp.com/showthread.php?t=490436 but it's from an include. 2 I think this may add problems, some objects may be needed. In my script, I have new floors, and if they unstream for anyone, vehicles on the floor may just go under (for example). 3 Adjusting draw distance because of FPS is really just the client's job I think. 4 If added, there has to be an option not to enable it, because some people like me may want certain objects to be always streamed, even if the player can't see the objects, for me its for vehicle's position stability, but there might be more reasons. Thank you, rt-2

[TamerGezici]

It is possible to find a player's FPS reliably. This is going to be an optional feature, if you don't need it then you don't have to use it. Objects can have an extra parameter to set their priority so floor objects can be streamed first

[Southclaws]

A common solution for this is LOD based on size or importance too. There's already a dataset for model sizes somewhere so wrapping that around CreateDynamicObject to scale the draw/priority could be rather easy.

[rt-2]

What is the best reliable method to know a player's FPS?

[TamerGezici]

@As far as I know, the ones on the forums usually work fine. Such as this one: http://forum.sa-mp.com/showthread.php?t=172202

I have been using that for years and It's working like a charm.

[TommyB123]

Players with lower end computers have complained to me about FPS issues on my server for a while now. The thing is, there's already ways to implement limits such as these. They don't work in conjunction with someone's framerate, however in my opinion there are better ways of handling client performance issues than forcing limitations based on FPS. Think of it like graphics settings in a traditional video game, some people might appreciate more details and be willing to sacrifice performance to see them.

I've implemented two commands on my server. One command is quite simple, it allows the user to set their own limit for streamed objects. I don't allow users to set this limit below 350 or above 1,000 for obvious reasons. The other, more experimental command I've implemented recently lets users set their stream distance multiplier using the Streamer_SetRadiusMultiplier native. I didn't really document this new command so not a lot of people know about it, but it's still something you brought up in your original point which can be adjusted based on user input. These features seem to have sufficed for most people, bar a few who get 5fps during the server's busy times (~150 users), so I don't see why limits tied to FPS should be put in place.

tl;dr: I don't think it's necessary to introduce FPS based limits to streaming when there's already options for limiting everything you laid out in your original point which players can adjust to their liking.

[IstuntmanI]

AFAIK, if you change the draw distance from game options it will also change the draw distance of objects which are created by SA-MP (not sure if you have to specify 0.0 for this).

What @TommyB123 did is what I also did and what you should do too. You have these functions: Streamer_SetRadiusMultiplier - limits streamdistance for every item for a player. Streamer_SetVisibleItems - limits viewable objects by a player.

You can also just check player's FPS by yourself and use these two functions. Also, don't use insane streamdistances and drawdistances by default. You shouldn't use a huge streaming distance if the draw distance is a lot smaller. Also, don't use lots of useless objects and lots of animated objects (like those animated really laggy fountains).

Streamer Plugin shouldn't interact with player's FPS, that's out of its scope.

This issue should be closed.

[TommyB123]

A bit off topic but I'm curious. Is there an array or list of model draw distance that could be used to set a dynamic object's stream distance to match its model's draw distance? That could be an interesting way to reduce the amount of objects streaming to someone's client since objects with appropriate draw distance would only stream when absolutely necessary. Could be a bit far fetched, though.

[Southclaws]

I don't think draw distance is a per-model thing since the engine doesn't do on-the-fly LOD (there are separate models for low LOD). There is however, an array of model sizes so you could use that to scale draw distance. A small flower pot shouldn't need to be streamed at 1000m but a skyscraper should.

Edit: here it is: https://github.com/Crayder/Model-Sizes-Plus Would actually be worth writing into the streamer actually, with a streaming mode you can toggle that automatically scales stream distance on object size.

[rt-2]

Yes but any of those features playing with draw distance should be an option and off by default to avoid breaking code. I have objects that I just ALWAYS stream to all players, I try to avoid it but I need a minimum for stability reasons.

[Southclaws]

Of course it would be optional. A per object flag would be suitable then. Settable via a Streamer_Set* function to avoid API changes to CreateDynamicObject. If I find the time, I might actually try and implement this and submit a PR.

[samp-incognito]

I agree that this is pretty easily scriptable with Streamer_SetRadiusMultiplier. Another point I'd make is that there's no standard way of determining the player's FPS outside of using SetPlayerDrunkLevel, which would conflict with any script also using it.

Integrating the model sizes include would be a good idea, though.

[ghost]

Integrating model sizes would be very good. Its better sit in Streamer like in YSF.