[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Data files for a MMORPG

Ivan Vucica wrote:

first, sincere apologies if this is a confusing message, but I'm trying

Indeed confusing.

to introduce you to some very basic info about the client for which I'm trying to create packages. It may be insufficient info, or just confusing and standing in the way. Please forgive me.

MMORPG client I mentioned in the previous posts, YATC, supports multiple data file versions. With each version, only one type of servers is supported. Reminder, those are proprietary data files from a "third

Is the server type in direct relation to the data set or is it related to
the actual client?

party company", the developers of original closed source client. By the way, the original developers have commented that "alternative" clients aren't allowed to connect to their service; client supports it, but we don't endorse it.

That sounds like a legal issue you must solve or avoid (and avoid your users
to get into it).

So as I'm doing "early Debianiasation", I'm interested in suggestions on how to proceed with data package creation. It'll take some time before we'll have our own, free packages, and until then we'll have to use the non-free versions.

Original client's name is Tibia.

First, since we'll eventually be developing a free dataset, should this proprietary dataset be placed into "tibia-data" or "yatc-data"? Or


should we create both "yatc-data" as a virtual package requiring

I think you mean "yatc-data is a meta-package". If it were virtual,
it would be simply provided by the tibia-data package.

"tibia-data", and later including its own data in place of original data?

That would be a good approach. Note that if you use the virtual-package
approach (as opposed to the meta package approach) you can't rely on having
versioned depends, since you can't have a versioned depends for a virtual

Second, the client supports only one set of data files; data files are

You said earlier it can support multiple data file versions!?
You mean that you can install either of some set of data sets, but only
one at a time?

not choosable. Client will automatically detect the version of original client from which the data files are taken, and use the appropriate version of the protocol. So I'll be definitely putting the data into /usr/share/yatc or /usr/share/tibia, but we can package one or more packages, and set one of them as a requirement.

Should we be packaging several versions of tibia-data, one for each supported and still widely used version of the client's protocol? For example:
* tibia-data-7.92
* tibia-data-8.00
* tibia-data-8.10
et cetera. Or should we just create one package based on the latest version of the official client, since the data files can also be placed in ~/.yatc/ or even in current work directory, and thus if user needs a different set (s)he can get the data separately?

Neither. I think you could install them side by side and have a tool that
allows you to choose the correct one. How, you ask?

Simple, provide each data set under its own: /usr/share/tibia-X.YZ and,
through the chooser (you can use debconf to select the default) you make
a /usr/share/yatc a symlink to the active data set.

Third, original company distributes a GNU/Linux version in a .tgz form. We work on one due to potential future license issues when used with OpenTibia as opposed to Tibia servers (which currently don't exist), and due to technological deficiencies of the original client's GNU/Linux version (a 2d game unable to run without an advanced 3d accelerator?!)

We could fetch the .tgz containing the data with wget and unpack them during .deb installation or dpkg-reconfigure. Is this a good practice with non-free data? Do other packages do such tricks?

Yes, see flashplugin-nonfree.

Fourth, how would you propose to package the data? What does a typical data-only source package structure look like? Can someone send me a .tar.gz on my private mail of a sample package structure that would create a .deb out of some sample data files, e.g. "text1.txt" and "text2.txt"?

That is usually a plain file structure. cp -r usuallly does the copying
of the files into debian/tmp. That directory becomes the internal
structure of the package.

Important notice: We're still not going to try to get into Debian by itself, and we're just preparing .deb packages. Data files issue should be discussed with the developer company before trying to do something like that, or otherwise both the maintainer and Debian could be in trouble. Besides, the client is not of production quality, in fact, it's unplayable since even attacking monsters is not possible.

But, some day ... :)

"Imagination is more important than knowledge" A.Einstein

Reply to: