rails-devel — List for discussion of Rails development

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, January 03, 2012 12:12 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Push request: Enforcement of forced train
> purchases
> 
> See comments below
> 
> On Tuesday, January 03, 2012 08:27:16 am Frederick Weld wrote:
> > Regarding "a train":
> > One option to accomodate both Erik's and Stefan's approach would be as
> > follows: Each 18xx variant has a set of trains that are relevant for
> > checking routes. For performance reasons, this set should be minimal.
> > So for 1830 it would be {2} and for 18VA (if it had route-dependent
> > enforcement) would be {2,1G}. The adapter's route check would be run
> > with this set.
> 
> That is possible, however I do not recommend to implement features
> potentially never used. From my experience after some time they get
> untested and/or unmaintained. For the time being I would define a static
> global inside RevenueAdapter.

I suppose you mean: define and use a fixed set {2}, and I agree with that
idea. 
At least we would then have a placeholder that we could later make
configurable, should the need arise.

Erik.

Re: [Rails-devel] Rails 2.0 OperationRound Status & other RoundClasses

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

Hi Martin,
good question: However I cannot and will not commit any date for this. 
The nice thing about the project here is that you do not work with time 
pressure, the bad thing is that it does not have the same priority as those 
from real life which have a schedule assigned.

To give a current guess in the best case it can be 2 months time, but it could 
also take 4 months, before Rounds will be implemented and stabilized.

I have recently update the Rails 2.0 package and you will realize that I have 
no even really started on breaking up the Round classes, as I still focus on 
the State/Model classes, but I expect that to finish soon. This will require 
some more testing and working to get stabilized again. 

Then I will start working on breaking up and redesigning the Round classes, so 
this should start in maybe a month or so.

As the developer of 1870 I am waiting for this to happen for two years now ;-)

Stefan


On Monday, January 02, 2012 01:20:44 pm Dr....@t-... wrote:
> Hi Stefan,
> 
> 	since i am currently fiddling in 1880 with some of those Classes
> (Stock-/Start-/OperatingRound) i would love to know when you expect to
> have a useable Class for crosschecks/refactoring the needed additions
> for 1880 in rails 2.0.
> 
>  >> Regarding incompatibility with Rails 2.0 (@Stefan):
>  >> Which aspect of this patch is incompatible to rails 2.0? Which
>  >> adjustment would be necessary in order to avert this?
>  >
>  >The incompatibility is narrowly defined in the sense that the
> 
> commit/patch
> 
>  >cannot be merged automatically with the Rails 2.0 patch:
>  >All patches that include a change GameManager or any of the Round
> 
> classes
> 
>  >cannot be merged automatically anymore.
>  >
>  >It does not mean that it incompatible in a broader sense, it is only
> 
> that
> 
>  >someone has to do the merge manually at some time in the future. And
> 
> as you
> 
>  >are already implement faster as I can currently comment on, it is
> 
> unlikely
> 
>  >that I will be able to that ;-)
> 
>  Btw, Happy new Year to ye all.  Regards Martin

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

See comments below

On Tuesday, January 03, 2012 08:27:16 am Frederick Weld wrote:
> Regarding "a train":
> One option to accomodate both Erik's and Stefan's approach would be as
> follows: Each 18xx variant has a set of trains that are relevant for
> checking routes. For performance reasons, this set should be minimal.
> So for 1830 it would be {2} and for 18VA (if it had route-dependent
> enforcement) would be {2,1G}. The adapter's route check would be run
> with this set.

That is possible, however I do not recommend to implement features potentially
never used. From my experience after some time they get untested and/or 
unmaintained. For the time being I would define a static global inside 
RevenueAdapter.

And I doubt that you have to worry about the performance, if you run each 
train separately (this was the minor "bug" in your implementation: It you want 
to test many trains, it is much faster to run each once). And you could even 
stop after the first intermediate update that a solution is found, as you do 
not care for the optimal solution.

> 
> Regarding "each consumer directly accesses the algorithm package":
> Functionally, Stefan has made a valid point. But having performance in
> mind, it might be better if network information would not always be
> built from the scratch for each kind of check in every consumer. For
> example, in SimTex's 1830, network information (both used for UI/AI)
> is built/updated after each action. The needed component
> ("NetworkState") would reside below the game engine consumers and
> either be part of the game engine or be placed on top of it. But
> perhaps such design is only the target in the longer term.

I thought about that (Alex suggested it as well some time ago): However I see 
many more advantages keeping algorithm stateless. All state information is 
stored inside the Rails game engine. Consider the algorithm defining an 
appropriate view on the Rails database first and throwing away the data after 
each use.

And think about the consequences: 
* Everything you want to store have to be Rails state variables (to allow 
undo). 
* You have to define triggers from all actions that might change the network.
* There are lot of optimization that still have to be run each time again.
* Most likely you will have to keep a network per company.
* Debugging will be horrible in those cases where the Rails engine state and 
the Network state gets out of synch.
* And the performance gain is minimal, as the time needed for route 
calculation by far exceeds the required time of creating the network.

> 
> Regarding "suggest vs. enforce":
> Thanks to Stefan for pointing out this pitfall. Actually I had
> envisaged "enforce" (not "suggest") during development. Would it be
> acceptable to introduce the new mode "suggest & enforce" if only some
> aspects are enforced (train purchase) and others not? I ask that
> because the gain of applying the forced train purchase logic for
> displaying a different info message would be not too big (in my
> opinion).

From my point of view I would not add this to Rails 1.x, but in the end this 
is up to you.

Re: [Rails-devel] Push request: Refactored network info (incl. keyboard shortcut and version for end-users)

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

> 
> The message is still a pop-up in the released version. That was
> necessary in order to have a clear trigger when to remove the drawn
> optimal routes (popup close) and potentially to re-draw the routes
> visible before (set revenue step). My original approach was to display
> the optimal routes until the user un-triggers them but then the routes
> would have to be re-calculated after each user action.
> 
> But perhaps you have any idea on that?
> 

Possibly connect clearing the graph to the clearing/updating cycle of the info 
panel of the map window. 

Re: [Rails-devel] Push request: Enforcement of forced train purchases

[Frederick W. <fre...@go...>]

Regarding "a train":
One option to accomodate both Erik's and Stefan's approach would be as
follows: Each 18xx variant has a set of trains that are relevant for
checking routes. For performance reasons, this set should be minimal.
So for 1830 it would be {2} and for 18VA (if it had route-dependent
enforcement) would be {2,1G}. The adapter's route check would be run
with this set.

Regarding "each consumer directly accesses the algorithm package":
Functionally, Stefan has made a valid point. But having performance in
mind, it might be better if network information would not always be
built from the scratch for each kind of check in every consumer. For
example, in SimTex's 1830, network information (both used for UI/AI)
is built/updated after each action. The needed component
("NetworkState") would reside below the game engine consumers and
either be part of the game engine or be placed on top of it. But
perhaps such design is only the target in the longer term.

Regarding "suggest vs. enforce":
Thanks to Stefan for pointing out this pitfall. Actually I had
envisaged "enforce" (not "suggest") during development. Would it be
acceptable to introduce the new mode "suggest & enforce" if only some
aspects are enforced (train purchase) and others not? I ask that
because the gain of applying the forced train purchase logic for
displaying a different info message would be not too big (in my
opinion).

Re: [Rails-devel] Push request: Refactored network info (incl. keyboard shortcut and version for end-users)

[Frederick W. <fre...@go...>]

Thanks for the push.

I totally agree that an overview (or even customization) of the
keyboard accelerators would be needed. Maybe I'll be able to provide
that one day...

The message is still a pop-up in the released version. That was
necessary in order to have a clear trigger when to remove the drawn
optimal routes (popup close) and potentially to re-draw the routes
visible before (set revenue step). My original approach was to display
the optimal routes until the user un-triggers them but then the routes
would have to be re-calculated after each user action.

But perhaps you have any idea on that?

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, January 02, 2012 7:26 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Push request: Enforcement of forced train
> purchases
> 
> Erik:
> running a virtual 2-train for any game is essentially identical to
> 
> > i) Check if there is a route that connects one home token of the
> > company with another scoring node (which is a valid terminate for a
> > train in this
> game).

No, my point is that these two conditions aren't identical in some cases.  
In 18VA, a 2-train would score $0 between Lynchburg and Roanoke (the route
is invalid), whereas a 1G-train would score at least $50.

"A train" is not the same as "a 2-train".

However, this is just a warning from my side, as I'm currently not aware of
any games where it really matters. 

Erik.


> which was the option you preferred.
> 
> However it avoids adding further route finding code (which would be
> essentially code duplication). Or do you have other ideas in mind?
> 
> Stefan
> 
> 
> On Monday, January 02, 2012 01:31:52 pm Erik Vos wrote:
> > > My current favorite for an implementation is to run a virtual
> > > 2-train and
> >
> > check
> >
> > > if it shows non-zero income => Company has a route. That will run
> > > fast, is easy to implement and very close to what players might
> > > usually expect.
> >
> > This
> >
> > > method could/should be implemented inside the algorithm package.
> >
> > Please be aware that in some games a minimal route requires a
> > different train, such as the good trains in 18VA and 1837 (coal
companies).
> > In these cases that doesn't pose a problem because trains are always
> > (18VA) or never (1837 CC) required, but other cases may be different.
> > That's why I'm not too happy with linking route existence to specific
> > trains.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > -----
> > --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> > complex infrastructure or vast IT resources to deliver seamless,
> > secure access to virtual desktops. With this all-in-one solution,
> > easily deploy virtual desktops for less than the cost of PCs and save
> > 60% on VDI infrastructure costs. Try it free!
> > http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
desktops
> for less than the cost of PCs and save 60% on VDI infrastructure costs.
Try it
> free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Push request: Refactored network info (incl. keyboard shortcut and version for end-users)

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

Pushed to master.

Clever idea to use that to close the pending feature request.

However a list of available keyboard commands is needed somewhere, otherwise
most user will never realize it. 

Have not checked so far: Does it show the message in the released version 
inside the info panel or is it still a pop-up, which annoys many users?

Stefan

PS: I suggest to grant Frederick rights to write to the repo, given the 
quality of his patches.


On Friday, December 30, 2011 09:57:25 pm Frederick Weld wrote:
> Feel free to push this into origin/master.
> 
> This patch is independent of the patch for forced train purchases.
> 
> ---Frederick
> 
> ============================
> 
> Added user-friendly network info including keyboard shortcut
> 
> Provided for a non-developer version of the network info menu.
> Differences to the developer-only version (available before):
> - omitting the menu item for the complete network graph
> - providing a localized dialog text for the dialog
> - omitting train run information and train simulation
> 
> Applied further extensions to network info menu (also valid for
> the developer-only version):
> - Keyboard shortcut (Ctrl+N) dynamically assigned to the network info
>   menu item of the currently operating company
> - Network info run visualization takes care of potential conflicts
>   with the visualization of the set revenue step
> - Network info run visualization is turned off after the dialog
> 
> Provided functionality covers the use case described in feature
> request 3064835 (and more).

Re: [Rails-devel] Push request: Correction bundle (Precise token label positioning, initial map image display, 1856 map)

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

Frederick:
First I have to say I like the new zooming options and your new background 
maps. I still have to apologize that I forgot to add a thanks to the latest 
release message (however added you to the Wikipedia changelog).

On the label size:
Regardless of line breaks or not, maybe a simple minimum font size would help.

Currently all other labels (coordinates and/or costs) do not scale at all, 
which has the advantage that even at smaller zooms they stay readable.

if one still wants some scaling even at smaller size is the following: Define 
a threshold size. Below that font size the labels do not scale linearly 
anymore but with an exponential less than one (e.g. square-root).

Stefan


On Monday, January 02, 2012 12:45:31 pm Erik Vos wrote:
> Yes, I also had concluded that a line break (option 3) would be best. But
> that will not simplify calculations...
> In the end, we might still want to have SVG tokens.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Frederick Weld [mailto:fre...@go...]
> > Sent: Monday, January 02, 2012 7:43 AM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Push request: Correction bundle (Precise token
> > label positioning, initial map image display, 1856 map)
> > 
> > I think the discussion could be reduced to the following question:
> > "How would an end-user want the NYNH token to be displayed?"
> > 
> > Possible options I could think of would be:
> > 
> > (1) In a font the height of which matches the token size.
> > = logic prior to the patch
> > --> The label "NYNH" by far exceeds the right bound of the token.
> > 
> > (2) Auto-size the font so that the label always perfectly fits the token
> 
> size.
> 
> > = logic applied in the patch
> > --> The label "NYNH" is too small to be readible (on small resolutions)
> > 
> > (3) Enter line break between NY and NH and applied (2) to the resulting
> 
> label.
> 
> > --> New company attribute ("tokenLabel") to define this
> > 
> > Given a second thought, I think option (3) would be the best option.
> > 
> > To all: What would you prefer (including other options not listed here)?
> 
> ---------------------------------------------------------------------------
> - --
> 
> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> > infrastructure or vast IT resources to deliver seamless, secure access to
> > virtual desktops. With this all-in-one solution, easily deploy virtual
> 
> desktops
> 
> > for less than the cost of PCs and save 60% on VDI infrastructure costs.
> 
> Try it
> 
> > free! http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex infrastructure or vast IT resources to deliver seamless, secure
> access to virtual desktops. With this all-in-one solution, easily deploy
> virtual desktops for less than the cost of PCs and save 60% on VDI
> infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Erik:
running a virtual 2-train for any game is essentially identical to 

> i) Check if there is a route that connects one home token of the company
> with another scoring node (which is a valid terminate for a train in this 
game).

which was the option you preferred.

However it avoids adding further route finding code (which would be 
essentially code duplication). Or do you have other ideas in mind?

Stefan


On Monday, January 02, 2012 01:31:52 pm Erik Vos wrote:
> > My current favorite for an implementation is to run a virtual 2-train and
> 
> check
> 
> > if it shows non-zero income => Company has a route. That will run fast,
> > is easy to implement and very close to what players might usually
> > expect.
> 
> This
> 
> > method could/should be implemented inside the algorithm package.
> 
> Please be aware that in some games a minimal route requires a different
> train, such as the good trains in 18VA and 1837 (coal companies).
> In these cases that doesn't pose a problem because trains are always (18VA)
> or never (1837 CC) required, but other cases may be different.
> That's why I'm not too happy with linking route existence to specific
> trains.
> 
> Erik.
> 
> 
> ---------------------------------------------------------------------------
> --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex infrastructure or vast IT resources to deliver seamless, secure
> access to virtual desktops. With this all-in-one solution, easily deploy
> virtual desktops for less than the cost of PCs and save 60% on VDI
> infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Frederick:
below are my follow-up comments on your patch.
So my proposals are:
* Move main code from OperatingRound to RevenueAdapter. Use a NetworkTrain 
that runs for 2 majors and check if it runs for non-zero revenue.
* Instead of modifying the game engine, change the message in the UI at time 
of train buying depending on that result.
* Keep the modification until "Enforce" RevenueCalculation options are 
available.
Stefan

My main point is that your patch does not comply to the current level of 
enforcement defined by the GameOptions.

Currently RouteCalculation is set to "Suggest",  thus it does not enforce the 
calculated amount (e.g. it does not prevent entering a revenue exceeding it). 

Other Options (planned for future) are:

* "Enforce" - In that level the game engine strictly enforces the rules 
without suggesting anything. Here Rails would calculate the optimal revenue, 
however it would not display the amount, it would only raise an error if a 
player enters revenue exceeding the calculated amount. This allows competitive 
play which might suite sophisticated players.

* "Suggest & Enforce" - This combines suggest and enforce and is optimal for 
novice players.

Your implementation falls into the latter category, as it both strictly 
enforces and indicates in the UI (by enabling/disabling the DONE button) if 
the company has a route or not.

To keep your patch in synch with "Suggest" it should not change the behavior 
of the game engine, but simply have the UI tell the player if or if not 
his/her company has to buy a train or not, depending if the route algorithm 
has found a route or not.

From a technical point of view:
I already stated that I suggest to add something like boolean hasRoute() to 
the RevenueAdapter inside the algorithm package.

So the consumers/clients below interacts with the algorithm package, in that 
sense the game engine is a client of algorithm if it needs that bit of 
information. 

If the UI itself gets the information feeded indirectly via the game engine or 
directly from algorithm is not that important anymore. It even might depend on 
what it is used for. If it is more a hint mechanism ("suggest") directly, if 
("enforce") it is rule enforcement indirectly.



> Regarding rails' layering:
> It would be a valid design decision to keep route awareness out of the
> game engine. But then every consumer of the game engine has to take
> care of becoming route aware on himself. Currently, that's not a big
> deal as there is only one consumer (the UI). But in the longer term,
> there could also be other consumers (RemoteHuman, AI) and, then,
> having put route awareness into the game engine would come in very
> handy.
> 

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

> My current favorite for an implementation is to run a virtual 2-train and
check
> if it shows non-zero income => Company has a route. That will run fast, is
> easy to implement and very close to what players might usually expect.
This
> method could/should be implemented inside the algorithm package.

Please be aware that in some games a minimal route requires a different
train, such as the good trains in 18VA and 1837 (coal companies).
In these cases that doesn't pose a problem because trains are always (18VA)
or never (1837 CC) required, but other cases may be different.
That's why I'm not too happy with linking route existence to specific
trains.

Erik.

[Rails-devel] Rails 2.0 OperationRound Status & other RoundClasses

[<Dr....@t-...>]

Hi Stefan, 

	since i am currently fiddling in 1880 with some of those Classes
(Stock-/Start-/OperatingRound) i would love to know when you expect to
have a useable Class for crosschecks/refactoring the needed additions
for 1880 in rails 2.0. 

	   >> 
 >> Regarding incompatibility with Rails 2.0 (@Stefan):
 >> Which aspect of this patch is incompatible to rails 2.0? Which
 >> adjustment would be necessary in order to avert this?
 >
 >The incompatibility is narrowly defined in the sense that the
commit/patch 
 >cannot be merged automatically with the Rails 2.0 patch:
 >All patches that include a change GameManager or any of the Round
classes  
 >cannot be merged automatically anymore. 
 >
 >It does not mean that it incompatible in a broader sense, it is only
that 
 >someone has to do the merge manually at some time in the future. And
as you 
 >are already implement faster as I can currently comment on, it is
unlikely 
 >that I will be able to that ;-)

 Btw, Happy new Year to ye all.  Regards Martin

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Quick answers first, see below.

On Monday, January 02, 2012 08:14:03 am Frederick Weld wrote:
> Regarding the definition of routes:
> Thanks for pointing out that there are variants that do not require
> forcedly purchsed trains to run (at least 1844). Actually, I started
> with a 2-train route check only to leave this approach when thinking
> of hex trains. The patch could easily be amended to revert back to
> that logic. (But, as Stefan said, the first step would consist of
> clarify this in a discussion.)

My current favorite for an implementation is to run a virtual 2-train
and check if it shows non-zero income => Company has a route. That will run 
fast, is easy to implement and very close to what players might usually 
expect. This method could/should be implemented inside the algorithm package. 

> 
> Regarding rails' layering:
> It would be a valid design decision to keep route awareness out of the
> game engine. But then every consumer of the game engine has to take
> care of becoming route aware on himself. Currently, that's not a big
> deal as there is only one consumer (the UI). But in the longer term,
> there could also be other consumers (RemoteHuman, AI) and, then,
> having put route awareness into the game engine would come in very
> handy.

More on this in a later e-mail.

> 
> Regarding incompatibility with Rails 2.0 (@Stefan):
> Which aspect of this patch is incompatible to rails 2.0? Which
> adjustment would be necessary in order to avert this?

The incompatibility is narrowly defined in the sense that the commit/patch 
cannot be merged automatically with the Rails 2.0 patch:
All patches that include a change GameManager or any of the Round classes  
cannot be merged automatically anymore. 

It does not mean that it incompatible in a broader sense, it is only that 
someone has to do the merge manually at some time in the future. And as you 
are already implement faster as I can currently comment on, it is unlikely 
that I will be able to that ;-)

> 
> ---------------------------------------------------------------------------
> --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex infrastructure or vast IT resources to deliver seamless, secure
> access to virtual desktops. With this all-in-one solution, easily deploy
> virtual desktops for less than the cost of PCs and save 60% on VDI
> infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Push request: Correction bundle (Precise token label positioning, initial map image display, 1856 map)

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

Yes, I also had concluded that a line break (option 3) would be best. But
that will not simplify calculations...
In the end, we might still want to have SVG tokens. 

Erik.

> -----Original Message-----
> From: Frederick Weld [mailto:fre...@go...]
> Sent: Monday, January 02, 2012 7:43 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Push request: Correction bundle (Precise token
> label positioning, initial map image display, 1856 map)
> 
> I think the discussion could be reduced to the following question:
> "How would an end-user want the NYNH token to be displayed?"
> 
> Possible options I could think of would be:
> 
> (1) In a font the height of which matches the token size.
> = logic prior to the patch
> --> The label "NYNH" by far exceeds the right bound of the token.
> 
> (2) Auto-size the font so that the label always perfectly fits the token
size.
> = logic applied in the patch
> --> The label "NYNH" is too small to be readible (on small resolutions)
> 
> (3) Enter line break between NY and NH and applied (2) to the resulting
label.
> --> New company attribute ("tokenLabel") to define this
> 
> Given a second thought, I think option (3) would be the best option.
> 
> To all: What would you prefer (including other options not listed here)?
> 
>
----------------------------------------------------------------------------
--
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
desktops
> for less than the cost of PCs and save 60% on VDI infrastructure costs.
Try it
> free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Push request: Enforcement of forced train purchases

[Frederick W. <fre...@go...>]

Regarding the definition of routes:
Thanks for pointing out that there are variants that do not require
forcedly purchsed trains to run (at least 1844). Actually, I started
with a 2-train route check only to leave this approach when thinking
of hex trains. The patch could easily be amended to revert back to
that logic. (But, as Stefan said, the first step would consist of
clarify this in a discussion.)

Regarding rails' layering:
It would be a valid design decision to keep route awareness out of the
game engine. But then every consumer of the game engine has to take
care of becoming route aware on himself. Currently, that's not a big
deal as there is only one consumer (the UI). But in the longer term,
there could also be other consumers (RemoteHuman, AI) and, then,
having put route awareness into the game engine would come in very
handy.

Regarding incompatibility with Rails 2.0 (@Stefan):
Which aspect of this patch is incompatible to rails 2.0? Which
adjustment would be necessary in order to avert this?

Re: [Rails-devel] Push request: Correction bundle (Precise token label positioning, initial map image display, 1856 map)

[Frederick W. <fre...@go...>]

I think the discussion could be reduced to the following question:
"How would an end-user want the NYNH token to be displayed?"

Possible options I could think of would be:

(1) In a font the height of which matches the token size.
= logic prior to the patch
--> The label "NYNH" by far exceeds the right bound of the token.

(2) Auto-size the font so that the label always perfectly fits the token size.
= logic applied in the patch
--> The label "NYNH" is too small to be readible (on small resolutions)

(3) Enter line break between NY and NH and applied (2) to the resulting label.
--> New company attribute ("tokenLabel") to define this

Given a second thought, I think option (3) would be the best option.

To all: What would you prefer (including other options not listed here)?

Re: [Rails-devel] Push request: Correction bundle (Precise token label positioning, initial map image display, 1856 map)

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

On Sun, Jan 1, 2012 at 5:59 PM, Erik Vos <eri...@xs...> wrote:
>> > commit 9fe97ef2fa38cf5d7c6d43c1916a0ceb0541034b
>> >
>> >    Added precise sizing and positioning of token labels
>> >
>> >    Introduced a generic logic that provides for precise
>> > sizing/positioning
>> >    for any label text length and zoom factor.
>> >
>> >    Replaces prior heuristic that, among others, placed labels partly
>> >    outside of the tokens.
>> >
>> > --> See Erik's description of the prior state:
>> > https://sourceforge.net/mailarchive/message.php?msg_id=28555719
>
> Now that I have seen the result, I'm not too happy about it.  The token labels fit inside the circles indeed, but readability has suffered a bit too much for my taste.
> For instance, the 1830 NYNH and 1856 BBG tokens are now hardly readable (for me) at normal scale.
> It's fine for me to have to rely on the colours only, but that's not true for everybody, as we have recently discussed.
>
> I'm not proposing to revert this commit, but I don't consider it a final solution either.
>
> Erik.
>

That's about what I expected.

IMO, the calculation being performed has improved, but now we'll need
to figure out a sensible default value for the scaling.

---Brett.

Re: [Rails-devel] Push request: Correction bundle (Precise token label positioning, initial map image display, 1856 map)

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

> > commit 9fe97ef2fa38cf5d7c6d43c1916a0ceb0541034b
> >
> >    Added precise sizing and positioning of token labels
> >
> >    Introduced a generic logic that provides for precise
> > sizing/positioning
> >    for any label text length and zoom factor.
> >
> >    Replaces prior heuristic that, among others, placed labels partly
> >    outside of the tokens.
> >
> > --> See Erik's description of the prior state:
> > https://sourceforge.net/mailarchive/message.php?msg_id=28555719

Now that I have seen the result, I'm not too happy about it.  The token labels fit inside the circles indeed, but readability has suffered a bit too much for my taste.
For instance, the 1830 NYNH and 1856 BBG tokens are now hardly readable (for me) at normal scale.
It's fine for me to have to rely on the colours only, but that's not true for everybody, as we have recently discussed.

I'm not proposing to revert this commit, but I don't consider it a final solution either.

Erik.

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

> i) Check if there is a route that connects one home token of the company
> with another scoring node (which is a valid terminate for a train in this game).
> 
> or
> 
> ii) Check if one would run the available train for purchase this train generates
> non-zero revenue on the existing network of that company.
> 
> Frederick has chosen the ii) and I used to intend to use the same approach,
> however my mind changed after reading some of the rules where the
> differences might matter. I would now suggest to check condition i) instead.
> 
> Other opinions here?

Intuitively, I would choose option i) as well,  if only to keeps things simple.

Erik.

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Frederick and others interested:

again thanks for your patch: However I would not apply it as it  for two main 
reasons. I have split my mail into two, because one targets
the question of rules and how to implement them and the next one which 
discusses in which layer of Rails it should be implemented and what the user
experience should be.

First I have to state that (at least from my point of view) there are the two 
possible implementations to check if a company has to purchase a train (for 
those games which require a valid route):

i) Check if there is a route that connects one home token of the company with 
another scoring node (which is a valid terminate for a train in this game).

or 

ii) Check if one would run the available train for purchase this train 
generates non-zero revenue on the existing network of that company.

Frederick has chosen the ii) and I used to intend to use the same approach, 
however my mind changed after reading some of the rules where the differences 
might matter. I would now suggest to check condition i) instead.

Other opinions here?

Stefan

Detailed discussion:

What is the definition of a "route"?

I had a few checks on those games that require a route according the rules 
difference list (http://www.fwtwr.com/18xx/rules_difference_list/9_2.htm), it 
seems that most agree that a valid route exists of two "scoring nodes" (be it 
cities, towns, off-board areas).

1830(AH) for example defines it pretty clear in the first sentence of 20.1:
"A route is a length of track joining 2 or more cities." (Cities in 1830 rules 
include towns (small cities) and off-board areas).

However in 20.2  it states "Any Corporation which is operating must have at 
least one train during its turn of an Operating Round unless there is no route 
available on which it could possibly run."

Re: [Rails-devel] Push request: Correction bundle (Precise token label positioning, initial map image display, 1856 map)

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

Patches applied to master.

---Brett.



On Sun, Jan 1, 2012 at 4:57 AM, Frederick Weld
<fre...@go...> wrote:
> Feel free to push this into origin/master.
>
> This patch is independent of the patches for forced train purchases
> and network info.
>
> ---Frederick
>
> commit 9fe97ef2fa38cf5d7c6d43c1916a0ceb0541034b
>
>    Added precise sizing and positioning of token labels
>
>    Introduced a generic logic that provides for precise sizing/positioning
>    for any label text length and zoom factor.
>
>    Replaces prior heuristic that, among others, placed labels partly
>    outside of the tokens.
>
> --> See Erik's description of the prior state:
> https://sourceforge.net/mailarchive/message.php?msg_id=28555719
>
> commit b41262c12a86ef75045d0a8e1edfa0b0a4983be3
>
>    Fixed 1856 background map's mini-map (Windsor area)
>
> commit d7e7993a920c1d275d87b4e80fac0652f9e678fd
>
>    Fixed the glitch of initially displaying map images in the wrong scale
>
>    Glitch description:
>    If the scale factor of the background map image differs from 1, the
>    map is initially displayed in the wrong scale for a second before
>    resizing eventually corrects this (especially applies to 1856/1889
>    background images as their scale is lower than 0.2).
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Push request: Correction bundle (Precise token label positioning, initial map image display, 1856 map)

[Frederick W. <fre...@go...>]

Feel free to push this into origin/master.

This patch is independent of the patches for forced train purchases
and network info.

---Frederick

commit 9fe97ef2fa38cf5d7c6d43c1916a0ceb0541034b

    Added precise sizing and positioning of token labels

    Introduced a generic logic that provides for precise sizing/positioning
    for any label text length and zoom factor.

    Replaces prior heuristic that, among others, placed labels partly
    outside of the tokens.

--> See Erik's description of the prior state:
https://sourceforge.net/mailarchive/message.php?msg_id=28555719

commit b41262c12a86ef75045d0a8e1edfa0b0a4983be3

    Fixed 1856 background map's mini-map (Windsor area)

commit d7e7993a920c1d275d87b4e80fac0652f9e678fd

    Fixed the glitch of initially displaying map images in the wrong scale

    Glitch description:
    If the scale factor of the background map image differs from 1, the
    map is initially displayed in the wrong scale for a second before
    resizing eventually corrects this (especially applies to 1856/1889
    background images as their scale is lower than 0.2).

[Rails-devel] Push request: Refactored network info (incl. keyboard shortcut and version for end-users)

[Frederick W. <fre...@go...>]

Feel free to push this into origin/master.

This patch is independent of the patch for forced train purchases.

---Frederick

============================

Added user-friendly network info including keyboard shortcut

Provided for a non-developer version of the network info menu.
Differences to the developer-only version (available before):
- omitting the menu item for the complete network graph
- providing a localized dialog text for the dialog
- omitting train run information and train simulation

Applied further extensions to network info menu (also valid for
the developer-only version):
- Keyboard shortcut (Ctrl+N) dynamically assigned to the network info
  menu item of the currently operating company
- Network info run visualization takes care of potential conflicts
  with the visualization of the set revenue step
- Network info run visualization is turned off after the dialog

Provided functionality covers the use case described in feature
request 3064835 (and more).

Re: [Rails-devel] Push request: Enforcement of forced train purchases

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

Erik & Frederick,
I half a 75% finished reply in my draft folder after reviewing the patch.
There is no technical reason to hold the patch (I like both the implementation and
the documentation), however there are two issues
which I believe should be considered: Even if I agree with Fredericks rule interpretation of
"having a route" I am sure that there will be other interpretations (especially if one generalizes
to all possible games and trains) and I would prefer to see a discussion at least on this list,
but it is even more likely that it should end up on the yahoo list.
>From a design point of view I agree with Eriks point of view that it should stay outside of the game engine,
however for different reasons... But here my opinion is not that important as the patch will not
make  into Rails 2.0 anyway.
So please be patient for more details.
Stefan



-----Ursprüngliche Nachricht-----
Von: "Frederick Weld" <fre...@go...>
Gesendet: Dec 30, 2011 11:17:21 AM
An: "Development list for Rails: an 18xx game" <rai...@li...>
Betreff: Re: [Rails-devel] Push request: Enforcement of forced train purchases

You are right that parts of the route calculation might be performed
twice. However:

(1) This only occurs if all other necessary conditions for forced
train purchases apply (see lazy route calculation in
OperatingRound.isForcedTrainPurchase).

(2) Even then, this duplication only applies to the initialization of
the network graph, as the second route determination is parameterized
differently with respect to trains (publicly available train types vs.
company owned ones (=zero) for triggering by the UI layer).

For the target design, I fully agree with you. The tricky part would
consist of avoiding duplication during graph construction and route
calculation, given that each OR-step is potentially based on a
different graph (eg., lay tile changes graph for lay token) and works
with different train sets (set revenue vs. forced train purchase).

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel