rails-devel — List for discussion of Rails development

Re: [Rails-devel] compliments and request for any docs

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

I downloaded the software and it seems to run fine until I get to the start
of the first operating round. I just can't figure out how to lay a tile. Is
there any documentation   available? 
 

No, but you have stumbled upon a fatal bug in version 1.1.0.  Please upgrade
to 1.1.1.
 
Erik.  

Re: [Rails-devel] compliments and request for any docs

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

On Tue, Dec 22, 2009 at 9:35 PM, Gary at Haunted Game Cafe
<ga...@ha...> wrote:
> [...] the start
> of the first operating round. I just can't figure out how to lay a tile.

What happens when you click on an available hex? You *should* have the
available tiles for that hex show up on the left-hand side.

Are you using Rails 1.1.1?  I had some problems with odd broken map
displays in 1.1.0

 - Aliza

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automaticroute calculation

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

	do note that legal tile/track placement would be a prerequisite
feature for route calculation.

That's indeed where I would start (once I have found the time and courage -
perhaps after my retirement 17 months from now :-)

Erik.

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

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

Hi all,

thanks for your replies.

I'm astonished of the list of difficulties for implementing this feature (I
was aware of quite none of them).

Given the very unfavorable cost/benefit ratio of this feature, I now fully
understand that it is given low priority.

Cheers,
Frederick

[Rails-devel] compliments and request for any docs

[Gary at H. G. C. <ga...@ha...>]

Hello Rails project.

I apologize if this is the wrong forum to address this.

I downloaded the software and it seems to run fine until I get to the start
of the first operating round. I just can't figure out how to lay a tile. Is
there any documentation available?

Thank you very much.
Gary Sproul

The Haunted Game Cafe
3307 S College Ave
Fort Collins, CO 80525
(970) 402-2466
HauntedGameCafe.com

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

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

An added layer of weirdness:  tiles are not monolithic.

split city, hitting both sides allowed (1830, 1856, 18FR, 18Mex, etc.)
split city, hitting both sides not allowed (1873)
split city, values differ (18Mex, 1860)

optional dits: 1860
free dits: 18Mex
dits count: 1830, 1856, etc.
N+M trains: lots

I won't even get into hex trains,
this-train-class-may-not-hit-this-city, blocking vs. non-blocking
tokens, etc.

(I'll also note that in general, 1860 is flat out weird; I would not
hold my breath for any automated implementation.)

I suspect a table of all the possible properties of 18xx trains would
be quite voluminous. (...  and now I want to design a game with
half-revenue for soft-rusted trains...)

 - Aliza

On Tue, Dec 22, 2009 at 4:25 PM, Jim Black <jim...@ya...> wrote:
>
> On Dec 22, 2009, at 4:04 PM, Mark Smith wrote:
>
>> I would look forward to the ability to select the route manually, center-by-center, tile track-by-tile track, highlighting the route as you go. And on successive turns, the previous route would be highlited (saved for re-use) and allow for modifications if the director chooses... or if the route is compromised (a token gets laid in the center blocking it from use for example), it requires a re-evaluation.
>>
>> There has been talk about implementing a "route-awareness" where it would enforce tile lays that a company can perform. I would see the capability to manually select the route (and the subsequent semi-auto summing up) as a next step towards true auto-route calculation.
>>
>> And for those that state "I really don't want to pick my own route!"... I reply, that once the full auto-route calculation is implemented (somewhere down the road), the option to manually select the route can be an option you can turn-on or off as your preference.
>
> I also think this would be an excellent way for rails to add route awareness- allow users to specify the route(s) manually, rails saves the result (and, perhaps, offers the resulting math/total for the earnings).
>
> Other players can now see the route(s) visually, too, which makes it easier for them to verify that it's all legal (right now we have to cross-reference hex coordinates, it's painstaking).
>
> That approach would be great, and require no "route finding" algorithms or even "legal track" awareness.  The user would just tie the route together manually, as Mark suggests.
>
> -  jim
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

[Jim B. <jim...@ya...>]

On Dec 22, 2009, at 4:04 PM, Mark Smith wrote:

> I would look forward to the ability to select the route manually, center-by-center, tile track-by-tile track, highlighting the route as you go. And on successive turns, the previous route would be highlited (saved for re-use) and allow for modifications if the director chooses... or if the route is comprimised (a token gets laid in the center blocking it from use for example), it requires a re-evaluation. 
> 
> There has been talk about implementing a "route-awareness" where it would enforce tile lays that a company can perform. I would see the capability to manually select the route (and the subsequent semi-auto summing up) as a next step towards true auto-route calculation.
> 
> And for those that state "I really don't want to pick my own route!"... I reply, that once the full auto-route calculation is implemented (somewhere down the road), the option to manually select the route can be an option you can turn-on or off as your preference.

I also think this would be an excellent way for rails to add route awareness- allow users to specify the route(s) manually, rails saves the result (and, perhaps, offers the resulting math/total for the earnings).

Other players can now see the route(s) visually, too, which makes it easier for them to verify that it's all legal (right now we have to cross-reference hex coordinates, it's painstaking).  

That approach would be great, and require no "route finding" algorithms or even "legal track" awareness.  The user would just tie the route together manually, as Mark suggests.

-  jim

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

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

One item that I have not seen discussed about route calculation is that in
the board game the director is forced to calculate the route. He may, with
all the best intentions, seek to find the best route, but fails. And as has
been stated, there are games where another "shareholder" (or simply any
other player) MAY specify a better route. It is not a rule requirement that
the best route MUST be found. The other players may choose to ignore to fact
the route is not the best (or they fail to find a better route that is
there).

My point is that within 18xx I feel it is a very important part of the game
to find your optimal route. And I would look forward to the ability to
select the route manually, center-by-center, tile track-by-tile track,
highlighting the route as you go. And on successive turns, the previous
route would be highlited (saved for re-use) and allow for modifications if
the director chooses... or if the route is comprimised (a token gets laid in
the center blocking it from use for example), it requires a re-evaluation.

There has been talk about implementing a "route-awareness" where it would
enforce tile lays that a company can perform. I would see the capability to
manually select the route (and the subsequent semi-auto summing up) as a
next step towards true auto-route calculation.

And for those that state "I really don't want to pick my own route!"... I
reply, that once the full auto-route calculation is implemented (somewhere
down the road), the option to manually select the route can be an option you
can turn-on or off as your preference.

Mark

On Tue, Dec 22, 2009 at 5:48 PM, John A. Tamplin <ja...@ja...> wrote:

> On Tue, Dec 22, 2009 at 5:18 AM, Frederick Weld <
> fre...@go...> wrote:
>
>> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
>> graph) for route calculation is updated whenever someone lays a tile. By
>> doing this, you get a very low constant factor of the time the algorithm
>> needs, meaning you'll still have exponential time but you won't perceive
>> this until the size of the graph becomes very large.
>>
>
> Also note that PC 1830 frequently computed incorrect routes.
>
> Building the connectivity graph isn't actually the time-consuming part (and
> as you say, is trivial to build incrementally).  Also, building a route
> calculation engine that didn't have to work for multiple games would
> probably work ok, but when you start adding things like bonuses that depend
> on which stops you make, trains that can skip cities, etc, all the heuristic
> graph algorithms go out the window.
>
> --
> John A. Tamplin
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

[John A. T. <ja...@ja...>]

On Tue, Dec 22, 2009 at 5:18 AM, Frederick Weld <
fre...@go...> wrote:

> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
> graph) for route calculation is updated whenever someone lays a tile. By
> doing this, you get a very low constant factor of the time the algorithm
> needs, meaning you'll still have exponential time but you won't perceive
> this until the size of the graph becomes very large.
>

Also note that PC 1830 frequently computed incorrect routes.

Building the connectivity graph isn't actually the time-consuming part (and
as you say, is trivial to build incrementally).  Also, building a route
calculation engine that didn't have to work for multiple games would
probably work ok, but when you start adding things like bonuses that depend
on which stops you make, trains that can skip cities, etc, all the heuristic
graph algorithms go out the window.

-- 
John A. Tamplin

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

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

Another thing that varies by game -- the president/director/current
plunderer of a railroad may or may not be required to use the optimal
route. (Yes, there are situations where you would want $10 less of
income.)

This is often stated in the rules as "if any shareholder can point out
a better route, the director is required to use it."

Another possibility for tinkering would be games where there's a
payment to an owner of a map feature.

In 1844 there's an explicit rule that you can't run a suboptimal route
just to get the virgin run through a tunnel/mountain.

Perhaps the optimal path would be a route suggestion feature; ideally
this would be something you could use (and not save!) even when it's
not that railroad's turn, to help people parallel-process their turns.

 - Aliza

On Tue, Dec 22, 2009 at 2:41 PM, Jim Black <jim...@ya...> wrote:
>
> Frederick-
>
> Best of luck with the new feature development- what an awesome way to join the rails team !!!   ;-)
>
> More seriously, do note that legal tile/track placement would be a prerequisite feature for route calculation.
>
> In our user groups- using rails for pbem- this wouldn't take priority over any of the other stuff Erik and Brett have been working on.
>
> Adding up routes is a pain, but it's a well-understood pain, and it's actually straightforward to note the stuff for pbem (works way better than f2f for this).
>
> As Aliza mentioned, route bonuses & rules get complicated really quickly, across the 18xx- we avoid critical Rails bottlenecks getting this straight, if we just/simply continue typing in the earnings each turn.
>
> I'm not saying it wouldn't be a nice feature, but it sounds like it's been carefully evaluated by the developers (here and in the yahoo group) and would be a lot of work.
>
>  - jim
>
>
> On Dec 22, 2009, at 2:19 PM, brett lentz wrote:
>
>> We agree with you that route calculation is important, but so are many
>> other things that are far easier to implement.
>>
>> If you're volunteering to write the code, great. Just let us know when
>> to expect your first set of patches.
>>
>> Let me know if you need any help checking out the code so that you can
>> get started helping us add this feature.
>>
>> ---Brett.
>>
>>
>>
>> On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld
>> <fre...@go...> wrote:
>>> Hi developers,
>>>
>>> I was wondering why this feature is prioritized so low. For me, this would
>>> be THE reason to use the computer instead of a physical board.
>>>
>>> Is it that you need a good algorithm before implementing this? In such a
>>> case, please consider the following:
>>> (1) Even though the brute force algorithm wouldn't be in O(n^p), it will
>>> probably be ok for non-diesel runs.
>>> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
>>> graph) for route calculation is updated whenever someone lays a tile. By
>>> doing this, you get a very low constant factor of the time the algorithm
>>> needs, meaning you'll still have exponential time but you won't perceive
>>> this until the size of the graph becomes very large.
>>>
>>> What do you think about that?
>>>
>>> Best Regards,
>>> Frederick
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>> Take advantage of Verizon's best-in-class app development support
>>> A streamlined, 14 day to market process makes app distribution fast and easy
>>> Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

[Jim B. <jim...@ya...>]

Frederick-

Best of luck with the new feature development- what an awesome way to join the rails team !!!   ;-)

More seriously, do note that legal tile/track placement would be a prerequisite feature for route calculation.

In our user groups- using rails for pbem- this wouldn't take priority over any of the other stuff Erik and Brett have been working on.

Adding up routes is a pain, but it's a well-understood pain, and it's actually straightforward to note the stuff for pbem (works way better than f2f for this).  

As Aliza mentioned, route bonuses & rules get complicated really quickly, across the 18xx- we avoid critical Rails bottlenecks getting this straight, if we just/simply continue typing in the earnings each turn.

I'm not saying it wouldn't be a nice feature, but it sounds like it's been carefully evaluated by the developers (here and in the yahoo group) and would be a lot of work.

 - jim

 
On Dec 22, 2009, at 2:19 PM, brett lentz wrote:

> We agree with you that route calculation is important, but so are many
> other things that are far easier to implement.
> 
> If you're volunteering to write the code, great. Just let us know when
> to expect your first set of patches.
> 
> Let me know if you need any help checking out the code so that you can
> get started helping us add this feature.
> 
> ---Brett.
> 
> 
> 
> On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld
> <fre...@go...> wrote:
>> Hi developers,
>> 
>> I was wondering why this feature is prioritized so low. For me, this would
>> be THE reason to use the computer instead of a physical board.
>> 
>> Is it that you need a good algorithm before implementing this? In such a
>> case, please consider the following:
>> (1) Even though the brute force algorithm wouldn't be in O(n^p), it will
>> probably be ok for non-diesel runs.
>> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
>> graph) for route calculation is updated whenever someone lays a tile. By
>> doing this, you get a very low constant factor of the time the algorithm
>> needs, meaning you'll still have exponential time but you won't perceive
>> this until the size of the graph becomes very large.
>> 
>> What do you think about that?
>> 
>> Best Regards,
>> Frederick
>> 
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
>> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

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

Run calculation algorithms were discussed at length on the 18xx YahooGroup
mailing list recently. It's not a simple problem, but you are correct that
it is not insurmountable.

That said, many people feel such as myself feel there are LOTS of reasons to
use the computer instead of a physical board. In particular, it's fairly
difficult to use a physical board when I'm playing a game with someone in in
Chicago and another player in Ohio, considering that I live in Oregon.
However, thanks to rails, I am now playing exactly that game by email.  For
play-by-email, Rails has many advantages over the traditional
Vassal/CyberBoard/spreadsheet/human-moderator solutions.  Rules enforcement,
good text logging, automatic funds distribution, turn-order tracking... the
list of benefits Rails provides goes on and on and on...

As on any open source software project, the developers put their time where
they feel the most interest or need.  Clearly, the developers are focusing
on adding new games, supporting pbem, and some usability enhancements at the
moment.  Since they are volunteers, we have an interest in them spending
their time on things that interest them, otherwise they will burn out and
depart.

As was noted, more developers are welcome.  I personally don't have the
skill or time (though I might get it together to put together some xml files
for a few new games) but I very much appreciate the work of those who do.

--
Chris

Please consider the environment before printing this e-mail.


On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld <
fre...@go...> wrote:

> Hi developers,
>
> I was wondering why this feature is prioritized so low. For me, this would
> be THE reason to use the computer instead of a physical board.
>
> Is it that you need a good algorithm before implementing this? In such a
> case, please consider the following:
> (1) Even though the brute force algorithm wouldn't be in O(n^p), it will
> probably be ok for non-diesel runs.
> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
> graph) for route calculation is updated whenever someone lays a tile. By
> doing this, you get a very low constant factor of the time the algorithm
> needs, meaning you'll still have exponential time but you won't perceive
> this until the size of the graph becomes very large.
>
> What do you think about that?
>
> Best Regards,
> Frederick
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

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

We agree with you that route calculation is important, but so are many
other things that are far easier to implement.

If you're volunteering to write the code, great. Just let us know when
to expect your first set of patches.

Let me know if you need any help checking out the code so that you can
get started helping us add this feature.

---Brett.



On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld
<fre...@go...> wrote:
> Hi developers,
>
> I was wondering why this feature is prioritized so low. For me, this would
> be THE reason to use the computer instead of a physical board.
>
> Is it that you need a good algorithm before implementing this? In such a
> case, please consider the following:
> (1) Even though the brute force algorithm wouldn't be in O(n^p), it will
> probably be ok for non-diesel runs.
> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
> graph) for route calculation is updated whenever someone lays a tile. By
> doing this, you get a very low constant factor of the time the algorithm
> needs, meaning you'll still have exponential time but you won't perceive
> this until the size of the graph becomes very large.
>
> What do you think about that?
>
> Best Regards,
> Frederick
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic routecalculation

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

Hi Frederick.
 
Opinions on what has most priority seem to vary.
 
I agree that your suggestion (2) would probably the way to do it.
 
We only have to find someone willing and able and having the time to
implement this feature....
 
Erik.


  _____  

From: Frederick Weld [mailto:fre...@go...] 
Sent: Tuesday 22 December 2009 11:19
To: rai...@li...
Subject: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic
routecalculation


Hi developers,
 
I was wondering why this feature is prioritized so low. For me, this would
be THE reason to use the computer instead of a physical board.
 
Is it that you need a good algorithm before implementing this? In such a
case, please consider the following:
(1) Even though the brute force algorithm wouldn't be in O(n^p), it will
probably be ok for non-diesel runs.
(2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
graph) for route calculation is updated whenever someone lays a tile. By
doing this, you get a very low constant factor of the time the algorithm
needs, meaning you'll still have exponential time but you won't perceive
this until the size of the graph becomes very large.
 
What do you think about that?
 
Best Regards,
Frederick
 

Re: [Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

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

This would be awesome, but so many 18xx variants have variations on
the calculations:

dedicated destination runs
special trains like the Ghan in 1848
token ignores for special routes (1873)
limited-use token ignores (1860)
X-to-Y bonuses (18West, 18Ardennes, others)
Off-board variation by train type (1889 has offboard values reserved
for Diesel trains)
Requirements for route intersections
Owned vs. unowned bonus tokens (1870)

...  and those are just the ones I know off the top of my head.

I agree, though, that automatic route calculations, or at least
suggestions, would be awesome.

A GUI tool to help pick routes would be a lot more programming work,
but would be more useful and flexible in the long run, I think.

 - Aliza

On Tue, Dec 22, 2009 at 2:18 AM, Frederick Weld
<fre...@go...> wrote:
> Hi developers,
>
> I was wondering why this feature is prioritized so low. For me, this would
> be THE reason to use the computer instead of a physical board.
>
> Is it that you need a good algorithm before implementing this? In such a
> case, please consider the following:
> (1) Even though the brute force algorithm wouldn't be in O(n^p), it will
> probably be ok for non-diesel runs.
> (2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
> graph) for route calculation is updated whenever someone lays a tile. By
> doing this, you get a very low constant factor of the time the algorithm
> needs, meaning you'll still have exponential time but you won't perceive
> this until the size of the graph becomes very large.
>
> What do you think about that?
>
> Best Regards,
> Frederick
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

[Rails-devel] 18xx Rails: Feature Request 1517702 - automatic route calculation

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

Hi developers,

I was wondering why this feature is prioritized so low. For me, this would
be THE reason to use the computer instead of a physical board.

Is it that you need a good algorithm before implementing this? In such a
case, please consider the following:
(1) Even though the brute force algorithm wouldn't be in O(n^p), it will
probably be ok for non-diesel runs.
(2) What SimTex's 1830 (most probably) does: A separate model (multi-edge
graph) for route calculation is updated whenever someone lays a tile. By
doing this, you get a very low constant factor of the time the algorithm
needs, meaning you'll still have exponential time but you won't perceive
this until the size of the graph becomes very large.

What do you think about that?

Best Regards,
Frederick

Re: [Rails-devel] Save-file compatibility issues

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

On Mon, Dec 21, 2009 at 6:21 AM, Jeffrey Brent McBeth <mc...@br...> wrote:
> On Mon, Dec 21, 2009 at 05:24:32AM -0800, Chris Shaffer wrote:
>> Could you explicate the security issues?  We are currently doing exactly
>> this, and it works just fine.  It is also convenient for multiplatform - all
>> I need is access to Dropbox, and it doesn't matter if I'm on my home Ubuntu,
>> my work Mac, etc...
>
> Running an application local to your machine is a security risk only
> if your machine has been compromised.
>
> Running an application across the network is a security risk if your
> machine, the protocol, or the remote machine have been compromised.
>

When the remote disk is something like a Dropbox share, I also need to
trust everyone else with access to the share.

I don't think there are viruses that infect .jar files just yet, but
I'm sure that will happen eventually.

 - Aliza

Re: [Rails-devel] 1856 in Rails 1.1.0 -- error starting 1856 game

[Jim B. <jim...@ya...>]

> The only problem is that a version difference does not always imply incompability.

It does, more than Rails seems to realize.  

Sometimes a newer version will successfully load an older version's save, but present a different resulting state/game- different $$ balance, different stock prices, etc.  The Rails users I'm playing with all are having problems with this issue, and the resulting difficulty of running / maintaining multiple versions in parallel across different games, etc.  

> I plan to return to implementing new games (maybe also because 2 out of 2 
> voters in the 18xx Yahoo group found that the most important new development to do :-).

I'm not meaning to be negative, I'm a big Rails fan- but, I do think that stability, and more work with version-to-version compatibility, is a higher priority than new game support, features for online play, etc.  That's just one vote (mine)- but, by my math, that means you have registered at least 3 votes/opinions- not just 2.  ;)
 
 - jim

On Dec 21, 2009, at 10:13 AM, Erik Vos wrote:

> Your proposal makes much sense. The only problem is that a version
> difference does not always imply incompability.
>  
> In fact two different version numbers are already included in
> saved files: the public one, and an internally hardcoded one.
> The latter one in fact does the incompatibility check,
> but right now it just aborts loading.
> You may see it at work when loading VERY old saved files.
>  
> I like your proposal to let the user decide instead.
> But that will not help out with the current version.
>  
> Erik.
> 
> From: Mark Smith [mailto:mar...@gm...] 
> Sent: Monday 21 December 2009 18:47
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 in Rails 1.1.0 -- error starting 1856 game
> 
> Erik,
> 
> One of the items you mentioned is to prevent a new version from being able to open an older (incompatible) saved game.
> 
> What might be very simple is to add an "<VERSION>1.1.1</VERSION>" tag to the save game file (at the begining). If the tag is NOT present, display a warning dialog "Save File does not appear to be a compatible version, Load Anyway?" with a YES, and NO button. This would allow a player to try and load it, but the player is warned.
> 
> Mark
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 in Rails 1.1.0 -- error starting 1856 game

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

Your proposal makes much sense. The only problem is that a version
difference does not always imply incompability. 
 
In fact two different version numbers are already included in
saved files: the public one, and an internally hardcoded one.
The latter one in fact does the incompatibility check, 
but right now it just aborts loading. 
You may see it at work when loading VERY old saved files. 
 
I like your proposal to let the user decide instead.
But that will not help out with the current version.
 
Erik.


  _____  

From: Mark Smith [mailto:mar...@gm...] 
Sent: Monday 21 December 2009 18:47
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 in Rails 1.1.0 -- error starting 1856 game


Erik,

One of the items you mentioned is to prevent a new version from being able
to open an older (incompatible) saved game.

What might be very simple is to add an "<VERSION>1.1.1</VERSION>" tag to the
save game file (at the begining). If the tag is NOT present, display a
warning dialog "Save File does not appear to be a compatible version, Load
Anyway?" with a YES, and NO button. This would allow a player to try and
load it, but the player is warned.

Mark

Re: [Rails-devel] 1856 in Rails 1.1.0 -- error starting 1856 game

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

Erik,

One of the items you mentioned is to prevent a new version from being able
to open an older (incompatible) saved game.

What might be very simple is to add an "<VERSION>1.1.1</VERSION>" tag to the
save game file (at the begining). If the tag is NOT present, display a
warning dialog "Save File does not appear to be a compatible version, Load
Anyway?" with a YES, and NO button. This would allow a player to try and
load it, but the player is warned.

Mark

Re: [Rails-devel] Save-file compatibility issues

[Jeffrey B. M. <mc...@br...>]

On Mon, Dec 21, 2009 at 05:24:32AM -0800, Chris Shaffer wrote:
> Could you explicate the security issues?  We are currently doing exactly
> this, and it works just fine.  It is also convenient for multiplatform - all
> I need is access to Dropbox, and it doesn't matter if I'm on my home Ubuntu,
> my work Mac, etc...

Running an application local to your machine is a security risk only
if your machine has been compromised.

Running an application across the network is a security risk if your
machine, the protocol, or the remote machine have been compromised.

Jeff

-- 
----------------------------------------------------------------------------
"The man who does not read good books has no advantage over 
 the man who cannot read them."
 -- Mark Twain
----------------------------------------------------------------------------

Re: [Rails-devel] Save-file compatibility issues

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

Could you explicate the security issues?  We are currently doing exactly
this, and it works just fine.  It is also convenient for multiplatform - all
I need is access to Dropbox, and it doesn't matter if I'm on my home Ubuntu,
my work Mac, etc...

--
Chris

Please consider the environment before printing this e-mail.


On Mon, Dec 21, 2009 at 2:00 AM, Aliza Panitz <ali...@gm...>wrote:

> For those who use Dropbox or other file-sharing tools, perhaps put a
> copy of the correct version of Rails in the same directory as the
> savefiles?  It's not that big... though the security issues in
> executing code from the network are a possible stopper.
>
>  - Aliza
>
> On Sun, Dec 20, 2009 at 7:28 PM, Jim Black <jim...@ya...>
> wrote:
> > I do switch versions w/ different games, but it's quite awkward, and
> error
> > prone.  More problematic, it causes cascading interdependencies across
> > players- where everyone has to upgrade in step, and run multiple
> different
> > versions across their different games, etc.
> > Surprisingly, in practice the combinatorials get out of hand really
> quickly-
> > it seems to be causing a lot of problems across players and games, at
> > present.
> >
> >
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1856 in Rails 1.1.0 -- error starting 1856 game

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

See inserts below.
 


  _____  

From: Jim Black [mailto:jim...@ya...] 
Sent: Monday 21 December 2009 04:28
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 in Rails 1.1.0 -- error starting 1856 game


I do switch versions w/ different games, but it's quite awkward, and error
prone.  More problematic, it causes cascading interdependencies across
players- where everyone has to upgrade in step, and run multiple different
versions across their different games, etc.   


Surprisingly, in practice the combinatorials get out of hand really quickly-
it seems to be causing a lot of problems across players and games, at
present.

Hopefully Rails will turn out to be more stable in the near future.
A lot has happened recently, and some behind-the-scenes structural 
changes have had more side-effects (i.e. caused bugs) than I had
expected. 
 
I think that all has about settled now, the GUI looks better in several
respects,
and once it's clear that there are no more critical bugs, I plan to return
to implementing new games (maybe also because 2 out of 2 voters in the 
18xx Yahoo group found that the most important new development to do :-).
 


Given how much work it's taken getting 1856 up and running even
partway, how much development is being put into making it easier to
extend Rails to new games?

 - Aliza


The current plan is first to look at the two now half-implemented games 1835
and 1870. 
Each one has quite some new aspects that will need fairly extensive
programming,
so I can't tell when anything gets finished.
 
I'm constantly trying to implement new features in a generic way, so that 
other games with the same feature might be easier to do, but it doesn't
always work out like that. In general it is impossible to predict how hard
implementing a new feature is. Sometimes it's a matter of hours, sometimes
days, weeks or months. 
 
1856 took almost a year, partly because the CGR formation with all its
details 
was very hard to get right in all possible permutations of circumstances.
Now that such a merger has been done, others may turn out to be easier to do
(such as the 1835 Prussian merger), but equally well, they may not.
 
Another example: private special properties have almost always been
difficult. 
By now, enough groundwork might have been done to make future ones easier
to do, but there is no guarantee. 
 
Last of all, the time I can (and want to) spend on this work fluctuates
heavily.
I also have a day job, a family, and several more hobbies....
 
Erik.

Re: [Rails-devel] 1856 in Rails 1.1.0 -- error starting 1856 game

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

> It's really easy to accidentally open a game in the wrong 
> version and trash it.
> 

I could have updated the built-in version number that prevents 
you from loading old save files into newer Rails versions. 
I didn't just because I completely overlooked it. 
And if I hadn't I might have skipped it equally well, 
for various reasons. In fact I'm now actively trying
to avoid the need to declare such version incompatibilities.

I believe that with 1.1.0, only some old save files 
don't work any longer (because these had invalid moves),
which (if I had thought about it) might have been another 
reason to avoid making the loading of old save files impossible.
Most of my own save files used for testing still work.

[Rails-devel] Save-file compatibility issues

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

For those who use Dropbox or other file-sharing tools, perhaps put a
copy of the correct version of Rails in the same directory as the
savefiles?  It's not that big... though the security issues in
executing code from the network are a possible stopper.

 - Aliza

On Sun, Dec 20, 2009 at 7:28 PM, Jim Black <jim...@ya...> wrote:
> I do switch versions w/ different games, but it's quite awkward, and error
> prone.  More problematic, it causes cascading interdependencies across
> players- where everyone has to upgrade in step, and run multiple different
> versions across their different games, etc.
> Surprisingly, in practice the combinatorials get out of hand really quickly-
> it seems to be causing a lot of problems across players and games, at
> present.
>
>