From: Stefan F. <ste...@we...> - 2012-05-19 04:49:47
|
Erik: I would still prefer a solution which assigns the mine station of the ZKB tile the name "mine" and the town on that tile no name. The scenario that both have the name "mine", but that the "loop" attribute on the map.xml overrides the behavior seems odd to me. Maybe the best solution in the long run is to add a "vertexSet" attribute to stations directly to avoid connecting the functionality with the labeling issues. Or add a vertexSet tag to Map.xml which explicitly lists the stations that cannot be run to at the same time. More comments see below. Stefan On 05/18/2012 07:40 PM, Erik Vos wrote: > Stefan, > > Modifying Tiles.xml is inherently unsafe. You are betting on me not having > to fix tiles in a game, or if I do, that I would remember to retrofit your > changes manually. > I'd consider that a pretty unsafe bet, as it has already turned out to be > with 1835 - although not yet with 18EU. > In theory I could hardcode such specialties in the now generic > ConvertTilesXML class, but that is not a route that I want to take. > (The whole tile creation process is explained at length in the Wiki page > that I published earlier this week.) I was under the impression, that you had implemented a bypass for hand-made definitions in Tiles.xml: Is not exactly that the function of HandmadeTiles.xml in the Tiles directory? And the Berlin tile of 1835 is missing, whereas the 18EU tiles are included. Would not adding Berlin tile there make it safe? > > For exactly this purpose I have added the 'loop' attribute, which was > intended to replace your initial approach. > Adding<Access loop="no"/> to the relevant hex definitions in Map.xml > should enable you to pick up the exception via tile.isLoopAllowed() or > stop.isLoopAllowed(). That is the intention of this attribute, however it is not (yet) supported by the revenue calculation code. And the attribute itself does not fix the issue we have to address for 1837. > > Erik. > >> -----Original Message----- >> From: Stefan Frey [mailto:ste...@we...] >> Sent: Friday, May 18, 2012 1:24 PM >> To: Development list for Rails: an 18xx game >> Subject: Re: [Rails-devel] 1837 Revenue Calculation >> >> Erik: >> in principle there is no need to add a special type for individual stops. > I >> referred to the attribute that allowed the naming of stations in > Tiles.xml. >> >> The current code supports the "city"-attribute for the Station tag in > Tiles.xml. >> This allowed the naming of individual stations and thus creates > automatically >> VertexVisitSets for identical named stations. >> This is used for e.g. for the Paris and Berlin/Vienna Tiles in 18EU. >> >> It was also (initially) implemented for Berlin in 1835, however this was > erased >> by a commit from you 11 months ago (so this requires a fix, as yellow > Berlin- >> Berlin runs are allowed currently). >> >> I remember that you were in opposition to this approach (most likely as > you >> create the Tiles.xml automatically and so there is always the danger of >> removing this, but I believed that you were able to provide an automatic > by- >> pass). So maybe you can suggest a different handling. >> >> Keep in mind that the name approach is used for the off-board map, >> however the names are taken here from Map.xml. >> >> Stefan >> >> >> On 05/17/2012 10:54 AM, Erik Vos wrote: >>> OK. >>> We don't yet have the capability to assign special types to individual >>> stops on one tile, so I will work to add such a capability. >>> Perhaps adding a 'stop' attribute to the<Access> tag will do (in >>> other places 'city' is used, but I think those can better be replaced by > 'stop' >>> too). >>> >>> Erik. >>> >>>> -----Original Message----- >>>> From: Stefan Frey [mailto:ste...@we...] >>>> Sent: Tuesday, May 15, 2012 1:53 PM >>>> To: Development list for Rails: an 18xx game >>>> Subject: Re: [Rails-devel] 1837 Revenue Calculation >>>> >>>> Erik: >>>> town or offboard does not matter as the node will be replaced by a >>>> bonus- node anyway. >>>> >>>> Another good thing about setting name/id to "mine" is that this >>>> identifies >>> the >>>> correct node(s) to replace (in the case of ZKB). >>>> So for ZKB the definition of the tile should be a two-town tile with >>>> the >>> correct >>>> town labeled as "mine". >>>> Stefan >>>> >>>> >>>> On 05/15/2012 01:37 PM, Erik Vos wrote: >>>>> BTW I chose the mines to be town type because towns cannot be >> tokened. >>>>> >>>>>> -----Original Message----- >>>>>> From: Erik Vos [mailto:eri...@xs...] >>>>>> Sent: Tuesday, May 15, 2012 1:12 PM >>>>>> To: 'Development list for Rails: an 18xx game' >>>>>> Subject: Re: [Rails-devel] 1837 Revenue Calculation >>>>>> >>>>>> See below. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stefan Frey [mailto:ste...@we...] >>>>>> >>>>>>> B) Define the coal tiles as offboard fields. Add a >>>>>>> StaticRevenueModifier >>>>>> that >>>>>>> removes the offboard (major scoring) node and replace it by a >>>>>>> bonus vertex for the G-trains only. (Bonus vertices can be defined >>>>>>> to be train >>>>>> dependent, >>>>>>> whereas scoring nodes have to be identical). >>>>>> >>>>>> I have provisionally defined the mine tiles as fixed (i.e. grey) >>>>>> with a >>>>> town that >>>>>> has zero (i.e. variable) value. >>>>>> (This definition is mainly for usage in XML, the real picture will >>>>>> be >>>>> different >>>>>> once we have better SVG tiles). >>>>>> I can change that if you want, but my thinking was that this hex >>>>>> would not really behave as an off-board one. >>>>>> And I can replace the town by a city if you prefer that. >>>>>> >>>>>> One potential problem is the ZKB mine tile, with has two stops: a >>>>> fixed-value >>>>>> village and a variable-value mine. >>>>>> Can you handle that? See below. >>>>>> >>>>>>> C) Add a name="Mine" attribute to all mines. This automatically >>>>>>> treats >>>>>> them >>>>>>> as a VertexVisitSet and thus a train can only visit one of them. >>>>>>> Alternatively this could be checked in step D) too. >>>>>> >>>>>> In Map.xml or in TileSet.xml? >>>>>> For the ZKB this should apply to only one of the two stops, so >>>>>> perhaps we should add an extra 'city="1"' attribute. >>>>>> >>>>>>> D) Add a DynamicRevenueModifier that checks that routes of >>>>>>> G-Trains have at least one mine in their route, otherwise the >>>>>>> route will be >>> void. >>>>>>> >>>>>>> I can easily add those elements, however I will wait until it is >>>>>>> possible >>>>>> to have >>>>>>> 1837 at least startup, so that I am able to test. >>>>>> >>>>>> 1837 already starts, in that it displays all initial windows. I >>>>>> haven't >>>>> tried >>>>>> anything beyond that point. The only specific class is >>>>>> StartRound_1835; otherwise, the 1830 rules apply. >>>>>> >>>>>> Erik. >>>>>> >>>>>> >>>>>> >>>>> -------------------------------------------------------------------- >>>>> -- >>>>> ------ >>>>> -- >>>>>> Live Security Virtual Conference >>>>>> Exclusive live event will cover all the ways today's security and >>>>>> threat landscape has changed and how IT managers can respond. >>>>>> Discussions will include endpoint security, mobile security and the >>>>>> latest in malware >>>>> threats. >>>>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>>> _______________________________________________ >>>>>> Rails-devel mailing list >>>>>> Rai...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> -- >>>>> -------- >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. >>>>> Discussions will include endpoint security, mobile security and the >>>>> latest in malware threats. >>>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> _______________________________________________ >>>>> Rails-devel mailing list >>>>> Rai...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>>> >>>> >>>> >>> ---------------------------------------------------------------------- >>> ------ >>> -- >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. >>>> Discussions will include endpoint security, mobile security and the >>>> latest in malware >>> threats. >>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> Rails-devel mailing list >>>> Rai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rails-devel >>> >>> >>> ---------------------------------------------------------------------- >>> -------- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. >>> Discussions will include endpoint security, mobile security and the >>> latest in malware threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Rails-devel mailing list >>> Rai...@li... >>> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> >> > ---------------------------------------------------------------------------- > -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and threat >> landscape has changed and how IT managers can respond. Discussions will >> include endpoint security, mobile security and the latest in malware > threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |