Re: Data files for a MMORPG
On Thu, 24 Jan 2008, Eddy Petrior wrote:
Ivan Vucica wrote:
Cheers,
first, sincere apologies if this is a confusing message, but I'm trying
Indeed confusing.
Sorry :)
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?
One example of things that change between versions are item identifiers
A server running on a particular set of "server data files" designed for a
particular protocol version can run only with particular set of "client
data files" designed for the same version.
That sounds like a legal issue you must solve or avoid (and avoid your users
to get into it).
Yes, three solutions are:
1) Get in contact with the company and ask them for permission
Unlikely.
They don't really want an open client due to large cheating problems already
present in the game or they'd open up their client. So, we're "getting
away" by developing a client for OpenTibia Server, thus making legal
doubts about it clear. (Company's game rules forbid modifying the client,
and anyone breaking those rules cannot legally use the service according
to the license agreement. But LA can change at any time.)
2) Fetching the real client and unpacking it automatically.
That's what users currently do, only manually.
Except, instead of using the data with their client, they'll use it with
ours. No clause in License Agreement or Rules mentions this.
3) Creating our own data set.
Eventually.
A fact is that there's 20000+ 32x32 sprites we'd have to replace. True,
many are similar and rare, but it is still 20000+ sprites. Community has
proven to be lazy, or perhaps we served them incorrect tools.
I think you mean "yatc-data is a meta-package". If it were virtual,
it would be simply provided by the tibia-data package.
Well both solutions are ok, since indeed yatc-data will be provided by
tibia-data, but still we may someday want to replace it with real data.
So meta-package is a better solution. Thanks!
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?
Yes, it supports multiple data versions.
Yes, it supports only one set at a time.
:)
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.
Hmph.
Well, we could build that into the client too. Ok, I'll keep that in mind.
Yes, see flashplugin-nonfree.
Does it do the trick with data, or with code too?
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.
I think I am not following you there. I saw debian/yatc formed, not
debian/tmp during package building?
Well nevermind, I think I'll figure this out over time ;)
Reply to: