On Saturday 30 December 2006 19:04, Tim Ansell wrote: > As these emails are getting very long I'm going to split this into a few > separate lines of thought. > > These two issues are ultimately linked. The most important factor we > need to considering these issues is the "Changing client's shouldn't > loose you any information" requirement. <snip> > > > Say a Ship goes to Planet A then Planet B and then Planet C and "scans > > > for details" at each planet. The planets are however quite close > > > together, this means that it only takes 1 turn to get around. If you > > > "miss" turn 2 then you miss the details about Planet B. > > > > > > Plus if you no longer have a ship at Planet B it should still list what > > > it was like when you last got there. > > > > > > This is kind of like how in StarCraft where the Fog of War showed what > > > was there when you last was saw it. > > > > > > This is also seen in Stars! Where a planets details may have "128 years > > > ago". > > > > You don't need history support to handle this last case... but on the > > server side it is *nearly* the same implementation. > > > > Ghost objects (such as a stealth ships) which appear once and then > > disappear are reasonable in requiring history, but might be better > > implemented as a kind of "old sensor reading" object. Adding full history > > just adds to what the client could (and i imagine in libtpclient-py, > > would) download. > > There is also another use case, what happens if the client wants to > display a graph of the population on a planet over the years? It would > need data from each year. These graphs could actually be quite important > in many places (IE to see how adding factories improves production). > > I can't see a way to do these graphs without having all the previous > turns information available. You can't rely on the libtpclient-py cache > because this would violate the "Changing client's" rule. > > Can you think of a better way of doing this?
No. The amount of data that would need to be available just for that probably makes history support worth it. > > > > > * Partial object support. Sometimes you'll only have > > > > > permission/ability to only view parts of an object. For example you > > > > > might only be able to see certain stats of an object (IE tonnage of > > > > > a far away fleet). This would also concern the current problem we > > > > > have about > > > > > designs/components. > > <snip> > > > > I think there should be a differentiation between the following states > > > of fields: > > > 1. Current Data > > > 2. Unknown Data > > > 3. Old Data (and how old) > > > > > > The client needs to know about these different states to be able to > > > calculate and show correct information to the person. > > > > > > Any suggestions on the best way to do this? I thinking we need an age > > > for each field because you may have the following situation. > > > > > > Scanners can see the size and environment stats. > > > Ships in orbit can see "installations" and population. > > > > > > You have a ship which arrives at a planet. > > > Te ship gets destroyed. > > > Another ship has planet in scanner range. > > > > > > Size/Enviroment stats keep getting updated until the second > > > ship is destroyed while the population/installation stats don't. > > > > > > At the moment it appears to me that every player will have to have > > > their own personal "view" of the universe. How this view is calculated > > > is up to the server. (I can see quite a nice way to do it in > > > tpserver-py.) > > > > Size/Environment isn't something likely to change often. But I get the > > point. > > > > But I can only see how much bigger this will make object frames, and the > > amount of data to be stored in the database (which isn't that critical I > > suppose). Any idea how we might do that? > > I was thinking that maybe we could have an "field age" list of SInts. > This would tell you how old each field is (with -1 being Unknown data) > in number of turns. > > For example, > > * a UInt32, Design ID > * a UInt64, the last modified time of this design description > * a list of UInt32, categories this design is in > * a Formatted String, name of the design > * a Formatted String, description of the design > * a SInt32, number of times the design is in use > * a SInt32, owner of the design > * a list of, > * a UInt32, component id > * a UInt32, the number of components > * a Formatted String, human readable feedback on the design > * a list of, > * a UInt32, property id > * a Formatted String, property display string > > Say we know the following information about an enemies Design and it was > last seen 5 turns ago with a good sensor reading 8 turns ago. > > [ 100, > 123456783, > [], > "Unknown Ship 1", > "This type ship was first seen at a battle over Planet X. It was last > seen at position (x, y, z)", > 0, > 0, > [(100 - "Big Hull", 1), (6 - "Weapons of Mass Destruction", 3), (9 - > "Unknown electrical components", 8)], > "", > [(99 - 'mass', "100kt")] ] > > [0, 0, -1, -0, 0, -1, 0, [(8, 8), (8, 8), (8, 8)], -1, [(5, 5)]] > > It would add 4 bytes (SInt32) for every value on an object. > > I think this information is very important in the long run however. It > would also get rid of the need for history data if we didn't need > graphing. > > Any thoughts on this proposal? For designs it is overkill. For most objects it's overkill. It might be useful to have one for the object as a whole (or turn number might be better). In the original usecase above, it would make sense to have one "age" (turn number) for each set of properties that can be detected separately. So the environment stats would have one, and the population another, the resources yet another. This would reduce your pre-field "age" to per-group-of-fields. > Mithro Later Lee
pgp0QjFI5AiyC.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
