Vassal 3.4.xyz errors/warnings

[uckelman]

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.

[barbanera]

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 (92.46 KiB) Viewed 1574 times

[uckelman]

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.

[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.

[uckelman]

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.

[barbanera]

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.

[uckelman]

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.

[barbanera]

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.