rails-devel — List for discussion of Rails development

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

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

A round-off to the fit-to-xyz zoom functionality is now available in master.

The current logic of discrete zoom steps is still valid - but it is
complemented by a continuous adjustment factor ("last mile
adjustment").

In addition, the appearance and width of the scroll bar is now considered.

Re: [Rails-devel] UTF-8 characters for japanese city names in 1889 (was: Push request: Refactored network info (incl. keyboard shortcut and version for end-users))

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

> I suggest making displaying locale city or other names a game option
> "displayLocaleNames" and provide a new attribute as localeName (or is
> localName the correct spelling?) inside map.xml.

Very good proposal.

But I'll refrain from changing anything within rails.game until the
switch to rails 2.0 in order to avert merging issue - and local name
would be an attribute within the model.

==> I changed the encoding to UTF-8 (patch attached).
@Stefan: Would you mind to verify kanji visibility and push it if it's ok now?

Re: [Rails-devel] UTF-8 characters for japanese city names in 1889 (was: Push request: Refactored network info (incl. keyboard shortcut and version for end-users))

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

On Monday, January 09, 2012 01:32:25 pm Frederick Weld wrote:
> Regarding the use case:
> I would really like the kanji to be displayed in the tooltips, as the
> background map's labels will be covered by upgrading tiles - and,
> thus, are not available any more.

I suggest making displaying locale city or other names a game option 
"displayLocaleNames" and provide a new attribute as localeName (or is 
localName the correct spelling?) inside map.xml.

This would then allow to add German city names to 1835 and localized version 
in 18EU. This could possibly extended to company names later.

I fear that the knowledge of kanji is not so widespread as you might assume 
;-). 
I have to admit that I got stuck after learning Hiraganas and Katakanas and a 
number of kanjis which could be easily counted using my own hands.

> 
> Regarding the realization:
> So I should use real UTF chars in the map.xml (instead of html
> escapes)? If yes, I could provide for that - but hopefully no one will
> edit the map.xml using an ansi editor...

I think there is at least some hope that no one will be given commit rights to 
the repo who starts editing those files with an ANSI editor :-)

Stefan

Re: [Rails-devel] UTF-8 characters for japanese city names in 1889 (was: Push request: Refactored network info (incl. keyboard shortcut and version for end-users))

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

Regarding the use case:
I would really like the kanji to be displayed in the tooltips, as the
background map's labels will be covered by upgrading tiles - and,
thus, are not available any more.

Regarding the realization:
So I should use real UTF chars in the map.xml (instead of html
escapes)? If yes, I could provide for that - but hopefully no one will
edit the map.xml using an ansi editor...

Re: [Rails-devel] Push request: HexMap speed-up and highlighting

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

I assume it will not be too difficult, but it might not merge automatically.
As stated I refactor the Model classes, so there are a few syntactical changes 
in the UI classes, that are observers of the Model objects.

As the UI classes themselves are not very atomic, merges can easily get 
difficult (especially if you did some white-space changes and/or addition of 
comments too).

Stefan

On Monday, January 09, 2012 12:45:49 pm Frederick Weld wrote:
> > I hope it will not be too difficult to merge into the 2.0 branch.
> 
> The scope of the patches is ui/swing-only.
> Hence, no issue is to be expected during merge. (given the scope of
> rails 2.0's refactoring is restricted to the games engine - or do you
> plan to adjust the engine's consumers?)
> 
> ---------------------------------------------------------------------------
> --- 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] UTF-8 characters for japanese city names in 1889 (was: Push request: Refactored network info (incl. keyboard shortcut and version for end-users))

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

Frederick,
sorry I thought (again) that those are html-only escapes, instead of the html 
unicode escapes.

So you are right that the fonts used for tooltips on my system does not 
support japanese characters. Unfortunately there is no general solution
for this problem using Java (compare 
http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp#cjk-font-
problem)
Therefore I suggest to remove the Japanese characters from the tooltips, I 
believe that for most players having them on the background map is enough.

In general:
We had this discussion before and I am a supporter of using true/full UTF-8 
support instead of UFT-8 escaping, as there is no standard way of escaping
(compare e.g. http://billposer.org/Software/ListOfRepresentations.html).

Using your escapes implies that the city names can only be used inside a html 
body, as the Java escape rules differ. Using true UTF-8 characters avoids that 
problem.

Interestingly the svg-file for the background map you supplied for 1889 
contains the city names as true UTF-8 characters.

But I know that other opinions differ.

Stefan


> 
> I used escapes in the Map.xml in order to avert any ANSI/UTF issue. If
> no characters are displayed, that would be caused by some missing
> fonts. The tooltips are correctly displayed on my machine.
> 

Re: [Rails-devel] Push request: HexMap speed-up and highlighting

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

> I hope it will not be too difficult to merge into the 2.0 branch.

The scope of the patches is ui/swing-only.
Hence, no issue is to be expected during merge. (given the scope of
rails 2.0's refactoring is restricted to the games engine - or do you
plan to adjust the engine's consumers?)

Re: [Rails-devel] Push request: HexMap speed-up and highlighting

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

Frederick:
excellent patch that improves UI handling a lot.
I hope it will not be too difficult to merge into the 2.0 branch.
Stefan


On Saturday, January 07, 2012 07:45:25 pm Frederick Weld wrote:
> Would you please git push this to origin/master?
> 
> (patches extracted after local branch rebase on Erik's last changes)
> 
> Originally, I just aimed at adding some interactivity to the hex map
> (highlighting for mouseovers and more - details see below). But it
> turned out that rails' response times would not support that
> (especially if no background map was used).
> 
> Therefore, the attached series of patches also includes a complete
> refactoring of the hex map. The key point here is that each layer
> (tiles, routes, etc.) has its own off-screen buffer into which it
> exclusively draws and that paintComponent copies these buffers 1:1
> except if there were really some changes on the layer (this is
> supported by an invalidation mechanism).
> 
> As a result, the performance / responsiveness of the hex map has
> vastly improved.
> 
> ===================
> 
> commit 008edc0b9be69fcd66918d533a1a02f6fff5a63c
> 
>     Added highlighting of private companies' hexes triggered by mouse-over
> 
>     Triggers have been installed on the labels of private companies that
>     are displayed on the start round auction, the OR panel (including
>     the menu), and the game status.
> 
> commit aa6bde64d2d0502a5aac79c11ed533dd1c06da3b
> 
>     Added off-screen image buffers for hexMap layers and invalidation logic
> 
>     Vastly improved performance of painting the hex map by the following.
> 
>     Defined layers according to the prior drawing order of hexmap's
>     paintComponent (tiles, routes, markings, tokens and texts). HexMap
>     manages these layers is no JComponent any more.
>     Each layer:
>     - is a JComponent and has its z order in MapPanel,
>     - only draws its content if it has been changed,
>     - only draws into its own permanent off-screen drawing buffer,
>     - copies drawing buffer to MapPanel for making its contents visible.
> 
>     Supported this by introducing a new invalidation logic
>     (eg., repaintTiles) that:
>     - indicates to the affected layer which portions are to be re-drawn,
>     - averts redraw of inaffected layers
>     - is triggered by the hexmap or GUIHex whenever possible
>       (no need for triggering by consumers ORPanel, ORUIManager, etc.)
> 
> commit 4a74fcc8fc7dfaecd87e1644feb9945d10287ad3
> 
>     Added config option for highlighting and public company highlighting
> 
>     Introduced highlighting for public/minor companies, displaying
>     their home/destination hexes.
> 
>     Added config option for highlighting within the map tab. It applies
>     to all triggers (ORPanel and StatusWindow) except for the menu items
>     (for which highlighting will always take place).
> 
>     Fixed an issue with highlighting privates of portfolios. Now,
>     portfolios are evaluated not during registration but during the mouse
>     over event.
> 
> commit eea148a1e256b41e66c92471e40aa628fd1fce1d
> 
>     Enabled company network info upon click on company captions
> 
>     If the caption of a company (both in ORPanel and StatusWindow) is
>     clicked, its network info is displayed as if the corresponding
>     network info menu item had been clicked.
> 
> commit a63b9f693300fb1aa2edb66ac1f9f74832dbd048
> 
>     Added hex highlighting on mouse position and fixed tooltips
> 
>     Added a new layer on top-most z-order for tool tips. By this means,
>     tool tips are available again (they were not displayed any more after
>     having introduced layered off-screen buffers).
> 
>     Provided for highlighting of the hex under the mouse pointer.
> 
> commit 684a6125513c1e935b3cba1dd64a1b92d3c7b22c
> 
>     Added dirty region handling for hexmap's routes layer
> 
>     Changes to the train routes do not lead to a redraw of the complete
>     layered pane any more. This has been achieved by adding logic for
>     determining the region affected by train route changes.
> 
>     Apart from further performance gains, this also fixes prior issue that
>     routes were not correctly refreshed.
> 
> commit 1a5972f9c38b951a63bd333aadf328963c2b697b
> 
>     Added handling of concurrent hex map paints
> 
>     The key blocks / methods are now synchronized on the hex map (acting
>     as the monitor). This became necessary after observing very rare
>     paintComponent calls with invalid clip rectangles (out of JComponent
>     bounds), leading to out-of-bounds paints of the background map.
> 
>     After this addition, no further occurrence of this symptom could be
>     observed.

Re: [Rails-devel] Autosave handling (was: Push request: 2 minor bug fixes (autosave handling and defaulting of game options))

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

And another answer to an older mail, refer to the bottom of the mail.

On Tuesday, December 27, 2011 07:59:30 pm Frederick Weld wrote:
> 
>     Fixed autosave functionality (handling of 18xx_autosave.xxx files)
> 
>     Target design is that
>     (1) new temp file (.tmp) is created
>     (2) former autosave (.rails) becomes the backup autosave (.rails.bak)
>     (3) temp file (.tmp) becomes the new autosave (.rails)
> 
>     Prior to the fix, the implementation did not process step (2)
> correctly, as backup autosaves were never dropped. This meant that
> autosave resulted in an error message and three files in the autosave
> folder (.tmp , .rails , .rails.bak). That's why autosave had never worked
> for me (and I doubt that it could have worked for others).

Thanks for fixing this. Autosave did work until (my own) refactoring of the 
save file processing, where I missed that bit. As it got not much love from 
the others (mostly because ftf-plays with Rails are the exception) I did not 
test that as I should have.

Stefan

Re: [Rails-devel] Game Options defaults (was: Push request: 2 minor bug fixes (autosave handling and defaulting of game options))

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

Answering an older mail: see answer at the bottom.

On Tuesday, December 27, 2011 09:50:31 pm Erik Vos wrote:
> > From: Frederick Weld [mailto:fre...@go...]
> > 
> >     Fixed retrieval of default game options (if options pane was not
> 
> opened)
> 
> >     Game options have to be read from GamesList.xml and not from the
> >     respective game's Games.xml GameOption tags.
> >     Before the fix, this was not the case if the options pane had not
> >     been opened (which is the moment at which the GamesList's default
> >     options were loaded).
> >     
> >     This fix also solves Bug 3448429, as the reported missing 18EU route
> >     calculation was due to inconsistent defaulting between GamesList
> >     (default=suggest) and Games (default=deactivate). Now, the defaults
> >     are always taken from GamesList.
> 
> I vaguely remember that Stefan had a good reason why it was implemented
> with different defaults.
> Or was that only for backward compatibility at some point?
> 
> Erik.

Yes there is a valid distinction between those too and there is a use case for 
the difference:

The GameList.xml "default" defines the attributes at the GameStart (thus it is 
the default option shown in the start UI).

The Game.xml "default"  is/was ONLY used if the option is not defined in a 
Rails save file: Thus for those cases where a save file was saved with a 
previous Rails version which do not feature that option.

The use case is now for those options which have a default defined which is 
incompatible to the behavior defined (implicitly) in the previous Rails 
version: There have been several examples, one is the revenue calculation 
(which is a default for new games, but not automatically turned on for 
existing games) and all those options which made Rails enforcing stricter 
rules (or add automatic passes) which might have broke previous save files.

I did not implement that part of Rails and my guess was that this was not 
really intended: It seems that this behavior got forgotten during the 
refactoring of the xml parsing.

I always intended to merge the two lists and instead use attribute 
default="...." always and undefined="..." only for those cases where there is 
a reason to deviate. But that could/should wait until Rails 2.0

Stefan

Re: [Rails-devel] Push request: HexMap speed-up and highlighting

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

Applied and pushed.

This looks really great. Thanks!

---Brett.



On Sat, Jan 7, 2012 at 1:45 PM, Frederick Weld
<fre...@go...> wrote:
> Would you please git push this to origin/master?
>
> (patches extracted after local branch rebase on Erik's last changes)
>
> Originally, I just aimed at adding some interactivity to the hex map
> (highlighting for mouseovers and more - details see below). But it
> turned out that rails' response times would not support that
> (especially if no background map was used).
>
> Therefore, the attached series of patches also includes a complete
> refactoring of the hex map. The key point here is that each layer
> (tiles, routes, etc.) has its own off-screen buffer into which it
> exclusively draws and that paintComponent copies these buffers 1:1
> except if there were really some changes on the layer (this is
> supported by an invalidation mechanism).
>
> As a result, the performance / responsiveness of the hex map has
> vastly improved.
>
> ===================
>
> commit 008edc0b9be69fcd66918d533a1a02f6fff5a63c
>
>    Added highlighting of private companies' hexes triggered by mouse-over
>
>    Triggers have been installed on the labels of private companies that
>    are displayed on the start round auction, the OR panel (including
>    the menu), and the game status.
>
> commit aa6bde64d2d0502a5aac79c11ed533dd1c06da3b
>
>    Added off-screen image buffers for hexMap layers and invalidation logic
>
>    Vastly improved performance of painting the hex map by the following.
>
>    Defined layers according to the prior drawing order of hexmap's
>    paintComponent (tiles, routes, markings, tokens and texts). HexMap
>    manages these layers is no JComponent any more.
>    Each layer:
>    - is a JComponent and has its z order in MapPanel,
>    - only draws its content if it has been changed,
>    - only draws into its own permanent off-screen drawing buffer,
>    - copies drawing buffer to MapPanel for making its contents visible.
>
>    Supported this by introducing a new invalidation logic
>    (eg., repaintTiles) that:
>    - indicates to the affected layer which portions are to be re-drawn,
>    - averts redraw of inaffected layers
>    - is triggered by the hexmap or GUIHex whenever possible
>      (no need for triggering by consumers ORPanel, ORUIManager, etc.)
>
> commit 4a74fcc8fc7dfaecd87e1644feb9945d10287ad3
>
>    Added config option for highlighting and public company highlighting
>
>    Introduced highlighting for public/minor companies, displaying
>    their home/destination hexes.
>
>    Added config option for highlighting within the map tab. It applies
>    to all triggers (ORPanel and StatusWindow) except for the menu items
>    (for which highlighting will always take place).
>
>    Fixed an issue with highlighting privates of portfolios. Now,
>    portfolios are evaluated not during registration but during the mouse
>    over event.
>
> commit eea148a1e256b41e66c92471e40aa628fd1fce1d
>
>    Enabled company network info upon click on company captions
>
>    If the caption of a company (both in ORPanel and StatusWindow) is
>    clicked, its network info is displayed as if the corresponding
>    network info menu item had been clicked.
>
> commit a63b9f693300fb1aa2edb66ac1f9f74832dbd048
>
>    Added hex highlighting on mouse position and fixed tooltips
>
>    Added a new layer on top-most z-order for tool tips. By this means,
>    tool tips are available again (they were not displayed any more after
>    having introduced layered off-screen buffers).
>
>    Provided for highlighting of the hex under the mouse pointer.
>
> commit 684a6125513c1e935b3cba1dd64a1b92d3c7b22c
>
>    Added dirty region handling for hexmap's routes layer
>
>    Changes to the train routes do not lead to a redraw of the complete
>    layered pane any more. This has been achieved by adding logic for
>    determining the region affected by train route changes.
>
>    Apart from further performance gains, this also fixes prior issue that
>    routes were not correctly refreshed.
>
> commit 1a5972f9c38b951a63bd333aadf328963c2b697b
>
>    Added handling of concurrent hex map paints
>
>    The key blocks / methods are now synchronized on the hex map (acting
>    as the monitor). This became necessary after observing very rare
>    paintComponent calls with invalid clip rectangles (out of JComponent
>    bounds), leading to out-of-bounds paints of the background map.
>
>    After this addition, no further occurrence of this symptom could be
>    observed.
>
> ------------------------------------------------------------------------------
> 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: HexMap speed-up and highlighting

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

Would you please git push this to origin/master?

(patches extracted after local branch rebase on Erik's last changes)

Originally, I just aimed at adding some interactivity to the hex map
(highlighting for mouseovers and more - details see below). But it
turned out that rails' response times would not support that
(especially if no background map was used).

Therefore, the attached series of patches also includes a complete
refactoring of the hex map. The key point here is that each layer
(tiles, routes, etc.) has its own off-screen buffer into which it
exclusively draws and that paintComponent copies these buffers 1:1
except if there were really some changes on the layer (this is
supported by an invalidation mechanism).

As a result, the performance / responsiveness of the hex map has
vastly improved.

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

commit 008edc0b9be69fcd66918d533a1a02f6fff5a63c

    Added highlighting of private companies' hexes triggered by mouse-over

    Triggers have been installed on the labels of private companies that
    are displayed on the start round auction, the OR panel (including
    the menu), and the game status.

commit aa6bde64d2d0502a5aac79c11ed533dd1c06da3b

    Added off-screen image buffers for hexMap layers and invalidation logic

    Vastly improved performance of painting the hex map by the following.

    Defined layers according to the prior drawing order of hexmap's
    paintComponent (tiles, routes, markings, tokens and texts). HexMap
    manages these layers is no JComponent any more.
    Each layer:
    - is a JComponent and has its z order in MapPanel,
    - only draws its content if it has been changed,
    - only draws into its own permanent off-screen drawing buffer,
    - copies drawing buffer to MapPanel for making its contents visible.

    Supported this by introducing a new invalidation logic
    (eg., repaintTiles) that:
    - indicates to the affected layer which portions are to be re-drawn,
    - averts redraw of inaffected layers
    - is triggered by the hexmap or GUIHex whenever possible
      (no need for triggering by consumers ORPanel, ORUIManager, etc.)

commit 4a74fcc8fc7dfaecd87e1644feb9945d10287ad3

    Added config option for highlighting and public company highlighting

    Introduced highlighting for public/minor companies, displaying
    their home/destination hexes.

    Added config option for highlighting within the map tab. It applies
    to all triggers (ORPanel and StatusWindow) except for the menu items
    (for which highlighting will always take place).

    Fixed an issue with highlighting privates of portfolios. Now,
    portfolios are evaluated not during registration but during the mouse
    over event.

commit eea148a1e256b41e66c92471e40aa628fd1fce1d

    Enabled company network info upon click on company captions

    If the caption of a company (both in ORPanel and StatusWindow) is
    clicked, its network info is displayed as if the corresponding
    network info menu item had been clicked.

commit a63b9f693300fb1aa2edb66ac1f9f74832dbd048

    Added hex highlighting on mouse position and fixed tooltips

    Added a new layer on top-most z-order for tool tips. By this means,
    tool tips are available again (they were not displayed any more after
    having introduced layered off-screen buffers).

    Provided for highlighting of the hex under the mouse pointer.

commit 684a6125513c1e935b3cba1dd64a1b92d3c7b22c

    Added dirty region handling for hexmap's routes layer

    Changes to the train routes do not lead to a redraw of the complete
    layered pane any more. This has been achieved by adding logic for
    determining the region affected by train route changes.

    Apart from further performance gains, this also fixes prior issue that
    routes were not correctly refreshed.

commit 1a5972f9c38b951a63bd333aadf328963c2b697b

    Added handling of concurrent hex map paints

    The key blocks / methods are now synchronized on the hex map (acting
    as the monitor). This became necessary after observing very rare
    paintComponent calls with invalid clip rectangles (out of JComponent
    bounds), leading to out-of-bounds paints of the background map.

    After this addition, no further occurrence of this symptom could be
    observed.

[Rails-devel] Forced selling and saved file editing

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

I have pushed two commits:

1. During testing modal popups, I discovered that any required immediate
selling of over-limit shares in stock rounds was announced but not enforced.
I'm not sure if that has been always so; I thought it once worked correctly.
But in any case, it does work now. Checking, announcing and enforcing has
been integrated in the pre-validation step (setSellableShares()).  Existing
double or even triple calls to the over-limit message creation method are
now avoided.  A separate over-limit check method still exists to enable
resetting autopasses at the right time.  

2. The ListAndFixSavedFiles tool has been extended to allow detailed
correction of user actions.  So far, only BuyTrain and LayTile have been
included. I needed that to fix some interesting but old saved files for
testing purposes.

I'm so far only considering to correct client (user) settings.  Server
(game-engine) settings could be added, but I see no need for that yet.
The above class contains specific dialogs per action class type, all as
inner classes. A framework has been included to make adding new action
classes as easy as possible.
The dialogs don't look very pretty yet, but I think I can leave that as an
exercise for others.

Erik.

[Rails-devel] Start round non-modal popup

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

In my long-running project to turn all (relevant) modal popups in non-modal
ones, I have now converted the request for initial share prices in start
rounds.
This affects, for instance, requesting the B&O par price in 1830.

The popup layout is now similar to the corresponding request in stock
rounds, using a list of radio buttons instead of a dropdown.

Erik.

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

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

> as long as Rails only support a "Suggest" option for routes, the
> communication and mechanisms between the UI and the game engine could
> and should be kept unchanged. The UI would present the most likely correct
> default, however the user can still decided to deviate.
> 
> I have not implemented that part of Rails, thus Erik could possibly add
more
> how the user decision feeds back to the game engine. 

Always via PossibleAction object, in this case SetDividend, which also
includes the chosen (or predefined) revenue allocation: withhold, split or
payout.

Obviously, with "Enforce" the game engine could/should validate and possibly
reject the revenue amount. 

Erik.

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

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

Currently (origin/master), the game engine enforces that the president
may only add cash if he has no train and his company is tagged with
<train... mandatory="yes"> (which represents a necessary condition for
forced train purchases).

Given your answer, the goal would be to omit this enforcement.

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

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

See comments below.

> My guess is that allowing the Scale parameter to be continuous would have no
> obvious negative effect.

Current logic is to have a buffer of 20 zoom factors (associated with
the 20 zoom steps). But probably no big issue to refactor this.

> One guess is
> that you might not use the size of the ViewPort of the Scrollpane embedding
> the map?

This could do the trick. Currently, available size is taken from the MapPanel.

> Another observation: The toolips does not show the japanese characters (only
> rectangle dummies instead). So it seems there is an UFT-8 issue again.

I used escapes in the Map.xml in order to avert any ANSI/UTF issue. If
no characters are displayed, that would be caused by some missing
fonts. The tooltips are correctly displayed on my machine.

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

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

Frederick:
as long as Rails only support a "Suggest" option for routes, the communication 
and mechanisms between the UI and the game engine could and should be kept 
unchanged. The UI would present the most likely correct default, however the 
user can still decided to deviate.

I have not implemented that part of Rails, thus Erik could possibly add more 
how the user decision feeds back to the game engine. But if I remember 
correctly the user is simply always able to add own cash currently. Like for a 
real ftf game the user has to refrain from such an illegal action.

Only for an "Enforce" option this question is relevant for the game engine, as 
for the all other use cases.

Stefan


On Tuesday, January 03, 2012 02:40:19 pm Frederick Weld wrote:
> Another related aspect is as follows:
> 
> Currently, parts of the game engine (OperatingRound and
> action.BuyTrain) are conceived in such a way that they need to know
> whether the company is forced to buy a train (since only then the
> president is allowed to add his cash).
> If the game engine was held unaware of routes, it would also be unable
> to determine the possible actions of buy train.
> 
> What would be the design to cope with this situation?
> 
> Should the game engine consumer filter out all those actions that
> necessite president cash for BuyTrain, in case the train purchase was
> not forced?
> 
> ---------------------------------------------------------------------------
> --- Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> 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...>]

See comments below.

On Thursday, January 05, 2012 12:32:20 pm Frederick Weld wrote:
> Thanks again for pushing.
> 
> > * After KU buys a 2 train the error in the route calculation prevents the
> > Done from getting activated, this makes continuing the game impossible.
> 
> This should not be the case any more after applying 0003 - as all
> route calculations now take place in another thread. Are you sure that
> 0003 had been applied when making these observations?

Sorry my mistake:
Patch has been applied, however Eclipse did not build afterwards, regardless 
of my setting AutomaticBuild. It seems that Eclipse does not recognize 
external git am command, however it does for an external git pull.

> 
> > * "Fit to width" sometimes sets the zoom scale a little to large, so that
> > the horizontal scrollbar still remains active.
> > * "Fit to height" often sets the zoom scale such that a large unused
> > border at the bottom remains.
> 
> The algorithm of "Fit to xyz" selects the maximum possible zoom step
> for which the map is expected to be within the bounds.
> 
> - Zoom steps are designed to be discrete, hence leading to your
> observation ("fit to height"). I avoided refactoring for continuous
> zoom levels in order to be able to maintain current zoom in/out logic.

My guess is that allowing the Scale parameter to be continuous would have no 
obvious negative effect. 

> - For evaluating expected map sizes, the algorithm depends on the
> map's original size and the panel's size. Normally, this works out
> fine. But it is true that there are some exceptions - most notably
> when scrollbars are added for the dimension not to fit to. (Your
> example: "fit to width" horizontally sizes correctly but, because the
> map is higher than the pane, a vertical scroll bar has to be added. As
> a result, it is possible that the map does not fit horizontally any
> more.)
> If you have an idea here, please feel free to adjust this.


Unfortunately I have no time do so now (that is code that I have not written 
myself, so you are more knowledgeable than me currently). One guess is
that you might not use the size of the ViewPort of the Scrollpane embedding 
the map?

Another observation: The toolips does not show the japanese characters (only 
rectangle dummies instead). So it seems there is an UFT-8 issue again.

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

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

Thanks again for pushing.

> * After KU buys a 2 train the error in the route calculation prevents the Done
> from getting activated, this makes continuing the game impossible.

This should not be the case any more after applying 0003 - as all
route calculations now take place in another thread. Are you sure that
0003 had been applied when making these observations?

> * "Fit to width" sometimes sets the zoom scale a little to large, so that the
> horizontal scrollbar still remains active.
> * "Fit to height" often sets the zoom scale such that a large unused border at
> the bottom remains.

The algorithm of "Fit to xyz" selects the maximum possible zoom step
for which the map is expected to be within the bounds.

- Zoom steps are designed to be discrete, hence leading to your
observation ("fit to height"). I avoided refactoring for continuous
zoom levels in order to be able to maintain current zoom in/out logic.
- For evaluating expected map sizes, the algorithm depends on the
map's original size and the panel's size. Normally, this works out
fine. But it is true that there are some exceptions - most notably
when scrollbars are added for the dimension not to fit to. (Your
example: "fit to width" horizontally sizes correctly but, because the
map is higher than the pane, a vertical scroll bar has to be added. As
a result, it is possible that the map does not fit horizontally any
more.)
If you have an idea here, please feel free to adjust this.

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

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

Frederick:
0003 is Pushed.

I did play around with the save file of 1889 you provided and came up with a 
few observations:

* After KU buys a 2 train the error in the route calculation prevents the Done 
from getting activated, this makes continuing the game impossible. 
I will import the fix to the master branch as soon as I have some time 
available, however the game UI should be robust against a failing revenue 
calculation.

* "Fit to width" sometimes sets the zoom scale a little to large, so that the 
horizontal scrollbar still remains active.

* "Fit to height" often sets the zoom scale such that a large unused border at 
the bottom remains.

Are you sure you use the correct window sizes and/or maybe some rounding is 
involved?

Stefan



On Wednesday, January 04, 2012 05:25:52 pm Frederick Weld wrote:
> Thanks for the push!
> 
> I performed some refactoring as I was not too happy with some aspects.
> Would you mind pushing the 0003 patch?
> 
> *******
> Routes of current company calculated asynchronously
> 
> Polished the handling of route calculations. This was needed as a
> follow-up to introducing persistent route display of the current
> company.
> 
> Achieved the following:
> - All route calculations are performed asynchronously (as it was already
> the case before for set-revenue route calculations).
> - ORPanel now only uses one revenue adapter for both use cases
> (current route display and set-revenue calculation).
> *******
> 
> For the Q & A:
> > * You only show the optimal routes on map, but there is nothing
> > displayed about what the run for and which cities etc.?
> 
> Nothing is displayed. More information is available in the network
> info menu. But this could be expanded of course (if we got the pull
> from the 18xx end users).
> 
> > * I thought I had coded an automatic size adjustment of the config window
> > to the number of options available. Did it not work like that?
> 
> Unfortunately, this didn't work. The config window starts with a fixed
> size (6xx * 4xx) and does not resize.
> 
> > * The bug (revenue breaks with an error if company has no route at all)
> > you reported is already known, however not fixed in master yet (that
> > still resides in branch revenue if I remember correctly). As it used to
> > do no harm, I was too lazy to merge it yet.
> 
> Now, it does not harm any more (as everything is run asynchronously).
> So you don't have to merge this.
> 
> > * Other issue: I would prefer background maps displaying the coordinates
> > on their own instead of Rails adding them, this spoils the beauty
> > somehow ;-)
> 
> Within rails, I experimented with anti-aliasing or outlining the
> coordinates but the results weren't satisfactory. Keep in mind that
> this minimum font size we wanted for the station tokens cannot be
> maintained for the coordinates if they are part of the map...

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 performed some refactoring as I was not too happy with some aspects.
Would you mind pushing the 0003 patch?

*******
Routes of current company calculated asynchronously

Polished the handling of route calculations. This was needed as a
follow-up to introducing persistent route display of the current
company.

Achieved the following:
- All route calculations are performed asynchronously (as it was already
the case before for set-revenue route calculations).
- ORPanel now only uses one revenue adapter for both use cases
(current route display and set-revenue calculation).
*******

For the Q & A:

> * You only show the optimal routes on map, but there is nothing
> displayed about what the run for and which cities etc.?
Nothing is displayed. More information is available in the network
info menu. But this could be expanded of course (if we got the pull
from the 18xx end users).

> * I thought I had coded an automatic size adjustment of the config window
> to the number of options available. Did it not work like that?
Unfortunately, this didn't work. The config window starts with a fixed
size (6xx * 4xx) and does not resize.

> * The bug (revenue breaks with an error if company has no route at all) you
> reported is already known, however not fixed in master yet (that still resides
> in branch revenue if I remember correctly). As it used to do no harm, I was
> too lazy to merge it yet.
Now, it does not harm any more (as everything is run asynchronously).
So you don't have to merge this.

> * Other issue: I would prefer background maps displaying the coordinates on
> their own instead of Rails adding them, this spoils the beauty somehow ;-)
Within rails, I experimented with anti-aliasing or outlining the
coordinates but the results weren't satisfactory. Keep in mind that
this minimum font size we wanted for the station tokens cannot be
maintained for the coordinates if they are part of the map...

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

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

Frederick:
Both patches pushed. Both work for me.

Q & A:
* You only show the optimal routes on map, but there is nothing
displayed about what the run for and which cities etc.?

* I thought I had coded an automatic size adjustment of the config window
to the number of options available. Did it not work like that?

* The bug (revenue breaks with an error if company has no route at all) you 
reported is already known, however not fixed in master yet (that still resides 
in branch revenue if I remember correctly). As it used to do no harm, I was 
too lazy to merge it yet.

* Other issue: I would prefer background maps displaying the coordinates on 
their own instead of Rails adding them, this spoils the beauty somehow ;-) 

Stefan


On Tuesday, January 03, 2012 09:22:32 pm Frederick Weld wrote:
> I finally concluded to introduce a new config option ("Display routes
> of currently active company") instead of the keyboard shortcut. The
> main reason is that, while being highly desirable for 18xx newbies,
> implementing this option was not much effort once I replaced the popup
> by some lazy invalidation mechanism (of the route display).
> 
> Would you please git push this?
> 
> @Stefan: There appears to be a bug in the route calculation. It can be
> reproduced by the attached save game (just buy a train for KU - route
> display has to be active of course). I could have corrected the
> symptoms but probably it's better if you had a look at this.
> 
> --------------------
> 
> Subject: [PATCH 1/2] Fixed hexmap layering (tokens and text now displayed
> on top of routes)
> 
> Before, route strokes were placed on top of the map, thus hiding
> potentially valuable information.
> 
> This has been adjusted: Train routes are now drawn on top of the hexes
> but below any further map information (tokens, home bases, texts for
> costs, special tokens)
> 
> Subject: [PATCH 2/2] Added option to display optimal routes of currently
>  active company
> 
> If this option is chosen, optimal routes are displayed for each OR
> step. This option replaces prior keyboard shortcut Ctrl+N which had
> some disadvantages (popup, optimal route display only temporary).
> 
> The config section "map/report" has been split as it contained too
> many items after adding aforementioned option.

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

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

I finally concluded to introduce a new config option ("Display routes
of currently active company") instead of the keyboard shortcut. The
main reason is that, while being highly desirable for 18xx newbies,
implementing this option was not much effort once I replaced the popup
by some lazy invalidation mechanism (of the route display).

Would you please git push this?

@Stefan: There appears to be a bug in the route calculation. It can be
reproduced by the attached save game (just buy a train for KU - route
display has to be active of course). I could have corrected the
symptoms but probably it's better if you had a look at this.

--------------------

Subject: [PATCH 1/2] Fixed hexmap layering (tokens and text now displayed on
 top of routes)

Before, route strokes were placed on top of the map, thus hiding
potentially valuable information.

This has been adjusted: Train routes are now drawn on top of the hexes
but below any further map information (tokens, home bases, texts for
costs, special tokens)

Subject: [PATCH 2/2] Added option to display optimal routes of currently
 active company

If this option is chosen, optimal routes are displayed for each OR
step. This option replaces prior keyboard shortcut Ctrl+N which had
some disadvantages (popup, optimal route display only temporary).

The config section "map/report" has been split as it contained too
many items after adding aforementioned option.

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

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

Another related aspect is as follows:

Currently, parts of the game engine (OperatingRound and
action.BuyTrain) are conceived in such a way that they need to know
whether the company is forced to buy a train (since only then the
president is allowed to add his cash).
If the game engine was held unaware of routes, it would also be unable
to determine the possible actions of buy train.

What would be the design to cope with this situation?

Should the game engine consumer filter out all those actions that
necessite president cash for BuyTrain, in case the train purchase was
not forced?