rails-devel — List for discussion of Rails development

Re: [Rails-devel] Release planning for 1.4

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

No objections.

-----Original Message-----
From: brett lentz [mailto:bre...@gm...] 
Sent: Wednesday 18 August 2010 00:21
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Release planning for 1.4

A release this weekend is fine by me.

Erik or anyone else - any objections?


---Brett.



On Tue, Aug 17, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote:
> Brett:
> I would even prefer a sooner release: This might avoid more duplicate bug
> reports. I suggest this Sunday (22nd) it time permits on your side.
> I will be (even more) time constrained in the near future and thus there
will
> not happen much until the later date anyway.
> Stefan
>
> On Monday, August 16, 2010 11:17:12 pm brett lentz wrote:
>> I'd like to start the discussion on planning our next release. I think
>> we've fixed several important bugs that users would like to see
>> released.
>>
>> Erik, Stefan - What do you guys think?  Does a Sept 1 release date
>> seem reasonable? That'd give us a bit over two weeks of time to finish
>> up the recent changes to logging and anything else that isn't stable
>> enough for release.
>>
>> ---Brett.
>>
>>
---------------------------------------------------------------------------
>> --- This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
----------------------------------------------------------------------------
--
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

----------------------------------------------------------------------------
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Release planning for 1.4

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

A release this weekend is fine by me.

Erik or anyone else - any objections?


---Brett.



On Tue, Aug 17, 2010 at 2:26 PM, Stefan Frey <ste...@we...> wrote:
> Brett:
> I would even prefer a sooner release: This might avoid more duplicate bug
> reports. I suggest this Sunday (22nd) it time permits on your side.
> I will be (even more) time constrained in the near future and thus there will
> not happen much until the later date anyway.
> Stefan
>
> On Monday, August 16, 2010 11:17:12 pm brett lentz wrote:
>> I'd like to start the discussion on planning our next release. I think
>> we've fixed several important bugs that users would like to see
>> released.
>>
>> Erik, Stefan - What do you guys think?  Does a Sept 1 release date
>> seem reasonable? That'd give us a bit over two weeks of time to finish
>> up the recent changes to logging and anything else that isn't stable
>> enough for release.
>>
>> ---Brett.
>>
>> ---------------------------------------------------------------------------
>> --- This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Release planning for 1.4

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

Brett:
I would even prefer a sooner release: This might avoid more duplicate bug
reports. I suggest this Sunday (22nd) it time permits on your side.
I will be (even more) time constrained in the near future and thus there will 
not happen much until the later date anyway.
Stefan 

On Monday, August 16, 2010 11:17:12 pm brett lentz wrote:
> I'd like to start the discussion on planning our next release. I think
> we've fixed several important bugs that users would like to see
> released.
> 
> Erik, Stefan - What do you guys think?  Does a Sept 1 release date
> seem reasonable? That'd give us a bit over two weeks of time to finish
> up the recent changes to logging and anything else that isn't stable
> enough for release.
> 
> ---Brett.
> 
> ---------------------------------------------------------------------------
> --- This SF.net email is sponsored by
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Usage patterns for game history window

[Chris S. <chr...@gm...>]

I would use it to play a pbem forward to explore options, then returning to
the current state to take my actual turn.  You see this behavior in Aliza's
various reports, where she submits files from prospective moves.

I also like the ability to browse through previous game states to figure out
what happened between turns, especially if it is a slow game.

--
Chris

Please consider the environment before printing this e-mail.


On Mon, Aug 16, 2010 at 12:07 PM, Stefan Frey <ste...@we...> wrote:

> I am little guessing about the usage of the new game report/history window:
> As it is very easy to navigate to past actions of the game, I wonder what
> the
> user intentions will be:
>
> Will the main use be a possible return to a previous state of the game (for
> example during a ftf game an action was skipped wrongly or a player was
> allowed a take back)?
> In that case it make sense to keep the other windows fully activated and
> responsive to user actions.
>
> After adding the ability to comment the following use case might occur
> frequently in pbem:
> Going back to one action, add a comment and return to the end of action
> stack.
>
> Or maybe it will be more a tool for analyzing the crucial situations after
> the
> game has finished?
>
> The reason is that for the two latter use cases it would be better to
> disable
> the game windows to user actions to avoid deleting the game history
> unintentionally, preventing a return to the latest game state.
> Then there should be a button/menu item (maybe in the Main GameStatus
> Window
> under Moderator) that allows to restart the game at the selected point in
> history. (=> Replay from here).
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Usage patterns for game history window

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

I'd agree with Steve, I've been thinking for a while that a 'restart
game from here' and then just clicking 'next action' or something
similar would be a great learning experience for replaying games and
trying out scenarios

(especially after Steve's brutal 1830 victory he just scored over us :p)

On 16 August 2010 20:18, Steve Undy <ste...@gm...> wrote:
> I see it as useful for analyzing a game after completion, including playing
> "what-if" scenarios.
>
> Steve Undy
> st...@ro...
>
>
> On Mon, Aug 16, 2010 at 1:07 PM, Stefan Frey <ste...@we...> wrote:
>>
>> I am little guessing about the usage of the new game report/history
>> window:
>> As it is very easy to navigate to past actions of the game, I wonder what
>> the
>> user intentions will be:
>>
>> Will the main use be a possible return to a previous state of the game
>> (for
>> example during a ftf game an action was skipped wrongly or a player was
>> allowed a take back)?
>> In that case it make sense to keep the other windows fully activated and
>> responsive to user actions.
>>
>> After adding the ability to comment the following use case might occur
>> frequently in pbem:
>> Going back to one action, add a comment and return to the end of action
>> stack.
>>
>> Or maybe it will be more a tool for analyzing the crucial situations after
>> the
>> game has finished?
>>
>> The reason is that for the two latter use cases it would be better to
>> disable
>> the game windows to user actions to avoid deleting the game history
>> unintentionally, preventing a return to the latest game state.
>> Then there should be a button/menu item (maybe in the Main GameStatus
>> Window
>> under Moderator) that allows to restart the game at the selected point in
>> history. (=> Replay from here).
>>
>> Stefan
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] please allow simple player text-messages/annotations, within main save-file & report window

[Jim B. <ji...@ko...>]

Erik, Stefan-

thanks so much, for your attention to this user-annotation feature- I'm really looking forward to trying it out.  :-)

best,
 - jim

[Rails-devel] Release planning for 1.4

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

I'd like to start the discussion on planning our next release. I think
we've fixed several important bugs that users would like to see
released.

Erik, Stefan - What do you guys think?  Does a Sept 1 release date
seem reasonable? That'd give us a bit over two weeks of time to finish
up the recent changes to logging and anything else that isn't stable
enough for release.

---Brett.

Re: [Rails-devel] Some (multi-)undo related bugs

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

Stefan,

I'll come back to your remarks later this week. I do have thoughts on these
matters, but no time right now.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Monday 16 August 2010 21:46
To: 'Development list for Rails: an 18xx game'
Subject: [Rails-devel] Some (multi-)undo related bugs

A rather longish discussion of implementation details to follow. Mainly 
information for Erik.
Stefan

A side-effect of the new game history is that it allows to jump around
between 
very different game states, switching round types and phases on the fly.
This acts as a advanced test on the undo mechanism and overall it works very

well. However there are still some bugs to discover, which might also act as

examples to avoid confusing the undo/redo mechanism:

* The toolTip on hexes was not updated correctly after undo/redos (still 
showing the tile information from the previous state), as the update was 
controlled only by the tile/token lay UI classes and not the game backend.
I shortly considered a ToolTipModel approach, but I realized that is much 
easier to update the toolTip at the time it is requested by the user.
I would still like to move the code to create the toolTip string from the UI

GUIHex class to the game MapHex class to reduce the amount of processing and

calls to the game classes from the UI class. 
Or is there a reason to avoid that, Erik?
It seems to me that now all UI elements update correctly after undo (I 
recently added a PresidentModel to update the president column).

* A more subtle problem arose from a 18EU test: After going back from a
major 
turns to a minor ones during the green phase, the minor was suddenly allowed

to lay a green tile.
This occured as the tileLayPerColour state change triggers a call to the 
operatingCompany  variable inside the OperatingRound instance. This variable

itself however is not a state variable itself, but gets only initialized
from 
the state variable operatingCompanyObject at the begin of the companies' 
action generation. Thus during the undo Rails assume that the
tileLayPerColour 
request is still for the major company, as the operatingRound is not
updated.

I admit that I have introduced the operatingCompanyObject myself and did not

think about this problem at that time: The lesson to learn here is to
strongly 
avoid working with non-state variables, which simply contain a reference to
a 
state variable. This is an wide open door for bugs & troubles a long time 
later.
Either use the state variable directly or encapsulate it to a method call,
if 
the state mechanism seems to unwieldy. 

----------------------------------------------------------------------------
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Price tokens change order when moving up.

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

Hi Aliza,
3044491 was already fixed, but still to be released.

The other 18AL bug you are referring to (3026083) is not that critical as you 
might assume: Version 1.3 only displays in the game report that the 4 trains 
are rusted. The game engine itself progresses correctly and allows the 4 
trains the additional run. The wrong text will be changed in the next release.

The other remaining 18AL bug (3017592) causes minor annoyance during revenue 
calculation for the company with named trains (always assumes that the bonus 
is scored if the cities to connect do not exist in the route network of that 
company). Again fixed in the next release.

I do not know an easy way to change the state of the bugs after a version 
release of Sourceforge (but I am no expert here), but usually you can assume 
that it will be the next release after the version for which the bug was 
reported and/or still valid (shown in the group field).

Stefan

On Friday, August 13, 2010 07:42:08 pm Aliza Panitz wrote:
> I did not see a bug filed on this in SourceForge so I filed bug
> 3044491on it with a savefile.
> 
> (I also note that a more critical bug affecting 18AL, ID: 3026083, has
> been marked as fixed but there's nothing in Sourceforge to tell me
> what Rails release, if any, contains the fix.)
> 
> If the bug has been fixed, when can we expect to see a new version of
> Rails published with the fix? Is there a way to set up Sourceforge so
> people can see what published version contains the fix for each bug,
> or at least add a "released" status after "fixed"?
> 
> Peter, Brad, Joshua, this involves a play-ahead of our game based on
> my guessing what people would do, please do not look at the savefile
> (though you can probably guess.)
> 
>  - Aliza
> 
> On Sun, Jul 4, 2010 at 1:57 PM, Erik Vos <eri...@xs...> wrote:
> > (Switching to the proper group)
> > This has been fixed now - in Subversion!
> > 
> > Erik.
> > 
> > ________________________________
> > From: 18...@ya... [mailto:18...@ya...] On Behalf Of
> > John A. Tamplin Sent: Friday 02 July 2010 00:17
> > To: 18...@ya...
> > Subject: Re: [18xx] par value marker movement
> > 
> > On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...> wrote:
> > > At the end of the SR, the companies are scanned for being sold out in
> > > the order in which they appear in the Game Status window. Any upward
> > > token moves
> > > are then executed in that order and follow the normal move rules. So I
> > > suspect that the token order gets reversed only if a 'lower' company
> > > token is on top of a 'higher' one. Or it could be the reverse...:-)
> > > Indeed we need
> > > a saved file to prove that.
> > > In any case, I would encourage to file it as a bug, so it will get
> > > proper attention at some point.
> > 
> > The tokens are supposed to be processed in market order, which winds up
> > preserving the same stacking.
> > 
> > --
> > John A. Tamplin
> 
> ---------------------------------------------------------------------------
> --- This SF.net email is sponsored by
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Some (multi-)undo related bugs

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

A rather longish discussion of implementation details to follow. Mainly 
information for Erik.
Stefan

A side-effect of the new game history is that it allows to jump around between 
very different game states, switching round types and phases on the fly.
This acts as a advanced test on the undo mechanism and overall it works very 
well. However there are still some bugs to discover, which might also act as 
examples to avoid confusing the undo/redo mechanism:

* The toolTip on hexes was not updated correctly after undo/redos (still 
showing the tile information from the previous state), as the update was 
controlled only by the tile/token lay UI classes and not the game backend.
I shortly considered a ToolTipModel approach, but I realized that is much 
easier to update the toolTip at the time it is requested by the user.
I would still like to move the code to create the toolTip string from the UI 
GUIHex class to the game MapHex class to reduce the amount of processing and 
calls to the game classes from the UI class. 
Or is there a reason to avoid that, Erik?
It seems to me that now all UI elements update correctly after undo (I 
recently added a PresidentModel to update the president column).

* A more subtle problem arose from a 18EU test: After going back from a major 
turns to a minor ones during the green phase, the minor was suddenly allowed 
to lay a green tile.
This occured as the tileLayPerColour state change triggers a call to the 
operatingCompany  variable inside the OperatingRound instance. This variable 
itself however is not a state variable itself, but gets only initialized from 
the state variable operatingCompanyObject at the begin of the companies' 
action generation. Thus during the undo Rails assume that the tileLayPerColour 
request is still for the major company, as the operatingRound is not updated.

I admit that I have introduced the operatingCompanyObject myself and did not 
think about this problem at that time: The lesson to learn here is to strongly 
avoid working with non-state variables, which simply contain a reference to a 
state variable. This is an wide open door for bugs & troubles a long time 
later.
Either use the state variable directly or encapsulate it to a method call, if 
the state mechanism seems to unwieldy. 

Re: [Rails-devel] Usage patterns for game history window

[Steve U. <ste...@gm...>]

I see it as useful for analyzing a game after completion, including playing
"what-if" scenarios.

Steve Undy
st...@ro...


On Mon, Aug 16, 2010 at 1:07 PM, Stefan Frey <ste...@we...> wrote:

> I am little guessing about the usage of the new game report/history window:
> As it is very easy to navigate to past actions of the game, I wonder what
> the
> user intentions will be:
>
> Will the main use be a possible return to a previous state of the game (for
> example during a ftf game an action was skipped wrongly or a player was
> allowed a take back)?
> In that case it make sense to keep the other windows fully activated and
> responsive to user actions.
>
> After adding the ability to comment the following use case might occur
> frequently in pbem:
> Going back to one action, add a comment and return to the end of action
> stack.
>
> Or maybe it will be more a tool for analyzing the crucial situations after
> the
> game has finished?
>
> The reason is that for the two latter use cases it would be better to
> disable
> the game windows to user actions to avoid deleting the game history
> unintentionally, preventing a return to the latest game state.
> Then there should be a button/menu item (maybe in the Main GameStatus
> Window
> under Moderator) that allows to restart the game at the selected point in
> history. (=> Replay from here).
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Usage patterns for game history window

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

I am little guessing about the usage of the new game report/history window:
As it is very easy to navigate to past actions of the game, I wonder what the 
user intentions will be:

Will the main use be a possible return to a previous state of the game (for 
example during a ftf game an action was skipped wrongly or a player was 
allowed a take back)?
In that case it make sense to keep the other windows fully activated and 
responsive to user actions. 

After adding the ability to comment the following use case might occur 
frequently in pbem:
Going back to one action, add a comment and return to the end of action stack.

Or maybe it will be more a tool for analyzing the crucial situations after the 
game has finished?
 
The reason is that for the two latter use cases it would be better to disable 
the game windows to user actions to avoid deleting the game history 
unintentionally, preventing a return to the latest game state.
Then there should be a button/menu item (maybe in the Main GameStatus Window 
under Moderator) that allows to restart the game at the selected point in 
history. (=> Replay from here).

Stefan

Re: [Rails-devel] please allow simple player text-messages/annotations , within main save-file & report window

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

Sorry for not being involved in the discussion before, but I implemented a 
simple solution offline yesterday. 

* How it works:

I mainly followed Jim's suggestion:

The dynamic report window has a comment button, which allows to add a comment 
to the current action, which is then displayed (in a smaller green font 
currently) beside the action in the report window. 
It is stored in Rails game file, thus is still visible after reload. 

It alllows easy commenting of past events: Simply press the link of the action 
to be commented, Rails goes back to that situation, add the comment and then 
go back to the current event.

* Implementation:

I had the same problem to solve already for the new dynamic report window: 
Messages are not directly linked to actions, thus there was the need to built 
that connection. For this I decided not to change anything in the core part 
of Rails (the action and move mechanisms), but simply use the current 
movestack index as an identifier for the messages.

The same idea works for user comments: A simple Map <Integer, String> links 
actions and user comments. All user comments are then stored at the end of 
Rails game file by serializing the map.

* Comparison to actions

The mechanism currently bypasses the action mechanism of Rails. However it is 
easy to change it to use a kind of GameAction (similar to Save, Undo etc.), 
which are not fully qualified actions, as they are not stored in the action 
stack and thus are not saved and are not undoable.

On the one hand I like the idea using fully qualified actions for comments and 
thus leverage on existing mechanisms for save and undo.  On the other 
comments are not real actions and I fear that if one starts to look into the 
details they might require different treatment: For example currently going 
back to a past game action adding a comment action at this point would not 
allow to go back to the end of action stack without modifying the undo/redo 
mechanism. This might be not that bad as it sounds, because adding past 
actions and still be able to redo the action stack is on my wishlist anyhow. 
But implementing this correctly is not easy due to the requried failure 
handling in the general case.

Stefan


On Sunday 15 August 2010 13:21:08 Erik Vos wrote:
> OK, but please note, that if we allow players to add messages out of turn,
> the acting player name must be added to that action. Without that, the game
> engine cannot know that it's not the current player who entered that
> message. So we would have to add a player name selection choice list to the
> message entry control, unless (in a PBEM game) the local.player.name
> property is used.
>
> Erik.
>
> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Saturday 14 August 2010 21:13
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] please allow simple player
> text-messages/annotations, within main save-file & report window
>
> Erik Vos wrote:
> > This is a very interesting idea, and I understand that such a feature
>
> would
>
> > be much more useful that the existing editing option.
> >
> > The main issue is about the sequence of actions. You say: "Instead, we
>
> want
>
> > to be able to simply associate a message-text with each move" and "from a
> > user-interface pov, the 'current player' is speaking". If taken
> > literally, this would mean, that the message should become part of the
> > move*, and
>
> that
>
> > the message must be entered _before_ the move is completed and executed
>
> (by
>
> > pressing "Pass", "Buy", "Done", "Lay Tile", etc.). This way, we can
> > easily ensure that a message becomes part of the move and is logged,
> > saved and undone with it. (The messages would always be displayed either
> > before or after the existing move text.)
>
> I like this idea but would make the message a separate "action".  (This
> might
> mean you're allowed to send messages out of turn, or only that each turn in
> PBEM games has to end with the "Done" button so that you have a chance to
> enter messages before ending your turn.)
>
> If messages are allowed out-of-turn, then a player who uses "Undo" within
> his
> turn may have to undo somebody else's message to reach his own action.
>
> ---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] please allow simple player text-messages/annotations, within main save-file & report window

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

OK, but please note, that if we allow players to add messages out of turn,
the acting player name must be added to that action. Without that, the game
engine cannot know that it's not the current player who entered that
message. So we would have to add a player name selection choice list to the
message entry control, unless (in a PBEM game) the local.player.name
property is used.

Erik.

-----Original Message-----
From: John David Galt [mailto:jd...@di...] 
Sent: Saturday 14 August 2010 21:13
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] please allow simple player
text-messages/annotations, within main save-file & report window

Erik Vos wrote:
> This is a very interesting idea, and I understand that such a feature
would
> be much more useful that the existing editing option.
> 
> The main issue is about the sequence of actions. You say: "Instead, we
want
> to be able to simply associate a message-text with each move" and "from a
> user-interface pov, the 'current player' is speaking". If taken literally,
> this would mean, that the message should become part of the move*, and
that
> the message must be entered _before_ the move is completed and executed
(by
> pressing "Pass", "Buy", "Done", "Lay Tile", etc.). This way, we can easily
> ensure that a message becomes part of the move and is logged, saved and
> undone with it. (The messages would always be displayed either before or
> after the existing move text.)

I like this idea but would make the message a separate "action".  (This
might
mean you're allowed to send messages out of turn, or only that each turn in
PBEM games has to end with the "Done" button so that you have a chance to
enter messages before ending your turn.)

If messages are allowed out-of-turn, then a player who uses "Undo" within
his
turn may have to undo somebody else's message to reach his own action.

----------------------------------------------------------------------------
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] please allow simple player text-messages/annotations, within main save-file & report window

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

Erik Vos wrote:
> This is a very interesting idea, and I understand that such a feature would
> be much more useful that the existing editing option.
> 
> The main issue is about the sequence of actions. You say: "Instead, we want
> to be able to simply associate a message-text with each move" and "from a
> user-interface pov, the 'current player' is speaking". If taken literally,
> this would mean, that the message should become part of the move*, and that
> the message must be entered _before_ the move is completed and executed (by
> pressing "Pass", "Buy", "Done", "Lay Tile", etc.). This way, we can easily
> ensure that a message becomes part of the move and is logged, saved and
> undone with it. (The messages would always be displayed either before or
> after the existing move text.)

I like this idea but would make the message a separate "action".  (This might
mean you're allowed to send messages out of turn, or only that each turn in
PBEM games has to end with the "Done" button so that you have a chance to
enter messages before ending your turn.)

If messages are allowed out-of-turn, then a player who uses "Undo" within his
turn may have to undo somebody else's message to reach his own action.

Re: [Rails-devel] please allow simple player text-messages/annotations, within main save-file & report window

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

This is a very interesting idea, and I understand that such a feature would
be much more useful that the existing editing option.

The main issue is about the sequence of actions. You say: "Instead, we want
to be able to simply associate a message-text with each move" and "from a
user-interface pov, the 'current player' is speaking". If taken literally,
this would mean, that the message should become part of the move*, and that
the message must be entered _before_ the move is completed and executed (by
pressing "Pass", "Buy", "Done", "Lay Tile", etc.). This way, we can easily
ensure that a message becomes part of the move and is logged, saved and
undone with it. (The messages would always be displayed either before or
after the existing move text.)

There may be one catch: players must remember which actions relinquish a
turn and make sure that any messages are entered before completing such
actions. Keep in mind that in several cases players have only one action per
turn, such as in private company auctions and during state company
formations.

>From a usability POV, a case could me made for allowing to enter a message
_after_ a move has completed (by the player having the turn at that move).
This would amount to making message entry a separate move*, which is quite
possible. However, we would then run into difficulties in defining to which
player (current or previous) the message should be ascribed, and to which
action move (the previous or the next) it should be linked for undoability
purposes. Perhaps we can define solutions for these problems, but is there a
need?

Erik.

*Technically: PossibleAction and MoveSet.

-----Original Message-----
From: Jim Black [mailto:ji...@ko...] 
Sent: Thursday 12 August 2010 19:28
To: rai...@li...
Subject: [Rails-devel] please allow simple player
text-messages/annotations,within main save-file & report window


If you're doing some work in the report window, I'd like to request/revisit
the notion of a feature for a player annotation/message, along with each
move.

This came up earlier, and Erik implemented a feature that allows edit/save
of the report-window/file- but that's not the feature pbem users want.  

Instead, we want to be able to simply associate a message-text with each
move, and have that message-text saved in the GAME FILE (.rails), and,
logged in the report window.

So the report window might read like this :

<snip>
Jim buys a 10% share of PRR from Pool for $90.
JIM:  Now, I wish I'd floated PRR earlier.  :-(
Fred buys a 10% share of NYNH from IPO for $67.
FRED:  If PRR came out earlier, I wouldn't have bought the #4 train- either
way, NYC will get that #5.
Aliza buys a 10% share of PRR from Pool for $90.
ALIZA:  Would you guys keep the noise down?
Jason buys a 10% share of PRR from Pool for $90.
Jim passes.
Fred passes.
etc...
<snip>

To summarize, I think this feature has these aspects:

a) a new text-control in the main user-interface (maybe in the report-window
toolbar, maybe somewhere else)- the current player can type text into the
control, and it will be saved as a comment in the game-record (at this point
in the game).
b) these player annotations are saved in the regular .rails file, along with
the traditional player moves
c) the report-window reports these player texts/messages, simply interleaved
in it main game log.  (as in my example, above.   alternatively, a different
window might just list player's messages- but, personally, I'd prefer a
single log, w/ everything reported there.)
d) there is no additional save/edit action required (or desired), to save
the text-message- it's /automatically/ appended to the main game record,
during a normal Save...
e) undo/etc should also undo the message- the messages are attached to moves
(from a user-interface pov, the "current player" is speaking).

I'm trying to be precise, to be helpful- but, I don't think it's very
difficult, as described here?

This would provide a /huge/ social benefit in pbem games.  

(The Rails record is too dry- no player interaction, eg compared with VASSAL
pbem games.  Rails does everything else, though- so, pbem players don't use
email for much game chat, either- and, even if they did, it wouldn't be
saved along with the game.)

thanks for the consideration,
 - jim
  


----------------------------------------------------------------------------
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] please allow simple player text-messages/annotations, within main save-file & report window

[Chris S. <chr...@gm...>]

I concur with this request 100%.

--
Chris

Please consider the environment before printing this e-mail.


On Thu, Aug 12, 2010 at 10:27 AM, Jim Black <ji...@ko...> wrote:

>
> If you're doing some work in the report window, I'd like to request/revisit
> the notion of a feature for a player annotation/message, along with each
> move.
>
> This came up earlier, and Erik implemented a feature that allows edit/save
> of the report-window/file- but that's not the feature pbem users want.
>
> Instead, we want to be able to simply associate a message-text with each
> move, and have that message-text saved in the GAME FILE (.rails), and,
> logged in the report window.
>
> So the report window might read like this :
>
> <snip>
> Jim buys a 10% share of PRR from Pool for $90.
> JIM:  Now, I wish I'd floated PRR earlier.  :-(
> Fred buys a 10% share of NYNH from IPO for $67.
> FRED:  If PRR came out earlier, I wouldn't have bought the #4 train- either
> way, NYC will get that #5.
> Aliza buys a 10% share of PRR from Pool for $90.
> ALIZA:  Would you guys keep the noise down?
> Jason buys a 10% share of PRR from Pool for $90.
> Jim passes.
> Fred passes.
> etc...
> <snip>
>
> To summarize, I think this feature has these aspects:
>
> a) a new text-control in the main user-interface (maybe in the
> report-window toolbar, maybe somewhere else)- the current player can type
> text into the control, and it will be saved as a comment in the game-record
> (at this point in the game).
> b) these player annotations are saved in the regular .rails file, along
> with the traditional player moves
> c) the report-window reports these player texts/messages, simply
> interleaved in it main game log.  (as in my example, above.   alternatively,
> a different window might just list player's messages- but, personally, I'd
> prefer a single log, w/ everything reported there.)
> d) there is no additional save/edit action required (or desired), to save
> the text-message- it's /automatically/ appended to the main game record,
> during a normal Save...
> e) undo/etc should also undo the message- the messages are attached to
> moves (from a user-interface pov, the "current player" is speaking).
>
> I'm trying to be precise, to be helpful- but, I don't think it's very
> difficult, as described here?
>
> This would provide a /huge/ social benefit in pbem games.
>
> (The Rails record is too dry- no player interaction, eg compared with
> VASSAL pbem games.  Rails does everything else, though- so, pbem players
> don't use email for much game chat, either- and, even if they did, it
> wouldn't be saved along with the game.)
>
> thanks for the consideration,
>  - jim
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Price tokens change order when moving up.

[Aliza P. <ali...@gm...>]

I did not see a bug filed on this in SourceForge so I filed bug
3044491on it with a savefile.

(I also note that a more critical bug affecting 18AL, ID: 3026083, has
been marked as fixed but there's nothing in Sourceforge to tell me
what Rails release, if any, contains the fix.)

If the bug has been fixed, when can we expect to see a new version of
Rails published with the fix? Is there a way to set up Sourceforge so
people can see what published version contains the fix for each bug,
or at least add a "released" status after "fixed"?

Peter, Brad, Joshua, this involves a play-ahead of our game based on
my guessing what people would do, please do not look at the savefile
(though you can probably guess.)

 - Aliza

On Sun, Jul 4, 2010 at 1:57 PM, Erik Vos <eri...@xs...> wrote:
>
> (Switching to the proper group)
> This has been fixed now - in Subversion!
>
> Erik.
>
> ________________________________
> From: 18...@ya... [mailto:18...@ya...] On Behalf Of John A. Tamplin
> Sent: Friday 02 July 2010 00:17
> To: 18...@ya...
> Subject: Re: [18xx] par value marker movement
>
>
>
> On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...> wrote:
>
> > At the end of the SR, the companies are scanned for being sold out in the
> > order in which they appear in the Game Status window. Any upward token
> > moves
> > are then executed in that order and follow the normal move rules. So I
> > suspect that the token order gets reversed only if a 'lower' company token
> > is on top of a 'higher' one. Or it could be the reverse...:-) Indeed we
> > need
> > a saved file to prove that.
> > In any case, I would encourage to file it as a bug, so it will get proper
> > attention at some point.
>
> The tokens are supposed to be processed in market order, which winds up
> preserving the same stacking.
>
> --
> John A. Tamplin
>

Re: [Rails-devel] Report window as game history

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

* I could change the (static/legacy) report window to the new behavior of 
clearing undone actions instead of appending undoing, but then the
difference 
between the two is merely formatting and the availability of hyperlinks.
Then 
it is easier to deactivate the formatting and hyperlinks than to support two

different subclasses of the ReportWindow. 

[EV] There are more differences:
- the old version has Save and Edit(find) menu options. Print is on the wish
list (but a bit redundant, as that can also be done after copy/pasting into
any editor). I suppose these menu options could be retrofitted into the new
version.
- it is editable in the sense that personal comments can be inserted (and
saved). That might not be so easy to retrofit into the new version. I
believe that such editability once was a Feature Request.

I wouldn't be against a complete merge, but only if all old functionality
can be retained. As Stefan says, a choice between the two options might be
the best path for now. 

Erik.

Re: [Rails-devel] 1856 THB home hex (Hamilton) blocked or not?

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

Some time ago I forwarded the question to the yahoo group. There were two 
possible interpretations suggested:

A) THB home hex is blocked like Erie until brown, except that on the gray 3 
slots tile, two companies can token before THB.
B) As long as the other slot stays open, tokening of one company is allowed.

There is a new game option that allows to select A) or B). Default is B) as it 
allows play of A) if players decide to interpret the rule differently.

For this I rewrote the token blocking procedure:

Companies with undecided tokens can have two different blocking behaviors:
i) Block a slot in all cities of that hex (allCitiesBlocked = yes in XML for 
the company)
ii) Block a slot in any city of that hex (allCitiesBlocked = no in XML for the 
company)

i) is the behavior of Erie and THB in variant A)
ii) is the behavior of THB in variant B)

The blocking procedure potentially works for multiple home bases in a single 
hex now. I kept the blockedForTokenLays attribute of the MapHex for 1835 
compatibilty (Preussen does not block an additional slot of Berlin) and other 
future use.

Stefan

On Monday, July 12, 2010 11:03:45 pm Stefan Frey wrote:
> > 3025465: 1856. THB token spot blocked inappropriately
> > 
> > [EV] Hmm, I have always thought that the same token laying rules would
> > apply to the THB home hex (Hamilton) as to the Erie home hex in 1830, and
> > so I have implemented it identically. But I see that the 1856 rules are
> > silent on this point, and can't find any clarifications either. Is it
> > indeed generally agreed that another company may lay a token in Hamilton
> > before the THB does?
> 
> Erik,
> thanks for catching this ambiguity. I thought you intended that behavior as
> for the Erie compatability an unlaidHomeBlocksTokens="yes" for Hamilton was
> missing.
> 
> I checked the rules before the fix and it seemed that the indicate that a
> token can be laid. As there is no special rule for THB as for the Erie in
> 1830, it falls back to the standard spec:
> "In the starting city for a company that has not yet started, a company
> cannot place a station marker on the last available space (if an extra
> space becomes available later, the station marker may then be placed)."
> Seems the question is if the two cities on the OO tile are considered as
> one entity.
> The 1856 FAQ of Steve Thomas is also quiet on this topic.
> 
> At least the group, which filed the bug, considers the Hamilton hex not
> completely blocked. Does anyone of the 1856 experts (I am not) have a
> definite answer or should we escalate the question to the 18xx yahoo list?
> 
> Stefan
> 
> ---------------------------------------------------------------------------
> --- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] please allow simple player text-messages/annotations, within main save-file & report window

[Jim B. <ji...@ko...>]

If you're doing some work in the report window, I'd like to request/revisit the notion of a feature for a player annotation/message, along with each move.

This came up earlier, and Erik implemented a feature that allows edit/save of the report-window/file- but that's not the feature pbem users want.  

Instead, we want to be able to simply associate a message-text with each move, and have that message-text saved in the GAME FILE (.rails), and, logged in the report window.

So the report window might read like this :

<snip>
Jim buys a 10% share of PRR from Pool for $90.
JIM:  Now, I wish I'd floated PRR earlier.  :-(
Fred buys a 10% share of NYNH from IPO for $67.
FRED:  If PRR came out earlier, I wouldn't have bought the #4 train- either way, NYC will get that #5.
Aliza buys a 10% share of PRR from Pool for $90.
ALIZA:  Would you guys keep the noise down?
Jason buys a 10% share of PRR from Pool for $90.
Jim passes.
Fred passes.
etc...
<snip>

To summarize, I think this feature has these aspects:

a) a new text-control in the main user-interface (maybe in the report-window toolbar, maybe somewhere else)- the current player can type text into the control, and it will be saved as a comment in the game-record (at this point in the game).
b) these player annotations are saved in the regular .rails file, along with the traditional player moves
c) the report-window reports these player texts/messages, simply interleaved in it main game log.  (as in my example, above.   alternatively, a different window might just list player's messages- but, personally, I'd prefer a single log, w/ everything reported there.)
d) there is no additional save/edit action required (or desired), to save the text-message- it's /automatically/ appended to the main game record, during a normal Save...
e) undo/etc should also undo the message- the messages are attached to moves (from a user-interface pov, the "current player" is speaking).

I'm trying to be precise, to be helpful- but, I don't think it's very difficult, as described here?

This would provide a /huge/ social benefit in pbem games.  

(The Rails record is too dry- no player interaction, eg compared with VASSAL pbem games.  Rails does everything else, though- so, pbem players don't use email for much game chat, either- and, even if they did, it wouldn't be saved along with the game.)

thanks for the consideration,
 - jim
  

Re: [Rails-devel] Report window as game history

[Chris S. <chr...@gm...>]

This sounds like it would work to me.  If users can copy/paste with newlines
from the HTML version, I don't really anticipate needing to use the legacy
version very often.

--
Chris

Please consider the environment before printing this e-mail.


On Wed, Aug 11, 2010 at 4:21 PM, Stefan Frey <ste...@we...> wrote:

> Chris & Erik:
> * Fixed the missing newline in copy&paste from the new report window
> (google is your friend).
>
> * There is a new configuration window now, which allows to set options via
> an
> UI. I will add some code (similar to the one  font changes) that makes the
> change immediate and does not require a reload. Supplying both
> simultaneously
> would be possible, but might bring more confusion to newbies than benefits
> to
> the experts?
>
> * I could change the (static/legacy) report window to the new behavior of
> clearing undone actions instead of appending undoing, but then the
> difference
> between the two is merely formatting and the availability of hyperlinks.
> Then
> it is easier to deactivate the formatting and hyperlinks than to support
> two
> different subclasses of the ReportWindow.
>
> There are two reasons to keep the static version:
> A) For me the static window acts as an accounting trail, thus keeps track
> of
> undos explicitly.
> B) For (quite old) computers (or handhelds if Rails gets portable in the
> future) the JEditorPane is a drag on performance and the whole content is
> updated after each action instead of appending as in the static case.
>
> Stefan
>
>
> On Thursday, August 12, 2010 12:31:15 am Chris Shaffer wrote:
> > In that case, could there be an option to enable both report windows, so
> > users can switch back and forth between them within a single game?  And
> > without requiring them to edit configuration files and reload?  I'd hate
> to
> > have to choose between one or the other, since they both have lots of
> > utility.
> >
> > --
> > Chris
> >
> > Please consider the environment before printing this e-mail.
> >
> > On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote:
> > >  I found that you can do that, but at the rather severe penalty of
> losing
> > >
> > > all end-of lines. The report becomes one long line.
> > > Better keep to the (what Stefan in his wisdom disposes as) "legacy"
> > > report if you want to save or copy it.
> > >
> > > Erik.
> > >
> > >  ------------------------------
> > >
> > > *From:* Chris Shaffer [mailto:chr...@gm...]
> > > *Sent:* Wednesday 11 August 2010 21:17
> > >
> > > *To:* Development list for Rails: an 18xx game
> > > *Subject:* Re: [Rails-devel] Report window as game history
> > >
> > > Is it still possible to copy text from the Report window for pasting
> into
> > > an email?
> > >
> > > --
> > > Chris
> > >
> > > Please consider the environment before printing this e-mail.
> > >
> > > On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...>
> wrote:
> > >> The linked movesets in the CGR 1856 merger inspired a feature that
> > >> proved to
> > >> be surprisingly easy (as it leverages on the excellent move/state
> > >> mechanisms
> > >> in Rails). The downside is that it can be effected by the all undo
> > >> related bugs, but the number of those was on the decrease lately.
> > >>
> > >> The report window now acts as game history: There are hyperlinks for
> > >> each action. Clicking on any of those lets Rails jump to that game
> > >> situation (by
> > >> calling undo repeatedly). Return to a later position is possible
> unless
> > >> an action is taken (as it is the case for standard redo). I also added
> > >> two buttons (<< and >>) to allow single-step moves.
> > >>
> > >> The old report window (which is editable) can be activated via the
> > >> Configuration menu (or setting report.window.type to static in the
> > >> legacy configfiles).
> > >>
> > >> Stefan
> > >>
> > >>
> > >>
> ------------------------------------------------------------------------
> > >> ------ This SF.net email is sponsored by
> > >>
> > >> Make an app they can't live without
> > >> Enter the BlackBerry Developer Challenge
> > >> http://p.sf.net/sfu/RIM-dev2dev
> > >> _______________________________________________
> > >> Rails-devel mailing list
> > >> Rai...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> > >
> -------------------------------------------------------------------------
> > > ----- This SF.net email is sponsored by
> > >
> > > Make an app they can't live without
> > > Enter the BlackBerry Developer Challenge
> > > http://p.sf.net/sfu/RIM-dev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Report window as game history

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

Chris & Erik:
* Fixed the missing newline in copy&paste from the new report window
(google is your friend).

* There is a new configuration window now, which allows to set options via an 
UI. I will add some code (similar to the one  font changes) that makes the 
change immediate and does not require a reload. Supplying both simultaneously 
would be possible, but might bring more confusion to newbies than benefits to 
the experts? 

* I could change the (static/legacy) report window to the new behavior of 
clearing undone actions instead of appending undoing, but then the difference 
between the two is merely formatting and the availability of hyperlinks. Then 
it is easier to deactivate the formatting and hyperlinks than to support two 
different subclasses of the ReportWindow. 

There are two reasons to keep the static version:
A) For me the static window acts as an accounting trail, thus keeps track of 
undos explicitly. 
B) For (quite old) computers (or handhelds if Rails gets portable in the 
future) the JEditorPane is a drag on performance and the whole content is 
updated after each action instead of appending as in the static case. 

Stefan


On Thursday, August 12, 2010 12:31:15 am Chris Shaffer wrote:
> In that case, could there be an option to enable both report windows, so
> users can switch back and forth between them within a single game?  And
> without requiring them to edit configuration files and reload?  I'd hate to
> have to choose between one or the other, since they both have lots of
> utility.
> 
> --
> Chris
> 
> Please consider the environment before printing this e-mail.
> 
> On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote:
> >  I found that you can do that, but at the rather severe penalty of losing
> > 
> > all end-of lines. The report becomes one long line.
> > Better keep to the (what Stefan in his wisdom disposes as) "legacy"
> > report if you want to save or copy it.
> > 
> > Erik.
> > 
> >  ------------------------------
> > 
> > *From:* Chris Shaffer [mailto:chr...@gm...]
> > *Sent:* Wednesday 11 August 2010 21:17
> > 
> > *To:* Development list for Rails: an 18xx game
> > *Subject:* Re: [Rails-devel] Report window as game history
> > 
> > Is it still possible to copy text from the Report window for pasting into
> > an email?
> > 
> > --
> > Chris
> > 
> > Please consider the environment before printing this e-mail.
> > 
> > On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> wrote:
> >> The linked movesets in the CGR 1856 merger inspired a feature that
> >> proved to
> >> be surprisingly easy (as it leverages on the excellent move/state
> >> mechanisms
> >> in Rails). The downside is that it can be effected by the all undo
> >> related bugs, but the number of those was on the decrease lately.
> >> 
> >> The report window now acts as game history: There are hyperlinks for
> >> each action. Clicking on any of those lets Rails jump to that game
> >> situation (by
> >> calling undo repeatedly). Return to a later position is possible unless
> >> an action is taken (as it is the case for standard redo). I also added
> >> two buttons (<< and >>) to allow single-step moves.
> >> 
> >> The old report window (which is editable) can be activated via the
> >> Configuration menu (or setting report.window.type to static in the
> >> legacy configfiles).
> >> 
> >> Stefan
> >> 
> >> 
> >> ------------------------------------------------------------------------
> >> ------ This SF.net email is sponsored by
> >> 
> >> Make an app they can't live without
> >> Enter the BlackBerry Developer Challenge
> >> http://p.sf.net/sfu/RIM-dev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- This SF.net email is sponsored by
> > 
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Report window as game history

[Chris S. <chr...@gm...>]

In that case, could there be an option to enable both report windows, so
users can switch back and forth between them within a single game?  And
without requiring them to edit configuration files and reload?  I'd hate to
have to choose between one or the other, since they both have lots of
utility.

--
Chris

Please consider the environment before printing this e-mail.


On Wed, Aug 11, 2010 at 2:17 PM, Erik Vos <eri...@xs...> wrote:

>  I found that you can do that, but at the rather severe penalty of losing
> all end-of lines. The report becomes one long line.
> Better keep to the (what Stefan in his wisdom disposes as) "legacy" report
> if you want to save or copy it.
>
> Erik.
>
>  ------------------------------
> *From:* Chris Shaffer [mailto:chr...@gm...]
> *Sent:* Wednesday 11 August 2010 21:17
>
> *To:* Development list for Rails: an 18xx game
> *Subject:* Re: [Rails-devel] Report window as game history
>
> Is it still possible to copy text from the Report window for pasting into
> an email?
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> wrote:
>
>> The linked movesets in the CGR 1856 merger inspired a feature that proved
>> to
>> be surprisingly easy (as it leverages on the excellent move/state
>> mechanisms
>> in Rails). The downside is that it can be effected by the all undo related
>> bugs, but the number of those was on the decrease lately.
>>
>> The report window now acts as game history: There are hyperlinks for each
>> action. Clicking on any of those lets Rails jump to that game situation
>> (by
>> calling undo repeatedly). Return to a later position is possible unless an
>> action is taken (as it is the case for standard redo). I also added two
>> buttons (<< and >>) to allow single-step moves.
>>
>> The old report window (which is editable) can be activated via the
>> Configuration menu (or setting report.window.type to static in the legacy
>> configfiles).
>>
>> Stefan
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Report window as game history

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

I found that you can do that, but at the rather severe penalty of losing all
end-of lines. The report becomes one long line.
Better keep to the (what Stefan in his wisdom disposes as) "legacy" report
if you want to save or copy it.
 
Erik.


  _____  

From: Chris Shaffer [mailto:chr...@gm...] 
Sent: Wednesday 11 August 2010 21:17
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Report window as game history


Is it still possible to copy text from the Report window for pasting into an
email?

--
Chris

Please consider the environment before printing this e-mail.



On Tue, Aug 10, 2010 at 4:20 PM, Stefan Frey <ste...@we...> wrote:


The linked movesets in the CGR 1856 merger inspired a feature that proved to
be surprisingly easy (as it leverages on the excellent move/state mechanisms
in Rails). The downside is that it can be effected by the all undo related
bugs, but the number of those was on the decrease lately.

The report window now acts as game history: There are hyperlinks for each
action. Clicking on any of those lets Rails jump to that game situation (by
calling undo repeatedly). Return to a later position is possible unless an
action is taken (as it is the case for standard redo). I also added two
buttons (<< and >>) to allow single-step moves.

The old report window (which is editable) can be activated via the
Configuration menu (or setting report.window.type to static in the legacy
configfiles).

Stefan

----------------------------------------------------------------------------
--
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel