Create account / Log in

Vassal 3.4.xyz errors/warnings

Issues with the Vassal engine.

Moderators: uckelman, Tim M

Re: Vassal 3.4.xyz errors/warnings

Postby uckelman » December 21st, 2020, 12:24 am

I can tell you that the module behavior for those images changed from 3.3.2 to 3.3.3-beta1, which was released in the middle of August. I could do more if I knew what I was looking for in the module.
User avatar
uckelman
Site Admin
 
Posts: 9220
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Vassal 3.4.xyz errors/warnings

Postby barbanera » December 21st, 2020, 9:43 am

uckelman wrote:I can tell you that the module behavior for those images changed from 3.3.2 to 3.3.3-beta1, which was released in the middle of August. I could do more if I knew what I was looking for in the module.


Those images showing greyed out space ships are placed at startup by the following:

1) Empire War map window -> TALON tabbed panel -> Terran tab -> Terran map window

2) BB, BA, CL, ... at-start stacks (one per ship type) to place an initial one (at the bottom of each column)

3) Place Marker traits - triggering on "setup" which is invoked by a startup GKC - inside those same at-start-stacks to spawn another one, which spawns another one in turn etc, increasing each their own counter (numBB, numBA...), and stopping at 5

Here is an example (disregard the Invisible trait, which is empty and not used):

BBtemplate.jpg
BBtemplate.jpg (92.46 KiB) Viewed 1574 times
barbanera
 
Posts: 467
Joined: January 12th, 2012, 2:27 pm

Re: Vassal 3.4.xyz errors/warnings

Postby uckelman » December 21st, 2020, 11:55 am

Go to Preferences > Compatibility and check "Use Classic Moved Fixed Distance trait move batching". That will solve your piece placement problem. Brent can probably explain why, and what to do instead.
User avatar
uckelman
Site Admin
 
Posts: 9220
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Vassal 3.4.xyz errors/warnings

Postby barbanera » December 21st, 2020, 2:14 pm

Thanks, hopefully Brent will chime in and point me what needs to be changed in the module itself (not the end user preferences), then. Especially for future reference, I mean.

As for this particular module: this is all very much discouraging, as I said.. At this stage, who knows how many other things there are that are failing under 3.4.x and that I have yet to notice.
barbanera
 
Posts: 467
Joined: January 12th, 2012, 2:27 pm

Re: Vassal 3.4.xyz errors/warnings

Postby uckelman » December 21st, 2020, 2:48 pm

Thus spake barbanera:
> Thanks, hopefully Brent will chime in and point me what needs to be
> changed in the module itself (not the end user preferences), then.
> Especially for future reference, I mean.
>
> As for this particular module: this is all very much discouraging, as I
> said.. At this stage, who knows how many other things there are that are
> failing under 3.4.x and that I have yet to notice.

This has been true of every version change in VASSAL---each release during
3.2 could have broken something. Also each release during 3.1, and during
3.0, and each release before that. And each update to Java or your drivers
or OS... Basically this is true of all software ever written.

We can't programatically determine what effects changes we make will have
on your module, and we can't fix bugs at all if we have to also maintain
previous behavior. If we stop fixing bugs, then I'll simply be having this
conversation with someone else---someone who is complaining about the bugs
we haven't fixed--and I'd prefer to defend a decision to fix bugs instead
of a decision not to fix bugs.

Your module seems to have relied on a quite a few bugs---way, way more than
any other module we've seen. That's bad luck. If you don't fix these things,
eventually the module will become unusable, and I don't mean unusable with
3.4. I mean unusable with 3.2.17, because people will have an increasingly
difficult time running 3.2.17---it relies on Java 8 and that's not far off
from the end of its life.

Now is the time to fix these problems, while there's still a collective
memory of what's involved. Wait and it will only get harder.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 9220
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Vassal 3.4.xyz errors/warnings

Postby barbanera » December 21st, 2020, 3:11 pm

So, wait a minute, the Move Fixed Distance change was to fix a bug? Not some kind of performance improvement, instead?

Well, what can I say.. I was just using Move Fixed Distance to place a marker and shift it up 150 pixels, which in turns places another which does the same etc.

I challenge everybody to figure beforehand this was relying on a bug.
barbanera
 
Posts: 467
Joined: January 12th, 2012, 2:27 pm

Re: Vassal 3.4.xyz errors/warnings

Postby uckelman » December 21st, 2020, 4:27 pm

barbanera wrote:So, wait a minute, the Move Fixed Distance change was to fix a bug? Not some kind of performance improvement, instead?

Yes, the old Move Fixed Distance behavior prevented Undo from working properly. We'd had complaints about Undo failing sometimes for more than a decade and only discovered the cause in June. It was an extraordinarily difficult thing to troubleshoot.

Well, what can I say.. I was just using Move Fixed Distance to place a marker and shift it up 150 pixels, which in turns places another which does the same etc.

I challenge everybody to figure beforehand this was relying on a bug.

No one's claiming you should have known.
User avatar
uckelman
Site Admin
 
Posts: 9220
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Vassal 3.4.xyz errors/warnings

Postby barbanera » December 21st, 2020, 6:23 pm

Ok, but may I ask then if fixing that old standing bug perhaps didn't break something else in the meanwhile?

I cannot understand why just doing that multiple place, move, spawn cycle would not be supported by the new Move Fixed Distance trait.

Or perhaps it is, but it should be done some other way? Forgive me but "move batching" the old way gives me hope it can be done, but it doesn't give me any hint how to do it updating the module itself.

That procedure really helps me to avoid having to define 50 different at-start-stacks to deploy 50 equal pieces on a line, say. I could try switching to STLs, I guess (to CurrentX/CurrentY+displacement), assuming that would work instead. But that would be painful/slow updating of basically all of my modules.
barbanera
 
Posts: 467
Joined: January 12th, 2012, 2:27 pm

Previous

Return to Technical Support & Bugs

Who is online

Users browsing this forum: Bing [Bot] and 5 guests