vassal 3.3.3 beta
After installing this version i got this message, sometimes:
Next GPID updated from 5141 to 5142
Using Linux Debian 10, java11-openjdk-amd64.
The numbers increase constantly but i couldn’t find a regularity in that. It appears in the course of editing a mod, saving it and reopening it.
I am getting these sort of messages myself.
Moreover, not only Next GPID is continuosly reported as being updated - whenever I open the module for editing - but also GPIDs of new traits are being updated. As an example, I just added several place Markers traits on a Piece and after saving and reopening the module for editing I get:
I just saved the module straight away again and reopened it and I got:
Thanks for the info, investigating.
Hi,
I have found one issue relating to GPID allocation, but it would not cause the messages you are seeing and I have not been able to recreate these directly. Could you please tell me:
The ‘Several Place Markers’ you added to a Piece, where they added directly to a Piece, or where they added to a Prototype that the piece uses?
Where you editing the module with the beta version when you added the Place Marker traits?
Does this behaviour continue with further editings of the module using the beta version only?
Does this behaviour occur with the newly release 3.4.0-beta?
Thanks,
Brent.
I don’t know if it is the same circumstances but I have seen these GPID updated messages as well. under v3.3.3-beta1 and v3.4.0-beta1. Here is one example from a test in another thread (step (c)):-
[code]Under v3.4.0-beta1
a) Edit module.
Output in chat log:
b) Open and scenario and make a turn (works ok, executing several GKC routines that failed before).
c) Save the edit and re-open.
Output in chat log:
To address your questions from my experience:-
I have both types in my module.
No. The Place Marker traits have been in my module since v3.3.2 or earlier.
In the above test, it seemed to be a one time; I haven’t been seeing it continuously and in the above mentioned test, it occurred on the second open of the module but not on subsequent ones.
Yes.
These messages are normal and are reporting the results of the GpID check and cleanup that happens whenever you edit a module. Previously, they where not reported, but I though it would be useful to report them to Designers, especially those getting into manual buildfile editing.
In normal circumstances, you should never see any of these messages, except in 2 cicumstances:
In both cases, saving the module under the 3.3.3 or 3.4.0 betas or later saves the update and you should never see any again unless you manually edit the buildfile.
[code]- Place/Replace trait Place Marker - Command Counter GPID updated from to 3766
These messages are reporting that Vassal has located the previously ignored Place Marker/Replace with Other traits inside Prototypes and has allocated them a new GpID, updating them from blank to a value.
- Next GPID updated from 9786 to 9787This message indicates that Vassal has found that the next GpID to be allocated has already been allocated, so it is bumping it up to the next available number.
Both of these types of messages should not occur on subsequent edits of the module as long as you saved it using 3.3.3/3.4.0 unless you edit the buildfile manually.
If these messages do re-occur, it would be great could get a report of what sort of editing was done on the module.
Regards,
Brent.
That comes up after i had deleted one piece, copied and renamed another one. All within the editor no manually working on the buildfile.
Linux Debian 10, java11-openjdk-amd64, Vassal 3.4.0-beta 1.
Peter
Hi, here is my report:
1) Downloaded, installed and then started vassal 3.4.0 beta1.
2) Opened the module for editing (showing as a 3.3.0 beta1 module), got a next GPID report:
- High Frontier 4th Edition version 0.993
- Next GPID updated from 9786 to 9787
3) Saved it without any change and closed. The module now shows as a 3.4.0 beta1 module.
4) Reopened it for editing (again with 3.4.0 beta1), no next GPID report:
- High Frontier 4th Edition version 0.993
5) Edited a piece (not a prototype: a piece in an at-start-stack on the Main Map) and added a Place Marker trait "Place Aqua", saved and closed.
6) Reopened the module again for editing:
- High Frontier 4th Edition version 0.993
- Place/Replace trait Place Marker - Place Aqua GPID updated from to 9790
7) Saved and closed.
8) Reopened once again for editing:
- High Frontier 4th Edition version 0.993
- Next GPID updated from 9791 to 9792
9) Saved and closed.
10) Reopened for editing:
- High Frontier 4th Edition version 0.993
11) Edited the above piece to remove the "Place Aqua" place marker trait. Saved and closed.
12) Reopened for editing:
- High Frontier 4th Edition version 0.993
13) Added again a Place Marker trait to the same piece as above (this time called "Test this"). Saved and closed.
13) Reopened for editing, and get a GPID update report (but why 9795? the next GPID - as reported above - was supposed to be 9792)
- High Frontier 4th Edition version 0.993
- Place/Replace trait Place Marker - Test this GPID updated from to 9795
14) Saved and closed.
15) Reopened for editing:
- High Frontier 4th Edition version 0.993
- Next GPID updated from 9796 to 9797
16) Removed the said place marker, saved and closed.
17) Reopened for editing:
- High Frontier 4th Edition version 0.993
Etc etc, ad libitum
Perhaps the running away GPIDs are not an issue and there is no bug here.
However, my vote would then be to avoid reporting these GPIDs updates for place marker traits and for next GPIDs… I don’t think a module developer really needs to see them and they are just confusing.
Just my 2c.
Hmmm. I found it helpful to know that “something was happening”. Among other things a gentle reminder that I (or some predecessor) had mis-hand-edited something. Also once you re-save the module after this, those messages go away.
In the normal course of events, the GPID’s are allocated quietly and you never hear about them.
For most designers, this will be a one-time thing moving from pre 3.3.3 to post 3.4.0 and you should never see another one again.
Normally, if you see these messages, something is wrong and you need to know about it. If you haven’t edited the buildfile, then they indicate a VASSAL bug.
Barbanera, I missed reading the bottom of your report. Looks like there are issues, but I have a better idea where to look now.
Thanks.
Thanks for the report Peter.
Hi Barbanera,
I have solved 2 problems:
I cannot reproduce this problem:
[code]5) Edited a piece (not a prototype: a piece in an at-start-stack on the Main Map) and added a Place Marker trait “Place Aqua”, saved and closed.
Where creating a new Place Marker trait anywhere fails to get a GPID allocated. Is it possible to get a link to this version of the module so I can track this deeper?
Thanks,
Brent.
My most recent encounter with the message was this sequence (may be normal, but I have an idea if it is)…
My idea, if possible and if the above is a necessary consequence of Place Marker, then flag the relevant edit action when it is performed, at least in addition to error messages later.
e.g. If it is defining the Marker independently of an existing piece that causes the issue, then either
a) Do the GPID update when Define Marker action is taken in a Placed Marker trait that doesn’t already have a piece id, or during the module save process… guessing neither
of these are possible/relevant ?
or
b) Put out a warning message (alert or to the chat window) advising that Refresh Counters won’t be possible until the module is saved and re-opened. This at least will ensure that the user associates the messages with the type of action that they are doing.
Mark
Hi Brent,
You can download it from here:
drive.google.com/drive/folders/ … w1uT6C6uja
The Piece where I am adding those Place Marker traits is the last one in the Main Map called “Solar System map” in the at-start-stack of the same name. The Place Marker traits used there (as well as the ones used in the testing I reported) place pieces taken from the “Game Pieces” Game Piece Palette.
Regards,
Stefano
P.S. I’ll be damned… I just noticed that actually starting a “New Game” with 3.4.0 beta1 now gives a lot of warning/errors that I was not getting at all up to and including 3.3.3 beta1:
[code]- Bad Data in Module: (claims) [Place Marker - Place claim counters] - Resources.place_error Could not find required so next game piece palette will open in its own window in Module markerSpec=VASSAL.build.module.PieceWindow:required so next game piece palette will open in its own window/VASSAL.build.widget.PieceSlot:claims
All these errors relate to pieces placed in the VP Track window, which indeed no longer works as before (still working under 3.3.0 beta1).
Same module as before, subsequently edited but no new Place Marker traits or pieces added… latest re-open gave this message:
Also, it seems to have increased from 3902 to 3903 at some point but I missed that one.
Mark
Ok, now it’s getting really weird. Thanks for the link, I will have a play with your module.
Hi Mark,
When creating new Place Marker traits, the GPID’s should all be allocated and if necessary updated. There should be no error next time the module is loaded.
I just can’t seem to be able to reproduce thus.
Could you please describe the exact steps by which you do this? By ‘based’ on, are you using Copy and Paste? Of a whole piece, of just a trait? Prototype, piece or piece in an at-start Stack or Deck? Are these Piece Markers defined by clicking on the Define Marker button, or the Select button, or changing between the two?
Thanks,
Brent.
Ok, Thanks both of you, I think I have tracked down the final error. The GPID was not being set if you used then ‘Select’ button to select a definition from another Game Piece Palette.
These errors
- Bad Data in Module: (claims) [Place Marker - Place claim counters] - Resources.place_error Could not find required so next game piece palette will open in its own window in Module markerSpec=VASSAL.build.module.PieceWindow:required so next game piece palette will open in its own window/VASSAL.build.widget.PieceSlot:claimsare referring to Place Marker traits that where created by clicking the ‘Select’ button, then selecting pieces in a Game Palette named “required so next game piece palette will open in its own window” which no longer appears to be in the module. Does this mean anything to you?
There same issues appears to be present in earlier versions of the module (looking at the buildfile), but the error messages don’t appear to be reported in earlier versions of Vassal.
Sounds right for my example - I was using ‘Select’ to set up a Place Marker trait and then going on to use ‘Define’ to change the piece details that ‘Select’ imported.
Let me know if you need any more info at this time.
Mark