[C0mBat1ve]

why would I use big vars instead of PVars except for speed?

[Kane]

Quote:

1) PVars can be shared/accessed across gamemode scripts and filterscripts, making it easier to modularise your code. 2) PVars are automatically deleted when a player leaves the server, meaning you don't have to manually reset variables for the next player who joins. 3) No real need for complex enums/player info structures. 4) Saves memory by not allocating pawn array elements for playerids which will probably never be used. 5) You can easily enumerate and print/store the PVar list. This makes both debugging and player info storage easier. 6) Even if a PVar hasn't been created, it still will return a default value of 0. 7) PVars can hold very large strings using dynamically allocated memory.

2 and beyond are good reasons.

Edit: I misread your question but still, those are why you SHOULD use PVars.

[C0mBat1ve]

Quote:

Originally Posted by Arthur Kane 2 and beyond are good reasons. Edit: I misread your question but still, those are why you SHOULD use PVars.

Yea I know these, I am already using PVars, I am just wondering why would you use massives with these benefits, what cons?

[NaS]

The big advantage of regular Arrays with Enums is speed. If you have data that is constantly in use and accessed very often it may be better to use an Array, however PVars aren't slow either so this will probably only come into mind with many players and very frequently used data.

I personally find Arrays more convenient though. You can directly perform operations on them, copy them etc.

Also Arrays can be bulk-saved so you could make an Array for stored Player Data and save and load it as-is. With PVars you'd need to save each value by name (or its Index).

[iKarim]

The main reason I'd use PVars is when I need variables that's accessible via filterscripts, but I never really use filterscripts. Arrays are preferred.

[C0mBat1ve]

Quote:

Originally Posted by ****** 1) True, but only useful for data that needs sharing, and as a general rule, you should provide function accessors, not shared global state. This is true for any variable type. 2) True, but hardly a hardship - you can reset an enum in one simple expression (even though many people don't). And if your default values aren't '0', you still need reset code. 3) Structured data is a GOOD thing! Though vast 'PlayerInfo' structures aren't. 4) False, PVars take WAY more space. 5) See 3 for why the 'PlayerInfo' pattern is bad. 6) In other words, it hides errors in yiur code, instead of having the compile pick them up instantly to fix them. 7) I've written a whole multi-language text library and not needed them yet. Oh, and contrary to popular belief, they are VASTLY slower, not just a little bit.

What would you store player data in for not a big server (100 players on peak)?