TripleA

Messaging :

Most of the messaging changes are done.  There are a
couple more things to do with threading and the
history, hopefully I can do that soon.

For those who are interested, almost all the messaging
work id done in UnifiedMessenger.  ChannelMessenger
and RemoteMessenger are both based on this. 
MessageManager has been removed, and Messenger
shouldnt be used to send messages by anything other
than UnifiedMessenger.


Logging :

I added some logging code using the java.util.logging
packages.  There is a file called logging.properties
in the data directory that controls it.

You can see all the objects (and there size) passed
over the network by editing the 

games.strategy.net.Connection.level=WARNING

line, and set the level to FINEST.


Maps :

Each map now has a map.properties file.  This is used
to set the color for each player.  I think we are
finally at the point where new players can be added
without a recompile.  



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com

I have added Thomas Matthijs's fix for TripleA's path name when finding 
the Root folder for triplea (GameRunner.java)

I as well started changing the path names around in triplea. I took the 
idea from Thomas Matthijs again to have TripleA look for a path relative 
to the package name ie. /games/strategy/ ...etc  I put the fully 
qualified map directory path in Constants.java along with a constant for
a file separator ie. "/" or "\" if on windows.. handled by Java VM for
platform independency or something.

It all works except for the Map Skins selection code. I tried to mess 
with it, but it keeps throwing a null when trying to get a directory 
listing (TripleAFrame.java)..

Currently the source is like so:

final File mapsDir = new File(System.getProperty("user.dir") + 
"/../classes/" + Constants.MAP_DIR);

Ideally I want it to use the Constants.MAP_DIR alone without depending 
on the "user.dir" and the "/../classes/"

The MAP_DIR = /games/strategy/triplea/image/images/maps/

This won't have any problems with people who install triplea out of the 
box.. but will for people who install triplea via a Gentoo ebuild or any 
package that places the binaries else where.


-- 
NeKromancer (also known as George)
nekromancer@...

"Everything is never what it seems"
"Followers believe, but leaders are the believed"
"People are willing to abandon you, learning disabilities won't"

Hi,

Just wanted to say that I don't think I will have immediate time to 
check out how to add convoy zones for A&A Europe. So someone else can 
check that out.

For now I will concentrate my efforts on the map utiles and the xml 
editor. Just a note, the xml editor is pretty close to being done. Some 
small stuff I Gotta get out of the way, I 'll probably give the current 
map utils a face lift as I did with the polygrabber (ie, giving them a 
menu bar) was even thinking of included a "Help" menu item that lists 
some help on how to use the program.

-- 
NeKromancer (also known as George)
nekromancer@...

"Everything is never what it seems"
"Followers believe, but leaders are the believed"
"People are willing to abandon you, learning disabilities won't"

Hey,

I added a new type of thing to TripleA.

The problem was that IDelegates could only talk to
IGamePlayers, this leads to two problems.

The first is that 1 user interface may be associated
with multiple game players.  If a delegate wanted to
send information to be displayed on the screen, he had
to send it to all GamePlayers, and the game players
would have to co-ordinate so that only one of them
showed the info on the screen.  This was done by the
hacky MultiDestinationMessage (now removed).  The
MultiDestination message was ignored if it had already
been processed on the given vm.

The second problem was that if you want to have an
observer, without a game player on the vm, you can
only  watch game data changes and step changes.  There
was no way for the delegates to convey information to
the ui other than through a IGamePlayer.

This has been fixed with a new IDisplay.  An IDisplay
is meant to represent a user interface.  The
delegateBridge has new methods to allow a delegate to
broadcast information to all IDisplays.  When an
observer plays he will have 1 display and no game
players.  When a player is playing he will have 1 or
more IGamePlayers, but only 1 IDisplay.

Game players that interact with the user will
generally be connected to a IDisplay.  How they are
connected is left to the code that creates game
players (IGameLoader).

Some GamePlayers like AI's will probably not be
connected to a IDisplay.

Sean


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail

Hey,

As part of the conversion to use the new messaging
classes, I redid the cryto random source.  We now have
a generic Vault.

Players on any vm can lock data in the vault, and then
can unlock the data at a later time.  Other players
cannot see what is in the vault until it is released.

When the data is unlocked, other players can confirm
that what is unlocked is actually what was originally
placed in the vault.

CryptoRandomSource now just uses the vault to encrypt
and decrypt the dice rolls.

The vault code is in games.strategy.engine.vault,
while  CryptoRandomSource is in
games.strategy.engine.random

The CryptoRandomSource gets its random numbers from a 
PlainRandomSource, so it will use the new twister
random algorithm.

Sean

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com