rails-devel — List for discussion of Rails development

[Rails-devel] revenue library

[Freek D. <sf_...@ma...>]

Stefan, and all others who helped,

My compliments for the revenue calculator. It looks awesome already!

I just did a minor commit adding the graph libraries to the classpath in
build.xml; without it, it did not run. (This is only relevant for those
who use ant to build the app).

Regards,
Freek

Re: [Rails-devel] Rails Bug

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

I have tried to reproduce this error with the newest code, but everything
went fine.
That means that either the problem has been fixed in the meantime, or that
you have hit upon a rare case that only appears under some special
circumstances. In the latter case, I would need one or more saved files,
taken as closely as possible before the error(s) occur(s).

Any applicable fixes will be in the next release, as well as a first
implementation of revenue calculation.
(I just found that the current calculation algorithm does not count the 18EU
villages and ports, so it's definitely not finished).

As for Java versions: Rails is written for Java 1.5 (or 5.0). I am not aware
of any reasons why it would not run under 1.6/6.0, but Rails is not
systematically tested with that version, at least not by me.

Regards,
Erik.

-----Original Message-----
From: cha...@us...
[mailto:cha...@us...] 
Sent: Wednesday 05 May 2010 08:12
To: ev...@us...
Subject: Rails Bug


Message body follows:

I just downloaded the most recent Rails.  The game hung hard
twice during stock trading in 18EU.  Once right after
operations ended and trading started for the first time,
once after all the Minor companies were sold and some stocks
were bought, just as it was switching to another player's
stock trade turn (so both happened at the start of a
player's stock phase, before he had a chance to do
anything).  I saved the game and loaded (which got me past
the first lock-up).  When I loaded the second saved game it
was at a much earlier point in the game, and I got a warning
me that it was saved in a state where one of the [player
name] something was empty or null.  Sorry I can't recall the
exact error.

Playing on Vista, I have the latest Java and I don't have
problems running other Java apps.  I worked at Microsoft as
a hardware/OS tech and can pretty much tell you that it's
not a problem with my PC or setup.

BTW, the next feature I would add is a suggestion of the
best possible routes during each player's operation.  You'll
need it for AI, anyway, and it can cut HOURS from the
play-time as a player-assist.

DJL

--
This message has been sent to you, a registered SourceForge.net user,
by another site user, through the SourceForge.net site.  This message
has been delivered to your SourceForge.net mail alias.  You may reply
to this message using the "Reply" feature of your email client, or
using the messaging facility of SourceForge.net at:
https://sourceforge.net/sendmessage.php?touser=1278869

[Rails-devel] 1835 updates

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

I have completed the 1835 Clemens variant, and added three new game options:
- The LD private to provide 30M income in stead of 20M,
- BY can float at either 50% or 20%,
- Minors do not operate if BY has not floated (at 50%).

I have also marked 1835 "Almost playable". 
There are still some bugs. One serious bug (reported before) is, that the
game hangs if the start packet has not been fully sold and the minors are
about to operate. There now is a workaround: select the third option listed
above, or the Clemens variant.

The Games List has been reorganized to put the games in playability order.
You'll no longer be annoyed (as I was) by finding the yet experimental 1825
at the top.

Erik.

[Rails-devel] 1835 Prussian operation

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

I have implemented the main Prussian peculiarity, once it runs: 
no dividend is paid out for shares that have been exchanged 
for precursors (privates, minors) that have run before in the same OR.

To get the details right, I have followed the clarification in Bill Stoll's
old FAQ 
(see
http://web.archive.org/web/20041024222224/www.geocities.com/TimesSquare/Aren
a/5276/depot/1835f.htm):

<quote>
Q5.1 Can PR operation be denied after it has already been denied once?
    This question is in reference to section XIII "Bringing the Prussian
Railway into Service" in the 2nd Edition English translation of the rules.
This section says: "It is not permitted for the owner of a certificate to
gain a bonus by getting two lots of income for any certificate in the same
round. If therefore the Prussian Railway is opened at a point in the
operating round where its operation would result in a player gaining such a
bonus then the Prussian, although open, does not operate until the following
round."

    The game author, Michael Meier-Bachl, responded indirectly to this
question. Here is FAQ author's interpretation of what he wrote: (the game
author provided the example) "If the PR forms during an Operating Round
(OR), then: a) if the Minor #2 (M2) has already operated, the Prussian (PR)
does not operate until the next OR. That is the ONLY instance in which the
PR, although formed, does not operate. b) if a Private or Minor company
converts to PR in an OR after providing income or operating, then those
converted shares earn no PR dividends in that OR. The unpaid dividends stay
in the bank."

    "Example: M1 buys the first 4-train, M2 converts to PR before operating,
M1, M5 and Braunschweigische convert to PR shares. Then in this OR, M3, M4
and M6 operate. Then the Prussian will operate. If Prussia pays dividends,
the former M1 and Braunschweigische will not get dividends this round, and
the former M5 WILL get dividends."
</quote>

Implementing this feature required some refactoring: most of the payout
logic has moved from PublicCompany to OperatingRound.

Erik.

Re: [Rails-devel] Improved revenue prediction / different scenario

[alexti <al...@sh...>]

Hi Stefan,

Thanks for the explanation. I think I understand what you're doing; I  
wasn't doing exactly the same and changing my algorithm brought some  
improvement, but as usual it was not that big - I'm starting to feel you  
have some kind of magic predictor ;-)

I've run your scenario and my algorithm found the same set of routes,  
however it was able to find more scenic route between M6 and L11 for 5+5  
train :) It took 46s. Here are my stats.

Routes found in 45.9643s
[4:340] {E12,C10.SE,C10.NW,B9,B11,A10.N,A8.S,A8.N,A4.S,A4.N,A2.S}
[8:290]  
{N1.SW,M2,L3.NE,L3.SW,K4,J3,J5,G6.NE,G6.NW,F5,E6.NE,E6.NW,D5,B3.SE,B3.NW,A2.SE}
[10:230] {E12,H13,I14.NE,J13.SW,J13.NE,L11,M8,M10,M6,L5.SE,L5.NW,K4,J5,H3}
[6:240]  
{N1.S,N3.N,N3.SW,M4.NE,M4.NW,L3.SE,L3.NW,J3,H3,F5,D5,D7.N,D7.NW,C6.SE,C6.SW,B7,B9,C8.SW,C8.S,C10.N,C10.SW,B11}
50,125,612 routes tried

The frustrating (to me) part is that you've done only 564,805 while I did  
over 50 millions (almost 100 times more). I am not sure how you manage to  
eliminate so many possibilities. I know that my algorithm doesn't handle  
multiple stations efficiently - essentially it scales linearly with number  
of stations. I have not thought about it yet, but it still wouldn't  
explain the difference.

Maybe I'm overlooking something. Or maybe I have some bug in the  
implementation that doesn't eliminate something I think it does :)

Thanks,
Alex.


On Sun, 02 May 2010 13:20:14 -0600, Stefan Frey <ste...@we...> wrote:

> Alex,
> sorry for not answering earlier to the question about the improved  
> revenue
> prediction.
>
> The scheme is simple.  Assume that N is the number of trains in the  
> trainset.
> First I replace the maximum revenue potential of each single train by the
> maximum results of running each train alone.
>
> If there are more than two trains to run:
> Start with J=N-1 and decrease J with each step until J=1.
> - Run the combined set of trains [J, ... N] and use the optimal result to
> predict the maximum future revenue potential of that train set.
>
> Then run the combined optimization of all trains, given the maximum  
> revenue
> potential for each set [J, N], with J > 1.
>
> I would like to compare another scenario based on the track network A to  
> check
> if we get the same results.
> The changes are:
> - SLSF has 4 tokens now (D5, J3, L11, E12)
> - Trains running are 6E, 8, 5+5, 4D
> (E: ignores towns, D: ignores towns and double city and offboard values)
> The best run I find is 1100. Total running time 78 sec.
> Network runs (6E cyan, 8 pink, 5+5 orange, 4D gray)  and log is attached.
>
> Stefan
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [Rails-devel] Implementation details for revenue calculation

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

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Saturday 01 May 2010 21:54
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

> B) Upgrades to green Berlin are not allowed (no valid orientation).

[EV] Was caused by the OO tile laying fix. Green Berlin was subjected to the
same kind of check.
The OO-check is now only done if the number of cities on a tile remains the
same.

I have attached another one: At least on my laptop the southern part of the 
map is not shown anymore when Bay is active, as they have several special 
lays available. And no scrollbar shows up to scroll down.

[EV] I don't see this problem with this saved file.
Did you see any exceptions in the window where Rails is started?

Erik.

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. <ste...@we...>]

Erik:
I agree that is really hard to know (predict) what all the 18xx (might) have 
defined, especially in those areas which are not that important to be covered 
by the rules comparison list. For those details everyone is restricted to the 
knowledge of the titles he plays regularly.

In some sort re-factoring is always a kind of reinventing. Hopefully to the 
better.

I fixed the issue with the ClosePrivate implementation, some leftover of the 
separation of the correction actions prevented the propagation of the action 
down to the OR class.

I will be away for a week on vacation, I hope to find a finalized 1835 after 
that ;-)

Stefan

> It's usually impossible to tell beforehand if some special case can be
> handled by a generic property, or needs special code (in a game-specific
> subclass). I usually try to find out how it can be done with minimal code.
> In this case I gladly leave it to you how to model all of this. I only got
> a (perhaps unjustified) feeling that you were reinventing some wheel. But I
> may be wrong, and in that case I have said nothing. Peace is not in danger.
>
> Erik.
>
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Improved revenue prediction / different scenario

[Stefan F. <ste...@we...>]

Alex,
sorry for not answering earlier to the question about the improved revenue 
prediction. 

The scheme is simple.  Assume that N is the number of trains in the trainset.
First I replace the maximum revenue potential of each single train by the 
maximum results of running each train alone.

If there are more than two trains to run:
Start with J=N-1 and decrease J with each step until J=1.
- Run the combined set of trains [J, ... N] and use the optimal result to 
predict the maximum future revenue potential of that train set.

Then run the combined optimization of all trains, given the maximum revenue 
potential for each set [J, N], with J > 1.

I would like to compare another scenario based on the track network A to check 
if we get the same results.
The changes are:
- SLSF has 4 tokens now (D5, J3, L11, E12)
- Trains running are 6E, 8, 5+5, 4D
(E: ignores towns, D: ignores towns and double city and offboard values)
The best run I find is 1100. Total running time 78 sec.
Network runs (6E cyan, 8 pink, 5+5 orange, 4D gray)  and log is attached.

Stefan

Re: [Rails-devel] Implementation details for revenue calculation

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

What is your suggestion then to model the off-board stations in 18Scan,
where 
only the token-owner can run to? "Off-board destinations"?

[EV] Those tiles haven't been defined yet, and I'm not even sure if
TileDesigner can do that, so these might need special treatment (i.e.
handcrafting) anyway. 
I'd say: either some property in the hex definition in Map.xml, or (indeed)
a special name in Tiles.xml. I guess the former would be easier.

It's usually impossible to tell beforehand if some special case can be
handled by a generic property, or needs special code (in a game-specific
subclass). I usually try to find out how it can be done with minimal code.
In this case I gladly leave it to you how to model all of this. I only got a
(perhaps unjustified) feeling that you were reinventing some wheel. But I
may be wrong, and in that case I have said nothing. Peace is not in danger.

Erik.

Re: [Rails-devel] Some minor changes

[Stefan F. (web.de) <ste...@we...>]

Erik;
you are welcome. 
Actually both were always there, but the second I forgot to commit and the 
other was only used in the no-map mode. Unfortunately after the move of the 
close private action to the general section of the OperatingRound the action 
is shown in the menu and can be selected, but the close is not executed in my 
test. I will look into that tomorrow.
Stefan

On Saturday 01 May 2010 22:23:06 Erik Vos wrote:
> -> CloseManually Tag available for the ClosingConditions of
> PrivatCompanies,
>
> allows to close that private via the special menu during ORs
> -> ListandFixSavedFiles allows the deletion of single actions and refreshes
> the display after the edit events
>
> [EV] Very good, these were two novelties that I had in mind of doing at
> some time.
> Thanks for saving me work! :-)
>
> Erik.
>
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

Erik:

The difference is minor: You define the station types  first  and then define 
the properties by coding methods that check the types, I would define the 
properties first and then define station types accordingly.

As I think we are going in circles here, I will use your 
solution to keep the peace ;-) 

What is your suggestion then to model the off-board stations in 18Scan, where 
only the token-owner can run to? "Off-board destinations"?

Kiruna is a (standard) town on a off-board map tile, that is simple.

Stefan


On Saturday 01 May 2010 22:21:34 Erik Vos wrote:
> Another extension allows the pattern:
> slots = 0 => always run through
> slots = -1 => never run through (as standard off-map areas)
>
> [EV] Not needed. Normal off-board areas have an OffMapCity type station,
> which should have the not-run-through property built in.
> But here we were talking about City type stations.
>
> I personally favor defining more variables and prefer not encode several
> dimensions into one variable.
>
> [EV] Agreed, but, as said, that was not needed.
>
> In your defintion e.g. a Station is fully tokened if number of slots ==
> number of tokens or number of slots equals zero.
>
> In my definition a Station is fully tokened if (number of slots == numer of
> tokens). I would first check if the station is fully tokened and then the
> different booleans define what companies can if they have or have not an
> own
>
> token.
>
> [EV] "Fully tokened" is not a very interesting property or state.
> "Runnable-through" is what we are interested in. And my definitions are:
> (a) a City type Station can be run through if there is at least one free
> slot
> (i.e. not "fully tokened") or the number of slots is zero. It is a variable
> state.
> (b) an OffMapCity type Station can never be run through. This is a fixed
> property.
>
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Some minor changes

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

-> CloseManually Tag available for the ClosingConditions of PrivatCompanies,

allows to close that private via the special menu during ORs
-> ListandFixSavedFiles allows the deletion of single actions and refreshes
the display after the edit events

[EV] Very good, these were two novelties that I had in mind of doing at some
time. 
Thanks for saving me work! :-)

Erik.

Re: [Rails-devel] Implementation details for revenue calculation

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

 


Another extension allows the pattern:
slots = 0 => always run through 
slots = -1 => never run through (as standard off-map areas)

[EV] Not needed. Normal off-board areas have an OffMapCity type station, 
which should have the not-run-through property built in.
But here we were talking about City type stations.

I personally favor defining more variables and prefer not encode several 
dimensions into one variable.

[EV] Agreed, but, as said, that was not needed.

In your defintion e.g. a Station is fully tokened if number of slots == 
number of tokens or number of slots equals zero.

In my definition a Station is fully tokened if (number of slots == numer of 
tokens). I would first check if the station is fully tokened and then the 
different booleans define what companies can if they have or have not an own

token.

[EV] "Fully tokened" is not a very interesting property or state. 
"Runnable-through" is what we are interested in. And my definitions are:
(a) a City type Station can be run through if there is at least one free
slot
(i.e. not "fully tokened") or the number of slots is zero. It is a variable
state.
(b) an OffMapCity type Station can never be run through. This is a fixed
property.

[Rails-devel] Some minor changes

[Stefan F. (web.de) <ste...@we...>]

-> Undo and Zoom works for the run paths
-> The run path now shows all the vertices visited (previously the vertices 
removed by the graph optimization where not included)
-> CloseManually Tag available for the ClosingConditions of PrivatCompanies, 
allows to close that private via the special menu during ORs
-> ListandFixSavedFiles allows the deletion of single actions and refreshes
the display after the edit events

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. (web.de) <ste...@we...>]

> [EV] Zero slots should be interpreted as: everybody can run through.
> I think such a rule would be generic enough, not needing additional
> attributes for *this* purpose.
>

Sure you can encode some of boolean attributes into the numerical attribute of 
slots.

Another extension allows the pattern:
slots = 0 => always run through 
slots = -1 => never run through (as standard off-map areas)

I personally favor defining more variables and prefer not encode several 
dimensions into one variable.

In your defintiion e.g. a Station is fully tokened if number of slots == 
number of tokens or number of slots equals zero.

In my definition a Station is fully tokened if (number of slots == numer of 
tokens). I would first check if the station is fully tokened and then the 
different booleans define what companies can if they have or have not an own 
token.

But in fact your are right: it is matter of preference.


> For solving the whole variety of possible off-map locations we need more
> flexibility and generality as outlined by the new attributes.
>
> [EV] Yes, but attributes of what?
> I think we basically have two dimensions: StationType and TrainType.
> The intersection (matrix) of these types needs properties that define
> the behaviour towards revenue calculation; I think we can assign
> such properties to either one.
> TrainType already exists, StationType would be a new class
> (already proposed by you), defined in some ConfigurableComponent.

Attributes of stations as outlined below. I hope that the question how tokens 
influence the running of train is not train dependent.

> B) Upgrades to green Berlin are not allowed (no valid orientation).
>
> I can provide save files if required.
>
> [EV] Yes please, for case B. I'm hitting on another bug when trying to get
> there... :-(
>

Attached. Hope you can open it, if you have changed anything already.

I have attached another one: At least on my laptop the southern part of the 
map is not shown anymore when Bay is active, as they have several special 
lays available. And no scrollbar shows up to scroll down.

Stefan

Re: [Rails-devel] Implementation details for revenue calculation

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

 

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Saturday 01 May 2010 20:58
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

Erik:
thanks, it is moving in the right direction, but it is still not on the 
target: Having zero slots it evaluates as fully tokened, thus no one can run

through. Setting slots to one, it would allow tokening :-(

[EV] Zero slots should be interpreted as: everybody can run through.
I think such a rule would be generic enough, not needing additional
attributes for *this* purpose.

For solving the whole variety of possible off-map locations we need more 
flexibility and generality as outlined by the new attributes. 

[EV] Yes, but attributes of what?
I think we basically have two dimensions: StationType and TrainType. 
The intersection (matrix) of these types needs properties that define
the behaviour towards revenue calculation; I think we can assign 
such properties to either one. 
TrainType already exists, StationType would be a new class
(already proposed by you), defined in some ConfigurableComponent.


At tests for revenue calculation on a 1835 map I ran into the following bugs

quickly:

A) Hamburg north (base of 6) has a value of 20, instead of the correct 40.

[EV] Correct. Fixed.

B) Upgrades to green Berlin are not allowed (no valid orientation).

I can provide save files if required.

[EV] Yes please, for case B. I'm hitting on another bug when trying to get
there... :-(

Erik.

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. <ste...@we...>]

Erik:
thanks, it is moving in the right direction, but it is still not on the 
target: Having zero slots it evaluates as fully tokened, thus no one can run 
through. Setting slots to one, it would allow tokening :-(

For solving the whole variety of possible off-map locations we need more 
flexibility and generality as outlined by the new attributes. But you are 
right, we should think that through carefully to both add enough flexibility 
and not breaking any of the old code. For the time being I will simply ignore 
the track structure in tile.xml for the off-map locations and rely on a 
separate defined graph structure, where no side-effects are possible.

In any case the new functionality can come in handy at times.

At tests for revenue calculation on a 1835 map I ran into the following bugs 
quickly:

A) Hamburg north (base of 6) has a value of 20, instead of the correct 40.
B) Upgrades to green Berlin are not allowed (no valid orientation).

I can provide save files if required.

Stefan



On Friday 30 April 2010 17:32:04 Erik Vos wrote:
> OK, I have replaced tile -939 in Tiles.xml by a handmade version.
> This applies to the generic Tiles.xml and to 1856 (Goderich) and 18EU
> (Hamburg).
> The extra element is a "City" type station, with zero slots.
> The tile is still recognizable as an off-board tile by its colour ("red").
>
> Please check if this works for you.
>
> There is now a new XML file called HandmadeTiles.xml.
> During running the XML conversion tool ConvertTilesXML,
> tile entries in this file are used; the corresponding
> tiles in TileDictionary.xml are not converted but skipped.
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday 29 April 2010 21:58
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Implementation details for revenue calculation
>
> yes that helps, otherwise it would not be scored. The same is true for the
> equivalent tile in 1856.
>
> The (additional) virtual vertex takes care of the bonus condition to end
> the
>
> run at the off-board location and is thus only required for 18EU.
>
> On Wednesday 28 April 2010 21:41:08 Erik Vos wrote:
> > Would it help if I changed the tile description in Tiles.xml accordingly?
> > (i.e. as you say: "a non-tokenable station in the middle of the hex")
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Stefan Frey (web.de) [mailto:ste...@we...]
> > Sent: Wednesday 28 April 2010 00:37
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Implementation details for revenue calculation
> >
> > 4) 18EU
> >
> > Hamburg: I have to admit that I do not like the Hamburg offboard tile:
> > The graphical representation does not define exactly, where the value
> > vertex is,
> >
> > as it does not contain any type of station.
> > I assume the most natural interpretation is to assume a non-tokenable
> > station
> > in the middle of the hex (similar to tile 12, only that the slot cannot
> > be filled). To work with the offboard bonuses, an additional vertex is
> > connected
> > to the station vertex, which acts as a sink (has no neighbors defined,
>
> thus
>
> > similar to a tokened out station). All of the bonus combinations for
> > Hamburg
> >
> > use that vertex to enforce the restriction that the bonus runs have to
>
> stop
>
> > in Hamburg. (D)
>
> ---------------------------------------------------------------------------
>
> >--- _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>- --
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

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

OK, I have replaced tile -939 in Tiles.xml by a handmade version.
This applies to the generic Tiles.xml and to 1856 (Goderich) and 18EU
(Hamburg).
The extra element is a "City" type station, with zero slots.
The tile is still recognizable as an off-board tile by its colour ("red").

Please check if this works for you.

There is now a new XML file called HandmadeTiles.xml.
During running the XML conversion tool ConvertTilesXML, 
tile entries in this file are used; the corresponding
tiles in TileDictionary.xml are not converted but skipped.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Thursday 29 April 2010 21:58
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Implementation details for revenue calculation

yes that helps, otherwise it would not be scored. The same is true for the 
equivalent tile in 1856.

The (additional) virtual vertex takes care of the bonus condition to end the

run at the off-board location and is thus only required for 18EU.

On Wednesday 28 April 2010 21:41:08 Erik Vos wrote:
> Would it help if I changed the tile description in Tiles.xml accordingly?
> (i.e. as you say: "a non-tokenable station in the middle of the hex")
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Wednesday 28 April 2010 00:37
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Implementation details for revenue calculation
>
> 4) 18EU
>
> Hamburg: I have to admit that I do not like the Hamburg offboard tile: The
> graphical representation does not define exactly, where the value vertex
> is,
>
> as it does not contain any type of station.
> I assume the most natural interpretation is to assume a non-tokenable
> station
> in the middle of the hex (similar to tile 12, only that the slot cannot be
> filled). To work with the offboard bonuses, an additional vertex is
> connected
> to the station vertex, which acts as a sink (has no neighbors defined,
thus
> similar to a tokened out station). All of the bonus combinations for
> Hamburg
>
> use that vertex to enforce the restriction that the bonus runs have to
stop
> in Hamburg. (D)
>
>
>
>
---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1830: Exchange option not offered

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

I created a similar situation with the current code and it went fine. So I
suppose it has been fixed in the meantime.

However, while testing this, I hit upon another problem: in case of an
exchange when the company is not at its train limit, and a train buy with
exchange is chosen, Rails displays a list of trains that can be exchanged,
including 'None'. Selecting this 'None' option does the buy at the reduced
exchange price, but without discarding any train! 

I think this 'None' option was a leftover from earlier versions, where this
was the way to buy a Diesel without exchange. Now that is a separate train
buy option. I have removed this option. Now, if the company only has one
train, the "which train to exchange" question is suppressed and the exchange
is executed without further ado (this removal of a question should not
affect saved files).

Erik.


-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Thursday 29 April 2010 10:40
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1830: Exchange option not offered

It looks like the fix to the trading of second Diesels onwards doesn't
quite work correctly in saved games.  See attached save file (load it
up in rails 1.2.2 - it won't work against current CVS build), on B&O's
last operating turn:

B&O (Steve) operates.
B&O lays tile #8 at hex I13/SE
B&O earns $200
B&O withholds dividend of $200.
B&O price goes from $142(J1) to $126(I1).
B&O buys a D-train from IPO for $800.

Key problem being the last line.  When played through, this was an
exchange of the 5 that the B&O currently has, on loading the save
file, it considers the trade to be a purchase, now B&O still has the 5
instead of the 5 being in the pool for purchase.

Phil

On 4 February 2010 23:19, Erik Vos <eri...@xs...> wrote:
> Hmm, I had always thought that only the first Diesel could be exchanged
for
> a lesser train, but after rereading the rules I must conclude that I was
> misguided. So all Diesels are now available by exchange.
>
> Erik.
>
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Thursday 04 February 2010 13:17
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] 1830: Exchange option not offered
>
> See the saved game file.  PRR to run, it just bought the 5 train off
> NYC, it should be able to exchange that for a D for $800, yet it isn't
> given the option to do so.  I've tested this on both 1.1.3 and 1.1.2
> and it seems to be an issue in both vesions
>
> Phil
>
>
>
----------------------------------------------------------------------------
--
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Changes to the Station objects

[Stefan F. (web.de) <ste...@we...>]

Thanks Erik for the first answers.

I agree that the fact that Tiles.xml is not game dependent, makes things 
somewhat more complicated. More seriously the automatic generation discourages 
any manual adjustments.

I considered to define bonus which are tile dependent there, but that I think
I will drop that idea too.

Maybe the easiest path to follow for now, is to define any rules related to 
the revenue calculation in a separate entity <RevenueCalculator> in Game.xml, 
wait until the dust settles and if advisable move some functionality back to 
more logical positions. That would decrease the coordination efforts.

The question about the token positions (be it open or used) was only related 
to the graphical representation. I wanted to ensure that the path shown 
travels through the tokens of the running company if there is one or through 
an open slot, if the station is not fully tokened. Thus not really that 
important.

Stefan


On Friday 30 April 2010 00:10:47 Erik Vos wrote:
> Stefan,
>
> This all needs careful consideration. Some short answers for now:
>
> A,B) Where would you want to define these extra attributes?
> Please note, that no game-dependent attributes can be defined in Tiles.xml.
> But you can use the types defined there as station type names for your
> extra properties.
> I think these properties should be placed in (or in place of, or added to)
> the <Defaults> section of <TrainManager> in Game.xml.
>
> C) I believe this is already (at least partly) provided for by the city
> type
>
> in Tiles.xml, and the various train attributes in Game.xml. None of this is
> already used, but at least that's where I would start refining this.
>
> D1) See the cityMap in util.ConvertTilesXML, which translates the XML
> output of TileDesigner into the overall Tiles.xml. The location codes are
> related to the TileDesigner position names. In short:
> first digit: side or corner, counted as in orientation.
> second digit: 0=side, 5=corner
> third digit: 0=center, 1/2/3=inner/middle/outer ring, 6-9 positions
> in sharp and wide bends.
>
> D2) Not sure what you are after. Tokens belong to cities (stations),
> the slot is considered immaterial. (I know this doesn't help out for
> 1835 Hamburg, I'm not yet sure how to handle that case).
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday 29 April 2010 21:54
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Changes to the Station objects
>
> Hi Erik,
>
> I would like to add additional attributes to the station class. This is
> mainly
> related to the different off-board locations in various games. At the
> bottom
>
> were are some questions how to derive graph coordinates for various
> objects.
>
> Any comments or suggestions are welcome,
> Stefan
>
>
> A) Each station adds the following (additional) attributes:
>
> tokenAllows = {RunThrough, RunFrom, NoAccess, N/A}
> If a token is laid it allows to run through, to run from or no access?
>
> openStationAllows = {RunThrough, RunTo, NoAccess, N/A}
> If a token is laid it allows to run through, to run to or none?
>
> closedStationAllows = {RunThrough, RunTo, NoAccess, N/A}
> If the station is fully tokened and the company does not own a token there,
> what are the possibilities?
>
> To allow an easier definition I suggest to use station type definitions
> like
>
> the company types etc.
>
> A station is closed if the number of tokens equals the number of slots,
> otherwise it is open.
>
> By this definition a town is always closed, but by setting
> closedStationAllows
> to RunThrough that is not an issue.
>
> B) Different off-board locations:
> There is a substantial variation of different kind of off-board locations.
> There are at least four cases, may be more.
>
> 1) Standard off-board locations (as in 1830)
> The off-board areas act as sinks for all companies.
> No tokens allowed.
> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunTo)
>
> 2) Tokenable off-board locations (example: SP base in 1870)
> A base token can be layed in at least one of the areas.
> The rules claim that off-board areas are still sink for all companies,
> except
> for the company with a token which can start a train there.
> But it cannot run its trains through the hex (thus SP cannot have the same
> train enter from NE and then continue to the E).
>
> (tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows =
> RunTo)
>
> 3) Run-through off-board locations (as Hamburg in 18EU)
> A non-tokenable station (similar to towns), that allows running through it.
>
> (tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
> RunThrough)
>
> And another from an non-implemented game:
> 4) Tokenable run-to off-board locations (as in 18Scan)
> Here a base-token is needed to run to the station.
>
> (tokenAllows = RunFrom, openStationAllows = NoAccess , closedStationAllows
> =
>
> NoAccess)
>
> In  general a station is fully tokened if the nb of slots equals the nb of
> tokens. This implies that (default) towns are fully tokened (0=0), but the
> fullyTokened attribute would be set to RunThrough.
>
> StationTypes should be added to provide defaults.
>
> C) Other new station attributes
> runStationType = {Major, Minor}
> Is it counted as city-type or town-type for plus-trains and express-trains?
>
> name = {...}
> I would like to add is a "name" attribute for stations on
> tiles. Identical names would imply that those stations are mutually
> exclusive
> for train runs. They would be automatically added to the list of exclusions
> to the revenue calculator.
>
> D) Related questions to the current implementations:
>
> 1) How is the position property defined? Is this from the tiledesigner? 
> How
>
> do I read for example a value of 408?
>
> 2) Is there an easy way to determine the coordinates of the token for a
> public
> company if there are two or more tokens available? I currently use
> getTokenCenter(), but how do I know which of the available slots belongs to
> which company? How would I determine which is an open slot?
>
>
>
> ---------------------------------------------------------------------------
>- --
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Changes to the Station objects

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

Stefan,

This all needs careful consideration. Some short answers for now:

A,B) Where would you want to define these extra attributes?
Please note, that no game-dependent attributes can be defined in Tiles.xml.
But you can use the types defined there as station type names for your extra
properties.
I think these properties should be placed in (or in place of, or added to) 
the <Defaults> section of <TrainManager> in Game.xml.

C) I believe this is already (at least partly) provided for by the city type

in Tiles.xml, and the various train attributes in Game.xml. None of this is 
already used, but at least that's where I would start refining this.

D1) See the cityMap in util.ConvertTilesXML, which translates the XML output
of TileDesigner into the overall Tiles.xml. The location codes are related 
to the TileDesigner position names. In short:
first digit: side or corner, counted as in orientation.
second digit: 0=side, 5=corner
third digit: 0=center, 1/2/3=inner/middle/outer ring, 6-9 positions 
in sharp and wide bends.

D2) Not sure what you are after. Tokens belong to cities (stations), 
the slot is considered immaterial. (I know this doesn't help out for
1835 Hamburg, I'm not yet sure how to handle that case).

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Thursday 29 April 2010 21:54
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Changes to the Station objects

Hi Erik,

I would like to add additional attributes to the station class. This is
mainly 
related to the different off-board locations in various games. At the bottom

were are some questions how to derive graph coordinates for various objects.

Any comments or suggestions are welcome,
Stefan


A) Each station adds the following (additional) attributes:

tokenAllows = {RunThrough, RunFrom, NoAccess, N/A}
If a token is laid it allows to run through, to run from or no access?

openStationAllows = {RunThrough, RunTo, NoAccess, N/A}
If a token is laid it allows to run through, to run to or none?

closedStationAllows = {RunThrough, RunTo, NoAccess, N/A}
If the station is fully tokened and the company does not own a token there, 
what are the possibilities?

To allow an easier definition I suggest to use station type definitions like

the company types etc.

A station is closed if the number of tokens equals the number of slots, 
otherwise it is open. 

By this definition a town is always closed, but by setting
closedStationAllows 
to RunThrough that is not an issue.

B) Different off-board locations:
There is a substantial variation of different kind of off-board locations. 
There are at least four cases, may be more.

1) Standard off-board locations (as in 1830)
The off-board areas act as sinks for all companies.
No tokens allowed.
(tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunTo)

2) Tokenable off-board locations (example: SP base in 1870)
A base token can be layed in at least one of the areas.
The rules claim that off-board areas are still sink for all companies,
except 
for the company with a token which can start a train there.
But it cannot run its trains through the hex (thus SP cannot have the same 
train enter from NE and then continue to the E).

(tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows = 
RunTo)

3) Run-through off-board locations (as Hamburg in 18EU)
A non-tokenable station (similar to towns), that allows running through it.

(tokenAllows = N/A, openStationAllows = N/A, closedStationAllows =
RunThrough)

And another from an non-implemented game:
4) Tokenable run-to off-board locations (as in 18Scan)
Here a base-token is needed to run to the station.

(tokenAllows = RunFrom, openStationAllows = NoAccess , closedStationAllows =

NoAccess)

In  general a station is fully tokened if the nb of slots equals the nb of 
tokens. This implies that (default) towns are fully tokened (0=0), but the 
fullyTokened attribute would be set to RunThrough. 

StationTypes should be added to provide defaults.

C) Other new station attributes
runStationType = {Major, Minor}
Is it counted as city-type or town-type for plus-trains and express-trains?

name = {...}
I would like to add is a "name" attribute for stations on 
tiles. Identical names would imply that those stations are mutually
exclusive 
for train runs. They would be automatically added to the list of exclusions 
to the revenue calculator.

D) Related questions to the current implementations:

1) How is the position property defined? Is this from the tiledesigner?  How

do I read for example a value of 408?

2) Is there an easy way to determine the coordinates of the token for a
public 
company if there are two or more tokens available? I currently use 
getTokenCenter(), but how do I know which of the available slots belongs to 
which company? How would I determine which is an open slot?



----------------------------------------------------------------------------
--
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Phil D. <de...@gm...>]

Glad to help with spreading the insidious invasion of my language to
the rest of the world :)

On 29 April 2010 21:04, Stefan Frey <ste...@we...> wrote:
> Phil:
> I was more making fun (of myself) after rereading the rules for the Pullman,
> but it is good to see that others read my proposals carefully ;-)
>
> My suggestion below is more against the spirit of the rules than according to
> it, but thanks for recommending to ask the 18xx yahoo group, which I believe
> is not needed, as I suspect that everyone agrees that it should be part of
> maximization process.
>
> And reading your mail carefully, I learn that the plural of vertex is
> vertices ;-)
> Stefan
>
>>
>> > Pullman: If I understand the 18EU rules correctly, the Pullman is an
>> > exception to the second sentence under 4.4.3: "... must calculate the
>> > maximum possible earnings". 4.4.9., second paragraph defines that "...
>> > doubles the value of any City or Off-Map Location of the President's
>> > choice".
>> > To capture the spirit of the rules and to simplify things the Pullman
>> > will not be part of the maximization process, but the President will be
>> > prompted to select one the city values of the runs.
>>
>> Hmm, not sure I agree, I think this is a case of slightly misleading
>> rules text.  I think that the 3: "... must calculate the maximum
>> possible earnings" is always in force and Pullmans must take account
>> of it.  David Hecht is pretty vocal on the 18XX yahoo list so it's
>> always worth posting the question if we aren't in agreement on this.
>> To make the 'must maximise' work for route calculation I would think
>> that your D approach should work here (I'm beginning to think that
>> with all these virtual vertices, route bonuses etc. that the EU
>> revenue calc might take a little while!)
>>
>> Phil
>>
>> ---------------------------------------------------------------------------
>>--- _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. <ste...@we...>]

Phil:
I was more making fun (of myself) after rereading the rules for the Pullman, 
but it is good to see that others read my proposals carefully ;-)

My suggestion below is more against the spirit of the rules than according to 
it, but thanks for recommending to ask the 18xx yahoo group, which I believe 
is not needed, as I suspect that everyone agrees that it should be part of 
maximization process.

And reading your mail carefully, I learn that the plural of vertex is 
vertices ;-)
Stefan

>
> > Pullman: If I understand the 18EU rules correctly, the Pullman is an
> > exception to the second sentence under 4.4.3: "... must calculate the
> > maximum possible earnings". 4.4.9., second paragraph defines that "...
> > doubles the value of any City or Off-Map Location of the President's
> > choice".
> > To capture the spirit of the rules and to simplify things the Pullman
> > will not be part of the maximization process, but the President will be
> > prompted to select one the city values of the runs.
>
> Hmm, not sure I agree, I think this is a case of slightly misleading
> rules text.  I think that the 3: "... must calculate the maximum
> possible earnings" is always in force and Pullmans must take account
> of it.  David Hecht is pretty vocal on the 18XX yahoo list so it's
> always worth posting the question if we aren't in agreement on this.
> To make the 'must maximise' work for route calculation I would think
> that your D approach should work here (I'm beginning to think that
> with all these virtual vertices, route bonuses etc. that the EU
> revenue calc might take a little while!)
>
> Phil
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Implementation details for revenue calculation

[Stefan F. <ste...@we...>]

yes that helps, otherwise it would not be scored. The same is true for the 
equivalent tile in 1856.

The (additional) virtual vertex takes care of the bonus condition to end the 
run at the off-board location and is thus only required for 18EU.

On Wednesday 28 April 2010 21:41:08 Erik Vos wrote:
> Would it help if I changed the tile description in Tiles.xml accordingly?
> (i.e. as you say: "a non-tokenable station in the middle of the hex")
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Wednesday 28 April 2010 00:37
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Implementation details for revenue calculation
>
> 4) 18EU
>
> Hamburg: I have to admit that I do not like the Hamburg offboard tile: The
> graphical representation does not define exactly, where the value vertex
> is,
>
> as it does not contain any type of station.
> I assume the most natural interpretation is to assume a non-tokenable
> station
> in the middle of the hex (similar to tile 12, only that the slot cannot be
> filled). To work with the offboard bonuses, an additional vertex is
> connected
> to the station vertex, which acts as a sink (has no neighbors defined, thus
> similar to a tokened out station). All of the bonus combinations for
> Hamburg
>
> use that vertex to enforce the restriction that the bonus runs have to stop
> in Hamburg. (D)
>
>
>
> ---------------------------------------------------------------------------
>--- _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Changes to the Station objects

[Stefan F. <ste...@we...>]

Hi Erik,

I would like to add additional attributes to the station class. This is mainly 
related to the different off-board locations in various games. At the bottom 
were are some questions how to derive graph coordinates for various objects.

Any comments or suggestions are welcome,
Stefan


A) Each station adds the following (additional) attributes:

tokenAllows = {RunThrough, RunFrom, NoAccess, N/A}
If a token is laid it allows to run through, to run from or no access?

openStationAllows = {RunThrough, RunTo, NoAccess, N/A}
If a token is laid it allows to run through, to run to or none?

closedStationAllows = {RunThrough, RunTo, NoAccess, N/A}
If the station is fully tokened and the company does not own a token there, 
what are the possibilities?

To allow an easier definition I suggest to use station type definitions like 
the company types etc.

A station is closed if the number of tokens equals the number of slots, 
otherwise it is open. 

By this definition a town is always closed, but by setting closedStationAllows 
to RunThrough that is not an issue.

B) Different off-board locations:
There is a substantial variation of different kind of off-board locations. 
There are at least four cases, may be more.

1) Standard off-board locations (as in 1830)
The off-board areas act as sinks for all companies.
No tokens allowed.
(tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunTo)

2) Tokenable off-board locations (example: SP base in 1870)
A base token can be layed in at least one of the areas.
The rules claim that off-board areas are still sink for all companies, except 
for the company with a token which can start a train there.
But it cannot run its trains through the hex (thus SP cannot have the same 
train enter from NE and then continue to the E).

(tokenAllows = RunFrom, openStationAllows = RunTo, closedStationAllows = 
RunTo)

3) Run-through off-board locations (as Hamburg in 18EU)
A non-tokenable station (similar to towns), that allows running through it.

(tokenAllows = N/A, openStationAllows = N/A, closedStationAllows = RunThrough)

And another from an non-implemented game:
4) Tokenable run-to off-board locations (as in 18Scan)
Here a base-token is needed to run to the station.

(tokenAllows = RunFrom, openStationAllows = NoAccess , closedStationAllows = 
NoAccess)

In  general a station is fully tokened if the nb of slots equals the nb of 
tokens. This implies that (default) towns are fully tokened (0=0), but the 
fullyTokened attribute would be set to RunThrough. 

StationTypes should be added to provide defaults.

C) Other new station attributes
runStationType = {Major, Minor}
Is it counted as city-type or town-type for plus-trains and express-trains?

name = {...}
I would like to add is a "name" attribute for stations on 
tiles. Identical names would imply that those stations are mutually exclusive 
for train runs. They would be automatically added to the list of exclusions 
to the revenue calculator.

D) Related questions to the current implementations:

1) How is the position property defined? Is this from the tiledesigner?  How 
do I read for example a value of 408?

2) Is there an easy way to determine the coordinates of the token for a public 
company if there are two or more tokens available? I currently use 
getTokenCenter(), but how do I know which of the available slots belongs to 
which company? How would I determine which is an open slot?