Menu
▾
▴
Re: [Rails-devel] 1825 patch
|
From: Erik V. <eri...@xs...> - 2010-09-17 15:53:27
|
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 |
