Okay, this email is going to be a bit long as it is going to cover a lot
of your stuff.
Could you push your changes to the document repository to a branch? This
would let us see your changes easier.
---
Firstly, some rational about my thoughts,
TP04 does not need any "extra" objects file as the objects are
dynamically defined by the server in the same way orders are.
As TP03 has no way to define objects dynamically it needs a static way
to define them. Static object descriptions only effects TP03.
As we had always planned dynamic object description we decided to split
the protocol definition documents into to separate files (protocol3.php
and objects.php).
Hence, I don't believe that actual object descriptions belong in
protocol*.xml files.
----
Next, I think that the way object and order descriptions work should be
very similar (as it allows us to write once for both cases). How does
this description stuff work? Well you can think of it in "object
orientated" sense.
Object (or order) descriptions are the equivalent of "classes" and
actual objects (or orders) are the equivalent of "instances".
The classes are defined at the server. So for a client to be able to
understand what information the instances contains, they have to ask the
server for class definition - this is what OrderDesc and ObjectDesc
frames are.
----
Lastly, what type of requirements do we have?
* The ability to define different types of information (IE
Coordinate, Player, etc)
* The ability to define data relevant to that information on a,
* Per object/order instance level
* Per object type/order type level
* The ability to group different types of information together to
create a "compound" type
So why do we need this?
We need the first requirement so that the client can sensible display
the various information.
We need the second point so that we can "customise" the information
dependent on what is being selected.
For the first subpoint,
We want this so we can have a generic build order which can
specify which objects can be built dependent on the object
selected (or even position in the order queue).
You could think of these as "member variables" of a class.
For the second subpoint
We want the ability to define a bunch of information which is
common at type level, for example the various points on a
graph.
You could think of these as "static constant members" of a
class.
Each parameter defines both "member variables" and "static constant
members".
The last point we need so that we don't end up with 1000's of different
types of data. For example if we wanted information which could be
"aged" we can just combined the information with a "turns" parameter in
a group.
---
How does this impact the XML? The XML is *not* describing classes
directly, it is acting at a "meta level" and describe how we can
describe classes.
The XML needs to define what type of parameters exist, this information
needs to include,
The "static constant members" <descstruct>
The "member variables" <usestruct>
---
So here are some brief thoughts about how would I do this in java.
I would create a two "Parameter" hierarchy which looks like this,
ParameterBase
-> ObjectParameterBase
-> Type 1
-> Type 2
-> OrderParameterBase
-> Type 1
-> Type 2
ParameterInstanceBase
-> ObjectParameterInstanceBase
-> Type 1 Instance
-> Type 2 Instance
-> OrderParameterInstanceBase
-> Type 1 Instance
-> Type 2 Instance
The Type 1/2 level would be auto generated from the XML.
Each Parameter would have a member to store the "class static" values
and a function which returns a ParameterInstance type object of the
"member" instances from a string.
For example,
class OrderQueueInstance : ObjectParameterInstanceBase {
int queueid;
int numorders;
int[] ordertypes;
string structure = "II[I]";
}
class OrderQueue : ObjectParameterBase {
string structure = "I";
/**
* OrderQueue blah blah
*/
OrderQueue(int ms) {
maxslots = ms;
}
/**
* Maximum Slots
*
* Maximum number of slots that can fit in this order queue.
*/
private int maxslots;
int getMaxSlots() { return maxslots; }
/**
* Convert a string to a dictionary for this parameter
*/
OrderQueueInstance convert( string abc ) {
return OrderQueueInstance(*unpack(OrderQueueInstance.structure,
abc));
}
}
ObjectDesc objects would then have a vector of ParameterBase's while
Objects would have a reference to ObjectDesc vector of
ParameterInstance's.
Hope this helps and keep up the good work!
Mithro
<snip>
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
