Items Script

[Torankusu]

To also elaborate, storing items in an inventory via clientr. Flags can be sketchy simply because if yhat flag exceeds a certain character limit (128?), and someone edits the attributes manually through rc, you run the risk of clipping off part of the flag.

There are ways around it, by scripting some commands to use in rc to edit a player's attributes, but storing this information in a players clientr. Flags can be avoided.

[John]

To also elaborate, storing items in an inventory via clientr. Flags can be sketchy simply because if yhat flag exceeds a certain character limit (128?), and someone edits the attributes manually through rc, you run the risk of clipping off part of the flag.

There are ways around it, by scripting some commands to use in rc to edit a player's attributes, but storing this information in a players clientr. Flags can be avoided.

Not true, there's no limit for that flag. (well, 65535-65536 would be the strings' max). Nobody is supposed to edit flags via RC anyways, this right should only be used for resets and nothing else.

iEra uses clientr. flags, there's no problem in that but the annoying part is that it uses a lot of flags, which I find it as bad coding.

[Torankusu]

Any flag that exceeds a preset character limit does not display the entire length in player flags via RC when editing the player attributes <--- How is this not true?

Here is a snippet anyone can use to test for yourself.

Simply put this in a level npc.

// Created by Torankusu
function onCreated() {
  this.image = "door.png";
  setshape(0,32,32);
}

//RIGHT CLICK IT...
function onActionRightMouse() {
  //empty array for each re-test..
  temp.tarr = {};
  //simple loop..
  for (temp.i = 0; temp.i < 400; temp.i++) {
    //add about 400 vars to array...
    temp.tarr.add(temp.i);
  }
  //set the clientr flag to the array (should be well over 400+ chars..)
  player.clientr.testflag111 = temp.tarr;
  //echo to RC to see the complete flag's contents..
  echo("Flag List: " @ player.clientr.testflag111);
}

/*
At this point, Open your account via RC to edit attributes,
locate the flag (clientr.testflag111), and you should only see
up to about the #70.

Manually EDIT that flag, to remove any number,
for example, the 0, or the 1 at the beginning 
And then do:
*/

//and type "test" on your player..
function onPlayerChats(){
  if (player.chat == "test") {
    this.chat = "Ok!";
    echo(player.clientr.testflag111);
  }
}

//Check RC to see what that flag is now equal to.. 

After following those steps, you will see that if the flag is manually edited via RC (which, as I said was a bad idea anyway,) you would be clipping off the rest of the data not displayed < -- again, how is that not true?

(you are only shown 205 chars into the flag via RC, 225 including the flag name and = sign)

Now, how this could relate to the original poster's question in regards to an item system:
If you write your system poorly, which is very likely, and pass certain information on to the player to be stored in clientr.flags, you will have to do as I previously mentioned, and write something to handle adding and deleting (or more or less updating the quantity of said item), even in the event that you or another admin need to remove or add an item to a player.

For example, if you or another admin need to add 20 grenades, or remove 200 shells from a player -- if that flag exceeds a certain limit, you will simply break it. The alternative is to script a command for handling the removing and adding of items to players in the event that you need to do this.

All I was saying John, but thanks for the help anyway.

[John]

To also elaborate, storing items in an inventory via clientr. Flags can be sketchy simply because if yhat flag exceeds a certain character limit (128?), and someone edits the attributes manually through rc, you run the risk of clipping off part of the flag.

There are ways around it, by scripting some commands to use in rc to edit a player's attributes, but storing this information in a players clientr. Flags can be avoided.

This is the point that I said it was not true...

And I already stated that editing variables in RC should be forbidden.

[Torankusu]

Should I really have been precise for someone that doesn't really even understand what a clientr. flag is to begin with (the original poster)? or maybe you shouldn't have overlooked the "AND...."
My bad, I guess I shouldn't have said 128 characters! Regardless of what you highlight, or examples you can't deny, it doesn't make my initial statement any less true:

TO CLARIFY...
DO NOT USE CLIENTR. FLAGS TO STORE DATA IN RELATION TO ITEMS, as THERE ARE BETTER ALTERNATIVES AT THIS DAY AND AGE (see: sql) TO USE TO ACHIEVE WHAT YOU WANT, WITH MORE FLEXIBLE USES.


not sorry for the caps, some people tend to want to ARGUE about UNRELATED things.

[John]

Should I really have been precise for someone that doesn't really even understand what a clientr. flag is to begin with (the original poster)? or maybe you shouldn't have overlooked the "AND...."
My bad, I guess I shouldn't have said 128 characters! Regardless of what you highlight, or examples you can't deny, it doesn't make my initial statement any less true:

TO CLARIFY...
DO NOT USE CLIENTR. FLAGS TO STORE DATA IN RELATION TO ITEMS, as THERE ARE BETTER ALTERNATIVES AT THIS DAY AND AGE (see: sql) TO USE TO ACHIEVE WHAT YOU WANT, WITH MORE FLEXIBLE USES.


not sorry for the caps, some people tend to want to ARGUE about UNRELATED things.

I don't really want to be a dick here, but you can't tell someone who doesn't know what's a clientr flag to use a connection between SQL and Graal... :P

[Torankusu]

Fair enough, however sqlite is simple to learn with considerably more resources available than for gs2, so I can recommend he start learning there if he is wanting to learn database structure and advantages.

Once learned, applying it to an item system, or even character slot / quest progression system could be easier.