I’ve implemented versioning for the image cache, but I haven’t found a way
to test it yet because I can’t figure out how to use GamePieceImages. I’ve
tried this in 3.0.17 to get a baseline for how it’s supposed to work, but I
can’t make it go. Did this work in 3.0.17?
After creating a GamePieceLayout and a child GamePieceImage, how do I
use that in a piece face?
There’s a repaint problem with the GamePieceLayout properties dialog.
You can see this whenever you click one of the buttons in the section
below the visualizer. It looks like the parent container isn’t being
repainted when its children change.
This works fine for me. If I create a child GamePieceImage and name it piece2.png, then close the GamePieceImage, then go to a BasicPiece and click the drop-down list, I now get piece2.png as one of the options.
The place where things are supposed to be happening is GamePieceImage.rebuildVisualizerImage(). This is called everytime something changes in one of the item instances that requires the image to be regenerated.
The code in there is much changed from my original and now is just not doing the do.
Another issue is that the GamePieceImages must NOT be regenerated at any time except when specifically edited and one of the image options is changed. At the moment, the GamePieceImages are all being regenerated whenever the module is opened for editing (which is bad) or for playing (which is really, really bad).
Joel, If you can fix the image handling in GamePieceImage.rebuildVisualizerImage(), I can look into the rebuilding issue. It is happening as a side effect of the Build of the GamePieceImage components. The creation of the images is tied to the initialisation of the Visualizer. The initialization of the Visualizer needs to be lazier.
Another side effect of this is that an image is also being created by the visualizer for the Layout that should never be saved into the module.
Yes, that works, but I thought that it did more than just add entries
to the drop-down list. Surely we could do that with a much simpler
“Drop-Down List Adder” component which doesn’t bother to do all of the
image layout stuff.
Here’s what I’m doing in 3.0.17.
Create a new module.
Under Game Piece Layouts, add a Game Piece Layout.
Add a Symbol, and close the dialog.
Add a Game Piece Image under the Game Piece Layout.
Name it “foo”, and close the dialog.
Add a single piece to the piece palette.
Under the properties for the Basic Piece trait, I see “foo” in the
list, but I never get any image from selecting it.
Saving the module and opening it for play makes no different. I see the
image in the Game Piece Image, but never on the piece I defined with it.
Er? I’m not talking about a problem with the visualizer, I’m talking about
a problem with the whole dialog. It looks like some components are being
reparented without their parent being redrawn, or something.
It was broken under 3.0.17 for other reasons. You and/or Rodney broke it more when you converted it to use ImageOp so not it is double broken.
Yes, but the Visualized is broke in 3.0.17 so it you can’t see what is happening. It doesn’t make sense.
Try changing the symbol to another setting and change the color. It does work sort of.
There are multiple problems:
The Visualizer is not rebuilt to show the new image when you change any of the parameters within a definition (e.g. changing a symbol from Infantry to Armor).
The new image (i.e. one with an armor symbol instead of an infantry symbol) is not written to the archive when you make a change.
The image is recreated when the user opens the module, which is wrong because it may reference fonts he does not have. The image MUST be created (and only created) on the module designers machine at the time he changes the definition (e.g. changing a symbol from infantry to armor). At this time, a number of things need to happen:
a) The Visualizer is updated to show the new image to the designer.
b) The new image is added to the archive.
c) Any existing versions of that image in the image cache need to be cleared.
My feeling is you are we are trying to over-engineer a solution to this. The image only changes in Edit Mode when one of the parameters changes. At that point we create a new image, add it to the DataArchive and uncache/remove the old image from the cache. Once in the Archive, the image can be referenced with a simple SourceOp.
Brent, I think we’re not talking about the same thing here. What I’m
talking about is in this picture.
This is what the dialog looks like after I hit the “Symbol” button. There’s
a strip along the right edge and another below the buttons at the bottom
which fail to repaint. There’s something wrong with the way that the
components are being changed as as a result of hitting that button.
Very Strange. I have not seen this in either 3.0.17 or 3.1 and have never had it reported to me by any of the people using GPI’s. There is nothing strage about the dialog, it is just a series of nested components, added in the standard way. The dialog is repacked each time an item is changed on the lower part of the dialog. Java on linux appears to be behaving differently to Windows???
I have a working setup now by which you can expire an Op by advancing its
This was delayed by several days because I found another deadlock problem
like the one revealed by the Panzer Commander module, in which a request
ends up in the queue behind a request which depends on it. I thought I’d
covered all of the ways that can happen, but I discovered when running
your TDC module with a purposely insufficient max heap that you can still
get this situation if the result of a request is garbage collected between
when it finishes and when its parent request gets a reference to it. This
required me to rethink how I was queuing requests, and tonight I found a
stupid simple solution to the problem: If you’re a running request and you
find that you depend on another request which is still queued, take it out
of the queue and run it yourself. Duh.
Anyway, I’ll have this all committed to the trunk by tomorrow evening,
so if you can get GamePieceImage to the point where it would work if you
could update a SourceOp by calling update() on it after writing a new image
to the ArchiveWriter, then we’ll have it working again.
Ok, sounds good. Once you have that working, I will take over and review and update the whole Game Piece Images code. It’s had too many people hacking at it (with good intent!) and is in need of an overhaul.
Thanks for the answers. I now see where my problems where coming from, I set out the text box size imagining that the text would be placed in the box using the top right corner as a start. It wasn’t , so I had to massively enlarge the boxes, and use the htm center command to put the text in the middle of the box. A bit of a nightmare, it took some 40 attempts to put all text boxes in place.
Second problem though, I’m using red background , and wanted white text. The text is white, thought it shows some kind of a black ‘ghost’ outline taht makes it immensely difficult to read… Alias or anti-alias do not seem to matter… any tips?
Third problem, there are plenty NATO symbols missing from the library.
It’s there in trunk@4136 and later. Calling ImageOp.update() expires the
cache key associated with that ImageOp. Right now, the sole use of it is
in ArchiveWriter.addImage(), to handle the case in which an image is added
but then the contents of the file change, after which the image is added