Local/Global Properties

[chrono280]

Having some slight heart palpitations Hope you can help me understand what I'm doing wrong.

In my 3.2.0-svn8213 module I have (many) values sort of operating in a chart like a spread sheet but to boil it down-

-There are numerical counters that report the value of "colonyCounterValue" which is a global property stored on the Map Window they are in.
-This "colonyCounterValue" property can be passed to a Global Property (filed in the root/main map Global Property section). This Global Property is something like "BluecolonyCounterValue". So it would only be for the Blue team.
-The green team has a similar numerical counter on his Map Window with a "colonyCounterValue" Global Property that passes its value to the GreenColonyCounterValue global property on the main map.
-The idea behind all of this is that the numerical counters in my chart have generic global properties that (I thought) were Local to the Map window. This makes it easy for me to copy and paste a chart for another team. Then I just adjust a counter on the chart that "routes" these values to their respective team global value.

Counter value (generic) -> Blue window -> Blue's counter value global property.

Counter value (generic) -> Green window -> Green's counter value global property.

But what is happening now that I have finally set it up (there are MANY MANY numerical counter "cells" in my spreadsheet). Is that if the Green player makes a change to the generic "colonyCounterValue" it will be reflected on the Blue Window. In other words, I thought the Global Properties stored in a given window were treated as local properties for the counters in that window... but it seems they are not. ...Help! Thanks in advance

[chrono280]

New twist: This only happens in a multiplayer game. If ,offline, I join as Green, change the colonyCounterValue property, switch to Blue and refresh the counter there, it does NOT show me the value of Green's counter which is what it was doing in the above example. So to summarize again:

Green Production Window -> numerical counter that reports value of -> colonyCounterValue (Global Prop in that window)
Blue Production Window -> numerical counter that reports value of -> colonyCounterValue (Global Prop in that window)

In a multiplayer game if someone puts a value into the counter on the Green Production Window, it will be mirrored in the Blue Production window as well. However, if Blue puts a value into the counter on the Blue Production Window it is NOT mirrored onto Green.

If playing offline, the values are NOT mirrored at all and operate independently.

Let me know if I can explain this any better.

[barbanera]

This is known bug 4278.

Till they fix it, you are forced to use unique variable names in every window (Green_countervalue in the Green window, Blue_countervalue in the blue window etc).

[chrono280]

Wow I had no idea this existed already. Looks like it was reported in Feb, I was about halfway through writing the Production Sheet section of my module at that time.

Really this is a showstopper for my module. I can rewrite it with team-dependent global properties, but it would require changing the prototypes for hundreds pieces since they now just inherity a single prototype for using the local variables and then use $PlayerSide$ when somthing needs to be sent to a team specific variable.

So, Barbanera & Brian & irishwulf & anybody else:

How can I help!? I really want to get this fixed for the 3.2.0 release. My knowledge of Java is limited but I'm prepared to do everything I can to fix this since that beats re-doing half of my new module. Where can I start? I'll see about putting the word out on the BGG fourms for this game if anybody with Java experience could take a stab at fixing this specific bug.

Let me know how I can make this happen.... I'm desperate!

For anybody following along, here is the link to the bug:
http://www.vassalengine.org/tracker/sho ... gi?id=4278

[barbanera]

Yeah.. I know how you feel. It was a show stopper for me as well and I had to painfully rename all variables, on a map specific base, clone the prototypes in multiple instances for map specific use etc..

If it can help, remember you can still use set global properties with Named Map = $playerSide$ and gp name something like <countername>_$playerSide$ which is the way I had to go for.

[chrono280]

Geez, that's miserable. I mean I know how to do that, I can make new GPs within the map window easily enough, but I have a grid that is 15 counters by 20 counters (like a spreadsheet) and grids similar to that in 4 other tabs within my production window. It's just a massive amount of prototypes to replace. In fact I'd go form having something like 50 prototypes total in my game to like 200, since they would now need to 'talk' to different variables. Maybe I could do it in text edit with the buildfile. I'd also have to go and do it for Red and Yellow then. It stinks, I thought I was on to something with the way I had the local/global properties set up so I could duplicate everything out, changing only a few properties for each team's private window.

What needs to be done to the vassal engine to fix this bug? I just think that's gotta be easier than re-wiring my production sheets. It took me months to get them working right. There's gotta be something I can do to help!

[barbanera]

If you know a bit of Java why don't you pursue the line of investigation that Seth (Irishwulf) initiated following my report?

[Brent Easton]

I believe I have sorted out this bug, just doing some final testing. Turns out that the saving/restoring/changing of same named Global Properties in different zones/maps is completely broken in both 3.1.19 and 3.2. Just making sure my changes do the same broken behaviour when processing pre-bugfix save games or log files.

[barbanera]

That's great news, Brent. Thank you.

[chrono280]

Brent, you made my day (and saved me hours and hours of work), thanks for figuring this out!

[Brent Easton]

Have submitted a fix to branch Brent-3.2@8216.

As Seth found, the identity of the Global property container (module, map or zone) was not being encoded when Commands where generated to set or change property values. This caused all references to a property in different containers to be handled by the first container found, effectively making the subsequent same named properties invisible.

The same fix needs to be applied to the latest 3.1 branch as well.

[uckelman]

Thus spake Brent Easton:
> Have submitted a fix to branch Brent-3.2@8216.
>
> As Seth found, the identity of the Global property container (module,
> map or zone) was not being encoded when Commands where generated to set
> or change property values. This caused all references to a property in
> different containers to be handled by the first container found,
> effectively making the subsequent same named properties invisible.
>
> The same fix needs to be applied to the latest 3.1 branch as well.

Thanks, Brent. I'll merge this when I return home from Iceland tomorrow.

--
J.

[uckelman]

Thus spake Brent Easton:
> Have submitted a fix to branch Brent-3.2@8216.
>
> As Seth found, the identity of the Global property container (module,
> map or zone) was not being encoded when Commands where generated to set
> or change property values. This caused all references to a property in
> different containers to be handled by the first container found,
> effectively making the subsequent same named properties invisible.

Merged to 3.2@8218. Try the build I've uploaded.

http://www.vassalengine.org/~uckelman/builds/

I'll roll this into 3.1 tomorrow.

--
J.

[chrono280]

Just tried to install the new build and it doesn't seem to install the vassal EXE (for the Win version of course). Is there a problem with the installer?

Neither standard nor custom install seems to install the EXE. Not sure if any other vital files are missing, I just know it does not run.

Thanks again

[Flaney]

Just tried to install the new build and it doesn't seem to install the vassal EXE (for the Win version of course). ... Neither standard nor custom install seems to install the EXE. Not sure if any other vital files are missing, I just know it does not run.

Confirming failure to install. Reverting to last build.

Flaney