Still having issues with Send to Location

Ok. I have tried to get Send to Location with property expressions working multiple times now and I just can’t get it to work. This is what I get for my trouble: (Using Version 3.1.18 which is where its supposedly fixed)

Bad Data in Module: Factory (Factory)(?) [Send to Location - Discard] - Numeric field contains a non-number Xlocation[$$playerSide$DiscardX$]=playerSideDiscardX

Amy I doing something wrong or what? I tried reporting what it should be Player1DiscardX and checked and I have a deck called that. I tried switching it so that it pointed to a zone, still doesn’t work. I also noticed if I just try to report $$playerSide$DiscardX$ using the reporting function that it gives me Player1DiscardX as well, so it seems like the vassal isn’t actually processing the nested variables correctly still. IE it processes playerSide but then doesn’t process Player1DiscardX but instead returns Player1DiscardX

Module I am working with

aielman.redirectme.net/modules/Space%20Clash/spaceclash.zip

More Information:

I created a marker Player1X and stored the value 3095 in it (the X value I wanted the card sent to) and tried to use it instead in the Send to Location command.

When I report the value $$playerSide$X$ I get the correct value 3095.

When I try to use it in the X of Send to Location I get

  • Bad Data in Module: Factory (Factory)(?) [Send to Location - Discard] - Numeric field contains a non-number Xlocation[$$playerSide$X$]=playerSideX

Afaik nested variables don’t work on 3.1.18.

$$…$…$ just doesn’t work.

No, double indirection will generally not work in Vassal 3.1. It does work in certain instances, but this is more by good fortune than design.

You might like to try testing version 3.2 where you can specify

{GetProperty(“playerSide”+X)}

to get the desired result.

[Oops, found a bug in the Expression Builder help feature, functions are not working correctly.]

B.

*********** REPLY SEPARATOR ***********

On 26/02/2012 at 12:33 PM barbanera wrote:

Afaik nested variables don’t work on 3.1.18.

$$…$…$ just doesn’t work.


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

ugggh I thought the whole point of bug 4106 was to fix this.

so 3.2 may or may not fix the whole problem?

I would like to see this, because that syntax has never ever worked for me. In fact, I don’t see how the existing code could make it work - the string is, as I recall, parsed left-to-right and the ‘$’ basically toggles between ‘evaluate as a property’ and ‘evaluate as a literal string’. I wouldn’t be entirely surprised, though, to find some obscure field with different behavior, and I always like learning new arcane techniques. Do you have an example module where you’ve done this?

Well, like I said I can report $$playerSide$X$ correctly sooo.

It just doesn’t work on the X. The link above has it, just grab any card and hit ctrl 1 or ctrl 2 on it

The only reference I found to ‘playerSide’ in your module is in the Report Action trait for the ‘base’ prototype, which has this report format:

TESTING24 $playerSide$Discard2X  $Player1X$  $location$

That doesn’t follow the syntax that you’re claiming. Is there somewhere else in your module that you use nested property expansion (double indirection)?

-Seth

I don’t think what you are describing is a bug, and it’s definitely not bug 4106. It’s a feature that doesn’t exist in Vassal 3.1. Vassal 3.2 can do what you want using the syntax Brent has already provided - which I have used extensively myself and can therefore bear witness that it works (many, many thanks, Brent). But I believe the issue is unrelated to Send to Location; the syntax you’re using is simply invalid.

Sorry, I wasn’t very clear about that.

The only place that double indirection works is in 3.1 style Property Match strings where the left-hand argument is assumed to be a property name and automatically evaluated. Therefore, if you specify a property match expression like

$playerSide$X = 2

Then you get two layers of indirection because the $playerSide$ is pre-evaluated before the entire left hand side of the comparison is re-evaluated as a property name. This is just a by-product of the strange and confusing way that 3.1 style property match strings work. It’s one of the reasons I extended to the Beanshell Java expressions to replace these. With 3.2 we get a logical syntax that supports any complexity of expression including correctly supporting parentheses (e.g. {X < 2 && (A > 1 || b > 2)}

ugggh I thought the whole point of bug 4106 was to fix this.

No, as Seth says, bug 4106 fixes the problem where a string like $playerSide$X was not being evaluated. Double indirection strings like $$playerSide$X$ have never been supported anywhere in Vassal.

Rgds,
B.

*********** REPLY SEPARATOR ***********

On 26/02/2012 at 4:50 PM irishwulf wrote:

“aielman” wrote:

More Information:

I created a marker Player1X and stored the value 3095 in it (the X
value I wanted the card sent to) and tried to use it instead in the
Send to Location command.

When I report the value $$playerSide$X$ I get the correct value 3095.

I would like to see this, because that syntax has never ever worked for
me. In fact, I don’t see how the existing code could make it work - the
string is, as I recall, parsed left-to-right and the ‘$’ basically
toggles between ‘evaluate as a property’ and ‘evaluate as a literal
string’. I wouldn’t be entirely surprised, though, to find some obscure
field with different behavior, and I always like learning new arcane
techniques. Do you have an example module where you’ve done this?


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

Sorry for digging up this thread, but this is exactly what I’m looking for.

Is there Mac OS build for 3.2 or an expected release date?

Thanks

Brent Easton

Thus spake LimitedInfinity:

Sorry for digging up this thread, but this is exactly what I’m looking
for.

Is there Mac OS build for 3.2 or an expected release date?

There are development builds here:

vassalengine.org/~uckelman/builds/

We’ll release 3.2.0-beta1 when it’s ready. I wanted that to be months
ago, but that’s not happened.


J.

Thanks uckelman