Openkore.com

OpenKore Forums
It is currently 25 Feb 2018, 07:45

All times are UTC - 5 hours [ DST ]





Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 30 Oct 2008, 05:15 
Offline
Administrator
Administrator
User avatar

Joined: 24 Apr 2008, 12:02
Posts: 1299
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.

_________________
Join our Team. Click here.
Image


Image


Top
 Profile  
 
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 30 Oct 2008, 12:59 
Offline
Spam Generator
Spam Generator

Joined: 04 Apr 2008, 09:30
Posts: 501
Location: Melbourne, City of beer and awful sushis
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.

_________________
Make Openkore Awesome. Join the team.


Top
 Profile  
 
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 30 Oct 2008, 13:32 
Offline
Kami-Sama Desu~
Kami-Sama Desu~
User avatar

Joined: 04 Apr 2008, 09:24
Posts: 196
Location: 31th Dimension
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.

_________________
Openkore Svn Zips:
Image
Doing Stuff Better At CollectSkin.com


Top
 Profile  
 
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 30 Oct 2008, 13:41 
Offline
Administrator
Administrator
User avatar

Joined: 24 Apr 2008, 12:02
Posts: 1299
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.

_________________
Join our Team. Click here.
Image


Image


Top
 Profile  
 
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 22 Mar 2009, 20:17 
Offline
Super Moderators
Super Moderators
User avatar

Joined: 06 May 2008, 12:47
Posts: 801
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)


Attachments:
File comment: Openkore DB ERD
Openkore_ERD.pdf [234.08 KiB]
Downloaded 246 times

_________________
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!
Top
 Profile  
 
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 25 Mar 2009, 13:18 
Offline
Super Moderators
Super Moderators
User avatar

Joined: 06 May 2008, 12:47
Posts: 801
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:
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

_________________
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!


Top
 Profile  
 
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 25 Mar 2009, 13:42 
Offline
Administrator
Administrator
User avatar

Joined: 24 Apr 2008, 12:02
Posts: 1299
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.

_________________
Join our Team. Click here.
Image


Image


Top
 Profile  
 
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 25 Mar 2009, 14:00 
Offline
Super Moderators
Super Moderators
User avatar

Joined: 06 May 2008, 12:47
Posts: 801
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.

_________________
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!


Top
 Profile  
 
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 20 Apr 2009, 15:23 
Offline
Super Moderators
Super Moderators
User avatar

Joined: 06 May 2008, 12:47
Posts: 801
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?

_________________
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!


Top
 Profile  
 
 Post subject: Re: AI 2008 SqlLite tables.
PostPosted: 20 Apr 2009, 23:30 
Offline
Perl Monk
Perl Monk

Joined: 04 Apr 2008, 17:26
Posts: 811
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.

_________________
cs : ee : realist


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group