rails-devel — List for discussion of Rails development

RE: [Rails-devel] Provisional Token Idea

[Erik V. <eri...@hc...>]

> Erik -
> 
> Would it make things easier rather than having a provisional 
> Token, to have a provisional List of tokens?
> 
> When everything else about Tokens is dealt with in lists, 
> perhaps it makes more sense to do a ProvisionalTokenList for 
> previewing token placement.
> 
> What do you think?

I see, you don't want to have a single token in the GUI *and*
a list of (previously laid) tokens from the Model.
Yes, the prov. list would be a good solution.

Erik.

[Rails-devel] Provisional Token Idea

[Brett L. <wak...@ea...>]

Erik -

Would it make things easier rather than having a provisional Token, to have a provisional List of tokens?

When everything else about Tokens is dealt with in lists, perhaps it makes more sense to do a ProvisionalTokenList for previewing token placement.

What do you think?

---Brett.

RE: [Rails-devel] RE: Token laying

[Brett L. <wak...@ea...>]

>> 
>> >And the token is still only drawn after "Done" has been pressed.
>> >My idea was to draw the token as soon as the hex was clicked
>> >in token laying mode. This would show a "provisional token",
>> >just as with tile laying, to be replaced with a permanent token
>> >when Done is pressed. 
>> 
>> 
>> I don't think this is quite as necessary as it was with tile 
>> placement. Token placement doesn't radically change the look 
>> of the board.
>> 
>> I think that as long as we have the selected hex being 
>> highlighted to show where the token is going, that ought to 
>> be sufficient.
>
>I disagree.
>For 2-station tiles think the user should see in which station (city)
>the token has been placed before Done is pressed.
>But this is not urgent, of course.
>

Obviously we need to prompt the user as to which station he's placing the token in.  

However, don't misunderstand what I'm saying.   It would definitely be nice to preview the token lay before hitting 'done', but I don't believe that it's absolutely necessary.


I have found the core bug with the token placement.  Apparently there's some point separating the Hex-side Station list from the Tile-side Station list is failing and the tokens are being added to the Tile-side Station list.

I'll be working on fixing this today.


---Brett.

RE: [Rails-devel] RE: Token laying

[Erik V. <eri...@hc...>]

> >But still only the very first laid non-home token of any 
> company is shown!
> >(I have not mentioned this before, but this was also the case
> >with your original token laying code). 
> >BTW the station number in the call you added was 1 but should
> >have been 0: I got an exception. 
> >
> 
> 
> Ok... those items are fixable.

I've fixed the exception, but not the rest.
 
> It's really a two-part problem.  
> 
> 1) Are we adding the token to the station?  
> 2) Are we drawing the tokens in the hex in a way that we can 
> see all tokens?
> 
> I'll work on this.
> 
> 
> >And the token is still only drawn after "Done" has been pressed.
> >My idea was to draw the token as soon as the hex was clicked
> >in token laying mode. This would show a "provisional token",
> >just as with tile laying, to be replaced with a permanent token
> >when Done is pressed. 
> 
> 
> I don't think this is quite as necessary as it was with tile 
> placement. Token placement doesn't radically change the look 
> of the board.
> 
> I think that as long as we have the selected hex being 
> highlighted to show where the token is going, that ought to 
> be sufficient.

I disagree.
For 2-station tiles think the user should see in which station (city)
the token has been placed before Done is pressed.
But this is not urgent, of course.

Erik.

RE: [Rails-devel] Tile orientations

[Brett L. <wak...@ea...>]

If you can already export your data to XML, I prefer using that. 

---Brett.


-----Original Message-----
>From: "John A. Tamplin" <ja...@ja...>
>Sent: Dec 26, 2005 3:49 PM
>To: rai...@li...
>Subject: RE: [Rails-devel] Tile orientations
>
>On Mon, 26 Dec 2005, Erik Vos wrote:
>
>> Absolutely!
>>
>> But even then we will need XML tile definitions like the ones we already
>> have
>> (Tiles.xml and TileSet.xml), because these will be used to enforce the
>> rules.
>> So these or similar XML files should somehow be derivable from your tile
>> definitions.
>
>My personal preference would be to have a JDBC driver for access to game 
>information, and one backend could be using XML or other text files. 
>However, that may not have enough others who would use a database backend 
>to justify the effort (I would have it directly access my database so I 
>don't have to maintain multiple copies of the same data and worry about 
>keeping them up to date).
>
>In any case, it is trivial to generate an XML file automatically from the 
>database.
>
>-- 
>John A. Tamplin					ja...@ja...
>770/436-5387 HOME				4116 Manson Ave
>                 		 		Smyrna, GA  30082-3723
>

RE: [Rails-devel] Tile orientations

[John A. T. <ja...@ja...>]

On Mon, 26 Dec 2005, Erik Vos wrote:

> Absolutely!
>
> But even then we will need XML tile definitions like the ones we already
> have
> (Tiles.xml and TileSet.xml), because these will be used to enforce the
> rules.
> So these or similar XML files should somehow be derivable from your tile
> definitions.

My personal preference would be to have a JDBC driver for access to game 
information, and one backend could be using XML or other text files. 
However, that may not have enough others who would use a database backend 
to justify the effort (I would have it directly access my database so I 
don't have to maintain multiple copies of the same data and worry about 
keeping them up to date).

In any case, it is trivial to generate an XML file automatically from the 
database.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Tile orientations

[Brett L. <wak...@ea...>]

>I have made a new version of the TileDesigner database, which I will
>send to Brett for conversion to .gif files. I have also doubled the sizes
>of the tile numbers and revenue indicators, hoping that these would get a
>bit
>closer to being readable. I will change the XML accordingly. 


I wouldn't worry too much about tile readability while we're using GIFs.  Due to the rescaling we're doing within the game, I doubt there's much we can do until we're using a dynamically generated graphic.

I think the tile number and revenue indicators are best left in the tooltip window, for now.


---Brett.

RE: [Rails-devel] RE: Token laying

[Brett L. <wak...@ea...>]

-----Original Message-----
>From: Erik Vos <eri...@hc...>
>Sent: Dec 26, 2005 6:20 AM
>To: rai...@li...
>Subject: RE: [Rails-devel] RE: Token laying
>
>> Wow.  Now I can see why you got lost.   You've nested the 
>> token laying calls quite deeply.  I think much of this could 
>> be simplified, but for now it works with the one-line change 
>> I've committed.
>> 
>> In PublicCompany.layBaseToken() you were adding the token to 
>> the company, but weren't adding the token to the hex. After 
>> including a call to hex.addToken(), the token is being drawn 
>> on the map.
>
>But still only the very first laid non-home token of any company is shown!
>(I have not mentioned this before, but this was also the case
>with your original token laying code). 
>BTW the station number in the call you added was 1 but should
>have been 0: I got an exception. 
>


Ok... those items are fixable.

It's really a two-part problem.  

1) Are we adding the token to the station?  
2) Are we drawing the tokens in the hex in a way that we can see all tokens?

I'll work on this.


>And the token is still only drawn after "Done" has been pressed.
>My idea was to draw the token as soon as the hex was clicked
>in token laying mode. This would show a "provisional token",
>just as with tile laying, to be replaced with a permanent token
>when Done is pressed. 


I don't think this is quite as necessary as it was with tile placement. Token placement doesn't radically change the look of the board.

I think that as long as we have the selected hex being highlighted to show where the token is going, that ought to be sufficient.


---Brett

RE: [Rails-devel] Tile orientations

[Erik V. <eri...@hc...>]

> > We now have gif files with tiny numbers that are not 
> readable at all.
> > I have just created a new TileDesigner file with double 
> size numbers,
> > we'll see how that works after Brett has had time to create 
> gifs out of that
> > file.
> 
> I assume this is just a temporary solution and you still want 
> to use the 
> tile rendering solution I proposed, right?  Pre-drawn bitmap 
> images are 
> not suitable for a scalable interface (not to mention different users 
> having different resolution screens and preferences).

Absolutely!

But even then we will need XML tile definitions like the ones we already
have
(Tiles.xml and TileSet.xml), because these will be used to enforce the
rules.
So these or similar XML files should somehow be derivable from your tile
definitions.

Erik.

RE: [Rails-devel] Tile orientations

[Brett L. <wak...@ea...>]

Correct.  The preferred solution is dynamically rendering the tiles.

---Brett.


-----Original Message-----
>From: "John A. Tamplin" <jat...@ja...>
>Sent: Dec 26, 2005 11:51 AM
>To: rai...@li...
>Subject: RE: [Rails-devel] Tile orientations
>
>On Mon, 26 Dec 2005, Erik Vos wrote:
>
>> We now have gif files with tiny numbers that are not readable at all.
>> I have just created a new TileDesigner file with double size numbers,
>> we'll see how that works after Brett has had time to create gifs out of that
>> file.
>
>I assume this is just a temporary solution and you still want to use the 
>tile rendering solution I proposed, right?  Pre-drawn bitmap images are 
>not suitable for a scalable interface (not to mention different users 
>having different resolution screens and preferences).
>
>-- 
>John A. Tamplin					ja...@ja...
>770/436-5387 HOME				4116 Manson Ave
>                 		 		Smyrna, GA  30082-3723
>
>

RE: [Rails-devel] Tile orientations

[John A. T. <jat...@ja...>]

On Mon, 26 Dec 2005, Erik Vos wrote:

> We now have gif files with tiny numbers that are not readable at all.
> I have just created a new TileDesigner file with double size numbers,
> we'll see how that works after Brett has had time to create gifs out of that
> file.

I assume this is just a temporary solution and you still want to use the 
tile rendering solution I proposed, right?  Pre-drawn bitmap images are 
not suitable for a scalable interface (not to mention different users 
having different resolution screens and preferences).

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

RE: [Rails-devel] Tile orientations

[Erik V. <eri...@hc...>]

> > Yes, tile #45. I have chosen the one that appears in the PS18XX tile
> > set for 1830, as I think we should align with the PBEM community.
> 
> I would think mirroring what is in the actual game is more 
> appropriate. 
> For example, in some cases the PS18XX tiles are totally 
> unrelated to the 
> orienation used in the original game (in some cases even the 
> tile numbers, 
> such as 18MEX, since they were developed before the game was 
> published).

I agree with that, but I would not go as far as preconfiguring
different versions of the same tile in one game.
The base orientation will be defined in TileSet.xml,
and if people want to change the orientations defined there
to match their own game box, that's fine, but not our concern.

If a certain game has a consistent tile set of tile numbers, 
we'll use that. If not, we'll follow some common usage, e.g.
Steve Thomas's PBEM tile sets.
 
> > Yes, that is my approach too. The "database" now is Tiles.xml.
> > I have just uploaded new versions of the tile XML files.
> >
> > However, after a quick check of your database and some of 
> the games you
> > have published I now see, that you use Marco's tile 
> orientations rather than
> > the ones
> > that I found in the 1830 game box and in the PS18XX set for 1830.
> 
> I assume you are referring to the web tile images?  Those 
> have not been 
> regenerated yet.  I am about 80% done with merging all the 
> different tile 
> sources into my database (kept in Informix using the schema I posted 
> here earlier).  Too many things going on, but it will get 
> finished one day 
> and then I will regenerate all the tile images.

OK. It would be great if we could leverage your database
to provide tile sets tailored to each separate game,
but we'll have to see how that works out.

> > We clearly must make a choice which orientation set we will use.
> 
> I think the first question is what is the goal -- if it is to exactly 
> mirror what came in the box, there are a lot of complicating 
> issues such 
> as using multiple orientations in the same game and 
> (especially in 182x) 
> different print runs having different orientations.  If the 
> goal is to 
> support PBEM using only electronic maps, then choosing one 
> orientation is 
> best, even if you have to make clear that players using 
> physical boards 
> will have to carefully watch orientations -- otherwise, you 
> have to find a 
> way to disambiguate different tiles which have the same number but 
> different orientations.

Yes, see above.
The simple solution is one standard tile set for all games.
Better, but perhaps less easy to create, would be a separate set 
for each individual game.

> > But IMO displaying tile (and revenue) numbers at all
> > will only be worth while if we either succeed in 
> implementing SVC graphics,
> > or go for a separate gif file for each tile orientation (otherwise
> > the number reading directions will rotate with the tile).
> > And if we succeed in scaling the numbers such that these 
> are readable
> > and still do not overwhelm the map. I have my doubts on this aspect.
> 
> The way I intended to handle it was to automatically leave 
> out components 
> of the tile image depending on the size being drawn.  That 
> way, if you 
> have a sufficiently large screen area or are zoomed in to the 
> map, you 
> will see all the detail available in the tile.  If you zoom 
> out, you see 
> only the detail that is useful at that resolution.  I haven't 
> downloaded 
> and built Rails since the tile code has been working, so I don't know 
> exactly how you have implemented this.

We now have gif files with tiny numbers that are not readable at all.
I have just created a new TileDesigner file with double size numbers,
we'll see how that works after Brett has had time to create gifs out of that
file.

Erik.

RE: [Rails-devel] Tile orientations

[John A. T. <ja...@ja...>]

On Mon, 26 Dec 2005, Erik Vos wrote:

> Yes, tile #45. I have chosen the one that appears in the PS18XX tile
> set for 1830, as I think we should align with the PBEM community.

I would think mirroring what is in the actual game is more appropriate. 
For example, in some cases the PS18XX tiles are totally unrelated to the 
orienation used in the original game (in some cases even the tile numbers, 
such as 18MEX, since they were developed before the game was published).

> Yes, that is my approach too. The "database" now is Tiles.xml.
> I have just uploaded new versions of the tile XML files.
>
> However, after a quick check of your database and some of the games you
> have published I now see, that you use Marco's tile orientations rather than
> the ones
> that I found in the 1830 game box and in the PS18XX set for 1830.

I assume you are referring to the web tile images?  Those have not been 
regenerated yet.  I am about 80% done with merging all the different tile 
sources into my database (kept in Informix using the schema I posted 
here earlier).  Too many things going on, but it will get finished one day 
and then I will regenerate all the tile images.

> We clearly must make a choice which orientation set we will use.

I think the first question is what is the goal -- if it is to exactly 
mirror what came in the box, there are a lot of complicating issues such 
as using multiple orientations in the same game and (especially in 182x) 
different print runs having different orientations.  If the goal is to 
support PBEM using only electronic maps, then choosing one orientation is 
best, even if you have to make clear that players using physical boards 
will have to carefully watch orientations -- otherwise, you have to find a 
way to disambiguate different tiles which have the same number but 
different orientations.

> But IMO displaying tile (and revenue) numbers at all
> will only be worth while if we either succeed in implementing SVC graphics,
> or go for a separate gif file for each tile orientation (otherwise
> the number reading directions will rotate with the tile).
> And if we succeed in scaling the numbers such that these are readable
> and still do not overwhelm the map. I have my doubts on this aspect.

The way I intended to handle it was to automatically leave out components 
of the tile image depending on the size being drawn.  That way, if you 
have a sufficiently large screen area or are zoomed in to the map, you 
will see all the detail available in the tile.  If you zoom out, you see 
only the detail that is useful at that resolution.  I haven't downloaded 
and built Rails since the tile code has been working, so I don't know 
exactly how you have implemented this.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

RE: [Rails-devel] Tile orientations

[Erik V. <eri...@hc...>]

> > I have started checking the tile orientations in Tile Designer
> > vs. the files as provided with the games (1830 only so far).
> > (the standard is that the position of the tile number defines
> > either the S or the SW edge of the unrotated tile).
> >
> > It turns out that almost all 1830 tiles have a different orientation
> > in TileDesigner! However statistically unlikely it may be, the only
> > correct one (except the obvious tile #63) was tile #67!
> 
> You will find that different games use different orientations 
> of the same 
> tile, and sometimes the same game uses multiple orientations 
> of the one 
> tile (I believe there is one in 1830 that has multiple orientations).

Yes, tile #45. I have chosen the one that appears in the PS18XX tile
set for 1830, as I think we should align with the PBEM community.
 
> My solution was to define a canonical orientation and store it in the 
> database that way, and then for each game it could define a rotation 
> relative to the canonical orientation (even multiple 
> instances of the same 
> tile in different orientations).

Yes, that is my approach too. The "database" now is Tiles.xml.
I have just uploaded new versions of the tile XML files.

However, after a quick check of your database and some of the games you
have published I now see, that you use Marco's tile orientations rather than
the ones 
that I found in the 1830 game box and in the PS18XX set for 1830.

We clearly must make a choice which orientation set we will use.

Whether or not a choice for whichever "canonical" orientation is important 
depends on the question whether or not we will display the tile numbers at
all
on the map.
If we do, I think we should aim at displaying the tile number for each game
in the correct place as often as we can. Now that you currently are the most
prolific game publisher, the balance will shift your way inevitably...

But IMO displaying tile (and revenue) numbers at all 
will only be worth while if we either succeed in implementing SVC graphics,
or go for a separate gif file for each tile orientation (otherwise 
the number reading directions will rotate with the tile).
And if we succeed in scaling the numbers such that these are readable
and still do not overwhelm the map. I have my doubts on this aspect.

At least we need a spreadsheet listing the orientations of 
all common tiles in all popular games against your database.
Maybe I'll start one.

Erik.

Re: [Rails-devel] Tile orientations

[John A. T. <ja...@ja...>]

On Mon, 26 Dec 2005, Erik Vos wrote:

> I have started checking the tile orientations in Tile Designer
> vs. the files as provided with the games (1830 only so far).
> (the standard is that the position of the tile number defines
> either the S or the SW edge of the unrotated tile).
>
> It turns out that almost all 1830 tiles have a different orientation
> in TileDesigner! However statistically unlikely it may be, the only
> correct one (except the obvious tile #63) was tile #67!

You will find that different games use different orientations of the same 
tile, and sometimes the same game uses multiple orientations of the one 
tile (I believe there is one in 1830 that has multiple orientations).

My solution was to define a canonical orientation and store it in the 
database that way, and then for each game it could define a rotation 
relative to the canonical orientation (even multiple instances of the same 
tile in different orientations).

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

[Rails-devel] Tile orientations

[Erik V. <eri...@hc...>]

I have started checking the tile orientations in Tile Designer
vs. the files as provided with the games (1830 only so far).
(the standard is that the position of the tile number defines 
either the S or the SW edge of the unrotated tile).

It turns out that almost all 1830 tiles have a different orientation
in TileDesigner! However statistically unlikely it may be, the only
correct one (except the obvious tile #63) was tile #67!

I have made a new version of the TileDesigner database, which I will
send to Brett for conversion to .gif files. I have also doubled the sizes
of the tile numbers and revenue indicators, hoping that these would get a
bit
closer to being readable. I will change the XML accordingly. 

As said, only 1830 has been done so far. Tile #45 exists in two versions
in this game, I gave chosen one of these as the standard one, 
in line with the choice made in the PS18XX 1830 tile set.

In other games, tiles have been printed in different orientations
(i.e. with the tile number in a different position w.r.t the track).
So we'll have to make the unrotated tile position game-dependent
(it's a pity we can't move the tile number to different positions).

The base rotation per game will be defined in TileSet.xml, 
I think by a <Tile> attribute like  baseRotation="5" 
(the number 5 would apply to e.g. tile 7 in 1856).

The purpose if this all is to keep the orientation indications of laid
tiles,
as printed in the OR and Log screens, in line with those used by PBEM
players.

Erik.

RE: [Rails-devel] RE: Token laying

[Erik V. <eri...@hc...>]

> Wow.  Now I can see why you got lost.   You've nested the 
> token laying calls quite deeply.  I think much of this could 
> be simplified, but for now it works with the one-line change 
> I've committed.
> 
> In PublicCompany.layBaseToken() you were adding the token to 
> the company, but weren't adding the token to the hex. After 
> including a call to hex.addToken(), the token is being drawn 
> on the map.

But still only the very first laid non-home token of any company is shown!
(I have not mentioned this before, but this was also the case
with your original token laying code). 
BTW the station number in the call you added was 1 but should
have been 0: I got an exception. 

And the token is still only drawn after "Done" has been pressed.
My idea was to draw the token as soon as the hex was clicked
in token laying mode. This would show a "provisional token",
just as with tile laying, to be replaced with a permanent token
when Done is pressed. 
 
> Now we just need to add in the logic for selecting the 
> station for hexes with multiple stations.

I think I will start with:
- implementing the keep-existing-track rule for tile laying;
this will require me to get deeper into track and station handling;
- fixing the tile orientations as displayed in the OR window. 

From there I think linking in the station selection for token laying will be
easier.

Erik.

RE: [Rails-devel] RE: Token laying

[Brett L. <wak...@ea...>]

>> 3. For the token drawing... is it deliberate that it's not 
>> currently being drawn, or is it a bug (and should I look into 
>> fixing the bug)?
>
>The problem is in the Token laying code, which requires the token
>to be known by the Model before it can be shown. This is unlike tiles,
>which are only reported as being laid to the Model when "Done" is pressed.
>
>The idea is that the token should already be drawn if GUIHex or GUITile
>knows about it
>as a "provisionalGUIToken", similar to the existing "provisionalGUITile".
>I was intending to handle tokens similarly, but to enable that token laying
>(positioning) and token drawing should be decoupled.
>
>Trying to fix this, I got lost in all kinds of changes all over
>the place, and finally reverted everything for a fresh start.
>
>Among the things I was working on are:
>
>- Unless absolutely needed, I would have left the stock chart tokens
>out of the TokenHolder implementors (the stock chart token is a totally
>different thing, only its physical representation is identical for
>practical reasons). I think the Stock Chart was perfect as it was.
>
>- I was creating a new model-side BaseToken object, linked to both a company
>and (optionally) a station (the exiting Token would be renamed to GUIToken).
>This would make it easier to enumerate and manage laid and unlaid tokens 
>(in some games tokens can come back to the company).
>
>(Talking about enumeration, we don't count laid tiles yet against
>the maximum available number. I think I'll do that first now 
>for better inspiration on how to manage the tokens).
>
>- I'm am not sure if we should really use the rather fluid existing Station
>object (per tile) to hold tokens, rather than a new Station-like object that
>
>is persistent, and would because of that better be suited to act as a node
>in the Route network that we will have to build one day.
>Tile-linked station objects come and go as tiles are laid and upgraded.
>I think we need a more persistent kind of object.
>
>But I found that all these things need more thought (and I got lost, as I
>said).



Wow.  Now I can see why you got lost.   You've nested the token laying calls quite deeply.  I think much of this could be simplified, but for now it works with the one-line change I've committed.

In PublicCompany.layBaseToken() you were adding the token to the company, but weren't adding the token to the hex. After including a call to hex.addToken(), the token is being drawn on the map.

Now we just need to add in the logic for selecting the station for hexes with multiple stations.

---Brett.

[Rails-devel] More tile laying restrictions observed

[Erik V. <eri...@hc...>]

I have committed code to implement tile laying restrictions caused by:

1. The quantity of available tiles,
2. Hexes blocked by unsold privates.

The config for the hex blocking has been moved
from Map.xml to CompanyManager.xml, because the latter
is parsed after the former.

Erik.

RE: [Rails-devel] RE: Token laying

[Brett L. <wak...@ea...>]

>(We should refine click spot detection to identify the city (station)
>on which a token is laid on multi-station tiles. I have added codes named
>"position" to Tiles.xml, which encode the city position on the tile,
>as these were defined by Marco. These position codes should enable
>finding the city clicked upon, and also mark the place to lay a token.
>I can explain the encoding if you're interested.


Sure, I'm interested.  It may make drawing tokens simpler if we have some positional information we can reference.


>Among the things I was working on are:
>
>- Unless absolutely needed, I would have left the stock chart tokens
>out of the TokenHolder implementors (the stock chart token is a totally
>different thing, only its physical representation is identical for
>practical reasons). I think the Stock Chart was perfect as it was.


The reason I made StockSpace a TokenHolder is because there was literally *nothing* to change. It already was a good example of a TokenHolder.


>- I was creating a new model-side BaseToken object, linked to both a company
>and (optionally) a station (the exiting Token would be renamed to GUIToken).
>This would make it easier to enumerate and manage laid and unlaid tokens 
>(in some games tokens can come back to the company).


I'm not completely convinced this is necessary, but I can see how it might make things less obtuse.  Thinking of company references as tokens takes a bit of a mental leap.


>(Talking about enumeration, we don't count laid tiles yet against
>the maximum available number. I think I'll do that first now 
>for better inspiration on how to manage the tokens).
>
>- I'm am not sure if we should really use the rather fluid existing Station
>object (per tile) to hold tokens, rather than a new Station-like object that
>is persistent, and would because of that better be suited to act as a node
>in the Route network that we will have to build one day.
>Tile-linked station objects come and go as tiles are laid and upgraded.
>I think we need a more persistent kind of object.


This is why we currently copy the tile-side Station object  over to the hex-side Station object if there are differences between the new Tile's stations and the current Hex's stations.

I don't like this, so if there's a better way to manage the changes to number of stations and number of tokens a station will hold, I'm all for it.


>
>But I found that all these things need more thought (and I got lost, as I
>said).


No worries.  Things are getting a wee bit complicated. I don't expect us to get it perfect on the first attempt. ;-)


>> 4. For revenue counting, the red, off-map routes have an 
>> offMapValue of -1, which makes it difficult to calculate 
>> route revenue.
>
>This is only a marker for "not yet assigned".
>The idea is to assign the values dynamically per phase,
>and to define these in TileSet.xml, so that we would not need
>to create new off-map tiles for each new set of values.
>But all this has not yet been implemented (another bullet on your list!).


Alrighty. Not a huge rush for this. There's bigger stuff to work on, first.


>> Erik - Is there any of this I should work on, or any specific 
>> items I should leave to you?
>
>Perhaps you could look again at token drawing, as I discussed
>under point 3?


Absolutely.  I ought to have some time to work on this over the holiday.



---Brett.

RE: [Rails-devel] RE: Token laying

[Erik V. <eri...@hc...>]

> 1. The token laying UI isn't very intuitive.  If I don't want 
> to lay a token, I must press the button labeled "cancel". 
> Perhaps the button should say "Skip Phase" or "No Token" or 
> something else to indicate that token laying isn't mandatory. 
> "Cancel"  just doesn't convey quite the right message, in my mind.
> 
> We should also do this for tile laying, which has a similar 
> issue of needing to click 'cancel' if the user doesn't want 
> to play a tile.

Yes, that sounds better.
 
> Where we SHOULD have a cancel button is to be able to take 
> back the last action. However, I don't want to look at an 
> 'undo' functionality just yet.
> 
> 
> 2. When I click on a hex to select where to lay a token, the 
> hex isn't being highlighted. We should be highlighting the 
> hex when a user clicks on it.

Not needed IMO, because when a tile is clicked, the token can be shown
immediately (see next point); there is no need to wait for the user
to perform an additional action on that tile.

(We should refine click spot detection to identify the city (station)
on which a token is laid on multi-station tiles. I have added codes named
"position" to Tiles.xml, which encode the city position on the tile,
as these were defined by Marco. These position codes should enable
finding the city clicked upon, and also mark the place to lay a token.
I can explain the encoding if you're interested.

> 3. For the token drawing... is it deliberate that it's not 
> currently being drawn, or is it a bug (and should I look into 
> fixing the bug)?

The problem is in the Token laying code, which requires the token
to be known by the Model before it can be shown. This is unlike tiles,
which are only reported as being laid to the Model when "Done" is pressed.

The idea is that the token should already be drawn if GUIHex or GUITile
knows about it
as a "provisionalGUIToken", similar to the existing "provisionalGUITile".
I was intending to handle tokens similarly, but to enable that token laying
(positioning) and token drawing should be decoupled.

Trying to fix this, I got lost in all kinds of changes all over
the place, and finally reverted everything for a fresh start.

Among the things I was working on are:

- Unless absolutely needed, I would have left the stock chart tokens
out of the TokenHolder implementors (the stock chart token is a totally
different thing, only its physical representation is identical for
practical reasons). I think the Stock Chart was perfect as it was.

- I was creating a new model-side BaseToken object, linked to both a company
and (optionally) a station (the exiting Token would be renamed to GUIToken).
This would make it easier to enumerate and manage laid and unlaid tokens 
(in some games tokens can come back to the company).

(Talking about enumeration, we don't count laid tiles yet against
the maximum available number. I think I'll do that first now 
for better inspiration on how to manage the tokens).

- I'm am not sure if we should really use the rather fluid existing Station
object (per tile) to hold tokens, rather than a new Station-like object that

is persistent, and would because of that better be suited to act as a node
in the Route network that we will have to build one day.
Tile-linked station objects come and go as tiles are laid and upgraded.
I think we need a more persistent kind of object.

But I found that all these things need more thought (and I got lost, as I
said).

> 4. For revenue counting, the red, off-map routes have an 
> offMapValue of -1, which makes it difficult to calculate 
> route revenue.

This is only a marker for "not yet assigned".
The idea is to assign the values dynamically per phase,
and to define these in TileSet.xml, so that we would not need
to create new off-map tiles for each new set of values.
But all this has not yet been implemented (another bullet on your list!).

> 5. Lastly, it's still possible for any player to close any 
> private company, even companies they don't own.

This is only a stop-gap to enable closure of privates of which
the special property has not yet been implemented. This button
will disappear when we are done!
 
> Erik - Is there any of this I should work on, or any specific 
> items I should leave to you?

Perhaps you could look again at token drawing, as I discussed
under point 3?
 
> An additional point to think about:
> 
> One thing I noticed in the Colossus code is that there is 
> copious use of AbstractActions (javax.swing.AbstractAction).  
> These seemed to be a good way of bridging the gap between the 
> UI and the Model. The UI buttons were hooked up to call the 
> AbstractAction, and then within the AbstractAction was the 
> code for executing that game phase.
> 
> As our UI code gets more and more complex, perhaps this might 
> be a good way of organizing and simplifying it.

I'll have a look at it.

Erik.

Re: [Rails-devel] RE: Token laying

[Brett L. <wak...@ea...>]

I've finally had a chance to look at this batch of updates. (It's been a busy week.)

Some comments:

1. The token laying UI isn't very intuitive.  If I don't want to lay a token, I must press the button labeled "cancel". Perhaps the button should say "Skip Phase" or "No Token" or something else to indicate that token laying isn't mandatory. "Cancel"  just doesn't convey quite the right message, in my mind.

We should also do this for tile laying, which has a similar issue of needing to click 'cancel' if the user doesn't want to play a tile.

Where we SHOULD have a cancel button is to be able to take back the last action. However, I don't want to look at an 'undo' functionality just yet.


2. When I click on a hex to select where to lay a token, the hex isn't being highlighted. We should be highlighting the hex when a user clicks on it.

3. For the token drawing... is it deliberate that it's not currently being drawn, or is it a bug (and should I look into fixing the bug)?

4. For revenue counting, the red, off-map routes have an offMapValue of -1, which makes it difficult to calculate route revenue.

5. Lastly, it's still possible for any player to close any private company, even companies they don't own.


Erik - Is there any of this I should work on, or any specific items I should leave to you?


An additional point to think about:

One thing I noticed in the Colossus code is that there is copious use of AbstractActions (javax.swing.AbstractAction).  These seemed to be a good way of bridging the gap between the UI and the Model. The UI buttons were hooked up to call the AbstractAction, and then within the AbstractAction was the code for executing that game phase.

As our UI code gets more and more complex, perhaps this might be a good way of organizing and simplifying it.


---Brett.



-----Original Message-----
>From: Erik Vos <eri...@hc...>
>Sent: Dec 17, 2005 3:51 PM
>To: rai...@li...
>Subject: [Rails-devel] RE: Token laying
>
>Now fixed. No tokens drawn yet.
>
>I have also done the easy points 2 and 3 on Brett's backlog list:
>phase restrictions on tile laying and private buying.
>
>Erik.
>
>> -----Original Message-----
>> From: Erik Vos [mailto:eri...@hc...] 
>> Sent: 17 December 2005 00:12
>> To: rai...@li...
>> Subject: Token laying
>> 
>> I have committed code to integrate token laying.
>> Most of it is done, except the token drawing.
>> The first token laid is correctly priced.
>> 
>> I'm now getting stuck on the second operating company;
>> I expect that I can sort that out tomorrow. 
>> It must be a minor problem.
>> 
>> Erik.
>> 
>> 

Re: [Rails-devel] RE: Token laying

[Brett L. <wak...@ea...>]

Yay!

---Brett.

-----Original Message-----
>From: Erik Vos <eri...@hc...>
>Sent: Dec 17, 2005 3:51 PM
>To: rai...@li...
>Subject: [Rails-devel] RE: Token laying
>
>Now fixed. No tokens drawn yet.
>
>I have also done the easy points 2 and 3 on Brett's backlog list:
>phase restrictions on tile laying and private buying.
>
>Erik.
>
>> -----Original Message-----
>> From: Erik Vos [mailto:eri...@hc...] 
>> Sent: 17 December 2005 00:12
>> To: rai...@li...
>> Subject: Token laying
>> 
>> I have committed code to integrate token laying.
>> Most of it is done, except the token drawing.
>> The first token laid is correctly priced.
>> 
>> I'm now getting stuck on the second operating company;
>> I expect that I can sort that out tomorrow. 
>> It must be a minor problem.
>> 
>> Erik.
>> 
>> 
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Rails-devel mailing list
>Rai...@li...
>https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] RE: Token laying

[Erik V. <eri...@hc...>]

Now fixed. No tokens drawn yet.

I have also done the easy points 2 and 3 on Brett's backlog list:
phase restrictions on tile laying and private buying.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@hc...] 
> Sent: 17 December 2005 00:12
> To: rai...@li...
> Subject: Token laying
> 
> I have committed code to integrate token laying.
> Most of it is done, except the token drawing.
> The first token laid is correctly priced.
> 
> I'm now getting stuck on the second operating company;
> I expect that I can sort that out tomorrow. 
> It must be a minor problem.
> 
> Erik.
> 
> 

RE: [Rails-devel] Stepping back and taking inventory

[Erik V. <eri...@hc...>]

A few more items to do:

- Emergency money raising
- Bankruptcy
- Normal game end 

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of Erik Vos
> Sent: 14 December 2005 20:08
> To: rai...@li...
> Subject: RE: [Rails-devel] Stepping back and taking inventory
> 
> > I just wanted to take a moment to step back from the code and 
> > take stock of where the whole application is at and see what 
> > we've got left to do before 1830 is "working" well enough to 
> > release for wider public consumption.
> > 
> > Here's the things that I can see are left to do:
> > 
> > 1. Fix tile rotation bug.  Hex F20 (the double town north of 
> > NYC) doesn't allow all legal tile rotations.
> 
> Which tile does that apply to? I can't find any misfits here.
> 
>  2. Add tile upgrade restrictions. Currently there's nothing 
> > stopping upgrading to green tiles before the first 3-train 
> > has been purchased.
> > 3. Add private purchasing limits.  Similar to #2, there's 
> > nothing stopping purchasing of privates before the first 
> > 3-train has been purchased.
> > 4. Finish off the token playing UI. As we've discussed over 
> > the last day or two.
> > 5. Finish token drawing code. Relies on #4. We currently only 
> > handle single tokens in a hex.
> > 6. Add token blocking. We're not currently checking for space 
> > in a station before playing a token.
> > 
> > I'm not sure what the status of the private company's special 
> > abilities are, so that's a possible #7.
> 
> This is done, except for the special token lays and the M&H/NYC swap.
> 
> > Right now route counting requires looking at the tooltips of 
> > each hex to see the city's value. While cumbersome, it's not 
> > something that needs fixing just yet.
> 
> Restricting tile lays to extend existing routes also depends on that.
> However, I could pretty easily add a restriction that a new 
> tile should
> connect to some existing track, except on a home base.
> 
> Route determination is the biggest issue still left. Next year!
> 
> Erik.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep 
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>