rails-devel — List for discussion of Rails development

Re: [Rails-devel] 18EU Tile number overlaps

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

> I am saying that 18EU's tile #80 is identical in function to the
> "standard" tile #80 -- I view the graphic differences as no different
> than whether a bridge symbol is drawn on overpasses or what font the
> revenue number is drawn in.

Agreed - I think the cases that matter are the ones where there are
real conflicts.

> I'm not suggesting using different tile numbers -- I am saying to
> distinguish game X's tile A from game Y's tile A each tile would have a
> unique tile id, which is not printed on the tile, while the tile number
> attribute would be A in each case.

Definitely agree on this - the display should match the documentation
and printed game.  A unique ID that isn't displayed will do fine, as
you suggested earlier.

-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

Re: [Rails-devel] 18EU Tile number overlaps

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

Chris Shaffer wrote:
> Yes, it does matter, because people often rely on printed tile upgrade
> charts and lists.  Also, upgrade possibilities are often delineated in
> the rules by tile number.  Since you can't update those documents, you
> should be consistent with them.
>   
I am saying that 18EU's tile #80 is identical in function to the 
"standard" tile #80 -- I view the graphic differences as no different 
than whether a bridge symbol is drawn on overpasses or what font the 
revenue number is drawn in.

I'm not suggesting using different tile numbers -- I am saying to 
distinguish game X's tile A from game Y's tile A each tile would have a 
unique tile id, which is not printed on the tile, while the tile number 
attribute would be A in each case.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/24/07, brett lentz <wak...@gm...> wrote:
>
> What's the reasoning behind keeping the tile numbering the same?  If
> it's merely because that's what people already know and use for PBEM,
> that reasoning strikes me as tenuous at best.  So long as Rails uses
> an internally consistent numbering scheme, the tile numbering is
> largely irrelevant for actual gameplay.
>
> In other words, the gameplay value of Tile #9 isn't the fact that it's
> number nine, but the fact that it represents track going from one side
> of the hex to the opposite side in a straight line. So, therefore
> whether it's labelled 9 or 99 doesn't really matter at all, does it?

Yes, it does matter, because people often rely on printed tile upgrade
charts and lists.  Also, upgrade possibilities are often delineated in
the rules by tile number.  Since you can't update those documents, you
should be consistent with them.

-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

Re: [Rails-devel] 18EU Tile number overlaps

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

On 10/24/07, John A. Tamplin <ja...@ja...> wrote:
> Chris Shaffer wrote:
> > I strongly suggest you keep the same numbers, but indicate in some way
> > that they are variants.  The game should be as similar to the printed
> > version as possible, despite tile numbering conflicts.
> >
> You already have to deal with multiple identical tile numbers that have
> different track.  I suggest using the same solution I do in my database
> -- I have a unique tile ID and an attribute of the tile is the number to
> display on the tile.
>
> Also, note that tiles 80-83 are in fact identical to the "standard"
> 80-83 -- they have the same connectivity between edges, but are just
> drawn differently.
>


Just to play devil's advocate for a moment...

What's the reasoning behind keeping the tile numbering the same?  If
it's merely because that's what people already know and use for PBEM,
that reasoning strikes me as tenuous at best.  So long as Rails uses
an internally consistent numbering scheme, the tile numbering is
largely irrelevant for actual gameplay.

In other words, the gameplay value of Tile #9 isn't the fact that it's
number nine, but the fact that it represents track going from one side
of the hex to the opposite side in a straight line. So, therefore
whether it's labelled 9 or 99 doesn't really matter at all, does it?

FWIW - I believe the previous numbering collisions were dealt with by
bumping the tile numbers into a new range (e.g. 65 became 2065).
Though, my memory isn't clear on this point, which is what instigated
the question in the first place. :-)


---Brett.

Re: [Rails-devel] 18EU Tile number overlaps

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

Chris Shaffer wrote:
> I strongly suggest you keep the same numbers, but indicate in some way
> that they are variants.  The game should be as similar to the printed
> version as possible, despite tile numbering conflicts.
>   
You already have to deal with multiple identical tile numbers that have 
different track.  I suggest using the same solution I do in my database 
-- I have a unique tile ID and an attribute of the tile is the number to 
display on the tile.

Also, note that tiles 80-83 are in fact identical to the "standard" 
80-83 -- they have the same connectivity between edges, but are just 
drawn differently.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] 18EU Tile number overlaps

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

I strongly suggest you keep the same numbers, but indicate in some way
that they are variants.  The game should be as similar to the printed
version as possible, despite tile numbering conflicts.

Chris


On 10/24/07, Brett Lentz <wak...@gm...> wrote:
> I'm working on importing the new tiles for 18EU, but I've run into some
> overlaps in tile numbering.
>
> I was able to import the TileDesigner data from John. Unfortunately,
> these tiles already exist (and are different tiles): -5, -6, -7, -8, -9,
> -10, -11, 80, 81, 82, 83.
>
> So, it looks like I'll need to re-number these 18EU tiles. Any
> suggestions on what the new tile numbers ought to be?
>
>
>  ---Brett.
>
>
>         "Fantasies are free."
>         "NO!! NO!! It's the thought police!!!!"
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>


-- 
Chris

Keep the flying car. I want the future where "resurrection" is a
medical specialty.

[Rails-devel] 18EU Tile number overlaps

[Brett L. <wak...@gm...>]

I'm working on importing the new tiles for 18EU, but I've run into some
overlaps in tile numbering.

I was able to import the TileDesigner data from John. Unfortunately,
these tiles already exist (and are different tiles): -5, -6, -7, -8, -9,
-10, -11, 80, 81, 82, 83.

So, it looks like I'll need to re-number these 18EU tiles. Any
suggestions on what the new tile numbers ought to be?


 ---Brett.


	"Fantasies are free."
	"NO!! NO!! It's the thought police!!!!"

Re: [Rails-devel] Question regarding Revenue display behaviour

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

> Hi there,
> during a test game i observed that the Revenue filed doesnt 
> get updated 
> until the User hits payout or withhold.
> 
> While that might make sense from a rule conform handling, it 
> never the 
> less obscures/insecures the operator as he cant see currently which 
> value has been selected.
> 
> I.e. you set the revenue and are then asked to either 
> withhold or payout 
> but unless you noted which value you actually "selected" the revenue 
> field itself doesnt show the value.
> 
> Intentional ? I would prefer that the selected revenue is 
> displayed (if 
> necessary with a note like proposed ) before it will actually 
> selected 
> for payout or other actions.

The technical reason is, that revenue setting and payout selection
count as one UI action. The game engine, which updates the panel,
is not informed until the payout has been chosen.

But your point is valid, and I will add a provisional revenue update
before the payout selection.

In a future version for internet play (not yet possible), this will mean,
that only the operating player will see this value before the payout
selection.
That looks OK to me.

Erik.

[Rails-devel] Question regarding Revenue display behaviour

[Martin B. <ne...@tr...>]

Hi there,
during a test game i observed that the Revenue filed doesnt get updated 
until the User hits payout or withhold.

While that might make sense from a rule conform handling, it never the 
less obscures/insecures the operator as he cant see currently which 
value has been selected.

I.e. you set the revenue and are then asked to either withhold or payout 
but unless you noted which value you actually "selected" the revenue 
field itself doesnt show the value.

Intentional ? I would prefer that the selected revenue is displayed (if 
necessary with a note like proposed ) before it will actually selected 
for payout or other actions.


Regards,
Martin

Re: [Rails-devel] Price Protection

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

Yes, that sounds exactly right.

I would suggest to make it a subclass of StockRound,
like ShareSellingRound (emergency selling to buy a train).

Like that other class, you can probably reuse GameStatus for the UI.
In this case only buy actions would be allowed 
(in ShareSellingRound only sell actions are allowed).

That is all governed by what you put into PossibleActions.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of Brett Lentz
> Sent: Friday 12 October 2007 01:26
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Price Protection
> 
> After whittling away at the rest of the 18EU XML, I think I'd like to
> take a stab at implementing Price Protection.
> 
> Judging by the code, it appears that the best way to go about 
> this is to
> implement it as a special Round, then have the StockRound 
> code signal to
> the GameManager whether it needs to initiate a "Price 
> Protection Round".
> 
> This looks like it will allow the GameManager and GameUIManager to
> prompt the user with an appropriate UI and handle the price protection
> processing based on the user's input.
> 
> Do I have that about right?  Is this a good way of implementing Price
> Protection?
> 
> 
>  ---Brett.
> 
> 
> Love is the only game that is not called on account of darkness.
> 		-- M. Hirschfield
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and 
> a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] Map for 18EU

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

brett lentz wrote:
> Sure!  Send 'em!
>   
Attached.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Map for 18EU

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

On 10/11/07, John A. Tamplin <ja...@ja...> wrote:
> Brett Lentz wrote:
> >> Can you make the extra tiles in TileDesigner, or shall I do it?
> >>
> > As soon as I get time, I can.
> >
> > I probably won't get to it until early next week or so. If you are
> > interested in doing it before then, you're welcome to. :-)
> >
> BTW, I have all the tiles I use in any of our games in TileDesigner
> (although some of them use extensions to the format that my perl code
> understands) -- I am happy to send them if you want them.


Sure!  Send 'em!

---Brett.

Re: [Rails-devel] Map for 18EU

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

Brett Lentz wrote:
>> Can you make the extra tiles in TileDesigner, or shall I do it?
>>     
> As soon as I get time, I can.  
>
> I probably won't get to it until early next week or so. If you are
> interested in doing it before then, you're welcome to. :-)
>   
BTW, I have all the tiles I use in any of our games in TileDesigner 
(although some of them use extensions to the format that my perl code 
understands) -- I am happy to send them if you want them.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Price Protection

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

Brett Lentz wrote:
> After whittling away at the rest of the 18EU XML, I think I'd like to
> take a stab at implementing Price Protection.
> 
> Judging by the code, it appears that the best way to go about this is to
> implement it as a special Round, then have the StockRound code signal to
> the GameManager whether it needs to initiate a "Price Protection Round".
> 
> This looks like it will allow the GameManager and GameUIManager to
> prompt the user with an appropriate UI and handle the price protection
> processing based on the user's input.
> 
> Do I have that about right?  Is this a good way of implementing Price
> Protection?

It would work, provided we go back to a stock round after the special round.

(This type of situation is why I resisted the notion that only one round can
be going on at a time: it seems cleaner to me if the special round takes
place during one turn of a stock round which continues after the special
round ends.  The same scheme also works for private company auctions.
Similarly, forced train purchases, and complicated phase changes such as the
1835 Pr formation and 1841 IRSFF succession, can best be handled as special
rounds that take place during one turn of an operating round.)

[Rails-devel] Price Protection

[Brett L. <wak...@gm...>]

After whittling away at the rest of the 18EU XML, I think I'd like to
take a stab at implementing Price Protection.

Judging by the code, it appears that the best way to go about this is to
implement it as a special Round, then have the StockRound code signal to
the GameManager whether it needs to initiate a "Price Protection Round".

This looks like it will allow the GameManager and GameUIManager to
prompt the user with an appropriate UI and handle the price protection
processing based on the user's input.

Do I have that about right?  Is this a good way of implementing Price
Protection?


 ---Brett.


Love is the only game that is not called on account of darkness.
		-- M. Hirschfield

Re: [Rails-devel] Map for 18EU

[Brett L. <wak...@gm...>]

On Thu, 2007-10-11 at 15:33 -0700, Brett Lentz wrote:
> On Fri, 2007-10-12 at 00:22 +0200, Erik Vos wrote:
> > > I've written up a basic Map.xml for 18EU.  It's not complete, 
> > > there are
> > > 3 or 4 map locations that require new tile images. 
> > > 
> > > I also haven't added the orientation parameters. Those will need to be
> > > added once more of the other XML files are fleshed out.
> > 
> > Can you make the extra tiles in TileDesigner, or shall I do it?
> > 
> 
> As soon as I get time, I can.  
> 
> I probably won't get to it until early next week or so. If you are
> interested in doing it before then, you're welcome to. :-)
> 
>  ---Brett.
> 
> 
> Three o'clock in the afternoon is always just a little too late or a
> little
> too early for anything you want to do.
> 		-- Jean-Paul Sartre



StockMarket and TileSet XML files for 18EU are in.



 ---Brett.


Memories of you remind me of you.
-- Karl Lehenbauer

Re: [Rails-devel] Map for 18EU

[Brett L. <wak...@gm...>]

On Fri, 2007-10-12 at 00:22 +0200, Erik Vos wrote:
> > I've written up a basic Map.xml for 18EU.  It's not complete, 
> > there are
> > 3 or 4 map locations that require new tile images. 
> > 
> > I also haven't added the orientation parameters. Those will need to be
> > added once more of the other XML files are fleshed out.
> 
> Can you make the extra tiles in TileDesigner, or shall I do it?
> 

As soon as I get time, I can.  

I probably won't get to it until early next week or so. If you are
interested in doing it before then, you're welcome to. :-)

 ---Brett.


Three o'clock in the afternoon is always just a little too late or a
little
too early for anything you want to do.
		-- Jean-Paul Sartre

Re: [Rails-devel] Map for 18EU

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

> I've written up a basic Map.xml for 18EU.  It's not complete, 
> there are
> 3 or 4 map locations that require new tile images. 
> 
> I also haven't added the orientation parameters. Those will need to be
> added once more of the other XML files are fleshed out.

Can you make the extra tiles in TileDesigner, or shall I do it?

Erik.

[Rails-devel] Map for 18EU

[Brett L. <wak...@gm...>]

I've written up a basic Map.xml for 18EU.  It's not complete, there are
3 or 4 map locations that require new tile images. 

I also haven't added the orientation parameters. Those will need to be
added once more of the other XML files are fleshed out.


 ---Brett.


court, n.:
	A place where they dispense with justice.
		-- Arthur Train

Re: [Rails-devel] Game Start UI changes

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

> I found the problem. I forgot to check for a null. The fix has been
> committed.

Works fine now.
Thanks, also for the Game Info.

Erik.

Re: [Rails-devel] Revenue and Value parameters in Map.xml

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

> I'm looking over the 18AL Map.xml and noticing that there are two
> different parameters in the Hex tag:  revenue and value.
> 
> What's the difference between these?  Where would I use one instead of
> the other?

revenue is an error (or a leftover from a much earlier version).
I have changed it all to value.

Erik.

[Rails-devel] Revenue and Value parameters in Map.xml

[Brett L. <wak...@gm...>]

I'm looking over the 18AL Map.xml and noticing that there are two
different parameters in the Hex tag:  revenue and value.

What's the difference between these?  Where would I use one instead of
the other?


 ---Brett.


Pedaeration, n.:
	The perfect body heat achieved by having one leg under the
	sheet and one hanging off the edge of the bed.
		-- Rich Hall, "Sniglets"

Re: [Rails-devel] Game Start UI changes

[Brett L. <wak...@gm...>]

On Wed, 2007-10-10 at 21:04 +0200, Erik Vos wrote:

> May I suggest to add a button (e.g. "Info") or some other
> device to show the current game's additional info,
> as included in the <Description> tag in GamesList.xml?
> 
> I have just added some info (about a limitation) for 1830.
> Other games already had some text (1835 has the longest story right now).


Game Notes button added.

Also added dynamic toggling of the name textboxes.


 ---Brett.


The trouble with being punctual is that people think you have nothing more
important to do.

Re: [Rails-devel] Game Start UI changes

[Brett L. <wak...@gm...>]

On Thu, 2007-10-11 at 00:42 +0200, Erik Vos wrote:
> > Ok, looking at the line that is in the error...  it's the check that
> > looks for if you've selected "Human" and have something in the name
> > textbox.
> > 
> > Can you make sure your drop-downs are set to Human and not None?
> 
> As it starts, the first 3 boxes (with default names) are "Human",
> and the rest is "None". No difference if I change all to "Human".
> 
> Frankly, I don't see the point of these selection boxes.
> Why not remove them? AI players are way behind our horizon.


AI is only a long way off because nobody has expressed interest in
working on it. My hope is that by reserving some space in the UI for it,
someone that is interested can see the desire for such a feature and
fill it.

I found the problem. I forgot to check for a null. The fix has been
committed.


 ---Brett.


A failure will not appear until a unit has passed final inspection.

Re: [Rails-devel] Game Start UI changes

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

> Ok, looking at the line that is in the error...  it's the check that
> looks for if you've selected "Human" and have something in the name
> textbox.
> 
> Can you make sure your drop-downs are set to Human and not None?

As it starts, the first 3 boxes (with default names) are "Human",
and the rest is "None". No difference if I change all to "Human".

Frankly, I don't see the point of these selection boxes.
Why not remove them? AI players are way behind our horizon.

Erik.