Create account / Log in

Variables / Property Names in place of Actual Values

Talk about module design ideas and techniques.

Moderators: Tim M, uckelman

Variables / Property Names in place of Actual Values

Postby Rommel14 » July 4th, 2011, 5:00 am

Greetings once again!

After receiving some very helpful posts in the last few days, I need to ask a general question for which I have not found an answer anywhere yet.

In several examples provided to me recently, people have been using variable names in place of actual values when setting up Dynamic Properties or Global Properties. This allows the code to plug in a value that may be changed by another piece / marker / etc.

For example:

* The Global Property $TerrainValue$ is an integer (let's say "6", so TerrainValue=6).
* Piece A has a Dynamic Property, $DefenseFactor$, which is dependent upon the map terrain.
* This Dynamic Property is numeric and watches for a CTRL-T command, at which point it sets $DefenseFactor$ to a specific value.
* However, the specific value provided to the Dynamic Property is not an integer but rather a variable, $TerrainValue$.
* Therefore, when CTRL-T is received, the defense factor of Piece A would be set to 6, the terrain value of the map.

Question:

Are there any cases or situations where a $variable$ cannot be substituted for a constant value? I have tried to use a $variable$ in a few traits and it worked OK, but I wasn't sure if there were any established exceptions. Can a $variable$ be used for any constant?

Thanks yet again for any help!
Rommel14
"For to win 100 victories in 100 battles is not the acme of skill.
To subdue the enemy without fighting is the acme of skill.
Thus, what is of supreme importance in war is to attack the enemy's strategy."
-- Sun Tzu, The Art of War
User avatar
Rommel14
 
Posts: 39
Joined: June 27th, 2011, 12:58 am

Re: Variables / Property Names in place of Actual Values

Postby DrNostromo » July 4th, 2011, 3:18 pm

Strangely, there are a few places where a variable won't work when you expect they would. The oddest one that I've had to work around on several occasions is in the Global Key Command trait.

If you use a GKC to send a command to a deck of cards, for instance, you can send the command to all pieces or a fixed number of pieces. This fixed number has to be a integer value ...in cannot be a variable.

In a Layer trait, Property Name must be a numeric integer variable and Level 1 = must be an integer (no variable).

Those are the two that come to mind immediately. I'm sure there are others but I don't recall running into them yet.
User avatar
DrNostromo
 
Posts: 1036
Joined: December 21st, 2007, 3:54 am
Location: Wine Country, Cal. USA

Re: Variables / Property Names in place of Actual Values

Postby Rommel14 » July 7th, 2011, 3:57 am

DrNostromo,

Hmmm...thanks for the practical experience. Your comment about the Deck GKC may force me to rethink part of one solution. As for the Layer Level, yep, I thought that might be the case. I think that I have run into that one before, but I thought it was either a bug or that I had corrupted my build file.

Yet again, thanks for the valuable insights!
Rommel14
"For to win 100 victories in 100 battles is not the acme of skill.
To subdue the enemy without fighting is the acme of skill.
Thus, what is of supreme importance in war is to attack the enemy's strategy."
-- Sun Tzu, The Art of War
User avatar
Rommel14
 
Posts: 39
Joined: June 27th, 2011, 12:58 am


Return to Module Design

Who is online

Users browsing this forum: Google [Bot] and 2 guests