Menu
▾
▴
rails-devel
|
From: Bill R. <ro...@gm...> - 2011-01-25 09:58:08
|
Hello,
Hopefully this is the right place to post this. I've recently checked the source out of svn and have been playing around with rails (so that I can play 18EU on my laptop with small screen). When playing 1889 I run into a problem that the owner of private B cannot lay the port tile, but only if I use the code I've checked out of svn -- version 1.4 works correctly.
Specifically, when the user clicks on a map space where he can lay the port tile there's a NullPointerException thrown from line 106 of UpgradesPanel.populate(). It looks like the call to layTile.getTileColours() returns a null pointer for at least one of the tiles in the list (I assume it's the port tile, since it's a special tile, so the constructed of LayTile is called for the SPECIAL_PROPERTY case where LayTile.tileColours does not get set.
I have a savegame that can be used as a test-case, but I encounter this problem literally anytime the owner of private B attempts to lay the port tile (which can be as early as the first tile lay), so I'm not sure it's worth sending out.
I am able to get around the problem my testing that layTile.getTileColours() returns non-null, but as I'm not familiar with the code, I'm not sure if that will break anything else. Specifically, if I change lines 104-115 of UpgradesPanel.populate() to the following:
for (TileI tile : tiles) {
// Skip if not allowed in LayTile
if (layTile.getTileColours() != null && layTile.getTileColours().get(tile.getColourName()) < 1) continue;
// special check: does the tile increase the colour number?
// this avoids that a special tile lay down or equalgrades existing tiles
// TODO EV: I'm not sure if this is a necessary precaution.
if (layTile.getTileColours() != null && !layTile.isTileColourAllowed(tile.getColourName())) continue;
if (!orUIManager.tileUpgrades.contains(tile))
orUIManager.tileUpgrades.add(tile);
}
then it seems that the private power works correctly.
I'd send a patch, but I'm not convinced that UpgradesPanel is the right place to make this change and I'm also not sure that the bug isn't some artifact of me misconfiguring Eclipse.
Thanks,
Bill Rosgen
|
|
From: Phil D. <de...@gm...> - 2011-01-25 10:28:30
|
Bill,
I've just checked this against the trunk code checked out today and I
don't have this problem.
Are you using a saved game made with 1.4? There has been a change to
the tile manifest to 1889 (tile 440 was broken) so it's likely that
your saved game won't work with the trunk code because of this change.
Starting a new game from scratch and using B's power worked okay for
me.
Phil
On 25 January 2011 09:57, Bill Rosgen <ro...@gm...> wrote:
> Hello,
>
> Hopefully this is the right place to post this. I've recently checked the source out of svn and have been playing around with rails (so that I can play 18EU on my laptop with small screen). When playing 1889 I run into a problem that the owner of private B cannot lay the port tile, but only if I use the code I've checked out of svn -- version 1.4 works correctly.
>
> Specifically, when the user clicks on a map space where he can lay the port tile there's a NullPointerException thrown from line 106 of UpgradesPanel.populate(). It looks like the call to layTile.getTileColours() returns a null pointer for at least one of the tiles in the list (I assume it's the port tile, since it's a special tile, so the constructed of LayTile is called for the SPECIAL_PROPERTY case where LayTile.tileColours does not get set.
>
> I have a savegame that can be used as a test-case, but I encounter this problem literally anytime the owner of private B attempts to lay the port tile (which can be as early as the first tile lay), so I'm not sure it's worth sending out.
>
> I am able to get around the problem my testing that layTile.getTileColours() returns non-null, but as I'm not familiar with the code, I'm not sure if that will break anything else. Specifically, if I change lines 104-115 of UpgradesPanel.populate() to the following:
>
> for (TileI tile : tiles) {
> // Skip if not allowed in LayTile
> if (layTile.getTileColours() != null && layTile.getTileColours().get(tile.getColourName()) < 1) continue;
>
> // special check: does the tile increase the colour number?
> // this avoids that a special tile lay down or equalgrades existing tiles
> // TODO EV: I'm not sure if this is a necessary precaution.
> if (layTile.getTileColours() != null && !layTile.isTileColourAllowed(tile.getColourName())) continue;
>
> if (!orUIManager.tileUpgrades.contains(tile))
> orUIManager.tileUpgrades.add(tile);
> }
>
> then it seems that the private power works correctly.
>
> I'd send a patch, but I'm not convinced that UpgradesPanel is the right place to make this change and I'm also not sure that the bug isn't some artifact of me misconfiguring Eclipse.
>
> Thanks,
> Bill Rosgen
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
|
|
From: Bill R. <ro...@gm...> - 2011-01-25 10:42:10
|
Hi Phil,
I encounter this error when playing a new game created in the trunk code. If it works for others, it's probably some sort of misconfiguration on my end. As far as I can tell I have the latest version of the source, but I'm not very familiar with Eclipse.
Bill
On 2011-01-25, at 18:23 , Phil Davies wrote:
> Bill,
>
> I've just checked this against the trunk code checked out today and I
> don't have this problem.
>
> Are you using a saved game made with 1.4? There has been a change to
> the tile manifest to 1889 (tile 440 was broken) so it's likely that
> your saved game won't work with the trunk code because of this change.
> Starting a new game from scratch and using B's power worked okay for
> me.
>
> Phil
>
>
> On 25 January 2011 09:57, Bill Rosgen <ro...@gm...> wrote:
>> Hello,
>>
>> Hopefully this is the right place to post this. I've recently checked the source out of svn and have been playing around with rails (so that I can play 18EU on my laptop with small screen). When playing 1889 I run into a problem that the owner of private B cannot lay the port tile, but only if I use the code I've checked out of svn -- version 1.4 works correctly.
>>
>> Specifically, when the user clicks on a map space where he can lay the port tile there's a NullPointerException thrown from line 106 of UpgradesPanel.populate(). It looks like the call to layTile.getTileColours() returns a null pointer for at least one of the tiles in the list (I assume it's the port tile, since it's a special tile, so the constructed of LayTile is called for the SPECIAL_PROPERTY case where LayTile.tileColours does not get set.
>>
>> I have a savegame that can be used as a test-case, but I encounter this problem literally anytime the owner of private B attempts to lay the port tile (which can be as early as the first tile lay), so I'm not sure it's worth sending out.
>>
>> I am able to get around the problem my testing that layTile.getTileColours() returns non-null, but as I'm not familiar with the code, I'm not sure if that will break anything else. Specifically, if I change lines 104-115 of UpgradesPanel.populate() to the following:
>>
>> for (TileI tile : tiles) {
>> // Skip if not allowed in LayTile
>> if (layTile.getTileColours() != null && layTile.getTileColours().get(tile.getColourName()) < 1) continue;
>>
>> // special check: does the tile increase the colour number?
>> // this avoids that a special tile lay down or equalgrades existing tiles
>> // TODO EV: I'm not sure if this is a necessary precaution.
>> if (layTile.getTileColours() != null && !layTile.isTileColourAllowed(tile.getColourName())) continue;
>>
>> if (!orUIManager.tileUpgrades.contains(tile))
>> orUIManager.tileUpgrades.add(tile);
>> }
>>
>> then it seems that the private power works correctly.
>>
>> I'd send a patch, but I'm not convinced that UpgradesPanel is the right place to make this change and I'm also not sure that the bug isn't some artifact of me misconfiguring Eclipse.
>>
>> Thanks,
>> Bill Rosgen
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Erik V. <eri...@xs...> - 2011-02-04 18:42:11
|
Fixed bug #3165621: 1889 port token could not be laid.
Tile laying code has been generally cleaned up and simplified. Some other
(unrelated) minor bugs have been found and fixed.
Cases where both a regular and a special property-originating tile can be
laid on the same hex now work correctly (such as in 1899 hex G10 in the
saved file provided with the above bug).
Please let me know if any unwanted change in behaviour of tile laying
processes are found. I have done quite some testing (and found some more
bugs in that process, still to fix), but it's not really possible to check
for all potential side effects of changing such old code.
> -----Oorspronkelijk bericht-----
> Van: Bill Rosgen [mailto:ro...@gm...]
> Verzonden: dinsdag 25 januari 2011 11:42
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] 1889 Regression: private B and laying the
port
> tile?
>
> Hi Phil,
>
> I encounter this error when playing a new game created in the trunk code.
If
> it works for others, it's probably some sort of misconfiguration on my
end.
> As far as I can tell I have the latest version of the source, but I'm not
very
> familiar with Eclipse.
>
> Bill
>
> On 2011-01-25, at 18:23 , Phil Davies wrote:
>
> > Bill,
> >
> > I've just checked this against the trunk code checked out today and I
> > don't have this problem.
> >
> > Are you using a saved game made with 1.4? There has been a change to
> > the tile manifest to 1889 (tile 440 was broken) so it's likely that
> > your saved game won't work with the trunk code because of this change.
> > Starting a new game from scratch and using B's power worked okay for
> > me.
> >
> > Phil
> >
> >
> > On 25 January 2011 09:57, Bill Rosgen <ro...@gm...> wrote:
> >> Hello,
> >>
> >> Hopefully this is the right place to post this. I've recently checked
the
> source out of svn and have been playing around with rails (so that I can
play
> 18EU on my laptop with small screen). When playing 1889 I run into a
> problem that the owner of private B cannot lay the port tile, but only if
I use
> the code I've checked out of svn -- version 1.4 works correctly.
> >>
> >> Specifically, when the user clicks on a map space where he can lay the
> port tile there's a NullPointerException thrown from line 106 of
> UpgradesPanel.populate(). It looks like the call to
layTile.getTileColours()
> returns a null pointer for at least one of the tiles in the list (I assume
it's the
> port tile, since it's a special tile, so the constructed of LayTile is
called for the
> SPECIAL_PROPERTY case where LayTile.tileColours does not get set.
> >>
> >> I have a savegame that can be used as a test-case, but I encounter this
> problem literally anytime the owner of private B attempts to lay the port
tile
> (which can be as early as the first tile lay), so I'm not sure it's worth
sending
> out.
> >>
> >> I am able to get around the problem my testing that
> layTile.getTileColours() returns non-null, but as I'm not familiar with
the code,
> I'm not sure if that will break anything else. Specifically, if I change
lines 104-
> 115 of UpgradesPanel.populate() to the following:
> >>
> >> for (TileI tile : tiles) {
> >> // Skip if not allowed in LayTile
> >> if (layTile.getTileColours() != null &&
> >> layTile.getTileColours().get(tile.getColourName()) < 1) continue;
> >>
> >> // special check: does the tile increase the colour
number?
> >> // this avoids that a special tile lay down or
equalgrades existing
> tiles
> >> // TODO EV: I'm not sure if this is a necessary
precaution.
> >> if (layTile.getTileColours() != null &&
> >> !layTile.isTileColourAllowed(tile.getColourName())) continue;
> >>
> >> if (!orUIManager.tileUpgrades.contains(tile))
> >> orUIManager.tileUpgrades.add(tile);
> >> }
> >>
> >> then it seems that the private power works correctly.
> >>
> >> I'd send a patch, but I'm not convinced that UpgradesPanel is the right
> place to make this change and I'm also not sure that the bug isn't some
> artifact of me misconfiguring Eclipse.
> >>
> >> Thanks,
> >> Bill Rosgen
> >>
> >>
> >> ---------------------------------------------------------------------
> >> --------- Special Offer-- Download ArcSight Logger for FREE (a $49
> >> USD value)!
> >> Finally, a world-class log management solution at an even better price-
> free!
> >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> >> February 28th, so secure your free ArcSight Logger TODAY!
> >> http://p.sf.net/sfu/arcsight-sfd2d
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >
> > ----------------------------------------------------------------------
> > -------- Special Offer-- Download ArcSight Logger for FREE (a $49 USD
> > value)!
> > Finally, a world-class log management solution at an even better
price-free!
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > February 28th, so secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsight-sfd2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
----------------------------------------------------------------------------
--
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Phil D. <de...@gm...> - 2011-02-10 15:24:00
Attachments:
1851_20110210_1520_Phil.rails
|
Erik,
I think something is going funny with the tile laying code in games
where you can lay multiple tiles in a turn. Try loading up the
attached saved game and try and lay a yellow tile somewhere, you get
the following error noted below. I spotted this trying to do some
work on 1825 but it's present in 1851, I haven't tried 1835 yet but I
imagine it might have the same situation. Seems to be a failure
around decreasing the number of allowed tile lays for the company.
Exception in thread "AWT-EventQueue-0" java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
at rails.game.OperatingRound.updateAllowedTileColours(OperatingRound.java:476)
at rails.game.OperatingRound.checkNormalTileLay(OperatingRound.java:458)
at rails.game.OperatingRound.registerNormalTileLay(OperatingRound.java:445)
at rails.game.OperatingRound.layTile(OperatingRound.java:429)
at rails.game.OperatingRound.process(OperatingRound.java:192)
at rails.game.GameManager.process(GameManager.java:824)
at rails.ui.swing.GameUIManager.processOnServer(GameUIManager.java:239)
at rails.ui.swing.ORWindow.process(ORWindow.java:154)
at rails.ui.swing.ORUIManager.layTile(ORUIManager.java:796)
at rails.ui.swing.ORUIManager.executeUpgrade(ORUIManager.java:1328)
at rails.ui.swing.UpgradesPanel.actionPerformed(UpgradesPanel.java:399)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
On 4 February 2011 18:42, Erik Vos <eri...@xs...> wrote:
> Fixed bug #3165621: 1889 port token could not be laid.
> Tile laying code has been generally cleaned up and simplified. Some other
> (unrelated) minor bugs have been found and fixed.
> Cases where both a regular and a special property-originating tile can be
> laid on the same hex now work correctly (such as in 1899 hex G10 in the
> saved file provided with the above bug).
>
> Please let me know if any unwanted change in behaviour of tile laying
> processes are found. I have done quite some testing (and found some more
> bugs in that process, still to fix), but it's not really possible to check
> for all potential side effects of changing such old code.
>
>> -----Oorspronkelijk bericht-----
>> Van: Bill Rosgen [mailto:ro...@gm...]
>> Verzonden: dinsdag 25 januari 2011 11:42
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] 1889 Regression: private B and laying the
> port
>> tile?
>>
>> Hi Phil,
>>
>> I encounter this error when playing a new game created in the trunk code.
> If
>> it works for others, it's probably some sort of misconfiguration on my
> end.
>> As far as I can tell I have the latest version of the source, but I'm not
> very
>> familiar with Eclipse.
>>
>> Bill
>>
>> On 2011-01-25, at 18:23 , Phil Davies wrote:
>>
>> > Bill,
>> >
>> > I've just checked this against the trunk code checked out today and I
>> > don't have this problem.
>> >
>> > Are you using a saved game made with 1.4? There has been a change to
>> > the tile manifest to 1889 (tile 440 was broken) so it's likely that
>> > your saved game won't work with the trunk code because of this change.
>> > Starting a new game from scratch and using B's power worked okay for
>> > me.
>> >
>> > Phil
>> >
>> >
>> > On 25 January 2011 09:57, Bill Rosgen <ro...@gm...> wrote:
>> >> Hello,
>> >>
>> >> Hopefully this is the right place to post this. I've recently checked
> the
>> source out of svn and have been playing around with rails (so that I can
> play
>> 18EU on my laptop with small screen). When playing 1889 I run into a
>> problem that the owner of private B cannot lay the port tile, but only if
> I use
>> the code I've checked out of svn -- version 1.4 works correctly.
>> >>
>> >> Specifically, when the user clicks on a map space where he can lay the
>> port tile there's a NullPointerException thrown from line 106 of
>> UpgradesPanel.populate(). It looks like the call to
> layTile.getTileColours()
>> returns a null pointer for at least one of the tiles in the list (I assume
> it's the
>> port tile, since it's a special tile, so the constructed of LayTile is
> called for the
>> SPECIAL_PROPERTY case where LayTile.tileColours does not get set.
>> >>
>> >> I have a savegame that can be used as a test-case, but I encounter this
>> problem literally anytime the owner of private B attempts to lay the port
> tile
>> (which can be as early as the first tile lay), so I'm not sure it's worth
> sending
>> out.
>> >>
>> >> I am able to get around the problem my testing that
>> layTile.getTileColours() returns non-null, but as I'm not familiar with
> the code,
>> I'm not sure if that will break anything else. Specifically, if I change
> lines 104-
>> 115 of UpgradesPanel.populate() to the following:
>> >>
>> >> for (TileI tile : tiles) {
>> >> // Skip if not allowed in LayTile
>> >> if (layTile.getTileColours() != null &&
>> >> layTile.getTileColours().get(tile.getColourName()) < 1) continue;
>> >>
>> >> // special check: does the tile increase the colour
> number?
>> >> // this avoids that a special tile lay down or
> equalgrades existing
>> tiles
>> >> // TODO EV: I'm not sure if this is a necessary
> precaution.
>> >> if (layTile.getTileColours() != null &&
>> >> !layTile.isTileColourAllowed(tile.getColourName())) continue;
>> >>
>> >> if (!orUIManager.tileUpgrades.contains(tile))
>> >> orUIManager.tileUpgrades.add(tile);
>> >> }
>> >>
>> >> then it seems that the private power works correctly.
>> >>
>> >> I'd send a patch, but I'm not convinced that UpgradesPanel is the right
>> place to make this change and I'm also not sure that the bug isn't some
>> artifact of me misconfiguring Eclipse.
>> >>
>> >> Thanks,
>> >> Bill Rosgen
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> --------- Special Offer-- Download ArcSight Logger for FREE (a $49
>> >> USD value)!
>> >> Finally, a world-class log management solution at an even better price-
>> free!
>> >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> >> February 28th, so secure your free ArcSight Logger TODAY!
>> >> http://p.sf.net/sfu/arcsight-sfd2d
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >>
>> >
>> > ----------------------------------------------------------------------
>> > -------- Special Offer-- Download ArcSight Logger for FREE (a $49 USD
>> > value)!
>> > Finally, a world-class log management solution at an even better
> price-free!
>> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> > February 28th, so secure your free ArcSight Logger TODAY!
>> > http://p.sf.net/sfu/arcsight-sfd2d
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better
> price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
|
|
From: Phil D. <de...@gm...> - 2011-02-10 15:30:36
|
Minor clarification...this only appears to be an issue with dev code,
not the 1.4.1 release...so actually if this is something that has come
about as a result of things you are working on then just ignore me :)
On 10 February 2011 15:23, Phil Davies <de...@gm...> wrote:
> Erik,
>
> I think something is going funny with the tile laying code in games
> where you can lay multiple tiles in a turn. Try loading up the
> attached saved game and try and lay a yellow tile somewhere, you get
> the following error noted below. I spotted this trying to do some
> work on 1825 but it's present in 1851, I haven't tried 1835 yet but I
> imagine it might have the same situation. Seems to be a failure
> around decreasing the number of allowed tile lays for the company.
>
>
> Exception in thread "AWT-EventQueue-0" java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
> at java.util.HashMap$KeyIterator.next(Unknown Source)
> at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
> at rails.game.OperatingRound.updateAllowedTileColours(OperatingRound.java:476)
> at rails.game.OperatingRound.checkNormalTileLay(OperatingRound.java:458)
> at rails.game.OperatingRound.registerNormalTileLay(OperatingRound.java:445)
> at rails.game.OperatingRound.layTile(OperatingRound.java:429)
> at rails.game.OperatingRound.process(OperatingRound.java:192)
> at rails.game.GameManager.process(GameManager.java:824)
> at rails.ui.swing.GameUIManager.processOnServer(GameUIManager.java:239)
> at rails.ui.swing.ORWindow.process(ORWindow.java:154)
> at rails.ui.swing.ORUIManager.layTile(ORUIManager.java:796)
> at rails.ui.swing.ORUIManager.executeUpgrade(ORUIManager.java:1328)
> at rails.ui.swing.UpgradesPanel.actionPerformed(UpgradesPanel.java:399)
> at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
> at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
> at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
> at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
> at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
> at java.awt.Component.processMouseEvent(Unknown Source)
> at javax.swing.JComponent.processMouseEvent(Unknown Source)
> at java.awt.Component.processEvent(Unknown Source)
> at java.awt.Container.processEvent(Unknown Source)
> at java.awt.Component.dispatchEventImpl(Unknown Source)
> at java.awt.Container.dispatchEventImpl(Unknown Source)
> at java.awt.Component.dispatchEvent(Unknown Source)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
> at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
> at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
> at java.awt.Container.dispatchEventImpl(Unknown Source)
> at java.awt.Window.dispatchEventImpl(Unknown Source)
> at java.awt.Component.dispatchEvent(Unknown Source)
> at java.awt.EventQueue.dispatchEvent(Unknown Source)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.run(Unknown Source)
>
>
>
>
> On 4 February 2011 18:42, Erik Vos <eri...@xs...> wrote:
>> Fixed bug #3165621: 1889 port token could not be laid.
>> Tile laying code has been generally cleaned up and simplified. Some other
>> (unrelated) minor bugs have been found and fixed.
>> Cases where both a regular and a special property-originating tile can be
>> laid on the same hex now work correctly (such as in 1899 hex G10 in the
>> saved file provided with the above bug).
>>
>> Please let me know if any unwanted change in behaviour of tile laying
>> processes are found. I have done quite some testing (and found some more
>> bugs in that process, still to fix), but it's not really possible to check
>> for all potential side effects of changing such old code.
>>
>>> -----Oorspronkelijk bericht-----
>>> Van: Bill Rosgen [mailto:ro...@gm...]
>>> Verzonden: dinsdag 25 januari 2011 11:42
>>> Aan: Development list for Rails: an 18xx game
>>> Onderwerp: Re: [Rails-devel] 1889 Regression: private B and laying the
>> port
>>> tile?
>>>
>>> Hi Phil,
>>>
>>> I encounter this error when playing a new game created in the trunk code.
>> If
>>> it works for others, it's probably some sort of misconfiguration on my
>> end.
>>> As far as I can tell I have the latest version of the source, but I'm not
>> very
>>> familiar with Eclipse.
>>>
>>> Bill
>>>
>>> On 2011-01-25, at 18:23 , Phil Davies wrote:
>>>
>>> > Bill,
>>> >
>>> > I've just checked this against the trunk code checked out today and I
>>> > don't have this problem.
>>> >
>>> > Are you using a saved game made with 1.4? There has been a change to
>>> > the tile manifest to 1889 (tile 440 was broken) so it's likely that
>>> > your saved game won't work with the trunk code because of this change.
>>> > Starting a new game from scratch and using B's power worked okay for
>>> > me.
>>> >
>>> > Phil
>>> >
>>> >
>>> > On 25 January 2011 09:57, Bill Rosgen <ro...@gm...> wrote:
>>> >> Hello,
>>> >>
>>> >> Hopefully this is the right place to post this. I've recently checked
>> the
>>> source out of svn and have been playing around with rails (so that I can
>> play
>>> 18EU on my laptop with small screen). When playing 1889 I run into a
>>> problem that the owner of private B cannot lay the port tile, but only if
>> I use
>>> the code I've checked out of svn -- version 1.4 works correctly.
>>> >>
>>> >> Specifically, when the user clicks on a map space where he can lay the
>>> port tile there's a NullPointerException thrown from line 106 of
>>> UpgradesPanel.populate(). It looks like the call to
>> layTile.getTileColours()
>>> returns a null pointer for at least one of the tiles in the list (I assume
>> it's the
>>> port tile, since it's a special tile, so the constructed of LayTile is
>> called for the
>>> SPECIAL_PROPERTY case where LayTile.tileColours does not get set.
>>> >>
>>> >> I have a savegame that can be used as a test-case, but I encounter this
>>> problem literally anytime the owner of private B attempts to lay the port
>> tile
>>> (which can be as early as the first tile lay), so I'm not sure it's worth
>> sending
>>> out.
>>> >>
>>> >> I am able to get around the problem my testing that
>>> layTile.getTileColours() returns non-null, but as I'm not familiar with
>> the code,
>>> I'm not sure if that will break anything else. Specifically, if I change
>> lines 104-
>>> 115 of UpgradesPanel.populate() to the following:
>>> >>
>>> >> for (TileI tile : tiles) {
>>> >> // Skip if not allowed in LayTile
>>> >> if (layTile.getTileColours() != null &&
>>> >> layTile.getTileColours().get(tile.getColourName()) < 1) continue;
>>> >>
>>> >> // special check: does the tile increase the colour
>> number?
>>> >> // this avoids that a special tile lay down or
>> equalgrades existing
>>> tiles
>>> >> // TODO EV: I'm not sure if this is a necessary
>> precaution.
>>> >> if (layTile.getTileColours() != null &&
>>> >> !layTile.isTileColourAllowed(tile.getColourName())) continue;
>>> >>
>>> >> if (!orUIManager.tileUpgrades.contains(tile))
>>> >> orUIManager.tileUpgrades.add(tile);
>>> >> }
>>> >>
>>> >> then it seems that the private power works correctly.
>>> >>
>>> >> I'd send a patch, but I'm not convinced that UpgradesPanel is the right
>>> place to make this change and I'm also not sure that the bug isn't some
>>> artifact of me misconfiguring Eclipse.
>>> >>
>>> >> Thanks,
>>> >> Bill Rosgen
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> --------- Special Offer-- Download ArcSight Logger for FREE (a $49
>>> >> USD value)!
>>> >> Finally, a world-class log management solution at an even better price-
>>> free!
>>> >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>>> >> February 28th, so secure your free ArcSight Logger TODAY!
>>> >> http://p.sf.net/sfu/arcsight-sfd2d
>>> >> _______________________________________________
>>> >> Rails-devel mailing list
>>> >> Rai...@li...
>>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>> >>
>>> >
>>> > ----------------------------------------------------------------------
>>> > -------- Special Offer-- Download ArcSight Logger for FREE (a $49 USD
>>> > value)!
>>> > Finally, a world-class log management solution at an even better
>> price-free!
>>> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>>> > February 28th, so secure your free ArcSight Logger TODAY!
>>> > http://p.sf.net/sfu/arcsight-sfd2d
>>> > _______________________________________________
>>> > Rails-devel mailing list
>>> > Rai...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>>
>> ----------------------------------------------------------------------------
>> --
>>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>>> Finally, a world-class log management solution at an even better
>> price-free!
>>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>>> February 28th, so secure your free ArcSight Logger TODAY!
>>> http://p.sf.net/sfu/arcsight-sfd2d
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> The modern datacenter depends on network connectivity to access resources
>> and provide services. The best practices for maximizing a physical server's
>> connectivity to a physical network are well understood - see how these
>> rules translate into the virtual world?
>> http://p.sf.net/sfu/oracle-sfdevnlfb
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
|
|
From: <ab...@o2...> - 2011-02-10 15:30:47
|
It worked fine on my machine. I did:
L&N lays tile #9 at hex G15/SW
L&N lays tile #9 at hex H14/SW
(straight tracks continuing the existing one) with no error at all.
Windows 7, Rails 1.4.1
Adam Badura
-----Oryginalna wiadomość-----
From: Phil Davies
Sent: Thursday, February 10, 2011 4:23 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1889 Regression: private B and laying the
porttile?
Erik,
I think something is going funny with the tile laying code in games
where you can lay multiple tiles in a turn. Try loading up the
attached saved game and try and lay a yellow tile somewhere, you get
the following error noted below. I spotted this trying to do some
work on 1825 but it's present in 1851, I haven't tried 1835 yet but I
imagine it might have the same situation. Seems to be a failure
around decreasing the number of allowed tile lays for the company.
Exception in thread "AWT-EventQueue-0"
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$KeyIterator.next(Unknown Source)
at java.util.Collections$UnmodifiableCollection$1.next(Unknown Source)
at
rails.game.OperatingRound.updateAllowedTileColours(OperatingRound.java:476)
at rails.game.OperatingRound.checkNormalTileLay(OperatingRound.java:458)
at rails.game.OperatingRound.registerNormalTileLay(OperatingRound.java:445)
at rails.game.OperatingRound.layTile(OperatingRound.java:429)
at rails.game.OperatingRound.process(OperatingRound.java:192)
at rails.game.GameManager.process(GameManager.java:824)
at rails.ui.swing.GameUIManager.processOnServer(GameUIManager.java:239)
at rails.ui.swing.ORWindow.process(ORWindow.java:154)
at rails.ui.swing.ORUIManager.layTile(ORUIManager.java:796)
at rails.ui.swing.ORUIManager.executeUpgrade(ORUIManager.java:1328)
at rails.ui.swing.UpgradesPanel.actionPerformed(UpgradesPanel.java:399)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
On 4 February 2011 18:42, Erik Vos <eri...@xs...> wrote:
> Fixed bug #3165621: 1889 port token could not be laid.
> Tile laying code has been generally cleaned up and simplified. Some other
> (unrelated) minor bugs have been found and fixed.
> Cases where both a regular and a special property-originating tile can be
> laid on the same hex now work correctly (such as in 1899 hex G10 in the
> saved file provided with the above bug).
>
> Please let me know if any unwanted change in behaviour of tile laying
> processes are found. I have done quite some testing (and found some more
> bugs in that process, still to fix), but it's not really possible to check
> for all potential side effects of changing such old code.
>
>> -----Oorspronkelijk bericht-----
>> Van: Bill Rosgen [mailto:ro...@gm...]
>> Verzonden: dinsdag 25 januari 2011 11:42
>> Aan: Development list for Rails: an 18xx game
>> Onderwerp: Re: [Rails-devel] 1889 Regression: private B and laying the
> port
>> tile?
>>
>> Hi Phil,
>>
>> I encounter this error when playing a new game created in the trunk code.
> If
>> it works for others, it's probably some sort of misconfiguration on my
> end.
>> As far as I can tell I have the latest version of the source, but I'm not
> very
>> familiar with Eclipse.
>>
>> Bill
>>
>> On 2011-01-25, at 18:23 , Phil Davies wrote:
>>
>> > Bill,
>> >
>> > I've just checked this against the trunk code checked out today and I
>> > don't have this problem.
>> >
>> > Are you using a saved game made with 1.4? There has been a change to
>> > the tile manifest to 1889 (tile 440 was broken) so it's likely that
>> > your saved game won't work with the trunk code because of this change.
>> > Starting a new game from scratch and using B's power worked okay for
>> > me.
>> >
>> > Phil
>> >
>> >
>> > On 25 January 2011 09:57, Bill Rosgen <ro...@gm...> wrote:
>> >> Hello,
>> >>
>> >> Hopefully this is the right place to post this. I've recently checked
> the
>> source out of svn and have been playing around with rails (so that I can
> play
>> 18EU on my laptop with small screen). When playing 1889 I run into a
>> problem that the owner of private B cannot lay the port tile, but only if
> I use
>> the code I've checked out of svn -- version 1.4 works correctly.
>> >>
>> >> Specifically, when the user clicks on a map space where he can lay the
>> port tile there's a NullPointerException thrown from line 106 of
>> UpgradesPanel.populate(). It looks like the call to
> layTile.getTileColours()
>> returns a null pointer for at least one of the tiles in the list (I
>> assume
> it's the
>> port tile, since it's a special tile, so the constructed of LayTile is
> called for the
>> SPECIAL_PROPERTY case where LayTile.tileColours does not get set.
>> >>
>> >> I have a savegame that can be used as a test-case, but I encounter
>> >> this
>> problem literally anytime the owner of private B attempts to lay the port
> tile
>> (which can be as early as the first tile lay), so I'm not sure it's worth
> sending
>> out.
>> >>
>> >> I am able to get around the problem my testing that
>> layTile.getTileColours() returns non-null, but as I'm not familiar with
> the code,
>> I'm not sure if that will break anything else. Specifically, if I change
> lines 104-
>> 115 of UpgradesPanel.populate() to the following:
>> >>
>> >> for (TileI tile : tiles) {
>> >> // Skip if not allowed in LayTile
>> >> if (layTile.getTileColours() != null &&
>> >> layTile.getTileColours().get(tile.getColourName()) < 1) continue;
>> >>
>> >> // special check: does the tile increase the colour
> number?
>> >> // this avoids that a special tile lay down or
> equalgrades existing
>> tiles
>> >> // TODO EV: I'm not sure if this is a necessary
> precaution.
>> >> if (layTile.getTileColours() != null &&
>> >> !layTile.isTileColourAllowed(tile.getColourName())) continue;
>> >>
>> >> if (!orUIManager.tileUpgrades.contains(tile))
>> >> orUIManager.tileUpgrades.add(tile);
>> >> }
>> >>
>> >> then it seems that the private power works correctly.
>> >>
>> >> I'd send a patch, but I'm not convinced that UpgradesPanel is the
>> >> right
>> place to make this change and I'm also not sure that the bug isn't some
>> artifact of me misconfiguring Eclipse.
>> >>
>> >> Thanks,
>> >> Bill Rosgen
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> --------- Special Offer-- Download ArcSight Logger for FREE (a $49
>> >> USD value)!
>> >> Finally, a world-class log management solution at an even better
>> >> price-
>> free!
>> >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> >> February 28th, so secure your free ArcSight Logger TODAY!
>> >> http://p.sf.net/sfu/arcsight-sfd2d
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >>
>> >
>> > ----------------------------------------------------------------------
>> > -------- Special Offer-- Download ArcSight Logger for FREE (a $49 USD
>> > value)!
>> > Finally, a world-class log management solution at an even better
> price-free!
>> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> > February 28th, so secure your free ArcSight Logger TODAY!
>> > http://p.sf.net/sfu/arcsight-sfd2d
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better
> price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical
> server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Erik V. <eri...@xs...> - 2011-02-10 23:07:35
|
Ah, the ConcurrentModificationException: an old friend.... That occurs when
a List is modified while it is being iterated.
I'll look at it a.s.a.p.
Erik.
> -----Oorspronkelijk bericht-----
> Van: Phil Davies [mailto:de...@gm...]
> Verzonden: donderdag 10 februari 2011 16:24
> Aan: Development list for Rails: an 18xx game
> Onderwerp: Re: [Rails-devel] 1889 Regression: private B and laying the
port
> tile?
>
> Erik,
>
> I think something is going funny with the tile laying code in games where
you
> can lay multiple tiles in a turn. Try loading up the attached saved game
and
> try and lay a yellow tile somewhere, you get the following error noted
below.
> I spotted this trying to do some work on 1825 but it's present in 1851, I
> haven't tried 1835 yet but I imagine it might have the same situation.
Seems
> to be a failure around decreasing the number of allowed tile lays for the
> company.
>
>
> Exception in thread "AWT-EventQueue-0"
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
> at java.util.HashMap$KeyIterator.next(Unknown Source)
> at java.util.Collections$UnmodifiableCollection$1.next(Unknown
> Source)
> at
> rails.game.OperatingRound.updateAllowedTileColours(OperatingRound.java
> :476)
> at
> rails.game.OperatingRound.checkNormalTileLay(OperatingRound.java:458)
> at
> rails.game.OperatingRound.registerNormalTileLay(OperatingRound.java:445)
> at rails.game.OperatingRound.layTile(OperatingRound.java:429)
> at rails.game.OperatingRound.process(OperatingRound.java:192)
> at rails.game.GameManager.process(GameManager.java:824)
> at
> rails.ui.swing.GameUIManager.processOnServer(GameUIManager.java:239)
> at rails.ui.swing.ORWindow.process(ORWindow.java:154)
> at rails.ui.swing.ORUIManager.layTile(ORUIManager.java:796)
> at
> rails.ui.swing.ORUIManager.executeUpgrade(ORUIManager.java:1328)
> at
> rails.ui.swing.UpgradesPanel.actionPerformed(UpgradesPanel.java:399)
> at javax.swing.AbstractButton.fireActionPerformed(Unknown
> Source)
> at javax.swing.AbstractButton$Handler.actionPerformed(Unknown
> Source)
> at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown
> Source)
> at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
> at
> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown
> Source)
> at java.awt.Component.processMouseEvent(Unknown Source)
> at javax.swing.JComponent.processMouseEvent(Unknown Source)
> at java.awt.Component.processEvent(Unknown Source)
> at java.awt.Container.processEvent(Unknown Source)
> at java.awt.Component.dispatchEventImpl(Unknown Source)
> at java.awt.Container.dispatchEventImpl(Unknown Source)
> at java.awt.Component.dispatchEvent(Unknown Source)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown
> Source)
> at java.awt.LightweightDispatcher.processMouseEvent(Unknown
> Source)
> at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
> at java.awt.Container.dispatchEventImpl(Unknown Source)
> at java.awt.Window.dispatchEventImpl(Unknown Source)
> at java.awt.Component.dispatchEvent(Unknown Source)
> at java.awt.EventQueue.dispatchEvent(Unknown Source)
> at
> java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
> at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown
> Source)
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
> at java.awt.EventDispatchThread.run(Unknown Source)
>
>
>
>
> On 4 February 2011 18:42, Erik Vos <eri...@xs...> wrote:
> > Fixed bug #3165621: 1889 port token could not be laid.
> > Tile laying code has been generally cleaned up and simplified. Some
> > other
> > (unrelated) minor bugs have been found and fixed.
> > Cases where both a regular and a special property-originating tile can
> > be laid on the same hex now work correctly (such as in 1899 hex G10 in
> > the saved file provided with the above bug).
> >
> > Please let me know if any unwanted change in behaviour of tile laying
> > processes are found. I have done quite some testing (and found some
> > more bugs in that process, still to fix), but it's not really possible
> > to check for all potential side effects of changing such old code.
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: Bill Rosgen [mailto:ro...@gm...]
> >> Verzonden: dinsdag 25 januari 2011 11:42
> >> Aan: Development list for Rails: an 18xx game
> >> Onderwerp: Re: [Rails-devel] 1889 Regression: private B and laying
> >> the
> > port
> >> tile?
> >>
> >> Hi Phil,
> >>
> >> I encounter this error when playing a new game created in the trunk
> code.
> > If
> >> it works for others, it's probably some sort of misconfiguration on
> >> my
> > end.
> >> As far as I can tell I have the latest version of the source, but I'm
> >> not
> > very
> >> familiar with Eclipse.
> >>
> >> Bill
> >>
> >> On 2011-01-25, at 18:23 , Phil Davies wrote:
> >>
> >> > Bill,
> >> >
> >> > I've just checked this against the trunk code checked out today and
> >> > I don't have this problem.
> >> >
> >> > Are you using a saved game made with 1.4? There has been a change
> >> > to the tile manifest to 1889 (tile 440 was broken) so it's likely
> >> > that your saved game won't work with the trunk code because of this
> change.
> >> > Starting a new game from scratch and using B's power worked okay
> >> > for me.
> >> >
> >> > Phil
> >> >
> >> >
> >> > On 25 January 2011 09:57, Bill Rosgen <ro...@gm...> wrote:
> >> >> Hello,
> >> >>
> >> >> Hopefully this is the right place to post this. I've recently
> >> >> checked
> > the
> >> source out of svn and have been playing around with rails (so that I
> >> can
> > play
> >> 18EU on my laptop with small screen). When playing 1889 I run into a
> >> problem that the owner of private B cannot lay the port tile, but
> >> only if
> > I use
> >> the code I've checked out of svn -- version 1.4 works correctly.
> >> >>
> >> >> Specifically, when the user clicks on a map space where he can lay
> >> >> the
> >> port tile there's a NullPointerException thrown from line 106 of
> >> UpgradesPanel.populate(). It looks like the call to
> > layTile.getTileColours()
> >> returns a null pointer for at least one of the tiles in the list (I
> >> assume
> > it's the
> >> port tile, since it's a special tile, so the constructed of LayTile
> >> is
> > called for the
> >> SPECIAL_PROPERTY case where LayTile.tileColours does not get set.
> >> >>
> >> >> I have a savegame that can be used as a test-case, but I encounter
> >> >> this
> >> problem literally anytime the owner of private B attempts to lay the
> >> port
> > tile
> >> (which can be as early as the first tile lay), so I'm not sure it's
> >> worth
> > sending
> >> out.
> >> >>
> >> >> I am able to get around the problem my testing that
> >> layTile.getTileColours() returns non-null, but as I'm not familiar
> >> with
> > the code,
> >> I'm not sure if that will break anything else. Specifically, if I
> >> change
> > lines 104-
> >> 115 of UpgradesPanel.populate() to the following:
> >> >>
> >> >> for (TileI tile : tiles) {
> >> >> // Skip if not allowed in LayTile
> >> >> if (layTile.getTileColours() != null &&
> >> >> layTile.getTileColours().get(tile.getColourName()) < 1) continue;
> >> >>
> >> >> // special check: does the tile increase the
> >> >> colour
> > number?
> >> >> // this avoids that a special tile lay down or
> > equalgrades existing
> >> tiles
> >> >> // TODO EV: I'm not sure if this is a necessary
> > precaution.
> >> >> if (layTile.getTileColours() != null &&
> >> >> !layTile.isTileColourAllowed(tile.getColourName())) continue;
> >> >>
> >> >> if (!orUIManager.tileUpgrades.contains(tile))
> >> >> orUIManager.tileUpgrades.add(tile);
> >> >> }
> >> >>
> >> >> then it seems that the private power works correctly.
> >> >>
> >> >> I'd send a patch, but I'm not convinced that UpgradesPanel is the
> >> >> right
> >> place to make this change and I'm also not sure that the bug isn't
> >> some artifact of me misconfiguring Eclipse.
> >> >>
> >> >> Thanks,
> >> >> Bill Rosgen
> >> >>
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> ---
> >> >> --------- Special Offer-- Download ArcSight Logger for FREE (a $49
> >> >> USD value)!
> >> >> Finally, a world-class log management solution at an even better
> >> >> price-
> >> free!
> >> >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> >> >> February 28th, so secure your free ArcSight Logger TODAY!
> >> >> http://p.sf.net/sfu/arcsight-sfd2d
> >> >> _______________________________________________
> >> >> Rails-devel mailing list
> >> >> Rai...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> >>
> >> >
> >> > -------------------------------------------------------------------
> >> > ---
> >> > -------- Special Offer-- Download ArcSight Logger for FREE (a $49
> >> > USD value)!
> >> > Finally, a world-class log management solution at an even better
> > price-free!
> >> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> >> > February 28th, so secure your free ArcSight Logger TODAY!
> >> > http://p.sf.net/sfu/arcsight-sfd2d
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> >>
> > ----------------------------------------------------------------------
> > ------
> > --
> >> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> >> Finally, a world-class log management solution at an even better
> > price-free!
> >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> >> February 28th, so secure your free ArcSight Logger TODAY!
> >> http://p.sf.net/sfu/arcsight-sfd2d
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- The modern datacenter depends on network connectivity to
> > access resources and provide services. The best practices for
> > maximizing a physical server's connectivity to a physical network are
> > well understood - see how these rules translate into the virtual
> > world?
> > http://p.sf.net/sfu/oracle-sfdevnlfb
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
|
|
From: Erik V. <eri...@xs...> - 2011-01-25 21:22:19
|
Hi Bill,
Please send me that saved file (or even better: enter a bug in Sourceforge
and attach it there).
Having a real test case always helps.
I think I can understand why this happens: tile colours do not seem to be
initialised if a special property is used to lay a tile.
And I agree that this bug can better be fixed at its source than at its
manifestation point.
Erik.
> -----Oorspronkelijk bericht-----
> Van: Bill Rosgen [mailto:ro...@gm...]
> Verzonden: dinsdag 25 januari 2011 10:58
> Aan: rai...@li...
> Onderwerp: [Rails-devel] 1889 Regression: private B and laying the port
tile?
>
> Hello,
>
> Hopefully this is the right place to post this. I've recently checked the
source
> out of svn and have been playing around with rails (so that I can play
18EU on
> my laptop with small screen). When playing 1889 I run into a problem that
> the owner of private B cannot lay the port tile, but only if I use the
code I've
> checked out of svn -- version 1.4 works correctly.
>
> Specifically, when the user clicks on a map space where he can lay the
port
> tile there's a NullPointerException thrown from line 106 of
> UpgradesPanel.populate(). It looks like the call to
layTile.getTileColours()
> returns a null pointer for at least one of the tiles in the list (I assume
it's the
> port tile, since it's a special tile, so the constructed of LayTile is
called for the
> SPECIAL_PROPERTY case where LayTile.tileColours does not get set.
>
> I have a savegame that can be used as a test-case, but I encounter this
> problem literally anytime the owner of private B attempts to lay the port
tile
> (which can be as early as the first tile lay), so I'm not sure it's worth
sending
> out.
>
> I am able to get around the problem my testing that
layTile.getTileColours()
> returns non-null, but as I'm not familiar with the code, I'm not sure if
that will
> break anything else. Specifically, if I change lines 104-115 of
> UpgradesPanel.populate() to the following:
>
> for (TileI tile : tiles) {
> // Skip if not allowed in LayTile
> if (layTile.getTileColours() != null &&
> layTile.getTileColours().get(tile.getColourName()) < 1) continue;
>
> // special check: does the tile increase the colour
number?
> // this avoids that a special tile lay down or
equalgrades existing
> tiles
> // TODO EV: I'm not sure if this is a necessary
precaution.
> if (layTile.getTileColours() != null &&
> !layTile.isTileColourAllowed(tile.getColourName())) continue;
>
> if (!orUIManager.tileUpgrades.contains(tile))
> orUIManager.tileUpgrades.add(tile);
> }
>
> then it seems that the private power works correctly.
>
> I'd send a patch, but I'm not convinced that UpgradesPanel is the right
place
> to make this change and I'm also not sure that the bug isn't some artifact
of
> me misconfiguring Eclipse.
>
> Thanks,
> Bill Rosgen
>
>
>
----------------------------------------------------------------------------
--
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Erik V. <eri...@xs...> - 2011-02-11 22:56:07
|
Fixed. > It worked fine on my machine. I did: Indeed. The error was probably introduced by one of my most recent changes. Erik. |
|
From: Phil D. <de...@gm...> - 2011-02-14 11:01:55
|
Cool, thanks Erik On 11 February 2011 22:56, Erik Vos <eri...@xs...> wrote: > Fixed. > >> It worked fine on my machine. I did: > > Indeed. The error was probably introduced by one of my most recent changes. > > Erik. > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X