rails-devel — List for discussion of Rails development

RE: [Rails-devel] UI Updates

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

>>> Argh. I really gotta stop using Java 1.5 on my systems. I 
>>> apologize for that.
>>> 
>>> What do you mean by the tiles being clipped?

>>That the borders are not visible, only the center part.
>>Or is that specific to me?
>>I can't believe that *that* is caused by Java version
>>differences, but you never know....

>Ahh... I'm pretty sure I know what that is.

>In the paint() method for each GUIHex, you'll notice a call to g2.setClip(hexagon)

>This sets the clipping boundary for each hex to be the size and dimensions 
>of the hexagon. This is probably cutting out the borders on the hexes.

>However, the reason we need to setClip() is because otherwise the 
>clickable area for each hexagon would be a bunch of overlapping 
>rectangles that cause problems for detecting which hex a click triggers.


Actually, I've found a better way of doing things.

In GUIHex, there's still the PaintOverlay code from Colossus.

This seems to work a lot better than my rather hackish image loading code.  

It currently only works under the NS hex orientation.

If I can get the rotation math correct I'll have it working for all hexes shortly.

---Brett.

RE: [Rails-devel] UI Updates

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

>I had lots of problems to get scrolling right in the Log window.
>Now it is a JFrame containing a JPanel containing a JScrollPane
>(which contains the JLabel which contains all the text).


The alternative is to have the JLabel which contains the text implement the Scrollable interface, which is what I did with HexMap.

RE: [Rails-devel] UI Updates

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

>> Nope, we don't have this problem anywhere else. It's 
>> specifically HexMap that's the problem.

>I had lots of problems to get scrolling right in the Log window.
>Now it is a JFrame containing a JPanel containing a JScrollPane
>(which contains the JLabel which contains all the text).

>Map Window is a JFrame containing a ScrollPane containing a JPanel
>(HexMap, which contains all the small JPanels representing tiles).

>I don't claim anything, I just wonder if adding a JPanel (as in LogWindow)
>would help (so we would get JFrame/JPanel/JScrollPane/HexMap).


I actually had that same idea at one point, but it didn't work.

After a little more reading, it seems like the difference between 'heavyweight' and 'lightweight' objects is how they tie into the windowing system.  AWT seems to do more things directly with the native windowing system whereas Swing doesn't hook as deeply into the native windowing system.

This is what makes Swing objects look significantly better and take up less resources regardless of the platform the code is running on.

I'm not really sure what is causing HexMap to be considered 'heavyweight'. As far as I can tell, it's comprised of only lightweight objects.


>> Argh. I really gotta stop using Java 1.5 on my systems. I 
>> apologize for that.
>> 
>> What do you mean by the tiles being clipped?

>That the borders are not visible, only the center part.
>Or is that specific to me?
>I can't believe that *that* is caused by Java version
>differences, but you never know....

Ahh... I'm pretty sure I know what that is.

In the paint() method for each GUIHex, you'll notice a call to g2.setClip(hexagon)

This sets the clipping boundary for each hex to be the size and dimensions of the hexagon. This is probably cutting out the borders on the hexes.

However, the reason we need to setClip() is because otherwise the clickable area for each hexagon would be a bunch of overlapping rectangles that cause problems for detecting which hex a click triggers.


---Brett.

RE: [Rails-devel] UI Updates

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

> Nope, we don't have this problem anywhere else. It's 
> specifically HexMap that's the problem.

I had lots of problems to get scrolling right in the Log window.
Now it is a JFrame containing a JPanel containing a JScrollPane
(which contains the JLabel which contains all the text).

Map Window is a JFrame containing a ScrollPane containing a JPanel
(HexMap, which contains all the small JPanels representing tiles).

I don't claim anything, I just wonder if adding a JPanel (as in LogWindow)
would help (so we would get JFrame/JPanel/JScrollPane/HexMap).

> Argh. I really gotta stop using Java 1.5 on my systems. I 
> apologize for that.
> 
> What do you mean by the tiles being clipped?

That the borders are not visible, only the center part.
Or is that specific to me?
I can't believe that *that* is caused by Java version
differences, but you never know....

Erik.

RE: [Rails-devel] UI Updates

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

Nope, we don't have this problem anywhere else. It's specifically HexMap that's the problem.

Argh. I really gotta stop using Java 1.5 on my systems. I apologize for that.

What do you mean by the tiles being clipped?

---Brett.


-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Sep 28, 2005 2:08 PM
To: rai...@li...
Subject: RE: [Rails-devel] UI Updates

Strange, we don't have this problem in the other windows, do we?

Unfortunately, setPreferredSize() does not compile with Java 1.4,
because JFrame and ScrollPane are not JComponents. 
I have outcommented these lines for now. 
I have wrestled with sizes in the other windows too,
when I've more time I will have another look.

Another thing to do is to better scale the map (now the tiles are clipped)
and move it against the upper and left borders.

Erik.


> I've gotten ScrollBars on the Map window to work without drawing bugs.
> 
> Here's the scoop on this badboy:
> 
> For some reason that I haven't yet pinned down, HexMap is 
> considered a HeavyWeight component. Most Swing objects 
> (JPanel, JLabel, etc) are considered LightWeight components.
> 
> So, when using JScrollPane with HexMap, the map hexes kept 
> being drawn on top of the scroll bars.
> 
> The reason being that HeavyWeight components are ALWAYS drawn 
> on top of LightWeight components, regardless of Z-ordering.  
> This has a bunch of legacy reasoning from back when Sun made 
> the transition from AWT to Swing.
> 
> This is why mixing lightweight and heavyweight components is 
> not recommended.
> 
> SO, the solution was to use AWT's ScrollPane rather than 
> Swing's JScrollPane. ScrollPane is a heavyweight component 
> because all of AWT's components are heavyweight components.
> 
> Unfortunately, as you'll see if you examine MapWindow, this 
> causes problems for MouseListeners. Swing objects will 
> automatically pass events up to their parent objects. AWT 
> objects won't. So, the MouseListener needs to be explicitly 
> added to all levels of the hierarchy in order to function, as 
> it is currently being done in MapWindow.
> 
> For the future:  If we can figure out how to make HexMap a 
> lightweight component, I'd really like to do that. There are 
> a lot of good things we gain if we can do it. 
> 
> For now, if you see any drawing weirdness with the MapWindow, 
> this is the likely source. Be careful how you layer AWT and 
> Swing objects.
> 
> 
> ---Brett.
> 
> 
> 
> -----Original Message-----
> From: Brett Lentz <wak...@ea...>
> Sent: Sep 27, 2005 3:19 PM
> To: rai...@li...
> Subject: [Rails-devel] UI Updates
> 
> I've just committed some UI reorganization and minor cleanups.
> 
> Here's a rough list of what's changed:
> 
> 1. We no longer draw every single window when a game starts. 
> The StatusWindow opens, and if it's the beginning of a 
> startRound, the StartRoundWindow opens.  That's it.
> 
> The Stock Market chart is only setVisible during stock 
> rounds, and the Map is only setVisible during Operating Rounds.
> 
> 2. I've added a series of drop-down menus to the Status 
> Window. This includes an Options menu where you can open any 
> of the other windows as you see fit.
> 
> 3. I've added Mnemonics to all existing buttons, so now they 
> can be accessed via ALT+key combinations if so desired.
> 
> 
> I'm still working on getting the MapWindow to correctly use 
> ScrollBars. Hopefully that'll be working fairly soon.
> 
> ---Brett.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, 
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, 
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] UI Updates

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

Strange, we don't have this problem in the other windows, do we?

Unfortunately, setPreferredSize() does not compile with Java 1.4,
because JFrame and ScrollPane are not JComponents. 
I have outcommented these lines for now. 
I have wrestled with sizes in the other windows too,
when I've more time I will have another look.

Another thing to do is to better scale the map (now the tiles are clipped)
and move it against the upper and left borders.

Erik.


> I've gotten ScrollBars on the Map window to work without drawing bugs.
> 
> Here's the scoop on this badboy:
> 
> For some reason that I haven't yet pinned down, HexMap is 
> considered a HeavyWeight component. Most Swing objects 
> (JPanel, JLabel, etc) are considered LightWeight components.
> 
> So, when using JScrollPane with HexMap, the map hexes kept 
> being drawn on top of the scroll bars.
> 
> The reason being that HeavyWeight components are ALWAYS drawn 
> on top of LightWeight components, regardless of Z-ordering.  
> This has a bunch of legacy reasoning from back when Sun made 
> the transition from AWT to Swing.
> 
> This is why mixing lightweight and heavyweight components is 
> not recommended.
> 
> SO, the solution was to use AWT's ScrollPane rather than 
> Swing's JScrollPane. ScrollPane is a heavyweight component 
> because all of AWT's components are heavyweight components.
> 
> Unfortunately, as you'll see if you examine MapWindow, this 
> causes problems for MouseListeners. Swing objects will 
> automatically pass events up to their parent objects. AWT 
> objects won't. So, the MouseListener needs to be explicitly 
> added to all levels of the hierarchy in order to function, as 
> it is currently being done in MapWindow.
> 
> For the future:  If we can figure out how to make HexMap a 
> lightweight component, I'd really like to do that. There are 
> a lot of good things we gain if we can do it. 
> 
> For now, if you see any drawing weirdness with the MapWindow, 
> this is the likely source. Be careful how you layer AWT and 
> Swing objects.
> 
> 
> ---Brett.
> 
> 
> 
> -----Original Message-----
> From: Brett Lentz <wak...@ea...>
> Sent: Sep 27, 2005 3:19 PM
> To: rai...@li...
> Subject: [Rails-devel] UI Updates
> 
> I've just committed some UI reorganization and minor cleanups.
> 
> Here's a rough list of what's changed:
> 
> 1. We no longer draw every single window when a game starts. 
> The StatusWindow opens, and if it's the beginning of a 
> startRound, the StartRoundWindow opens.  That's it.
> 
> The Stock Market chart is only setVisible during stock 
> rounds, and the Map is only setVisible during Operating Rounds.
> 
> 2. I've added a series of drop-down menus to the Status 
> Window. This includes an Options menu where you can open any 
> of the other windows as you see fit.
> 
> 3. I've added Mnemonics to all existing buttons, so now they 
> can be accessed via ALT+key combinations if so desired.
> 
> 
> I'm still working on getting the MapWindow to correctly use 
> ScrollBars. Hopefully that'll be working fairly soon.
> 
> ---Brett.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, 
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, 
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

Re: [Rails-devel] UI Updates

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

I've gotten ScrollBars on the Map window to work without drawing bugs.

Here's the scoop on this badboy:

For some reason that I haven't yet pinned down, HexMap is considered a HeavyWeight component. Most Swing objects (JPanel, JLabel, etc) are considered LightWeight components.

So, when using JScrollPane with HexMap, the map hexes kept being drawn on top of the scroll bars.

The reason being that HeavyWeight components are ALWAYS drawn on top of LightWeight components, regardless of Z-ordering.  This has a bunch of legacy reasoning from back when Sun made the transition from AWT to Swing.

This is why mixing lightweight and heavyweight components is not recommended.

SO, the solution was to use AWT's ScrollPane rather than Swing's JScrollPane. ScrollPane is a heavyweight component because all of AWT's components are heavyweight components.

Unfortunately, as you'll see if you examine MapWindow, this causes problems for MouseListeners. Swing objects will automatically pass events up to their parent objects. AWT objects won't. So, the MouseListener needs to be explicitly added to all levels of the hierarchy in order to function, as it is currently being done in MapWindow.

For the future:  If we can figure out how to make HexMap a lightweight component, I'd really like to do that. There are a lot of good things we gain if we can do it. 

For now, if you see any drawing weirdness with the MapWindow, this is the likely source. Be careful how you layer AWT and Swing objects.


---Brett.



-----Original Message-----
From: Brett Lentz <wak...@ea...>
Sent: Sep 27, 2005 3:19 PM
To: rai...@li...
Subject: [Rails-devel] UI Updates

I've just committed some UI reorganization and minor cleanups.

Here's a rough list of what's changed:

1. We no longer draw every single window when a game starts. The StatusWindow opens, and if it's the beginning of a startRound, the StartRoundWindow opens.  That's it.

The Stock Market chart is only setVisible during stock rounds, and the Map is only setVisible during Operating Rounds.

2. I've added a series of drop-down menus to the Status Window. This includes an Options menu where you can open any of the other windows as you see fit.

3. I've added Mnemonics to all existing buttons, so now they can be accessed via ALT+key combinations if so desired.


I'm still working on getting the MapWindow to correctly use ScrollBars. Hopefully that'll be working fairly soon.

---Brett.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] UI Updates

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

I've just committed some UI reorganization and minor cleanups.

Here's a rough list of what's changed:

1. We no longer draw every single window when a game starts. The StatusWindow opens, and if it's the beginning of a startRound, the StartRoundWindow opens.  That's it.

The Stock Market chart is only setVisible during stock rounds, and the Map is only setVisible during Operating Rounds.

2. I've added a series of drop-down menus to the Status Window. This includes an Options menu where you can open any of the other windows as you see fit.

3. I've added Mnemonics to all existing buttons, so now they can be accessed via ALT+key combinations if so desired.


I'm still working on getting the MapWindow to correctly use ScrollBars. Hopefully that'll be working fairly soon.

---Brett.

RE: [Rails-devel] Map status

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

>> > I don't know if you find this idea worth further pursueing,
>> > but if so, I must say that there seems to be much more to 
>> > mouse handling than meets the eye.....
>> 
>> 
>> It's an interesting idea.  I'm not sure how useful it will be 
>> to anyone other than us developers. 

>I think it will, if we tailor the info presented for that purpose.
>As it is now, the tiles are rather small, and any info on the tile
>(revenue, location) has become unreadable.
>So I believe a tooltip will be a requirement.

>Info to be presented could include:
>Hex: City name (if applicable), any relevant properties.
>Hex location name is also very useful for PB(E)Mmers.
>Tile: Number, revenue, perhaps any valid upgrades.
 

I think this is probably a good thing to do in addition to adding the ability to manually adjust the map's scale to better fit the user's screen.

Re: [Rails-devel] First Diesel exchange

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

Huzzah!

---Brett.

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Sep 25, 2005 1:08 PM
To: rai...@li...
Subject: [Rails-devel] First Diesel exchange

Companies can now execute the low-price First Diesel exchange.

Erik.

[Rails-devel] First Diesel exchange

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

Companies can now execute the low-price First Diesel exchange.

Erik.

RE: [Rails-devel] Map status

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

> > I don't know if you find this idea worth further pursueing,
> > but if so, I must say that there seems to be much more to 
> > mouse handling than meets the eye.....
> 
> 
> It's an interesting idea.  I'm not sure how useful it will be 
> to anyone other than us developers. 

I think it will, if we tailor the info presented for that purpose.
As it is now, the tiles are rather small, and any info on the tile
(revenue, location) has become unreadable.
So I believe a tooltip will be a requirement.

Info to be presented could include:
Hex: City name (if applicable), any relevant properties.
Hex location name is also very useful for PB(E)Mmers.
Tile: Number, revenue, perhaps any valid upgrades.
 
> One other way to try it is to change Mouse*Listener to Action 
> Listener and combine the rotation code with the tooltip code 
> into a single ActionEvent.

Sounds good.

> I think the other thing you'll have to do is adjust the 
> Paint() and/or Repaint() methods to redraw the area under the 
> mouse. Rather than drawing the whole map again, you could 
> getRectClip() (a rectangular clipping area) and only repaint 
> the hexes included in the clipping area.
> 
> I agree with you, there's a lot more to Java's GUI system 
> than meets the eye. 
> 
> 
> ---Brett.

Erik.

RE: [Rails-devel] Map status

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

> I don't know if you find this idea worth further pursueing,
> but if so, I must say that there seems to be much more to 
> mouse handling than meets the eye.....


It's an interesting idea.  I'm not sure how useful it will be to anyone other than us developers. 

One other way to try it is to change Mouse*Listener to Action Listener and combine the rotation code with the tooltip code into a single ActionEvent.

I think the other thing you'll have to do is adjust the Paint() and/or Repaint() methods to redraw the area under the mouse. Rather than drawing the whole map again, you could getRectClip() (a rectangular clipping area) and only repaint the hexes included in the clipping area.

I agree with you, there's a lot more to Java's GUI system than meets the eye. 


---Brett.

RE: [Rails-devel] Map status

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

Thanks for the new tile images. 18AL is now OK.

> There are a few different ways, the easiest being just to 
> comment out the g2.drawImage() call in the 
> orientation-specific GUIHex.Paint() method.
> 
> One idea I have been batting around is to change HexMap from 
> extending JPanel to extending JLayeredPane so that when we 
> draw the hexes, we can choose which is drawn on top.

I tried a different approach: enabling ToolTips,
to display Hex and current Tile properties when the cursor
hovers above a tile (or if the tile is clicked once).

First I tried these on the GUIHex classes (tiles),
but that doesn't work - mouse events never reach the tiles.
I suppose you have found that out before.

Then I tried to do it in HexMap, in two ways:

- by having HexMap implement MouseMotionListener,
and setting a tooltip in mouseMoved().
This does not work, and mouseClicked() also ceases to respond.

- by setting the tooltip in mouseClicked().
That does the job, but only once: additional mouse clicks
do nothing anymore (and the tooltip will display everywhere).

The latter situation is currently committed, so that you
can have a look if you want. Restore the old situation
by removing line 555 from HexMap.

I don't know if you find this idea worth further pursueing,
but if so, I must say that there seems to be much more to 
mouse handling than meets the eye.....

Erik.

RE: [Rails-devel] Map status

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

Yup.   We definitely will need to put it into documentation.

Perhaps after we do a first release we'll get a few more volunteers to help set stuff like that up. 

---Brett.

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Sep 24, 2005 2:32 PM
To: rai...@li...
Subject: RE: [Rails-devel] Map status

Yes, for us two it's OK.
But sometime someone not having the Java code handy
might want to create maps. 


> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> Brett Lentz
> Sent: 24 September 2005 19:47
> To: rai...@li...
> Subject: RE: [Rails-devel] Map status
> 
> Double check the base Hex class.  It's got a commented out 
> portion about how sides are numbered.
> 
> That way you don't have to remember, it's always there for reference. 
> 
> ---Brett.
> 
> 
> 
> 
> -----Original Message-----
> From: Erik Vos <eri...@hc...>
> Sent: Sep 24, 2005 5:23 AM
> To: rai...@li...
> Subject: RE: [Rails-devel] Map status
> 
> > > Yes, if the hex has such properties (like the preprinted 
> grey ones)
> > > or is on the border of the map, the impassability can be derived.
> > > I was referring to the cases were it cannot, such as the one
> > > I gave as an example. In those cases an extra specification 
> > is needed.
> > > No big deal.
> > 
> > 
> > I agree.  My point was, it's probably better to specify a 
> > hexside as impassible rather than a path from one hex to 
> > another.  The difference is semantic, but I think it's a vital one.
> > 
> > In terms of XML, the difference would be having this:
> > 
> > <hex A1>
> > <impassable sides="1,2,3">
> > </hex>
> > 
> > versus
> > 
> > <hex C1>
> > <impassable hex="D2">
> > </hex>
> > 
> > <hex D2>
> > <impassable hex="C1">
> > </hex>
> > 
> > 
> > That way, in the code, we make the calculation of "if your 
> > side X or your neighbor's corresponding side Y is impassible..."
> > 
> > We're going to need to be working with examining hexsides and 
> > neighbor hexes when we do route calculation anyway, so this 
> > would be a good first step building the foundation for that.
> > 
> > What do you think?
> 
> Your way is easier to parse and process, but less easy to configure,
> because Map.xml file builders need to remember which side is 
> 0 (or 1?),
> both for EW and NS hex maps. I'd rather not burden my memory
> with that tidbit (once we are done with programming maps, that is).
> 
> Taking such complications off the shoulders of fallible people
> is one thing that computers are very good at, once you have
> instructed them properly....
> 
> Of course, *internally* we would work with side numbers.
> 
> Erik.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App 
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App 
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] Map status

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

Yes, for us two it's OK.
But sometime someone not having the Java code handy
might want to create maps. 


> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf Of 
> Brett Lentz
> Sent: 24 September 2005 19:47
> To: rai...@li...
> Subject: RE: [Rails-devel] Map status
> 
> Double check the base Hex class.  It's got a commented out 
> portion about how sides are numbered.
> 
> That way you don't have to remember, it's always there for reference. 
> 
> ---Brett.
> 
> 
> 
> 
> -----Original Message-----
> From: Erik Vos <eri...@hc...>
> Sent: Sep 24, 2005 5:23 AM
> To: rai...@li...
> Subject: RE: [Rails-devel] Map status
> 
> > > Yes, if the hex has such properties (like the preprinted 
> grey ones)
> > > or is on the border of the map, the impassability can be derived.
> > > I was referring to the cases were it cannot, such as the one
> > > I gave as an example. In those cases an extra specification 
> > is needed.
> > > No big deal.
> > 
> > 
> > I agree.  My point was, it's probably better to specify a 
> > hexside as impassible rather than a path from one hex to 
> > another.  The difference is semantic, but I think it's a vital one.
> > 
> > In terms of XML, the difference would be having this:
> > 
> > <hex A1>
> > <impassable sides="1,2,3">
> > </hex>
> > 
> > versus
> > 
> > <hex C1>
> > <impassable hex="D2">
> > </hex>
> > 
> > <hex D2>
> > <impassable hex="C1">
> > </hex>
> > 
> > 
> > That way, in the code, we make the calculation of "if your 
> > side X or your neighbor's corresponding side Y is impassible..."
> > 
> > We're going to need to be working with examining hexsides and 
> > neighbor hexes when we do route calculation anyway, so this 
> > would be a good first step building the foundation for that.
> > 
> > What do you think?
> 
> Your way is easier to parse and process, but less easy to configure,
> because Map.xml file builders need to remember which side is 
> 0 (or 1?),
> both for EW and NS hex maps. I'd rather not burden my memory
> with that tidbit (once we are done with programming maps, that is).
> 
> Taking such complications off the shoulders of fallible people
> is one thing that computers are very good at, once you have
> instructed them properly....
> 
> Of course, *internally* we would work with side numbers.
> 
> Erik.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App 
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App 
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

RE: [Rails-devel] Map status

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

There are a few different ways, the easiest being just to comment out the g2.drawImage() call in the orientation-specific GUIHex.Paint() method.

One idea I have been batting around is to change HexMap from extending JPanel to extending JLayeredPane so that when we draw the hexes, we can choose which is drawn on top.

---Brett.

-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Sep 24, 2005 7:33 AM
To: rai...@li...
Subject: RE: [Rails-devel] Map status

Is there an easy way to suppress tile display,
so that the underlying map coordinates and
tile numbers show up again?

That would help me a lot to debug the 18AL map!

Erik.

RE: [Rails-devel] Map status

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

> Which brings up another issue: the map window needs to be resized
> so that it snugly fits around the map (perhaps cutting of part
> of the outer tiles).

There's two ways I'd like to solve this:

1. I've been working on adding scrollbars/scrollpanes to the map area, but I haven't gotten it quite right yet.
2. I'd like to eventually add a drop-down menu that includes the option of setting the scale.


---Brett.

RE: [Rails-devel] Map status

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

Double check the base Hex class.  It's got a commented out portion about how sides are numbered.

That way you don't have to remember, it's always there for reference. 

---Brett.




-----Original Message-----
From: Erik Vos <eri...@hc...>
Sent: Sep 24, 2005 5:23 AM
To: rai...@li...
Subject: RE: [Rails-devel] Map status

> > Yes, if the hex has such properties (like the preprinted grey ones)
> > or is on the border of the map, the impassability can be derived.
> > I was referring to the cases were it cannot, such as the one
> > I gave as an example. In those cases an extra specification 
> is needed.
> > No big deal.
> 
> 
> I agree.  My point was, it's probably better to specify a 
> hexside as impassible rather than a path from one hex to 
> another.  The difference is semantic, but I think it's a vital one.
> 
> In terms of XML, the difference would be having this:
> 
> <hex A1>
> <impassable sides="1,2,3">
> </hex>
> 
> versus
> 
> <hex C1>
> <impassable hex="D2">
> </hex>
> 
> <hex D2>
> <impassable hex="C1">
> </hex>
> 
> 
> That way, in the code, we make the calculation of "if your 
> side X or your neighbor's corresponding side Y is impassible..."
> 
> We're going to need to be working with examining hexsides and 
> neighbor hexes when we do route calculation anyway, so this 
> would be a good first step building the foundation for that.
> 
> What do you think?

Your way is easier to parse and process, but less easy to configure,
because Map.xml file builders need to remember which side is 0 (or 1?),
both for EW and NS hex maps. I'd rather not burden my memory
with that tidbit (once we are done with programming maps, that is).

Taking such complications off the shoulders of fallible people
is one thing that computers are very good at, once you have
instructed them properly....

Of course, *internally* we would work with side numbers.

Erik.





-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

RE: [Rails-devel] Map status

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

Is there an easy way to suppress tile display,
so that the underlying map coordinates and
tile numbers show up again?

That would help me a lot to debug the 18AL map!

Erik.

RE: [Rails-devel] Map status

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

> >> We could create full water hexes to spice things up a bit.
> >> But to create nice coastlines I think we should follow my earlier 
> >> suggestion to create a single image that represents the whole map 
> >> with all details, including the preprinted tiles. 
> >> We would still have the preprinted tiles as separate objects
> >> (the current situation), but not display them on top of the map.
> >> These objects would then only exist to define the possible 
> upgrades.
> 
> 
> >That might be viable for the long-term.  For now, I think 
> I'll cook up some tiles in the Gimp or TileDesigner.
> 
> >Do we have any preference on what they should be numbered?

Outside of the current number ranges please. 
I would propose -9001 etc.
 
> 
> On second thought, there's a lot of extra stuff here that I 
> wasn't accounting for.
> 
> I know there's some Alpha Compositing that can be done to 
> provide transparency/translucency.  
> 
> I think I'll need to give more thought to the problem before 
> we settle on a solution.  Thankfully, 1830 really doesn't 
> have much of this problem. :-)

for now I would suggest to settle for plain water (blue)
and land (dark green) tiles to fill up a rectangular space.

Which brings up another issue: the map window needs to be resized
so that it snugly fits around the map (perhaps cutting of part
of the outer tiles).


I have just committed the 1856 map with orientations.
This map does not display correctly here, probably due to the
missing -939 tile (Goderich), which I added to the Tile Dictionary
a while ago. I will send you my version of the TD by separate mail.

Erik.
 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App 
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

RE: [Rails-devel] Map status

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

> > Yes, if the hex has such properties (like the preprinted grey ones)
> > or is on the border of the map, the impassability can be derived.
> > I was referring to the cases were it cannot, such as the one
> > I gave as an example. In those cases an extra specification 
> is needed.
> > No big deal.
> 
> 
> I agree.  My point was, it's probably better to specify a 
> hexside as impassible rather than a path from one hex to 
> another.  The difference is semantic, but I think it's a vital one.
> 
> In terms of XML, the difference would be having this:
> 
> <hex A1>
> <impassable sides="1,2,3">
> </hex>
> 
> versus
> 
> <hex C1>
> <impassable hex="D2">
> </hex>
> 
> <hex D2>
> <impassable hex="C1">
> </hex>
> 
> 
> That way, in the code, we make the calculation of "if your 
> side X or your neighbor's corresponding side Y is impassible..."
> 
> We're going to need to be working with examining hexsides and 
> neighbor hexes when we do route calculation anyway, so this 
> would be a good first step building the foundation for that.
> 
> What do you think?

Your way is easier to parse and process, but less easy to configure,
because Map.xml file builders need to remember which side is 0 (or 1?),
both for EW and NS hex maps. I'd rather not burden my memory
with that tidbit (once we are done with programming maps, that is).

Taking such complications off the shoulders of fallible people
is one thing that computers are very good at, once you have
instructed them properly....

Of course, *internally* we would work with side numbers.

Erik.

RE: [Rails-devel] Map status

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

> Yes, if the hex has such properties (like the preprinted grey ones)
> or is on the border of the map, the impassability can be derived.
> I was referring to the cases were it cannot, such as the one
> I gave as an example. In those cases an extra specification is needed.
> No big deal.


I agree.  My point was, it's probably better to specify a hexside as impassible rather than a path from one hex to another.  The difference is semantic, but I think it's a vital one.

In terms of XML, the difference would be having this:

<hex A1>
<impassable sides="1,2,3">
</hex>

versus

<hex C1>
<impassable hex="D2">
</hex>

<hex D2>
<impassable hex="C1">
</hex>


That way, in the code, we make the calculation of "if your side X or your neighbor's corresponding side Y is impassible..."

We're going to need to be working with examining hexsides and neighbor hexes when we do route calculation anyway, so this would be a good first step building the foundation for that.

What do you think?

---Brett.

RE: [Rails-devel] Map status

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

>> We could create full water hexes to spice things up a bit.
>> But to create nice coastlines I think we should follow my earlier 
>> suggestion to create a single image that represents the whole map 
>> with all details, including the preprinted tiles. 
>> We would still have the preprinted tiles as separate objects
>> (the current situation), but not display them on top of the map.
>> These objects would then only exist to define the possible upgrades.


>That might be viable for the long-term.  For now, I think I'll cook up some tiles in the Gimp or TileDesigner.

>Do we have any preference on what they should be numbered?


On second thought, there's a lot of extra stuff here that I wasn't accounting for.

I know there's some Alpha Compositing that can be done to provide transparency/translucency.  

I think I'll need to give more thought to the problem before we settle on a solution.  Thankfully, 1830 really doesn't have much of this problem. :-)

RE: [Rails-devel] Map status

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

> > 4. A tag or attribute to define impassable hexsides where 
> upgradeable hexes
> > border each other (e.g. C11/D12 in 1830) should be added to Map.xml.
> > Perhaps a tag like 
> >   <Hex name="C11" ....>
> >      <NoGo name="D12"/>
> >   </Hex>
>  
> 
> The thing we need to be careful with here is that most hexes 
> only have one or two sides that are impassable. Other hexes, 
> like water, are completely impassable from all sides.
> 
> I think we should see if we can leverage the code related to 
> checking neighbor hexes that still exists from importing the 
> Colossus hex code.   It'll be much easier to do this if we 
> can easily check the neighbors of each hex and examine the 
> shared hexside for properties that mark it as impassable.
> 
> I think that it'll be easier to write code to check hexside 3 
> of hex A1 with hexside 5 of hex C3 for impassable=true on 
> either hexside.

Yes, if the hex has such properties (like the preprinted grey ones)
or is on the border of the map, the impassability can be derived.
I was referring to the cases were it cannot, such as the one
I gave as an example. In those cases an extra specification is needed.
No big deal.

Erik.