Actually, I think we have two different use cases here. It might be better to separate them into two different OrderParameters.
One for selecting things in general, with one weight for each item. The other
would be for Resources, which can use the resource description for the
weights. The former (generic) case follows my previous structure and would be
used for Build Fleet orders (for example). The latter could look like this:
Resource list:
* List of selectable:
* id, resource id
* max quanity
* max mass
* max volume
* List of selected:
* id, resource id
* quanity
The generic case discussion is below, with a few more comments from me.
On Thu, 22 Nov 2007, Brett Nash wrote:
> > > I'm just thinking this takes the normal case for building stuff really
> > > nicely... So building ships and stuff can be done automatically in the
> > > client in an easy way?
> >
> > So, yes the refsys "type" field is necessary...
> >
> > > Also trading games with different cargo units can work with the list
> > > easily too.
> >
> > How well will total weighted max work with both resource "size" and
> > "mass"? Could there be a problem there? IE, hitting the max size OR the
> > max mass?
>
> It just wouldn't work at all.
Hence the above Resource List.
> To do that we'd have to change it to:
Because this seems to be getting too complicated...
> Each item adds:
> * A list of:
> ...
> * List of Weightings
> ...
> Then at the end:
> * A list of:
> * Maximum weighting (0 for ignored - no limit on this resource)
> * A GRS to the 'resource'.
>
> So basically instead of a single weight, we get a vector for each item.
>
> The final list would contain a reference to the resource type in use.
>
> The result is so the UI can do things like:
> Scouts * 3 (9 Ironium, 3 Germ, 21 Bor, 1128 Resources)
> Destroyer (50 Ironium, 42 Germ, 122 Bor, 29 Resources)
> ..
>
> Used: 50 Ironium, 45 Germ, 143 Bor, 1157 Res)
> Maximum ( 200 Ironium, 9843 Germ, 145 Bot, 1200 Res)
>
> Using 0 limits it means full costs can be calculated in games like
> Stars!.
There is already a resource list in the Order frame to specify what resources
will be used in doing the order. So this is already available. Build Fleet
order in Minisec uses this already.
> > > * A list of:
> > > * a UInt32, read only, id of what can be selected
> > > * a String, read only, String Name of can be
> > > selected
> > > * a SInt32, read only, maximum number of can to
> > > be selected, -1 means no limit
> > > * an UInt32, read only, weighting.
> > > 0 means doesn't count to limit
> > > * a GRS list, read only, What this item refers
> > > too
> >
> > Why a list?
>
> That's one for mithro ;-)
Questions still stands. Mithro: why a list for GRS per item, and why not just
a "list type" and use the item id as a the reference (design/player/etc) id.
I note that tpserver-cpp already does this for the listparameter in Build
Fleet in minisec.
> Regards,
> nahs
Later
Lee
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
