rails-devel — List for discussion of Rails development

Re: [Rails-devel] 1825 patch

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

Applied. Thanks.
Erik. 

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Tuesday 12 October 2010 11:09
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

See attached patch.  I've done what Stefan suggested below and changed
to an IntegerState variable for the formationOrderIndex, as well as
moving it into the specific game class.  There are potentially other
games out there where this matters but I think it's niche enough to be
in the game specific files.

This also includes the start of the StockRound_1825 where I've started
thinking about receivership.  Doesn't really do much as of yet but
it's a start.

Phil

On 17 September 2010 22:57, Stefan Frey <ste...@we...> wrote:
> I have not created a test case for that, but I would guess that you should
> change the formationOrderIndex from an Integer variable to an IntegerState
> variable, as otherwise it is likely that the mechanism will fail with
> undo-actions.
>
> And I would prefer if everything related to the formationOrderIndex is
kept in
> the subclass PublicCompany_1825, as it is only used by those.
> I am usually confused by variables in a base class, which are only used in
> subclass context.
>

Re: [Rails-devel] 1825 patch

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

See attached patch.  I've done what Stefan suggested below and changed
to an IntegerState variable for the formationOrderIndex, as well as
moving it into the specific game class.  There are potentially other
games out there where this matters but I think it's niche enough to be
in the game specific files.

This also includes the start of the StockRound_1825 where I've started
thinking about receivership.  Doesn't really do much as of yet but
it's a start.

Phil

On 17 September 2010 22:57, Stefan Frey <ste...@we...> wrote:
> I have not created a test case for that, but I would guess that you should
> change the formationOrderIndex from an Integer variable to an IntegerState
> variable, as otherwise it is likely that the mechanism will fail with
> undo-actions.
>
> And I would prefer if everything related to the formationOrderIndex is kept in
> the subclass PublicCompany_1825, as it is only used by those.
> I am usually confused by variables in a base class, which are only used in
> subclass context.
>

[Rails-devel] Dynamic company order and other fixes

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

I have finally managed to add a missing feature that affects all games
implemented so far (except 1825): the operating company order is now
dynamic. After each company turn the operating order is recalculated. The OR
panel will be recreated if the order has changed.

I am also gradually fixing and implementing a number of outstanding bugs and
minor requests, many of which come from John David Galt's long list.

Done so far:

- If a company has no train, "No train" is reported below the map instead of
"Withhold".
- Show grayed out "Buy Train" button in the train buying step if the company
has no money, or cannot buy a train for any other reason.
- Fix treasury selling tooltip (which said "buy" instead of "sell").

Erik.

Re: [Rails-devel] 1825 patch

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

Excellent news, good work :)

On 20 September 2010 22:40, Erik Vos <eri...@xs...> wrote:
> Well, that was simple indeed. The white fake tiles are now gone. Hexsides
> can be declared "open" which means that track can be laid against these
> sides even at the board edge. I have applied this to the map of 1825U1. As
> far as I can see now, such track is ignored by the revenue calculator.
>
> Erik.
>
> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Monday 20 September 2010 19:46
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] 1825 patch
>
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Monday 20 September 2010 11:57
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> I kind of like the idea of having half-hexes to plug onto the top/side
> of the map from an aesthetic point of view, however, in terms of time
> spend, I think it might end up being more worthwhile being able to
> define edges that are 'safe' for pointing track into (and that
> automatically act as a terminus of 0 value perhaps?
>
> I'm not sure how tricky that is, of course, but it would sidestep the
> issue of even needing these extra fake hexes anyway.
>
> [EV] Yes, that shouldn't be too difficult. I'll try it out one of these
> days.
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 1825 map

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

The map should now be complete.

I checked the playable tiles and found that only the striped tiles 119, 166
and 200 are missing in the current tile set. I will create these with the
colour that indicates in which phase these tiles can be laid. Perhaps the
stripes can be added later, as well as the square around the city of tile
200.

Some tiles exist under different numbers in the tile set. I will not create
new tiles for these:
52 = 59 or 1052
114 = 632
115 = 169
198 = 631
199 = 630

Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Thursday 23 September 2010 00:08
To: 'Development list for Rails: an 18xx game'
Subject: 1825 map

I have added almost the whole of the 1825 map: units 2 and 3 and the
regional kits R1-3. The map has holes where yet unimplemented preprinted
tiles exist.

The units and kits can be selected via the Options menu. To avoid the need
to create separate entries in LocalisedText.properties for each possible
choice, I have extended the option parameter concept to enable separate
options with the same name but different parameter values (so far option
parameters could only be used for localisation of a single option with that
name).

So now we have in 1825/Map.xml:
  <IfOption name="Include" parm="Unit3" value="yes">
	(unit 3 hexes)
  </IfOption>
  <IfOption name="Include" parm="Unit2" value="yes">
	(Unit 2 hexes)
  </IfOption>
  <IfOption name="Include" parm="Unit1" value="yes">
	(Unit 1 hexes)
    <IfOption name="Include" parm="R1" value="yes">
	(Kit R1 hexes)
    </IfOption>
    <IfOption name="Include" parm="R2" value="yes">
	(Kit R2 hexes)
    </IfOption>
    <IfOption name="Include" parm="R3" value="yes">
	(Kit R3 hexes)
    </IfOption>
  </IfOption>

Note the nesting: the kits R1-3 require Unit 1 to be selected.

The map now also correctly displays 'strange' hex names like AA99 (Penzance
in R2).

I have *not* applied this concept yet to any other components: layable
tiles, trains, companies etc. I will create all missing tiles; for now I
suppose I can leave the rest of the configuration to Phil.

For the tile and train quantities we will need a new facility to add up (+)
numbers. For instance:
	<Tile id="6" quantity="2">
	   	<IfOption name="Include" parm="Unit1" value="yes">
			<Attributes quantity="+2"/>
		</IfOption>
		<IfOption name="Include" parm="Unit2" value="yes">
			<Attributes quantity="+2"/>
		</IfOption>
		(etc.)	
		<Upgrade id="12,13,14,15"></Upgrade>
	</Tile>

The configuration of money and certificate limits may get complicated;
perhaps we'll have to devise new tricks, or hardcode things (such as the
limits in 1856).
In any case, some of the 1825 XML files will become unusually bulky...

Erik.

Re: [Rails-devel] 1825 map

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

The '25 stock market also looks a little weird, since the X-axis goes
up to Z then the next columns are [ and \.  It works it just looks a
little strange and I thought it wasn't worth worrying about an
overhaul of the stockmarket code just for that.

[EV] I had in mind to create separate StockMarket classes for 1D and
hexagonal (1837) stock markets, but I'm not sure if the former is really
needed. In any case, in the UI I would like to see the 1D boxes a bit
taller, and perhaps narrower. We might also need to do something special for
1860.
Getting the X-axis values right above Z (e.g. AA, like with
Penzance/Falmouth) is a minor issue.

Erik.

Re: [Rails-devel] 1825 map

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

On 22 September 2010 23:07, Erik Vos <eri...@xs...> wrote:
> I have added almost the whole of the 1825 map: units 2 and 3 and the
> regional kits R1-3. The map has holes where yet unimplemented preprinted
> tiles exist.
> The map now also correctly displays 'strange' hex names like AA99 (Penzance
> in R2).

The '25 stock market also looks a little weird, since the X-axis goes
up to Z then the next columns are [ and \.  It works it just looks a
little strange and I thought it wasn't worth worrying about an
overhaul of the stockmarket code just for that.

> I have *not* applied this concept yet to any other components: layable
> tiles, trains, companies etc. I will create all missing tiles; for now I
> suppose I can leave the rest of the configuration to Phil.

Excellent, I want to focus on getting 1 unit at least playable to
conclusion but all of this means it should in theory be able to go
from Unit 1 playable to the whole set playable with minimal additional
complexity

> For the tile and train quantities we will need a new facility to add up (+)
> numbers. For instance:
>        <Tile id="6" quantity="2">
>                <IfOption name="Include" parm="Unit1" value="yes">
>                        <Attributes quantity="+2"/>
>                </IfOption>
>                <IfOption name="Include" parm="Unit2" value="yes">
>                        <Attributes quantity="+2"/>
>                </IfOption>
>                (etc.)
>                <Upgrade id="12,13,14,15"></Upgrade>
>        </Tile>

There is also an odd scenario around tokens, LNWR has different token
numebrs and home bases depending on if you are using unit 1, unit 2 or
a combination of both.  This is probably possible within the current
framework but again it's more weight to the XML file.

> The configuration of money and certificate limits may get complicated;
> perhaps we'll have to devise new tricks, or hardcode things (such as the
> limits in 1856).
> In any case, some of the 1825 XML files will become unusually bulky...

As I mentioned in my other mail, I think having the facility for
slightly more freeform parameters as part of the game setup would help
immensely, especially where bank sizes are concerned.  It would open
the way for people to houserule a little more and take away some of
the need to manually add variants as game options.

Phil

Re: [Rails-devel] 1825 map

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

The one thing I've come to find with the discussions that go on around
bank size in 1825 is that no one seems to agree on the exact
configuration they play with.

My thoughts were that bank size should be a free entry field where any
reasonable number could be entered, thus allowing a default selection
to be set for a given combination of units, then allowing players to
manually in/decrease that number before the game starts.  I don't
think we can do this with our current option system design (I could be
wrong??) since they seem to work more on a set of pre-defined hard
coded selections.

Incidentally, this would make a neater interface for testing
configurations.  Confirming that bank breaking works as expected is a
lot easier to test by editing the bank down and having it selectable
in the user interface and not hacking the XML every time you want to
test it is neater :)

Phil

On 22 September 2010 23:11, Steve Undy <ste...@gm...> wrote:
> I think the most interesting thing to add will be the bank size and
> certificate limits.  These vary widely depending on player count and the
> combination of units/regional kits selected.
>
> Steve Undy
> st...@ro...
>
>
> On Wed, Sep 22, 2010 at 4:07 PM, Erik Vos <eri...@xs...> wrote:
>>
>> I have added almost the whole of the 1825 map: units 2 and 3 and the
>> regional kits R1-3. The map has holes where yet unimplemented preprinted
>> tiles exist.
>>
>> The units and kits can be selected via the Options menu. To avoid the need
>> to create separate entries in LocalisedText.properties for each possible
>> choice, I have extended the option parameter concept to enable separate
>> options with the same name but different parameter values (so far option
>> parameters could only be used for localisation of a single option with
>> that
>> name).
>>
>> So now we have in 1825/Map.xml:
>>  <IfOption name="Include" parm="Unit3" value="yes">
>>        (unit 3 hexes)
>>  </IfOption>
>>  <IfOption name="Include" parm="Unit2" value="yes">
>>        (Unit 2 hexes)
>>  </IfOption>
>>  <IfOption name="Include" parm="Unit1" value="yes">
>>        (Unit 1 hexes)
>>    <IfOption name="Include" parm="R1" value="yes">
>>        (Kit R1 hexes)
>>    </IfOption>
>>    <IfOption name="Include" parm="R2" value="yes">
>>        (Kit R2 hexes)
>>    </IfOption>
>>    <IfOption name="Include" parm="R3" value="yes">
>>        (Kit R3 hexes)
>>    </IfOption>
>>  </IfOption>
>>
>> Note the nesting: the kits R1-3 require Unit 1 to be selected.
>>
>> The map now also correctly displays 'strange' hex names like AA99
>> (Penzance
>> in R2).
>>
>> I have *not* applied this concept yet to any other components: layable
>> tiles, trains, companies etc. I will create all missing tiles; for now I
>> suppose I can leave the rest of the configuration to Phil.
>>
>> For the tile and train quantities we will need a new facility to add up
>> (+)
>> numbers. For instance:
>>        <Tile id="6" quantity="2">
>>                <IfOption name="Include" parm="Unit1" value="yes">
>>                        <Attributes quantity="+2"/>
>>                </IfOption>
>>                <IfOption name="Include" parm="Unit2" value="yes">
>>                        <Attributes quantity="+2"/>
>>                </IfOption>
>>                (etc.)
>>                <Upgrade id="12,13,14,15"></Upgrade>
>>        </Tile>
>>
>> The configuration of money and certificate limits may get complicated;
>> perhaps we'll have to devise new tricks, or hardcode things (such as the
>> limits in 1856).
>> In any case, some of the 1825 XML files will become unusually bulky...
>>
>> Erik.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 1825 map

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

I think the most interesting thing to add will be the bank size and
certificate limits.  These vary widely depending on player count and the
combination of units/regional kits selected.

Steve Undy
st...@ro...


On Wed, Sep 22, 2010 at 4:07 PM, Erik Vos <eri...@xs...> wrote:

> I have added almost the whole of the 1825 map: units 2 and 3 and the
> regional kits R1-3. The map has holes where yet unimplemented preprinted
> tiles exist.
>
> The units and kits can be selected via the Options menu. To avoid the need
> to create separate entries in LocalisedText.properties for each possible
> choice, I have extended the option parameter concept to enable separate
> options with the same name but different parameter values (so far option
> parameters could only be used for localisation of a single option with that
> name).
>
> So now we have in 1825/Map.xml:
>  <IfOption name="Include" parm="Unit3" value="yes">
>        (unit 3 hexes)
>  </IfOption>
>  <IfOption name="Include" parm="Unit2" value="yes">
>        (Unit 2 hexes)
>  </IfOption>
>  <IfOption name="Include" parm="Unit1" value="yes">
>        (Unit 1 hexes)
>    <IfOption name="Include" parm="R1" value="yes">
>        (Kit R1 hexes)
>    </IfOption>
>    <IfOption name="Include" parm="R2" value="yes">
>        (Kit R2 hexes)
>    </IfOption>
>    <IfOption name="Include" parm="R3" value="yes">
>        (Kit R3 hexes)
>    </IfOption>
>  </IfOption>
>
> Note the nesting: the kits R1-3 require Unit 1 to be selected.
>
> The map now also correctly displays 'strange' hex names like AA99 (Penzance
> in R2).
>
> I have *not* applied this concept yet to any other components: layable
> tiles, trains, companies etc. I will create all missing tiles; for now I
> suppose I can leave the rest of the configuration to Phil.
>
> For the tile and train quantities we will need a new facility to add up (+)
> numbers. For instance:
>        <Tile id="6" quantity="2">
>                <IfOption name="Include" parm="Unit1" value="yes">
>                        <Attributes quantity="+2"/>
>                </IfOption>
>                <IfOption name="Include" parm="Unit2" value="yes">
>                        <Attributes quantity="+2"/>
>                </IfOption>
>                (etc.)
>                <Upgrade id="12,13,14,15"></Upgrade>
>        </Tile>
>
> The configuration of money and certificate limits may get complicated;
> perhaps we'll have to devise new tricks, or hardcode things (such as the
> limits in 1856).
> In any case, some of the 1825 XML files will become unusually bulky...
>
> Erik.
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] 1825 map

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

I have added almost the whole of the 1825 map: units 2 and 3 and the
regional kits R1-3. The map has holes where yet unimplemented preprinted
tiles exist.

The units and kits can be selected via the Options menu. To avoid the need
to create separate entries in LocalisedText.properties for each possible
choice, I have extended the option parameter concept to enable separate
options with the same name but different parameter values (so far option
parameters could only be used for localisation of a single option with that
name).

So now we have in 1825/Map.xml:
  <IfOption name="Include" parm="Unit3" value="yes">
	(unit 3 hexes)
  </IfOption>
  <IfOption name="Include" parm="Unit2" value="yes">
	(Unit 2 hexes)
  </IfOption>
  <IfOption name="Include" parm="Unit1" value="yes">
	(Unit 1 hexes)
    <IfOption name="Include" parm="R1" value="yes">
	(Kit R1 hexes)
    </IfOption>
    <IfOption name="Include" parm="R2" value="yes">
	(Kit R2 hexes)
    </IfOption>
    <IfOption name="Include" parm="R3" value="yes">
	(Kit R3 hexes)
    </IfOption>
  </IfOption>

Note the nesting: the kits R1-3 require Unit 1 to be selected.

The map now also correctly displays 'strange' hex names like AA99 (Penzance
in R2).

I have *not* applied this concept yet to any other components: layable
tiles, trains, companies etc. I will create all missing tiles; for now I
suppose I can leave the rest of the configuration to Phil.

For the tile and train quantities we will need a new facility to add up (+)
numbers. For instance:
	<Tile id="6" quantity="2">
	   	<IfOption name="Include" parm="Unit1" value="yes">
			<Attributes quantity="+2"/>
		</IfOption>
		<IfOption name="Include" parm="Unit2" value="yes">
			<Attributes quantity="+2"/>
		</IfOption>
		(etc.)	
		<Upgrade id="12,13,14,15"></Upgrade>
	</Tile>

The configuration of money and certificate limits may get complicated;
perhaps we'll have to devise new tricks, or hardcode things (such as the
limits in 1856).
In any case, some of the 1825 XML files will become unusually bulky...

Erik.

Re: [Rails-devel] 1825 patch

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

Well, that was simple indeed. The white fake tiles are now gone. Hexsides
can be declared "open" which means that track can be laid against these
sides even at the board edge. I have applied this to the map of 1825U1. As
far as I can see now, such track is ignored by the revenue calculator.

Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Monday 20 September 2010 19:46
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] 1825 patch


-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Monday 20 September 2010 11:57
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

I kind of like the idea of having half-hexes to plug onto the top/side
of the map from an aesthetic point of view, however, in terms of time
spend, I think it might end up being more worthwhile being able to
define edges that are 'safe' for pointing track into (and that
automatically act as a terminus of 0 value perhaps?

I'm not sure how tricky that is, of course, but it would sidestep the
issue of even needing these extra fake hexes anyway.

[EV] Yes, that shouldn't be too difficult. I'll try it out one of these
days.

Re: [Rails-devel] 1825 patch

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

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Monday 20 September 2010 11:57
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

I kind of like the idea of having half-hexes to plug onto the top/side
of the map from an aesthetic point of view, however, in terms of time
spend, I think it might end up being more worthwhile being able to
define edges that are 'safe' for pointing track into (and that
automatically act as a terminus of 0 value perhaps?

I'm not sure how tricky that is, of course, but it would sidestep the
issue of even needing these extra fake hexes anyway.

[EV] Yes, that shouldn't be too difficult. I'll try it out one of these
days.

> And I would prefer if everything related to the formationOrderIndex is
kept in
> the subclass PublicCompany_1825, as it is only used by those.
> I am usually confused by variables in a base class, which are only used in
> subclass context.

There was a reason I had to put it in the interface, although this is
probably largely due to a lack of coding skill on my part...

Oh yeah, in OperatingRound_1825, line 23:

for (PublicCompanyI company : companyManager.getAllPublicCompanies()) {

If you make that foreach loop PublicCompany_125 then
getAllPublicCompanies doesn't work because that returns a collections
of PublicCompanyI objects.  There is likely a better way to fix this
than putting that information into the interface class so if so I'm
happy to be corrected!

[EV] I already wondered why you needed this interface. I will try to sort
out if we can omit it.

Re: [Rails-devel] 1825 patch

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

I kind of like the idea of having half-hexes to plug onto the top/side
of the map from an aesthetic point of view, however, in terms of time
spend, I think it might end up being more worthwhile being able to
define edges that are 'safe' for pointing track into (and that
automatically act as a terminus of 0 value perhaps?

I'm not sure how tricky that is, of course, but it would sidestep the
issue of even needing these extra fake hexes anyway.

On 17 September 2010 22:57, Stefan Frey <ste...@we...> wrote:
> I have not created a test case for that, but I would guess that you should
> change the formationOrderIndex from an Integer variable to an IntegerState
> variable, as otherwise it is likely that the mechanism will fail with
> undo-actions.

I'll look into this

> And I would prefer if everything related to the formationOrderIndex is kept in
> the subclass PublicCompany_1825, as it is only used by those.
> I am usually confused by variables in a base class, which are only used in
> subclass context.

There was a reason I had to put it in the interface, although this is
probably largely due to a lack of coding skill on my part...

Oh yeah, in OperatingRound_1825, line 23:

for (PublicCompanyI company : companyManager.getAllPublicCompanies()) {

If you make that foreach loop PublicCompany_125 then
getAllPublicCompanies doesn't work because that returns a collections
of PublicCompanyI objects.  There is likely a better way to fix this
than putting that information into the interface class so if so I'm
happy to be corrected!


>> Route awareness and revenue calculation: Have a variety of issues.
>> I'm reasonably confident I can fix these with the framework Stefan has
>> put together, I just haven't got round to looking at what needs doing
>> yet, so for the moment these two settings default to off.
>>
> Actually I only read your mail carefully after I have added the required code
> for 1825 revenue calculation. Sorry for not leaving that for you.
> A good reason for that was that I had the idea for the 1825 issues already in
> mind during the implementation of the revenue modifier framework.
> And from this I knew that I had to change a few subtle issues there to allow
> the 1825 modifiers show the results correctly.
> Without those the task would have been much harder.
>
> So there are now two dynamic modifiers, which allow double heading and prevent
> termination at towns. Feel free to test and adapt them to your needs.

I need to look in general how the modifiers for route calculation
work, I have a lot of saved emails to trawl through when I get the
spare time :)

> There is still one issue on revenue calculation: There is nothing preventing a
> train visiting two stations on a tile. The current method is to set the city
> attribute for all station of that tile to an identical value (in Tiles.xml).
> Erik already critized that and I am close to suggest that an attribute in
> TileSet.xml might be better (for example a VisitOnlyOnce attribute).
>
> Route awareness is currently work in progress, as I intend to add true route
> checks in a hopefully not too distant future. As 1825 has some rule
> adjustments in that area, it is worth to wait for changes there. I intend to
> provide a modifier interface similar to those used for revenue calculation.
>

Re: [Rails-devel] 1825 patch

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

Depending of how you want the left border look like, you might need two such
E/W border half-tiles, a small and a broad one. 

The problem with Inkscape is not to modify existing to create new ones, but
to size and tweak the result to make it fit into Rails maps. That's a pretty
delicate process. If anyone wants to try: instructions can be found in
CombineTiles.pl.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Saturday 18 September 2010 10:56
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

If I am not off-track now, two variations are needed:
One for North/South and one for West/East border hexes (with appropriate
rotation). I never worked with Inkscape, thus I do not know how difficult it

is to change the hex accordingly.
Stefan

On Saturday 18 September 2010 00:27:44 Erik Vos wrote:
> Hmm... how would that be at the left hand side of the 1825U1 map (where I
> have added such hexes today)?
> We would need several variations of such half-hexes.
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday 18 September 2010 00:00
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Another idea for those unplayable hexes, which however allow track to end
> there:
> Would it possible to have those tiles show up as half-hexes (thus half
> green,
> half background color), similar to the boardgame map?
>
> On Friday 17 September 2010 20:49:06 Erik Vos wrote:
> > I have added unplayable hexes to the left side where regional extensions
> > exist,
> > and removed Q21 and Q27 at the upper border, which do not exist in any
> > extension.
> > Comments in Map.xml now indicate which units and regional kits relate to
> > each group of unplayable hexes.
> >
> > I think that for all or most other units and kits new (preprinted) tiles
> > need be created. I can do that - let me know when you think you are
ready
> > to work on these extensions, at which time I will try to give it some
> > priority.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Friday 17 September 2010 00:45
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1825 patch
> >
> > Erik,
> >
> > No problem, I get mistaken for a Paul all the time ;)
> >
> > Yes, I will need an extra column to the left (well, a line of hexes
> > that borders on that edge anyway, it jumps between two column numbers
> > given the hex orientation). I've been meaning to try this out at some
> > point but does the map XML support IfOption tags for defining hexes?
> > The ability to add on the extra units and extensions is going to be
> > useful at some point, presumeably we can make it so that the lines are
> > this invisible hex colour if the extensions aren't in use and put the
> > real hexes there if they are
> >
> > Phil
> >
> > On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:
> > > (Apologies to Phil for misspelling his name)
> > >
> > > I have created a white tile -10000 that has now replaced tile 0 for
the
> > > Q-row, and marked it as not upgradable. It is not completely
invisible,
> > > as the map background turns out to be a bit off-white. If anyone can
> > > detect that colour's RGB value, I can apply it to this new tile too.
> > >
> > > By the way, Phil, don't you need some of these extra tiles at the
> >
> > left-hand
> >
> > > side of Unit 1 as well?
> > >
> > > While at tile tweaking, in the 18EU map I have also replaced tile -10
> > > by
> >
> > the
> >
> > > -3007 (Y) and -3008 centered city tiles, that I had created specially
>
> for
>
> > > 18EU, but apparently overlooked to use them in the map. The Y label is
> > > now visible, as requested by John Galt.
> > >
> > > Erik.
> > >
> > > -----Original Message-----
> > > From: Phil Davies [mailto:de...@gm...]
> > > Sent: Thursday 16 September 2010 02:11
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] 1825 patch
> > >
> > > Erik,
> > >
> > > I hadn't really decided what to do with that row long term. I was
> > > running a test game and found some odd behaviour when I used map
> > > correction to rotate a tile so that it pointed one end of it's track
> > > off map (the most obvious is that the next company to operate cannot
> > > lay a tile!) I added the extra row as a quick get out and that worked,
> > > honestly I forgot to remove it before submitting a patch!
> > >
> > > Actually, yes, if you could apply that fix you suggest, for the moment
> > > having this spare row works, I'll need to do something a bit more
> > > permanent when I get round to adding in Unit 2 since it will use that
> > > row but I can think about it when we get to that point!
> > >
> > > Phil
> > >
> > > On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
> > >> Hi Phil,
> > >>
> > >> Well done.
> > >>
> > >> On the Q row: I suppose you don't want to allow any tile lays on that
> > >
> > > extra
> > >
> > >> 'border' row.
> > >> That can be done in TileSet.xml:
> > >> 	<Tile id="0"><!-- Empty space -->
> > >> 		<Upgrade id="7,8,9"
> > >> hex="-Q9,Q11,Q13,Q15,Q17,Q19,Q21,Q23,Q25,Q27"/>
> > >> 	</Tile>
> > >> If you agree, I will commit that patch.
> > >>
> > >> A better solution would, of course, be to have a special blank tile
>
> that
>
> > > is
> > >
> > >> not upgradeable (and looks a bit different too) or to create an
option
> > >> to make border hexsides open for track in Map.xml.
> > >> Such options does not yet exist, but would be nice to have. Can't
> > >> promise doing that soon!
> > >>
> > >> Erik.
> > >>
> > >> -----Original Message-----
> > >> From: Phil Davies [mailto:de...@gm...]
> > >> Sent: Wednesday 15 September 2010 17:12
> > >> To: Development list for Rails: an 18xx game
> > >> Subject: [Rails-devel] 1825 patch
> > >>
> > >> Could someone review and (hopefully, if it's not too broken) apply
> > >> this patch for some updates to the 1825 implementation.
> > >>
> > >> There is only one shared component (IE: not in the _1825 game
specific
> > >> folder and not in the 1825 data folder) that I've hit with these
> > >> changes and that's the PublicCompany class and it's interface
> > >> PublicCompanyI.  The change I've made here is to add a
> > >> formationOrderIndex to the PublicCompany interface with the attendant
> > >> getters and setters.  The reason for doing this is that in 1825
> > >> companies always operate in descending par value order.  When two
> > >> companies share the same par value, they always operate in the order
> > >> they were formed.  This value is a simple incrementing integer value
> > >> that is a 0 for the first company at a given par, then a 1 for the
> > >> next and so on.  This seemed the easiest way to control operating
> > >> order for the OR's
> > >>
> > >> Everything else is 1825 specific code so shouldn't affect any
existing
> > >> games, but I'd certainly be keen on any feedback as to better/worse
> > >> ways of doing what I've done so far.
> > >>
> > >> With this patch, 1825 becomes 'somewhat' playable.  The key issues
> > >> that would prevent a normal game finishing:
> > >>
> > >> Tile placement: You are allowed to place track running off the board,
> > >> just not running into the sea or the blank side of a brown (grey in
> > >> rails) hex.  Currently the rails map implementation has no way of
> > >> distinguishing between 'legal' off board and 'nonlegal' offboard
track
> > >> play.  I think this can be got round using map correction as long as
> > >> routeawareness and revenue calculation is turned off (the bleed from
> > >> the network going outside of the map seems to confuse it if you map
> > >> correct and point a tile outside)
> > >>
> > >> Receivership and the ability to sell the presidents share to the pool
> > >> are not implemented, this is probably the 'big thing' to get 1825 to
a
> > >> fully playable state, I've never played a game of the tabletop
version
> > >> where someone didn't dump some company into receivership so without
> > >> that the rails implementation becomes fairly pedestrian.
> > >>
> > >> Route awareness and revenue calculation: Have a variety of issues.
> > >> I'm reasonably confident I can fix these with the framework Stefan
has
> > >> put together, I just haven't got round to looking at what needs doing
> > >> yet, so for the moment these two settings default to off.
> > >>
> > >> Phil
>
>
---------------------------------------------------------------------------
>
> >-
> >
> > > --
> > >
> > >> Start uncovering the many advantages of virtual appliances
> > >> and start using them to simplify application deployment and
> > >> accelerate your shift to cloud computing.
> > >> http://p.sf.net/sfu/novell-sfdev2dev
> > >> _______________________________________________
> > >> Rails-devel mailing list
> > >> Rai...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>
> >-
> >
> > > --:
> > > Start uncovering the many advantages of virtual appliances
> > > and start using them to simplify application deployment and
> > > accelerate your shift to cloud computing.
> > > http://p.sf.net/sfu/novell-sfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>
> >-
> >
> > > --
> > > Start uncovering the many advantages of virtual appliances
> > > and start using them to simplify application deployment and
> > > accelerate your shift to cloud computing.
> > > http://p.sf.net/sfu/novell-sfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>
> >- --
> >
> > > Start uncovering the many advantages of virtual appliances
> > > and start using them to simplify application deployment and
> > > accelerate your shift to cloud computing.
> > > http://p.sf.net/sfu/novell-sfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>
> >- --
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>
> >--- Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>- --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
---------------------------------------------------------------------------
>--- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1825 patch

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

If I am not off-track now, two variations are needed:
One for North/South and one for West/East border hexes (with appropriate
rotation). I never worked with Inkscape, thus I do not know how difficult it 
is to change the hex accordingly.
Stefan

On Saturday 18 September 2010 00:27:44 Erik Vos wrote:
> Hmm... how would that be at the left hand side of the 1825U1 map (where I
> have added such hexes today)?
> We would need several variations of such half-hexes.
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday 18 September 2010 00:00
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Another idea for those unplayable hexes, which however allow track to end
> there:
> Would it possible to have those tiles show up as half-hexes (thus half
> green,
> half background color), similar to the boardgame map?
>
> On Friday 17 September 2010 20:49:06 Erik Vos wrote:
> > I have added unplayable hexes to the left side where regional extensions
> > exist,
> > and removed Q21 and Q27 at the upper border, which do not exist in any
> > extension.
> > Comments in Map.xml now indicate which units and regional kits relate to
> > each group of unplayable hexes.
> >
> > I think that for all or most other units and kits new (preprinted) tiles
> > need be created. I can do that - let me know when you think you are ready
> > to work on these extensions, at which time I will try to give it some
> > priority.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Friday 17 September 2010 00:45
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1825 patch
> >
> > Erik,
> >
> > No problem, I get mistaken for a Paul all the time ;)
> >
> > Yes, I will need an extra column to the left (well, a line of hexes
> > that borders on that edge anyway, it jumps between two column numbers
> > given the hex orientation). I've been meaning to try this out at some
> > point but does the map XML support IfOption tags for defining hexes?
> > The ability to add on the extra units and extensions is going to be
> > useful at some point, presumeably we can make it so that the lines are
> > this invisible hex colour if the extensions aren't in use and put the
> > real hexes there if they are
> >
> > Phil
> >
> > On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:
> > > (Apologies to Phil for misspelling his name)
> > >
> > > I have created a white tile -10000 that has now replaced tile 0 for the
> > > Q-row, and marked it as not upgradable. It is not completely invisible,
> > > as the map background turns out to be a bit off-white. If anyone can
> > > detect that colour's RGB value, I can apply it to this new tile too.
> > >
> > > By the way, Phil, don't you need some of these extra tiles at the
> >
> > left-hand
> >
> > > side of Unit 1 as well?
> > >
> > > While at tile tweaking, in the 18EU map I have also replaced tile -10
> > > by
> >
> > the
> >
> > > -3007 (Y) and -3008 centered city tiles, that I had created specially
>
> for
>
> > > 18EU, but apparently overlooked to use them in the map. The Y label is
> > > now visible, as requested by John Galt.
> > >
> > > Erik.
> > >
> > > -----Original Message-----
> > > From: Phil Davies [mailto:de...@gm...]
> > > Sent: Thursday 16 September 2010 02:11
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] 1825 patch
> > >
> > > Erik,
> > >
> > > I hadn't really decided what to do with that row long term. I was
> > > running a test game and found some odd behaviour when I used map
> > > correction to rotate a tile so that it pointed one end of it's track
> > > off map (the most obvious is that the next company to operate cannot
> > > lay a tile!) I added the extra row as a quick get out and that worked,
> > > honestly I forgot to remove it before submitting a patch!
> > >
> > > Actually, yes, if you could apply that fix you suggest, for the moment
> > > having this spare row works, I'll need to do something a bit more
> > > permanent when I get round to adding in Unit 2 since it will use that
> > > row but I can think about it when we get to that point!
> > >
> > > Phil
> > >
> > > On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
> > >> Hi Phil,
> > >>
> > >> Well done.
> > >>
> > >> On the Q row: I suppose you don't want to allow any tile lays on that
> > >
> > > extra
> > >
> > >> 'border' row.
> > >> That can be done in TileSet.xml:
> > >> 	<Tile id="0"><!-- Empty space -->
> > >> 		<Upgrade id="7,8,9"
> > >> hex="-Q9,Q11,Q13,Q15,Q17,Q19,Q21,Q23,Q25,Q27"/>
> > >> 	</Tile>
> > >> If you agree, I will commit that patch.
> > >>
> > >> A better solution would, of course, be to have a special blank tile
>
> that
>
> > > is
> > >
> > >> not upgradeable (and looks a bit different too) or to create an option
> > >> to make border hexsides open for track in Map.xml.
> > >> Such options does not yet exist, but would be nice to have. Can't
> > >> promise doing that soon!
> > >>
> > >> Erik.
> > >>
> > >> -----Original Message-----
> > >> From: Phil Davies [mailto:de...@gm...]
> > >> Sent: Wednesday 15 September 2010 17:12
> > >> To: Development list for Rails: an 18xx game
> > >> Subject: [Rails-devel] 1825 patch
> > >>
> > >> Could someone review and (hopefully, if it's not too broken) apply
> > >> this patch for some updates to the 1825 implementation.
> > >>
> > >> There is only one shared component (IE: not in the _1825 game specific
> > >> folder and not in the 1825 data folder) that I've hit with these
> > >> changes and that's the PublicCompany class and it's interface
> > >> PublicCompanyI.  The change I've made here is to add a
> > >> formationOrderIndex to the PublicCompany interface with the attendant
> > >> getters and setters.  The reason for doing this is that in 1825
> > >> companies always operate in descending par value order.  When two
> > >> companies share the same par value, they always operate in the order
> > >> they were formed.  This value is a simple incrementing integer value
> > >> that is a 0 for the first company at a given par, then a 1 for the
> > >> next and so on.  This seemed the easiest way to control operating
> > >> order for the OR's
> > >>
> > >> Everything else is 1825 specific code so shouldn't affect any existing
> > >> games, but I'd certainly be keen on any feedback as to better/worse
> > >> ways of doing what I've done so far.
> > >>
> > >> With this patch, 1825 becomes 'somewhat' playable.  The key issues
> > >> that would prevent a normal game finishing:
> > >>
> > >> Tile placement: You are allowed to place track running off the board,
> > >> just not running into the sea or the blank side of a brown (grey in
> > >> rails) hex.  Currently the rails map implementation has no way of
> > >> distinguishing between 'legal' off board and 'nonlegal' offboard track
> > >> play.  I think this can be got round using map correction as long as
> > >> routeawareness and revenue calculation is turned off (the bleed from
> > >> the network going outside of the map seems to confuse it if you map
> > >> correct and point a tile outside)
> > >>
> > >> Receivership and the ability to sell the presidents share to the pool
> > >> are not implemented, this is probably the 'big thing' to get 1825 to a
> > >> fully playable state, I've never played a game of the tabletop version
> > >> where someone didn't dump some company into receivership so without
> > >> that the rails implementation becomes fairly pedestrian.
> > >>
> > >> Route awareness and revenue calculation: Have a variety of issues.
> > >> I'm reasonably confident I can fix these with the framework Stefan has
> > >> put together, I just haven't got round to looking at what needs doing
> > >> yet, so for the moment these two settings default to off.
> > >>
> > >> Phil
>
> ---------------------------------------------------------------------------
>
> >-
> >
> > > --
> > >
> > >> Start uncovering the many advantages of virtual appliances
> > >> and start using them to simplify application deployment and
> > >> accelerate your shift to cloud computing.
> > >> http://p.sf.net/sfu/novell-sfdev2dev
> > >> _______________________________________________
> > >> Rails-devel mailing list
> > >> Rai...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>
> >-
> >
> > > --:
> > > Start uncovering the many advantages of virtual appliances
> > > and start using them to simplify application deployment and
> > > accelerate your shift to cloud computing.
> > > http://p.sf.net/sfu/novell-sfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>
> >-
> >
> > > --
> > > Start uncovering the many advantages of virtual appliances
> > > and start using them to simplify application deployment and
> > > accelerate your shift to cloud computing.
> > > http://p.sf.net/sfu/novell-sfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>
> >- --
> >
> > > Start uncovering the many advantages of virtual appliances
> > > and start using them to simplify application deployment and
> > > accelerate your shift to cloud computing.
> > > http://p.sf.net/sfu/novell-sfdev2dev
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>
> >- --
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>
> >--- Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>- --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1825 patches

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

Jim,

All very valid observations, and a fair point I was incorrect in
stating that it amounts to the same thing.  However running in
formation order is not how the rules present it according to my
rulebook:

4.1.3, page 7:
The companies run in decreasing order of size, as shown by the price
on the share certificates.  When two companies have the same price,
for instance, the GER and the LSWR are both valued at £76, they are
run in the order in which they were formed.  This order does not
change during the game.

Am I or you operating from an older or corrected copy of the rules?
My rulebook is copyright 2009 so I'm assuming it's the latest version
but then it's entirely possible I'm missing an external FAQ or
clarification.

Phil

On 17 September 2010 23:25, Jim Black <ji...@ko...> wrote:
> my previous post had an editing error- a bunch of the previous thread/digest appended- apologies, here's a correction--
>
> <snip>
>
> A followup on operating order in 1825:
>
> Phil>> in 1825 companies always operate in descending par value order.
> Phil>> When two companies share the same par value, they always operate
> Phil>> in the order they were formed.
>
> Jim>> That's not right: throughout the 1825, majors operate strictly in order of
> Jim>> formation (NOT par value).
>
> Phil> This amounts to the same thing for all scenarios I can think of and is
> Phil> how it's written in the rulebook (the rulebook says companies operate
> Phil> in order of 'face value')
>
> No:  formation-order is related to par-value, but it can be very different.
>
> In 1825, companies become available in flights, organized by par-value.
>
> Once /any/ company in a given flight is sold-out, then all companies/shares in the next flight become available.
>
> Unit 1 has 5 flights:  LNWR (100), GWR (90), GER & LSWR (76), SECR (71), LBSC (67)
>
> And,
>
> Phil> the GWR which must form before either the GER or
> Phil> LSWR forms.  The tricky bit is catching which of those
> Phil> two forms first and this IS currently handled.
>
> This is all true, but not sufficient.
>
> When /either/ GER or LSWR sells out, SECR becomes available.  And, once SECR sells out, LBSC becomes available.
>
> As a result, it's very possible for SECR and LBSC to operate /before/ either GER, or LSWR (but never before both).
>
> In Unit2, there's 3 flights:  LNWR (100), MR & NER (82), GCR & GNR & L&Y (71)
>
> It's /very/ common for only one of MR & NER to form, then sell out, while the other company stands unpurchased.  (Eg, MR forms and sells out, but no one wants NER because of its remote location. )  Then, a few companies in the 3rd flight form (GCR, GNR, and/or L&Y), before the remaining company in flight 2 every forms.  As a result, that flight 2 company operates very late- /not/ in par-value order, at all.
>
> best,
> -  jim
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Worth increase per OR

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

OK, I have committed code to show each player's worth increase during the
last complete OR in an extra row in the Game Status.
Erik.

-----Original Message-----
From: John David Galt [mailto:jd...@di...] 
Sent: Tuesday 14 September 2010 07:13
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Rails 1.4 18EU playtest with commentary

Erik Vos wrote:
> OK, thanks.
> 
> Next question: would you like the income-per-OR be updated continuously
> during that OR (which means that all values need to be reset to 0 at the
> start of the OR), or just once when an OR is finished (so that the
previous
> value remains visible up to that point)?

If I were writing it, it would update at the end of each OR (and maybe log
itself to make look-back possible).

----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1825 patch

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

Hmm... how would that be at the left hand side of the 1825U1 map (where I
have added such hexes today)?
We would need several variations of such half-hexes. 
Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Saturday 18 September 2010 00:00
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

Another idea for those unplayable hexes, which however allow track to end 
there:
Would it possible to have those tiles show up as half-hexes (thus half
green, 
half background color), similar to the boardgame map?

On Friday 17 September 2010 20:49:06 Erik Vos wrote:
> I have added unplayable hexes to the left side where regional extensions
> exist,
> and removed Q21 and Q27 at the upper border, which do not exist in any
> extension.
> Comments in Map.xml now indicate which units and regional kits relate to
> each group of unplayable hexes.
>
> I think that for all or most other units and kits new (preprinted) tiles
> need be created. I can do that - let me know when you think you are ready
> to work on these extensions, at which time I will try to give it some
> priority.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 17 September 2010 00:45
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> No problem, I get mistaken for a Paul all the time ;)
>
> Yes, I will need an extra column to the left (well, a line of hexes
> that borders on that edge anyway, it jumps between two column numbers
> given the hex orientation). I've been meaning to try this out at some
> point but does the map XML support IfOption tags for defining hexes?
> The ability to add on the extra units and extensions is going to be
> useful at some point, presumeably we can make it so that the lines are
> this invisible hex colour if the extensions aren't in use and put the
> real hexes there if they are
>
> Phil
>
> On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:
> > (Apologies to Phil for misspelling his name)
> >
> > I have created a white tile -10000 that has now replaced tile 0 for the
> > Q-row, and marked it as not upgradable. It is not completely invisible,
> > as the map background turns out to be a bit off-white. If anyone can
> > detect that colour's RGB value, I can apply it to this new tile too.
> >
> > By the way, Phil, don't you need some of these extra tiles at the
>
> left-hand
>
> > side of Unit 1 as well?
> >
> > While at tile tweaking, in the 18EU map I have also replaced tile -10 by
>
> the
>
> > -3007 (Y) and -3008 centered city tiles, that I had created specially
for
> > 18EU, but apparently overlooked to use them in the map. The Y label is
> > now visible, as requested by John Galt.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Thursday 16 September 2010 02:11
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1825 patch
> >
> > Erik,
> >
> > I hadn't really decided what to do with that row long term. I was
> > running a test game and found some odd behaviour when I used map
> > correction to rotate a tile so that it pointed one end of it's track
> > off map (the most obvious is that the next company to operate cannot
> > lay a tile!) I added the extra row as a quick get out and that worked,
> > honestly I forgot to remove it before submitting a patch!
> >
> > Actually, yes, if you could apply that fix you suggest, for the moment
> > having this spare row works, I'll need to do something a bit more
> > permanent when I get round to adding in Unit 2 since it will use that
> > row but I can think about it when we get to that point!
> >
> > Phil
> >
> > On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
> >> Hi Phil,
> >>
> >> Well done.
> >>
> >> On the Q row: I suppose you don't want to allow any tile lays on that
> >
> > extra
> >
> >> 'border' row.
> >> That can be done in TileSet.xml:
> >> 	<Tile id="0"><!-- Empty space -->
> >> 		<Upgrade id="7,8,9"
> >> hex="-Q9,Q11,Q13,Q15,Q17,Q19,Q21,Q23,Q25,Q27"/>
> >> 	</Tile>
> >> If you agree, I will commit that patch.
> >>
> >> A better solution would, of course, be to have a special blank tile
that
> >
> > is
> >
> >> not upgradeable (and looks a bit different too) or to create an option
> >> to make border hexsides open for track in Map.xml.
> >> Such options does not yet exist, but would be nice to have. Can't
> >> promise doing that soon!
> >>
> >> Erik.
> >>
> >> -----Original Message-----
> >> From: Phil Davies [mailto:de...@gm...]
> >> Sent: Wednesday 15 September 2010 17:12
> >> To: Development list for Rails: an 18xx game
> >> Subject: [Rails-devel] 1825 patch
> >>
> >> Could someone review and (hopefully, if it's not too broken) apply
> >> this patch for some updates to the 1825 implementation.
> >>
> >> There is only one shared component (IE: not in the _1825 game specific
> >> folder and not in the 1825 data folder) that I've hit with these
> >> changes and that's the PublicCompany class and it's interface
> >> PublicCompanyI.  The change I've made here is to add a
> >> formationOrderIndex to the PublicCompany interface with the attendant
> >> getters and setters.  The reason for doing this is that in 1825
> >> companies always operate in descending par value order.  When two
> >> companies share the same par value, they always operate in the order
> >> they were formed.  This value is a simple incrementing integer value
> >> that is a 0 for the first company at a given par, then a 1 for the
> >> next and so on.  This seemed the easiest way to control operating
> >> order for the OR's
> >>
> >> Everything else is 1825 specific code so shouldn't affect any existing
> >> games, but I'd certainly be keen on any feedback as to better/worse
> >> ways of doing what I've done so far.
> >>
> >> With this patch, 1825 becomes 'somewhat' playable.  The key issues
> >> that would prevent a normal game finishing:
> >>
> >> Tile placement: You are allowed to place track running off the board,
> >> just not running into the sea or the blank side of a brown (grey in
> >> rails) hex.  Currently the rails map implementation has no way of
> >> distinguishing between 'legal' off board and 'nonlegal' offboard track
> >> play.  I think this can be got round using map correction as long as
> >> routeawareness and revenue calculation is turned off (the bleed from
> >> the network going outside of the map seems to confuse it if you map
> >> correct and point a tile outside)
> >>
> >> Receivership and the ability to sell the presidents share to the pool
> >> are not implemented, this is probably the 'big thing' to get 1825 to a
> >> fully playable state, I've never played a game of the tabletop version
> >> where someone didn't dump some company into receivership so without
> >> that the rails implementation becomes fairly pedestrian.
> >>
> >> Route awareness and revenue calculation: Have a variety of issues.
> >> I'm reasonably confident I can fix these with the framework Stefan has
> >> put together, I just haven't got round to looking at what needs doing
> >> yet, so for the moment these two settings default to off.
> >>
> >> Phil
>
>
---------------------------------------------------------------------------
>-
>
> > --
> >
> >> Start uncovering the many advantages of virtual appliances
> >> and start using them to simplify application deployment and
> >> accelerate your shift to cloud computing.
> >> http://p.sf.net/sfu/novell-sfdev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>-
>
> > --
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>-
>
> > --
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>- --
>
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
---------------------------------------------------------------------------
>- --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
---------------------------------------------------------------------------
>--- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel



----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1825 patches

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

my previous post had an editing error- a bunch of the previous thread/digest appended- apologies, here's a correction--

<snip>

A followup on operating order in 1825:

Phil>> in 1825 companies always operate in descending par value order.  
Phil>> When two companies share the same par value, they always operate
Phil>> in the order they were formed.  

Jim>> That's not right: throughout the 1825, majors operate strictly in order of
Jim>> formation (NOT par value).

Phil> This amounts to the same thing for all scenarios I can think of and is
Phil> how it's written in the rulebook (the rulebook says companies operate
Phil> in order of 'face value')

No:  formation-order is related to par-value, but it can be very different.   

In 1825, companies become available in flights, organized by par-value.  

Once /any/ company in a given flight is sold-out, then all companies/shares in the next flight become available.  

Unit 1 has 5 flights:  LNWR (100), GWR (90), GER & LSWR (76), SECR (71), LBSC (67)

And,

Phil> the GWR which must form before either the GER or
Phil> LSWR forms.  The tricky bit is catching which of those 
Phil> two forms first and this IS currently handled.

This is all true, but not sufficient.  

When /either/ GER or LSWR sells out, SECR becomes available.  And, once SECR sells out, LBSC becomes available.  

As a result, it's very possible for SECR and LBSC to operate /before/ either GER, or LSWR (but never before both).

In Unit2, there's 3 flights:  LNWR (100), MR & NER (82), GCR & GNR & L&Y (71)

It's /very/ common for only one of MR & NER to form, then sell out, while the other company stands unpurchased.  (Eg, MR forms and sells out, but no one wants NER because of its remote location. )  Then, a few companies in the 3rd flight form (GCR, GNR, and/or L&Y), before the remaining company in flight 2 every forms.  As a result, that flight 2 company operates very late- /not/ in par-value order, at all.

best,
-  jim

Re: [Rails-devel] 1825 patches

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

A followup on operating order in 1825:

Phil>> in 1825 companies always operate in descending par value order.  
Phil>> When two companies share the same par value, they always operate
Phil>> in the order they were formed.  

Jim>> That's not right: throughout the 1825, majors operate strictly in order of
Jim>> formation (NOT par value).

Phil> This amounts to the same thing for all scenarios I can think of and is
Phil> how it's written in the rulebook (the rulebook says companies operate
Phil> in order of 'face value')

No:  formation-order is related to par-value, but it can be very different.   

In 1825, companies become available in flights, organized by par-value.  

Once /any/ company in a given flight is sold-out, then all companies/shares in the next flight become available.  

Unit 1 has 5 flights:  LNWR (100), GWR (90), GER & LSWR (76), SECR (71), LBSC (67)

And,

Phil> the GWR which must form before either the GER or
Phil> LSWR forms.  The tricky bit is catching which of those 
Phil> two forms first and this IS currently handled.

This is all true, but not sufficient.  

When /either/ GER or LSWR sells out, SECR becomes available.  And, once SECR sells out, LBSC becomes available.  

As a result, it's very possible for SECR and LBSC to operate /before/ either GER, or LSWR (but never before both).

In Unit2, there's 3 flights:  LNWR (100), MR & NER (82), GCR & GNR & L&Y (71)

It's /very/ common for only one of MR & NER to form, then sell out, while the other company stands unpurchased.  (Eg, MR forms and sells out, but no one wants NER because of its remote location. )  Then, a few companies in the 3rd flight form (GCR, GNR, and/or L&Y), before the remaining company in flight 2 every forms.  As a result, that flight 2 company operates very late- /not/ in par-value order, at all.

best,
-  jim



However, this doesn't take into account that SECR 
> Only minors operate in descending par value.

SO far away from adding minor companies at the moment but I will bear
that in mind!

> Also, please review the bug incident I filed (I think Erik moved it to feature requests), enumerating many 1825 issues- it
> would be really helpful if this was surveyed again, before marking 1825 playable/experimental.

I will do, I 1825 up until the last week has been the map XML and
nothing more, absolutely nothing was written for it so I've not
bothered checking bug reports since I wasn't expecting anyone to try
launching it!  I'll review these and see if I need to add anything
else that isn't already on my list.  The goal for me at this stage is
to get Unit 1 playable on it's own, from start to finish with all
features covered in the core rulebook.  Once that is done I can start
thinking about mixing in other units/minors/tile packs etc.

> I'm curious whether you implemented the update to allow 1-4 steps on the stock-market, depending on the size of earnings.

Yep, all working

> Also, whether running 2 2-trains as 1 3-train works in the revenue-calc engine...

Currently no, in fact currently the route calculation is totally
broken for 1825 since it allows you to start and end at small towns
AND visit two stations on the same hex, both of which aren't allowed.
So for the moment I'm afraid anyone testing will have to revert to
manual routing.  Route calculation is either 2nd or 1st on my list of
things to fix...right after I work out how complicated receivership is
and which I fancy tackling first

Phil


On 15 September 2010 16:38, Jim Black <ji...@ko...> wrote:
> 
> Phil wrote:
> 
>> in 1825 companies always operate in descending par value order.
>> When two companies share the same par value, they always operate
>> ?in the order they were formed.
> 
> That's not right: ?throughout the 1825, majors operate strictly in order of formation (NOT par value).
> 
> Only minors operate in descending par value.
> 
> Also, please review the bug incident I filed (I think Erik moved it to feature requests), enumerating many 1825 issues- it would be really helpful if this was surveyed again, before marking 1825 playable/experimental.
> 
> I'm curious whether you implemented the update to allow 1-4 steps on the stock-market, depending on the size of earnings. ?(That's really important..) ? Also, whether running 2 2-trains as 1 3-train works in the revenue-calc engine...
> 
> best,
> ?- jim
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 



------------------------------

Message: 4
Date: Wed, 15 Sep 2010 17:13:57 +0100
From: Phil Davies <de...@gm...>
Subject: Re: [Rails-devel] 1825 patches
To: "Development list for Rails: an 18xx game"
	<rai...@li...>
Message-ID:
	<AANLkTi=6XK...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

Oh, one further item that occurs to me that's worth mentioning for
anyone that is keen to test 1825 (please bear in mind it still has
many issues and is currently only testable from the SVN codebase).

The start round works ass-backwards but functionally correctly to the
physical game.  In the boardgame, you randomise the distribution of
the private companies, then seat yourself around the table in
ascending value of private.

On rails, the method is to ensure you randomise the seating of the
players first, then during the start round, each player will be forced
to buy the appropriate private related to their seating position.
This ends up being the exact same thing but does mean that it's
important you hit that 'randomise seating' button or put people into
the startup screen in the order you have determined seating to be
using whatever external randomisation system of your choice.

Brett: This is the sort of player information I think would be useful
to have on the documentation wiki...can I get access to edit pages
there to add this sort of info?  Or at least someone create a page for
1825 that I have rights over so I can stick down thoughts like this as
they come up?

Phil

On 15 September 2010 16:57, Phil Davies <de...@gm...> wrote:
> Jim,
> 
>>> in 1825 companies always operate in descending par value order.
>>> When two companies share the same par value, they always operate
>>> ?in the order they were formed.
>> 
>> That's not right: ?throughout the 1825, majors operate strictly in order of formation (NOT par value).
> 
> This amounts to the same thing for all scenarios I can think of and is
> how it's written in the rulebook (the rulebook says companies operate
> in order of 'face value')
> 
> In the case of 1825 unit 1 (which is all I've got added so far), the
> LNWR MUST form before the GWR which must form before either the GER or
> LSWR forms. ?The tricky bit is catching which of those two forms first
> and this IS currently handled.
> 
>> Only minors operate in descending par value.
> 
> SO far away from adding minor companies at the moment but I will bear
> that in mind!
> 
>> Also, please review the bug incident I filed (I think Erik moved it to feature requests), enumerating many 1825 issues- it
>> would be really helpful if this was surveyed again, before marking 1825 playable/experimental.
> 
> I will do, I 1825 up until the last week has been the map XML and
> nothing more, absolutely nothing was written for it so I've not
> bothered checking bug reports since I wasn't expecting anyone to try
> launching it! ?I'll review these and see if I need to add anything
> else that isn't already on my list. ?The goal for me at this stage is
> to get Unit 1 playable on it's own, from start to finish with all
> features covered in the core rulebook. ?Once that is done I can start
> thinking about mixing in other units/minors/tile packs etc.
> 
>> I'm curious whether you implemented the update to allow 1-4 steps on the stock-market, depending on the size of earnings.
> 
> Yep, all working
> 
>> Also, whether running 2 2-trains as 1 3-train works in the revenue-calc engine...
> 
> Currently no, in fact currently the route calculation is totally
> broken for 1825 since it allows you to start and end at small towns
> AND visit two stations on the same hex, both of which aren't allowed.
> So for the moment I'm afraid anyone testing will have to revert to
> manual routing. ?Route calculation is either 2nd or 1st on my list of
> things to fix...right after I work out how complicated receivership is
> and which I fancy tackling first
> 
> Phil
> 
> 
> On 15 September 2010 16:38, Jim Black <ji...@ko...> wrote:
>> 
>> Phil wrote:
>> 
>>> in 1825 companies always operate in descending par value order.
>>> When two companies share the same par value, they always operate
>>> ?in the order they were formed.
>> 
>> That's not right: ?throughout the 1825, majors operate strictly in order of formation (NOT par value).
>> 
>> Only minors operate in descending par value.
>> 
>> Also, please review the bug incident I filed (I think Erik moved it to feature requests), enumerating many 1825 issues- it would be really helpful if this was surveyed again, before marking 1825 playable/experimental.
>> 
>> I'm curious whether you implemented the update to allow 1-4 steps on the stock-market, depending on the size of earnings. ?(That's really important..) ? Also, whether running 2 2-trains as 1 3-train works in the revenue-calc engine...
>> 
>> best,
>> ?- jim
>> 
>> 
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
> 



------------------------------

Message: 5
Date: Wed, 15 Sep 2010 09:49:21 -0700
From: brett lentz <bre...@gm...>
Subject: Re: [Rails-devel] 1825 patches
To: "Development list for Rails: an 18xx game"
	<rai...@li...>
Message-ID:
	<AANLkTi=5=W=LTvFmm8OMYUjA-RZe8Gq7=SG8...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 15, 2010 at 9:13 AM, Phil Davies <de...@gm...> wrote:
> Brett: This is the sort of player information I think would be useful
> to have on the documentation wiki...can I get access to edit pages
> there to add this sort of info? ?Or at least someone create a page for
> 1825 that I have rights over so I can stick down thoughts like this as
> they come up?

Absolutely.   You should now have rights to edit the wiki.

(Which reminds me, I need to put a link to the wiki on the main homepage.)

> Phil

Anyone else that would like to help contribute to the wiki, please
ping me off-list and I'll upgrade your access.

---Brett



------------------------------

Message: 6
Date: Wed, 15 Sep 2010 22:39:42 +0200
From: "Erik Vos" <eri...@xs...>
Subject: Re: [Rails-devel] 1825 patch
To: "'Development list for Rails: an 18xx game'"
	<rai...@li...>
Message-ID: <81E9E9FF1D56401696A1A83EB3DDD3FE@ERIKVOS4>
Content-Type: text/plain;	charset="us-ascii"

Hi Phil,

Well done. 

On the Q row: I suppose you don't want to allow any tile lays on that extra
'border' row.
That can be done in TileSet.xml:
	<Tile id="0"><!-- Empty space -->
		<Upgrade id="7,8,9"
hex="-Q9,Q11,Q13,Q15,Q17,Q19,Q21,Q23,Q25,Q27"/>
	</Tile>
If you agree, I will commit that patch.

A better solution would, of course, be to have a special blank tile that is
not upgradeable (and looks a bit different too) or to create an option to
make border hexsides open for track in Map.xml. 
Such options does not yet exist, but would be nice to have. Can't promise
doing that soon!

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Wednesday 15 September 2010 17:12
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] 1825 patch

Could someone review and (hopefully, if it's not too broken) apply
this patch for some updates to the 1825 implementation.

There is only one shared component (IE: not in the _1825 game specific
folder and not in the 1825 data folder) that I've hit with these
changes and that's the PublicCompany class and it's interface
PublicCompanyI.  The change I've made here is to add a
formationOrderIndex to the PublicCompany interface with the attendant
getters and setters.  The reason for doing this is that in 1825
companies always operate in descending par value order.  When two
companies share the same par value, they always operate in the order
they were formed.  This value is a simple incrementing integer value
that is a 0 for the first company at a given par, then a 1 for the
next and so on.  This seemed the easiest way to control operating
order for the OR's

Everything else is 1825 specific code so shouldn't affect any existing
games, but I'd certainly be keen on any feedback as to better/worse
ways of doing what I've done so far.

With this patch, 1825 becomes 'somewhat' playable.  The key issues
that would prevent a normal game finishing:

Tile placement: You are allowed to place track running off the board,
just not running into the sea or the blank side of a brown (grey in
rails) hex.  Currently the rails map implementation has no way of
distinguishing between 'legal' off board and 'nonlegal' offboard track
play.  I think this can be got round using map correction as long as
routeawareness and revenue calculation is turned off (the bleed from
the network going outside of the map seems to confuse it if you map
correct and point a tile outside)

Receivership and the ability to sell the presidents share to the pool
are not implemented, this is probably the 'big thing' to get 1825 to a
fully playable state, I've never played a game of the tabletop version
where someone didn't dump some company into receivership so without
that the rails implementation becomes fairly pedestrian.

Route awareness and revenue calculation: Have a variety of issues.
I'm reasonably confident I can fix these with the framework Stefan has
put together, I just haven't got round to looking at what needs doing
yet, so for the moment these two settings default to off.

Phil




------------------------------

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

------------------------------

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel


End of Rails-devel Digest, Vol 35, Issue 18
*******************************************

Re: [Rails-devel] 1825 patch

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

Another idea for those unplayable hexes, which however allow track to end 
there:
Would it possible to have those tiles show up as half-hexes (thus half green, 
half background color), similar to the boardgame map?

On Friday 17 September 2010 20:49:06 Erik Vos wrote:
> I have added unplayable hexes to the left side where regional extensions
> exist,
> and removed Q21 and Q27 at the upper border, which do not exist in any
> extension.
> Comments in Map.xml now indicate which units and regional kits relate to
> each group of unplayable hexes.
>
> I think that for all or most other units and kits new (preprinted) tiles
> need be created. I can do that - let me know when you think you are ready
> to work on these extensions, at which time I will try to give it some
> priority.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 17 September 2010 00:45
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> No problem, I get mistaken for a Paul all the time ;)
>
> Yes, I will need an extra column to the left (well, a line of hexes
> that borders on that edge anyway, it jumps between two column numbers
> given the hex orientation). I've been meaning to try this out at some
> point but does the map XML support IfOption tags for defining hexes?
> The ability to add on the extra units and extensions is going to be
> useful at some point, presumeably we can make it so that the lines are
> this invisible hex colour if the extensions aren't in use and put the
> real hexes there if they are
>
> Phil
>
> On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:
> > (Apologies to Phil for misspelling his name)
> >
> > I have created a white tile -10000 that has now replaced tile 0 for the
> > Q-row, and marked it as not upgradable. It is not completely invisible,
> > as the map background turns out to be a bit off-white. If anyone can
> > detect that colour's RGB value, I can apply it to this new tile too.
> >
> > By the way, Phil, don't you need some of these extra tiles at the
>
> left-hand
>
> > side of Unit 1 as well?
> >
> > While at tile tweaking, in the 18EU map I have also replaced tile -10 by
>
> the
>
> > -3007 (Y) and -3008 centered city tiles, that I had created specially for
> > 18EU, but apparently overlooked to use them in the map. The Y label is
> > now visible, as requested by John Galt.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Thursday 16 September 2010 02:11
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1825 patch
> >
> > Erik,
> >
> > I hadn't really decided what to do with that row long term. I was
> > running a test game and found some odd behaviour when I used map
> > correction to rotate a tile so that it pointed one end of it's track
> > off map (the most obvious is that the next company to operate cannot
> > lay a tile!) I added the extra row as a quick get out and that worked,
> > honestly I forgot to remove it before submitting a patch!
> >
> > Actually, yes, if you could apply that fix you suggest, for the moment
> > having this spare row works, I'll need to do something a bit more
> > permanent when I get round to adding in Unit 2 since it will use that
> > row but I can think about it when we get to that point!
> >
> > Phil
> >
> > On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
> >> Hi Phil,
> >>
> >> Well done.
> >>
> >> On the Q row: I suppose you don't want to allow any tile lays on that
> >
> > extra
> >
> >> 'border' row.
> >> That can be done in TileSet.xml:
> >> 	<Tile id="0"><!-- Empty space -->
> >> 		<Upgrade id="7,8,9"
> >> hex="-Q9,Q11,Q13,Q15,Q17,Q19,Q21,Q23,Q25,Q27"/>
> >> 	</Tile>
> >> If you agree, I will commit that patch.
> >>
> >> A better solution would, of course, be to have a special blank tile that
> >
> > is
> >
> >> not upgradeable (and looks a bit different too) or to create an option
> >> to make border hexsides open for track in Map.xml.
> >> Such options does not yet exist, but would be nice to have. Can't
> >> promise doing that soon!
> >>
> >> Erik.
> >>
> >> -----Original Message-----
> >> From: Phil Davies [mailto:de...@gm...]
> >> Sent: Wednesday 15 September 2010 17:12
> >> To: Development list for Rails: an 18xx game
> >> Subject: [Rails-devel] 1825 patch
> >>
> >> Could someone review and (hopefully, if it's not too broken) apply
> >> this patch for some updates to the 1825 implementation.
> >>
> >> There is only one shared component (IE: not in the _1825 game specific
> >> folder and not in the 1825 data folder) that I've hit with these
> >> changes and that's the PublicCompany class and it's interface
> >> PublicCompanyI.  The change I've made here is to add a
> >> formationOrderIndex to the PublicCompany interface with the attendant
> >> getters and setters.  The reason for doing this is that in 1825
> >> companies always operate in descending par value order.  When two
> >> companies share the same par value, they always operate in the order
> >> they were formed.  This value is a simple incrementing integer value
> >> that is a 0 for the first company at a given par, then a 1 for the
> >> next and so on.  This seemed the easiest way to control operating
> >> order for the OR's
> >>
> >> Everything else is 1825 specific code so shouldn't affect any existing
> >> games, but I'd certainly be keen on any feedback as to better/worse
> >> ways of doing what I've done so far.
> >>
> >> With this patch, 1825 becomes 'somewhat' playable.  The key issues
> >> that would prevent a normal game finishing:
> >>
> >> Tile placement: You are allowed to place track running off the board,
> >> just not running into the sea or the blank side of a brown (grey in
> >> rails) hex.  Currently the rails map implementation has no way of
> >> distinguishing between 'legal' off board and 'nonlegal' offboard track
> >> play.  I think this can be got round using map correction as long as
> >> routeawareness and revenue calculation is turned off (the bleed from
> >> the network going outside of the map seems to confuse it if you map
> >> correct and point a tile outside)
> >>
> >> Receivership and the ability to sell the presidents share to the pool
> >> are not implemented, this is probably the 'big thing' to get 1825 to a
> >> fully playable state, I've never played a game of the tabletop version
> >> where someone didn't dump some company into receivership so without
> >> that the rails implementation becomes fairly pedestrian.
> >>
> >> Route awareness and revenue calculation: Have a variety of issues.
> >> I'm reasonably confident I can fix these with the framework Stefan has
> >> put together, I just haven't got round to looking at what needs doing
> >> yet, so for the moment these two settings default to off.
> >>
> >> Phil
>
> ---------------------------------------------------------------------------
>-
>
> > --
> >
> >> Start uncovering the many advantages of virtual appliances
> >> and start using them to simplify application deployment and
> >> accelerate your shift to cloud computing.
> >> http://p.sf.net/sfu/novell-sfdev2dev
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>-
>
> > --
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>-
>
> > --
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>- --
>
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>- --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1825 patch

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

Phil:
this already adds a lot of functionality to 1825. Those rules have some nasty 
difficulties, so I think it is good work!

I had a short glance on the code and overall it seems very reasonable.

A few comments below.
Stefan

> There is only one shared component (IE: not in the _1825 game specific
> folder and not in the 1825 data folder) that I've hit with these
> changes and that's the PublicCompany class and it's interface
> PublicCompanyI.  The change I've made here is to add a
> formationOrderIndex to the PublicCompany interface with the attendant
> getters and setters.  The reasoess is currently work in progress, as I 
intend to add true route checks in a non for doing this is that in 1825
> companies always operate in descending par value order.  When two
> companies share the same par value, they always operate in the order
> they were formed.  This value is a simple incrementing integer value
> that is a 0 for the first company at a given par, then a 1 for the
> next and so on.  This seemed the easiest way to control operating
> order for the OR's

I have not created a test case for that, but I would guess that you should 
change the formationOrderIndex from an Integer variable to an IntegerState 
variable, as otherwise it is likely that the mechanism will fail with 
undo-actions.

And I would prefer if everything related to the formationOrderIndex is kept in 
the subclass PublicCompany_1825, as it is only used by those. 
I am usually confused by variables in a base class, which are only used in 
subclass context.

> Route awareness and revenue calculation: Have a variety of issues.
> I'm reasonably confident I can fix these with the framework Stefan has
> put together, I just haven't got round to looking at what needs doing
> yet, so for the moment these two settings default to off.
>
Actually I only read your mail carefully after I have added the required code 
for 1825 revenue calculation. Sorry for not leaving that for you.
A good reason for that was that I had the idea for the 1825 issues already in 
mind during the implementation of the revenue modifier framework. 
And from this I knew that I had to change a few subtle issues there to allow 
the 1825 modifiers show the results correctly.
Without those the task would have been much harder.

So there are now two dynamic modifiers, which allow double heading and prevent 
termination at towns. Feel free to test and adapt them to your needs.

There is still one issue on revenue calculation: There is nothing preventing a 
train visiting two stations on a tile. The current method is to set the city 
attribute for all station of that tile to an identical value (in Tiles.xml). 
Erik already critized that and I am close to suggest that an attribute in 
TileSet.xml might be better (for example a VisitOnlyOnce attribute).

Route awareness is currently work in progress, as I intend to add true route 
checks in a hopefully not too distant future. As 1825 has some rule 
adjustments in that area, it is worth to wait for changes there. I intend to 
provide a modifier interface similar to those used for revenue calculation.

Re: [Rails-devel] 1825 patch

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

I have added unplayable hexes to the left side where regional extensions
exist,
and removed Q21 and Q27 at the upper border, which do not exist in any
extension.
Comments in Map.xml now indicate which units and regional kits relate to
each group of unplayable hexes.

I think that for all or most other units and kits new (preprinted) tiles
need be created. I can do that - let me know when you think you are ready to
work on these extensions, at which time I will try to give it some priority.

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Friday 17 September 2010 00:45
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

Erik,

No problem, I get mistaken for a Paul all the time ;)

Yes, I will need an extra column to the left (well, a line of hexes
that borders on that edge anyway, it jumps between two column numbers
given the hex orientation). I've been meaning to try this out at some
point but does the map XML support IfOption tags for defining hexes?
The ability to add on the extra units and extensions is going to be
useful at some point, presumeably we can make it so that the lines are
this invisible hex colour if the extensions aren't in use and put the
real hexes there if they are

Phil



On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:

> (Apologies to Phil for misspelling his name)
>
> I have created a white tile -10000 that has now replaced tile 0 for the
> Q-row, and marked it as not upgradable. It is not completely invisible, as
> the map background turns out to be a bit off-white. If anyone can detect
> that colour's RGB value, I can apply it to this new tile too.
>
> By the way, Phil, don't you need some of these extra tiles at the
left-hand
> side of Unit 1 as well?
>
> While at tile tweaking, in the 18EU map I have also replaced tile -10 by
the
> -3007 (Y) and -3008 centered city tiles, that I had created specially for
> 18EU, but apparently overlooked to use them in the map. The Y label is now
> visible, as requested by John Galt.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Thursday 16 September 2010 02:11
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> I hadn't really decided what to do with that row long term. I was
> running a test game and found some odd behaviour when I used map
> correction to rotate a tile so that it pointed one end of it's track
> off map (the most obvious is that the next company to operate cannot
> lay a tile!) I added the extra row as a quick get out and that worked,
> honestly I forgot to remove it before submitting a patch!
>
> Actually, yes, if you could apply that fix you suggest, for the moment
> having this spare row works, I'll need to do something a bit more
> permanent when I get round to adding in Unit 2 since it will use that
> row but I can think about it when we get to that point!
>
> Phil
>
>
>
> On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
>
>> Hi Phil,
>>
>> Well done.
>>
>> On the Q row: I suppose you don't want to allow any tile lays on that
> extra
>> 'border' row.
>> That can be done in TileSet.xml:
>> 	<Tile id="0"><!-- Empty space -->
>> 		<Upgrade id="7,8,9"
>> hex="-Q9,Q11,Q13,Q15,Q17,Q19,Q21,Q23,Q25,Q27"/>
>> 	</Tile>
>> If you agree, I will commit that patch.
>>
>> A better solution would, of course, be to have a special blank tile that
> is
>> not upgradeable (and looks a bit different too) or to create an option to
>> make border hexsides open for track in Map.xml.
>> Such options does not yet exist, but would be nice to have. Can't promise
>> doing that soon!
>>
>> Erik.
>>
>> -----Original Message-----
>> From: Phil Davies [mailto:de...@gm...]
>> Sent: Wednesday 15 September 2010 17:12
>> To: Development list for Rails: an 18xx game
>> Subject: [Rails-devel] 1825 patch
>>
>> Could someone review and (hopefully, if it's not too broken) apply
>> this patch for some updates to the 1825 implementation.
>>
>> There is only one shared component (IE: not in the _1825 game specific
>> folder and not in the 1825 data folder) that I've hit with these
>> changes and that's the PublicCompany class and it's interface
>> PublicCompanyI.  The change I've made here is to add a
>> formationOrderIndex to the PublicCompany interface with the attendant
>> getters and setters.  The reason for doing this is that in 1825
>> companies always operate in descending par value order.  When two
>> companies share the same par value, they always operate in the order
>> they were formed.  This value is a simple incrementing integer value
>> that is a 0 for the first company at a given par, then a 1 for the
>> next and so on.  This seemed the easiest way to control operating
>> order for the OR's
>>
>> Everything else is 1825 specific code so shouldn't affect any existing
>> games, but I'd certainly be keen on any feedback as to better/worse
>> ways of doing what I've done so far.
>>
>> With this patch, 1825 becomes 'somewhat' playable.  The key issues
>> that would prevent a normal game finishing:
>>
>> Tile placement: You are allowed to place track running off the board,
>> just not running into the sea or the blank side of a brown (grey in
>> rails) hex.  Currently the rails map implementation has no way of
>> distinguishing between 'legal' off board and 'nonlegal' offboard track
>> play.  I think this can be got round using map correction as long as
>> routeawareness and revenue calculation is turned off (the bleed from
>> the network going outside of the map seems to confuse it if you map
>> correct and point a tile outside)
>>
>> Receivership and the ability to sell the presidents share to the pool
>> are not implemented, this is probably the 'big thing' to get 1825 to a
>> fully playable state, I've never played a game of the tabletop version
>> where someone didn't dump some company into receivership so without
>> that the rails implementation becomes fairly pedestrian.
>>
>> Route awareness and revenue calculation: Have a variety of issues.
>> I'm reasonably confident I can fix these with the framework Stefan has
>> put together, I just haven't got round to looking at what needs doing
>> yet, so for the moment these two settings default to off.
>>
>> Phil
>>
>>
>>
>
----------------------------------------------------------------------------
> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
----------------------------------------------------------------------------
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1825 patch

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

Yes, that should be possible.

Erik. 

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Friday 17 September 2010 00:45
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

Erik,

No problem, I get mistaken for a Paul all the time ;)

Yes, I will need an extra column to the left (well, a line of hexes
that borders on that edge anyway, it jumps between two column numbers
given the hex orientation). I've been meaning to try this out at some
point but does the map XML support IfOption tags for defining hexes?
The ability to add on the extra units and extensions is going to be
useful at some point, presumeably we can make it so that the lines are
this invisible hex colour if the extensions aren't in use and put the
real hexes there if they are

Phil



On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:

> (Apologies to Phil for misspelling his name)
>
> I have created a white tile -10000 that has now replaced tile 0 for the
> Q-row, and marked it as not upgradable. It is not completely invisible, as
> the map background turns out to be a bit off-white. If anyone can detect
> that colour's RGB value, I can apply it to this new tile too.
>
> By the way, Phil, don't you need some of these extra tiles at the
left-hand
> side of Unit 1 as well?
>
> While at tile tweaking, in the 18EU map I have also replaced tile -10 by
the
> -3007 (Y) and -3008 centered city tiles, that I had created specially for
> 18EU, but apparently overlooked to use them in the map. The Y label is now
> visible, as requested by John Galt.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Thursday 16 September 2010 02:11
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> I hadn't really decided what to do with that row long term. I was
> running a test game and found some odd behaviour when I used map
> correction to rotate a tile so that it pointed one end of it's track
> off map (the most obvious is that the next company to operate cannot
> lay a tile!) I added the extra row as a quick get out and that worked,
> honestly I forgot to remove it before submitting a patch!
>
> Actually, yes, if you could apply that fix you suggest, for the moment
> having this spare row works, I'll need to do something a bit more
> permanent when I get round to adding in Unit 2 since it will use that
> row but I can think about it when we get to that point!
>
> Phil
>
>
>
> On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
>
>> Hi Phil,
>>
>> Well done.
>>
>> On the Q row: I suppose you don't want to allow any tile lays on that
> extra
>> 'border' row.
>> That can be done in TileSet.xml:
>> 	<Tile id="0"><!-- Empty space -->
>> 		<Upgrade id="7,8,9"
>> hex="-Q9,Q11,Q13,Q15,Q17,Q19,Q21,Q23,Q25,Q27"/>
>> 	</Tile>
>> If you agree, I will commit that patch.
>>
>> A better solution would, of course, be to have a special blank tile that
> is
>> not upgradeable (and looks a bit different too) or to create an option to
>> make border hexsides open for track in Map.xml.
>> Such options does not yet exist, but would be nice to have. Can't promise
>> doing that soon!
>>
>> Erik.
>>
>> -----Original Message-----
>> From: Phil Davies [mailto:de...@gm...]
>> Sent: Wednesday 15 September 2010 17:12
>> To: Development list for Rails: an 18xx game
>> Subject: [Rails-devel] 1825 patch
>>
>> Could someone review and (hopefully, if it's not too broken) apply
>> this patch for some updates to the 1825 implementation.
>>
>> There is only one shared component (IE: not in the _1825 game specific
>> folder and not in the 1825 data folder) that I've hit with these
>> changes and that's the PublicCompany class and it's interface
>> PublicCompanyI.  The change I've made here is to add a
>> formationOrderIndex to the PublicCompany interface with the attendant
>> getters and setters.  The reason for doing this is that in 1825
>> companies always operate in descending par value order.  When two
>> companies share the same par value, they always operate in the order
>> they were formed.  This value is a simple incrementing integer value
>> that is a 0 for the first company at a given par, then a 1 for the
>> next and so on.  This seemed the easiest way to control operating
>> order for the OR's
>>
>> Everything else is 1825 specific code so shouldn't affect any existing
>> games, but I'd certainly be keen on any feedback as to better/worse
>> ways of doing what I've done so far.
>>
>> With this patch, 1825 becomes 'somewhat' playable.  The key issues
>> that would prevent a normal game finishing:
>>
>> Tile placement: You are allowed to place track running off the board,
>> just not running into the sea or the blank side of a brown (grey in
>> rails) hex.  Currently the rails map implementation has no way of
>> distinguishing between 'legal' off board and 'nonlegal' offboard track
>> play.  I think this can be got round using map correction as long as
>> routeawareness and revenue calculation is turned off (the bleed from
>> the network going outside of the map seems to confuse it if you map
>> correct and point a tile outside)
>>
>> Receivership and the ability to sell the presidents share to the pool
>> are not implemented, this is probably the 'big thing' to get 1825 to a
>> fully playable state, I've never played a game of the tabletop version
>> where someone didn't dump some company into receivership so without
>> that the rails implementation becomes fairly pedestrian.
>>
>> Route awareness and revenue calculation: Have a variety of issues.
>> I'm reasonably confident I can fix these with the framework Stefan has
>> put together, I just haven't got round to looking at what needs doing
>> yet, so for the moment these two settings default to off.
>>
>> Phil
>>
>>
>>
>
----------------------------------------------------------------------------
> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
----------------------------------------------------------------------------
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1825 patch

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

Erik,

No problem, I get mistaken for a Paul all the time ;)

Yes, I will need an extra column to the left (well, a line of hexes
that borders on that edge anyway, it jumps between two column numbers
given the hex orientation). I've been meaning to try this out at some
point but does the map XML support IfOption tags for defining hexes?
The ability to add on the extra units and extensions is going to be
useful at some point, presumeably we can make it so that the lines are
this invisible hex colour if the extensions aren't in use and put the
real hexes there if they are

Phil



On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:

> (Apologies to Phil for misspelling his name)
>
> I have created a white tile -10000 that has now replaced tile 0 for the
> Q-row, and marked it as not upgradable. It is not completely invisible, as
> the map background turns out to be a bit off-white. If anyone can detect
> that colour's RGB value, I can apply it to this new tile too.
>
> By the way, Phil, don't you need some of these extra tiles at the left-hand
> side of Unit 1 as well?
>
> While at tile tweaking, in the 18EU map I have also replaced tile -10 by the
> -3007 (Y) and -3008 centered city tiles, that I had created specially for
> 18EU, but apparently overlooked to use them in the map. The Y label is now
> visible, as requested by John Galt.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Thursday 16 September 2010 02:11
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> I hadn't really decided what to do with that row long term. I was
> running a test game and found some odd behaviour when I used map
> correction to rotate a tile so that it pointed one end of it's track
> off map (the most obvious is that the next company to operate cannot
> lay a tile!) I added the extra row as a quick get out and that worked,
> honestly I forgot to remove it before submitting a patch!
>
> Actually, yes, if you could apply that fix you suggest, for the moment
> having this spare row works, I'll need to do something a bit more
> permanent when I get round to adding in Unit 2 since it will use that
> row but I can think about it when we get to that point!
>
> Phil
>
>
>
> On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
>
>> Hi Phil,
>>
>> Well done.
>>
>> On the Q row: I suppose you don't want to allow any tile lays on that
> extra
>> 'border' row.
>> That can be done in TileSet.xml:
>> 	<Tile id="0"><!-- Empty space -->
>> 		<Upgrade id="7,8,9"
>> hex="-Q9,Q11,Q13,Q15,Q17,Q19,Q21,Q23,Q25,Q27"/>
>> 	</Tile>
>> If you agree, I will commit that patch.
>>
>> A better solution would, of course, be to have a special blank tile that
> is
>> not upgradeable (and looks a bit different too) or to create an option to
>> make border hexsides open for track in Map.xml.
>> Such options does not yet exist, but would be nice to have. Can't promise
>> doing that soon!
>>
>> Erik.
>>
>> -----Original Message-----
>> From: Phil Davies [mailto:de...@gm...]
>> Sent: Wednesday 15 September 2010 17:12
>> To: Development list for Rails: an 18xx game
>> Subject: [Rails-devel] 1825 patch
>>
>> Could someone review and (hopefully, if it's not too broken) apply
>> this patch for some updates to the 1825 implementation.
>>
>> There is only one shared component (IE: not in the _1825 game specific
>> folder and not in the 1825 data folder) that I've hit with these
>> changes and that's the PublicCompany class and it's interface
>> PublicCompanyI.  The change I've made here is to add a
>> formationOrderIndex to the PublicCompany interface with the attendant
>> getters and setters.  The reason for doing this is that in 1825
>> companies always operate in descending par value order.  When two
>> companies share the same par value, they always operate in the order
>> they were formed.  This value is a simple incrementing integer value
>> that is a 0 for the first company at a given par, then a 1 for the
>> next and so on.  This seemed the easiest way to control operating
>> order for the OR's
>>
>> Everything else is 1825 specific code so shouldn't affect any existing
>> games, but I'd certainly be keen on any feedback as to better/worse
>> ways of doing what I've done so far.
>>
>> With this patch, 1825 becomes 'somewhat' playable.  The key issues
>> that would prevent a normal game finishing:
>>
>> Tile placement: You are allowed to place track running off the board,
>> just not running into the sea or the blank side of a brown (grey in
>> rails) hex.  Currently the rails map implementation has no way of
>> distinguishing between 'legal' off board and 'nonlegal' offboard track
>> play.  I think this can be got round using map correction as long as
>> routeawareness and revenue calculation is turned off (the bleed from
>> the network going outside of the map seems to confuse it if you map
>> correct and point a tile outside)
>>
>> Receivership and the ability to sell the presidents share to the pool
>> are not implemented, this is probably the 'big thing' to get 1825 to a
>> fully playable state, I've never played a game of the tabletop version
>> where someone didn't dump some company into receivership so without
>> that the rails implementation becomes fairly pedestrian.
>>
>> Route awareness and revenue calculation: Have a variety of issues.
>> I'm reasonably confident I can fix these with the framework Stefan has
>> put together, I just haven't got round to looking at what needs doing
>> yet, so for the moment these two settings default to off.
>>
>> Phil
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ----------------------------------------------------------------------------
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ----------------------------------------------------------------------------
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel