Graal Forums

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   NPC Scripting (https://forums.graalonline.com/forums/forumdisplay.php?f=8)
-   -   item database query (https://forums.graalonline.com/forums/showthread.php?t=77223)

xAndrewx 10-18-2007 08:52 PM

item database query
 
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.
HTML Code:

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

HTML Code:

[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

HTML Code:

1003 = { {"AmmoLimit", 9999}, {"AmmoName", "Uzi"}, {"ClipAmount", 32}};
To gain the ammo name, I'd end up doing

HTML Code:

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 10-19-2007 12:13 AM

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 10-19-2007 02:11 AM

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 10-19-2007 02:31 AM

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 10-19-2007 03:59 AM

Quote:

Originally Posted by Googi (Post 1353466)
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 10-19-2007 05:17 AM

Quote:

Originally Posted by Novo (Post 1353472)
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 10-19-2007 06:51 AM

Quote:

Originally Posted by Googi (Post 1353476)
But you could find out how much faster.

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

Googi 10-19-2007 07:03 AM

Quote:

Originally Posted by Novo (Post 1353478)
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 10-19-2007 07:32 AM

Quote:

Originally Posted by Googi (Post 1353479)
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 10-19-2007 08:54 AM

Quote:

Originally Posted by Novo (Post 1353463)
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


All times are GMT +2. The time now is 12:46 AM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.