Switch trigger action

[panther 2010]

Hello

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:

Switch trigger

Case 0:
command 1;
command 2;
...
command n.

Case 1 :
command 1;
command 2;
...
command n.

Case 2 :
command 1;
command 2;
...
command n.

It's possible?

[marktb1961]

++++1 for this.

[panther 2010]

Hello marktb1961,

I'm glad my suggestion was appreciated.

Several years ago I had proposed another one, but, perhaps because the times were not yet ripe, I have not heard anything about it (see viewtopic.php?f=9&t=4142) .

Thank you .

Be well.

Panther 2010

[pawnpusher]

+1 for this too.

This is like the CASE construct in FORTRAN.

I can see this being very useful.

[panther 2010]

Hello pawnpusher,

the switch statement exists in Java, too.

This is an exemple that simulates a CRT :

public class CRT {
public static void main(string[]args) {
int DieRoll;
string CombatResult;

switch(DieRoll) {
case 1 :
CombatResult = "X;
break;
case 2 :
CombatResult = "R;
break;
case 3 :
CombatResult = "D;
break;
case 4 :
CombatResult = "NE;
break;
case 5 :
CombatResult = "DA;
break;
case 6 :
CombatResult = "RA;
break;
}
System.out.println(CombatResult);
}
}

Cheers!

Panther 2010.

[shilinski]

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.

[panther 2010]

Hello shilinski,

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.

Cheers.

[Brent Easton]

This is absolutely a great idea.

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?

Regards.

[panther 2010]

Hello Brent,

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!

Be well.

Panther 2010

[marktb1961]

Hello Brent,

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!

Be well.

Panther 2010

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.

Mark

[panther 2010]

Hello marktb1961,

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.

Cheers.

Panther 2010

[uckelman]

Thus spake panther 2010 via messages:
> 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.

--
J.

[panther 2010]

Hello uckelman,

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.

Be well.

Panther 2010

[uckelman]

Thus spake panther 2010 via messages:
> Hello uckelman,
>
> 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'm not sure what you're talking about here.

--
J.

[panther 2010]

Hello uckelman,

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.

Be well

Panther 2010