rails-devel — List for discussion of Rails development

[Rails-devel] Bug report: Tiles are now shown (was: Rails version 1.0.1 released)

[Akiyoshi N. <aki...@ni...>]

Hello, 

This is a bug report for Rails 1.01.  Rails 1.00 does not have 
this bug.  

In Map winodw, tiles are not shown when I click a hex.  

Akiyoshi NOMURA
  mailto:aki...@ni...

[Rails-devel] Rails version 1.0.1 released

[brett l. <wak...@gm...>]

Version 1.0.1 is out on the SF.net site, ready for consumption.

Key changes in this release:

* Fixed several UI issues with the map window.
* Added a scroll bar to the list of tile upgrades.
* Added some clarity to displaying the president of a company
* Added fields to the Game Status window to show the certificate
limits and player's total number of certificates.
* Added 18Kaas to the list of games. 18Kaas should be fully playable;
it's 1830 on a different map.


You can download the latest version at:
http://sourceforge.net/project/showfiles.php?group_id=132173

The main project site is at:
http://sourceforge.net/projects/rails/



Found a bug? Have a feature you'd like to see added?
You can submit a bug report or feature request by clicking the Bugs or
Feature Requests links on the project website. If you have a
Sourceforge.net account, you will receive e-mail notifications when
your bug or feature request is fixed.


---Brett.

Re: [Rails-devel] Route and revenue calculation.

[brett l. <wak...@gm...>]

On 7/10/06, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
>
> >You don't need a list. All you need is the logic for determining
> >whether a route is legal or not. i.e. Contiguous track segements,
> >passing through at least one city with the owner's token, not passing
> >through blocked cities, not going red-to-red, etc.
> >
> >Instead of generating the list of all legal routes, you simply apply
> >the single route given by the user to the set of rules used for
> >determining the validity of the route. If valid, we return the value
> >of the route and move onward.
> >
> >
> I still think the "test" portion of the "generate and test" is the
> complicated part, and little is saved but much lost by leaving out the
> route computation.  Aside from that, giving feedback to the user will
> require more work, as you have to figure out which hexes might be legal
> to add to what he has clicked already.  I don't see this being
> sufficient (if any) savings in effort versus just doing it right in the
> first place.
>
>

Fair enough.   You're probably a better judge of the amount of work involved.


---Brett.

Re: [Rails-devel] Route and revenue calculation.

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

brett lentz wrote:

>You don't need a list. All you need is the logic for determining
>whether a route is legal or not. i.e. Contiguous track segements,
>passing through at least one city with the owner's token, not passing
>through blocked cities, not going red-to-red, etc.
>
>Instead of generating the list of all legal routes, you simply apply
>the single route given by the user to the set of rules used for
>determining the validity of the route. If valid, we return the value
>of the route and move onward.
>  
>
I still think the "test" portion of the "generate and test" is the 
complicated part, and little is saved but much lost by leaving out the 
route computation.  Aside from that, giving feedback to the user will 
require more work, as you have to figure out which hexes might be legal 
to add to what he has clicked already.  I don't see this being 
sufficient (if any) savings in effort versus just doing it right in the 
first place.

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

Re: [Rails-devel] Route and revenue calculation.

[brett l. <wak...@gm...>]

On 7/10/06, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
>
> >The distinction I'm making is that, for #1, we don't have to do any of
> >the multiple walks across the connectivity graph or route comparison
> >that we'd have to do with #2.
> >
> >
> Then how would it come up with the list of legal routes?
>

You don't need a list. All you need is the logic for determining
whether a route is legal or not. i.e. Contiguous track segements,
passing through at least one city with the owner's token, not passing
through blocked cities, not going red-to-red, etc.

Instead of generating the list of all legal routes, you simply apply
the single route given by the user to the set of rules used for
determining the validity of the route. If valid, we return the value
of the route and move onward.


> >So, instead of incurring the costs associated with finding the best
> >route, we make the assumption that the user will find it for us. All
> >we have to do is validate that the user is providing us with a legal
> >route.
> >
> >
> Aside from the recent suggestion which I haven't had a chance to
> analyze, these algorithms all generate all possible legal routes and
> simply choose the maximum valued one.  So, the only possible savings
> would be not counting the value of the cities, but I don't think that
> saves much.
>

See above.   We skip generating a list of all legal routes, and focus
on evaluating the correctness of a single route.

> >The UI code will need to be generated anyway, because we're going to
> >need to show the user the route we're selecting. This is just the
> >difference between programmatically selecting hexes and acting on the
> >user's selection of hexes.
> >
> >
> So the user would have to click on hexes they want to use?  How would
> you handle other things like which city circle to use if the next hop in
> the route being built could be either, or whether to pick up something
> for treasury money or for dividends?  It seems the most straightforward
> approach would be a listbox of legal routes, sorted by total value.  For
> games that require a maximal run, it could restrict the list, and games
> which have no other side effects and require a maximal run it shouldn't
> show the dialog at all.
>

Yes, the user would click on the hexes they want to use.

If we have the data available, we can also allow the user to click
specific city circles that his train hits. At the very least, after
the user has selected all of the hexes involved in the route, if
there's still ambiguity, we can pop up a dialog box and get the
information we need to resolve the ambiguity.

Picking up cargo can be handled after route legality is verified. It
has no bearing on deciding if a route is valid for a particular train.


---Brett.

Re: [Rails-devel] Route and revenue calculation.

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

Erik Vos wrote:

>My approach would be: always show the (or a) maximum value route.
>In addition, only in games where the user can make a choice, 
>show a listbox or enable a menu option to let him make the choice 
>in some way or another.
>  
>
I think in the cases where the user has a choice and it matters, it 
should pop up automatically, perhaps with a default highlighted.  But we 
can cross that bridge when we get there, as it will be a long time 
before 1860 or 1844 are implemented.

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

Re: [Rails-devel] Route and revenue calculation.

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

> >The UI code will need to be generated anyway, because we're going to
> >need to show the user the route we're selecting. This is just the
> >difference between programmatically selecting hexes and acting on the
> >user's selection of hexes.
> >  
> >
> So the user would have to click on hexes they want to use?  How would 
> you handle other things like which city circle to use if the 
> next hop in 
> the route being built could be either, or whether to pick up 
> something 
> for treasury money or for dividends?  It seems the most 
> straightforward 
> approach would be a listbox of legal routes, sorted by total 
> value.  For 
> games that require a maximal run, it could restrict the list, 
> and games 
> which have no other side effects and require a maximal run it 
> shouldn't 
> show the dialog at all.

My approach would be: always show the (or a) maximum value route.
In addition, only in games where the user can make a choice, 
show a listbox or enable a menu option to let him make the choice 
in some way or another.

As regards multi-city tiles: we can easily determine which city 
is closest to the click spot (measured from the city center).
(We will also need such a city selection mechanism for laying tokens 
on multi-city tiles.)
But if we have calculated routes beforehand, a listbox looks
a lot easier to implement indeed.

Erik.

Re: [Rails-devel] Route and revenue calculation.

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

brett lentz wrote:

>The distinction I'm making is that, for #1, we don't have to do any of
>the multiple walks across the connectivity graph or route comparison
>that we'd have to do with #2.
>  
>
Then how would it come up with the list of legal routes?

>So, instead of incurring the costs associated with finding the best
>route, we make the assumption that the user will find it for us. All
>we have to do is validate that the user is providing us with a legal
>route.
>  
>
Aside from the recent suggestion which I haven't had a chance to 
analyze, these algorithms all generate all possible legal routes and 
simply choose the maximum valued one.  So, the only possible savings 
would be not counting the value of the cities, but I don't think that 
saves much.

>The UI code will need to be generated anyway, because we're going to
>need to show the user the route we're selecting. This is just the
>difference between programmatically selecting hexes and acting on the
>user's selection of hexes.
>  
>
So the user would have to click on hexes they want to use?  How would 
you handle other things like which city circle to use if the next hop in 
the route being built could be either, or whether to pick up something 
for treasury money or for dividends?  It seems the most straightforward 
approach would be a listbox of legal routes, sorted by total value.  For 
games that require a maximal run, it could restrict the list, and games 
which have no other side effects and require a maximal run it shouldn't 
show the dialog at all.

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

Re: [Rails-devel] Route and revenue calculation.

[brett l. <wak...@gm...>]

On 7/10/06, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
>
> >Perhaps we should approach this in two stages:
> >
> >1. Legal route calculation.   We should allow the user to select their
> >desired route, and only provide information about the legality of the
> >route. Here, we could potentially re-use our current hex-selection
> >mechanism to allow users to select the hexes involved in their desired
> >route. Then, we can do the calculations involved in finding the value
> >of the designated route.
> >
> >2. Best route calculation. As a user-configurable option, we should
> >allow toggling between user-selected routes and computer-decided
> >"best" routes. In the case where a tactical decision needs to be made,
> >we should simply offer a selection of the highest value routes in each
> >category or fall back to user-selected routing.
> >
> >I think that #1 is around 80% of the work we need to do. Once we've
> >got that done, handling #2 might have a more clear path.
> >
> >
> The difference between them is simply #1 doesn't have to choose the
> highest valued set of routes, but has to do all the UI code for
> selecting them.  If the goal is to get it working for 1830 and similar
> games, I suggest getting automatic route selection is both easiest and
> most useful.
>

The distinction I'm making is that, for #1, we don't have to do any of
the multiple walks across the connectivity graph or route comparison
that we'd have to do with #2.

So, instead of incurring the costs associated with finding the best
route, we make the assumption that the user will find it for us. All
we have to do is validate that the user is providing us with a legal
route.

The UI code will need to be generated anyway, because we're going to
need to show the user the route we're selecting. This is just the
difference between programmatically selecting hexes and acting on the
user's selection of hexes.

---Brett.

Re: [Rails-devel] Route and revenue calculation.

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

brett lentz wrote:

>Perhaps we should approach this in two stages:
>
>1. Legal route calculation.   We should allow the user to select their
>desired route, and only provide information about the legality of the
>route. Here, we could potentially re-use our current hex-selection
>mechanism to allow users to select the hexes involved in their desired
>route. Then, we can do the calculations involved in finding the value
>of the designated route.
>
>2. Best route calculation. As a user-configurable option, we should
>allow toggling between user-selected routes and computer-decided
>"best" routes. In the case where a tactical decision needs to be made,
>we should simply offer a selection of the highest value routes in each
>category or fall back to user-selected routing.
>
>I think that #1 is around 80% of the work we need to do. Once we've
>got that done, handling #2 might have a more clear path.
>  
>
The difference between them is simply #1 doesn't have to choose the 
highest valued set of routes, but has to do all the UI code for 
selecting them.  If the goal is to get it working for 1830 and similar 
games, I suggest getting automatic route selection is both easiest and 
most useful.

The complication comes in other games where the president is not 
required to take the highest-paying set of routes or in games like 1844 
where the choice between equal sets has other side effects, such as 
activating a tunnel or mountain, and therefore the president should be 
allowed to choose among them.

In either case, what we need is an algorithm that generates the results 
and determines the result of using that route, including the total 
earned for dividends and company treasury (1860, 1895, 1824, and 1837 
all have the latter), as well as any side effects such as activation of 
mountains/tunnels.  The wrapper around that algorithm can initially be 
just the simply maximum for 1830 and we can get fancier later.

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

Re: [Rails-devel] Route and revenue calculation.

[brett l. <wak...@gm...>]

On 7/10/06, ia...@co... <ia...@co...> wrote:

> An interesting point to note is that the 'best' answer with split train types is not clear: consider having a train which pays some money straight to treasury and some to the 'dividend pool', and a second which pays only to the 'dividend pool'. For any given possible level of straight-to-treasury payment there will be a maximum dividend-pool payment, and vice-versa. However which combination to take is a tactical choice by the player. E.g. the treasury payment might be one of {$30, $40, $60} with concommitant dividend contributions of {$150, $120, $110}. The {$40/$120} option may be what the company director wants, and he should be allowed to select it.
>
>


Perhaps we should approach this in two stages:

1. Legal route calculation.   We should allow the user to select their
desired route, and only provide information about the legality of the
route. Here, we could potentially re-use our current hex-selection
mechanism to allow users to select the hexes involved in their desired
route. Then, we can do the calculations involved in finding the value
of the designated route.

2. Best route calculation. As a user-configurable option, we should
allow toggling between user-selected routes and computer-decided
"best" routes. In the case where a tactical decision needs to be made,
we should simply offer a selection of the highest value routes in each
category or fall back to user-selected routing.

I think that #1 is around 80% of the work we need to do. Once we've
got that done, handling #2 might have a more clear path.

---Brett.

[Rails-devel] Route and revenue calculation.

[<ia...@co...>]

Some thoughts extracted from a private email I sent:

Of course, [completing my old code to work with 1835 style n+m trains] still wouldn't allow for three types of station (e.g. coal mine, village and city in Lonny Orgler's Austrian 18xxs). Don't forget train/gauge issues. Also in 1825/1829 only 'T' trains may end a route at a small station. Austrian Goods trains also MUST have a coal mine on the route.

Jonathan Ferro's idea looks interesting too, but I really don't have the time (even for this email right now) to analyse it in detail.

An interesting point to note is that the 'best' answer with split train types is not clear: consider having a train which pays some money straight to treasury and some to the 'dividend pool', and a second which pays only to the 'dividend pool'. For any given possible level of straight-to-treasury payment there will be a maximum dividend-pool payment, and vice-versa. However which combination to take is a tactical choice by the player. E.g. the treasury payment might be one of {$30, $40, $60} with concommitant dividend contributions of {$150, $120, $110}. The {$40/$120} option may be what the company director wants, and he should be allowed to select it.

Re: [Rails-devel] More fixes around tile laying

[brett l. <wak...@gm...>]

On 7/9/06, Erik Vos <eri...@hc...> wrote:
> > 1517705 (reported by Akiyoshi Nomura):
> > If a tile cannot be laid because of lack of money,
> > the tile is still shown on the screen after the error message.
> >
> > Fixed by having the game engine check for valid tile laying
> > in a somewhat earlier stage. This has affected the distribution
> > of work between GUIHex and ORPanel.
>
> The same problem turned out to exist after rejection of
> a Token lay (for instance, for lack of money).
> I fixed this as well.
>
> However, both fixes turned out to have the side effect,
> that the Cancel (No Tile/No Token) button was left disabled.
>
> After this was repaired, I also found an easy fix for
> the disappearance of the upgrade tiles after rotation
> (the fix was simply to skip redrawing the UpgradesPanel).
>
> Brett, I hope, that I'm not crossing any work you have
> been doing on this last problem...
>

It shouldn't so long as you're updating your local copy of the source
tree before making/committing any changes.

> BTW I think that UpgradesPanel is repainted too often.
> But that is not an urgent issue.
>

I agree on both points.  There is plenty of optimization that can be done.

> It seems to me that, however often we rework the whole
> tile/token laying related code, we can't get the whole
> thing transparent enough to lift any work in this area
> above the trial-and-error level. A fresh look is needed.
>

There is certainly room for improvement.

---Brett.

Re: [Rails-devel] More fixes around tile laying

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

> 1517705 (reported by Akiyoshi Nomura):
> If a tile cannot be laid because of lack of money,
> the tile is still shown on the screen after the error message.
> 
> Fixed by having the game engine check for valid tile laying 
> in a somewhat earlier stage. This has affected the distribution 
> of work between GUIHex and ORPanel.
 
The same problem turned out to exist after rejection of
a Token lay (for instance, for lack of money). 
I fixed this as well.

However, both fixes turned out to have the side effect, 
that the Cancel (No Tile/No Token) button was left disabled.

After this was repaired, I also found an easy fix for
the disappearance of the upgrade tiles after rotation
(the fix was simply to skip redrawing the UpgradesPanel).

Brett, I hope, that I'm not crossing any work you have 
been doing on this last problem...

BTW I think that UpgradesPanel is repainted too often.
But that is not an urgent issue.

It seems to me that, however often we rework the whole 
tile/token laying related code, we can't get the whole 
thing transparent enough to lift any work in this area
above the trial-and-error level. A fresh look is needed.

Erik.

Re: [Rails-devel] Fixes

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

> brett lentz wrote:
> > In this situation, my understanding of the rules is that you can't
> > sell the presidency,
> 
> It is controversial whether the president can sell one of his 
> two shares
> (since it's not a separate certificate), but most people play 
> that he can
> (provided that either the bank pool or the new president holds a 10%
> certificate that can be given to the seller as "change").
> 
> In 1835, this sale would definitely be illegal because 1835's rules
> explicitly say that you buy and sell whole certificates, not shares.
> I've played in groups that apply the same rule to 1830 and 
> other games.

Never heard that this is controversial. The 1835 rules (2nd English
edition) are particularly clear about it (IV.3, and Rule XV.7
says "Only shares may be sold"). Of course, another player must have 
enough shares to exchange for the President's share (usually 20%).

Erik.

Re: [Rails-devel] Fixes

[John D. G. <jd...@di...>]

> Erik Vos wrote:
>> I have (hopefully) fixed the reported (and some more) bugs
>> regarding share buying/selling and certificate counting.
>>
>> This includes a problem I found, that if 3 players have
>> each 20% of a company, with 40% in the Pool, the
>> presidency could not be sold.

brett lentz wrote:
> In this situation, my understanding of the rules is that you can't
> sell the presidency,

It is controversial whether the president can sell one of his two shares
(since it's not a separate certificate), but most people play that he can
(provided that either the bank pool or the new president holds a 10%
certificate that can be given to the seller as "change").

In 1835, this sale would definitely be illegal because 1835's rules
explicitly say that you buy and sell whole certificates, not shares.
I've played in groups that apply the same rule to 1830 and other games.

[Rails-devel] More fixes around tile laying

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

I have fixed two bugs:

1517725 (reported by Bill Skulley):
Quantity of double-dot yellow tiles is not observed.

This was in fact an error in TileSet.xml: at some point
in time I had replaced the keyword "amount" by "quantity"
in this XML file, but apparently not everywhere.

1517705 (reported by Akiyoshi Nomura):
If a tile cannot be laid because of lack of money,
the tile is still shown on the screen after the error message.

Fixed by having the game engine check for valid tile laying 
in a somewhat earlier stage. This has affected the distribution 
of work between GUIHex and ORPanel.

NOTE: This check will become redundant (but not be removed!)
once we have a mechanism to select valid tile laying locations beforehand; 
this selection should take available money into account.

Erik 

Re: [Rails-devel] Tile Database API & route calculation

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

Erik Vos wrote:

>>Yes, but how does that change my suggestion to calculate them 
>>based on 
>>the drawing of the tile rather than to store them in the XML and then 
>>have to back-calculate the center point of the city structure for 
>>drawing the tile? 
>>    
>>
>I agree with your suggestion, which I had not noticed before.
>(A few posts ago I asked whether you intended to calculate 
>slot spots bases on city drawing, and I didn't notice a clear
>answer to that. Apologies if I missed it.)
>I never intended to suggest back-calculation. 
>  
>
Also, the drawing of tokens (as opposed to hit detection) could be done 
by the tile object as well (indeed the home token locations are done as 
annotations in the token slots already), taking advantage of the minimum 
size checking code to be built in -- ie, if the scale is small enough, 
just use a colored circle rather than the actual token herald.

>I was not talking about the tiles database (now Tiles.xml), 
>but about the amount of tiles per game and the location 
>of the preprinted tiles on the map, all of which are now in
>TileSet.xml, together with the upgrade rules and any per-hex
>tile laying restictions.
>
>I made that distinction on purpose: Tiles.xml is generic
>(although there is now a subset per game, but that subset is 
>not essential indeed, only a speed-up),
>and TileSet.xml has anything that is game-specific regarding the
>usage of the tiles.
>I hope you don't intend to mix up that distinction.
>  
>
No, just as in my database I have a tiles table (and various join 
tables) containing the actaul tiles, and game_tiles (and others) which 
contain the information about the set of tiles in a given game.  
However, collectively I am calling all of these the tile database as 
these tables all contain information about tiles.

>(BTW, I generate the per-game Tiles.xml from the generic Tiles.xml
>and the per-game TileSet.xml, this is done by the stand-alone
>class util.MakeGameTileSets.
>No manual work except running this class!).
>  
>
Ok, that is what I was arguing for -- there is only one authoritative 
list and the others are all generated on demand (preferably with make if 
the master changes rather than having to manually run it), and the 
generated file is never edited.

>In general I agree, but in this case the saving of code by 
>not having to sort out all the default upgrades and then apply
>any exceptions IMO far outweighs the extra effort to specify all
>upgrades beforehand. I'm not going to write *that* code!
>In other words, feel free to add categories but I won't use these.
>
>However, a stand-alone program to fill up a skeleton TileSet.xml with 
>the default upgrade rules, which then can be edited manually
>would be very nice as a contribution from your side!
>Or perhaps a program to expand a TileSet with inclusion
>and exclusion upgrade rules to one that fully specifies all allowed 
>upgrades. But I can live without any of these.
>  
>
As Dave Mitton pointed out, finding legal upgrades is actually quite 
simple if you have keep the connectivity bitvectors per tile -- you can 
even get the various orientations of legal upgrades for free as well.  
You just take a candidate upgrade, rotate it through all six 
orientations, and any that have all the bits set that were set in the 
original are a legal upgrade.

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

Re: [Rails-devel] Tile Database API & route calculation

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

> >>The tile code draws the entire city structure as one, and 
> >>only needs the 
> >>center point and orientation of the city structure.  For hit 
> >>detection, 
> >>I suggest that simply saving the calculated position is better than 
> >>trying to store that in the XML data, espeially since zooming and 
> >>panning is going to change where it is drawn.
> >>    
> >>
> >Yes, but to drop tokens we need the slot center locations 
> rather than the
> >city location. 
> >  
> >
> Yes, but how does that change my suggestion to calculate them 
> based on 
> the drawing of the tile rather than to store them in the XML and then 
> have to back-calculate the center point of the city structure for 
> drawing the tile? 

I agree with your suggestion, which I had not noticed before.
(A few posts ago I asked whether you intended to calculate 
slot spots bases on city drawing, and I didn't notice a clear
answer to that. Apologies if I missed it.)
I never intended to suggest back-calculation.
 
> >That will work in many cases, but by far not all 
> >(for instance the Y hexes in 18Scan, to name just one example).
> >The subject of having/not having default upgrade rules has been
> >discussed in 18xx-softdev a few years ago, and the conclusion then
> >was, that it would be best to specify all upgrades explicitly.
> >At that time I was the main dissenter, but I have converted 
> myself since.
> >Hence: the TileSet.xml files now specify all allowed upgrades.
> >I would prefer to keep it that way.
> >  
> >
> If you don't want to use the data, that is fine, but I really think 
> there should be one authoritive database (replicated of 
> course) for all 
> the tiles in the 18xx world.  Otherwise, we wind up with 
> problems like 
> the way things are today, where different games reuse tile numbers or 
> draw the same tiles differently.  As such, since my tile database and 
> John Galt's and others all have the category data, I think it 
> should be 
> included.  Ideally, I would like to be able to generate the XML for a 
> given game from an authoritive tile database.  Also ideally, the XML 
> version of the tile database would be useful for multiple software 
> packages (moderators, tile generation programs, PBeM map generators, 
> etc) to avoid further duplication.

I was not talking about the tiles database (now Tiles.xml), 
but about the amount of tiles per game and the location 
of the preprinted tiles on the map, all of which are now in
TileSet.xml, together with the upgrade rules and any per-hex
tile laying restictions.

I made that distinction on purpose: Tiles.xml is generic
(although there is now a subset per game, but that subset is 
not essential indeed, only a speed-up),
and TileSet.xml has anything that is game-specific regarding the
usage of the tiles.
I hope you don't intend to mix up that distinction.

(BTW, I generate the per-game Tiles.xml from the generic Tiles.xml
and the per-game TileSet.xml, this is done by the stand-alone
class util.MakeGameTileSets.
No manual work except running this class!).

> I find it useful to have default behavior even if it doesn't 
> cover all 
> cases -- in the exceptions, you can override the default 
> behavior as needed.

In general I agree, but in this case the saving of code by 
not having to sort out all the default upgrades and then apply
any exceptions IMO far outweighs the extra effort to specify all
upgrades beforehand. I'm not going to write *that* code!
In other words, feel free to add categories but I won't use these.

However, a stand-alone program to fill up a skeleton TileSet.xml with 
the default upgrade rules, which then can be edited manually
would be very nice as a contribution from your side!
Or perhaps a program to expand a TileSet with inclusion
and exclusion upgrade rules to one that fully specifies all allowed 
upgrades. But I can live without any of these.

Erik.
 

Re: [Rails-devel] Tile Database API & route calculation

[Dave M. <da...@mi...>]

A couple more comments on my implementation...

On 7/7/2006 11:47 PM, Dave Mitton wrote:
>On 7/7/2006 12:17 AM, John A. Tamplin wrote:
> >Ok, it was more work than I thought it would be and I am not totally
> >satisfied with it yet -- feel free to suggest improvements.
> >
> >The route finding code (and other similar uses such as connectivity
> >requirement for tile and token placement) needs to know the following:
> >
> >     * which edges are connected to other edges
> >     * which junctions are connected to which edges
> >     * which junctions are connected to each other
> >     * the revenue value of each junction (possibly varying by phase)
> >     * the number of token slots for each junction (which may be zero for
> >       off-board areas or villages)
> >     * which connections interfere with which other connections (ie, only
> >       one train can be run on a given set of connections)
> >
> >The connectivity within a tile will be modelled by breaking down a
> >junction into multiple exits from it -- ie, if track from a given
> >junction going to side A and going to side B share some track and can't
> >be used together, that will be treated as one exit.  If they don't share
> >track, they will be in two different exits.  Thus, we have the following
> >connectivity tests:
> >
> >     * edge - edge
> >     * edge - junction/exit
> >     * junction/exit - junction/exit
>
>In my 1830 program, I just considered cities to be another "edge"
>I created a bit vector for the edges in a hex/tile
>To describe the tile, each edge had a vector of edges it was connected to.
>I didn't deal with junctions (none in 1830 tiles), but I think the
>idea is extensible.
>
>
> >Based on where the tiles are placed an in what orientation, a
> >connectivity graph of junctions to map hex edges can be kept up to
> >date.  Each company will also have a list of junctions where there
> >tokens are located, and a connectivity graph of other junctions
> >reachable from each of those.  When a new tile or the company's own
> >token is placed, additional edges will get added to the connectivity
> >graph (and nodes as well if new junctions are added on new tiles).  When
> >a foreign token is placed, edges may get removed if a city is full of
> >tokens.
>
>Will need a token container somewhere.
>
>
> >Tile placement for a company will find the union of reachable map hex
> >edges from all of the company's tokens and highlight possible tile
> >locations.  When one is selected, the possible tiles that connect to one
> >of the reachable edges on that hex and which can be oriented such that
> >they don't connect to a blocked hex edge (the blocked edge list will be
> >created when the map is created, and not updated afterwards) will be
> >shown as options, and only rotations which meet these criteria will be
> >shown in the cycle of rotations.
>
>Right, so for this application it's not necessary to build a "tree" 
>or "graph".
>For tile placement, you need a bool IsEdgeConnected(loc,edge) function.

Actually, having an array of edge connectivity vectors per hex (a bit 
matrix) led to some interesting capabilities.
To match a tile to the map, you do an matrix rotation on the array.
When rotated, a canidate tile must preserve the existing 
connectivity, so the new tile's bit vector must be a superset of on 
the existing map hex.  AND'ing the tile's matrix against the hex, 
should yield the hex's matrix.



...
Dave. 

[Rails-devel] An all-trains-at-once approach (LONG)

[Jonathan F. <jo...@ya...>]

Here's an idea for 18xx company revenue computation that I have been
kicking around for a while, and never gotten around to trying because I
didn't ever find the time to set up test situations for it (basically
the reason I've only ever lurked on this list).  This is a cleaned-up
transcript of me describing it to the Code Review Bear.
http://sjbdeveloper.blogspot.com/2006/03/teddy-bear-code-reviews.html

Generally speaking, the idea is that instead of calculating all
possible routes for each train and then trying combinations of all the
trains until you find a set that doesn't overlap or conflict, don't
even generate conflicting routes in the first place.

Suppose that we had a data structure which composed into a single
"routing state" object: (a) a pointer to the map being used for route
segment tracing, (b) a pointer to the set of trains being run, and (c)
a route for each train that contains both the revenue points (stations,
towns, off-board, specials) and the track between them (you need this
for conflict clarification, in case there are parallel routes between
two revenue points).

Such an object could be constructed any time any part of a route
computation comes under analysis.  It is not necessary that the map
represent the current state of play, so that you can evaluate future
tile placement or theoretical runs with no enemy tokens.  It is not
necessary that the set of trains represent the actual holding of a
company, so that you can compute destination runs, "borrowed diesel"
operations, or testing for whether a company even has a legal run or
route to a tile lay.  It is not necessary that the train->route
assignment represent a "good" run, so that it can represent an
intermediate point on a search.

I propose that a fundamental operation on this object is "what are all
the possible ways that any one train can have its route extended by one
route segment?"  This operation takes into account all route segments
that are precluded due to already being obstructed by other existing
routes, being obstructed by enemy tokens, or by not being appropriate
for the type of train (narrow-gauge or off-board), and does not include
those as possible results.  It DOES include any extensions that would
not be legal as they stand (not all connected [1860], or have a route
ending in a village [1829]), because they might be extended further to
eventually come to be legal states after all, and can't be discounted.

This state object together with the operator to generate route
extensions satisfy the state space conditions for generalized search
algorithms, e.g. as shown in Russel & Norvig, 1995, pp. 72ff.

Breadth-first search would run like this:

for each possible assignment of trains to tokens {
  create a route state where each train has a 0-length "route" at its
  token and put that state on the queue;
  // Example: 3 2-trains and 3 tokens would have 27 starting states.
}

bestState = null;
while the route state queue is not empty {
  pull routeStateParent off the queue;
  routeStateChildren = routeStateParent.getRouteExtensions();

  if ( routeStateChildren.isEmpty() ) {
    // Parent can't be extended any further, due to trains being out of
    // movement points or being blocked.
    if ( routeStateParent.revenue() <= bestState.revenue() ) {
      // In some games you might want to hang on to less-than-best if
      // there are other features, like halts or exploration.
    }
    else if ( ! routeStateParent.runIsLegal() ) {
      // This is where you kick out a run for game-rule reasons.  If
the
      // reason is "all trains still have 0-length routes", then keep
      // track of the possibility that this company may not be required
      // to own trains at all.
    }
    else {
      bestState = routeStateParent;
    }
  }
  else {
    for each child {
      // It MIGHT be possible to prune here, if it's possible to figure
      // out that there's NO possible good extension of this child,
      // e.g. if a 2038 ship doesn't have enough movement left to reach
      // a base.
      enqueue the child;
    }
  }
}
return bestState;

[Note: At the point where it might be possible to prune, it also might
be possible to determine that this child is equivalent to another state
already queued.  For example, a single train going from token T1 to
token T2 is equivalent to one going the other way, so you wouldn't have
to put the second one on the queue, but actually figuring this out
might be more expensive than just living with it.]

---

I think we all understand that the best route for a long train is not
necessarily equal to the best route for a shorter train plus however
many additional revenue points it can reach, but here's a test case
that makes this really clear:

  20 ---- 20T ---- 10 ---- 10 ---- 50
           \
            \
             -- 10 ---- 10 ---- 50

(The company's only token is at station "T".)

Trains         Best Revenue
2              40
3              50
4              90 (NOT 60)
2,2            70
2,3            80
3,3            90
4,3            140 (NOT 100)
4,4            180 (NOT 150)

This is basically the reason that route-finding does not appear to have
a simple recursive/memoization/dynamic-programming solution.

---

What does this mean in terms of the hex-level API?

I think it's important to use the API to raise the focus from the
individually conflicting arcs on individual tiles to conflicts between
"route segment"s, which is the term the players (and game rule coders)
will be thinking in.  I've deliberately left the term a bit fuzzy, but
I think it should mean something like "all of the track arcs, across
arbitrary many tiles, that connect one revenue/bonus/gamestate map
feature to the next one, in any possible train route according to the
rules of this game".

For 1830-ish games, this is rather simply following the track from one
city/village to the next.

For 1860-ish games, which allow skipping of villages/halts, there are
city-to-village route segments that conflict with
city-to-city-beyond-that-village route segments along the same track.

For 1844-ish games, where some trains count hexes rather than stations,
one route segment may take more than one "point" of capacity, and that
will affect future route extension calculations for that train.

For 2038, there is a choice of making every route segment be "one
movement point" or making a route segment be "however far to the next
mine you are actually going to pick up from".  If you were going to
list every one in the entire map that might be memory-intensive, but
you probably never need to do that since the conflictsWith() check is
so simple.

It might be desirable to make it so that the decision of whether to
precompute the list of route segments every time the map changes is up
to the individual game, not baked into the core algorithm.

In any case, it is clear to me that a RouteSegment class, far from
being a burden to maintain as an "intermediate" data structure,
represents a key point of "impedance matching" to bridge overall
thinking from the hex level to the route level.

So, having thought this far, here is some more pseudocode:

getRouteExtensions()
{
  for each train in the routeState that has movement remaining {
    for each "live" end of the current train route {
      // Ends might not be live if they've gone off-board or have
      // otherwise dead-ended in this routeState, including enemy
      // tokens.  2038 ships always only have one live end.
      for each routeSegment from this endpoint {
        if (game-specific reason this train can't use this segment) {
          // This is the check for H-trains going beyond their movement
          // limit [1844], or for going to a different city on a tile
          // you've visited [1829], or for a segment that skips
villages
          // when used with a train that actually can't [1860] or
          // vice-versa [18Scan].
        }
        else if (routeSegment.conflictsWith(routeState.allSegments()))
{
          // This test is where the bitvectors John is talking about
          // could come in handy.
        }
        else {
          // Good enough to try.
          copyState = routeState.copy();
          extend this train's route in copyState by routeSegment;
          record movement usage for this train; // Might be zero.
          add copyState to resultSet;
        }
      }
    }
  }
  return resultSet;
}

Hm, after all this, I see I haven't really handled double-heading, but
I think that issue can be handled in the representation of the train
set.

It's also possible that rather than having the map and the trainSet be
in the routeState, to save time on object copying, that they would be
"global" to the entire search tree.  There would also have to be a
RouteResult object type that did contain all these details, for
representing the result of route searching to the rest of the program.

Anyway, I enjoyed thinking about this, so I hope it helps.

-- Jonathan

Re: [Rails-devel] Tile Database API & route calculation

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

Erik Vos wrote:

>>The tile code draws the entire city structure as one, and 
>>only needs the 
>>center point and orientation of the city structure.  For hit 
>>detection, 
>>I suggest that simply saving the calculated position is better than 
>>trying to store that in the XML data, espeially since zooming and 
>>panning is going to change where it is drawn.
>>    
>>
>Yes, but to drop tokens we need the slot center locations rather than the
>city location. 
>  
>
Yes, but how does that change my suggestion to calculate them based on 
the drawing of the tile rather than to store them in the XML and then 
have to back-calculate the center point of the city structure for 
drawing the tile? 

>That will work in many cases, but by far not all 
>(for instance the Y hexes in 18Scan, to name just one example).
>The subject of having/not having default upgrade rules has been
>discussed in 18xx-softdev a few years ago, and the conclusion then
>was, that it would be best to specify all upgrades explicitly.
>At that time I was the main dissenter, but I have converted myself since.
>Hence: the TileSet.xml files now specify all allowed upgrades.
>I would prefer to keep it that way.
>  
>
If you don't want to use the data, that is fine, but I really think 
there should be one authoritive database (replicated of course) for all 
the tiles in the 18xx world.  Otherwise, we wind up with problems like 
the way things are today, where different games reuse tile numbers or 
draw the same tiles differently.  As such, since my tile database and 
John Galt's and others all have the category data, I think it should be 
included.  Ideally, I would like to be able to generate the XML for a 
given game from an authoritive tile database.  Also ideally, the XML 
version of the tile database would be useful for multiple software 
packages (moderators, tile generation programs, PBeM map generators, 
etc) to avoid further duplication.

I find it useful to have default behavior even if it doesn't cover all 
cases -- in the exceptions, you can override the default behavior as needed.

>Yes, for route calculation, but does the exclude also affect drawing that
>tile?
>  
>
No, if special drawing instructuctions are required to achieve the 
desired effect rather than the default then they need to be included.

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

Re: [Rails-devel] Tile Database API & route calculation

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

> >I presume that, in case a city has more than one slot,
> >slot center locations will be calculated from
> >the Station position and the tile orientation.
> >Can't we better specify these explicitly?
> >  
> >
> The tile code draws the entire city structure as one, and 
> only needs the 
> center point and orientation of the city structure.  For hit 
> detection, 
> I suggest that simply saving the calculated position is better than 
> trying to store that in the XML data, espeially since zooming and 
> panning is going to change where it is drawn.

Yes, but to drop tokens we need the slot center locations rather than the
city location. 

> >And what is the use of "Category"? Just a simple way to 
> create annotation?
> >  
> >
> No, Category controls which tiles may be played there.  For 
> example, in 
> 1830 the B tiles may only be played in Baltimore and Boston and also 
> control upgrades.  At sufficient zoom levels, it should be 
> displayed on 
> the map as it is relevant to game play.

That will work in many cases, but by far not all 
(for instance the Y hexes in 18Scan, to name just one example).
The subject of having/not having default upgrade rules has been
discussed in 18xx-softdev a few years ago, and the conclusion then
was, that it would be best to specify all upgrades explicitly.
At that time I was the main dissenter, but I have converted myself since.
Hence: the TileSet.xml files now specify all allowed upgrades.
I would prefer to keep it that way.
 
> >Wouldn't preprinted Milano then also need drawing specifications
> >to show the tracks joining?
> >  
> >
> That is the point of the exclude list, to show that the two 
> connections 
> join before the city and therefore can't be use simultaneously.

Yes, for route calculation, but does the exclude also affect drawing that
tile?

Erik.

Re: [Rails-devel] Tile Database API & route calculation

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

Erik Vos wrote:

>Looks good to me generally.
>See some comments below.
> 
>  
>
>>Ok, after looking at Iain's code, I propose the following:
>>
>>Extend the tile XML file to show additional exclusive track 
>>use and add 
>>necessary drawing data:
>>
>><Tile id="62" colour="green" category="NY">
>>    # position/rotation can be defaulted
>>    <Station id="1" type="City" slots="2" value="80" 
>>position="90,.4" rotation="0" />
>>    <Station id="2" type="City" slots="2" value="80" 
>>position="270,.4" rotation="0" />
>>    # gauge and level are defaulted, use shorter labels for 
>>size and parsing speed
>>    <Track from="1" to="A" />
>>    <Track from="1" to="F" />
>>    <Track from="2" to "E" />
>>    <Track from="2" to "D" />
>></Tile>
>>    
>>
>
>I presume that, in case a city has more than one slot,
>slot center locations will be calculated from
>the Station position and the tile orientation.
>Can't we better specify these explicitly?
>  
>
The tile code draws the entire city structure as one, and only needs the 
center point and orientation of the city structure.  For hit detection, 
I suggest that simply saving the calculated position is better than 
trying to store that in the XML data, espeially since zooming and 
panning is going to change where it is drawn.

>><Tile id="Map-1841-Milano" colour="yellow" category="M">
>>    <Annotation text="Milano" size="12pt" position="270,.7" 
>>justify="b" rotation="0" />
>>    <Station id="1" type="City" slots="1" value="60" 
>>position="210,.6" />
>>    <Track from="1" to "A">
>>        <Excludes from="1" to "B" />
>>    </Track>
>>    <Track from="1" to "B">
>>        <Excludes from="1" to="A" />
>>    </Track>
>></Tile>
>><Tile id="23" colour="green">
>>    <Track from="A" to="D" />
>>    <Track from="D" to="B" />
>></Tile>
>><Tile id=16 colour="green">
>>    <Track from="A" to "C" level="0"/>
>>    <Track from="B" to "D" level="2"/>
>></Tile>
>><Tile id="Map-1830-Altoona" colour="fixed">
>>    <Station id="1" type="City" slots="1" value="10" 
>>reservedtoken="PRR" />
>>    <Track from="E" to="1" />
>>    <Track from="B" to="1" />
>>    <Track from="B" to="E">
>>	 <Draw from="E" to="[210,.25]" radius="-.25" />
>>	 <Draw from="[210,.25]" to="[300,.25]" radius=".25" />
>>	 <Draw from="[300,.25]" to="B" radius="-.25" />
>>    </Track>
>></Tile> 
>>    
>>
>
>This tile happens to be the only one with drawing instructions.
>I presume, that in all other cases the drawing instructions are
>derived automatically. 
>  
>
Yes, in the other cases it is trivial to draw straight lines and curved 
lines between the edges with practically no computation.  Better to 
leave that calculation to the software rather than requiring a person to 
draw it, and only providing specific drawing instrcutions.

>For instance tile #65 (OO city with a sharp and a wide bend):
>would the tracks be curved by default (as they should, IMO), 
>or are special drawing instructions needed to achieve that?
>(TileDesigner derives such things from the specified off-center city
>location).
>  
>
The way I handled that in my tile database is I generated the exact 
positions and curvatures from the TileDesigner code and stored them in 
the database, but only for those which had non-trivial drawing 
requirements.  If the city circles are positioned on the natural curves 
between edges, it should be detected as such automatically.

>>Tile code defaults to the id if it is numeric, otherwise it 
>>defaults to 
>>"", can be overriden with code="603" etc.
>>    
>>
>
>What is the purpose of the tile code?
>  
>
The tile code is the number printed on the tile.  Unfortunately, these 
are not unique as various games have duplicated

>In Tiles.xml I had made a distinction between "id" and "name",
>where id must be unique. "name" was intended to be the tile number 
>as printed on the tile (not by TileDesigner, though), 
>and is displayed on the screen and in the logs where applicable.
>  
>
TileDesigner calls what is printed on the tile the code, so it sounds 
like you just renamed it to "name".  To me, "name" would be more like 
"Milano" or "M" than the number printed on the tile.  Obviously, it is 
trivial to name it whatever you want (as many of the other terms from 
TileDesigner have been changed, such as Junction->Station, 
Level->Colour, etc).

>So the two different tiles 69 have ids 69 and 1069, but both have
>name="69". Is this perhaps what you intend to use code for?
>  
>
Yes.

>And what is the use of "Category"? Just a simple way to create annotation?
>  
>
No, Category controls which tiles may be played there.  For example, in 
1830 the B tiles may only be played in Baltimore and Boston and also 
control upgrades.  At sufficient zoom levels, it should be displayed on 
the map as it is relevant to game play.

>Wouldn't preprinted Milano then also need drawing specifications
>to show the tracks joining?
>  
>
That is the point of the exclude list, to show that the two connections 
join before the city and therefore can't be use simultaneously.

>How about scaling?
>The main problem we have with the tiles generated by TileDesigner is,
>that these do not scale down very well. 
>Revenue value and tile number get unreadable on the map.
>Do you have a fix for that?
>  
>
My perl port of TileDesigner generates Postscript code.  The proposed 
structure would have it drawing directly on a canvas, whether that is on 
the screen or a postscript output file.   My intent for handling small 
scale is to simply omit text when the scaled point size gets too small.  
In this way, the tile code and small text annotations show up 
automatically at high zoom levels, while the tile category will show up 
even to relatively low zoom levels, with the smallest drawn hexes 
showing only the background and track.  The RenderTile object that knows 
about drawing on the screen would simply compare the final point size of 
text it is to draw with a configurable cutoff and ignore the request if 
it is too small.

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

Re: [Rails-devel] Tile Database API & route calculation

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

Looks good to me generally.
See some comments below.
 
> Ok, after looking at Iain's code, I propose the following:
> 
> Extend the tile XML file to show additional exclusive track 
> use and add 
> necessary drawing data:
> 
> <Tile id="62" colour="green" category="NY">
>     # position/rotation can be defaulted
>     <Station id="1" type="City" slots="2" value="80" 
> position="90,.4" rotation="0" />
>     <Station id="2" type="City" slots="2" value="80" 
> position="270,.4" rotation="0" />
>     # gauge and level are defaulted, use shorter labels for 
> size and parsing speed
>     <Track from="1" to="A" />
>     <Track from="1" to="F" />
>     <Track from="2" to "E" />
>     <Track from="2" to "D" />
> </Tile>

I presume that, in case a city has more than one slot,
slot center locations will be calculated from
the Station position and the tile orientation.
Can't we better specify these explicitly?

> <Tile id="Map-1841-Milano" colour="yellow" category="M">
>     <Annotation text="Milano" size="12pt" position="270,.7" 
> justify="b" rotation="0" />
>     <Station id="1" type="City" slots="1" value="60" 
> position="210,.6" />
>     <Track from="1" to "A">
>         <Excludes from="1" to "B" />
>     </Track>
>     <Track from="1" to "B">
>         <Excludes from="1" to="A" />
>     </Track>
> </Tile>
> <Tile id="23" colour="green">
>     <Track from="A" to="D" />
>     <Track from="D" to="B" />
> </Tile>
> <Tile id=16 colour="green">
>     <Track from="A" to "C" level="0"/>
>     <Track from="B" to "D" level="2"/>
> </Tile>
> <Tile id="Map-1830-Altoona" colour="fixed">
>     <Station id="1" type="City" slots="1" value="10" 
> reservedtoken="PRR" />
>     <Track from="E" to="1" />
>     <Track from="B" to="1" />
>     <Track from="B" to="E">
> 	 <Draw from="E" to="[210,.25]" radius="-.25" />
> 	 <Draw from="[210,.25]" to="[300,.25]" radius=".25" />
> 	 <Draw from="[300,.25]" to="B" radius="-.25" />
>     </Track>
> </Tile> 

This tile happens to be the only one with drawing instructions.
I presume, that in all other cases the drawing instructions are
derived automatically. 

For instance tile #65 (OO city with a sharp and a wide bend):
would the tracks be curved by default (as they should, IMO), 
or are special drawing instructions needed to achieve that?
(TileDesigner derives such things from the specified off-center city
location).

> Tile code defaults to the id if it is numeric, otherwise it 
> defaults to 
> "", can be overriden with code="603" etc.

What is the purpose of the tile code?

In Tiles.xml I had made a distinction between "id" and "name",
where id must be unique. "name" was intended to be the tile number 
as printed on the tile (not by TileDesigner, though), 
and is displayed on the screen and in the logs where applicable.
So the two different tiles 69 have ids 69 and 1069, but both have
name="69". Is this perhaps what you intend to use code for?

And what is the use of "Category"? Just a simple way to create annotation?

> Note that for the #23 tile the excludes are automatically picked up 
> since the edges overlap.  Since 90% of the gauge will be normal, it 
> makes sense to default that attribute (as well as level, 
> which is only 
> needed for tiles with overpasses).  The Milano tile shows how extra 
> excludes that wouldn't be known just from looking at the connectivity 
> information are specified.  The last tile shows how you can 
> specify how 
> to draw a particular piece of track if the default choices 
> won't work (a 
> negative radius means curving away from the center of the 
> tile, positive 
> means curve towards the center; leaving radius out means a straight 
> line).  

Wouldn't preprinted Milano then also need drawing specifications
to show the tracks joining?

If you are worried about intialization time (and 
> automatically 
> positioning elements that don't have a position specified is not a 
> trivial task), this file could be built from a master file 
> that contains 
> all the tile definitions and filling in all the drawing and other 
> defaulted information.  Once you do that, this needs to be 
> considered a 
> generated file, but that is a good thing since otherwise you 
> will have 
> multiple copies of the same tile data that have to be updated and we 
> know that means they won't be exactly the same.
> 
> In addition to text annotations, we need to support other 
> annotations as 
> well, which would be used to show additional building costs 
> or graphics 
> added to the tile.  In my perl code, I just supply arbitrary 
> postscript 
> code for them, but that won't work here.  I suggest having something 
> like <Annotation shape="xxx" position="a,r" scale="s"/> which 
> references 
> shape xxx defined elsewhere, either SVG to draw it or perhaps even 
> custom code.
> 
> It will be a lot less work to add the excludes that can't be deduced 
> automatically than to do all the splitting of junctions into junction 
> exits, and the resulting datastructure will be simpler as well.

Yes, this is much simpler. 

How about scaling?
The main problem we have with the tiles generated by TileDesigner is,
that these do not scale down very well. 
Revenue value and tile number get unreadable on the map.
Do you have a fix for that?

Erik.