Jump to content
XCOMUFO & Xenocide

XNet Definition File format


chrisp_21

Recommended Posts

Great!

Please take a look at interface submission made for PAQ and FontRenderer in Sourceforge.net mailing list. This will show you an example of what would you need to do first.

I will write up a requirements list for XNet Definition Loader shortly.

Link to comment
Share on other sites

Great!

 

Here are requirements for XNet definition loader:

- XNet Definition Loader (XNDL) will be an object, which read XNet Definition File from file system (eventually definition file will be stored in PAQ).

- XNDL will store read information in the memory and expose set of 'get' methods to retrieve the information. Note, the information is read-only.

- XNDL will have methods to provide additional information about data definition, for example: what is the number of categories? what is the number of entries in each category? etc.

- XNDL will not have methods to retrieve entry data from file system. This functionality will be implemented in other classes.

- XNet Definition File (XNDF) will be a file in XML format, which describes existing data categories, entries for each category and information location for each entry.

- Entry's information will be located on the file system in data type specific directories (eventually those directories will be stored in PAQ).

 

This thread will be "the number one" documentation.

 

 

If someone sees anything missing, please comment promptly.

Link to comment
Share on other sites

Here is what I've started for the XML data..

 

EDIT:

 

Sorry for some reason I can't upload anything.  You'll have to get it at:

 

http://stormhaven.ecn.purdue.edu/~djchrisp/xnet.xml

 

 

Just a start.

You almost nailed it! I bet you have not read the thread I point to in my previous post, but still there are very few things that need to be changed:

- some entries will have a 3D model in addition to image;

- there must not be any text which we will display on the screen in this XML file. Reasons: a) eventually game will be translated to other languages. All language specific files will be kept in separate directory. Ideally there will be only plain text files; B) it is job of Creative Text Department members to name things and to provide descriptions to them; c) some descriptions are very long. they would clutter XML too much. So, please use a references to some external files which contains, names of categories, entries and descriptions;

- there could be special descriptions, like stats, which might require special display format.

Link to comment
Share on other sites

Ah, I did read that way back when but long since forgot about it.

 

Wow.. two weeks.. didn't quite make that.

 

I figured I was a little off, that's why I posted an early example. :)

It makes since to not include the text.. I should have thought of that. :/

 

The descriptions are very long, and that is one thing that I personally

am not very fond of, but that's not my department so I won't throw a

fit. I know I very rarely read the text when there's that much, and I'm

the kind of guy who will keep playing a game just to uncover those last

few secrets.. There's no harm in it though.

 

It sounds like we're on the same page on how the XNDL is stored in

realtime. From what you wrote it sounds like we are to load the

class into memory and simply keep it there. So there are no trees

or lists to search, just a series of get methods. This is what I had in

mind because it shouldn't take up that much memory and will eliminate

search time. I figured we would load it whenever the geoscape starts up

and keep it in memory as long as the game is in geoscape mode. I've

done similar classes before so this should be pretty straightforward.

Link to comment
Share on other sites

I am not fond of long descriptions too, but I guess there are people who would love them.

 

As far as loading go, I think it is fine to load it on geoscape initialization, since it will not take lots of memory anyway. However, to make things more clean, I suggest to load info and to create XNDL only when XNet view will be called. That is if player will never open an XNet view, XNDL will never be created. Minor memory usage improvement as well.

Link to comment
Share on other sites

  • 3 months later...

Mamutas/Crisp-

Has additional work on this XML file occurred? I've been wondering what format and naming conventions would be needed for the individual entries, I'd be happy to pick up this task and finish for you. I'm not a programmer, but can read up on XML, it appears fairly straight forward so far. It seems there are 2 parts needed: this definition file which calls the individual data files; and the data files themselves.

 

Regarding the data files, yes they are pretty long for the most part, but my intent is to have the in-game stats be the very first thing, followed by a short paragraph at the beginning with a summary for those who don't want to bother with all the details, then the remaining text.

 

To clarify what you need, should the stats for items include the price/build times as well, and should all the stats be pulled from a file seperate from the descriptive text? Could these stats be part of the definition file, or should they make up a third file? For the definition file, reading previous posts, it should include:

 

xnetentry (generic name)

category (like craft or weapon)

imagefile (png filename)

modelfile (3D filename)

stats (actual damage/range type stuff)

description (text entry)

 

Should there also be some type of counter Mamutas, for determining how many entries as you said before? Could it be built into the naming system, or does it need to be numeric variable so the code knows how many button/entries to make for the UI?

Link to comment
Share on other sites

There is a discussion about research tree definition which somehow intermingled with XNet entry discussions. It is in SF mailing list.

 

Here to answer your questions.

 

-Should the stats for items include the price/build times as well?

Not necessarily, that kind of info belongs to strategy guides, but we might show it here too.

-Should all the stats be pulled from a file seperate from the descriptive text?

It will be better to have them in separate file as far as I see. Cause they are really independent on descritpion and could be changed often during balancing.

- Could these stats be part of the definition file, or should they make up a third file?

Definition file does not have any context text in it, but just refers to files which has it. For example, for rifle it will have something like:

<Rifle>

stats="text/stats/rifle.txt"

description="text/descr/rifle.txt"

image="images/rifle.txt"

</Rifle>

 

- Should there also be some type of counter Mamutas, for determining how many entries as you said before? Could it be built into the naming system, or does it need to be numeric variable so the code knows how many button/entries to make for the UI?

I am not sure what counter were you talking about, but there should be an category description like:

<Category name='Weapons'>

entries=rifle, pistol, cannon

</Category>

The definition loader will load that data and will be able to provide the counter to UI.

 

Check SF mailing list, ChrisP has posted his initial version there.

Link to comment
Share on other sites

×
×
  • Create New...