Re: Data files for a MMORPG
Ivan Vucica wrote:
Cheers,
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
tibia-data
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
package.
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 ... :)
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
Reply to: