Currently, if you want to assign a series of commands to be executed for each given value of a property, it is necessary to define a trigger action for each of the values that the property can assume.
A possible improvement could be represented by a kind of “switch trigger action” which should work according to the following structure:
I’d settle for a trigger that supported if-then-else, but I would not complain about a case statement. In either case, it would add code branching, which is found at even the most fundamental assembly language.
It would be great to be able to use triggers in Vassal that can support both an if-then-else statement and a case statement, which is widely used in almost all current programming languages.
You only really need the Switch/Case version as if-then-else can easily be implemented by a switch/case statement if you allow the switch value to be true/false as well as integer or string.
How do you see envision this trait when compared to the current Trigger? Does it need the additional ‘watch for keystroke’ and ‘looping’ facilities offered by Trigger Action? My feeling is to keep it as basic as possible. If you need to do any looping, then activate a Trigger action to do that.
As with any change, it’s a matter of someone having the time and inclination to code it. This would be a change to be included in v3.6. How are your Java skills Panther?
I agree: the if-then-else statement can be thought of as a particular sub case of the case statement, the one in which there are only two alternatives.
I also think it is best to keep this new trait as simple as possible; additional ‘watch for keystroke’ and ‘looping’
facilities are better if they are used in a Trigger action.
Unfortunately my knowledge of the Java language is only elementary.
I started analyzing the characteristics of this language only to see if it was possible to insert some of them in the expressions of the BeanShell.
I have noticed that practically all the mathematical functions of the Math library work perfectly, while I have encountered problems with the use of the Booelan operators and especially with the manipulation of strings.
A heartfelt thanks for everything you are doing to make Vassal more efficient!
hear, hear with the thanks. So many great features have been added since v3.3 emerged and I am looking forward to starting to use v3.5 for module editing.
I also agree with the concept of a simple case structure, leaving the existing trigger to handle complexity underneath. It seems to me that this modular approach will be easier to understand and less bug-prone. I only wonder if there will be a noticeable performance overhead from having to nest trigger traits within the case structure rather than the sequence/loop being provided direct by the Case trait.
my knowledge of Java is only elementary and I am unable to determine whether or not there will be a performance overhead in nesting the trigger traits within the case structure rather than in the sequence / loop file provided directly by the Case trait .
The performance overhead problem, however, should not be underestimated at all: some of the modules I am working on often cause memory problems; I have yet to understand how Vassal (or Java) manages memory: with a computer with 8 GB RAM how can errors be reported with not enough memory? It seems that Vassal (or Java) uses the same memory slot already used by the operating system.
The performance overhead problem, however, should not be underestimated
at all: some of the modules I am working on often cause memory problems;
I have yet to understand how Vassal (or Java) manages memory: with a
computer with 8 GB RAM how can errors be reported with not enough
memory? It seems that Vassal (or Java) uses the same memory slot
already used by the operating system.
Java allocates a fixed maximum amount of memory for itself on startup.
(This can be adjusted by the “maximum heap” setting in the preferences
for each module.) The amount of free RAM you have outside of what Java
allocates isn’t relevant, because Java won’t give your program more RAM
once Java is running.
Thus, it’s quite possible to simultaneously have a Java program run out
of memory while still having loads of unused system memory.
If this happens, increase the max heap setting for the module.
I tried several times to set the maximun heap to a higher value, but all I got was an error code informing me of the attempt to use a memory value greater than what is available and this despite that an entire memory slot from 4 GB was unused. The problem lies in how and especially where Java allocates memory. If possible, Java should be forced to allocate memory in a free memory slot, and not in one already used by the operating system and other programs that are activated automatically when the computer starts.
I tried several times to set the maximun heap to a higher value, but all
I got was an error code informing me of the attempt to use a memory
value greater than what is available and this despite that an entire
memory slot from 4 GB was unused.
Ok. To what were you trying to set the max heap?
The problem lies in how and especially
where Java allocates memory. If possible, Java should be forced to
allocate memory in a free memory slot, and not in one already used by
the operating system and other programs that are activated automatically
when the computer starts.
I well know that Java allocates memory contiguously. The problem is where Java allocates memory. I checked the memory footprint of the computer both before running Vassal and after. Java always allocates memory in a memory slot already occupied by the operating system and other programs, systematically ignoring the presence of other completely free memory slots. Increasing the memory, if it were possible with my laptop, would not solve the problem, since a friend of mine, with a computer with 16 GB, has the same problem with the same module. Maybe, the problem would be solved by forcing Java to allocate a 2GB chunk in a free slot and not in one already partially occupied. Unfortunately my knowledge of Java is too superficial so I don’t know if this is possible and how to do it. I will try to search the web, especially Java programmers’ forums looking for something that can help me.
Conceptually, the Switch Trigger is quite simple. The problem that has prevented me moving on this is the complexity required in the user interface to create and maintain that. You end up with a variable length list of variable length lists and those Combined Configurers are a real pain to create.
Essentially, you can already do this, at the expense of breaking each part of the case statement out into a separate trigger, with consequent performance issues and lack of readability.
The CRT switch statement above I have thought of as implementing as some sort of ‘Table Lookup’ or ‘Switch property’. However, this one is fairly easy to implement a lot more efficiently using Global Variables. Create 6 global variables case1, case2…case6 with the values “X”, “R”, … “RA”, then just lookup {GetProperty(“case” + DieRoll)}
Hello Brent,
I understand your point of view very well: performance issues are a big problem.
Currently, to simulate a CRT (or any other two-dimensional table) I use three Global Variables: CombatOdd, DieRoll and CombatResult. In the beginning a large number of trigger traits was needed to do this, while now I use a limited number of trigger traits, one for each possible result (“D”, “X”, etc.). Unfortunately, to drastically reduce the number of trigger traits, it was necessary to use complex conditions to be evaluated within each trigger.
There is certainly an easier way to achieve the same result, but I haven’t found it yet.
I noticed that you use the GetProperty function. In the past I have tried to use it, but I had to give up as the result I was getting was not what I expected, most likely due to the use of a incorrect syntax.
In this regard, I think a good tutorial on how to properly use the BeanShell functions would be of great help.