rails-devel — List for discussion of Rails development

Re: [Rails-devel] OK, Poking around a bit more

[Mark S. <mar...@gm...>]

Grr... hit send to soon

On Fri, Nov 28, 2008 at 11:05 AM, Mark Smith <mar...@gm...> wrote:
> I have come across another Bug, and some suggestions:
>
> BUG -- When laying a Tile, you select a Hex, and it shows the
> Allowable Upgrades. Select an Upgrade Tile, then select a DIFFERENT
> Upgrade Tile for the same hex. The list of available Upgrade Tiles
> goes blank. If you select a Different Hex, and then re-select the
> original Hex the Upgrades re-appear.
>
> Suggestions:
>
> 1. If you select a Hex that you cannot lay a tile on, and try to
> select a tile to place, the Pop-up Dialog claims "This tile cannot be
> laid in a valid orientation". This message is mis-leading because
> valid orientations exist, but The company laying the tile is NOT
> Allowed to lay due to lack of connection to the hex. And then when you
> click OK, the list of available tiles gets cleared. I suggest the
> following:
>

A. If the Tile is a location that can be laid by the company,
Highlight in a Green color (Green is good), or a lighter shade of the
Green Color. Better still would be a dashed thick Green/Blue to
distinguish.
B. If the Tile is a location that cannot be laid by the company,
Highlight in Red - And show allowed Tiles.
C. The Message should state the company cannot Lay Tile in that hex.

2. In the Token Laying Phase, if there is no legal place for the
company to lay a token, there is no token available, or not enough
money is available (unless the game allows emergency funding/loan
acquisition to make up the money), do a pop-up stating reason why
token cannot be laid, just like when "No Train means No Revenue".

Mark

[Rails-devel] OK, Poking around a bit more

[Mark S. <mar...@gm...>]

I have come across another Bug, and some suggestions:

BUG -- When laying a Tile, you select a Hex, and it shows the
Allowable Upgrades. Select an Upgrade Tile, then select a DIFFERENT
Upgrade Tile for the same hex. The list of available Upgrade Tiles
goes blank. If you select a Different Hex, and then re-select the
original Hex the Upgrades re-appear.

Suggestions:

1. If you select a Hex that you cannot lay a tile on, and try to
select a tile to place, the Pop-up Dialog claims "This tile cannot be
laid in a valid orientation". This message is mis-leading because
valid orientations exist, but The company laying the tile is NOT
Allowed to lay due to lack of connection to the hex. And then when you
click OK, the list of available tiles gets cleared. I suggest the
following:

Re: [Rails-devel] Play by email

[Dave M. <da...@mi...>]

Hmm... somehow I broke a filter and these messages were landing in 
the wrong folder...

On 11/25/2008 01:19 PM, brett lentz wrote:
>On Mon, Nov 24, 2008 at 6:05 PM, Dave Mitton <da...@mi...> wrote:
> > Oh... I don't know about that.
> >
> > It's not jumping ahead a turn, it would be the ability to 
> retroactively change
> > a turn or an asset that would bother me.  "I should have bought that
> > last turn..."
>
>Until we implement an actual PBEM facility, the undo feature allows
>you to do this.
>
> > I would feel more comfortable in this kind of dynamic if the game 
> generated a
> > crypto hash of the game state and made it visible to all players 
> in the report.
> > And then it should be checked on subsequent turns so that everything
> > was consistent with what was before.
> >
>
>
>What stops someone from generating that hash after they've saved a
>bogus game state?

The hash would be generated in the log record between every turn.
The hash would reflect the game state, and re-entering the same moves 
should generate the same hash.


>Being an open-source project, there's nothing that prevents someone
>from compiling and using their own modified version of the game that
>generates correct checksums for invalid data. Being a small project,
>we simply don't have anyone volunteering to implement and maintain
>additional security mechanisms.

I don't think it's really that hard, but I'm just talking aloud here.
Indeed the mechanism should not care "how" the move got entered, just
that the state of the game is "checksumed" if you will in a manner that is
easy to verify and re-check after the fact.


>Further, we let the user manually input the value of their train runs.
>Not only is this error prone, but it is an easy way for someone to
>accidentally give themselves an invalid amount of money. In my
>opinion, having someone getting patches in to implement automated
>route calculation will reduce a major potential source of error and/or
>cheating (depending on your perspective).

Another user reality that I came to quickly is that you will have to
correct or have users correct their moves.  People will screw up, 
particularly if they don't have people looking over their shoulder 
until the move is posting.   An Undo facility is necessary.
People make mistakes and I don't expect the game to get the rules 
exactly correct.
Even if does, there will be times to override.


>I really don't think this should be a big concern. The nice thing
>about implementing a board game is that everything the app does can be
>done by hand. If you want to validate that the calculations are
>correct, the math is fairly basic and well-known. It should be trivial
>to find out if something isn't right.

The math can be correct and still things go wrong.


> > I don't know if your code has this feature, but I put it in my 1830
> > program when I was debugging.
> > An auditor pass would run between every turn:
> >         It would count up all the certificates, tokens, anything I
> > could think of
> >         (and that should include cash) to make sure everything was
> > accounted for
> >         and that the program didn't "leak" or "duplicate" any 
> game materials.
> >
> >
> > Dave.
>
>We currently do not audit the game to that extent. Patches are
>welcome, if you'd like to add it.
>
>---Brett.

Maybe one of these days.... at the moment I've been doing some 
10am-11pm hours C++ network authentication programming on Vista.  I'm 
not the happiest camper.

Dave.

[Rails-devel] Bugs

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

I have added a confirmation question on closing the main (Status) window.
This was a request in the bug list.

I have put several other bug reports to pending or closed status. These bugs
I could not reproduce, and no clear examples had been provided. Unless
counterexamples are provided, I consider these bugs as either previously
fixed or non-existing.
I will continue going through the bugs list in the coming days.

Erik 

Re: [Rails-devel] Play by email

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

1851 Louisville may be unique in having this problem, so perhaps it's a bit
of a waste to write so much code to fix it in a generic way. 

The problem with the 1830 Erie home base is, that the city selection must be
done during the green upgrade, i.e. during tile laying rather than token
laying. The yellow and green cities are not linked to each other, so the
initial (yellow) token placement is immaterial. Does anyone know if this
case (a home base on a OO city) is unique? I'm not aware of any other
examples.

BTW I'm no longer sure that having separate Station (linked to Tile) and
City (linked to MapHex) objects is the optimal solution to the
token-placement-after-upgrades problem. I have trouble remembering why
exactly I did add City, and removing it might simplify the code a lot. But
this needs more thought. 

Erik.

> -----Original Message-----
> From: Mark Smith [mailto:mar...@gm...] 
> Sent: Wednesday 26 November 2008 23:50
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Play by email
> 
> Note in any game with an O-O Tile will probably have the same problem.
> Part of what I was thinking in my code base (still to be added into
> Rails CVS) was to provide in the Upgrade information, not only legal
> orientations (to replicate the track), but also information about
> where Token on City X gets placed on the Upgraded Tile. It does make
> more sense to associate the Side to which the Track the City is
> connected to be used to determine where it goes. But for 1851, L&N
> Home that might make more sense as just a special-case since once it
> gets to the center-city location on the Green Tile the rest of the
> upgrades are simple. Or to maybe do a bit of both -- For the Special
> Case, encode City 1 goes to Center City on the Upgrade, if no City
> Upgrade is specified, use the default logic that you added.
> 
> Mark
> 
> On Wed, Nov 26, 2008 at 5:36 PM, Erik Vos <eri...@hc...> wrote:
> > The idea was to have a period of testing & bug fixing 
> before the release.
> > Say two weeks. Everyone being encouraged to find and report bugs.
> >
> > BTW I have just fixed the 1851 Louisville upgrade bug, 
> reported by Mark.
> > The token movement code was not prepare to handle the 
> special case of a
> > token in a city that did not have connections to the tile 
> edges. This fix
> > does not yet handle the problem of upgrading the Erie home 
> base in 1830,
> > which has TWO such cities.
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: brett lentz [mailto:wak...@gm...]
> >> Sent: Wednesday 26 November 2008 22:08
> >> To: Development list for Rails: an 18xx game
> >> Subject: Re: [Rails-devel] Play by email
> >>
> >> On Wed, Nov 26, 2008 at 12:25 PM, Erik Vos 
> <eri...@hc...> wrote:
> >> >> Sounds good to me.  Let's shoot for the 21st as the
> >> release date. That
> >> >> gives us nearly a month to get anything else in.
> >> >>
> >> >> Should this be primarily a bug-fix release, or will you 
> have 1856
> >> >> functional by then?  What's left to be implemented?
> >> >
> >> > No, 1856 is a long haul.
> >> > You may have overlooked that I have proposed a "change
> >> freeze", which is to
> >> > avoid the side effects that my sometimes complex updates
> >> sometimes have. In
> >> > other words, I will stop working on new features until
> >> after the release.
> >> >
> >> > Fine with me if that would inspire you to move the release
> >> to an earlier
> >> > date.
> >> > Another option might be to put the release into a CVS branch.
> >> >
> >> > Erik.
> >> >
> >> >
> >>
> >> Ok.  Are there any other pending changes?   If not, I could do the
> >> release this weekend.
> >>
> >>
> >> ---Brett.
> >>
> >> --------------------------------------------------------------
> >> -----------
> >> This SF.Net email is sponsored by the Moblin Your Move
> >> Developer's challenge
> >> Build the coolest Linux based applications with Moblin SDK &
> >> win great prizes
> >> Grand prize is a trip for two to an Open Source event
> >> anywhere in the world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >
> >
> > 
> --------------------------------------------------------------
> -----------
> > This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK 
> & win great prizes
> > Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] Play by email

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

Ok.  Two weeks would be the 14th, a week earlier than my initial
suggested date.

---Brett.

On Wed, Nov 26, 2008 at 2:36 PM, Erik Vos <eri...@hc...> wrote:
> The idea was to have a period of testing & bug fixing before the release.
> Say two weeks. Everyone being encouraged to find and report bugs.
>
> BTW I have just fixed the 1851 Louisville upgrade bug, reported by Mark.
> The token movement code was not prepare to handle the special case of a
> token in a city that did not have connections to the tile edges. This fix
> does not yet handle the problem of upgrading the Erie home base in 1830,
> which has TWO such cities.
>
> Erik.
>
>> -----Original Message-----
>> From: brett lentz [mailto:wak...@gm...]
>> Sent: Wednesday 26 November 2008 22:08
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Play by email
>>
>> On Wed, Nov 26, 2008 at 12:25 PM, Erik Vos <eri...@hc...> wrote:
>> >> Sounds good to me.  Let's shoot for the 21st as the
>> release date. That
>> >> gives us nearly a month to get anything else in.
>> >>
>> >> Should this be primarily a bug-fix release, or will you have 1856
>> >> functional by then?  What's left to be implemented?
>> >
>> > No, 1856 is a long haul.
>> > You may have overlooked that I have proposed a "change
>> freeze", which is to
>> > avoid the side effects that my sometimes complex updates
>> sometimes have. In
>> > other words, I will stop working on new features until
>> after the release.
>> >
>> > Fine with me if that would inspire you to move the release
>> to an earlier
>> > date.
>> > Another option might be to put the release into a CVS branch.
>> >
>> > Erik.
>> >
>> >
>>
>> Ok.  Are there any other pending changes?   If not, I could do the
>> release this weekend.
>>
>>
>> ---Brett.
>>
>> --------------------------------------------------------------
>> -----------
>> This SF.Net email is sponsored by the Moblin Your Move
>> Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK &
>> win great prizes
>> Grand prize is a trip for two to an Open Source event
>> anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Play by email

[Mark S. <mar...@gm...>]

Note in any game with an O-O Tile will probably have the same problem.
Part of what I was thinking in my code base (still to be added into
Rails CVS) was to provide in the Upgrade information, not only legal
orientations (to replicate the track), but also information about
where Token on City X gets placed on the Upgraded Tile. It does make
more sense to associate the Side to which the Track the City is
connected to be used to determine where it goes. But for 1851, L&N
Home that might make more sense as just a special-case since once it
gets to the center-city location on the Green Tile the rest of the
upgrades are simple. Or to maybe do a bit of both -- For the Special
Case, encode City 1 goes to Center City on the Upgrade, if no City
Upgrade is specified, use the default logic that you added.

Mark

On Wed, Nov 26, 2008 at 5:36 PM, Erik Vos <eri...@hc...> wrote:
> The idea was to have a period of testing & bug fixing before the release.
> Say two weeks. Everyone being encouraged to find and report bugs.
>
> BTW I have just fixed the 1851 Louisville upgrade bug, reported by Mark.
> The token movement code was not prepare to handle the special case of a
> token in a city that did not have connections to the tile edges. This fix
> does not yet handle the problem of upgrading the Erie home base in 1830,
> which has TWO such cities.
>
> Erik.
>
>> -----Original Message-----
>> From: brett lentz [mailto:wak...@gm...]
>> Sent: Wednesday 26 November 2008 22:08
>> To: Development list for Rails: an 18xx game
>> Subject: Re: [Rails-devel] Play by email
>>
>> On Wed, Nov 26, 2008 at 12:25 PM, Erik Vos <eri...@hc...> wrote:
>> >> Sounds good to me.  Let's shoot for the 21st as the
>> release date. That
>> >> gives us nearly a month to get anything else in.
>> >>
>> >> Should this be primarily a bug-fix release, or will you have 1856
>> >> functional by then?  What's left to be implemented?
>> >
>> > No, 1856 is a long haul.
>> > You may have overlooked that I have proposed a "change
>> freeze", which is to
>> > avoid the side effects that my sometimes complex updates
>> sometimes have. In
>> > other words, I will stop working on new features until
>> after the release.
>> >
>> > Fine with me if that would inspire you to move the release
>> to an earlier
>> > date.
>> > Another option might be to put the release into a CVS branch.
>> >
>> > Erik.
>> >
>> >
>>
>> Ok.  Are there any other pending changes?   If not, I could do the
>> release this weekend.
>>
>>
>> ---Brett.
>>
>> --------------------------------------------------------------
>> -----------
>> This SF.Net email is sponsored by the Moblin Your Move
>> Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK &
>> win great prizes
>> Grand prize is a trip for two to an Open Source event
>> anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Play by email

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

The idea was to have a period of testing & bug fixing before the release. 
Say two weeks. Everyone being encouraged to find and report bugs.

BTW I have just fixed the 1851 Louisville upgrade bug, reported by Mark.
The token movement code was not prepare to handle the special case of a
token in a city that did not have connections to the tile edges. This fix
does not yet handle the problem of upgrading the Erie home base in 1830,
which has TWO such cities.

Erik.

> -----Original Message-----
> From: brett lentz [mailto:wak...@gm...] 
> Sent: Wednesday 26 November 2008 22:08
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Play by email
> 
> On Wed, Nov 26, 2008 at 12:25 PM, Erik Vos <eri...@hc...> wrote:
> >> Sounds good to me.  Let's shoot for the 21st as the 
> release date. That
> >> gives us nearly a month to get anything else in.
> >>
> >> Should this be primarily a bug-fix release, or will you have 1856
> >> functional by then?  What's left to be implemented?
> >
> > No, 1856 is a long haul.
> > You may have overlooked that I have proposed a "change 
> freeze", which is to
> > avoid the side effects that my sometimes complex updates 
> sometimes have. In
> > other words, I will stop working on new features until 
> after the release.
> >
> > Fine with me if that would inspire you to move the release 
> to an earlier
> > date.
> > Another option might be to put the release into a CVS branch.
> >
> > Erik.
> >
> >
> 
> Ok.  Are there any other pending changes?   If not, I could do the
> release this weekend.
> 
> 
> ---Brett.
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] Play by email

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

On Wed, Nov 26, 2008 at 12:25 PM, Erik Vos <eri...@hc...> wrote:
>> Sounds good to me.  Let's shoot for the 21st as the release date. That
>> gives us nearly a month to get anything else in.
>>
>> Should this be primarily a bug-fix release, or will you have 1856
>> functional by then?  What's left to be implemented?
>
> No, 1856 is a long haul.
> You may have overlooked that I have proposed a "change freeze", which is to
> avoid the side effects that my sometimes complex updates sometimes have. In
> other words, I will stop working on new features until after the release.
>
> Fine with me if that would inspire you to move the release to an earlier
> date.
> Another option might be to put the release into a CVS branch.
>
> Erik.
>
>

Ok.  Are there any other pending changes?   If not, I could do the
release this weekend.


---Brett.

Re: [Rails-devel] Play by email

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

> > Since there are no random elements, another way to solve the problem
> > is to generate a human-readable game log.
> >
> > Chris

> We already do. It's location is configured in my.properties and
> written out as 18xx.log
> 
> ---Brett.

Even better: in the Game Status window, select Options and check Report
Window.

A recent change has enabled copying the report contents for any other use. 
We could also add save, print, mail or other options to that window.

Erik.

Re: [Rails-devel] Play by email

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

> As a completely separate issue, when watching the Debugger Console, I
> see the line 'Missing text for key Bank in locale English (en)'
> repeated over and over. Something weird happening there. And in the
> Game Status Window, I see under the Bank Shares/IPO Column the label
> '<Bank>'

My fault. I had localised "Bank" in a place where it was still hardcoded,
and while doing that changed the keyword from BANK to Bank. It seems I
haven't found all uses of that keyword. Guess I can best revert that change.

Erik.

Re: [Rails-devel] Play by email

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

> Sounds good to me.  Let's shoot for the 21st as the release date. That
> gives us nearly a month to get anything else in.
> 
> Should this be primarily a bug-fix release, or will you have 1856
> functional by then?  What's left to be implemented?

No, 1856 is a long haul.
You may have overlooked that I have proposed a "change freeze", which is to
avoid the side effects that my sometimes complex updates sometimes have. In
other words, I will stop working on new features until after the release.

Fine with me if that would inspire you to move the release to an earlier
date.
Another option might be to put the release into a CVS branch.

Erik.

Re: [Rails-devel] Play by email

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

On Mon, Nov 24, 2008 at 5:34 PM, Mark Smith <mar...@gm...> wrote:
> -----------------------
> As a completely separate issue, when watching the Debugger Console, I
> see the line 'Missing text for key Bank in locale English (en)'
> repeated over and over. Something weird happening there. And in the
> Game Status Window, I see under the Bank Shares/IPO Column the label
> '<Bank>'
>
> Mark


Check your localisedText.properties file and verify in the log output
that it is loaded.

---Brett.

Re: [Rails-devel] Play by email

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

On Mon, Nov 24, 2008 at 6:38 PM, Chris Shaffer <chr...@gm...> wrote:
> Well, yeah, I can see why you might want that.  But for now, a stable
> release could permit PBEM among trusted players.
>
> Since there are no random elements, another way to solve the problem
> is to generate a human-readable game log.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>


We already do. It's location is configured in my.properties and
written out as 18xx.log

---Brett.



> On Mon, Nov 24, 2008 at 6:05 PM, Dave Mitton <da...@mi...> wrote:
>> Oh... I don't know about that.
>>
>> It's not jumping ahead a turn, it would be the ability to retroactively change
>> a turn or an asset that would bother me.  "I should have bought that
>> last turn..."
>>
>> I would feel more comfortable in this kind of dynamic if the game generated a
>> crypto hash of the game state and made it visible to all players in the report.
>> And then it should be checked on subsequent turns so that everything
>> was consistent with what was before.
>>
>> I don't know if your code has this feature, but I put it in my 1830
>> program when I was debugging.
>> An auditor pass would run between every turn:
>>         It would count up all the certificates, tokens, anything I
>> could think of
>>         (and that should include cash) to make sure everything was
>> accounted for
>>         and that the program didn't "leak" or "duplicate" any game materials.
>>
>> Dave.
>>
>> On 11/23/2008 09:28 AM, Chris Shaffer wrote:
>>>I think I trust everyone - particularly since there are no random
>>>elements. It's not like we wouldn't notice if the game jumped forward
>>>an OR!
>>>
>>>When do you anticipate the next (relatively) stable release?
>>>
>>>--
>>>Chris
>>>
>>>Please consider the environment before printing this e-mail.
>>>
>>>
>>>
>>>
>>>On Sun, Nov 23, 2008 at 6:17 AM, Erik Vos <eri...@hc...> wrote:
>>> > Yes, you could do it this way (provided that the players trust
>>> each other to
>>> > behave by only playing their own turns).
>>> > For the future we foresee a central server picking up and validating moves,
>>> > and sending around the results, but that may still be a while away.
>>> >
>>> > Be warned, though, that the latest version (1.0.5) is somewhat
>>> buggy, so you
>>> > may want to wait for a next release. The latest available source
>>> code may be
>>> > better, if you can work from that. The trouble is, that adding new features
>>> > occasionally breaks some old code, and so far we have not been very good in
>>> > regression testing.
>>> >
>>> > Perhaps we should better organise releases, for instance by bringing out
>>> > betas and giving people some time to file bug reports (and we must learn to
>>> > remember to actually look at these bug reports!)
>>> >
>>> > Erik.
>>> >
>>> >
>> ...
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Play by email

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

On Mon, Nov 24, 2008 at 6:05 PM, Dave Mitton <da...@mi...> wrote:
> Oh... I don't know about that.
>
> It's not jumping ahead a turn, it would be the ability to retroactively change
> a turn or an asset that would bother me.  "I should have bought that
> last turn..."

Until we implement an actual PBEM facility, the undo feature allows
you to do this.

> I would feel more comfortable in this kind of dynamic if the game generated a
> crypto hash of the game state and made it visible to all players in the report.
> And then it should be checked on subsequent turns so that everything
> was consistent with what was before.
>


What stops someone from generating that hash after they've saved a
bogus game state?

Being an open-source project, there's nothing that prevents someone
from compiling and using their own modified version of the game that
generates correct checksums for invalid data. Being a small project,
we simply don't have anyone volunteering to implement and maintain
additional security mechanisms.

Further, we let the user manually input the value of their train runs.
Not only is this error prone, but it is an easy way for someone to
accidentally give themselves an invalid amount of money. In my
opinion, having someone getting patches in to implement automated
route calculation will reduce a major potential source of error and/or
cheating (depending on your perspective).

I really don't think this should be a big concern. The nice thing
about implementing a board game is that everything the app does can be
done by hand. If you want to validate that the calculations are
correct, the math is fairly basic and well-known. It should be trivial
to find out if something isn't right.


> I don't know if your code has this feature, but I put it in my 1830
> program when I was debugging.
> An auditor pass would run between every turn:
>         It would count up all the certificates, tokens, anything I
> could think of
>         (and that should include cash) to make sure everything was
> accounted for
>         and that the program didn't "leak" or "duplicate" any game materials.
>
>
> Dave.

We currently do not audit the game to that extent. Patches are
welcome, if you'd like to add it.

---Brett.

>
> On 11/23/2008 09:28 AM, Chris Shaffer wrote:
>>I think I trust everyone - particularly since there are no random
>>elements. It's not like we wouldn't notice if the game jumped forward
>>an OR!
>>
>>When do you anticipate the next (relatively) stable release?
>>
>>--
>>Chris
>>
>>Please consider the environment before printing this e-mail.
>>
>>
>>
>>
>>On Sun, Nov 23, 2008 at 6:17 AM, Erik Vos <eri...@hc...> wrote:
>> > Yes, you could do it this way (provided that the players trust
>> each other to
>> > behave by only playing their own turns).
>> > For the future we foresee a central server picking up and validating moves,
>> > and sending around the results, but that may still be a while away.
>> >
>> > Be warned, though, that the latest version (1.0.5) is somewhat
>> buggy, so you
>> > may want to wait for a next release. The latest available source
>> code may be
>> > better, if you can work from that. The trouble is, that adding new features
>> > occasionally breaks some old code, and so far we have not been very good in
>> > regression testing.
>> >
>> > Perhaps we should better organise releases, for instance by bringing out
>> > betas and giving people some time to file bug reports (and we must learn to
>> > remember to actually look at these bug reports!)
>> >
>> > Erik.
>> >
>> >
> ...
>
>

Re: [Rails-devel] Play by email

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

Well, yeah, I can see why you might want that.  But for now, a stable
release could permit PBEM among trusted players.

Since there are no random elements, another way to solve the problem
is to generate a human-readable game log.

--
Chris

Please consider the environment before printing this e-mail.




On Mon, Nov 24, 2008 at 6:05 PM, Dave Mitton <da...@mi...> wrote:
> Oh... I don't know about that.
>
> It's not jumping ahead a turn, it would be the ability to retroactively change
> a turn or an asset that would bother me.  "I should have bought that
> last turn..."
>
> I would feel more comfortable in this kind of dynamic if the game generated a
> crypto hash of the game state and made it visible to all players in the report.
> And then it should be checked on subsequent turns so that everything
> was consistent with what was before.
>
> I don't know if your code has this feature, but I put it in my 1830
> program when I was debugging.
> An auditor pass would run between every turn:
>         It would count up all the certificates, tokens, anything I
> could think of
>         (and that should include cash) to make sure everything was
> accounted for
>         and that the program didn't "leak" or "duplicate" any game materials.
>
> Dave.
>
> On 11/23/2008 09:28 AM, Chris Shaffer wrote:
>>I think I trust everyone - particularly since there are no random
>>elements. It's not like we wouldn't notice if the game jumped forward
>>an OR!
>>
>>When do you anticipate the next (relatively) stable release?
>>
>>--
>>Chris
>>
>>Please consider the environment before printing this e-mail.
>>
>>
>>
>>
>>On Sun, Nov 23, 2008 at 6:17 AM, Erik Vos <eri...@hc...> wrote:
>> > Yes, you could do it this way (provided that the players trust
>> each other to
>> > behave by only playing their own turns).
>> > For the future we foresee a central server picking up and validating moves,
>> > and sending around the results, but that may still be a while away.
>> >
>> > Be warned, though, that the latest version (1.0.5) is somewhat
>> buggy, so you
>> > may want to wait for a next release. The latest available source
>> code may be
>> > better, if you can work from that. The trouble is, that adding new features
>> > occasionally breaks some old code, and so far we have not been very good in
>> > regression testing.
>> >
>> > Perhaps we should better organise releases, for instance by bringing out
>> > betas and giving people some time to file bug reports (and we must learn to
>> > remember to actually look at these bug reports!)
>> >
>> > Erik.
>> >
>> >
> ...
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Play by email

[Dave M. <da...@mi...>]

Oh... I don't know about that.

It's not jumping ahead a turn, it would be the ability to retroactively change
a turn or an asset that would bother me.  "I should have bought that 
last turn..."

I would feel more comfortable in this kind of dynamic if the game generated a
crypto hash of the game state and made it visible to all players in the report.
And then it should be checked on subsequent turns so that everything 
was consistent with what was before.

I don't know if your code has this feature, but I put it in my 1830 
program when I was debugging.
An auditor pass would run between every turn:
         It would count up all the certificates, tokens, anything I 
could think of
         (and that should include cash) to make sure everything was 
accounted for
         and that the program didn't "leak" or "duplicate" any game materials.

Dave.

On 11/23/2008 09:28 AM, Chris Shaffer wrote:
>I think I trust everyone - particularly since there are no random
>elements. It's not like we wouldn't notice if the game jumped forward
>an OR!
>
>When do you anticipate the next (relatively) stable release?
>
>--
>Chris
>
>Please consider the environment before printing this e-mail.
>
>
>
>
>On Sun, Nov 23, 2008 at 6:17 AM, Erik Vos <eri...@hc...> wrote:
> > Yes, you could do it this way (provided that the players trust 
> each other to
> > behave by only playing their own turns).
> > For the future we foresee a central server picking up and validating moves,
> > and sending around the results, but that may still be a while away.
> >
> > Be warned, though, that the latest version (1.0.5) is somewhat 
> buggy, so you
> > may want to wait for a next release. The latest available source 
> code may be
> > better, if you can work from that. The trouble is, that adding new features
> > occasionally breaks some old code, and so far we have not been very good in
> > regression testing.
> >
> > Perhaps we should better organise releases, for instance by bringing out
> > betas and giving people some time to file bug reports (and we must learn to
> > remember to actually look at these bug reports!)
> >
> > Erik.
> >
> >
... 

Re: [Rails-devel] Play by email

[Mark S. <mar...@gm...>]

Looking at the Bug List, I see this Bug (Note mis-spelling is not mine):

1945687  	 1851 Uprgading L&M home base

I have replicated this bug, and added a comment about what I have seen
when replicating it. Basically, when the L&N Home is upgraded, the
Base Token for L&N Appears offset on the Green Provisional Tile, but
is not applied to the Tile when it is made fixed. I do not understand
the mechanics well enough yet to determine why it is going missing.
But performing an Un-Do brings the token and the Yellow Tile back.

It is NOT related the prior fix I applied where I moved the L&N from
the Southern City to the Northern City on the tile (I moved it back to
the southern, and the bug still appeared).

-----------------------
As a completely separate issue, when watching the Debugger Console, I
see the line 'Missing text for key Bank in locale English (en)'
repeated over and over. Something weird happening there. And in the
Game Status Window, I see under the Bank Shares/IPO Column the label
'<Bank>'

Mark

Re: [Rails-devel] Play by email

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

On Mon, Nov 24, 2008 at 1:25 PM, Erik Vos <eri...@hc...> wrote:
>> When do you anticipate the next (relatively) stable release?
>
> No plans yet, but perhaps it is time to do so.
>
> I would propose then to plan a release mid-december, and freeze changes
> until that time except for bug fixing. We can have another pass through the
> bug list, and everybody would be encouraged to test to one's heart's
> content.
>
> Brett, what do you think?
>
> Erik.


Sounds good to me.  Let's shoot for the 21st as the release date. That
gives us nearly a month to get anything else in.

Should this be primarily a bug-fix release, or will you have 1856
functional by then?  What's left to be implemented?


---Brett.

Re: [Rails-devel] Play by email

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

> When do you anticipate the next (relatively) stable release?

No plans yet, but perhaps it is time to do so.

I would propose then to plan a release mid-december, and freeze changes
until that time except for bug fixing. We can have another pass through the
bug list, and everybody would be encouraged to test to one's heart's
content.

Brett, what do you think?

Erik.

Re: [Rails-devel] Play by email

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

I think I trust everyone - particularly since there are no random
elements. It's not like we wouldn't notice if the game jumped forward
an OR!

When do you anticipate the next (relatively) stable release?

--
Chris

Please consider the environment before printing this e-mail.




On Sun, Nov 23, 2008 at 6:17 AM, Erik Vos <eri...@hc...> wrote:
> Yes, you could do it this way (provided that the players trust each other to
> behave by only playing their own turns).
> For the future we foresee a central server picking up and validating moves,
> and sending around the results, but that may still be a while away.
>
> Be warned, though, that the latest version (1.0.5) is somewhat buggy, so you
> may want to wait for a next release. The latest available source code may be
> better, if you can work from that. The trouble is, that adding new features
> occasionally breaks some old code, and so far we have not been very good in
> regression testing.
>
> Perhaps we should better organise releases, for instance by bringing out
> betas and giving people some time to file bug reports (and we must learn to
> remember to actually look at these bug reports!)
>
> Erik.
>
>
>
>
>> -----Original Message-----
>> From: Chris Shaffer [mailto:chr...@gm...]
>> Sent: Sunday 23 November 2008 02:30
>> To: Development list for Rails: an 18xx game
>> Subject: [Rails-devel] Play by email
>>
>> I've downloaded and played around with Rails for the first time in a
>> while.  It seems to me it is ready for play by email.  I load the
>> game, take my turn, save the game, email it to the next player.
>> Continue until the game is complete.
>>
>> Is there some snag that I'm not seeing?
>>
>> --
>> Chris
>>
>> Please consider the environment before printing this e-mail.
>>
>> --------------------------------------------------------------
>> -----------
>> This SF.Net email is sponsored by the Moblin Your Move
>> Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK &
>> win great prizes
>> Grand prize is a trip for two to an Open Source event
>> anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Play by email

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

Yes, you could do it this way (provided that the players trust each other to
behave by only playing their own turns). 
For the future we foresee a central server picking up and validating moves,
and sending around the results, but that may still be a while away.

Be warned, though, that the latest version (1.0.5) is somewhat buggy, so you
may want to wait for a next release. The latest available source code may be
better, if you can work from that. The trouble is, that adding new features
occasionally breaks some old code, and so far we have not been very good in
regression testing.

Perhaps we should better organise releases, for instance by bringing out
betas and giving people some time to file bug reports (and we must learn to
remember to actually look at these bug reports!)

Erik.




> -----Original Message-----
> From: Chris Shaffer [mailto:chr...@gm...] 
> Sent: Sunday 23 November 2008 02:30
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Play by email
> 
> I've downloaded and played around with Rails for the first time in a
> while.  It seems to me it is ready for play by email.  I load the
> game, take my turn, save the game, email it to the next player.
> Continue until the game is complete.
> 
> Is there some snag that I'm not seeing?
> 
> --
> Chris
> 
> Please consider the environment before printing this e-mail.
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

[Rails-devel] Play by email

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

I've downloaded and played around with Rails for the first time in a
while.  It seems to me it is ready for play by email.  I load the
game, take my turn, save the game, email it to the next player.
Continue until the game is complete.

Is there some snag that I'm not seeing?

--
Chris

Please consider the environment before printing this e-mail.

Re: [Rails-devel] delurking with a quick ReportWindow fix

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

On Sat, Nov 22, 2008 at 9:22 AM, Erik Vos <eri...@hc...> wrote:
>> The most recent information that I had is that "unified diff"
>> was still the preferred format for beginning contributions.
>> If that should be changed, just let me know.
>>
>> I don't see how to save the contents of an Eclipse "source
>> compare" view in any meaningful way.  I must add that
>> whenever a non-coding task can be performed in Cygwin/Emacs
>> instead of Eclipse, I almost always do so. :-)
>
> Eclipse can create unified diffs via (right-click)Team/Create Patch, see
> example below.
> The paths in this patch do have date/time, so that can't have been the
> problem after all.
> And this patch can be applied via Team/Apply Patch.
>
> Perhaps it's more important that there is no "orig" in the paths; indeed I
> also had to remove that stuff and make both paths equal to have Eclipse
> accept the previous patches.
>

This is likely the issue.  The patch command has a flag to specify the
number of directories to strip off the patch's location.

> N.B. The below patch only removes some dead code. I have committed it.
>
> Erik
>

---Brett

Re: [Rails-devel] delurking with a quick ReportWindow fix

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

> The most recent information that I had is that "unified diff" 
> was still the preferred format for beginning contributions.  
> If that should be changed, just let me know.
> 
> I don't see how to save the contents of an Eclipse "source 
> compare" view in any meaningful way.  I must add that 
> whenever a non-coding task can be performed in Cygwin/Emacs 
> instead of Eclipse, I almost always do so. :-)

Eclipse can create unified diffs via (right-click)Team/Create Patch, see
example below.
The paths in this patch do have date/time, so that can't have been the
problem after all.
And this patch can be applied via Team/Apply Patch.

Perhaps it's more important that there is no "orig" in the paths; indeed I
also had to remove that stuff and make both paths equal to have Eclipse
accept the previous patches.

N.B. The below patch only removes some dead code. I have committed it.

Erik


### Eclipse Workspace Patch 1.0
#P Rails
Index: rails/game/GameManager.java
===================================================================
RCS file: /cvsroot/rails/18xx/rails/game/GameManager.java,v
retrieving revision 1.35
diff -u -r1.35 GameManager.java
--- rails/game/GameManager.java	26 Oct 2008 20:47:37 -0000	1.35
+++ rails/game/GameManager.java	22 Nov 2008 17:12:15 -0000
@@ -54,7 +54,6 @@
     protected int currentNumberOfOperatingRounds = 1;
     protected boolean skipFirstStockRound = false;
 
-    //protected boolean companiesCanBuyPrivates = false;
     protected boolean gameEndsWithBankruptcy = false;
     protected int gameEndsWhenBankHasLessOrEqual = 0;
     protected boolean gameEndsAfterSetOfORs = true;
@@ -542,8 +541,6 @@
         }
 
         // Note: round may have changed!
-        // log.debug("Calling setPossibleActions for round
-        // "+getCurrentRound().toString());
         possibleActions.clear();
         getCurrentRound().setPossibleActions();
 
@@ -612,8 +609,7 @@
     }
 
     public void finishShareSellingRound() {
-        // currentRound = interruptedRound;
-        setRound(interruptedRound);
+         setRound(interruptedRound);
         ((OperatingRound) getCurrentRound()).resumeTrainBuying();
     }
 
@@ -815,57 +811,14 @@
         }
     }
 
-    /*
-    public static void setCompaniesCanBuyPrivates() {
-        instance.companiesCanBuyPrivates = true;
-    }
-    */
-
     public String getHelp() {
         return getCurrentRound().getHelp();
     }
 
-    /*
-    public static void setHasAnyParPrice(boolean hasAnyParPrice) {
-        instance.hasAnyParPrice = hasAnyParPrice;
-    }
-    */
-
     public boolean canAnyCompanyHoldShares() {
         return canAnyCompanyHoldShares;
     }
 
-    /*
-    public static void setCanAnyCompanyHoldShares(
-            boolean canAnyCompanyHoldShares) {
-        instance.canAnyCompanyHoldShares = canAnyCompanyHoldShares;
-    }
-    */
-
-    /*
-    public static boolean canAnyCompBuyPrivates() {
-        return instance.canAnyCompBuyPrivates;
-    }
-    */
-
-    /*
-    public static void setCanAnyCompBuyPrivates(boolean
canAnyCompBuyPrivates) {
-        instance.canAnyCompanyBuyPrivates = canAnyCompBuyPrivates;
-    }
-    */
-
-    /*
-    public static boolean doBonusTokensExist() {
-        return instance.bonusTokensExist;
-    }
-    */
-
-    /*
-    public static void setBonusTokensExist(boolean bonusTokensExist) {
-        instance.bonusTokensExist = bonusTokensExist;
-    }
-    */
-    
     public String getClassName (Defs.ClassName key) {
         
         switch (key) {