What is a VASSAL plugin?

[jrv]

How is it different from a VASSAL extension and/or module?

JR

 

[zgrose]

Context?

 

[jrv]

Context?

I have been exploring how to add a new counter type to vasl, and I saw that the bsh "plugin" creates a CommandEncoder, which is part of what I think I need to do. I have been working on an extension but now I wonder if a plugin might be the right packaging instead. I have been inserting the new counter into the buildFile by hand but now I think I need a PieceDefiner so it can participate in the editing process, and I see that is what the bsh plugin registers too.

JR

 

[zgrose]

Well, looking at the source for Plugin, ModulePlugin and ModuleExtension, it looks like Plugin was just there to extend Extensions (since a ModulePlugin *is* a ModuleExtension) with some new functions so it looks like you're on the right track so far.

 

[BigAl737]

I have been exploring how to add a new counter type to vasl, and I saw that the bsh "plugin" creates a CommandEncoder, which is part of what I think I need to do. I have been working on an extension but now I wonder if a plugin might be the right packaging instead. I have been inserting the new counter into the buildFile by hand but now I think I need a PieceDefiner so it can participate in the editing process, and I see that is what the bsh plugin registers too.

JR

I've been trying to teach myself this as well in an effort to provide counter support to VASL. If you have the time, would you share what works for you?

 

[jrv]

I've been trying to teach myself this as well in an effort to provide counter support to VASL. If you have the time, would you share what works for you?

I am trying to create a decorator that behaves like a state machine, that is that it can have transitions to other states in an arbitrary graph and is not limited to a linear structure. VASSAL has the embellishment decorator built in, which is used in layers to show images of the counter in various states. That code only understands a linear array of transitions. For instance the 4-5-8 ELRs to a 4-4-7 ELRs to a 4-2-6, but once it reaches conscript by game rule it should battle-harden to 5-2-7. This is not implemented, partly because the embellishment decorator only can return to a 4-4-7, i.e. it can only go back/forward through the array. Instead battle-hardening is disabled for this counter once the 4-2-6 state is reached. I found that very confusing when I first encountered it. [As an aside this might be implemented today using counter substitution; I have not tested this, however.]

I started out by adding a new StateCounterCommandEncoder to the code. What I have found out so far is that whenever there is text data for a PieceSlot entry in buildFile, VASSAL asks each registered command encoder if it knows what to do with the text. The first command encoder that returns a non-null result wins. The command encoders are free to decide whether to return a null or not based on any criteria they like. It seems that most just look for a known prefix. So I created a new prefix ("SC+") and put it in my buildFile by hand. I added a StateCounter Decorator class to handle instances of the new type of counter. All of this worked as an extension, but I have reached the point where I want to use the extension editor to add new instances rather than creating the buildFile by hand. It was at this point I found out about PieceDefiners and, through them, found Plugins.

I have uploaded what I have done so far to github: https://github.com/jrvjrv/StateCounterExt/releases/tag/0.05.00 . This is an extension, but it is by no means anything more than a proof-of-concept. I added a tab with three counters. The first one is the standard 4-5-8 from vasl, included just for my convenience. The next one is a state machine 4-5-8. If you ELR it twice to 4-2-6 then battle-harden it, it will become a 5-2-7, then a 6-2-8. I also added a state machine 4-4-7 that starts in a different state but is otherwise the same as the state machine 4-5-8. You can install the extension just like any other extension, but it is not complete by any means. If recommend only installing it for testing. Once you are done I recommend removing the extension.

If you are truly interested and dedicated, the source code is there too. Much of the implementation is copy/paste from embellishment, removing what I thought did not belong and/or didn't understand. I will have to understand much of this code in the future, but to get the proof-of-concept I noodled with it until it stopped throwing exceptions.

JR

 

[zgrose]

If you're looking for an improved ASL counter, the state you want to store is probably not what counter it is, but what attributes it has (flipped, heroic, berserk, etc).
IMO, Replace With Other is the best way to BH/ELR/etc in VASSAL so someway to pass metadata between counters would be da bomb.

 

[Sully]

If you look at the way the VASL counters were setup you'll see that the authors (bless their souls) did not use "Replace with Other" because you lose the counter state when you do. I did this with the Finns and there's a bug to this effect (#316). I'm not the brightest bulb on the tree but the fact that I gave up trying to duplicate the current counter logic ought to tell you something.

To get our current behavior each piece contains all of the possible states of the counter (broken, battle harden, ELR) making them incredibly complex. All of this is strung together through a set of nested prototype definitions making it nearly impossible for mere mortals to comprehend. In short, our counters are no longer maintainable, as witnessed by the ever-increasing set of bugs.

If I ruled the world I'd strip all this out and have each counter in VASL represent a physical counter. Yes, we'd lose some chrome, but it would be much much easier to create and maintain counters.

 

[jrv]

All of this is strung together through a set of nested prototype definitions making it nearly impossible for mere mortals to comprehend. In short, our counters are no longer maintainable, as witnessed by the ever-increasing set of bugs.

I am guessing by "nested prototype" you actually mean "nested Decorator", i.e. classes that extend Decorator. As best I understand the code, prototypes are themselves stacks of Decorators that can be inserted as a group into another stack.

JR

 

[jrv]

If you're looking for an improved ASL counter, the state you want to store is probably not what counter it is, but what attributes it has (flipped, heroic, berserk, etc).
IMO, Replace With Other is the best way to BH/ELR/etc in VASSAL so someway to pass metadata between counters would be da bomb.

I had not considered the problem of passing state when I suggested the "replace with" idea. You are right that only works with the current code if the counter will transition to a known state, e.g. vehicle in whatever state -> wreck. Although it might be possible to transmit state with the "replace counter" functionality it seems to me that this would increase the complexity of an already complex stack of counter decorators, making reasoning about the effects of other code changes more difficult. But perhaps it is the only way forward.

JR

 

[zgrose]

it seems to me that this would increase the complexity of an already complex stack of counter decorators, making reasoning about the effects of other code changes more difficult. But perhaps it is the only way forward.

You're replacing the complex stack of counter decorators with this internal metadata structure, if it's even possible. At least that's the design I would try for. There aren't really THAT many states to track (I think) in terms of ASL ones. Not sure how/if you could pass rotation and labels, etc.

So in a simplified case, let's say you have a 8-0 SMC counter that is Heroic and labeled "Sgt Frank." When you activate the Battle Hardening you would, fire off a Replace with Other to a 8-1 counter and then set that new counter's metadata (i.e. Heroic and that it's label is Sgt Frank). Almost like a Macro for "drag a 8-1 out of the tray and drop on top of the active counter (the 8-0), set it to Heroic and set its label to Sgt Frank, delete the 8-0"

I *think* some of that stuff might flow depending on the position of traits in the piece editor but I'd wouldn't bet on it and it's pretty messy. Create a new piece that could do this transformation explicitly would be pretty sweet. So the proof of concept would be if you could set an arbitrary list of properties on a counter and transmit that list to a new counter.

 

[Sully]

I am guessing by "nested prototype" you actually mean "nested Decorator", i.e. classes that extend Decorator. As best I understand the code, prototypes are themselves stacks of Decorators that can be inserted as a group into another stack.

JR

VASSAL allows you to create "prototypes" that are collections of piece traits (i.e.decorators). If you edit the VASL module you can see them here:



If you look at an individual counter you will see most of the piece attributes are inherited from a prototype:


You then look at the ruINF prototype to see that it, too, is defined using prototypes:


These can be nested 3 and 4 levels deep. It's turtles all the way down.