Tim Ansell pisze: >> That's the Plotter's work. I used CappedMixingPlotter for that - it mixes >> colours of regions proportionally to relative strenghts of each players' >> influences. Non-mixing Plotters, where the colour is of the strongest >> player, don't look so good here, because the planets all have the same value >> and borders are ugly straight lines :) > > I would still like to see them :P
Hmmmmm, it would be hard to do now, after the demo1 restart. Last I checked the universe was empty :) >>> For fleets it should be pretty easy to assign a strength value, for >>> planets, http://www.thousandparsec.net/tp/dev/documents/minisec.php >> Hmm, fleets are not really a "territory", but it might look interesting :) >> Starmapper doesn't support moving nodes, but for TP each session involves >> only one turn, so it's not a problem here... > > Okay. ...but if I added a support for dumping the data to a file for later "historical" use, it would be a problem. The reason I started Starmapper was because I wanted to do maps of a Stars! galaxy based on all data available, from all players (at least from those that I could make to generate reports each year). After the game ended I just launched Starmapper and in a couple of minutes had complete illustrated history of the game :) >>> There is no standard way to detect home worlds, on tpserver-cpp look for >>> a homeworld resource. >> Hmmmm. But this is a formal concept in the game? > > Not sure what you mean by "formal concept". > > When doing a battle, planets act identically to either 2 or 5 > battleships (depending on if the planet is a homeworld or not). So somehow the server knows that... Does that also mean that it uses this knowledge to generate higher military value for home worlds? If that's the case, then I don't need to know what's a home world :) >>> Yes, Thousand Parsec supports async frames from the server (which you >>> should notice have a Sequence Number of zero). >> Oh, good to know :) > > I see some support being added to libtpproto-java :P Yep, and I really like how I did that ;) (and as it turned out, the server seems to make stronger assumptions than I did - the responses are always in the same order as requests and if a response consists of several frames, they are sent contiguously; I designed PipelinedConnection to be able to handle even intertwined and not-in-order responses) -KS
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
