[TQ Binaries] Discussion and documentation

[pro4never]

This thread is a response to a suggestion by Lateralus . Seeing as I have no power to make sub sections to the forum I thought this could serve as a temporary area for people who enjoy binaries to discuss them and document how they work/interact with the TQ database.

WARNING: The epvp rules state that no illegal 'warez' are allowed to be posted. As such we do NOT allow posting the actual binary files. This is for discussion and documentation only! Anyone posting binary files will be infracted and the files removed. Posts requesting they be released will be deleted.


That being said... There is the actual Eudemons server AND client source code on epvp. I have no idea why eud seems to be exempt from the warez rule but that's not my concern. If you wish to look through it and work on reverse engineering various game systems or just understanding better how tq handles their database then I'd suggest a look through it (quite interesting although I've barely touched them)

Client:
Server:


Feel free to make large 'all in one' posts if you have stuff to share about how binaries work and I'll link to them from this post that way it will be somewhat easier for people to navigate through.

[Korvacs]

Lets start again shall we...

[Kiyono]

Well this might or not be become successful. I doubt that there are people around that come here to ask for download links but you'll never know.

Originally Posted by pro4never

I have no idea why eud seems to be exempt from the warez rule but that's not my concern.

I know you said that it's not your concern but apparently this is the reason:

Originally Posted by Korvacs

The Eudemons section really shouldnt be exempt, the moderators of that section have always defended it because without being exempt the section would basically have to be closed since no one has written an Eudemons source themselves, atleast thats the reason that was used the last time.

I dont really agree with it to be honest.

On a sidenote, I have seen the actual database posted before, is it fine to post that? It probably is seeing how there are flatfile databases around that are nothing else than TQ's database batched to ini files but I'll ask anyway.

[pro4never]

Yes it's only the TQ .exe's that are not allowed.

[Korvacs]

Was just curious if anyone else has tried converting the AI from the binaries into a source?

[InfamousNoone]

To my (very limited) knowledge of what's going on in the p-server world, Ultimation got the furthest with trying to do so. Not sure if he ever fully completed it (I doubt it) but I believe he got quit far.

[Kiyono]

So how exactly does cq_action interact with cq_task?

[Lateralus]

Originally Posted by Kiyono

So how exactly does cq_action interact with cq_task?

The columns `id_next` and `id_nextfail` in cq_task correspond directly to the IDs in cq_action. Some tables use the task table instead to trigger an action (cq_npc comes to mind).

[Kiyono]

So cq_npc the task0, 1, 2, ... 7 are ids in cq_task and the id_next/fail in the cq_task refers to an id in cq_action.
While you're here anyway, mind explaining the cq_task table?
I see some really weird values for certain columns e.g. profession is 0, *** is 999, min_pk is -10000 etc. I honestly don't know what the heck they mean.

[Lateralus]

Originally Posted by Kiyono

So cq_npc the task0, 1, 2, ... 7 are ids in cq_task and the id_next/fail in the cq_task refers to an id in cq_action.
While you're here anyway, mind explaining the cq_task table?
I see some really weird values for certain columns e.g. profession is 0, *** is 999, min_pk is -10000 etc. I honestly don't know what the heck they mean.

Yep. That's right. The columns check for values, if the checks succeed, it uses to id_next, else id_nextfail. I don't really think they're used very often... maybe 3 or 4 tasks use them. Those weird values are sentinels to ignore the checks.

[Kiyono]

Originally Posted by Lateralus

Yep. That's right. The columns check for values, if the checks succeed, it uses to id_next, else id_nextfail. I don't really think they're used very often... maybe 3 or 4 tasks use them. Those weird values are sentinels to ignore the checks.

I see so source wise it's handled like this for example:
if (itemname1 != null)
{
if has item
id_next
else
id_fail
}
else
//next check
}

And then for all checks like that.

[Lateralus]

Originally Posted by Kiyono

I see so source wise it's handled like this for example:
if (itemname1 != null)
{
if has item
id_next
else
id_fail
}
else
//next check
}

And then for all checks like that.

Yeah, basically. To save you some time, from what I know, the columns `client_active` and `query` aren't processed. I got that from EO though, not sure if they're processed in the binaries... I didn't check because it's not a big deal.

[Kiyono]

The values for columns money, profession, metempsychosis, query and client_active are always 0 so i guess that those are never used.

[Lateralus]

Originally Posted by Kiyono

The values for columns money, profession, metempsychosis, query and client_active are always 0 so i guess that those are never used.

That's true that they aren't used, but they're still processed (with the exceptions of query and client_active).

[nTL3fTy]

Basically how the Npc dialog system works is like this:

• Player clicks Npc in-game
• Server has the cq_npc info for that npc, and cycles through task0-7 until it finds one that has a corresponding entry in cq_task.
• Once a cq_task entry is found, it then tests the task variables (pk, marriage, ***, etc).
• Depending on whether the player passes the test or not, it selects id_next or id_nextfail from the task entry.
• With the id_next or id_nextfail selected, it then finds the entry with that id in cq_action and processes it.

Now, with the dialog open, any 'button' the player presses then looks for the corresponding task_id (from the param in cq_action for that specific button) and performs the tests again and selected id_next or id_nextfail from the cq_task entry. ...and repeat.

Also, client_active is used. It's used for guild member removal.