Menu
▾
▴
rails-devel
|
From: Frederick W. <fre...@go...> - 2011-12-30 20:57:31
|
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). |
|
From: Stefan F. <ste...@we...> - 2012-01-02 18:46:54
|
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). |
|
From: Frederick W. <fre...@go...> - 2012-01-03 06:47:09
|
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? |
|
From: Stefan F. <ste...@we...> - 2012-01-03 10:56:17
|
> > 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. |
|
From: Frederick W. <fre...@go...> - 2012-01-03 20:22:39
|
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.
|
|
From: Stefan F. <ste...@we...> - 2012-01-04 14:17:04
|
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.
|
|
From: Frederick W. <fre...@go...> - 2012-01-04 16:26:03
|
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... |
|
From: Stefan F. <ste...@we...> - 2012-01-05 10:40:04
|
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... |
|
From: Frederick W. <fre...@go...> - 2012-01-05 11:32:31
|
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.
|
|
From: Stefan F. <ste...@we...> - 2012-01-05 12:08:42
|
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.
|
|
From: Frederick W. <fre...@go...> - 2012-01-05 12:58:10
|
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. |
|
From: Stefan F. <ste...@we...> - 2012-01-09 11:50:58
|
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. > |
|
From: Frederick W. <fre...@go...> - 2012-01-09 12:32:34
|
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... |
|
From: Stefan F. <ste...@we...> - 2012-01-09 14:07:49
|
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 |
|
From: Frederick W. <fre...@go...> - 2012-01-09 15:19:08
|
> 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? |
|
From: Frederick W. <fre...@go...> - 2012-01-10 11:24:26
|
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.
|
|
From: Frederick W. <fre...@go...> - 2012-01-10 21:26:27
|
After having added a further round-off (transformed fit-to zoom from one-time zoom to permanent auto-zoom), I'm finally satisfied with the available zoom options. |
|
From: Stefan F. <ste...@we...> - 2012-01-11 12:06:52
|
Frederick: On my system the auto-zoom noticeably resizes the map after each change to the map (e.g. laying a tile or revenue calculation), even if the map panel size remains untouched: It creates a flicker effect as Rails seems to first shrink the map a smaller size and then expand it to full size again. As long as this effect is not fixed, I would prefer a one-time zoom. Stefan On Tuesday, January 10, 2012 10:26:20 pm Frederick Weld wrote: > After having added a further round-off (transformed fit-to zoom from > one-time zoom to permanent auto-zoom), I'm finally satisfied with the > available zoom options. > > --------------------------------------------------------------------------- > --- 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 |
|
From: Frederick W. <fre...@go...> - 2012-01-11 15:14:16
|
Stefan: The size of the map panel changes if the message panel's height changes. This is typically the case if new info texts (lay tile, set revenue) are displayed. So you have probably not experienced "superfluous" resizes - but, on a second thought, it's clear also to me that this is not as nice at it was supposed to be. I perceive several design options: (1) No change to the functionality: as already said, not nice... But nobody is forced to use the auto-zoom (can be disabled at any point in time by clicking on the selected menu item again). (2) Disable auto-zoom: I wouldn't like this disablement as I really would like to have the auto-zoom (eg., think of frequent OR Panel height changes in 18EU). (3) Freeze the message panel's size to 2-3 lines: But how to deal with multiline route details? (4) Only auto-zoom on special occasions (eg., beginning of the OR): But will the end-users understand that it's not a bug that the auto-zoom is only triggered occasionally? What would be your favorite? Are there other options? Technically, all would be viable. But I wouldn't like (2) that much. --- Frederick |
|
From: Chris S. <chr...@gm...> - 2012-01-11 15:46:58
|
On Wed, Jan 11, 2012 at 7:14 AM, Frederick Weld < fre...@go...> wrote: > (3) Freeze the message panel's size to 2-3 lines: But how to deal with > multiline route details? > I prefer this option. If the message panel overflows, could you add scroll bars? -- Chris Please consider the environment before printing this e-mail. |
|
From: Frederick W. <fre...@go...> - 2012-01-11 19:00:04
|
As (3) was also my favorite, I went for this solution (now already available in master). Here are the commit details: Prohibited resizing of OR's message panel (and ORPanel to some extent) Frequent resizing by the message panel and the OR panel caused the map panel to being resized - which was not desirable in case of activated auto-zoom. Message Panel is now fixed to the height of two lines. The additional vertical scrollbar allows for text containing more than two lines. ORPanel used to resize itself for each set-revenue step as the size of the revenue input box did not match the one of the revenue read-only field. These sizes are now aligned. (ORPanel still resizes if companies are added/removed from the list.) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X