<snip> > > 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.
So how do we do history support then? Have a "get object at x"? Where X is the turn? Ghost objects really fall under the next section rather then "History data". <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. <snip> > > 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). The reason I was thinking about it like this is too allow the following type of game play, - each time you "encounter" an enemy ship you have an x% chance of detecting a component you don't know - each time you "scan" an enemy ship you have an x% chance of detecting a component you do know So for example, You see an enemy ship of type "Super Blaster" your scanners detect that it has "10 Weapons Components, 6 Electrical Components and 2 Engine Components". You have a battle with enemy ship of type "Super Blaster", you discover it has at least 1, "Laser Type 2 component". You have another battle with enemy ship of type "Super Blaster", you discover it has at least 2, "Laser Type 2" components. etc.... You could even do something with "signatures", IE each component has a signature which once known is used to detect the component. For example, You have researched the "Big Engines Type 1" component, so you can automatically know when a ship (within scanner range) has this component. After a few battles you discover the signature for "Phasers Type 6" which you can then automatically know when a ship as this component. > 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. Ahh, but who defines what can be detected separately? I can see this being very ruleset specific, specially if they have different types of "speciality" scanners (IE Detect radiation at 5 times the normal range, etc). Mithro _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
