news listing


November 27, 2001:

The archives from Nov 17 were build with a version of generalobject.c that still contained the error. Thus, both the source distribution and the binary distribution actually didn't fix it. New archives are available on the download page.


November 17, 2001:

I've been notified that xk can be run on Windows XP, using X-Win 32. You can look at a screenshot of it. Send mail to Hauke Johannknecht to get information about how he got it to run.


Following the ToDo list of November 2nd, 2001, I've begun to overwork
Util.dat processing. A new file has been opened, process_utildat.c, that
seperates the funtions that do Util.dat processing. The following is heading
that new file, to describe a path things might go. It depends somewhat on
what can be expected from Phost development.


// created: November 03, 2001
//
//
// This file contains functions to process Util.dat stuff.
// A reasonable way to implement processing would be like the
// following:
//
//
// 1.) Read all records from all available Util.dat files and link
//     them into a single GO chain.
//     The information from which Util.dat the record originates must be
//     stored in the GO nodes.
// 2.) Browse through the GO chain and check the ControlRecords.
//     On each GO node, set the turn number that comes from the
//     belonging ControlRecord.
//     Ask the user what to do with outdated Util.dat information.
//     If the information should be skipped, unlink all GO nodes that
//     are outdated.
// 3.) Make the information from the GO chain available in the form
//     required.
//
//
// Suggestions:
//
//
// 1.) Abandon the model of fixed max. numbers of objects. Maintain all
//     object information in GO chains. To do this, generate appropriate
//     GO nodes from the available sources of information (data files like
//     pdata.dat, bdata.dat etc.) and the Util.dat records. Records to keep
//     information about planets and other objects need to be defined.
// 2.) For each turn, save the collected information to disk.
// 3.) On loading data, at each turn examine the saved information and
//     provide backtracking information. For example, if a planet has
//     been scanned/visited, the available information should be displayed
//     on the map, telling the user from which turn the information is.
// 4.) Efficient methods to maintain and access the GO chains must be found.
//     The scope of changes reaches all parts of the program.
//     Probably it's best to stay object-orientated in the sense that for
//     different types of objects seperate GO chains should be maintained
//     (mine fields, planets, bases, ships, worm holes, ion storms).
//     Maybe wormholes and ion storms should be linked into the mine field
//     chain because these are objects that are mostly just been drawn onto
//     the map, each type in a similar manner.
//     Accessing objects is usually done by provinding an index. These
//     indexes must somehow be efficiently translated into GO node accesses.
// 5.) Provide a set of functions to do the GO node accesses.
// 6.) Object identification should somehow be improved --> unique IDs.
// 7.) Internal data management of xk becomes independant from the underlying
//     data structures supplied within the files from RSTs. This allows to
//     internally extend the available data to support, for example,
//     advanced automatisation and planning methods.
//
//
// Order of implementation:
//
//
// 1.) Overwork the Util.dat processing


mailto: lee@yun.yagibdah.de
Last modified: Wed Nov 28 18:19:09 CET 2001