Bug Report for 1.2
Moderators: Ichibrothers, Cambronne
Bug Report for 1.2
If you open a scenario from within a module (gamebox), ZunTzu will keep a lock open on the .ztb file.
It will NOT do this if the scenario is loaded as the startup scenario. Only if you load a gamebox, then load a scenario afterward.
--- joshua
It will NOT do this if the scenario is loaded as the startup scenario. Only if you load a gamebox, then load a scenario afterward.
--- joshua
Re: Bug Report for 1.2
There are more bugs. For example I not recommend to hit space too fast (rapid/fast hit of space to take many cards). Some cars can be lost in the process:).dulcaoin wrote:If you open a scenario from within a module (gamebox), ZunTzu will keep a lock open on the .ztb file.
It will NOT do this if the scenario is loaded as the startup scenario. Only if you load a gamebox, then load a scenario afterward.
--- joshua
Unfortunately this program is not developed for long time. It is a shame because it is best program to play board games but it lack some functionalities (f.e. button to desynchronising view to check something on the board (without possibility to move elements), place to hide elements elements which are not counted for other players or area on board which is visible only for that player, remove multiple/all cards from hand etc. )
![Smile :)](./images/smilies/icon_smile.gif)
But I prefer to play in ZunTzu then in Vassal
![Wink ;)](./images/smilies/icon_wink.gif)
Geralt
Re: Bug Report for 1.2
I'm both trying to get the bugs captured for later reference, and to keep the forums alive in some way.Geralt wrote:There are more bugs. For example I not recommend to hit space too fast (rapid/fast hit of space to take many cards). Some cars can be lost in the process:).dulcaoin wrote:If you open a scenario from within a module (gamebox), ZunTzu will keep a lock open on the .ztb file.
It will NOT do this if the scenario is loaded as the startup scenario. Only if you load a gamebox, then load a scenario afterward.
--- joshua
Unfortunately this program is not developed for long time. It is a shame because it is best program to play board games but it lack some functionalities (f.e. button to desynchronising view to check something on the board (without possibility to move elements), place to hide elements elements which are not counted for other players or area on board which is visible only for that player, remove multiple/all cards from hand etc. ))
But I prefer to play in ZunTzu then in Vassal
Geralt
While I build modules, I run into issues, and as a software developer, I know the best time to capture the details is as they happen.
![Smile :)](./images/smilies/icon_smile.gif)
Re: Bug Report for 1.2
Here is another:dulcaoin wrote:If you open a scenario from within a module (gamebox), ZunTzu will keep a lock open on the .ztb file.
It will NOT do this if the scenario is loaded as the startup scenario. Only if you load a gamebox, then load a scenario afterward.
--- joshua
You can't put terrain counters in a stack, you will receive a NullReferenceException.
Note that you almost certainly have no need to DO this, it's just the error capturing and reporting that should be improved.
Re: Bug Report for 1.2
If you try to show the back side of a (single-sided) piece of terrain, you'll get a NullReferenceException (of the ABEND form).dulcaoin wrote:You can't put terrain counters in a stack, you will receive a NullReferenceException.
Note that you almost certainly have no need to DO this, it's just the error capturing and reporting that should be improved.
(another "duh" moment, but this makes for a reproducible test case)
-- joshua
- Bill Barrett
- 231
- Posts: 351
- Joined: 25 May 2008, 13:25
Hi dulcaoin,
I wouldn't describe those issues with Terrain objects as "bugs", because they simply won't arise if people build gameboxes in the prescribed (as Jerome intended/expected) way. Sure, people will screw up their xml (very easy to do), but as you suggest - nobody is ever likely to encounter that stacking "bug" (because Terrains aren't designed to stack) unless they try editing the saved scenario files before gaining a full understanding of the potential ramifications
Regards, Bill.
I wouldn't describe those issues with Terrain objects as "bugs", because they simply won't arise if people build gameboxes in the prescribed (as Jerome intended/expected) way. Sure, people will screw up their xml (very easy to do), but as you suggest - nobody is ever likely to encounter that stacking "bug" (because Terrains aren't designed to stack) unless they try editing the saved scenario files before gaining a full understanding of the potential ramifications
![Wink :wink:](./images/smilies/icon_wink.gif)
Regards, Bill.
Software should never ABEND. I say this as a professional software engineer (and one-time Quality Assurance engineer).Bill Barrett wrote:Hi dulcaoin,
I wouldn't describe those issues with Terrain objects as "bugs", because they simply won't arise if people build gameboxes in the prescribed (as Jerome intended/expected) way. Sure, people will screw up their xml (very easy to do), but as you suggest - nobody is ever likely to encounter that stacking "bug" (because Terrains aren't designed to stack) unless they try editing the saved scenario files before gaining a full understanding of the potential ramifications![]()
Regards, Bill.
![Wink :wink:](./images/smilies/icon_wink.gif)
As I pointed out in the first report, the defect in each case is not that the features aren't supported, it's that the exception is not handled (in the case of the ABEND) and not reported properly (in both cases). By having a reproducible test case, it will be possible to easily cause the issue in ZunTzu, catch it with debugger, and add just a few lines of code to more properly inform the user what the issue is (so he can fix it), and not abnormally end execution.
There are many ways to cause a NullReferenceException in software, and especially ZunTzu. While developing a companion app that lets me lay out the pieces much more efficiently, I've found several of them. When you're trying to develop a scenario, making a change and receiving a NRE tells you as the user absolutely nothing about what you're doing wrong. By pointing out two of them, I've created test cases that can be handled, and the software can become more properly robust and user-friendly. By reporting "you've attempted to place terrain in a stack, which is not allowed" or "you have attempted to show the back face for a counter (terrain) (card) that has no back-image defined," not only have you provided the user a coherent response to the error, and steps to fix it, but you've reduced the *multitude* of possible issues that might have lead to the NullReferenceException to occur (by 4 counts). That way, if you get an NRE, you know additional things that you DIDN'T do to cause it.
Respectfully,
-- joshua
- Bill Barrett
- 231
- Posts: 351
- Joined: 25 May 2008, 13:25
If I'm honest Bill (no, we don't *really* know one another), you were on my mind when I decided I should post these bugs. Once the "power user" starts to use every feature of the software, these issues then become apparent. As I was building my skill with the features of ZunTzu, I kept hitting these NRE's, and thinking "how did these prolific module designers get GOOD at this, it seems to like to cr4p the b3d REALLY often!" [and a large part of that is that ZT ABENDs when it should just report an error and stop loading]Bill Barrett wrote:Sure, but I just don't think that Jerome anticipated what you (and I, perhaps others also) are trying to do with the code....
Regards, Bill.
One "trick" it took me awhile to learn was that need to read the error feedback that might get sent back to Jerome (depending on which button you click). They're extremely informative.
In fact, that would be ANOTHER bug report -- those should be reported in app and not cause an ABEND either.
-- joshua
- Bill Barrett
- 231
- Posts: 351
- Joined: 25 May 2008, 13:25
I'm using "tricks" to get extra features out of ZunTzu.Bill Barrett wrote:Yup, I pretty much learned everything through trial and error.
And of course it took longer than expected
However, I can now build and edit gameboxes very quickly - it's getting the graphics to look their best that now consumes most of my dev time...
Defining the "map" to be a tabletop image, using "terrain" for the maps and turn tracks, and counters go on top of those.
Making extra tabs to act as "counter trays" so counters are sorted more logically than they usually are when punched.
Most importantly, an external database-backend application to do layout, so everything lines up neat and tidy and pro (especially edge to edge on multiple map boards, and "automatic" proper centered placement of counter stacks on hex coordinates of a given map, but also just general layout placement of sets of stacks of counters (in lines, rows, or grid) that are placed relative to previously placed sets of stack of counters that were laid out the same way -- which could continue down the line, etc.)
I'd say I'm probably doing twice the work needed to get a "standard" module running. Scenario images on the tabletop. "Waves" (separate rows) of counters stacked in neat lines for the various steps of setup, etc.
My Kingdom for grid snap, basically.
![Smile :-)](./images/smilies/icon_smile.gif)
http://boardgamegeek.com/thread/1225738 ... tzu-module
-- joshua
With some research, I see you're a master of the tabletop technique, as well, Bill. Didn't mean to take that away from you or anybody.dulcaoin wrote: I'm using "tricks" to get extra features out of ZunTzu.
Defining the "map" to be a tabletop image, using "terrain" for the maps and turn tracks, and counters go on top of those.
Was just trying to describe the level of detail.
![Smile :)](./images/smilies/icon_smile.gif)
-- joshua
- Bill Barrett
- 231
- Posts: 351
- Joined: 25 May 2008, 13:25
That's OK - you're relatively new here
But I'm very pleased to see some life injected back into the forums, and particularly your evident enthusiasm. It's a real shame (and something of a mystery to me) that ZunTzu hasn't attracted more adherents. Sure, it doesn't work natively on a Mac and PBEM is not integral to its design, but in my view it's much easier to use and offers the closest experience to playing an actual "physical" boardgame. Of course it has its shortcomings, and I would love to have use of some of the features/ideas available in VASSAL and CB, but not if it would be at the expense of accessibility or graphic quality.
Jerome has taken a (hopefully temporary) back seat, so we need to put out more and more high quality modules and thus spread the word, until the clamour for his return is deafening and irresistible
Regards, Bill.
![Wink :wink:](./images/smilies/icon_wink.gif)
But I'm very pleased to see some life injected back into the forums, and particularly your evident enthusiasm. It's a real shame (and something of a mystery to me) that ZunTzu hasn't attracted more adherents. Sure, it doesn't work natively on a Mac and PBEM is not integral to its design, but in my view it's much easier to use and offers the closest experience to playing an actual "physical" boardgame. Of course it has its shortcomings, and I would love to have use of some of the features/ideas available in VASSAL and CB, but not if it would be at the expense of accessibility or graphic quality.
Jerome has taken a (hopefully temporary) back seat, so we need to put out more and more high quality modules and thus spread the word, until the clamour for his return is deafening and irresistible
![Wink :wink:](./images/smilies/icon_wink.gif)
Regards, Bill.
I moved the thread to General Discussion.Bill Barrett wrote:That's OK - you're relatively new here![]()
But I'm very pleased to see some life injected back into the forums, and particularly your evident enthusiasm. It's a real shame (and something of a mystery to me) that ZunTzu hasn't attracted more adherents. Sure, it doesn't work natively on a Mac and PBEM is not integral to its design, but in my view it's much easier to use and offers the closest experience to playing an actual "physical" boardgame. Of course it has its shortcomings, and I would love to have use of some of the features/ideas available in VASSAL and CB, but not if it would be at the expense of accessibility or graphic quality.
Jerome has taken a (hopefully temporary) back seat, so we need to put out more and more high quality modules and thus spread the word, until the clamour for his return is deafening and irresistible![]()
Regards, Bill.
Stack inspector defect (non-crash, bad user experience):
1) go to a countersheet, "tear off" and stack 3 counters
2) drag that stack to main tabletop tab, place on tabletop
3) double-click stack to use stack inspector
4) click Unpunch (Del)
Bottom counter does not unpunch. Unpunch (Del) is greyed
* closing stack inspector will apparently return the counter to the countersheet, or counter can be dragged out to tabletop again, where it will stay when inspector is closed
1) go to a countersheet, "tear off" and stack 3 counters
2) drag that stack to main tabletop tab, place on tabletop
3) double-click stack to use stack inspector
4) click Unpunch (Del)
Bottom counter does not unpunch. Unpunch (Del) is greyed
* closing stack inspector will apparently return the counter to the countersheet, or counter can be dragged out to tabletop again, where it will stay when inspector is closed