On Friday 05 January 2007 14:36, Tim Ansell wrote: > > 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.
Thinking about it, we really only need two: Free space (3d) and "bound". In most cases, we don't need to specify where they are bound to. So either the 3 int64 position, or a uint32 object id that the object is bound to. > <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.) These aren't really queues. They are directions/goals/objectives to the planetry governor (or whatever). Maybe some sort of preference type is needed. Orders are the specific implementation of those goals/preferences. > We could also have a "hidden" object which could has queues to be use > for planet defaults or something. Well maybe. > > > 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.) That goes hand-in-hand with allowing multiple queues. > > > 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? Both are true. > I guess some people may want it to be a function of "logistics > technology". Hehe, now that would be interesting (if not kinda silly with a smart client remembering future orders for the player). > > > > > 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 Humm... I guess that is fine. > > > > > 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) Maybe. > > > > > 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. Ahh, I think I get it now. > > > 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 Fair enough. > > > 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? Could be, but more for Stars! like old planetry information. If you have visited a planet 27 turns before the current one, then it says the data is from 27 turns (years) ago. Also, time could be used for stats like time for population to double, etc. > Mithro Later Lee
pgpdEldGyAaN1.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
