Page 2 of 3

Re: AI 2008 SqlLite tables.

Posted: 30 Oct 2008, 05:15
by kLabMouse
isieo wrote:
kLabMouse wrote:I was reading
How do I redefine a builtin function, operator, or method?
and
overload

According, to what i've read, we could make it compatible with old style.
But that will be "Black Magic", and can cost us a very unreadable code (except that I dunno about sharing blessed variables that use overloaded operators).
well, if stuff is properly documented, we shouldn't have that problem.

i'll probably merge this with trunk after we got reviews from all the key people, then i'll release a beta version
I was thinking about it too.
But, planned to use "KoreStage" loader for loading that stuff.
Also. Multi threaded version and single thread will differ a bit.

P.S. Also the PortalLOS implementation (even with overload stuff) will differ a lot.

Re: AI 2008 SqlLite tables.

Posted: 30 Oct 2008, 12:59
by Cozzie
good documenting should not be used as a reason for unreadable and low code maintainability. A good code should rely on as little external documenting as possible. Openkore does not need so many legacy features, it complicates matters, is not necessary and a design overhaul will not fully compromise anything. A change in process is all that is required.

Re: AI 2008 SqlLite tables.

Posted: 30 Oct 2008, 13:32
by isieo
from what i read, it doesn't look like it will be unreadable code

its just operator overloading, so that we can retrive stuff the way we do it before.

well but i do agree that we do not need so many legacy stuff.

Re: AI 2008 SqlLite tables.

Posted: 30 Oct 2008, 13:41
by kLabMouse
isieo wrote:from what i read, it doesn't look like it will be unreadable code

its just operator overloading, so that we can retrive stuff the way we do it before.

well but i do agree that we do not need so many legacy stuff.
Well. I've analyzed, what we need to make it work, and look like old stuff.
it needs "overloading" of some dereference stuff (that will make Black Magic), also use tie'd SCALAR (So we could control user access to internals and support dynamic loading).

Those two, are really "Black Magic" because they access package internals by another way, then usual user code.

Re: AI 2008 SqlLite tables.

Posted: 22 Mar 2009, 20:17
by Technology
I currently am designing an ERD (Entity-relationship model) schema for the DB module.
Such ERD schema is a data model that will help us to gain insight in needed information and relations between data.
It will for example resolve bugs like this.
We will know not to use non unique attributes as if they were unique.

The essence of the DB module is to provide kore with knowledge.
You can compare it to the RO data folder providing RO with data and RMS provides the people with information, ...

EDIT:
Here's a small sneak peak, its not quite done yet since some more tables & attributes need to be added.
I haven't finished the datatypes either, but the basic structure is there.
Also some VARCHAR need to be NVARCHAR (translation support).
The SKILL entity currently has attributes like: area, self, target (wich is a violation of TNF, unless ofcourse there exists a skill that is a combination of more than 1 of those attributes)
Comments/idea's are welcome.

btw, i'm using Power* Architect to design it (written in java, cross platform and opensource)

Re: AI 2008 SqlLite tables.

Posted: 25 Mar 2009, 13:18
by Technology
Lately i've been playing with the idea of tables that will translate packet information to human text,
note that some table files are already there solely for this purpose.
This in order to reduce receive.pm's size and improve readability of the code.
example:

Code: Select all

sub gospel_buff_aligned {
	my ($self, $args) = @_;
	my $status = unpack("V1", $args->{ID});
	
	if ($status == 21) {
     		message T("All abnormal status effects have been removed.\n"), "info";
	} elsif ($status == 22) {
     		message T("You will be immune to abnormal status effects for the next minute.\n"), "info";
	} elsif ($status == 23) {
     		message T("Your Max HP will stay increased for the next minute.\n"), "info";
	} elsif ($status == 24) {
     		message T("Your Max SP will stay increased for the next minute.\n"), "info";
	} elsif ($status == 25) {
     		message T("All of your Stats will stay increased for the next minute.\n"), "info";
	} elsif ($status == 28) {
     		message T("Your weapon will remain blessed with Holy power for the next minute.\n"), "info";
	} elsif ($status == 29) {
     		message T("Your armor will remain blessed with Holy power for the next minute.\n"), "info";
	} elsif ($status == 30) {
     		message T("Your Defense will stay increased for the next 10 seconds.\n"), "info";
	} elsif ($status == 31) {
     		message T("Your Attack strength will stay increased for the next minute.\n"), "info";
	} elsif ($status == 32) {
     		message T("Your Accuracy and Flee Rate will stay increased for the next minute.\n"), "info";
	} else {
     		#message T("Unknown buff from Gospel: " . $status . "\n"), "info";
	}
}
could be written in a few lines using a table in the DB module: entity GOSPEL, with the statusID's as unique attributes and the msg as optional attribute.
if msg for the statusID exists, then print msg, else print out a warning.
This statusID vs message information could possibly be extracted from the sakexe.exe client.
in a kore table file gospel.txt we would have something like: statusID message

This is just one example but the idea has more uses.
We could even support translation like this. (a bit like how Thaikore does it)

Anyways, someone in my family accidently crashed my laptop,
all my research on the data folder files, kore tables and etc is on it...
so right now i'm trying to recover the data first

Re: AI 2008 SqlLite tables.

Posted: 25 Mar 2009, 13:42
by kLabMouse
MM... Let's try something like this:
SkillID, Magic, Message.

So, using SkillID and Magic, you can do anything you want.
The Message itself can get translated true native Kore translator.

Re: AI 2008 SqlLite tables.

Posted: 25 Mar 2009, 14:00
by Technology
kLabMouse wrote:MM... Let's try something like this:
SkillID, Magic, Message.

So, using SkillID and Magic, you can do anything you want.
The Message itself can get translated true native Kore translator.
I don't 100% get what you are trying to say here, doesn't the native kore translator suck?
I mean the translation should not happen at execution time, but rather at "compile time" (perl is interpreted, but you know what i mean).

Imo we should split the table files into different types:
- extracted from grf (skillnametable.txt) (some are language dependant/some aren't)
- extracted from client (mostly ID to name/handle)
- converted from eA (portals.txt)
- table files build up by us (packetdescription.txt)

One of the many benefits here is that we easily add support for translation of for example skillnames,
we simply copy the skillnametable.txt from our spanish, english, russian, ... server and voila.

Oh yea, and we should not use skillnames in the skillblocks if that is an obstacle for this proposal.
We should use skill handles / skillID's. (conferator: swordmanskills bug)

now: (hard to maintain)
skills.txt (combined data from different sources... possibly written by hand)
id handle name

future: (easy to maintain)
SKILL_id_handle.txt (extracted from RO client)
id handle

skillnametable.txt (extracted from grf)
handle#name#

So by using some parsers and the DB module we build the database (tables & relations) up by the design of our ERD schema.
Allow me to complete the ERD, everything will become clear.

Re: AI 2008 SqlLite tables.

Posted: 20 Apr 2009, 15:23
by Technology
Someone please re-upload the Openkore_ERD.pdf

FLD & DST @ DB
Here's an idea that we've been discussing on IRC.
We could make fld / dist data (in a database) available to both C (directly) and perl (trough C api).
Doing this, we won't need to pass this data from perl to C.

Reading, writing, updating will all happen trough this api.
The api will be controlled by the perl DB thread.
If any other thread wants to make changes, it will have to communicate with that perl DB thread.

Another idea was to have a dynamic layer on top of that to support dynamic map information (spells, traps, ...)
I have no idea how this is possible or best used in practice tho.

Now, what do you think?

Re: AI 2008 SqlLite tables.

Posted: 20 Apr 2009, 23:30
by sli
I've already working with multithreaded applications with SQLite, and the best way to implement it would simply be a class (or whatever) that handles a queue of database operations. Other threads simply add operations to this queue and the thread containing the database code handles it.