The createobject limit is very annoying
I dont want to write a streamer plugin, so I request you to simply increase the limit.
:edit: also createvehicle
Thanks
Quote from: EK.CrystalBlue on Sep 02, 2016, 01:12 PMwrite a streamer plugin
I keep hearing this from the VCMP people. But I can't seem to understand what this is. Knowing that VCMP cannot be extended in any way possible without injecting custom code and forcing people to download an unofficial modification.
@Stormeus you probably know better. Can you enlighten me on this one please?
Streamer plugin = take closest objects to players, delete all other objects
After a few moments, do that again, removing old objects and recreating new objects near players
This is all handled server-side
Well, whomever named it that way was the either a troll or plain stupid. No offence. That's the least intuitive name I've seen for what it actually does. Streaming had a whole different meaning last time I checked.
Anyway, I can probably think of a couple alternative ways of achieving something like this that doesn't involve constantly processing all the objects for all the players to see which object is visible or not.
Anyway, I'm done spamming with off-topic. Carry on.
Just curious: how did you even manage to hit those limits ? What kind of server are you scripting on ?
Objects' limit: 3000
Vehicles' limit: 1000
He allows players to map their own interiors.
Buying interiors stuff for a virtual flat in old video game...
Quote from: sseebbyy on Sep 02, 2016, 10:13 PMJust curious: how did you even manage to hit those limits ? What kind of server are you scripting on ?
Objects' limit: 3000
Vehicles' limit: 1000
VKs probably. They allow custom objects, vehicles, pickups etc in your own properties.
If we want client side player.gravity then we know we will desync. For example, I could create a 'player hide' script client side which changes the world of all the other players except the local player on client side, so basically others can see me, but i dont see others.
player.Weather for me isn't bad thing. Or weather, gravity etc.. for virtualworld ;)
Per-player weather/gravity/etc. is fine and we can add it despite the sync consequences, but this:
Quote from: vitogta on Jun 13, 2018, 08:11 PMWe need clientside objects
Flatly will not happen, ever. Adding this feature would introduce instability. Sync consequences aside, if the combined number of client and server-side objects is bigger than the game allows, then either
- The client crashes out.
- The client has to refuse to create objects, desyncing the game from what even the scripter expects.
Both of these are totally unacceptable.
I still don't understand how so many servers manage to completely blow away the 3,000 object limit that this is such a popular request. SA:MP has a limit a third the size of this and they seem to make do by only creating objects for interiors when they're needed and deleting them when they aren't. Constantly bumping entity limits carries a cost of memory and CPU usage.
Quote from: vitogta on Jun 13, 2018, 09:57 PMWhy we can't limit quantity of object instances ourself then?
Scripters can only be trusted to a limited degree. Case in point: I am currently writing patches to make sure the client-side GUI scripts don't try to work on null objects because I found a server that executes code like this every time you connect:
a <- null;
b <- GUISprite();
b.AddChild(a);
Quote from: vitogta on Jun 13, 2018, 09:57 PMThere is alot of bandwidth is used to work with moving serverside objects. It can be very optimized by clientside objects.
You know what else costs a lot of bandwidth? Leaving the server to do the work of checking thousands of objects.
Quote from: vitogta on Jun 13, 2018, 09:57 PMIt also can fix lag of object position (since each frame is under our control at clientside).
You're only shifting the burden to clients and will make their CPU usage far worse.
Quote from: vitogta on Jun 13, 2018, 09:57 PMQuote from: Stormeus on Jun 13, 2018, 09:35 PMConstantly bumping entity limits carries a cost of memory and CPU usage.
This is also can be a reason for that. To save server's cpu usage.
No, it affects the CPU of both the clients
and the servers. The servers have to do more work to send bandwidth updates to N players about the 5,000 objects you have on the server. The clients have to do more work to see which of these thousands of objects is visible. This is not sustainable.
I still don't understand why we should bump the entity limits. It is far less expensive for the server
and the client if the scripter creates the 60 or so objects for an interior only when it's needed, and deletes them when they're done, than to leave thousands upon thousands of objects in the entity pool. Scripters need to get far smarter about how they're using these features before we consider a move like that.
@Stormeus , while you are at it, please update the squirrel version to the latest available on both the client and the server. There are some funky issues waiting to be abused :)
Quote from: vitogta on Jun 13, 2018, 08:50 PMIts an example of mistake of coder. Not interface.
Huh? I guess you don't have any idea then at all.
On the client side objects topic;
Its just also a matter of proper management, adding objects to client side won't cause that big of a deal if its properly managed to stay within the limits of the game, although I guess it can be debated upon, the worst that can happen is floating clients because they have some object on their screen and other clients don't, but if the main issue here is just the object limits, I'm not sure how can it not be controlled.
However what more useful is to have
proper client-side scripting environment, the current one is painful in every possible way, not that we (or atleast I) don't appreciate the efforts to bring GUI to VCMP but atleast it should've been satisfactory.
If there's something that has to be improved client side as a start is to:
- Have proper client side environment and working functionality
- Provide all the basic Player and Vehicle methods
- The system of sending data from server to client and vice versa is completely crappy, something else with a better support for versatile function calls would be way better with more supported data types such as tables.
Sync part is not needed, as I said, the only reason I would want to create objects on client side is because I don't want to create them in unique world. As far as my understanding goes, VCMP syncs the information of the objects created server side to all clients no matter what world they are in (Not sure on this one) and hence that's the only reason I would make objects on client, mostly for stuff like 'attaching' scripts which I won't do at onPlayerMove server sided.
QuoteI want to be able to attach objects too (and more)
Not only you, but must be able to vehicle and player. And this (https://forum.vc-mp.org/?topic=5718.msg40296#msg40296).
Quote from: vitogta on Jun 14, 2018, 12:01 PMQuote from: rww on Jun 14, 2018, 11:55 AMQuoteI want to be able to attach objects too (and more)
Not only you, but must be able to vehicle and player. And this (https://forum.vc-mp.org/?topic=5718.msg40296#msg40296).
Once objects will be clientside we will be able to attach it to anywere, beside that it will provide more opportunities than just attaching (for people who knows math). This is a reason why I ask for this feature. Including that arrow.DFF case
But VC have built-in function to the arrow, so I don't see the sense to do a script for something like that. With no problems with animation, and can be colored by script.