item database query

[xAndrewx]

so, I have made an item database, however I don't know how to do it now. Here's how it works so far

It creates an arc file, and adds the contents of that arc file to a database.

1003.AmmoLimit=9999
1003.AmmoName=Uzi
1003.BulletGani=era_uzireload
1003.BulletsFire=1
1003.BulletsReduce=1
1003.ClipAmount=32

[Yes, on it's own line]
However, would this cause any lag? I can simply do from another NPC

[Control].id.AmmoLimit

to return 9999

However, I could also make each item have it's own line, to control that data. However, each time I would want to check something, I'd need to look inside the array

Here's what I mean

1003 = { {"AmmoLimit", 9999}, {"AmmoName", "Uzi"}, {"ClipAmount", 32}};

To gain the ammo name, I'd end up doing

getData(id, name) {
  for (temp.i: this.(@ temp.id) {
    if (temp.i[0] == temp.name) {
      return temp.i[1];
    }
  }
}

What do you think would be better for the server?

[zokemon]

I always find txt files (or whatever you want to call them) to be safer and thus better. The lag from loadlines and such would just be HD lag which Graal usually never experiances on the NPCServer so I really wouldn't worry about it. If you were to store all your data in a DB npc, not only do you have to worry about some idiot reseting the npc, but if the npcserver ever goes down, your data in those npcs might rollback.

[Novo]

Ew @ variable-names as pure numbers. It's not compatible in most languages... It might work on Graal though. VERY bad habit to pick up... Better leave it where you found it. On the other hand... mud_[id] would be a better variable name. Otherwise, it's alright.

I would advise you to make a function to obtain the variables through a function ( So some wise-person doesn't just go and change them ). By pretending they are protected information, you would define a function such as this:
public function "getMudProp( mudID, prop ) return this.(@ mudID ).(@ propName );

This would prevent people from knowing where the data is... It would also provide an interface to work with. The benefits of this method is that when you change the internal workings of the item, the integrity of the server remains safe ( you modify the code in one place ). It also gives you some assurance you won't mistakenly change the data. It also permits you to debug it much more effectively later on... Or do some testing on it ( efficiency-wise ). It also gives you a concise abstract 'contract' with the DB-NPC: You know, just by the function name, what are you getting exactly.

EDIT:
I don't know the difference in speed between the both methods, but as stated above, do use a function.

[Googi]

If you really want to know, test both methods by using a timeout. Have a script start a timeout, do some stuff (probably quite a bit of stuff) using the first method, and then save the value of the timeout to a variable/echo it/whatever. Then do the same with the second method (of course, make sure that the stuff done with the second method is the same as for the first).

[Novo]

Originally Posted by Googi

If you really want to know, test both methods by using a timeout. Have a script start a timeout, do some stuff (probably quite a bit of stuff) using the first method, and then save the value of the timeout to a variable/echo it/whatever. Then do the same with the second method (of course, make sure that the stuff done with the second method is the same as for the first).

Directly accessing the value is systematically faster than accessing the value and comparing a bunch of values inside. ( It could be slower on loading up, but once loaded, it is fairly fast ).

[Googi]

Originally Posted by Novo

Directly accessing the value is systematically faster than accessing the value and comparing a bunch of values inside. ( It could be slower on loading up, but once loaded, it is fairly fast ).

But you could find out how much faster.

[Novo]

Originally Posted by Googi

But you could find out how much faster.

N times faster. N being the size of the array.

[Googi]

Originally Posted by Novo

N times faster. N being the size of the array.

If you don't count the time it takes to open and read the file, sure.

[Novo]

Originally Posted by Googi

If you don't count the time it takes to open and read the file, sure.

Which is what caching does. You read it from file, you cache it to memory. The load-up times would differ. Taking the average amount of time it took to load up over the average life-span of the variable and you'll conclude that the load-up times are inconsequential.

[xAndrewx]

Originally Posted by Novo

Ew @ variable-names as pure numbers. It's not compatible in most languages... It might work on Graal though. VERY bad habit to pick up... Better leave it where you found it. On the other hand... mud_[id] would be a better variable name. Otherwise, it's alright.

I would advise you to make a function to obtain the variables through a function ( So some wise-person doesn't just go and change them ). By pretending they are protected information, you would define a function such as this:
public function "getMudProp( mudID, prop ) return this.(@ mudID ).(@ propName );

This would prevent people from knowing where the data is... It would also provide an interface to work with. The benefits of this method is that when you change the internal workings of the item, the integrity of the server remains safe ( you modify the code in one place ). It also gives you some assurance you won't mistakenly change the data. It also permits you to debug it much more effectively later on... Or do some testing on it ( efficiency-wise ). It also gives you a concise abstract 'contract' with the DB-NPC: You know, just by the function name, what are you getting exactly.

EDIT:
I don't know the difference in speed between the both methods, but as stated above, do use a function.

Got ya, thanks.

I just thought that doing a loop serverside for each prop would cause some some problems