> Yeah.
>
> The three I can think of are:
> - 3d free space
> - 2d planet surface
> - (0,1 or 2d) "inside" (such as in carrier, spacesation, drydock, etc)
Okay, supporting all these types shouldn't be to hard.
I think we should make a distinction between "bound" objects and "free
space" objects. Bound objects wouldn't really appear in the star map.
<snip>
> >
> > > > Order Queues -
> > > > Currently we only have one order queue. There is no real reason an
> > > > object couldn't have multiple order queue's.
> > > > This could be used for where you want a separate "Build Queue" to an
> > > > "Action Queue". It could also be used on ships where you have an
> > > > "Battle Queue" which specifies what the fleet should do in battle (IE
> > > > Attack hard for X turns, run away).
> > >
> > > Your "battle queue" is not really a queue, but some sort of "standing
> > > orders".
> >
> > Another option would be a "Default Order Queue". IE If you wanted new
> > fleets to have a "move to x", "remote mine" default order queue.
>
> That is a tricky one. I guess it would be possible to add that to the
> player's
> data (although I have no idea how tpserver-cpp could handle that). The most
> useful use of that is for new planets.
I was thinking per planet. IE A planet could have the following order
queues (on one particular server).
1. Build Queue - Things to build, Order Types (Build Fleet, Build
Infrastructure, Nop)
2. Priority Queue - What the planet should concentrate on, (Nop,
Research, Production, Defence)
3. New Fleet Queue - What orders are given to a new fleet (Any order
valid to a fleet this planet can build - IE Move, Remote Mine, Create
Minefield, Merge Fleet.)
We could also have a "hidden" object which could has queues to be use
for planet defaults or something.
> > I think the client should handling "Order Queue"s which only have one
> > type of order specially.
>
> What do you mean by "type of order"?
>
> Each object specifies what orders can be placed on it. Therefore only the
> type(s) of orders are allowed.
Each queue specifies (on each object) which type of order is allowed in
that queue. (Rather then the current per object order types.)
> > Maybe order queues could also have a possible "limit" on the number of
> > orders can be put in them.
>
> Not hard to do either. Although most of the time, the limit will be one of
> these things:
> - the human player's patience entering the orders
> - the resources at the object (fuel, supplies (endurance), or other normal
> resources)
> - boredom
There might be game play reasons for restricting queue length. (IE
Trying to simulate a less enlightened game.)
Or maybe the object can only have 1 order at a time?
I guess some people may want it to be a function of "logistics
technology".
> > > > Reference Property - Refers to something else (for example a player,
> > > > a design, etc)
> > > > List Property - Lists a bunch of other properties (IE Resources would
> > > > be a list of reference properties?)
> > > > Choice Property - Can make a choice of something.
> > > > Graph Property - Some type of graph, with the location where the
> > > > current value is and where it is heading. This could be used for
> > > > production capability (which is likely to be non-linear).
>
> > > > I still think we need a bunch of
> > > > common arguments which all objects must have.
> > >
> > > Ok. Any suggestion as to what those could be?
I was thinking a cut back version of the current common attributes.
* a UInt32, object ID
* a UInt32, object type
* a String, name of object
* a String, description of the object
* a list of UInt32, object IDs of objects contained in the current
object
* a UInt64, the last modified time
* x by UInt32 of padding, for future expansion of common
attributes
*
* extra data, as defined by each object description
> > > > We could describe a planet in the following way,
> > > > Temperature - Hab, Range (0K - 10,000K)
> > > > Radiation - Hab, Range (0Rad - 1000Rad)
> > > > Gravity - Hab, Range (0g - 1000g)
> > >
> > > I think you will find that all three of those should be exponential
> > > scales, not linear.
Maybe we need exponential type too? I could see that things like dB
would be pretty useful (IE Signal strength etc)
> > > > Production - Goodness, Graph (X - Value, Y - Production,
> > > > Points[(x,x), (x, x), (x, x)])
> > >
> > > I notice in the example below that this is written as "(89%, +10%)" which
> > > bears no resemblance to the description above. Just what does this mean?
> >
> > 89% -- current value, +10% where the value is currently heading (IE to
> > 99%).
> >
> > It would be to give an indication of where the values are heading.
>
> Ahh, I somewhat see what your saying. Could you map the two examples to each
> other please? What does "(89%, +10%)" look like in "Graph (X - Value, Y -
> Production, Points[(x,x), (x, x), (x, x)])" form?
The graph is described by a bunch of points which are connected
together. These points are listed in the argument description (rather
then sent with each object).
The object only gives the current point on graph (and where the value is
heading).
For example, a Planet Desc may have the following,
Graph - [(0, 0), (100, 10), (200, 0)]
Which describes a triangle. When you get a Planet however you get
(100, +100) - Which means that I can display a dot/line on the graph at
100 with an arrow pointing towards 200.
The actual graph part is more a nice UI issue I guess.
> > A gauge type would be displayed as a gauge. An integer would display as
> > a number. Some of the other things are important, IE its better for the
> > client if it knows that the value should be between X and Y.
>
> That wasn't the bit I was worried about. It was the "Descriptional
> Properties", "Habitation Properties", "Resource Properties", "Goodness
> Properties", etc.
It was just a way to group them logically for us to see if we have
covered everything. :P
> > IE See the order arguments stuff.
> >
> > > Time properties (ie, age, etc) don't appear. I might have missed them
> > > from the brain dump. Could be interesting to have the age of a colony or
> > > fleet.
> >
> > As in "Turn first seen at", "First created at", etc?
>
> Yeah, but more specifically "info is X turns old" (but presented in absolute
> turn, so curr_turn - turn = X).
Is this related to the History support in the other thread?
Mithro
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
