later on make Engine and XiStratPanel extend s.th. and put that source code into 1 single place
(or whatever design pattern (composition vs inheritance) might be used instead to avoid ugly copy/paste)
clientCore calls this after loginAck by server
does as well hashTables declaration and initialization
find out about the area to be rotated in atomic Rubik move: give them their vertices,
as if they would have been stored in database as regular face (with arbitrary number of edges though)
Tells every PlayerServer output stream to inform its clients the
game has ended and that they should reconnect to their original
adx:port to regain proper socket.
actually do the move, thereby keep track on preceding state, so
copy the _figures' array by value (but the single objects are not by value, only by reference)
F4Message wrapper class for messages
A message is used only (ONLY) between:
F4Server and F4Client, before the actual start of a game
PlayerServer and F4Client, after a game has been set up
it is NOT used between F4Daemon and PlayerServer whatsoever
There are many msgs.. usually a message is a requesto of
info, LOGIN, and there is the corresponding ACK, LOGIN_ACK
All message packing/unpacking of params is encapsulated in package "msg"
F4Message does message dispatching, i.e. building of proper
method calls from strings representing a socket emssage.
instead of using an abstract class Figur3D and extending for each type of piece,
we use only one class and deal with 'if then' constructs for the parametrical details
this method constructs the trails for a system of two Chess pieces of type A and opposite colour
there are reasons to construct the orbits prior to a representation dump, because that way one orbit may be used several times later for different combinations of generators/labels
at the moment we create the trails for all possible starting positions, this implies of course quite a lot of memory space consumption, and one could reuse a once contructed orbit in case a legal position to start with has already been reached within another trail before
this would save some space, but later on the retrieval of the trails (given a position) would require more time, since one would have to search within the orbits a little bit. but there is certainly a way to avoid this problem by using a faster data structure like an array or a hashmap or whatsoever
pay attention to the fact that the actual orbit and the originally intended places may not coincide due to dynamics
uses neisF
assumes that faces or holes a and b are connected at max once
used for computing the label of the directed edge
for holes edges we don't need this method
getLabel() -
Method in class org.xistrat.util.d3.vrmlgraph.Node
get neighbours (without using an edge iterator)
neisF[k][0] will not necessarily go over an edge with the points face[0][k], face[1][k]
(we could change the order of loops below to achieve this, but instead we prefer knowing for sure that neisF[k][0] is always not pointing to a hole)
default is to deal with flip/rot generators
default with -s: 0, 1, 2, 3 specifies if
0:(default) glueShapes and the 'double' is used,
or 1: labels pointing towards holes are fixed,
or 2: holes are treated as valid faces,
or 3: the full double including the projection and dual rot about vertices,
or 4: if additional to the -s=0 situation we use pairs of points instead of faces for the labels
-f: (crude) chess pieces groups in case pieces are specified
-m: adjacency matrices (in the future perhaps as well with pieces)
-q: 'vector' groups (for the moment only piece A)
-q with -s: 0, 1, 2, 3, 4, 5 specifies if
0:(default) 'vector' group,
or 1: projection in 'vector' labels (+rot),
or 2: standard local rot default and flip in 'vector' labels,
or 3: the relations stuff,
or 4: the Schur cover (spin groups with torsion),
or 5: some atlas papermodel thing is dealt with
-rf: autogenerate infiles for all intermediate states
-rg: dump atomic "Rubik"-like morphing groups
-kd and kp: knot will dump out writhe and finally Jones-Polynomial
-c: autogenerate for generating quasicrystal (Penrose etc.) files
Apply the spring embedding method to the graph data
Calling this method allows the number of calculations
to be specified, but all other values shall take their
defaults.
bulk data object to represent a single atomic move
(what piece it is, and if it's killing another piece and so on,
can be found out by using the corresponding position of all pieces.
may be pass in the turn-based mode
as well as indicating that my 'removing stones' is done from my point of view
(the latter may be omitted again when GoRules and/or GoEngine can estimate status of dead stones itself)
PASS -
Static variable in class org.xistrat.math.GoEngine
behavior for two touching boundaries
as usual pay attention in case both ids belong to boundaries, because then next is changed downwards and the other upwards (and vice versa)
used to refresh colors (dependent on valid flag) and
orientation (it is assumed that the first valid polygon is given in correct vertices' order)
(and of course the overall surface must be orientable)
more cutting and gluing of rotis edges chains in case they have points in common,
and building of another inner lines (but aren't used later on)
(yes, it's copy paste from repairHoles() )
(didn't fusionate because somewhere here holes might play a role as well ?!)
some quite simple 'naive coloring procedure' variant
color all faces in a (deterministic or better) randomized way, then
uncolor vertices in case they have neighbours with same color and
finish with some greedy fillment
some quite simple 'naive probabilistic doubling procedure' variant
'color' all vertices in a randomized way,
(that is to say specify the switches for the dual_rot),
then undo where collisions occur, and
finally finish with some greedy setting
another option is backtracking
(and of course we hope that a deterministic procedure will be possible later on)
(and yes, actually now we have the -q -s 4 instead for the cover stuff)
if ok then a desired outcome has been found or not
ServerClientPrintStream
by Walter Gamba (walter@yagga.net) October 1999
the site is http://www.yagga.net/java
Specialized output Stream that describes the interaction between the Server
and the Client.
XiStrat client applet version
Parameters:
server=
port=
verbose=true|false
Simply instantiates a F4ClientCore and binds it to a F4ClientPanel, then
adds the panel to itself.